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

[Flemming Andreasen <[e-mail]>]

On 5/19/18 3:49 PM, Adam Roach 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.
>
What happens if the INFO request is lost ?

Thanks

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