[Dart] FW: Document Action: 'Differentiated Services (DiffServ) and Real-time Communication' to Informational RFC (draft-ietf-dart-dscp-rtp-10.txt)

["Black, David" <[e-mail]>]

> The DART working group was formed in April of 2014. The working group
> was chartered to focus on a constrained problem and conclude quickly.

And we did it - two IETF meeting cycles from start to IESG approval!

Many, many thanks to everyone who contributed - it's been a pleasure
to work on this draft.  Moreover, the one-and-only DART WG meeting in
Toronto was the most fun I've had at the front of the room in an IETF
WG meeting in a long time.  Thank you!

--David

-----Original Message-----
From: IETF-Announce [mailto:[e-mail]] On Behalf Of The IESG
Sent: Wednesday, November 12, 2014 11:52 PM
To: IETF-Announce
Cc: dart mailing list; dart chair; RFC Editor
Subject: Document Action: 'Differentiated Services (DiffServ) and Real-time Communication' to Informational RFC (draft-ietf-dart-dscp-rtp-10.txt)

The IESG has approved the following document:
- 'Differentiated Services (DiffServ) and Real-time Communication'
  (draft-ietf-dart-dscp-rtp-10.txt) as Informational RFC

This document is the product of the DiffServ Applied to Real-time
Transports Working Group.

The IESG contact persons are Richard Barnes and Alissa Cooper.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/





Technical Summary

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.


Working Group Summary

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.


Document Quality

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.


Personnel

The Document Shepherd is Ben Campbell.  The Responsible AD is Richard Barnes.