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

From: Thomas Stach <[email-masked]>
Date: Sun, 13 May 2018 18:27:57 +0200

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 <[email-masked]>:
>>
>> 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
>
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 14 May 2018 11:24:48 +0200

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 <[email-masked]>:
> 
> Mirja,
>

---

From: Thomas Stach <[email-masked]>
Date: Mon, 14 May 2018 20:39:11 +0200

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

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 18 May 2018 10:06:53 +0200

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 <[email-masked]>:
> 
> Mirja,
> 
> The MUST was only intended for the aggregation of the candidates into one datagram.
>

---

From: Thomas Stach <[email-masked]>
Date: Sat, 19 May 2018 18:32:52 +0200

Mirja,

> As recommend by [RFC8085] Trickle ICE implementations SHOULD NOT send UDP datagrams more often than one every 3 seconds if the RTT is unknown.
Yes it does. I'll use your text.

Thanks
Thomas

---

From: Adam Roach <[email-masked]>
Date: Sat, 19 May 2018 14:49:27 -0500

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:
>> 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?
>>>> 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 08.04.2018 um 20:57 schrieb Thomas Stach 
>>>>>>> <[email-masked]>
>>>>>>> :
>>>>>>>
>>>>>> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ben Campbell <[email-masked]>
Date: Mon, 21 May 2018 10:08:10 -0500

I agree with Adam on this.

Ben.

> On May 19, 2018, at 2:49 PM, Adam Roach <[email-masked]> 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
>

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 21 May 2018 11:14:26 -0400

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 21 May 2018 10:19:34 -0500

> On May 21, 2018, at 10:14 AM, Flemming Andreasen <[email-masked]> wrote:
> 
> 
> 

It’s retransmitted according to normal SIP rules for SDP, as Adam mentioned in the following paragraph.  That’s going to happen one way or another, unless this draft wants to make normative changes to 3261 (I assume not).

Thanks!

Ben.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 21 May 2018 11:30:02 -0400

> It’s retransmitted according to normal SIP rules for SDP, as Adam mentioned in the following paragraph.  That’s going to happen one way or another, unless this draft wants to make normative changes…
Ok - thx

-- Flemming

---

From: Thomas Stach <[email-masked]>
Date: Tue, 22 May 2018 22:07:41 +0200

All,

how should I proceed here?

Would it be OK to mention the SIP retransmission behaviour in instead 
of  Mirja's RFC8085-based proposal ?

E.g. something like:

"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.
If the RTT is unknown, a Trickle ICE agent MUST NOT have
more than one INFO request pending at any one time.
In case of re-transmissions a Trickle-ICE agent needs to adhere to the default SIP
retransmission schedule resulting in intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc."

Mirja, would that text be ok for you?

Kind Regards
Thomas

---

From: Roman Shpount <[email-masked]>
Date: Tue, 22 May 2018 17:11:15 -0400

> retransmission schedule resulting in intervals of 500 ms, 1 s, 2 s, 4 s, 4
I think it should be enough to require that a Trickle ICE agent MUST NOT
have more than one INFO request pending at any one time. Requiring only one
request in progress will also deal with remote proxy or client overload
more gracefully. RTT is likely not a right measure here since INFO message
can traverse multiple proxies and RTT would need to include transport
delays between the proxies as well as proxy processing delay.

Also, there is no need to specify how normal SIP re-transmission works,
especially as it can be interpreted that you disallow modification of SIP
timer values when trickle ICE is used or modify RFC 3261 in some way. I
think it would be better simply state that when INFO messages are sent over
an unreliable transport, they are retransmitted according to the rules
specified in rfc3261 section 17.1.2.1 (
https://tools.ietf.org/html/rfc3261#section-17.1.2.1).

Finally, is it allowed to cancel (stop transmitting) the current INFO
request with ICE candidates and start a new INFO request with new candidate
set if new candidate is discovered while INFO message is being transmitted?
My assumption is that it is not allowed.

Regards,
_____________
Roman Shpount

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 31 May 2018 10:28:47 -0400

Hi

Did we reach a conclusion on this thread ? If not, what do we need to 
move it forward ?

Thanks

-- Flemming

On 5/22/18 5:11 PM, Roman Shpount wrote:
> On Tue, May 22, 2018 at 4:07 PM, Thomas Stach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     E.g. something like:
>
> I think it should be enough to require that a Trickle ICE agent MUST 
> NOT have more than one INFO request pending at any one time. Requiring 
> only one request in progress will also deal with remote proxy or 
> client overload more gracefully. RTT is likely not a right measure 
> here since INFO message can traverse multiple proxies and RTT would 
> need to include transport delays between the proxies as well as proxy 
> processing delay.
>
> Also, there is no need to specify how normal SIP re-transmission 
> works, especially as it can be interpreted that you disallow 
> modification of SIP timer values when trickle ICE is used or modify 
> RFC 3261 in some way. I think it would be better simply state that 
> when INFO messages are sent over an unreliable transport, they are 
> retransmitted according to the rules specified in rfc3261 section 
> 17.1.2.1 (https://tools.ietf.org/html/rfc3261#section-17.1.2.1).
>
> request with ICE candidates and start a new INFO request with new 
> candidate set if new candidate is discovered while INFO message is 
> being transmitted? My assumption is that it is not allowed.
>
> Regards,
> _____________
> Roman Shpount
>

---

From: Thomas Stach <[email-masked]>
Date: Thu, 31 May 2018 21:06:28 +0200

Hi,

I'd be also OK with Roman's Proposal and go ahead with the following text:

"Implementors MUST aggregate ICE candidates in
case that UDP is used as transport protocol.
A Trickle ICE agent MUST NOT have
more than one INFO request pending at any one time.
When INFO messages are sent over an unreliable transport,
they are retransmitted according to the rules specified in
RFC3261 section 17.1.2.1."

I hope that this text is also acceptable for the WG and  our ADs.

Thanks

Thomas

On 2018-05-31 16:28, Flemming Andreasen wrote:
>> On Tue, May 22, 2018 at 4:07 PM, Thomas Stach 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     E.g. something like:
>>
>> NOT have more than one INFO request pending at any one time. 
>> Requiring only one request in progress will also deal with remote 
>> proxy or client overload more gracefully. RTT is likely not a right 
>> measure here since INFO message can traverse multiple proxies and RTT 
>> would need to include transport delays between the proxies as well as 
>> proxy processing delay.
>>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 31 May 2018 15:11:19 -0400

Thomas,

One slight correction:

"Implementors MUST aggregate ICE candidates in case that unreliable
transport protocol such as UDP is used. A Trickle ICE agent MUST NOT have
more than one INFO request pending at any one time.
When INFO messages are sent over an unreliable transport, they are
retransmitted according to the rules specified in  RFC3261 section
17.1.2.1."

Regards,

_____________
Roman Shpount

On Thu, May 31, 2018 at 3:06 PM, Thomas Stach <[email-masked]>
wrote:

> Did we reach a conclusion on this thread ? If not, what do we need to move
> it forward ?
>
> Thanks
>
> -- Flemming
>
> have more than one INFO request pending at any one time. Requiring only
> one request in progress will also deal with remote proxy or client overload
> specified in rfc3261 section 17.1.2.1 (https://tools.ietf.org/html/
> rfc3261#section-17.1.2.1).
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 31 May 2018 14:37:51 -0500

Of the solutions proposed so far, this is the one I like the most. 
Thanks, Roman.

/a

On 5/31/18 2:11 PM, Roman Shpount wrote:
> transport protocol such as UDP is used. A Trickle ICE agent MUST NOT 
> have more than one INFO request pending at any one time.
> On Thu, May 31, 2018 at 3:06 PM, Thomas Stach <[email-masked] 
>>     Did we reach a conclusion on this thread ? If not, what do we
>>     need to move it forward ?
>>
>>     Thanks
>>
>>     -- Flemming
>>
>>>     I think it should be enough to require that a Trickle ICE agent
>>>     MUST NOT have more than one INFO request pending at any one
>>>     time. Requiring only one request in progress will also deal with
>>>     remote proxy or client overload more gracefully. RTT is likely
>>>     not a right measure here since INFO message can traverse
>>>     multiple proxies and RTT would need to include transport delays
>>>     between the proxies as well as proxy processing delay.
>>>
>>>     modification of SIP timer values when trickle ICE is used or
>>>     modify RFC 3261 in some way. I think it would be better simply
>>>     state that when INFO messages are sent over an unreliable
>>>     transport, they are retransmitted according to the rules
>>>     specified in rfc3261 section 17.1.2.1
>>>     (https://tools.ietf.org/html/rfc3261#section-17.1.2.1
>>>     <https://tools.ietf.org/html/rfc3261#section-17.1.2.1>).
>>>
>>>     Finally, is it allowed to cancel (stop transmitting) the current
>>>     INFO request with ICE candidates and start a new INFO request
>>>     with new candidate set if new candidate is discovered while INFO
>>>     message is being transmitted? My assumption is that it is not
>>>     allowed.
>>>
>>>     Regards,
>>>     _____________
>>>     Roman Shpount
>>>
>>
>
>