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

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 03 Apr 2018 07:37:02 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mmusic-trickle-ice-sip-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the well-written doc and the quick response to the initial tsv
review. Also thanks to Jörg for the thorough and very helpful review!

As flagged by the tsv review, there can be an issue with the aggregation of
candidates in one INFO message when rate limited and the path MTU/UPD
fragmentation. While this is a small point only and I'm sure it can be easily
addressed, it important enough that I decided to put a discuss in. I'm sure
this can be resolved quickly as well.

Also if the document could give further guidance on an acceptable maximum for
the rate of INFO requests that be even better!

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial comments:

1) sec 4.3.2: "When sending the Answer in the 200 OK response to the INVITE
request,
   the Answerer needs to repeat exactly the same Answer that was
   previously sent in the unreliable provisional response in order to
   fulfill the corresponding requirements in [RFC3264].  Thus, the
   Offerer needs to be prepared for receiving a different number of
   candidates in that repeated Answer than previously exchanged via
   trickling and MUST ignore the candidate information in that 200 OK
   response."
   What do I miss? Why can there be a different number of candidates if the
   repeated Answer needs to be exactly the same...? Or is there an "not"
   missing? Not an expert though, so might be just me...

2) I guess section 10.1 could also be moved to the appendix but it is short
enough that leaving it in the body is fine as well.

---

From: Thomas Stach <[email-masked]>
Date: Wed, 4 Apr 2018 21:54:52 +0200

Mirja,

thanks for your comments.

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/
As large messages are already addressed in RFC 3261, I could add 
something like
"As a potentially large number of candidates are aggregated in a INFO 
request,
the message size can easily exceed the path MTU. SIP [RF3261] requires 
that if a request
is within 200 bytes of the path MTU, or if it is larger than 1300 bytes 
and the path MTU is unknown,
that the request is sent using an RFC 2914 
<https://tools.ietf.org/html/rfc2914> [43 
<https://tools.ietf.org/html/rfc3261#ref-43>] congestion controlled 
transport protocol,
such as TCP.
"
> the rate of INFO requests that be even better!
Adam proposed in his review to

"... require some minimum quarantine period between INFO requests 
(probably something in the range of 20 ms),
during which any new candidates that are gathered are aggregated into 
the next INFO message."

Would that be enough of a guidance?
If the answer is sent in a provisional response, it might have included 
a small  number (or even 0) of candidates.
Before the 200 OK is sent the answerer might have trickled additional 
candidates in INFOs.
However, the additional candidates will not appear in the answer in the 
body of the 200OK.
This is due to a requirement in RFC3264, that the answer in the 
provisional response must be exactly the same as in the 200OK.
So the total number of candidates that the offerer received will be 
different from the number of candidates in that answer.

> ,
So, I probably leave it where it is.

Thanks for your review

Thomas

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 5 Apr 2018 16:19:50 +0200

Hi Thomas,

> Am 04.04.2018 um 21:54 schrieb Thomas Stach <[email-masked]>:
> 
> Mirja,
> 
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
>> 
> As large messages are already addressed in RFC 3261, I could add something like
> "As a potentially large number of candidates are aggregated in a INFO request, 
> the message size can easily exceed the path MTU. SIP [RF3261] requires that if a request
> is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown,
> that the request is sent using an RFC 2914 [43] congestion controlled transport protocol, 
> such as TCP.

The only point is the interaction with the rate limit here. If you have to split up into two/multiple messages, you will not be able to send both immediately but have to wait for another interval. Maybe that can be further clarified with an additional sentence.

> "... require some minimum quarantine period between INFO requests (probably something in the range of 20 ms), 
> during which any new candidates that are gathered are aggregated into the next INFO message."
> 

Yes, that would be good! Usually we recommends something like one message per RTT. So probably 100ms or 200ms would be on the safe side but lower might be fine as well if the typically deployment scenario assumes a shorter RTT.

> If the answer is sent in a provisional response, it might have included a small  number (or even 0) of candidates.
> Before the 200 OK is sent the answerer might have trickled additional candidates in INFOs. 
> However, the additional candidates will not appear in the answer in the body of the 200OK. 
> This is due to a requirement in RFC3264, that the answer in the provisional response must be exactly the same as in the 200OK.
> So the total number of candidates that the offerer received will be different from the number of candidates in that answer.

Ah this is about the 200Ok answer. Somehow I missed that.

> So, I probably leave it where it is.

Sure!

Thanks!

Mirja

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 5 Apr 2018 12:12:44 -0500

This is Mirja's ballot thread, but ...

On Thu, Apr 5, 2018 at 9:19 AM, Mirja Kuehlewind (IETF) <[email-masked]
> wrote:

> The only point is the interaction with the rate limit here. If you have to
> split up into two/multiple messages, you will not be able to send both
> immediately but have to wait for another interval. Maybe that can be
> further clarified with an additional sentence.
>
> > "
> Yes, that would be good! Usually we recommends something like one message
> per RTT. So probably 100ms or 200ms would be on the safe side but lower
> might be fine as well if the typically deployment scenario assumes a
> shorter RTT.
>

I also appreciate this guidance (with or without Mirja's friendly
amendment). What I usually hope for, is "not saturating a path by retrying
at line rate" :-)

Anything that's not that, is a step in the right direction.

Spencer

---

From: Thomas Stach <[email-masked]>
Date: Sun, 8 Apr 2018 20:57:39 +0200

Mirja,

> The only point is the interaction with the rate limit here. If you have to split up into two/multiple messages, you will not be able to send both immediately but have to wait for another interval.…
Well, as SIP already prohibits fragmenting a packet that that is larger 
than 1300 bytes, do we need to say something about the rate of for 
sending such "illegal" packets?

> Yes, that would be good! Usually we recommends something like one message per RTT. So probably 100ms or 200ms would be on the safe side but lower might be fine as well if the typically deployment s…

  I propose to add a 3rd paragraph to section 10.9

"As a potentially large number of candidates are aggregated in an INFO 
request,
the message size can easily exceed the path MTU. SIP [RF3261] requires 
that if a request
is within 200 bytes of the path MTU, or if it is larger than 1300 bytes 
and the path MTU is unknown,
that the request is sent using an RFC 2914 [43] congestion controlled 
transport protocol,
such as TCP.
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."

Kind Regards
Thomas

<\snip>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Mon, 9 Apr 2018 07:51:29 -0700

Hi Thomas,

see below.

> Am 08.04.2018 um 11:57 schrieb Thomas Stach <[email-masked]>:
> 
> Mirja,
> 
> Well, as SIP already prohibits fragmenting a packet that that is larger than 1300 bytes, do we need to say something about the rate of for sending such "illegal" packets?

Sorry, yes that is fine. Didn’t read your earlier reply correctly. 

> "As a potentially large number of candidates are aggregated in an INFO request,
> 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.“

Thanks! Please update and I’ll clear!

Mirja

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 13 Apr 2018 17:06:09 +0200

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]>:
> 

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