draft-ietf-tsvwg-rtcweb-qos-12.txt   draft-ietf-tsvwg-rtcweb-qos-13.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: July 30, 2016 Cisco Systems Expires: September 1, 2016 Cisco Systems
D. Druta D. Druta
AT&T AT&T
January 27, 2016 February 29, 2016
DSCP and other packet markings for WebRTC QoS DSCP and other packet markings for WebRTC QoS
draft-ietf-tsvwg-rtcweb-qos-12 draft-ietf-tsvwg-rtcweb-qos-13
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 July 30, 2016. This Internet-Draft will expire on September 1, 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 Standards . . . . . . . . . . . . . . . . . 3 2. Relation to Other Specifications . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. DSCP Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5 5. DSCP Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Downward References . . . . . . . . . . . . . . . . . . . . . 7 8. Downward References . . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
10. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 8
11. Document History . . . . . . . . . . . . . . . . . . . . . . 8 11. Document History . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 9 12.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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
skipping to change at page 2, line 50 skipping to change at page 2, line 50
1. Private, wide-area networks. 1. Private, wide-area networks.
2. Residential Networks. If the congested link is the broadband 2. Residential Networks. If the congested link is the broadband
uplink in a cable or DSL scenario, often residential routers/NAT uplink in a cable or DSL scenario, often residential routers/NAT
support preferential treatment based on DSCP. support preferential treatment based on DSCP.
3. Wireless Networks. If the congested link is a local wireless 3. Wireless Networks. If the congested link is a local wireless
network, marking may help. network, marking may help.
Traditionally, DSCP values have been thought of as being site DSCP values are in principle site specific, with each site selecting
specific, with each site selecting its own code points for its own code points for controlling per-hop-behavior to influence the
controlling per-hop-behavior to influence the QoS for transport-layer QoS for transport-layer flows. However in the WebRTC use cases, the
flows. However in the WebRTC use cases, the browsers need to set browsers need to set them to something when there is no site specific
them to something when there is no site specific information. In information. In this document, "browsers" is used synonymously with
this document, "browsers" is used synonymously with "Interactive User "Interactive User Agent" as defined in the HTML specification,
Agent" as defined in the HTML specification,
[W3C.REC-html5-20141028]. This document describes a subset of DSCP [W3C.REC-html5-20141028]. This document describes a subset of DSCP
code point values drawn from existing RFCs and common usage for use code point values drawn from existing RFCs and common usage for use
with WebRTC applications. These code points are solely defaults. with WebRTC applications. These code points are solely defaults.
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 Standards 2. 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 3, line 49 skipping to change at page 3, line 48
further in the next section. further in the next section.
This specification does not change or override the advice in any This specification does not change or override the advice in any
other standards about setting packet markings. Rather, it simply other standards about setting packet markings. Rather, it simply
selects a subset of DSCP values that is relevant in the WebRTC selects a subset of DSCP values that is relevant in the WebRTC
context. context.
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. The forwarding (DF) value to provide basic best effort service. Even so,
mitigation for such action is through an authorization mechanism. there is benefit in marking traffic even if it only benefits the
Such authorization mechanism is outside the scope of this document. first few hops. The implications are discussed in Secton 3.2 of
[RFC7657]. Further, a mitigation for such action is through an
There is benefit in marking traffic even if it only benefits the authorization mechanism. Such an authorization mechanism is outside
first few hops. the scope of this document.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. 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
skipping to change at page 5, line 41 skipping to change at page 5, line 41
| | | | | | | | | | | |
| Data | CS1 | DF | AF11 | AF21 | | Data | CS1 | DF | AF11 | AF21 |
| | (8) | (0) | | | | | (8) | (0) | | |
+------------------------+-------+------+-------------+-------------+ +------------------------+-------+------+-------------+-------------+
Table 1: Recommended DSCP Values for WebRTC Applications Table 1: Recommended DSCP Values for WebRTC Applications
The application priority, indicated by the columns "very low", "low", The application priority, indicated by the columns "very low", "low",
"Medium", and "high", signifies the relative importance of the flow "Medium", and "high", signifies the relative importance of the flow
within the application. It is an input that the browser receives to within the application. It is an input that the browser receives to
assist it in selecting the DSCP value. Application priority does not assist in selecting the DSCP value and adjusting the network
refer to priority in the network transport. transport behavior.
The above table assumes that packets marked with CS1 are treated as The above table assumes that packets marked with CS1 are treated as
"less than best effort". However, the treatment of CS1 is "less than best effort". However, the treatment of CS1 is
implementation dependent. If an implementation treats CS1 as other implementation dependent. If an implementation treats CS1 as other
than "less than best effort", then the actual priority (or, more than "less than best effort", then the actual priority (or, more
precisely, the per-hop-behavior) of the packets may be changed from precisely, the per-hop-behavior) of the packets may be changed from
what is intended. It is common for CS1 to be treated the same as DF, what is intended. It is common for CS1 to be treated the same as DF,
so applications and browsers using CS1 cannot assume that CS1 will be so applications and browsers using CS1 cannot assume that CS1 will be
treated differently than DF [RFC7657]. Implementers should also note treated differently than DF [RFC7657]. However, it is also possible
that excess EF traffic is dropped. This could mean that a packet per [RFC2474] for CS1 traffic to be given better treatment than DF,
marked as EF may not get through as opposed to a packet marked with a thus caution should be exercised when electing to use CS1.
different DSCP value.
Implementers should also note that excess EF traffic is dropped.
This could mean that a packet marked as EF may not get through as
opposed to a packet marked with a different DSCP value. This is not
a flaw, but how excess EF traffic is intended to be treated.
The browser SHOULD first select the flow type of the flow. Within The browser SHOULD first select the flow type of the flow. Within
the flow type, the relative importance of the flow SHOULD be used to the flow type, the relative importance of the flow SHOULD be used to
select the appropriate DSCP value. select the appropriate DSCP value.
The combination of flow type and application priority provides The combination of flow type and application priority provides
specificity and helps in selecting the right DSCP value for the flow. specificity and helps in selecting the right DSCP value for the flow.
All packets within a flow SHOULD have the same application priority. All packets within a flow SHOULD have the same application priority.
In some cases, the selected application priority cell may have In some cases, the selected application priority cell may have
multiple DSCP values, such as AF41 and AF42. These offer different multiple DSCP values, such as AF41 and AF42. These offer different
drop precedences. The different drop precedence values provides drop precedences. The different drop precedence values provides
additional granularity in classifying packets within a flow. For additional granularity in classifying packets within a flow. For
example, in a video conference, the video flow may have medium example, in a video conference, the video flow may have medium
application priority. If so, either AF42 or AF43 may be selected. application priority. If so, either AF42 or AF43 may be selected.
If the I-frames in the stream are more important than the P-frames, If the I-frames in the stream are more important than the P-frames,
then the I-frames can be marked with AF42 and the P-frames marked then the I-frames can be marked with AF42 and the P-frames marked
with AF43. with AF43.
It is worth noting that the application priority is utilized by the It is worth noting that the application priority is utilized by the
SCTP scheduler for data channel traffic per coupled congestion control mechanism for media flows per
[I-D.ietf-rtcweb-data-channel]. [I-D.ietf-rmcat-coupled-cc] and the SCTP scheduler for data channel
traffic per [I-D.ietf-rtcweb-data-channel].
For reasons discussed in Section 6 of [RFC7657], if multiple flows For reasons discussed in Section 6 of [RFC7657], if multiple flows
are multiplexed using a reliable transport (e.g., TCP) then all of are multiplexed using a reliable transport (e.g., TCP) then all of
the packets for all flows multiplexed over that transport-layer flow the packets for all flows multiplexed over that transport-layer flow
MUST be marked using the same DSCP value. Likewise, all WebRTC data MUST be marked using the same DSCP value. Likewise, all WebRTC data
channel packets transmitted over an SCTP association MUST be marked channel packets transmitted over an SCTP association MUST be marked
using the same DSCP value, regardless of how many data channels using the same DSCP value, regardless of how many data channels
(streams) exist or what kind of traffic is carried over the various (streams) exist or what kind of traffic is carried over the various
SCTP streams. In the event that the browser wishes to change the SCTP streams. In the event that the browser wishes to change the
DSCP value in use for an SCTP association, it MUST reset the SCTP DSCP value in use for an SCTP association, it MUST reset the SCTP
skipping to change at page 7, line 16 skipping to change at page 7, line 24
application priority combination specified in Table 1 (above), then application priority combination specified in Table 1 (above), then
the network node at the edge will remark the DSCP value based on the network node at the edge will remark the DSCP value based on
policies. This could result in the flow not getting the network policies. This could result in the flow not getting the network
treatment it expects based on the original DSCP value in the packet. treatment it expects based on the original DSCP value in the packet.
Subsequently, if the packet enters a network that supports a larger Subsequently, if the packet enters a network that supports a larger
number of these combinations, there may not be sufficient information number of these combinations, there may not be sufficient information
in the packet to restore the original markings. Mechanisms for in the packet to restore the original markings. Mechanisms for
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. The service provided to a packet is dependent levels of service. However, DSCP marking is expected to provide a
upon the network design along the path, as well as the network statistical improvement in real-time service as a whole. The service
conditions at every hop. provided to a packet is dependent upon the network design along the
path, as well as the network conditions at every hop.
6. Security Considerations 6. Security Considerations
This specification does not add any additional security implication This specification does not add any additional security implication
other than the normal application use of DSCP not already addressed other than the normal application use of DSCP not already addressed
by the following specifications. For security implications on use of by the following specifications. For security implications on use of
DSCP, please refer to Section 7 of [RFC7657] and Section 6 of DSCP, please refer to Section 7 of [RFC7657] and Section 6 of
[RFC4594]. Please also see [I-D.ietf-rtcweb-security] as an [RFC4594]. Please also see [I-D.ietf-rtcweb-security] as an
additional reference. additional reference.
skipping to change at page 7, line 42 skipping to change at page 7, line 51
8. Downward References 8. Downward References
This specification contains a downwards reference to [RFC4594]. This specification contains a downwards reference to [RFC4594].
However, the parts of that RFC used by this specification are However, the parts of that RFC used by this specification are
sufficiently stable for this downward reference. sufficiently stable for this downward reference.
9. Acknowledgements 9. Acknowledgements
Thanks to David Black, Magnus Westerland, Paolo Severini, Jim Thanks to David Black, Magnus Westerland, Paolo Severini, Jim
Hasselbrook, Joe Marcus, Erik Nordmark, and Michael Tuexen for their Hasselbrook, Joe Marcus, Erik Nordmark, Michael Tuexen, and Brian
invaluable input. Carpenter for their invaluable input.
10. Dedication 10. Dedication
This document is dedicated to the memory of James Polk, a long-time This document is dedicated to the memory of James Polk, a long-time
friend and colleague. James made important contributions to this friend and colleague. James made important contributions to this
specification, including being one of its primary authors. The IETF specification, including being one of its primary authors. The IETF
global community mourns his loss and he will be missed dearly. global community mourns his loss and he will be missed dearly.
11. Document History 11. Document History
skipping to change at page 8, line 35 skipping to change at page 8, line 42
Communication (WebRTC): Media Transport and Use of RTP", Communication (WebRTC): Media Transport and Use of RTP",
draft-ietf-rtcweb-rtp-usage-25 (work in progress), June draft-ietf-rtcweb-rtp-usage-25 (work in progress), June
2015. 2015.
[I-D.ietf-rtcweb-security] [I-D.ietf-rtcweb-security]
Rescorla, E., "Security Considerations for WebRTC", draft- Rescorla, E., "Security Considerations for WebRTC", draft-
ietf-rtcweb-security-08 (work in progress), February 2015. ietf-rtcweb-security-08 (work in progress), February 2015.
[I-D.ietf-rtcweb-transports] [I-D.ietf-rtcweb-transports]
Alvestrand, H., "Transports for WebRTC", draft-ietf- Alvestrand, H., "Transports for WebRTC", draft-ietf-
rtcweb-transports-10 (work in progress), October 2015. rtcweb-transports-11 (work in progress), January 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997, RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[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>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-rmcat-coupled-cc]
Islam, S., Welzl, M., and S. Gjessing, "Coupled congestion
control for RTP media", draft-ietf-rmcat-coupled-cc-00
(work in progress), September 2015.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS "Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI
10.17487/RFC2474, December 1998, 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>. <http://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/ "Assured Forwarding PHB Group", RFC 2597, DOI 10.17487/
RFC2597, June 1999, RFC2597, June 1999,
<http://www.rfc-editor.org/info/rfc2597>. <http://www.rfc-editor.org/info/rfc2597>.
 End of changes. 16 change blocks. 
34 lines changed or deleted 44 lines changed or added

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