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

[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 
<https://tools.ietf.org/html/rfc2914> [43 
<https://tools.ietf.org/html/rfc3261#ref-43>] congestion controlled 
transport protocol,
such as TCP.
"
> 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?
>
>
> ----------------------------------------------------------------------
> 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.

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

Thanks for your review

Thomas
>