Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

One more proposal to give a clear recommendation:

Implementors MUST aggregate ICE candidates in
case that UDP is used as transport protocol.
It is RECOMMENDED that Trickle ICE implementations
implement a way to estimate the round-trip time (RTT)
and send only one INFO request per estimated RTT. 
As recommend by [RFC8085] Trickle ICE implementations SHOULD NOT send UDP datagrams more often than one every 3 seconds if the RTT is unknown.

Does that work for you?

Mirja



> Am 14.05.2018 um 20:39 schrieb Thomas Stach <[e-mail]>:
> 
> Mirja,
> 
> you are right it is not super clear.
> 
> The MUST was only intended for the aggregation of the candidates into one datagram.
> 
> Closer to this intention is probably:
> 
> Implementors MUST aggregate ICE candidates in
> case that UDP is used as transport protocol.
> It is RECOMMENDED that Trickle ICE implementations
> implement a way to estimate the round-trip time (RTT)
> and send only one INFO request per estimated RTT,
> since [RFC8085] advises that application don't send UDP datagrams
> more often than one every 3 seconds if the RTT is unknown.
> 
> Kind Regards
> 
> Thomas
> 
> 
> 
> 
> On 2018-05-14 11:24, Mirja Kuehlewind (IETF) wrote:
>> Works for me.
>> 
>> I not sure the wording is super clear though, just to double check:
>> You say basically "Implementors MUST […] send only one INFO request per estimated round-trip time (RTT).“ And the you say „RECOMMENDED […] to estimate RTT“. However if you have the first MUST, I guess you also must estimate the RTT…? Or is it also recommended to ICE to send only every 3 seconds if RTT is unknown?
>> 
>> Mirja
>> 
>> 
>> 
>>> Am 13.05.2018 um 18:27 schrieb Thomas Stach <[e-mail]>:
>>> 
>>> Mirja,
>>> 
>>> sorry for the loong delay in responding.
>>> 
>>> Based on your recommendation I'd re-write section 10.9 as follows
>>> 
>>> 10.9.  Rate of INFO Requests
>>> 
>>>    Given that IP addresses may be gathered rapidly a Trickle ICE Agent
>>>    with many network interfaces might create a high rate of INFO
>>>    requests if every newly detected candidate is trickled individually
>>>    without aggregation.
>>> 
>>>    Implementors MUST aggregate ICE candidates in
>>>    case that UDP is used as transport protocol and send only one INFO
>>>    request per estimated round-trip time (RTT). It is RECOMMENDED that
>>>    Trickle ICE implementations also implement a way to estimate RTT,
>>>    since [RFC8085] advises that application don't send UDP datagrams
>>>    more often than one every 3 seconds if the RTT is unknown.
>>> 
>>>    If the INFO requests are sent on top of TCP, which is probably the
>>>    standard way, this is not an issue for the network anymore, but it
>>>    can remain one for SIP proxies and other intermediaries forwarding
>>>    the SIP INFO messages.  Also, an endpoint may not be able to tell
>>>    that it has congestion controlled transport all the way, such that
>>>    the recommendations for UDP remain valid also in case of TCP.
>>> 
>>> Would that be aceptable?
>>> 
>>> Kind Regards
>>> Thomas
>>> 
>>> 
>>> On 2018-04-13 17:06, Mirja Kuehlewind (IETF) wrote:
>>>> Hi again!
>>>> 
>>>> I actually looked up the recommendation in RFC8085 section 3.1.3 which says:
>>>> 
>>>> "A second case of applications cannot maintain an RTT estimate for
>>>>        a destination, because the destination does not send return
>>>>        traffic.  Such applications SHOULD NOT send more than one UDP
>>>>        datagram every 3 seconds and SHOULD use an even less aggressive
>>>>        rate when possible."
>>>> 
>>>> 
>>>>> Am 08.04.2018 um 20:57 schrieb Thomas Stach <[e-mail]>
>>>>> :
>>>>> 
>>>>> In general, it is RECOMMENDED that a Trickle ICE Agent sends only one INFO request per RTT.
>>>>> A quarantine period of 100ms would be on the safe side, but lower values might be fine as well
>>>>> if the typically deployment scenario assumes a shorter RT.“
>>>>> 
>>>> So a recommendation of 100ms is probably not appropriate here. Inline with RFC8085 it would be 3 seconds. Thus it probably makes sense to strongly recommend to implement a way to estimate RTT. Please also add a reference to RFC8085.
>>>> 
>>>> Sorry for my late input. I should have double checked with RFC8085 earlier. I hope this can still be addressed appropriately.
>>>> 
>>>> Mirja
>>>> 
>>>> 
>>>> 
>