draft-ietf-tsvwg-rtcweb-qos-16.txt   draft-ietf-tsvwg-rtcweb-qos-17.txt 
Network Working Group P. Jones Network Working Group P. Jones
Internet-Draft S. Dhesikan Internet-Draft S. Dhesikan
Intended status: Standards Track C. Jennings Intended status: Standards Track C. Jennings
Expires: November 12, 2016 Cisco Systems Expires: November 21, 2016 Cisco Systems
D. Druta D. Druta
AT&T AT&T
May 11, 2016 May 20, 2016
DSCP Packet Markings for WebRTC QoS DSCP Packet Markings for WebRTC QoS
draft-ietf-tsvwg-rtcweb-qos-16 draft-ietf-tsvwg-rtcweb-qos-17
Abstract Abstract
Many networks, such as service provider and enterprise networks, can Many networks, such as service provider and enterprise networks, can
provide different forwarding treatments for individual packets based provide different forwarding treatments for individual packets based
on Differentiated Services Code Point (DSCP) values on a per-hop on Differentiated Services Code Point (DSCP) values on a per-hop
basis. This document provides the recommended DSCP values for web basis. This document provides the recommended DSCP values for web
browsers to use for various classes of WebRTC traffic. browsers to use for various classes of WebRTC traffic.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 12, 2016. This Internet-Draft will expire on November 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Relation to Other Specifications . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Relation to Other Specifications . . . . . . . . . . . . . . 3
4. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. DSCP Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5 5. DSCP Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Downward References . . . . . . . . . . . . . . . . . . . . . 8 8. Downward References . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
10. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 8
11. Document History . . . . . . . . . . . . . . . . . . . . . . 8 11. Document History . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Differentiated Services Code Point (DSCP) [RFC2474] packet marking Differentiated Services Code Point (DSCP) [RFC2474] packet marking
can help provide QoS in some environments. This specification can help provide QoS in some environments. This specification
provides default packet marking for browsers that support WebRTC provides default packet marking for browsers that support WebRTC
applications, but does not change any advice or requirements in other applications, but does not change any advice or requirements in other
IETF RFCs. The contents of this specification are intended to be a IETF RFCs. The contents of this specification are intended to be a
simple set of implementation recommendations based on the previous simple set of implementation recommendations based on the previous
RFCs. RFCs.
skipping to change at page 3, line 11 skipping to change at page 3, line 11
There are cases where these DSCP markings do not help, but, aside There are cases where these DSCP markings do not help, but, aside
from possible priority inversion for "less than best effort traffic" from possible priority inversion for "less than best effort traffic"
(see Section 5), they seldom make things worse if packets are marked (see Section 5), they seldom make things worse if packets are marked
appropriately. appropriately.
DSCP values are in principle site specific, with each site selecting DSCP values are in principle site specific, with each site selecting
its own code points for controlling per-hop-behavior to influence the its own code points for controlling per-hop-behavior to influence the
QoS for transport-layer flows. However in the WebRTC use cases, the QoS for transport-layer flows. However in the WebRTC use cases, the
browsers need to set them to something when there is no site specific browsers need to set them to something when there is no site specific
information. In this document, "browsers" is used synonymously with information. This document describes a subset of DSCP code point
"Interactive User Agent" as defined in the HTML specification, values drawn from existing RFCs and common usage for use with WebRTC
[W3C.REC-html5-20141028]. This document describes a subset of DSCP applications. These code points are intended to be the default
code point values drawn from existing RFCs and common usage for use values used by a WebRTC application. While other values could be
with WebRTC applications. These code points are intended to be the used, using a non-default value may result in unexpected per-hop
default values used by a WebRTC application. While other values behavior. It is RECOMMENDED that WebRTC applications use non-default
could be used, using a non-default value may result in unexpected values only in private networks that are configured to use different
per-hop behavior. It is RECOMMENDED that WebRTC applications use values.
non-default values only in private networks that are configured to
use different values.
This specification defines inputs that are provided by the WebRTC This specification defines inputs that are provided by the WebRTC
application hosted in the browser that aid the browser in determining application hosted in the browser that aid the browser in determining
how to set the various packet markings. The specification also how to set the various packet markings. The specification also
defines the mapping from abstract QoS policies (flow type, priority defines the mapping from abstract QoS policies (flow type, priority
level) to those packet markings. level) to those packet markings.
2. Relation to Other Specifications 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The terms "browser" and "non-browser" are defined in [RFC7742] and
carry the same meaning in this document.
3. Relation to Other Specifications
This document is a complement to [RFC7657], which describes the This document is a complement to [RFC7657], which describes the
interaction between DSCP and real-time communications. That RFC interaction between DSCP and real-time communications. That RFC
covers the implications of using various DSCP values, particularly covers the implications of using various DSCP values, particularly
focusing on Real-time Transport Protocol (RTP) [RFC3550] streams that focusing on Real-time Transport Protocol (RTP) [RFC3550] streams that
are multiplexed onto a single transport-layer flow. are multiplexed onto a single transport-layer flow.
There are a number of guidelines specified in [RFC7657] that apply to There are a number of guidelines specified in [RFC7657] that apply to
marking traffic sent by WebRTC applications, as it is common for marking traffic sent by WebRTC applications, as it is common for
multiple RTP streams to be multiplexed on the same transport-layer multiple RTP streams to be multiplexed on the same transport-layer
skipping to change at page 4, line 17 skipping to change at page 4, line 24
The DSCP value set by the endpoint is not trusted by the network. In The DSCP value set by the endpoint is not trusted by the network. In
addition, the DSCP value may be remarked at any place in the network addition, the DSCP value may be remarked at any place in the network
for a variety of reasons to any other DSCP value, including default for a variety of reasons to any other DSCP value, including default
forwarding (DF) value to provide basic best effort service. Even so, forwarding (DF) value to provide basic best effort service. Even so,
there is benefit in marking traffic even if it only benefits the there is benefit in marking traffic even if it only benefits the
first few hops. The implications are discussed in Secton 3.2 of first few hops. The implications are discussed in Secton 3.2 of
[RFC7657]. Further, a mitigation for such action is through an [RFC7657]. Further, a mitigation for such action is through an
authorization mechanism. Such an authorization mechanism is outside authorization mechanism. Such an authorization mechanism is outside
the scope of this document. the scope of this document.
3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
4. Inputs 4. Inputs
WebRTC applications send and receive two types of flows of WebRTC applications send and receive two types of flows of
significance to this document: significance to this document:
o media flows which are RTP streams [I-D.ietf-rtcweb-rtp-usage] o media flows which are RTP streams [I-D.ietf-rtcweb-rtp-usage]
o data flows which are data channels [I-D.ietf-rtcweb-data-channel] o data flows which are data channels [I-D.ietf-rtcweb-data-channel]
Each of the RTP streams and distinct data channels consists of all of Each of the RTP streams and distinct data channels consists of all of
skipping to change at page 8, line 13 skipping to change at page 8, line 13
restoring such original DSCP is outside the scope of this document. restoring such original DSCP is outside the scope of this document.
In summary, DSCP marking provides neither guarantees nor promised In summary, DSCP marking provides neither guarantees nor promised
levels of service. However, DSCP marking is expected to provide a levels of service. However, DSCP marking is expected to provide a
statistical improvement in real-time service as a whole. The service statistical improvement in real-time service as a whole. The service
provided to a packet is dependent upon the network design along the provided to a packet is dependent upon the network design along the
path, as well as the network conditions at every hop. path, as well as the network conditions at every hop.
6. Security Considerations 6. Security Considerations
This specification does not add any additional security implications Since the JavaScript application specifies the flow type and
beyond those addressed in the following DSCP-related specifications. application priority that determine the media flow DSCP values used
For security implications on use of DSCP, please refer to Section 7 by the browser, the browser could consider application use of a large
of [RFC7657] and Section 6 of [RFC4594]. Please also see number of higher priority flows to be suspicious. If the server
[I-D.ietf-rtcweb-security] as an additional reference. hosting the JavaScript application is compromised, many browsers
within the network might simultaneously transmit flows with the same
DSCP marking. The DiffServ architecture requires ingress traffic
conditioning for reasons that include protecting the network from
this sort of attack.
Otherwise, this specification does not add any additional security
implications beyond those addressed in the following DSCP-related
specifications. For security implications on use of DSCP, please
refer to Section 7 of [RFC7657] and Section 6 of [RFC4594]. Please
also see [I-D.ietf-rtcweb-security] as an additional reference.
7. IANA Considerations 7. IANA Considerations
This specification does not require any actions from IANA. This specification does not require any actions from IANA.
8. Downward References 8. Downward References
This specification contains a downwards reference to [RFC4594] and This specification contains a downwards reference to [RFC4594] and
[RFC7657]. However, the parts of the former RFC used by this [RFC7657]. However, the parts of the former RFC used by this
specification are sufficiently stable for this downward reference. specification are sufficiently stable for this downward reference.
skipping to change at page 9, line 46 skipping to change at page 10, line 10
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, DOI Guidelines for DiffServ Service Classes", RFC 4594, DOI
10.17487/RFC4594, August 2006, 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>. <http://www.rfc-editor.org/info/rfc4594>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services [RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657, DOI (Diffserv) and Real-Time Communication", RFC 7657, DOI
10.17487/RFC7657, November 2015, 10.17487/RFC7657, November 2015,
<http://www.rfc-editor.org/info/rfc7657>. <http://www.rfc-editor.org/info/rfc7657>.
[RFC7742] Roach, A., "WebRTC Video Processing and Codec
Requirements", RFC 7742, DOI 10.17487/RFC7742, March 2016,
<http://www.rfc-editor.org/info/rfc7742>.
12.2. Informative References 12.2. Informative References
[G.1010] International Telecommunications Union, "End-user [G.1010] International Telecommunications Union, "End-user
multimedia QoS categories", Recommendation ITU-T G.1010, multimedia QoS categories", Recommendation ITU-T G.1010,
November 2001. November 2001.
[I-D.ietf-rmcat-coupled-cc] [I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-02 control for RTP media", draft-ietf-rmcat-coupled-cc-02
(work in progress), April 2016. (work in progress), April 2016.
skipping to change at page 10, line 37 skipping to change at page 11, line 5
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services", Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003, RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>. <http://www.rfc-editor.org/info/rfc3662>.
[W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
Navara, E., O&#039;Connor, E., and S. Pfeiffer, "HTML5",
World Wide Web Consortium Recommendation REC-
html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>.
Authors' Addresses Authors' Addresses
Paul E. Jones Paul E. Jones
Cisco Systems Cisco Systems
Email: paulej@packetizer.com Email: paulej@packetizer.com
Subha Dhesikan Subha Dhesikan
Cisco Systems Cisco Systems
Email: sdhesika@cisco.com Email: sdhesika@cisco.com
Cullen Jennings Cullen Jennings
Cisco Systems Cisco Systems
Email: fluffy@cisco.com Email: fluffy@cisco.com
 End of changes. 14 change blocks. 
38 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/