Accelerating Content Delivery with BBR Congestion Control

Every Agiler edge server runs BBR congestion control. There is nothing to enable and no setting on your project. It is a different algorithm deciding how fast bytes leave the edge, and on the paths our traffic actually takes, it decides better than the default does.

Loss is a bad congestion signal

Most servers run CUBIC, which infers congestion from packet loss. Grow the congestion window until something drops, cut it, grow again. The result is the sawtooth every network engineer recognizes: the sending rate climbs, overshoots, collapses, and climbs back. It works on the assumption that a lost packet means a queue somewhere has filled up.

That assumption does not survive contact with the paths visitors arrive on. Wi-Fi loses frames to interference. Cellular links lose them during handover. A long-haul route loses a small fraction for reasons unrelated to load. CUBIC cannot distinguish those from congestive loss, so it backs off regardless, and throughput on a lossy transatlantic path settles far below what the link could carry. The longer the round trip, the worse it gets: recovery after each cut is measured in RTTs, so a distant visitor spends most of the transfer climbing back to a rate they should never have left.

The second failure is bufferbloat. “Grow until loss” means filling every buffer on the path before easing off, and modern buffers are deep. The bytes still arrive, but they arrive after sitting in a standing queue, and queueing delay applies to everything sharing the path — including the small, latency-sensitive requests a page render is blocked on. A single large transfer can add hundreds of milliseconds to every request behind it.

Modeling the path instead

BBR does not treat loss as a congestion signal at all. It builds a model of the path from two measurements: the delivery rate at the bottleneck link, and the minimum round-trip time observed when no queue has formed. Their product is the bandwidth-delay product — the amount of data that keeps the bottleneck fully busy with nothing queued in front of it.

BBR aims to keep roughly that much in flight, and to send at the bottleneck rate rather than faster. It periodically probes upward to discover new capacity, and drains down to re-measure the true minimum RTT, since the estimate is only valid while a queue is absent.

Two consequences follow. Random loss no longer halves the sending rate, so lossy paths keep their throughput. And because the goal is an empty queue at the bottleneck rather than a full one, latency stays flat while the transfer runs.

Idle connections keep what they learned

Loading a page is not one continuous transfer. The browser fetches HTML, pauses to parse it, then returns for stylesheets, scripts, and images over the same keepalive connection.

Standard behavior is to reset the congestion window after an idle period longer than a retransmission timeout and re-enter slow start, on the theory that path conditions may have changed. For a web workload the idle gaps are constant and short, and the path has not changed at all. Our edge servers keep the window the connection already earned, so the second wave of requests transfers at the rate the first one established instead of ramping from scratch.

The same algorithm everywhere

HTTP/3 traffic already ran BBR. QUIC carries congestion control inside the transport rather than deferring to the operating system’s TCP stack, and BBR is the algorithm it uses. HTTP/1.1 and HTTP/2 took whatever the TCP stack defaulted to instead.

This closes that gap. Every connection Agiler serves is now governed by BBR, whichever protocol carries it. A visitor whose browser or network cannot use HTTP/3 no longer pays a penalty in congestion control for it, and the traffic that was previously slowest to recover from loss is exactly the traffic this speeds up.

It is sender-side only. Nothing changes on the visitor’s machine, no client support is required, and there is no configuration on your project. It applies to every request Agiler serves.