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.


Attachment:


signature.asc




Description:

 Message signed with OpenPGP using GPGMail