draft-ietf-tsvwg-rtcweb-qos-08.txt   draft-ietf-tsvwg-rtcweb-qos-09.txt 
Network Working Group S. Dhesikan Network Working Group S. Dhesikan
Internet-Draft C. Jennings Internet-Draft C. Jennings
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: July 25, 2016 D. Druta, Ed. Expires: July 26, 2016 D. Druta, Ed.
AT&T AT&T
P. Jones P. Jones
Cisco Systems Cisco Systems
January 22, 2016 January 23, 2016
DSCP and other packet markings for WebRTC QoS DSCP and other packet markings for WebRTC QoS
draft-ietf-tsvwg-rtcweb-qos-08 draft-ietf-tsvwg-rtcweb-qos-09
Abstract Abstract
Many networks, such as service provider and enterprise networks, can Many networks, such as service provider and enterprise networks, can
provide treatment for individual packets based on Differentiated provide treatment for individual packets based on Differentiated
Services Code Point (DSCP) values on a per-hop basis. This document Services Code Point (DSCP) values on a per-hop basis. This document
provides the recommended DSCP values for web browsers to use for provides the recommended DSCP values for web browsers to use for
various classes of WebRTC traffic. various classes of WebRTC traffic.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 25, 2016. This Internet-Draft will expire on July 26, 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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
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 some inputs that the browser in a WebRTC This specification defines some inputs that the browser in a WebRTC
application can consider to aid in determining how to set the various application can consider to aid in determining how to set the various
packet markings and defines the mapping from abstract QoS policies packet markings and defines the mapping from abstract QoS policies
(flow type, priority level) to those packet markings. (flow type, priority level) to those packet markings.
2. Relation to Other Standards 2. Relation to Other Standards
This document exists as a complement to [I-D.ietf-dart-dscp-rtp], This document exists as a complement to [RFC7657], which describes
which describes the interaction between DSCP and real-time the interaction between DSCP and real-time communications. It covers
communications. It covers the implications of using various DSCP the implications of using various DSCP values, particularly focusing
values, particularly focusing on Real-time Transport Protocol (RTP) on Real-time Transport Protocol (RTP) [RFC3550] streams that are
[RFC3550] streams that are multiplexed onto a single transport-layer multiplexed onto a single transport-layer flow.
flow.
There are a number of guidelines specified in There are a number of guidelines specified in [RFC7657] that should
[I-D.ietf-dart-dscp-rtp] that should be followed when marking traffic be followed when marking traffic sent by WebRTC applications, as it
sent by WebRTC applications, as it is common for multiple RTP streams is common for multiple RTP streams to be multiplexed on the same
to be multiplexed on the same transport-layer flow. Generally, the transport-layer flow. Generally, the RTP streams would be marked
RTP streams would be marked with a value as appropriate from Table 1. with a value as appropriate from Table 1. A WebRTC application might
A WebRTC application might also multiplex data channel also multiplex data channel [I-D.ietf-rtcweb-data-channel] traffic
[I-D.ietf-rtcweb-data-channel] traffic over the same 5-tuple as RTP over the same 5-tuple as RTP streams, which would also be marked as
streams, which would also be marked as per that table. The guidance per that table. The guidance in [RFC7657] says that all data channel
in [I-D.ietf-dart-dscp-rtp] says that all data channel traffic would traffic would be marked with a single value that is typically
be marked with a single value that is typically different than the different than the value(s) used for RTP streams multiplexed with the
value(s) used for RTP streams multiplexed with the data channel data channel traffic over the same 5-tuple, assuming RTP streams are
traffic over the same 5-tuple, assuming RTP streams are marked with a marked with a value other than default forwarding (DF). This is
value other than default forwarding (DF). This is expanded upon expanded upon 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. It simply selects a other standards about setting packet markings. It simply selects a
subset of DSCP values that is relevant in the WebRTC context. This subset of DSCP values that is relevant in the WebRTC context. This
document also specifies the inputs that are needed by the browser to document also specifies the inputs that are needed by the browser to
provide to the media engine. provide to the media engine.
The DSCP value set by the endpoint is not always trusted by the The DSCP value set by the endpoint is not always trusted by the
network. Therefore, the DSCP value may be remarked at any place in network. Therefore, the DSCP value may be remarked at any place in
the network for a variety of reasons to any other DSCP value, the network for a variety of reasons to any other DSCP value,
skipping to change at page 4, line 23 skipping to change at page 4, line 23
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 entities transmit and receive two types of media of WebRTC entities transmit and receive two types of media of
significance to this document: RTP streams significance to this document:
[I-D.ietf-rtcweb-rtp-usage] and data channels
[I-D.ietf-rtcweb-data-channel]. Each of the RTP streams and distinct o media flows which are RTP streams [I-D.ietf-rtcweb-rtp-usage]
data channels consists of all of the packets associated with an o data flows which are data channels [I-D.ietf-rtcweb-data-channel]
independent media entity and are not alway equivalent to a transport-
layer flow defined by a 5-tuple (source address, destination address, Each of the RTP streams and distinct data channels consists of all of
source port, destination port, and protocol). There may be multiple the packets associated with an independent media entity and are not
RTP streams and data channels multiplexed over the same 5-tuple, with always equivalent to a transport-layer flow defined by a 5-tuple
each having a different level of importance to the application and, (source address, destination address, source port, destination port,
therefore, potentially marked using different DSCP values than and protocol). There may be multiple RTP streams and data channels
another RTP stream or data channel within the same transport-layer multiplexed over the same 5-tuple, with each having a different level
flow. (Note that there are restrictions with respect to marking of importance to the application and, therefore, potentially marked
different data channels carried within the same SCTP association as using different DSCP values than another RTP stream or data channel
outlined in Section 5.) within the same transport-layer flow. (Note that there are
restrictions with respect to marking different data channels carried
within the same SCTP association as outlined in Section 5.)
The following are the inputs that the browser provides to the media The following are the inputs that the browser provides to the media
engine: engine:
o Flow Type: The browser provides this input as it knows if the flow o Flow Type: The browser provides this input as it knows if the flow
is audio, interactive video with or without audio, non-interactive is audio, interactive video with or without audio, non-interactive
video with or without audio, or data. video with or without audio, or data.
o Application Priority: Another input is the relative importance of o Application Priority: Another input is the relative importance of
an RTP stream or data channel flow. Many applications have an RTP stream or data channel. Many applications have multiple
multiple flows of the same Flow Type and often some flows are more flows of the same Flow Type and often some flows are more
important than others. For example, in a video conference where important than others. For example, in a video conference where
there are usually audio and video flows, the audio flow may be there are usually audio and video flows, the audio flow may be
more important than the video flow. JavaScript applications can more important than the video flow. JavaScript applications can
tell the browser whether a particular flow is high, medium, low or tell the browser whether a particular flow is high, medium, low or
very low importance to the application. very low importance to the application.
[I-D.ietf-rtcweb-transports] defines in more detail what an [I-D.ietf-rtcweb-transports] defines in more detail what an
individual flow is within the WebRTC context. individual flow is within the WebRTC context.
5. DSCP Mappings 5. DSCP Mappings
skipping to change at page 6, line 24 skipping to change at page 6, line 27
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.
For reasons discussed in Section 6 of [I-D.ietf-dart-dscp-rtp], if For reasons discussed in Section 6 of [RFC7657], if multiple flows
multiple flows are multiplexed using a reliable transport (e.g., TCP) are multiplexed using a reliable transport (e.g., TCP) then all of
then all of the packets for all flows multiplexed over that the packets for all flows multiplexed over that transport-layer flow
transport-layer flow MUST be marked using the same DSCP value. MUST be marked using the same DSCP value. Likewise, all WebRTC data
Likewise, all WebRTC data channel packets transmitted over an SCTP channel packets transmitted over an SCTP association MUST be marked
association MUST be marked using the same DSCP value, regardless of using the same DSCP value, regardless of how many data channels
how many data channels (streams) exist or what kind of traffic is (streams) exist or what kind of traffic is carried over the various
carried over the various SCTP streams. In the event that the browser SCTP streams. In the event that the browser wishes to change the
wishes to change the DSCP value in use for an SCTP association, it DSCP value in use for an SCTP association, it MUST reset the SCTP
MUST reset the SCTP congestion controller after changing values. congestion controller after changing values. Frequent changes in the
Frequent changes in the DSCP value used for an SCTP association are DSCP value used for an SCTP association are discouraged, though, as
discouraged, though, as this would defeat any attempts at effectively this would defeat any attempts at effectively managing congestion.
managing congestion. It should also be noted that any change in DSCP It should also be noted that any change in DSCP value that results in
value that results in a reset of the congestion controller puts the a reset of the congestion controller puts the SCTP association back
SCTP association back into slow start, which may have undesirable into slow start, which may have undesirable effects on application
effects on application performance. performance.
For the data channel traffic multiplexed over an SCTP association, it For the data channel traffic multiplexed over an SCTP association, it
is RECOMMENDED that the DSCP value selected be the one associated is RECOMMENDED that the DSCP value selected be the one associated
with the highest priority requested for all data channels multiplexed with the highest priority requested for all data channels multiplexed
over the SCTP association. Likewise, when multiplexing multiple over the SCTP association. Likewise, when multiplexing multiple
flows over a TCP connection, the DCSP value selected should be the flows over a TCP connection, the DCSP value selected should be the
one associated with the highest priority requested for all one associated with the highest priority requested for all
multiplexed flows. multiplexed flows.
If a packet enters a QoS domain that has no support for the above If a packet enters a QoS domain that has no support for the above
skipping to change at page 8, line 18 skipping to change at page 8, line 18
This document was originally an individual submission in RTCWeb WG. This document was originally an individual submission in RTCWeb WG.
The RTCWeb working group selected it to be become a WG document. The RTCWeb working group selected it to be become a WG document.
Later the transport ADs requested that this be moved to the TSVWG WG Later the transport ADs requested that this be moved to the TSVWG WG
as that seemed to be a better match. as that seemed to be a better match.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-dart-dscp-rtp]
Black, D. and P. Jones, "Differentiated Services
(DiffServ) and Real-time Communication", draft-ietf-dart-
dscp-rtp-10 (work in progress), November 2014.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-13 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), January 2015. progress), January 2015.
[I-D.ietf-rtcweb-rtp-usage] [I-D.ietf-rtcweb-rtp-usage]
Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time Perkins, C., Westerlund, M., and J. Ott, "Web Real-Time
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.
skipping to change at page 9, line 5 skipping to change at page 8, line 47
[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
(Diffserv) and Real-Time Communication", RFC 7657, DOI
10.17487/RFC7657, November 2015,
<http://www.rfc-editor.org/info/rfc7657>.
12.2. Informative References 12.2. Informative References
[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/
 End of changes. 11 change blocks. 
61 lines changed or deleted 61 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/