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

[Spencer Dawkins at IETF <[e-mail]>]

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

On Thu, Apr 5, 2018 at 9:19 AM, Mirja Kuehlewind (IETF) <[e-mail]
> 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.
>
> > "
> >> 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 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


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