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

[Ben Campbell <[e-mail]>]

I agree with Adam on this.

Ben.

> On May 19, 2018, at 2:49 PM, Adam Roach <[e-mail]> wrote:
> 
> Sorry to jump in after this appears to have come to a conclusion, but it seems that this would be much easier to specify and to implement if it simply said that only one INFO request were allowed to be pending at any one time. This will limit cadence to exact RTT (rather than estimated RTT), and eliminate the additional language around unknown RTT handling.
> 
> In particular, the language below is problematic in that, taken on its face, it contradicts SIP message retransmission handling: it says that UDP datagrams are to be sent once every 3 seconds if the RTT is unknown, while SIP requires a retransmission schedule of 0s, 500ms, 1.5s, 3.5s, etc. I really don't want implementors to read the normative behavior below as modifying the message retransmission algorithm.
> 
> /a
> 
> On 5/19/18 11:32 AM, Thomas Stach wrote:
>> 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
>>>>>>> 
>>>>>>> 
>>>>>>> 
>> 
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
> 
>