"Reprint" WEBRTC congestion control based on GCC (upper)-Algorithm analysis

The greatest feature of real-time streaming media applications is real-time, while latency is the biggest enemy of real-time sex. The processing speed of media data is the important reason of delay, and the network congestion is the main cause of delay from the point of transmission. Network congestion can cause packet loss, and may result in longer data transfer times and increased latency.

Congestion control is one of the important methods in real-time streaming media application quality assurance (QoS), which plays an important role in alleviating network congestion, reducing network delay, smoothing data transmission and other quality assurance. WEBRTC control the transmission end data transmission code rate to control the network congestion, the use of Google's congestion control algorithm (Google congestion control, short gcc[1]) to control the transmission of the bit rate.

This paper is about the upper half of the WEBRTC congestion control algorithm, which focuses on the theoretical analysis of the algorithm, and tries to have a comprehensive and intuitive understanding of the QoS of WEBRTC. In the lower part, you will delve deeper into the WEBRTC source code and carefully analyze the implementation details of GCC.

Overview of 1 GCC algorithms

Google's RFC for GCC is in document [1], which is currently in the draft State and has not yet become the official RFC for the IETF. In addition, Google has published a series of papers [2][3][4] to discuss the implementation details of the algorithm, as well as its applications in Google Hangouts, WEBRTC and other products. Based on these documents, the paper studies the GCC algorithm theoretically.

The GCC algorithm is divided into two parts: the bit rate control based on packet loss rate and the rate control based on delay at the receiving end. 1 is shown

Figure 1 The overall structure of the GCC algorithm

The rate control based on packet loss rate is run on the sending side and relies on the RTCP RR message to work. The WEBRTC receives a RTCP RR message from the receiving end at the sender and dynamically adjusts the transmit port bitrate as according to the packet loss rate information carried in the report block. Based on the delay rate control operation on the receiving end, WEBRTC based on the time delay of the packet arrival, through the arrival time filter, estimated the network delay m (t), and then through the overload detector to determine the current network congestion, and finally in the code rate controller according to the rules to calculate the remote estimate maximum rate ar. After the AR is obtained, the sending end is returned via RTCP REMB message. The transmit side synthesizes as, AR and pre-configured upper and lower limits, calculates the final target rate A, the code rate will effect to encoder, RTP and Pacedsender modules, control the sender side of the bitrate.

2 bit rate control based on packet loss rate at the sending end

The basic idea of the GCC algorithm is to control the transmission code rate based on packet loss rate at the transmitting end, which is: the packet loss rate reflects the network congestion condition. If the packet loss rate is very small or 0, the network is in good condition, in the case of no more than the default maximum bitrate, you can increase the transmission of the bit rate; Conversely, if the packet loss rate becomes larger, it indicates that the network condition becomes worse, and the sending end bit rate should be reduced at this time. In other cases, the send-side bitrate remains the same.

The packet loss rate used by GCC is calculated based on the receive-side RTP receive statistics, which are returned to the sender via the RTCP RR message. RTCP RR Message Statistics receive end RTP receive information, such as packet loss,jitter,dlsr and so on, 2 shows:

Figure 2 RTCP RR message structure [5]

Figure 3 GCC calculation formula based on packet loss rate [4]

The final bitrate acts on the encoder, RTP, and Pacedsender modules to adjust the bitrate and smooth send-side transmit rate within the encoder.

3 receiver-side bitrate control based on latency

The GCC algorithm sends the code rate AR at the receiving end based on packet arrival delay estimation, and then feeds back to the sending end via RTCP REMB message, and sends the AR as the upper limit of the final target bitrate. The basic idea is that the arrival time delay of RTP packet (i) reflects the network congestion condition. When the delay is very small, it indicates that the network congestion is not serious, and the target rate can be increased appropriately. When the delay becomes larger, the network congestion becomes serious, and the target rate is reduced; the target bitrate remains constant when the delay is maintained at a low level.

Delay-based congestion control consists of three main modules: Arrival time filter, overload checker and rate controller, in addition to the overload threshold Adaptive module and the REMB message generation module, 1. The following is a discussion of the work process separately.

3.1 Arrival Time Filter (Arrival-time filter)

The module is used to calculate the network queuing delay m (i) for adjacent two packet groups. A packet group defines a collection of packets that are sent continuously over a period of time. A series of packets are sent continuously in a short time, this time is called burst time, the proposed burst time is 5ms. It is not recommended to measure the packet interval in the burst time, but to measure it as a group. The inter-group delay D (i) is calculated by sending time and arrival time of the adjacent two packet groups. Inter-group delay and calculation Equation 4 shows:

T (i) is the sending time of the first packet in the I packet Group, and T (i) is the arrival time of the last packet in the first packet group. The inter-frame delay is calculated using the following formula:

d(i) = t(i) – t(i-1) – (T(i) – T(i-1))    (3.1.1)

The formula 1.3.1 is the observation equation of D (i). On the other hand, D (i) can also be obtained by the following state equations:

d(i) = dL(i)/C(i) + w(i)                  (3.1.2)d(i) = dL(i)/C(i) + m(i) + v(i)           (3.1.3)

where DL (i) indicates the difference in length between two adjacent frames, C (i) indicates network channel capacity, M (i) indicates network queuing delay, V (i) represents 0 mean noise. M (i) is the network queuing delay we are trying to obtain. This value can be obtained by using the Kalman filter. Please refer to the literature [1][4][6] for specific calculation procedures.

3.2 Overload detector (Over-use Detector)

In this module, the Network queueing delay (i) calculated by the time-of-arrival filter is input, and the current threshold gamma_1 is combined to determine whether the current network is overloaded. The judgment algorithm is shown in 5 [2].

Figure 5 Overload detector pseudo-code

The algorithm evaluates current network congestion based on current network queueing delay m (i) and current threshold gamma_1 [2]: when m (i) > gamma_1, The algorithm calculates the duration of the current state T (ou) = t (OU) + Delta (t) if T (OU) Greater than the set threshold of gamma_2 (which is set to 10ms in the actual calculation) and M (i) > m (i-1), the network overload signal overuse is issued and the T (OU) is reset. If M (i) is less than M (i-1), it is not necessary to emit an overload signal even above the threshold gamma_1. When M (i) <-gamma_1, the algorithm considers that the current network is idle and emits a network low-load signal underuse. When the –gamma_1 <= m (i) <= gamma_1 is, the algorithm considers that the current network usage is moderate, signaling hold signals. The algorithm can be seen in Figure 6 as the process of calculating the timeline.Figure 6 Overload detection process on the time axis

It is important to note that the threshold value of gamma_1 has a great influence on the algorithm, and gamma_1 is self-adaptive. If it is a static value, it will bring a series of problems, see article [4]. So gamma_1 need dynamic adjustment to achieve good performance. This is the Adaptive threshould module in Figure 1. The formula for dynamic update of Threshold Gamma_1 is as follows:

gamma_1(i) = gamma_1(i-1) + (t(i)-t(i-1)) * K(i) * (|m(i)|-gamma_1(i-1))    (3.2.4)

When the |m (i) |>gamma_1 (i-1) is increased gamma_1 (i), the reverse is reduced by gamma_1 (i), and when |m (i) |–gamma_1 (i) >15, it is recommended that gamma_1 (i) not be updated. K (i) for the update factor, when |m (i) |<gamma_1 (i-1) k (i) = K_d, otherwise k (i) = K_u. It is also suggested that gamma_1 (i) be controlled in the [6,600] interval. Too small a value can cause the probe to be too sensitive. The recommended increase factor is greater than the reduction factor K_u > K_d. The recommended values given in the literature [1] are as follows:

gamma_1(0) = 12.5 msgamma_2  = 10 msK_u = 0.01K_d = 0.00018

3.3 Rate Controllers (Remote Controller)

The module based on the current network state of the overload detector is input, first of all, according to the finite state machine shown in Figure 7 to determine the current rate of change trend, and then calculate the target rate AR according to the formula shown in Figure 8.

Figure 7 Target rate AR change trend finite state machine

When the current network is overloaded, the target bitrate is in decrease state, and the target bitrate is in hold when the network is low, and when the network is in decrease state, it is migrated to the hold state when it is in the hold/increase state. The target rate is calculated according to the formula shown in Figure 8 when the rate of change trend is determined.

Fig. 8 AR calculation formula of target code rate

When the rate change trend is increase, the current code rate is the last bitrate multiplier of 1.05, when the rate change trend is decrease, the current code rate for the past 500ms in the maximum receive code rate by 0.85. When the rate change trend is hold, the current code rate remains the same. After the target rate AR is computed, the next step is to send the AR package back to the sending side in the REMB message. In the REMB message, AR is represented as AR = m * 2^exp, where M is encapsulated in the BR mantissa domain, accounting for 18 bits; exp is encapsulated in the BR exp domain, accounting for 6 bits. The REMB message is a RTCP message [7] of payload 206, as shown in format 9.Figure 9 REMB message Format

REMB messages are sent once per second and are sent immediately when AR (i) < 0.97 * AR (i-1).

3.4 Determination of target bitrate at the sending end

The determination of the final target bitrate of the transmitting end combines the bitrate as and the rate AR based on the delay calculation based on the packet loss rate. In addition, the upper and lower values of the target bitrate are also configured in the actual implementation. In combination with the above factors, the final target bitrate is determined as follows:

    target_bitrate = max( min( min(As, Ar), Amax), Amin)        (3.4.1)

After the target bitrate is determined, it is set to the Encoder module and the Pacedsender module, respectively.

4 Summary

Based on extensive investigation of the relevant RFCs and papers of the WEBRTC GCC algorithm, this paper comprehensively and thoroughly studied the theoretical analysis of the GCC algorithm, which is an opportunity to make an overall and intuitive understanding of the QoS of WEBRTC. Lay the groundwork for future in-depth webrtc of the implementation details of GCC within the source code.

Weizhenwei Link: http://www.jianshu.com/p/0f7ee0e0b3be Source: Jane Book copyright belongs to the author. Commercial reprint please contact the author for authorization, non-commercial reprint please specify the source.

"Reprint" WEBRTC congestion control based on GCC (upper)-Algorithm analysis