Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness

[Emil Ivov <[e-mail]>]

On 21.05.15 1:48, Bernard Aboba wrote:
> This is a review of draft-ietf-rtcweb-stun-consent-freshness.
>
> Overall, I believe that this document is not yet ready for publication
> as a proposed standard,
> due to transport-related issues.  Rather than building upon the RFC 5389
> transport model
> (including the transaction structure and RTT/RTO estimator), the
> specification proposes a
> new (and poorly specified) transport model that does not adapt properly
> to networks with differing transport characteristics.

I think we can easily fix this if we replace semantic usage of "STUN 
request" throughout the specification with "STUN transaction".

For example, in page 4 in the following paragraph:

    Each STUN binding request for consent MUST use a new
    cryptographically strong [RFC4086] STUN transaction ID.  Each STUN
    binding requests for consent is transmitted once only.  Hence, the
    sender cannot assume that it will receive a response for each consent
    request, and a response might be for a previous request (rather than
    for the most recently sent request).

replacing request with transaction we would get:

    Each STUN transaction MUST use a new cryptographically strong
    [RFC4086] STUN transaction ID.  Each STUN transaction for consent
    is transmitted once only. Hence, the sender cannot assume that it
    will receive a response for each consent transaction, and a response
    might be for a previous transaction (rather than for the most
    recently sent request).

The fact that this entire paragraphs becomes redundant after the change 
is probably good indication that we were basically defining STUN 
transactions ...

Obviously using transactions for every consent check would leave us with 
a couple of potential issues, like, what if you already have an ongoing 
STUN transaction and randomization tells you to start a new one. Those 
could be easily fixed however. For example, by simply starting the 
random timer after a STUN transaction has completed (as opposed to after 
sending the request).

Emil

-- 
https://jitsi.org