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

[Magnus Westerlund <[e-mail]>]

Hi,
(As individual)

removing the parts that appears resolved.

On 2014-02-05 07:19, Ram Mohan R (rmohanr) wrote:

>> -----Original Message-----
>> From: Magnus Westerlund [mailto:[e-mail]]
>> On 2013-11-14 18:23, Ram Mohan R (rmohanr) wrote:
>>> From: Magnus Westerlund <[e-mail]>
> 
> 
> 
>>
>>
>>>>
>>>> 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 ?

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.

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

Good, lets use a new TID.

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

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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------