Why BBRv2 Redefines TCP Congestion Control: Lessons from BBRv1’s Shortcomings

In October 2016 a YouTube video titled “Making Linux TCP Fast” introduced the BBR algorithm, marking a new era for TCP congestion control.

BBR is simple and based on a single‑flow ideal model, but real networks do not follow this model, leading to poor performance in multi‑flow scenarios, fairness issues, and frequent high‑retransmission throughput drops.

The root cause is that BBR must use more inflight data to probe potential bandwidth, similar to loss‑based algorithms, but without appropriate MD feedback, causing inflight to rise to high levels, leading to queuing and packet loss.

Multiple BBRv1 flows overestimate bandwidth due to the max_filter, causing the total sent data to exceed pipe capacity, creating standing queues and persistent packet loss because BBRv1 does not reduce the inflight cap (2 BDP).

BBRv2 addresses these problems by measuring delivery rate more precisely and constraining inflight using loss and ECN signals. It introduces a sub‑state machine within the ProbeBW state.

Key mechanisms of BBRv2 include:

Real‑time tracking of loss rate and ECN marks to adjust inflight_hi/lo and limit actual inflight.

Real‑time tracking of loss and ECN marks, supplemented by fairness guarantees, to drive sub‑state transitions.

In the cruise state, preserving headroom as a “common‑pool contribution”.

BBRv2 reserves an AIMD‑cycle window for Reno/CUBIC equal to 0.5 × Max_cwnd (≈ BDP RTTs). Two probe‑up phases are spaced by at least this window, and probe‑up proceeds only if no loss is observed, enabling friendly coexistence.

Typical BDP values are similar for data‑center (≈ 66 packets) and Internet (≈ 62 packets) networks, allowing BBRv2 to probe up after about 60 RTTs (≈ 2 s on the Internet, ≈ 1.3 ms in DC), a time scale that adapts to network conditions.

Compared with BBRv1’s fixed 8‑round probe, BBRv2’s longer, adaptive intervals provide a more robust coexistence strategy, especially in asynchronous multi‑flow environments where the BDP‑RTT AIMD cycle follows a right‑tailed Gaussian distribution.

Drawing on concepts from “The Beauty of Systems” such as “bounded rationality” and the “tragedy of the commons”, BBRv2’s feedback mechanisms mitigate selfish bandwidth consumption, offering a more equitable solution than BBRv1.

Although BBRv2 is not yet merged into the Linux kernel (as of v6.1‑rc2) and remains in Google’s branch, it shows promise for long‑term evolution and may eventually become the default algorithm, succeeding CUBIC.

In work discussing TCP CC evolution inside data centers, short bursts favor increasing init cwnd to about one BDP and reusing long‑lived connections; for long flows, BBRv2 is preferred as it adapts better and includes DCTCP features.