Traditional loss-based congestion control algorithms (Reno, CUBIC) treat packet loss as the primary signal of network congestion. They continuously ramp up the congestion window (cwnd) until an intermediate router buffer overflows and drops packets (tail drop). This design inherently maximizes queue occupancy, causing severe bufferbloat (latency inflation from tens of milliseconds to hundreds of milliseconds) and collapsing throughput on wireless or high-loss links where packets drop due to noise rather than true congestion. In contrast, BBR (Bottleneck Bandwidth and Round-trip propagation time), designed by Google, is a model-based algorithm. BBR continuously builds an explicit physical model of the network path by measuring two orthogonal parameters: max delivery rate (bottleneck bandwidth, BtlBw) over a sliding window, and minimum round-trip time (RTprop) over tens of seconds. BBR paces packets at exactly BtlBw and caps inflight data at 1 to 2 times BDP, achieving maximum throughput while keeping router queues nearly empty.

In 1979, Leonard Kleinrock proved that the optimal operating point for any network pipe is where delivery rate is maximized (equal to bottleneck bandwidth BtlBw) and end-to-end round-trip time is minimized (equal to physical propagation time RTprop). At this point, the network carries exactly one Bandwidth-Delay Product (1 BDP) of inflight data, queue occupancy is zero, and delay is minimal. For decades, engineers believed it was impossible to track the Kleinrock point because of a fundamental measurement ambiguity: to measure BtlBw, you must send faster than the bottleneck (which creates a queue and inflates RTT); to measure RTprop, you must drain the queue completely (which temporarily starves the bottleneck and drops throughput). BBR solves this by alternating between state machine phases: it probes bandwidth during ProbeBW and periodically drains inflight data to 4 packets during ProbeRTT to sample genuine RTprop.

RFC 8312 CUBIC replaced Reno as the default Linux congestion control algorithm in kernel 2.6.19. Reno linear increase (+1 MSS/RTT) took hours to recover a 10 Gbps pipe after a single packet loss. CUBIC replaces linear growth with a cubic polynomial function: W(t) = C * (t - K)^3 + W_max, where W_max is the window size prior to the last loss, C is a scaling constant (default 0.4), and K = cuberoot(W_max * beta / C) is the time required to regain W_max without loss. The cubic curve has three distinct phases: (1) Concave growth: rapid increase when far below W_max; (2) Plateau region: window growth flattens near W_max, providing stability and maximizing throughput near the estimated capacity; (3) Convex probe: if no loss occurs after K seconds, CUBIC accelerates sharply to aggressively discover newly available capacity.

Standard loss-based TCP relies on "ACK clocking": the sender only transmits new packets when triggered by arriving ACKs, leading to bursts of packets if ACKs cluster together. BBR fundamentally operates on packet pacing: rather than transmitting in bursts, BBR computes an explicit pacing rate: pacing_rate = pacing_gain * BtlBw, and schedules individual packets evenly spaced across time. If the underlying network interface card or queue discipline cannot pace packets, the kernel transmits whole cwnd bursts at wire speed, causing transient micro-burst queue drops in shallow-buffer switches. Linux fq (Fair Queueing with pacing, sch_fq) implements hardware/software pacing timers per socket, holding packets in the socket buffer until their exact departure timestamp, eliminating micro-burst packet loss.

BBRv1 suffered from two known issues in production: (1) Unfairness to CUBIC: because BBRv1 maintained ~1.5 to 2.0 BDP in flight, it persistently out-competed loss-based TCP flows and struggled to yield bandwidth; (2) Loss sensitivity in shallow buffers: in datacenter switches with shallow buffers (<0.2 BDP), BBRv1 1.25x pacing probe caused continuous 10% to 20% packet loss. BBRv2 addressed this by introducing explicit congestion signals: it integrates Explicit Congestion Notification (ECN, L4S/DCTCP style) and bounds inflight data based on observed packet loss rates (inflight_hi). BBRv3 further refines the state machine by shortening the ProbeRTT duration from 200ms to a dynamic interval, optimizing pacing rate ramps, and eliminating throughput dips on multi-gigabit connections.

The classic Mathis formula states: Throughput <= (MSS / RTT) * (C / sqrt(p)), where MSS is Maximum Segment Size, RTT is round-trip time, p is packet loss probability, and C is a constant (~0.93 for Reno). For loss-based TCP, even a 1% packet loss (p=0.01) on a 100ms transcontinental link with 1460-byte MSS caps throughput to approximately 1.16 MB/s (9.3 Mbps), regardless of whether the physical fiber has 10 Gbps capacity! BBR circumvents this catastrophic degradation because it does not halve its congestion window upon packet loss. BBR filters delivery rates over time: if packets are lost but delivered packets arrive at the full line rate, BBR recognizes that loss is random/non-congestive and maintains its full multi-gigabit transmission rate.