Telechat Review of draft-ietf-mmusic-trickle-ice-sip-14
review-ietf-mmusic-trickle-ice-sip-14-tsvart-telechat-ott-2018-04-03-00

Reviewer: Jörg Ott
Review result: Ready with Nits

This is a re-review of draft-ietf-mmusic-trickle-ice-sip.  The previous review
was on draft-ietf-mmusic-trickle-ice-sip-12. Revision -14 of the draft largely
addresses the issues on congestion-controlled transport.

Recap from the previous review for completeness:
I've reviewed this document as part of TSV-ART's ongoing effort to review key
IETF documents. These comments were written primarily for the transport area
directors, but are copied to the document's authors for their information and
to allow them to address any issues raised.  When done at the time of IETF Last
Call, the authors should consider this review together with any other last-call
comments they receive. Please always CC tsv-art@ietf.org if you reply to or
forward this review.

The draft defines a how the Session Initiation Protocol (SIP) shall
make use the incremental discovery and exchange of IP addresses as
provided by tricke ICE; the main purpose is reducing call setup latency.

The draft defines address the SIP aspects comprehensively with all
necessary features.  From a transport perspective relevant is primarily
its use the SIP INFO method for carrying updates to the collected
addresses to notify the respective peer that further ones can now
be tried and inform when when the address gathering is complete.

The revisions to section 10.9 largely address the congestion control
issues I raised before.  But there is new issue coming up:

10.9 Rate of INFO Requests
   Given that IP addresses may be gathered rapidly a Trickle ICE Agent
   with many network interfaces might create a high rate of INFO
   requests if every newly detected candidate is trickled individually
   without aggregation.  Implementors MUST consider aggregating ICE
   candidates in case that UDP is used as transport protocol and sending send
   INFOs only at some configurable intervals.

The aggregation now raises the issue of SIP INFO messages exceeding MTU size.
Measurements in the wild have shown that SIP INVITE messages may easily be
larger than MTU size, so this should be factored in.  If an INFO requests
exceeds a reasonable MTU size (say, 1280 bytes),  it should be sent, but not
earlier than 200ms after the previous INFO message was sent -- or something
along these lines.  Such a rare limit could be specified in general and, if
aggregation is employed, too, probably not harm the call setup process.

Nit: Put the statement "Also, an endpoint may not be able to tell
that it has congestion controlled transport all the way." into its own paragraph
so that this stands out.