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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Thomas,

see below.

> Am 08.04.2018 um 11:57 schrieb Thomas Stach <[e-mail]>:
> 
> Mirja,
> 
> On 2018-04-05 16:19, Mirja Kuehlewind (IETF) wrote:
>> Hi Thomas,
>> 
>>> Am 04.04.2018 um 21:54 schrieb Thomas Stach <[e-mail]>:
>>> 
>>> Mirja,
>>> 
>>> thanks for your comments.
>>> 
>>> On 2018-04-03 16:37, Mirja Kühlewind wrote:
>>>> 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.
>>>> 
>>> 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.
> 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. 

> 
>> 
>>> "
>>>> Also if the document could give further guidance on an acceptable maximum for
>>>> 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?
>> 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 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.“

Thanks! Please update and I’ll clear!

Mirja


> 
> Kind Regards
> Thomas
> 
> <\snip>
>