New changes in bandwidth assessment of WEBRTC

The bandwidth assessment (BWE) is perhaps the most critical module in the WEBRTC video engine, which determines the amount of video data that can be generated when network congestion is not raised in video traffic.

Early bandwidth assessment algorithms are relatively primitive, mostly based on packet loss estimation, the basic strategy is to gradually increase the amount of data sent, until the loss of packets detected. In order for the sender to learn about packet drops on the network, a standard RTCP RR can be used to send periodic reports.

The modern bandwidth evaluation algorithm can detect network congestion before the network link drops packets, and it can predict future congestion by detecting the inter of packets received. It is based on the link of the router has a certain cache, before the packet starts to be discarded, the data in the cache to accumulate events, so the delay compared to packet loss, the response to congestion more sensitive. Now several typical algorithms are: Google congest Control (https://tools.ietf.org/html/draft-ietf-rmcat-gcc-02), Ericsson's Sceam (https:// Github.com/ericssonresearch/scream) and MIT's Sprout (http://aim.nms.lcs.mit.edu/papers/nsdi13-sprout.pdf). Mozilla's article tells the history of the evolution of congestion control algorithms (https://blog.mozilla.org/webrtc/what-is-rmcat-congestion-control/)

WEBRTC at the beginning of the use of the receiving end of the bandwidth evaluation to determine the bit rate of the sender, as above, the receiver based on the amount of data received and changes in data delay, the current network bandwidth assessment, using the REMB to report the bandwidth of the evaluation to the sender. Another detail is that, in addition to using REMB, the sender of WEBRTC will determine the current video bitrate based on the packet loss situation, and the pseudo-code is as follows:

Sender pseudocode (send_side_bandwidth_estimation.cc):
  onfeedbackfromreceiver (lossrate):
    if (Lossrate < 2%) Video_bitrate *= 1.08
    if (lossrate > 10%) video_bitrate *= (1-0.5*lossrate)
    if (video_bitrate > Bwe) v Ideo_bitrate = Bwe;

The better rate control method is, the detection of congestion is, the rapid reduction of the code rate, when the network congestion is not, slowly increase the bitrate.

The most recent WEBRTC has moved the bandwidth assessment to the sending side. However, there is no significant change in the evaluation mechanism, and the receiving end needs to report the delay information to the sending side, which introduces 2 new protocols.
1. Transport wide sequence number header extension.
A=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
2. Transport Feedback
a=rtcp-fb:100 TRANSPORT-CC

See more: Https://www.ietf.org/archive/id/draft-holmer-rmcat-transport-wide-cc-extensions-01.txt the Original Post

Http://www.rtcbits.com/2017/01/bandwidth-estimation-in-webrtc-and-new.html