BBR Control in QUIC and HTTP/3

BBR congestion control is now available for LiteSpeed QUIC and the upcoming HTTP/3.

The newly released LiteSpeed Web Server 5.4.2, Web ADC 2.6.0, and OpenLiteSpeed 1.6.1 use BBR congestion control for QUIC connections. BBR (which stands for Bottleneck Bandwidth and RTT) is a new congestion control algorithm developed by Google in the last few years. It features several profitable properties.

Resistance to Loss

The main idea behind BBR is that packet loss may not mean that there is congestion in the network. For example, a packet may be lost due to transient radio interference. Cubic and other congestion-based algorithm do not distinguish between such spurious losses and real congestion, reducing their send rate in both cases. BBR, on the other hand, is not so easily spooked.

As a result, BBR can deliver sustained throughput performance even in the face of suboptimal network conditions.

Minimal Latency

Bufferbloat has been the bane of good UX for years. Since the problem was identified and alarm sounded, there have been changes to network infrastructure equipment to avoid buffering too much data. Nevertheless, the fact remains: Cubic will try to fill the bottleneck buffer on the network path, increasing connection latency. A study of 4G LTE networks reveals that to mask packet loss, buffers are used extensively, thereby inflating RTT.

BBR keeps track of the bottleneck bandwidth and periodically tests for minimum round-trip time. These estimates are used by the sender to avoid filling the bottleneck buffer. With BBR, an interactive web application is more likely to be responsive.

Drawbacks

Despite its terrific advantages, BBR is not without problems. It performs poorly when there are shallow buffers on the path and it may not be fair to other flows, claiming most of available bandwidth. These issues will be addressed in BBRv2, which is being actively developed at Google.

Test Results

Throughput Under Loss

To compare BBR to Cubic, I set up a pre-release build of LSWS 5.4.2 and conducted a few experiments downloading a static file from the web server using the LiteSpeed QUIC client. The bottleneck was set up on the client side using netem and ifb.

Table 1: Time to transfer 10 MB file, in seconds

It is evident that Cubic is very sensitive to packet loss, while BBR is not.

Latency

To test the difference in latency between Cubic and BBR, we set up a simple website with three resources: an HTML page with links to two files: one large and one tiny. The bottleneck was set up to have 20 MBit/sec bandwidth and 25 ms delay with a large buffer. The user clicks on the large file and it begins downloading. The user then clicks on the small file. When Cubic is used, it takes one to two seconds to download the small file:

Figure 1: Downloading small file when server uses Cubic

This is because Cubic tries to fill the intermediate buffer. BBR, on the other hand, keeps the bottleneck buffer filled “just right” so that downloading a small file take on the order of RTT:

Figure 2: Downloading small file when server user BBR

BBR Congestion Control in QUIC and HTTP/3

BBR is a novel congestion control technology. It has two advantages over the widely-deployed Cubic congestion control: insensitivity to random loss and low latency. With LiteSpeed, you can take advantage of this technology today to power your server’s Google QUIC and HTTP/3 connections.

As Google evolves BBR, we will continue to support the most recent stable version.