Network congestion is based on the IP datagram exchange network in a common network transmission problem, it has serious impact on the quality of the network, network congestion is reduce the network throughput and network packet loss and so on, one of the main reasons for these problems make the upper application unable to use the network bandwidth effectively obtain the high quality network transmission. Especially in the field of communication, network congestion caused by packet loss, delay, jitter and other problems, seriously affect the quality of communication, if not a good solution to these problems, a communication product can not be used in the real environment. In this respect, WebRTC network congestion control algorithm provides us with a reference to the implementation, this article will try to detail WebRTC congestion control algorithm -GCC implementation.

Related Reading recommendations

WebRTC Gateway Server 1: How to Select a Server Port Solution

WebRTC Gateway Server 2: How to Choose a PeerConnection Solution?

Introduction of WebRTC

WebRTC is a web-based real-time communication solution that enables point-to-point real-time communication in the browser without external plug-ins. WebRTC has been standardized by the W3C and IETF. The first browser to support WebRTC is Chrome, and other major browsers are also supporting it. The integrated WebRTC code in Chrome is all open source, and Chrome provides a LibWebRTC code base, which makes this RTC architecture can be ported to other apps to provide real-time communication functions.



GCCDescription of algorithm

This paper mainly introduces the congestion control algorithm of WebRTC. The transport layer of WebRTC is based on UDP protocol, on which standard RTP/RTCP protocol is used to encapsulate media streams. RTP/RTCP itself provides many mechanisms to ensure the reliability of transmission, such as RR/SR, NACK, PLI, FIR, FEC, REMB, etc. WebRTC also extends the RTP/RTCP protocol to provide some additional safeguards. Such as transport-CCfeedback, RTP Transport-wide-CC Extension, RTP ABS-SendTime Extension, etc., some of which will be introduced in detail later.

GCC algorithm is mainly divided into two parts, one is congestion control based on packet loss, the other is congestion control based on delay. In the early days of the implementation of the two congestion control algorithm is implemented in the sender and the receiver, the receiver calculated to estimate the bandwidth congestion control algorithm, through the remb RTCP feedback to the sender, the sender comprehensive the results of the two control algorithm to get a final delivery rate, and bit rate to send packets. Here’s how it works:



As can be seen from the figure, loss-based Controller is responsible for congestion control Based on packet Loss at the sender end. Its input is relatively simple. It only needs to estimate bandwidth according to the packet Loss rate feedback from the receiver end. The right side of the figure is more complicated. It does latency based bandwidth estimation, which is mainly introduced later in this article. In the recent implementation of WebRTC, GCC has moved its two congestion control algorithms to the sender, but the two algorithms themselves are not changed, but the sender needs to calculate the delay, so some additional feedback information is needed, so WebRTC extends the RTCP protocol. Chief among them is the addition of transport-CC Feedback, which carries the arrival time of each media packet received by the receiver.

Congestion control based on delay is complicated. WebRTC uses delay gradient to judge the degree of network congestion. The concept of delay ladder will be introduced in detail later.

Its algorithm is divided into several parts:

  • Time of arrival filter
  • Overload detector
  • Rate controller

After obtaining the transmit bit rate of the two congestion control algorithms, the final transmit bit rate of GCC takes the minimum value of the two algorithms. The congestion control algorithm GCC of WebRTC is introduced in detail.

(1) Bandwidth estimation based on packet loss

The congestion control based on packet loss is relatively simple. The basic idea is to judge the degree of network congestion according to the number of packet loss. The more packets are lost, the more congested the network will be. If there is no packet loss, this indicates that the network is in good condition, so you can increase the transmitting bit rate and probe upward to see if there is more bandwidth available. There are two points to realize the algorithm: one is to get the packet loss rate of the receiving end, the other is to determine the threshold of decreasing bit rate and increasing bit rate.

WebRTC obtains the packet loss rate of the receiving end through the RTCP Receive Report feedback packet. The Receive Report package has a Lost Fraction field that contains the packet loss rate at the receiving end, as shown in the figure below.



In addition, WebRTC estimates the transmitting bit rate by the following formula, where As(TK) is the estimated value of bandwidth at TK moment, and FL (TK) is the packet loss rate at TK moment:



In simple terms, when the packet loss rate is greater than 10%, the network is considered congested. In this case, the bandwidth decreases according to the packet loss rate. The higher the packet loss rate is, the more the bandwidth decreases. When the packet loss rate is less than 2%, the network is considered to be in good condition. In this case, increase the bandwidth by 5% to detect whether more bandwidth is available. If the packet loss rate is between 2% and 10%, the current bit rate will remain unchanged. In this way, some inherent packet loss on the network will not be wrongly identified as network congestion and thus reduce the bit rate. The packet loss on this part needs to be recovered by other means, such as NACK or FEC.

(2) Bandwidth estimation based on delay gradient

WebRTC implements two versions of bandwidth estimation based on delay gradient:

  • The earliest one is implemented at the receiving end, where the evaluated bandwidth results are fed back to the sender through RTCP REMB messages. In this implementation, to accurately calculate the delay gradient, WebRTC added an RTP extension header, ABS-send-time, which represents the exact sending time of each RTP packet, so as to avoid the error caused by the sending end delay in the estimation of network propagation delay. This pattern is also described in the RFC and Google’s paper.
  • In the recent implementation of WebRTC, all bandwidth estimation is placed in the sender, that is to say, the sender does not only bandwidth estimation based on packet loss, but also bandwidth estimation based on delay gradient. In order to perform bandwidth estimation based on delay gradient at the receiving end, WebRTC extends RTP/RTCP protocol. First, it adds the RTP extension header and a session-level sequence number, so as to do statistics of feedback information based on one session. Not just an audio stream or video stream; Second, an RTCP feedback message transport-CC-feedback is added, which is responsible for the arrival time of all media packets received by the receiving end. The receiver can estimate the bandwidth by calculating the delay gradient based on the reception delay and transmission interval between packets.

How to infer the current network condition according to the delay gradient will be elaborated in detail in the following aspects. Generally speaking, it can be divided into the following steps:

  • Time of arrival filter
  • Overload detector
  • Rate controller

The process is that the time-of-arrival filter calculates the delay change according to the arrival delay and transmission interval of the packet. Here, kalman filter is used to smooth the delay change to eliminate the error caused by network noise. The delay change will serve as the input of the overload detector, which will judge the current network status and return overuse/underuse/normal for three network states. The detection is based on comparing the delay change with a threshold, which is critical and dynamically adjusted. Finally, the rate controller calculates the bandwidth estimate according to a bandwidth estimation formula based on the changes in the network state.

(3) Arrival time filter

It has been mentioned many times before that WebRTC uses delay gradient to judge network congestion. What is the delay gradient and why it can be used as the basis for judging network congestion? We will introduce it in detail here.

1. Calculation of delay gradient



As shown in the figure above, the arrival time interval of two data packets is subtracted from their sending time interval to obtain a delay change, which is called one Way delay gradient, and the formula can be written as:



Then why can delay gradient be used to judge network congestion, as shown in the following two figures:





The scenario in the figure on the left is network transmission under ideal conditions without any congestion. According to the formula (2) we mentioned above, in this scenario, the calculated delay gradient should be 0. And the picture of the scene on the right is send congestion situation, when the package arrived in t2 time, the paper in the network experienced a queuing caused by congestion, which led to his arrival time than the original, now calculate the latency of gradient for a larger value, through the value, we can judge the current network congestion status.

In the specific implementation of WebRTC, there are some details to ensure the accuracy of delay gradient calculation, which are summarized as follows:

  • Since the measurement accuracy of delay gradient is very small, kalman filter is used to smooth the measurement result of delay gradient in order to avoid the error caused by network noise.
  • In the implementation of WebRTC, instead of simply measuring the delay gradient between individual packets, packets are grouped according to the sending time interval and arrival time interval to calculate the overall delay gradient between groups. The grouping rules are:


2) Packets whose arrival time interval is less than 5ms are classified as a group, because in wifi network, the forwarding mode of some wifi devices is that they have the opportunity to forward packets in a fixed time slice, and the interval of this time slice may be as long as 100ms. As a result, packets of 100ms are piled up and burst is formed when they are sent. All packets within the busRT are treated as a group.

  • In order to calculate the delay gradient, in addition to receiving state of each media packet, the sender also needs to record the sending state of each media packet and its sending time value. In this case, the ABS-send-time extension is no longer needed.

2. Transport – cc – feedback message

  • This message is an extension of RTCP and is specifically used to feedback packet acceptance in GCC. Two things to note here:
  • How to determine the sending rate of the message? According to the description in RFC[2], it can be sent once for each frame received, and it can also be sent once within one RTT. In the actual implementation of WebRTC, it is estimated that the sending rate is about 5% of a sending bandwidth.
  • If the packet gets lost, RFC [2] and WebRTC implementations are ignored, here comes the question is, ignore the package to calculate gradient delay impact is not big, just have bigger span is equivalent to the group of data packets, the lost package will not much affect on the calculation, but another problem is that the sender need to accept the accept rate calculation, When feedback is lost, it will be considered that the corresponding data packets are lost, which will affect the calculation of the receiving rate. This value will be used in the subsequent calculation of bandwidth estimation, resulting in certain errors.

The message format is as follows:



As shown in the figure above, the fields before the red box are the general fields of RTCP packets, and the fields in the red box are the specific contents of transport-CC, where the first four fields respectively represent:

  • Base sequence Number: indicates the start of the receiving information of the media packet carried by the current packet
  • Packet status Count: Indicates that the current packet carries the received information of several media packets
  • Reference Time: a reference time based on which the arrival time of each media packet in the packet is calculated
  • Fb pkt. count: number of transport-cc packets

After that, there are two types of information: multiple Packet Chunk fields and multiple RecV Delta fields. The specific meanings of Pcaket chunk are as follows:

As shown in the following two figures, there are two encoding modes for the structure representing the arrival state of the media packet, where T stands for chunk type. 0 indicates RunLength Chunk and 1 indicates Status Vector Chunk.

1) the Run LengthChunk



This representation is used when we receive multiple packets in a row, and they all have the same arrival state, we can use this encoding. Where S represents the arrival state, and Run Length represents how many consecutive packets belong to this arrival state.

There are three arrival states:

00 Packet not received

01 Packet received, small delta

10 Packet received, large ornegative delta

2) Status Vector Chunk



This representation is used for each packet that requires its own state representation, of course, the three states mentioned above. When S = 0, each bit in the symbolList represents the arrival status of a packet, and when S = 1, each two bits represent the status of a packet.

S = 0

0 Packet not received

1 Packet received , small detal

S = 1

With the Run Length of the Chunk

Finally, for each state for the Packet received Packet delay, in turn, fill in the | | delta recv fields, reach the state of 1, recv delta takes up one byte, reach the state of 2, The recv delta takes up two bytes, which shows that the purpose of this encoding is to minimize the size of the packet, since each media packet needs to feedback its acceptance status.

(4) Overload detector

After the delay gradient of each packet is calculated by the arrival time filter, it is necessary to judge the current network congestion state. By comparing with a certain threshold value, the network congestion is considered when the value is higher than a certain threshold value, and the network is considered good when the value is lower than a certain threshold value. Therefore, how to determine the threshold value is very important. This is the main work of the overload detector, which mainly consists of two parts: one is to determine the size of the threshold, and the other is to estimate the current network state based on the judgment of the delay gradient and threshold. There are three network states: overuse underuse normal. We first look at the judgment of network state.

1. Determine the network status

The judging basis is as follows:



Among themRepresents the calculated delay ladder,Represents a judgment threshold, which is adaptive, and how it is dynamically adjusted will be introduced later. Here we will first look at how to judge the current network status according to these two values.

As can be seen from the figure above, the judgment method here is:



Calculation is based on this, the network congestion occurs, the packet will be queued in the intermediate network equipment forwarding, which can cause delays in the growth of the gradient, when the network traffic down, network equipment, rapid consumption (forward) the sending packets in the queue, and subsequent packet queue time shorter, then delay gradient decreases or negative.

What needs to be explained here is:

  • In the actual implementation of WebRTC, the m(ti) value used does not directly use the calculated value of the arrival of each packet group, but rather magnfies the value by 60 times, although the arrival of each packet group (the grouping mentioned above) triggers the detection process. The reason for this may be that m(ti), which is usually very small and almost zero on an ideal network, can be amplified so that the algorithm does not fluctuate too much because it is too sensitive.
  • When determining whether to overuse, the current network state will not be changed once the threshold is exceeded, but the current network state will be judged as overuse only when the delay gradient exceeds the threshold for at least 100ms.

2. Adaptive threshold

The threshold mentioned in the previous sectionValue, it is the basis to judge the current network condition, so how to determine its value is very important. Although the delay gradient of the network is 0 under ideal conditions, in the actual network, the delay gradient of different forwarding paths still fluctuates, and the magnitude of the fluctuation is also different, which leads to the fixed settingToo large may not detect congestion, too small and too sensitive, resulting in a large change in speed. At the same time, another problem is that experiments show that a fixed value will lead to starve itself in the competition with TCP connections (TCP is congestion control based on packet loss), so WebRTC uses an adaptive threshold adjustment algorithm, which is as follows:

(1) Adaptive algorithm



The above formula is the threshold adaptive algorithm proposed by GCC, where:



Each set of packets triggers a probe and a threshold update, which is the time interval since the last threshold update.

Is a rate of change, or growth rate, of course it can also be negative growth, the base value of growth is: the difference between the current delay gradient and the previous threshold —. Its specific values are as follows:



Where: ku = 0.01; Kd = 0.00018

As can be seen from this equation, when the delay gradient decreases, the threshold decreases at a slower rate; As the delay gradient increases, the threshold increases at a slower rate. However, relatively speaking, the rate of threshold decrease is less than the rate of increase.

(5) Rate controller

The rate controller mainly realizes the transition of a state machine and calculates the current available bit rate according to the current state, as shown in the figure below:



The rate controller drives the rate control state machine according to the signal output by the overload detector (overuse underusenormal) to estimate the current network rate. As can be seen from the figure above, when the network is congested, the overuse signal will be received, and the state machine enters the “Decrease” state, and the transmission rate decreases. When the queued data packets are released quickly, the underuse signal is received and the state machine enters the hold state. When the network is stable, the state machine receives the Normal signal and enters the Increase state. The state machine starts to detect whether the transmission rate can be increased.

In Google paper[3], the formula for calculating bandwidth is as follows:




Among them= 1.05,= 0.85. It can be seen from the formula that when Increase is needed, the previous estimated bit rate multiplied by 1.05 is the current bit rate; In case of Decrease, the current estimated receiving bit rate (Rr(Ti)) is multiplied by 0.85 as the current bit rate; The Hold state does not change the bit rate.

Finally, the bit rate estimate based on packet loss is compared with the bit rate estimate based on delay, where the smallest bit rate estimate is used as the final sent bit rate.

This is the main content of the congestion control algorithm in WebRTC, and the algorithm is still evolving, with some improvements added in each version. There are other topics that are not covered here, such as smooth sending to avoid burst traffic; Padding packages and other strategies used to detect bandwidth. It should be said that this mechanism of WebRTC can cover most of the network scenarios, but according to our test, there are some special scenarios, such as jitter or packet loss is relatively high, its bandwidth utilization is not ideal, but the overall effect is very good.

In addition, to get more product dry goods, technical dry goods, remember to pay attention to netease yunxin blog.