Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS
draft-ietf-tsvwg-rtcweb-qos-18

[Ballot comment]

I was a little surprised that there's no additional security
considerations due to the fact that JS can set the
application priority - isn't that different enough (from
earlier uses of DSCP) that a browser might want to be a
little suspicious if some JS wants to try send too much
stuff as high priority, given that that same JS code might
be running on many many browsers all at once for a while
after some WebRTC server has been hacked? Or do we conclude
that that won't make any real difference or make it easier
for such JS malware to cause some kind of DoS somewhere?

[Ballot comment]

I was a litle surprised that there's no additional security
considerations due to the fact that JS can set the
application priority - isn't that different enough (from
earlier uses of DSCP) that a browser might want to be a
little suspicious if some JS wants to try send too much
stuff as high priority, given that that same JS code might
be running on many many browsers all at once for a while
after some WebRTC server has been hacked? Or do we conclude
that that won't make any real difference or make it easier
for such JS malware to cause some kind of DoS somewhere?

[Ballot comment]
Section 5:

The draft claims that "Currently, all WebRTC video is assumed to be interactive" and makes a reference to [I-D.ietf-rtcweb-transports], but the referred draft does not contain any explanation regarding this. Is this some kind of well known fact in WebRTC circles? If so, is it documented somewhere?

Section 8:

Is this really required to be in the document? The shepherd writeup does explain the rationale for the downrefs.

[Ballot comment]
I would suggest doing a pass through the document to check for uses of the term "browser" and "non-browser" to see if they could or should align with the terms defined in RFC 7742. It's not obvious to me why this document is using a different definition of "browser" than is used in that document.

[Ballot comment]
A very well-written document! Thanks for all the work!

One question: the doc says:
"This specification [...] does not change any advice or requirements in other
  IETF RFCs.  The contents of this specification are intended to be a
  simple set of implementation recommendations based on the previous
  RFCs."
This sounds like an information doc for me. However, I'm okay with standards track as this should be consistently applied by WebRTC browsers. Just wondering if this was discussed (because it also reads like this change in scope was applied in a later phase of the live-time of this doc)?

[Ballot comment]
A very-well written document! Thanks for all the work!

One question: the doc says:
"This specification [...] does not change any advice or requirements in other
  IETF RFCs.  The contents of this specification are intended to be a
  simple set of implementation recommendations based on the previous
  RFCs."
This sounds like an information doc for me. However, I'm okay with standards track as this should be consistently applied by WebRTC browsers. Just wondering if this was discussed (because it also reads like this change in scope was applied in a later phase of the live-time of this doc)?

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.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-rtcweb-qos-15.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

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

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "David L. Black" , draft-ietf-tsvwg-rtcweb-qos@ietf.org, tsvwg@ietf.org, david.black@emc.com, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Second Last Call:  (DSCP and other packet markings for WebRTC QoS) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'DSCP and other packet markings for WebRTC QoS'
  as Proposed Standard

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 2016-05-02. 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


  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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ballot/


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

Please note that this standards-track draft includes normative references
to RFC 4594 and RFC 7657, which are both Informational RFCs. The previous
Last Call announcement did not call attention to this, as required by BCP
97.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-rtcweb-qos-15.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

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

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "David L. Black" , draft-ietf-tsvwg-rtcweb-qos@ietf.org, tsvwg@ietf.org, david.black@emc.com, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: EXTENDED Last Call:  (DSCP and other packet markings for WebRTC QoS) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'DSCP and other packet markings for WebRTC QoS'
  as Proposed Standard

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 2016-04-18. 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.

Please note that this is an extended four-week Last Call for a working group
draft, to accommodate participants preparing for and attending IETF 95.

Abstract


  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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ballot/


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

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-rtcweb-qos-15.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

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

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "David L. Black" , draft-ietf-tsvwg-rtcweb-qos@ietf.org, tsvwg@ietf.org, david.black@emc.com, spencerdawkins.ietf@gmail.com, tsvwg-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (DSCP and other packet markings for WebRTC QoS) to Proposed Standard


The IESG has received a request from the Transport Area Working Group WG
(tsvwg) to consider the following document:
- 'DSCP and other packet markings for WebRTC QoS'
  as Proposed Standard

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 2016-04-11. 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.

Please note that this is an extended three-week Last Call for a working group
draft, to accommodate participants preparing for IETF 95.

Abstract


  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 file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rtcweb-qos/ballot/


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

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 Web RTC, 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.
It will be important to note these two DOWNREFs in the IETF 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).