Protocol Action: 'DSCP Packet Markings for WebRTC QoS' to Proposed Standard (draft-ietf-tsvwg-rtcweb-qos-18.txt)

The IESG <> Mon, 22 August 2016 14:11 UTC

Return-Path: <>
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id DF3A012D575; Mon, 22 Aug 2016 07:11:25 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: The IESG <>
To: "IETF-Announce" <>
Subject: Protocol Action: 'DSCP Packet Markings for WebRTC QoS' to Proposed Standard (draft-ietf-tsvwg-rtcweb-qos-18.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <>
Date: Mon, 22 Aug 2016 07:11:25 -0700
Archived-At: <>
Cc:,,, The IESG <>,
X-Mailman-Version: 2.1.17
List-Id: "IETF announcement list. No discussions." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Aug 2016 14:11:26 -0000

The IESG has approved the following document:
- 'DSCP Packet Markings for WebRTC QoS'
  (draft-ietf-tsvwg-rtcweb-qos-18.txt) as Proposed Standard

This document is the product of the Transport Area Working Group.

The IESG contact persons are Mirja Kühlewind and Spencer Dawkins.

A URL of this Internet Draft is:

Technical Summary

   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.

Working Group Summary

    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

Document Quality

    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


    Document Shepherd: David Black
    Responsible AD: Spencer Dawkins