[rtcweb] Comments on draft-ietf-rtcweb-stun-consent-freshness-00

[Magnus Westerlund <[e-mail]>]

Hi,

Here are my review comments on draft-ietf-rtcweb-stun-consent-freshness-00

1. General:
I understood one reason for splitting this out in its own document is
that we might have other future users of this mechanism. Thus I think it
should be written to be less WebRTC specific. It is appropriate to use
WebRTC as motivation for requirements etc, but the actual description of
the mechanism should be done in a neutral way.

2. Section 1.
   When a session is first established, WebRTC implementations are
   required to perform STUN connectivity checks as part of ICE
   [RFC5245].  That initial consent is not described further in this
   document.

When generalizing this, I think it is important to make clear that it is
assumed that ICE is being used for that initial consent.

3. Section 1:
"This document describes a new STUN usage with a request and response
   which verifies the remote peer consents to receive traffic, and
   detects loss of liveness."

I am missing a word after "request and response", transaction or
messages maybe?

4. Section 3:
 A
   response is necessary both for consent to continue sending traffic,
   as well as to ensure connectivity.

Is verify rather than "ensure" better?

5. Section 4:
   Consent freshness serves as a circuit breaker (so that if the path or
   remote peer fails the WebRTC browser stops sending all traffic on
   that remote peer), determining session liveness serves the purpose of
   notifying the application of connectivity failure so that the
   application can take appropriate action.

traffic on/traffic to

What is the definition of a peer here? What scope does the stop sending
have?

6. Section 4:
   1.  A consent timer, Tc, whose value is determined by the browser.
       This value MUST be 15 seconds.

I see a contradiction here, should it be determined by the browser or be
15 s? If it is 15, can you please motivate why it is this value, or
point to where it is motivated?

7. Section 4:
   If a valid STUN Binding Response is received, the consent timer is
   reset and fires again Tc seconds later.

Is it reset to the time of receiving it or the time of sending the
initial request this is the response for?

8. Section 4:
   If a valid STUN Binding Response is not received after 500ms, the
   STUN Binding Request is retransmitted (with the same Transaction ID
   and all other fields).  As long as a valid STUN Binding Response is
   not received, this retransmission is repeated every 500ms until Tf
   seconds have elapsed or a valid response is received.

So no exponential back-off on the retransmission timer. I think that is
fine. However, I think it do require you to expand a bit on what happens
when one gets multiple response on the same Transaction ID. For example
additional responses do they or do they not reset the Tc timer?

Then I wonder about the cases where the RTT is above 500 ms, should one
then scale this factor to be once per RTT?

9. Section 4:
"with the same Transaction ID"

Why not use a new transaction ID for each sent packet? It would allow
tracking loss and determine RTT more reliable. All for the small cost of
keeping track of slightly more Transaction IDs?

10. Section 4.
   Liveness timer: If no packets have been received on the local port in
   Tr seconds, the WebRTC browser MUST inform the JavaScript that
   connectivity has been lost.  The JavaScript application will use this
   notification however it desires (e.g., cease transmitting to the
   remote peer, provide a notification to the user, etc.).  Note the
   definition of a received packet is liberal, and includes an SRTP
   packet that fails authentication, a STUN Binding Request with an
   invalid USERNAME or PASSWORD, or any other packet.

I think this requires some considerations in regards to RTT. If the RTT
is 700 ms, high for a real-time app but not unheard of at all. Then a Tr
= 1 second would fire on a single loss.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------