Skip to main content

Shepherd writeup
rfc8837-18

Document shepherd write-up:

             DSCP and other packet markings for WebRTC QoS
                     draft-ietf-tsvwg-rtcweb-qos-14

1. Summary

Document Shepherd: David Black
Responsible AD: Spencer Dawkins


   Many networks, such as service provider and enterprise networks, can
   provide different forwarding treatments for individual packets based
   on Differentiated Services Code Point (DSCP) values on a per-hop
   basis.  This document provides the recommended DSCP values for web
   browsers to use for various classes of WebRTC traffic.

The WG has requested Proposed Standard status because this draft
specifies guidelines for Diffserv usage by WebRTC, including specific
standard DSCPs for browsers to use to apply network-based Diffserv to
network traffic generated by browser-based WebRTC applications.

2. Review and Consensus

The Transport Area WG (TSVWG) is a collection of people with varied
interests that don't individually justify their own working groups.

This draft is supported by the portion of the tsvwg working group that
is familiar with and interested in Diffserv.  The draft has received
significant review and critique from a number of Diffserv experts,
including the draft shepherd, and has undergone significant modification
as a result.  There has been significant interaction with the rtcweb WG
- e.g., coordinated text changes have been made to both this draft and
the rtcweb-transports draft to align functionality and terminology.

Work on this draft originally began in the rtcweb working group; this
draft was transferred to the tsvwg working group as it is primarily a
Diffserv draft that would be better handled in tsvwg, where other
Diffserv work is done.  The draft spent several years in the tsvwg
working group due in part to intermittent author attention, but more
importantly because (in 20/20 hindsight) completion of this draft turned
out to depend on sorting out some deeper issues around the interaction of
Diffserv and real-time communication.  That sorting out was accomplished
by the DART WG resulting in RFC 7657, whose completion cleared the way
for progress on this draft.  The resulting WG discussion on this draft
was active; there is no significant disagreement with the outcomes,
although there are multiple aspirations for future protocol enhancements
to remove limits specified in this draft (e.g., SCTP is currently limited
to one PHB and DSCP per association).

This draft is part of the much larger set of WebRTC specifications,
primarily in the rtcweb working group at IETF and at W3C.  Multiple
WebRTC implementations exist and are being worked on as the drafts
mature.

3. Intellectual Property

Each draft author has stated his/her direct, personal knowledge that any
IPR related to this document has already been disclosed, in conformance
with BCPs 78 and 79.

4. Other Points

idnits 2.13.02 found a couple of DOWNREFs to RFC 4594 and RFC 7657.
These two DOWNREFs were noted in the revised/extendedIETF Last Call
announcement.

Although both RFC 4594 and RFC 7657 are Informational, the document
shepherd believes that they are necessary to understand the Diffserv
technology used in this draft, and hence are appropriate as normative
references (e.g., this draft cites each of these RFCs more than half
a dozen times in support of a number of different concepts).

There are no IANA Considerations.

The IESG should note that this draft is far from a stand-alone document;
as noted above, it is part of the much larger set of WebRTC specs
and uses Diffserv, which is specified in another significant set of RFCs
(including RFC 4594 and RFC 7657).

IETF LC discussion resulted in minor edits and resolution of one issue.
The issue arose when Magnus Westerlund asked the (seemingly simple)
question of how a browser determines whether WebRTC video is interactive.

The answer turns out to be that the browser doesn't do that - all WebRTC
video (and actually all media) is interactive for a WebRTC application
running in a browser because the WebRTC browser API can't specify that
video (or media) is non-interactive.   In addition to explaining that in
this draft, the next version (-13) of the WebRTC transports draft
(draft-ietf-rtcweb-transports) will state that all WebRTC media is
interactive.
Back