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

[Magnus Westerlund <[e-mail]>]

Hi,

Removing things where I am in agreement or like your response.

On 2013-11-14 18:23, Ram Mohan R (rmohanr) wrote:
> Hi Magnus,
> 
> Thanks for your comments. Please see inline for responses.
> 
> 
> -----Original Message-----
> From: Magnus Westerlund <[e-mail]>
> Date: Tuesday, 12 November 2013 8:28 PM

>>
>> 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?
> 
> NEW:
> This document describes a new STUN usage with a request and response
> messages which verifies the remote peer consents to receive traffic, and
> detects loss of liveness.

Isn't it either "which verifies the remote peer's consent to" or "which
verifies that the remote peer consents to"?



>
>>
>> 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.
>>
> 
>>
>> What is the definition of a peer here?
> 
> Peer is the sink for the traffic originated from the sender for that flow
> (5 tuple). If a browser uses different 5 tuple for each stream(Audio,
> video, data) it sends then it should do consent for each flow. If it uses
> same 5-tuple (mux case) then there will be only one consent.

Please be explicit about this. I think it is easy to interpret that this
would apply to all flows from one end-point to a given destination address.

> 
> 
> 
>> What scope does the stop sending
>> have?
> 
> The stream that is being sent on a flow(5 tuple) for which a consent has
> failed will be stopped. If all the streams are muxed on a same 5 tuple the
> entire traffic will be stopped.
> 

I am fine with this, as long as the document is explicit about this
being the scope.


>>
>> 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?
> 
> The default value of 15 was some thing that EKR and Justin gave us based
> on the implementation/testing and fine tuning they have done on their
> browsers. I agree we can have some text around it that explains how this
> number is arrived. We will add the same.

Good, I think it is important we understand the considerations of why
this is a reasonable choice.


>>
>> 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?
> 
> Additional responses MUST reset the Tc timer.
> 

Okay, that appears fine.

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

What about this question?

>>
>> 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?
> 
> Yes, new transaction ID will help to determine the packet loss and RTT.
> 

Yes, so what is preferable here? Doing cloned retransmission, or
generating new TIDs for each outgoing request?

> 
> 
>>
>> 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.
> 
> Ok.  will start a discussion for this item in a separate email.
> 

Good

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]
----------------------------------------------------------------------