Last Call Review of draft-ietf-dart-dscp-rtp-07

Request Review of draft-ietf-dart-dscp-rtp
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-10-14
Requested 2014-10-02
Authors David Black, Paul Jones
Draft last updated 2014-10-12
Completed reviews Genart Last Call review of -07 by Robert Sparks (diff)
Genart Telechat review of -08 by Robert Sparks (diff)
Secdir Last Call review of -07 by Tina Tsou (diff)
Opsdir Last Call review of -07 by Fred Baker (diff)
Assignment Reviewer Fred Baker
State Completed
Review review-ietf-dart-dscp-rtp-07-opsdir-lc-baker-2014-10-12
Reviewed rev. 07 (document currently at 10)
Review result Has Nits
Review completed: 2014-10-12


I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the operational area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

In my opinion, this draft is "Ready with nits". I would like to congratulate the authors on an unusually clear and well-written draft.

As noted in its introduction, "This memo covers the implications of these DiffServ aspects for real-time network communication, including WebRTC traffic [I-D.ietf-rtcweb-overview]." The different "diffServ aspects" in question are the implications of running an application that aggressively marks its traffic for different network treatment in a best effort network - one in which traffic may be routinely reordered, duplicated, or lost in transit. If different DSCP marks result in different routing or the uses of different queues and therefore competing with different and potentially changing data flows ambient in the network, one would expect any such interactions to be exaggerated; for example, if multi-topology routing is used and some data flows take wildly different routes than others, one could readily imagine a packet in each data flow sent simultaneously arriving spaced tens or hundreds of milliseconds apart. While it is not referenced in the document, the term "real-time" as used here is defined in RFC 1633, and refers to an application that requires that the network make specific guarantees to it, whether in end to end delay, minimum delivery rate, or both. The term is generally understood to refer to voice and video services, but can also refer to telemetry or other traffic loads.

The the course of reading the draft, I came up with one matter that the AD should consider. In section 6 ("Guidelines"), several guidelines are given regarding the use of DSCPs in application-related traffic. For example, if reordering would be detrimental to the application, it is advised to not invite reordering by using multiple DSCPs that could drop traffic into different queues or on different routes. However, RFC 2119 is not invoked, the magic words are not capitalized, and there is one guideline that is unlike the others, in that it observes on a fact rather than giving guidance resulting from the fact. I think that may result in confusion on the reader's part: "does this 'Should' mean 'SHOULD', 'should', or something else?" Given that these are described as guidelines, I think the reader will be better served if the RFC 2119 reference is included and the words capitalized. To that end, the odd recommendation SHOULD be reworded from "Cannot rely on end-to-end preservation of DSCPs" to "MUST NOT rely on end-to-end preservation of DSCPs"; the former observes on a fact, while the latter is a useful guideline.




 Message signed with OpenPGP using GPGMail