Differentiated Services (Diffserv) and Real-Time Communication
draft-ietf-dart-dscp-rtp-10

[Ballot comment]
...
  So, for two arbitrary network endpoints, there can be no assurance
  that the DSCP set at the source endpoint will be preserved and
  presented at the destination endpoint.  Rather, it is quite likely
  that the DSCP will be set to zero (e.g., at the boundary of a network
  operator that distrusts or does not use the DSCP field) or to a value
  deemed suitable by an ingress classifier for whatever network 5-tuple
  it carries.
...

In general operational experience is it is unsafe if you are going to employ dscp marking in your your network, to not sanitize other dscp marking on ingress, which leads to a really fun tautology  in that in order to use it you have to break it first.

[Ballot comment]
Thanks for making this cross-area piece of work so well.

I had a little bit of a private mutter about whether it is the reliable transport protocols themselves or the implementations that are intolerant to out of order packets. Maybe the text here is a little too kind to the implementations and a little too critical of the protocols. But it is not a big issue in this document.

[Ballot comment]
Thank you for doing this work. It's excellent, and valuable.

I have a small number of editorial questions.

In this text:

1.  Introduction

  The results of using multiple DSCPs to obtain different QoS
  treatments within a single network 5-tuple (e.g., reordering) have
  transport protocol interactions, particularly with congestion control
  functionality.

This is probably perfectly accurate, but I find it confusing. I think my problem is that the sentence sounds like the sender's goal was to cause problems with transport protocol mechanisms. I think it means

- senders use multiple DSCPs to obtain different QoS treatments within a 5-tuple

- a side effect of using multiple DSCPs is that packets with different DSCPs will often be reordered

- this side effect causes problems with transport protocol mechanisms that expects largely in-order delivery, particularly with congestion control functionality

Am I reading this correctly?

In this text:

2.1.  RTP Background

  The STUN and TURN protocols were originally designed for use of UDP,

I’m not sure what “for use of UDP” means. Is this “to use UDP as a transport”?

  however, TURN has been extended to use TCP as a transport for
  situations in which UDP does not work [RFC6062].  When TURN selects
  use of TCP, the entire real-time communications session is carried
  over a single TCP connection (i.e., 5-tuple).

http://tools.ietf.org/html/rfc7350 has been published recently, defining DTLS as a transport for STUN. Is that in any way relevant to this section?

I feel horribly pedantic for even asking this, but in this text:
3.2.  Traffic Classifiers and DSCP Remarking

  DSCP markings are not end-to-end in general.  Each network can make
  its own decisions about what PHBs to use and which DSCP maps to each
  PHB.  While every PHB specification includes a recommended DSCP, and
  RFC 4594 [RFC4594] recommends their end-to-end usage, there is no
  requirement that every network support any PHBs

would this be “support any PHBs beyond Default Forwarding”?

In this text:

5.1.  DiffServ, Reordering and Transport Protocols

  Transport protocols provide data communication behaviors beyond those
  possible at the IP layer.  An important example is that TCP [RFC0793]
  provides reliable in-order delivery of data with congestion control.

is there a better reference for TCP than RFC 793? Isn’t that a version of TCP that does NOT have congestion control? Perhaps draft-ietf-tcpm-tcp-rfc4614bis-08 ...

Alternatively, if you dropped “with congestion control”, you might still be making your point … reliable, in-order delivery is beyond what IP does.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dart-dscp-rtp-07, which is currently in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Differentiated Services (DiffServ) and Real-time Communication) to Informational RFC


The IESG has received a request from the DiffServ Applied to Real-time
Transports WG (dart) to consider the following document:
- 'Differentiated Services (DiffServ) and Real-time Communication'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-10-14. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo describes the interaction between Differentiated Services
  (DiffServ) network quality of service (QoS) functionality and real-
  time network communication, including communication based on the
  Real-time Transport Protocol (RTP).  DiffServ is based on network
  nodes applying different forwarding treatments to packets whose IP
  headers are marked with different DiffServ Code Points (DSCPs).
  WebRTC applications, as well as some conferencing applications, have
  begun using the Session Description Protocol (SDP) bundle negotiation
  mechanism to send multiple traffic streams with different QoS
  requirements using the same network 5-tuple.  The results of using
  multiple DSCPs to obtain different QoS treatments within a single
  network 5-tuple (e.g., reordering) have transport protocol
  interactions, particularly with congestion control functionality.  In
  addition, DSCP markings may be changed or removed between the traffic
  source and destination.  This memo covers the implications of these
  DiffServ aspects for real-time network communication, including
  WebRTC.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ballot/


No IPR declarations have been submitted directly on this I-D.

Shepherd Proto Writeup for draft-ietf-dart-dscp-rtp-06


1. Summary

The document shepherd is Ben Campbell. The responsible Area Director is
Richard Barnes.

From the document abstract:

"This document describes the interaction between Differentiated Services
(DiffServ) network quality of service (QoS) functionality and real-time
network communication, including communication based on the Real-time
Transport Protocol (RTP).  DiffServ is based on network nodes applying
different forwarding treatments to packets whose IP headers are marked
with different DiffServ Code Points (DSCPs). WebRTC applications, as
well as some conferencing applications, have begun using the Session
Description Protocol (SDP) bundle negotiation mechanism to send multiple
traffic streams with different QoS requirements using the same network
5-tuple.  Use of different DSCPs to obtain different QoS treatments
within a single network 5-tuple, the results (e.g., reordering) may
cause transport protocol interactions, particularly with congestion
control functionality.  In addition, DSCP markings may be changed or
removed between the traffic source and destination.  This document
covers the implications of these DiffServ aspects for real-time network
communication, including WebRTC."

The document does not attempt to create standards, or state any
normative requirements. Rather, it offers considerations and guidance
for protocol designers and application implementors that consider
sending multiple RTP streams with a shared IP 5-tuple. Therefore the
requested publication type is "informational".

2. Review and Consensus

The DART working group was formed in April of 2014. The working group
was chartered to focus on a constrained problem and conclude quickly.
DART adopted this document with very little controversy.

While the working group is nominally in the RAI area, it has been
effectively a cross-area effort between RAI and TSV. This document
resulted in lively discussion among a core group of experts from both
areas. In general, the discussion converged quickly, and there were no
unresolved controversies.

In the shepherd's opinion, the only impediment to consensus was that
discussion kept overturning rocks, forcing participants to think about
new issues. One notable issue was whether this draft should offer
guidance on the interaction between having multiple DSCPs in a stream
and the multiple stream optimization work
(draft-ietf-avtcore-rtp-multi-stream-optimisation.) The working group
chose to avoid such guidance in this draft, and leave that for the
multi-stream draft to solve.

During the working group last call, we solicited comments from RTCWEB,
AVTCORE, MMUSIC, CLUE, TSVWG, and RMCAT. In the shepherd's opinion, it
has been well reviewed, and represents a strong consensus. The shepherd
does not think it needs any further specific reviews, other than the
usual reviews it would receive during the IETF last call process (for
example, Gen-ART and SecDir).

Since the document does not specify protocol, it will not be directly
implemented. However, we expect that at least the RTCWEB working group
will incorporate guidance from this document into it's output.

3. Intellectual Property

There have been no IPR disclosers related to this document. Both authors
have confirmed that they are not personally aware of any undisclosed
IPR.

4. Other Points

This document makes no requests of IANA.

The shepherd is not aware of any issues or additional information needed
for the IESG review of this document.