draft-ietf-tsvwg-rtcweb-qos-11.txt   draft-ietf-tsvwg-rtcweb-qos-12.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: July 30, 2016 Cisco Systems
D. Druta D. Druta
AT&T AT&T
January 27, 2016 January 27, 2016
DSCP and other packet markings for WebRTC QoS DSCP and other packet markings for WebRTC QoS
draft-ietf-tsvwg-rtcweb-qos-11 draft-ietf-tsvwg-rtcweb-qos-12
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 4, line 16 skipping to change at page 4, line 16
first few hops. first few hops.
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 transmit 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
the packets associated with an independent media entity, so an RTP the packets associated with an independent media entity, so an RTP
stream or distinct data channel is not always equivalent to a stream or distinct data channel is not always equivalent to a
transport-layer flow defined by a 5-tuple (source address, transport-layer flow defined by a 5-tuple (source address,
skipping to change at page 6, line 26 skipping to change at page 6, line 26
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 SCTP scheduler for data channel traffic per
[I-D.ietf-rtcweb-data-channel]. Further, the scheduler functionality [I-D.ietf-rtcweb-data-channel].
is viewed as more important than the DSCP marking.
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
 End of changes. 3 change blocks. 
4 lines changed or deleted 3 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/