Why WebRTC Removed the BBR Congestion Control Algorithm

WebRTC removed the BBR congestion control algorithm in Bug: webrtc:9883. The stated reason is straightforward:

This was introduced on trial but turned out to perform badly for WebRTC
purposes and never used in production.

In other words: it was introduced as a trial feature but performed poorly for WebRTC use cases and was never used in production.

There are also some articles in China discussing BBR's removal from WebRTC, mostly based on these two posts:

They mention:

However, BBR was deprecated due to some "performance issues" and removed from the codebase.

However, some Chinese readers translated performance as "性能" (performance/efficiency), which can be misleading—it sounds like BBR had a resource consumption problem. A more accurate translation would be "表现" (behavior/performance in the sense of how well it works).

BBR's Behavior

So what behavior led WebRTC to remove BBR?

The author of post 1 provided measured data:

webrtc-bbr-1

First chart: the red line shows bandwidth estimates from BBR. The blue line shows the corresponding recommended encoding bitrate (from the adaptive encoding module). The green histogram-like line represents actual send bandwidth. The horizontal dashed line is the true bandwidth value.

The second and third charts show round-trip time (RTT) and pacing queue size, respectively. Together they determine latency between the server and client.

According to the experimental results (above), when BBR overestimates bandwidth, the adaptive encoding module increases the encoder's target bitrate. This is very different from bulk transfer, where overestimation does not increase the total amount of data to send. The increased bitrate causes congestion. When in-flight data is limited by CWND, remaining data backs up in the pacing queue, causing noticeable latency between server and client.

In other words, when BBR estimates a bandwidth value higher than the actual bandwidth, the encoder bitrate exceeds what the network can carry. Packets queue up in the pacing buffer, and RTT increases accordingly.

If the number of queued packets exceeds the pacing queue threshold, a burst of packets is sent onto the network, worsening congestion and causing severe packet loss.

The Chinese article why bbr is removed from webrtc discusses this phenomenon.

A Google developer explained:

One issue is slight bandwidth overestimation, as you observed. Applying a max filter makes even small overestimates quite persistent. As your chart shows, this problem is most severe during the STARTUP phase, because bandwidth estimation is limited by send rate, and send rate during STARTUP is significantly higher than the bandwidth estimate. We may have an undiscovered bug in the bandwidth estimator, but there is also a known overestimation possibility when ACK aggregation is present.

In our tests, flows were often application-limited, which might prevent incorrect bandwidth estimates from expiring quickly from STARTUP, but given the persistent queue in your test, this does not seem to be a factor.

The last issue we observed is that when BBR is used bidirectionally for WebRTC streams, especially when it takes a long time to exit the STARTUP phase, the minimum round-trip time (min_rtt) estimate becomes inflated.

See: Post 1

Another reason for WebRTC removing BBR is mentioned in post 2:

I don't think there are any plans for using BBR. One of the problems with BBR for real-time communications is that it alternates between probing the bandwidth and measuring the RTT. To measure the bottleneck bandwidth, we need to build network queues. To accurately measure the RTT, all network queues must be completely drained which requires sending almost nothing for at least one RTT. These variations in target send rate do not play nice with encoders and jitter buffers.

In other words: I don't think there are any plans to use BBR. One problem with BBR for real-time communications is that it alternates between probing bandwidth and measuring RTT. To measure bottleneck bandwidth, network queues must be built. To accurately measure RTT, all network queues must be fully drained, requiring almost no sending for at least one RTT. These variations in target send rate do not work well with encoders and jitter buffers.

That is, BBR does not integrate well with WebRTC's encoder and Jitter Buffer.

Thoughts

Based on existing materials (@PixPark has not run their own tests), BBR is more accurate than GCC for bandwidth estimation and converges faster—those are BBR's strengths. Since WebRTC introduced BBR, there has been extensive discussion online, and many RTC developers in China had high hopes for it.

Since BBR was an experimental feature and did not work well with WebRTC in practice, does that mean BBR cannot be used in RTC at all?

Personally, for scenarios that require high bandwidth accuracy—such as server-side SVC layer forwarding and packet dropping—you can leverage BBR's accurate bandwidth estimates to more precisely control downstream packet forwarding.

Another option is to tune BBR parameters according to your requirements—for example, setting the encoder bitrate to 80% of the probed bandwidth (which may be a bad idea).

One remaining question is how BBR adapts in scenarios with large bandwidth fluctuations, such as walking through a hallway. That needs further exploration.

This article does not go deep into BBR and leaves some open questions—the main goal is to help readers understand why WebRTC removed BBR. If you know this area well, please share your views and insights.