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

Hi Emil,

The current mechanism helps determine RTT and packet loss, since transaction could be confused with the retransmission mechanism in RFC 5389 it was not used. 

-Tiru

> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Emil Ivov
> Sent: Friday, May 22, 2015 1:31 AM
> To: Bernard Aboba; rtcweb@ietf.org; The IESG
> Subject: Re: [rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness
> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb