Differentiated Services Code Point (DSCP) Packet Markings for WebRTC QoS
Extracted elements (24)
DSCP values are site-specific in principle, but WebRTC browsers need defaults when no site-specific information is available. This document selects a subset of existing DSCP values from RFC 4594 to serve as those defaults, rather than defining new values.
Frequent changes to the DSCP value for an SCTP association are discouraged because each change requires a congestion controller reset, putting the association back into slow start and potentially harming application performance.
The LE DSCP replaced CS1 for 'very low' priority traffic during document development, because LE more accurately conveys 'less than best effort' semantics. However, LE is commonly treated the same as DF in practice, so applications cannot assume differentiated treatment.
When a cell in Table 1 provides multiple DSCP values (e.g., AF41 and AF42), the different values offer different drop precedences to provide additional granularity. For example, more important video frames (I-frames) can be marked with AF42 and less important frames (P/B-frames) with AF43.
Excess EF traffic is intentionally dropped by the network. A packet marked EF may be dropped even though the same packet with a different DSCP value would have been forwarded.
If a packet enters a network that does not support a particular flow-type/application-priority DSCP combination, the edge node will remark based on local policy, and original markings may not be restorable if the packet later enters a network with richer DSCP support.
LE is commonly treated the same as DF by many network implementations; applications and browsers using LE cannot assume it will receive lower-than-best-effort treatment.
The DSCP value set by an endpoint is not trusted by the network and may be remarked at any hop, including to DF (best-effort). Benefits from DSCP marking may only apply at the first few hops.
WebRTC's use of multiple DSCP values may result in packets with certain DSCP values being blocked by a network. RFC 8835 Section 4.2 discusses how WebRTC implementations establish and maintain connectivity when such blocking occurs.
A web browser SHOULD use the DSCP values in Table 1 to mark appropriate media packets for WebRTC traffic, based on flow type and application priority.
All WebRTC data channel packets transmitted over an SCTP association MUST be marked using the same DSCP value, regardless of how many data channels exist or what traffic is carried.
Browsers MUST NOT use the AF3x DSCP values (for non-interactive video) for WebRTC applications, since all WebRTC video is currently assumed to be interactive.
For data channel traffic over an SCTP association, it is RECOMMENDED that the DSCP value selected be the one associated with the highest priority requested for all data channels multiplexed over the association.
If multiple flows are multiplexed over a reliable transport (e.g., TCP), all packets for all multiplexed flows MUST be marked using the same DSCP value.
If the browser wishes to change the DSCP value in use for an SCTP association, it MUST reset the SCTP congestion controller after changing values.
Implementations that previously used CS1 DSCP for 'very low' application priority traffic SHOULD be updated to use the LE DSCP instead.
It is RECOMMENDED that WebRTC applications use non-default DSCP values only in private networks that are configured to use different values.
Non-browser WebRTC implementations MAY use AF3x DSCP values for video that is known not to be interactive, e.g., in a WebRTC video playback application.
Application priority is an input from the WebRTC application to the browser, indicating the relative importance of a flow as High, Medium, Low, or Very Low. It is used alongside flow type to select the DSCP value.
Flow type is an input provided by the WebRTC application indicating whether the flow is audio, interactive video (with or without audio), non-interactive video (with or without audio), or data.
WebRTC flows are classified into two categories for DSCP marking: media flows (RTP streams per RFC 8834) and data flows (data channels per RFC 8831). Each has its own recommended DSCP values based on application priority.
If the server hosting a JavaScript WebRTC application is compromised, many browsers could simultaneously transmit flows with elevated DSCP markings, potentially constituting a network abuse attack. The Diffserv architecture's ingress traffic conditioning is the expected mitigation.
The browser should consider suspicious any application use of a large number of higher-priority flows, since the JavaScript application controls the flow type and application priority inputs that determine DSCP values.
Table 1 defines recommended DSCP values: Audio maps to LE(1)/DF(0)/EF(46)/EF(46) for Very Low/Low/Medium/High; Interactive Video maps to LE(1)/DF(0)/AF42-AF43(36,38)/AF41-AF42(34,36); Non-Interactive Video to LE(1)/DF(0)/AF32-AF33(28,30)/AF31-AF32(26,28); Data to LE(1)/DF(0)/AF11/AF21.