Congestion Control Principles

Congestion control regulates the rate at which senders inject data into a shared network so that aggregate demand stays near capacity, avoiding the congestion collapse that occurs when offered load overwhelms the network's ability to deliver it.

Definition

Congestion control is the set of mechanisms by which senders adjust their transmission rates in response to signals of network congestion, so as to keep the aggregate load near the network's capacity while sharing it fairly among competing flows.

Scope

This topic covers the principles and practice of congestion control: the distinction from flow control, the causes and costs of congestion, end-to-end versus network-assisted approaches, the additive-increase/multiplicative-decrease (AIMD) dynamic and its fairness and stability properties, and TCP's concrete algorithms — slow start, congestion avoidance, fast recovery — together with the role of explicit congestion notification and the existence of alternative algorithms. It excludes the per-connection reliability mechanisms, which address loss recovery rather than network overload.

Core questions

• How does congestion control differ from flow control?
• What causes congestion, and what is congestion collapse?
• What is the AIMD dynamic, and why does it lead to fairness and stability?
• How do TCP's slow start, congestion avoidance, and fast recovery phases work?
• How do end-to-end (loss/delay) signals compare with network-assisted signals such as ECN?

Key concepts

• congestion versus flow control
• congestion collapse
• additive-increase/multiplicative-decrease (AIMD)
• slow start
• congestion avoidance
• fast retransmit and fast recovery
• congestion window
• explicit congestion notification (ECN)
• fairness and efficiency

Key theories

Additive increase, multiplicative decrease (AIMD)

Increasing the sending window linearly while there is no congestion and halving it on a congestion signal drives competing flows toward an equal, efficient share of capacity; analysis shows AIMD converges to fairness and efficiency, which is why TCP adopts it.

TCP congestion control phases

TCP probes for bandwidth with an exponential slow-start, switches to linear congestion avoidance near the estimated capacity, and uses fast retransmit/fast recovery to react to isolated loss without restarting, inferring congestion primarily from packet loss.

Avoiding congestion collapse

Without rate control, retransmissions during overload can drive a network into congestion collapse where throughput plummets; the introduction of congestion avoidance in the late 1980s rescued the Internet from repeated collapses.

Clinical relevance

Congestion control is what keeps the shared Internet usable under heavy load: it has prevented systemic collapse since the late 1980s and continually balances throughput, latency, and fairness for billions of flows. Its design directly affects download speeds, video-streaming quality, and data-center performance, and active research on algorithms such as CUBIC and BBR and on low-latency queue management continues to refine this balance.

History

After a series of congestion collapses on the early Internet in 1986-1987, Van Jacobson's 1988 work introduced slow start and congestion avoidance, establishing modern TCP congestion control. Chiu and Jain's 1989 analysis explained why AIMD yields fairness and efficiency. Subsequent decades produced variants such as Reno, NewReno, CUBIC, and the model-based BBR, plus router-side mechanisms like RED and ECN.

Debates

Loss-based versus delay- and model-based congestion control

Loss-based TCP reacts only when buffers overflow, which can cause high latency (bufferbloat) and underuse fast long-distance links, motivating delay-based and model-based schemes such as BBR; debate centers on fairness when these coexist with traditional loss-based flows.

Key figures

• Van Jacobson
• Dah-Ming Chiu
• Raj Jain
• Sally Floyd

Seminal works

• jacobson1988
• chiu1989
• kurose2021

Frequently asked questions

What is the difference between flow control and congestion control?

Flow control protects the receiver: it stops a fast sender from overrunning a slow receiver's buffer. Congestion control protects the network: it stops senders collectively from overwhelming the routers and links between them. TCP does both, using the receive window for flow control and the congestion window for congestion control.

Why does TCP slow down when it sees packet loss?

Loss is TCP's main signal that the network is congested. By sharply reducing its sending rate on loss and increasing it only gradually otherwise, TCP backs off when the network is overloaded and probes for spare capacity when it is not, which keeps aggregate traffic near capacity and shares bandwidth roughly fairly.