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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 5 Feb 2014 06:19:14 +0000

Hi Magnus,

Sorry for delay. Please see inline for answers

>-----Original Message-----
>From: Magnus Westerlund [mailto:[email-masked]]
>Sent: Friday, November 15, 2013 2:32 PM
>To: Ram Mohan R (rmohanr);
>[email-masked]; [email-masked]
>Subject: Re: Comments on draft-ietf-rtcweb-stun-consent-freshness-00
>
>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 <[email-masked]>
>> 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"?

I will change to "which verifies the remote peer's consent 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.

Sure. We will add the above text and make it clearer in Section 4

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

Will make this explicit in the draft

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

Sure. Will check with Justin/EKR and add some text that justifies why 15
sec is default.

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

The ICE agent can learn the RTT of a given path from RTCP reports (if
present). If there is no RTCP reports then it can use STUN BindReq/Res to
learn RTT.

STUN allows you to learn the RTT of a path when you sending Binding
request and get a Binding response for a candidate pair. Before consent
timer
is started the browser¹s ICE agent would have done ICE checks and
concluded on a candidate for each media stream.  So an ICE agent can use
the RTT learnt here.
Thoughts on this ?

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

Using same Transaction ID would lead the peer ICE agent think this request
as a retransmission and it may not reset its Consent timer.  So I think
using new ID is better.

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

As discussed above the ICE agent can learn the RTT of a given path from
RTCP reports (if present) or compute the RTT from STUN BindReq/Response.
It can then use the learnt value
to influence the Tr value.

Regards,

Ram

>
>Good
>
>Cheers
>
>Magnus Westerlund
>
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone  +46 10 7148287
>Färögatan 6                | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden| mailto: [email-masked]
>----------------------------------------------------------------------
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 13 Feb 2014 09:14:57 +0100

Hi,
(As individual)

removing the parts that appears resolved.

> concluded on a candidate for each media stream.  So an ICE agent can use

I think using the STUN connectivity checks to gather an RTT estimate is
fine for this and likely the easiest. That avoids the need to have the
RTCP stack closely integrated with the consent mechanism.

And if I understand each new request has a new Transaction ID, that way
one can keep a running filtered RTT estimate to use for this. But, I do
believe that we should ha a mechanism in place to protect against RTTs >
500 ms. In buffer bloat case, as well as certain paths they do occur.

> as a retransmission and it may not reset its Consent timer.  So I think

Good, lets use a new TID.

> to influence the Tr value.

I will leave it to you to consider how to use and specify a proposal for
this.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------