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

[Thomas Stach <[e-mail]>]

Mirja,


On 2018-05-18 10:06, Mirja Kuehlewind (IETF) wrote:
> 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?
Yes it does. I'll use your text.

Thanks
Thomas
>
> 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
>>>>>
>>>>>
>>>>>