In the late 1980s, the Internet faced a crisis. As the network grew, a phenomenon called congestion collapse threatened to bring data transfer to a halt: senders would keep retransmitting packets that were already queued or dropped, making the problem worse. The central question that emerged was deceptively simple: what signal should a sender use to decide whether to speed up or slow down? The answer has shaped decades of protocol design, producing a family of frameworks that disagree on where to look for congestion—loss, delay, explicit router marks, or a model of the path itself—and on who should do the looking: the endpoints alone, the routers, or both in concert.
Van Jacobson’s 1988 TCP congestion control algorithms gave the Internet its first systematic answer. The sender infers congestion solely from packet loss: when an acknowledgment times out or a duplicate ACK arrives, the sender halves its window (multiplicative decrease); otherwise, it slowly increases the window by one segment per round trip (additive increase). This Additive Increase Multiplicative Decrease (AIMD) rule, implemented entirely at the endpoints, was a deliberate architectural choice. It preserved the End-to-End Principle by keeping the network core simple—routers just dropped packets when buffers overflowed—and it proved remarkably effective at preventing collapse. AIMD/TCP became the default paradigm, and its fairness property (converging to equal bandwidth shares among competing flows) set a benchmark that later frameworks would either preserve or challenge.
Almost as soon as AIMD was deployed, researchers asked whether routers could do more than drop packets. The Router-Assisted Congestion Control framework proposed that routers should actively signal incipient congestion before buffers overflow. The DECbit scheme (1990) had routers set a bit in packet headers when average queue length exceeded a threshold. Random Early Detection (RED, 1993) extended this idea by probabilistically marking or dropping packets as queue depth grew, giving senders a gentler signal than a hard drop. Explicit Congestion Notification (ECN, 2001) standardized a two-bit field so routers could mark packets without dropping them. Where AIMD treated the network as a black box that only reveals congestion through loss, Router-Assisted frameworks opened the box: they gave the network a voice. Yet deployment lagged. Because ECN required both router and endpoint support, and because AIMD worked well enough for most traffic, router-assisted signaling remained an optional enhancement rather than a replacement for loss-based inference.
A different critique of AIMD came from Delay-Based Congestion Control. Instead of waiting for loss, these frameworks use changes in round-trip time (RTT) as an early signal. TCP Vegas (1994) compared the actual throughput to an expected throughput based on the minimum observed RTT; when the difference grew, Vegas reduced its window before loss occurred. FAST TCP (2003) generalized this approach for high-speed long-distance links. The appeal was clear: delay-based control could detect congestion earlier, keeping queues short and reducing jitter. But it faced a fundamental fairness problem when competing with loss-based AIMD flows. Because AIMD flows fill buffers until they drop packets, they push delay-based flows to see higher RTTs, causing the delay-based flows to back off while the loss-based flows keep sending. In a mixed deployment, delay-based frameworks lose bandwidth to loss-based ones. This asymmetry meant that delay-based control, despite its theoretical elegance, never became the default—it survived as a specialized approach for environments where queueing delay matters more than raw throughput.
Multimedia applications posed a different problem for AIMD. Voice and video streams need a relatively smooth sending rate, but AIMD’s sawtooth pattern—halving the rate on loss, then slowly climbing back—produces abrupt changes that degrade perceptual quality. Equation-Based Congestion Control, embodied in TCP-Friendly Rate Control (TFRC, 2000), addressed this by modeling the steady-state throughput of TCP as a function of loss rate and RTT. Instead of reacting to each loss event, TFRC adjusts its rate to match the long-term average of a TCP flow under the same conditions. This preserves TCP-friendliness—TFRC does not steal bandwidth from AIMD flows—while delivering a much smoother rate. Where AIMD treats every loss as an urgent signal, TFRC treats loss as a statistical parameter. The trade-off is slower reaction to sudden changes in available bandwidth, which limits TFRC to applications that can tolerate a delayed response.
As link speeds grew to gigabits per second and RTTs remained bounded by the speed of light, AIMD revealed a new weakness: recovery from a single loss event could take tens of seconds or even minutes on a high-bandwidth, long-delay path. High-Speed Congestion Control frameworks modified AIMD’s increase and decrease rules to ramp up faster and cut less aggressively at high window sizes. HSTCP (2002) used a concave increase function that grew more aggressive as the window increased. BIC-TCP (2004) used a binary-search-like increase around the last window where loss occurred. CUBIC (2006), now the default in Linux, replaced the linear increase with a cubic function that grows quickly after a loss but flattens near the estimated bandwidth ceiling. These frameworks did not reject AIMD’s loss-based signal; they preserved it while changing the control law. The result was a family of protocols that could saturate high-speed links while remaining broadly fair to standard TCP when competing on lower-speed paths. CUBIC’s dominance today shows how a targeted modification of AIMD can become the new baseline.
By the mid-2000s, researchers had accumulated two distinct congestion signals—loss and delay—each with its own strengths. Hybrid Congestion Control frameworks sought to combine them. Compound TCP (2005), deployed in Windows, maintains two windows: a loss-based AIMD window and a delay-based window that grows when RTT is stable and shrinks when queuing delay increases. The effective window is their sum. This design lets Compound TCP probe for extra capacity using delay signals when the path is underutilized, while falling back to loss-based behavior when delay signals are ambiguous. Hybrid frameworks thus absorbed the insights of Delay-Based Congestion Control without abandoning the robustness of loss-based AIMD. They did not replace either parent framework; instead, they created a synthesis that performed better than either alone in many real-world conditions.
Data centers presented a radically different environment: shallow buffers, sub-millisecond RTTs, and a mix of latency-sensitive queries and bulk transfers. AIMD’s loss-based sawtooth caused buffer overflows and high tail latency. Data Center Congestion Control frameworks, led by DCTCP (2010), adapted Router-Assisted signaling to this setting. DCTCP uses ECN marks at a very low threshold (e.g., marking when queue length exceeds a few packets) and reacts proportionally to the fraction of marked packets in a window, rather than halving the window on any mark. The result is a fine-grained control loop that keeps queues nearly empty while maintaining high throughput. DCQCN (2014) extended similar ideas to RDMA over Converged Ethernet. Where earlier Router-Assisted frameworks had been optional enhancements for the general Internet, Data Center Congestion Control made router signaling essential: the shallow buffers of data center switches leave no room for loss-based detection. This framework also borrowed from Delay-Based control’s goal of low queueing delay, but achieved it through explicit marking rather than RTT measurement.
BBR (Bottleneck Bandwidth and Round-trip propagation time, 2016) broke with the entire signal-inference tradition. Instead of reacting to loss or delay, BBR builds a model of the path: it estimates the bottleneck bandwidth (BtlBw) and the round-trip propagation time (RTprop) by pacing packets at increasing rates and observing the resulting RTT. The sender then paces at the estimated BtlBw, keeping the queue at the bottleneck just barely occupied. Loss is treated as a sign that the model needs recalibration, not as a congestion signal. This is a paradigm shift. Where AIMD, Delay-Based, and Hybrid frameworks all infer congestion from observed events, BBR infers the path’s physical limits and sends at that rate. The approach achieves high throughput with low latency, but it also creates fairness tensions: BBR flows can starve CUBIC flows in some scenarios because BBR does not back off when it sees loss. BBR’s relationship to Router-Assisted frameworks is also complex—both aim to move beyond loss inference, but BBR does so by modeling at the endpoint, while Router-Assisted frameworks rely on network feedback. BBR is now deployed on Google’s internal networks and YouTube, and its ongoing evolution (BBRv2 adds loss-based responses) reflects the difficulty of replacing a deeply entrenched paradigm.
Today, no single framework dominates everywhere. CUBIC remains the Linux default and handles most Internet traffic. DCTCP and its variants are standard in data centers. BBR is increasingly used for long-haul and video traffic. These frameworks agree on the basic goal—maximize throughput while minimizing queueing delay—but disagree on the means. The central disagreement is about signal philosophy: should a sender treat loss as the definitive sign of congestion (CUBIC), or as a failure of the model (BBR)? A second disagreement concerns fairness: CUBIC and BBR flows do not share bandwidth equitably, and no consensus exists on whether new frameworks must be TCP-friendly. A third tension is architectural: should routers actively participate in signaling (DCTCP), or should endpoints infer everything from passive observation (CUBIC, BBR)? The field has moved from a single dominant framework to a pluralistic landscape where the right choice depends on the environment. The question that opened the subfield—what signal should a sender use?—now has multiple answers, each with its own domain of applicability and its own unresolved debates.