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

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