Skip to main content

Last Call Review of draft-ietf-dart-dscp-rtp-07
review-ietf-dart-dscp-rtp-07-opsdir-lc-baker-2014-10-12-00

Request Review of draft-ietf-dart-dscp-rtp
Requested revision 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 L. Black , Paul Jones
I-D 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 (Ting ZOU) (diff)
Opsdir Last Call review of -07 by Fred Baker (diff)
Assignment Reviewer Fred Baker
State Completed
Request Last Call review on draft-ietf-dart-dscp-rtp by Ops Directorate Assigned
Reviewed revision 07 (document currently at 10)
Result Has nits
Completed 2014-10-12
review-ietf-dart-dscp-rtp-07-opsdir-lc-baker-2014-10-12-00
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