Using DSCP for WebRTC packet marking and prioritization

It is a common request from WebRTC developers and customers to know how they can differentiate WebRTC traffic from other type in their networks.  Usually the goal is to be able to prioritize RTC traffic over other types of less important traffic.

By prioritizing the WebRTC traffic in the edge routers it is possible to improve the quality in some network scenarios.  The most common cases where this marking may help are:

  • Congested broadband uplink where the router can discard other type of traffic instead of WebRTC traffic when queues get full.
  • Congested local wireless network
One obvious way to do this is forcing all the traffic to be relayed through a TURN or SFU server and se the priority based on IP addresses.   That's easy and always work, but the problem is that it is very difficult to maintain when your infrastructure changes often (scaling elastically, new datacenters...).

Other way to accomplish this is to use Differentiated Services Code Point (DSCP) marking. With DSCP you can use a specific field (6 bits) in the IP header to mark different classes of traffic.  This field can carry any arbitrary value that you can associate in your routers with different forwarding treatments (priorities).

Even if any value can be used in that DSCP field, there are some commonly used DSCP values, and there are some recommended values to be used for WebRTC endpoints in this IETF draft.

Nowadays this is supported by Chrome and can be enabled with a proprietary constrain passed to the PeerConnection:

new RTCPeerConnection({"iceServers": []}, { optional: [{ googDscp: true }] });


When enabled the DSCP field in the IP packets sent by Chrome has the value 34 (aka Assured Forwarding 41 or AF41) for both audio and video as you can see in the next figure.  While the default value is 0 (Default Forwarding).


This is the full demo page if you want to test it yourself: https://jsfiddle.net/omzyh5dm/5/

Disclaimer: This is not working in WebRTC in case of Android and iOS and at least some versions of Windows but those issues should be fixed at some point based on the comments on the open tickets.

One question is why this "feature" is not enabled by default and all the packets are marked with the recommended DSCP values.   The main reason is because some routers could block packets with specific DSCP values as explained here, so it should be enabled only when you know that it is not going to be blocked in the network where your customers are at least until browsers implement mechanisms to discover those blocked packets and disable it automatically.

Links:
  • Differentiated services : https://en.wikipedia.org/wiki/Differentiated_services
  • DSCP Packet Markings for WebRTC QoS https://tools.ietf.org/html/draft-ietf-tsvwg-rtcweb-qos-18#section-2
  • DSCP Transport considerations: https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17#section-4.2
  • Test Page: https://jsfiddle.net/omzyh5dm/5/

You can follow me in Twitter if you are interested in Real Time Communications.



Comments

Post a Comment

Popular posts from this blog

Bandwidth Estimation in WebRTC (and the new Sender Side BWE)

Image
Bandwidth estimation is probably the most critical component in the video engine of WebRTC. The bandwidth estimation (BWE) module is responsible for deciding how much video* traffic you can send without congesting the network to prevent degradation of the video quality. In the past bandwidth estimation algorithms used to be very rudimentary and based mostly on packet loss. Basically we used to start increasing slowly the video bitrate until we detected packets being lost.  To detect the packet loss you use the standard RTCP feedback mechanisms where the receiver side reports packet loss periodically using RTCP Receiver Report (RR) messages. Modern bandwidth estimation algorithms are more advanced and try to detect congestion before it is bad enough to make routers discard packets. These algorithms predicts congestion analyzing the delay between packets. The idea is that when you start having some congestion, the buffers in the routers will start filling and the delay wil...
Read more

Improving Real Time Communications with Machine Learning

Image
When we talk about the applications of Artificial Intelligence / Machine Learning (AI/ML) for Real Time Communications (RTC) we can group them in two different planes: Service Level : There are many features that can be added to a videoconference service, for example identification of the participants, augmented reality, emotion detection, speech transcription or audio translation .  These features are usually based on image and speech recognition and language processing. Infrastructure Level : There are many ways to apply ML that do not provide new features but improve the quality and/or reliability of the audio/video transmission. Service level applications are fun, but they are more for Product Managers and I like technology more, so in the next sections I will try to describe possible applications of AI/ML for Real Time Communications at Infrastructure Level organizing those ideas in five different categories. Optimizing video quality Some of the ML algorithms use...
Read more

Controlling bandwidth usage in WebRTC (and how googSuspendBelowMinBitrate works)

Image
There are cases when we would like to limit the maximum bitrate being transmitted by WebRTC to avoid wasting resources in the user endpoints or save money reducing the bandwidth usage in our servers.   This is because the maximum bitrate by default in Chrome is around 2Mbps and for many use cases a much lower bitrate provides still pretty good quality.   BTW using a lower bitrate can also help with stability of quality in multiparty scenarios by reducing the amount of competition among different streams. There is no simple API to configure the maximum bitrate in WebRTC (although there is one in ORTC) but there are 3 ways to do this by mangling the SDP. 1. U se the standard  b=AS:BITRATE (Chrome) or b=TIAS:BITRATE  (Firefox) attributes in the SDP for the audio or video channel[1] 2. Use codec specific attributes (this work at least for opus audio codec with maxaveragebitrate property) [2] 3. Use the proprietary x-max-bitrate attribute in the video channel of the...
Read more