Loading field map
Congestion control is the set of techniques used by computer networks to prevent a situation where too much data is offered to the network at once, causing performance to collapse rather than merely degrade. When the load on a network link approaches its capacity, queues in routers begin to fill. If the load continues, those queues overflow and packets are dropped. Critically, the senders of those dropped packets—if they are using a reliable transport protocol like TCP—will retransmit the data, adding even more load to an already saturated network. This feedback loop can drive the network into a state of collapse where throughput falls to a small fraction of the available capacity, even though all links are busy. Congestion control is the science and engineering of preventing or managing this condition.
The central question of the field is deceptively simple: how should a sender decide how fast to transmit? The difficulty lies in the fact that, in most networks, a sender has no direct knowledge of the available bandwidth, the number of competing flows, or the state of router queues along its path. It must infer these conditions from indirect signals—most commonly, packet loss, delay, or explicit feedback from the network—and adjust its sending rate accordingly. The stakes are high: too aggressive a rate causes congestion and collapse; too conservative a rate wastes capacity and gives poor performance to users. The field therefore sits at the intersection of control theory, distributed algorithms, and practical protocol design.
Any congestion control scheme must balance two goals. The first is efficiency: the total traffic on a link should be as close as possible to the link's capacity without exceeding it. The second is fairness: when multiple flows share a bottleneck, each should receive a reasonable share of the capacity. These goals are in tension. A scheme that maximizes total throughput might starve some flows entirely; a scheme that gives every flow an equal share might leave capacity idle if flows have very different round-trip times.
The standard definition of fairness used in the field is max-min fairness: no flow can increase its rate without decreasing the rate of a flow that already has an equal or smaller rate. In practice, this means that all flows sharing a bottleneck should converge to roughly the same rate, regardless of how many hops their paths traverse. A simpler and more widely used operational target is that a congestion control scheme should converge to a stable equilibrium where the total load is near capacity and the per-flow rates are approximately equal.
The foundational approach to congestion control, and still the most widely deployed, is the Additive Increase, Multiplicative Decrease (AIMD) algorithm, introduced with TCP's congestion control in the late 1980s. The insight behind AIMD is that a sender should probe for available bandwidth cautiously and react to congestion decisively.
The sender maintains a congestion window, which limits how many unacknowledged packets it may have in flight. In the absence of congestion, the window increases by a small fixed amount per round-trip time—this is the additive increase. When congestion is detected—typically by the loss of a packet—the window is multiplied by a factor less than one, typically halved. This is the multiplicative decrease.
The elegance of AIMD lies in its dynamics. When multiple flows share a bottleneck, the additive increase phase lets them all grow their rates together, preserving whatever ratio of rates they currently have. The multiplicative decrease phase, however, cuts each flow's rate in proportion to its current rate, so a flow that has grown too large is cut more severely. Over time, this combination drives all flows toward equal rates. The scheme is also self-limiting: because the increase is additive and the decrease is multiplicative, the system naturally oscillates around the available capacity rather than overshooting it catastrophically.
AIMD has a crucial limitation: it only detects congestion after it has already occurred, by observing packet loss. This means the network must be driven into a state of queue overflow before the sender learns to slow down. The resulting oscillation between full queues and empty queues causes both delay and jitter. For bulk file transfer, this is acceptable. For interactive applications like voice or video, the delay spikes are problematic.
The recognition that loss is a late and crude signal led to a major division in the field. Loss-based congestion control, exemplified by the original TCP Reno and its successors, treats packet loss as the only signal of congestion. These schemes push the network until queues overflow, then back off. They are simple, robust, and work well when the goal is to maximize throughput over a path with ample buffering.
Delay-based congestion control, by contrast, uses the measured round-trip time as a signal. The key observation is that as queues build up, the round-trip time increases before any packet is lost. A sender that monitors its round-trip time can detect the onset of congestion earlier and slow down before queues overflow. The pioneering scheme in this tradition was TCP Vegas, developed in the mid-1990s. Vegas compares the actual throughput it is achieving to the throughput it would achieve if the network were empty, and adjusts its window to keep a small, fixed amount of data queued in the network.
Delay-based approaches have the advantage of avoiding the delay spikes and packet loss associated with loss-based schemes. They also tend to be more efficient in networks with large buffers, because they do not fill those buffers unnecessarily. However, they have a serious weakness: they are vulnerable to competition from loss-based flows. If a loss-based flow shares a bottleneck with a delay-based flow, the loss-based flow will keep increasing its rate until packets are dropped, while the delay-based flow, seeing rising delay, will back off. The result is that the delay-based flow gets a tiny share of the bandwidth. This fairness problem has prevented delay-based schemes from being widely deployed as the default, although they remain influential as components of hybrid schemes.
The choice between loss and delay is not the only axis of variation. A broader way to organize the field is by the type of signal the sender uses to infer congestion. This yields three broad families.
The first family uses implicit signals already present in the network. Loss and delay are the two classic examples. Loss is binary and unambiguous but late; delay is continuous and early but noisy, since round-trip time also varies with routing changes and link-layer retransmissions. A third implicit signal is the rate at which acknowledgments return to the sender, which can be used to estimate the available bandwidth directly.
The second family uses explicit signals from the network. The most important of these is Explicit Congestion Notification (ECN), which allows a router to mark a packet instead of dropping it when its queue is growing. The sender treats the mark as a signal to reduce its rate. ECN has the advantage of signaling congestion without incurring the cost of a retransmission, and it can be used to signal incipient congestion before the queue overflows. However, ECN only provides a binary signal—marked or not—and its deployment has been uneven.
The third family uses explicit rate signals, where the network tells the sender exactly how fast it may transmit. This is the approach taken by Asynchronous Transfer Mode (ATM) networks, where switches compute a fair rate for each flow and communicate it back to the sender. This approach gives the network precise control over its queues and can achieve very high utilization, but it requires routers to maintain per-flow state and to participate in a signaling protocol, which is impractical in the global Internet.
The original AIMD scheme was designed for networks where the bandwidth-delay product—the amount of data that can be in flight on a path—is modest. On a path with a 10 Mbps link and a 100 ms round-trip time, the bandwidth-delay product is about 125 KB, and AIMD converges to a fair share in a reasonable time. On a path with a 10 Gbps link and the same round-trip time, the bandwidth-delay product is 125 MB. AIMD would take an impractically long time to ramp up to a fair share, and a single packet loss would cut the rate in half, requiring another long ramp-up.
This problem motivated a family of high-speed congestion control schemes, including BIC and its successor CUBIC, which is now the default in Linux. CUBIC replaces the linear increase of AIMD with a cubic function of time since the last loss event. After a loss, the window grows very quickly, then slows as it approaches the window size at which the loss occurred, then grows again if no further loss occurs. This allows the sender to recover quickly from a loss while remaining stable near the equilibrium. CUBIC is still loss-based, but its growth function is designed to scale to very high bandwidth-delay products.
A different challenge comes from networks where the available bandwidth varies over time, either because the link is shared with other traffic or because the physical medium itself is variable. Wireless links are the canonical example: their capacity fluctuates with signal strength, interference, and competing users. A congestion control scheme designed for a stable wired link may misinterpret a temporary drop in capacity as congestion and cut its rate unnecessarily, or it may fail to detect congestion because the bottleneck is not in the router queue but in the air interface. Modern schemes, such as BBR, attempt to address this by explicitly modeling the path's bottleneck bandwidth and round-trip propagation time, rather than reacting to loss or delay alone.
A more recent development is the shift from reactive schemes, which respond to signals of congestion, to model-based schemes, which build an explicit model of the path and use it to compute a sending rate. The most influential of these is BBR, developed at Google and deployed on its internal and public networks. BBR estimates two parameters: the bottleneck bandwidth, which it measures by observing the rate at which acknowledgments return when the sender is sending faster than the bottleneck can drain, and the round-trip propagation time, which it measures by sending at a low rate and observing the minimum round-trip time over a window.
BBR then paces its sending at the estimated bottleneck bandwidth, while keeping the amount of data in flight equal to the bandwidth-delay product plus a small amount of buffering. This approach has several advantages. It does not fill router queues, so it achieves low delay. It does not rely on packet loss, so it works well on paths with shallow buffers or lossy wireless links. And it can achieve high utilization even on paths with very large bandwidth-delay products, because it does not need to probe for capacity by filling the pipe.
However, BBR has its own limitations. Its model assumes that the bottleneck bandwidth and propagation time are stable over the measurement window, which is not always true. It can be unfair to loss-based flows in some configurations, and it can interact poorly with other BBR flows that share a bottleneck, causing oscillations. The field is still actively researching how to make model-based schemes robust and fair in all circumstances.
The current state of congestion control is best described as a coexistence of multiple paradigms, each with its own strengths and weaknesses. The default in most operating systems is still a loss-based scheme—CUBIC on Linux, and a variant of CUBIC or NewReno on other platforms—because these schemes are well understood, robust, and fair to each other. Delay-based schemes have found a niche in data centers, where the network is controlled and the traffic is dominated by short, latency-sensitive flows. Model-based schemes like BBR are deployed on large-scale content delivery networks, where the operators can tune them carefully and where the benefits of low delay and high utilization are substantial.
The field continues to evolve in response to new network conditions. The rise of cellular networks, with their rapidly varying capacity and high latency, has motivated schemes that can distinguish between congestion and wireless loss. The growth of encrypted traffic has made it harder for middleboxes to observe and influence congestion control, pushing more of the logic into the endpoints. And the increasing use of multipath transport, where a single connection uses several network paths simultaneously, has created new challenges for fairness and stability.
A recurring theme across all these developments is the tension between simplicity and adaptability. The original AIMD scheme is simple enough to be implemented in a few dozen lines of code and to be analyzed mathematically. Modern schemes are more complex, with multiple modes, estimators, and heuristics, and their behavior is often understood only through simulation and deployment experience. This complexity is not gratuitous; it reflects the difficulty of the problem. A sender must infer the state of a network it cannot observe directly, must share that network with other senders it cannot coordinate with, and must do so over paths that change over time. Congestion control remains an active area of research precisely because no single scheme has yet resolved all these tensions.