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,

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

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


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

> 
>> ,
>> 
>> 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.
>> 
> So, I probably leave it where it is.

Sure!

Thanks!

Mirja


> 
> Thanks for your review
> 
> Thomas
>> 
>