Telechat Review of draft-ietf-mmusic-trickle-ice-sip-14
review-ietf-mmusic-trickle-ice-sip-14-tsvart-telechat-ott-2018-04-03-00
| Request | Review of | draft-ietf-mmusic-trickle-ice-sip |
|---|---|---|
| Requested rev. | no specific revision (document currently at 18) | |
| Type | Telechat Review | |
| Team | Transport Area Review Team (tsvart) | |
| Deadline | 2018-04-03 | |
| Requested | 2018-02-22 | |
| Draft last updated | 2018-04-03 | |
| Completed reviews |
Genart Last Call review of -12 by Dale Worley
(diff)
Secdir Last Call review of -12 by Shawn Emery (diff) Tsvart Last Call review of -12 by Joerg Ott (diff) Tsvart Telechat review of -14 by Joerg Ott (diff) Secdir Telechat review of -13 by Shawn Emery (diff) Genart Telechat review of -14 by Dale Worley (diff) |
|
| Assignment | Reviewer | Joerg Ott |
| State | Completed | |
| Review | review-ietf-mmusic-trickle-ice-sip-14-tsvart-telechat-ott-2018-04-03 | |
| Reviewed rev. | 14 (document currently at 18) | |
| Review result | Ready with Nits | |
| Review completed: | 2018-04-03 |
Review
review-ietf-mmusic-trickle-ice-sip-14-tsvart-telechat-ott-2018-04-03
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.