[WebRTC] Congestion Control GCC Class Diagram

Please add a picture description

GoogCcNetworkController : the central class of the entire congestion_controller module, which is the external interface

AcknowledgedBitrateEstimatorInterface

AcknowledgedBitrateEstimator : Estimate the current throughput.

BitrateEstimator : Calculate the current sending throughput using sliding window + Kalman filter.

RobustThroughputEstimator : A more robust ACK rate estimate (calculate the current throughput through the number of ack packets for a period of time).

Alr

ALR, that is, Application Limit Region, means that the application itself has some restrictions (not caused by the network bandwidth), which will cause the sending bit rate to be greatly reduced compared with usual.

A sudden low sending bit rate will cause some deviation in our estimated bandwidth, so we need to detect and distinguish such a scenario.

Generally speaking, the causes of ALR are: relatively high system load, lower acquisition/encoding frame rate, and so on.

The detection of ALR is also relatively simple. According to the average code rate sent over a period of time, it can be judged whether the current code rate deviates from the normal code rate.

This detection uses the IntervalBudget in pacing to detect, which is a leaky bucket algorithm. Each time the data is sent, the budget is consumed, and the budget is increased as time goes by. Finally, by checking the remaining ratio of the budget, it is judged whether the amount of data sent is sufficient.

AlrDetector: Detect whether the actual bit rate is much lower than the target bit rate

Loss-based bandwidth estimation

For historical reasons, the packet loss based estimation is at the sending end and the delay (REMB) based estimation is at the receiving end.

So the code based on packet loss is in SendSideBandwidthEstimation, and the estimation based on delay (REMB) is in Remote.

With the new delay-based (Transport-CC) estimate, it can only be placed in DelayBasedBwe.

SendSideBandwidthEstimation : Sender side bandwidth estimation.

  • Combining the evaluation results of LossBasedBandwidthEstimation and DelayBasedBwe, as well as the bandwidth evaluation value reported by the receiving end through the RTCP REMB/TMMBR message, the current_target_ is obtained by comparing these values, and current_target_ is the bandwidth evaluation value of the receiving end. This value will eventually affect the pacing module and the encoding module.
  • The bandwidth evaluation of webrtc in version 90 (check the version number through README.chromium in the src directory) is implemented by the sender. I heard that the delay_based algorithm of the previous version is implemented by the receiver, and then the bandwidth evaluation value is obtained. Feedback to the sender through the RTCP REMB message.

LossBasedBandwitdhEstimation : Bandwidth estimation based on packet loss

Latency-Based Bandwidth Estimation

DelayBasedBwe : Estimated code rate based on delay

InterArrival: Calculate the sending time difference, receiving time difference, byte difference, etc. of the packet group. Congestion results are not available.

SendTimeGroup : Definition of packet group, WebRTC divides and calculates delay by packet group.

TrendlineEstimator : Takes the output of InterArrival as input, calculates the delay trend using the least squares method, and evaluates the network status.

AimdRateControl : Adjust the bit rate in aimd way based on the network status predicted by TrendLine.

other

ProbeBitrateEstimator: Calculate the detection bit rate according to the feedback, and the PacingController will divide the packet according to the cluster. The transport-CC message can get the cluster to which the packet belongs and the sending and receiving information, and judge whether the upper limit of the link is reached by the ratio of the sent and received data size To perform bandwidth detection (probe algorithm)

ProbeController: Probe controller, judge whether to detect next time through the target code rate, and detect the code rate

CongestionWindowPushbackController : Set a time window based on the current rtt, and set the amount of data in the current time window based on the current code rate. By judging the usage of the current window, if the usage is too large, reduce the target code rate used in encoding , to speed up window fading and reduce latency

NetworkStateEstimator , NetworkStatePredictor : These two belong to the class to be developed, but they are only in the code, but they have not been developed yet, so they are useless

Guess you like

Origin blog.csdn.net/qq_41214278/article/details/128161761