Table of Contents
Understanding Congestion in Networks
Congestion control is about protecting the network itself, not only individual connections. While flow control cares about not overwhelming a single receiver, congestion control cares about not overwhelming the routers, links, and shared paths in between.
When too many packets share the same path at the same time, queues in routers fill up, packets are dropped, and delays grow. Congestion control is the set of strategies that transport protocols, especially TCP, use to detect this situation and to reduce the sending rate before the network collapses into persistent overload.
What Causes Congestion?
On any path between two hosts, each router has limited buffer memory and each link has a fixed capacity. If packets arrive faster than they can be forwarded, they are placed into queues. If the incoming rate stays too high, queues grow and eventually overflow, so routers start dropping packets.
Typical reasons include many TCP connections sharing the same link, a sudden burst of traffic from several senders, or slow receivers connected after a fast router. Since the IP layer provides no global coordination, each sender must infer congestion only from indirect signals such as delay or loss.
How TCP Detects Congestion
TCP is designed to adapt its sending rate based on feedback that suggests whether the network is congested or not. It does not see the routers directly, so it relies on observable behavior of acknowledgments and packets.
Two key signals guide TCP:
- Packet loss. If acknowledgments (ACKs) do not arrive in time, or if duplicate ACKs indicate that some data went missing, TCP assumes that packets were dropped in the network, usually due to full queues. Loss is treated as a strong sign of congestion.
- Increasing delay. As queues fill, ACKs arrive later. Some TCP variants can treat growing round trip time as an early warning that congestion is starting, even before actual losses occur.
Routers in basic IP networks do not explicitly tell TCP that they are congested. Instead, TCP assumes that loss or delay is a symptom of overload and reacts by slowing down.
Congestion Window and Sending Rate
To control congestion, TCP maintains a congestion window, usually written as $cwnd$. This is a limit on how much unacknowledged data the sender is allowed to have “in flight” on the network at any given moment.
The sending rule is conceptually:
At any time, the amount of unacknowledged data must not exceed
$$
\text{min}(\text{cwnd}, \text{receiver window})
$$
The receiver window is used for flow control and reflects how much the receiver can handle. The congestion window reflects what the network path can handle. The effective limit is the smaller of these two.
When the network appears healthy, TCP increases $cwnd$ so that it can use more bandwidth. When congestion is detected, TCP reduces $cwnd$ to relieve pressure on the path.
Slow Start
Slow start is the initial behavior TCP uses to “probe” the available capacity of the network. Despite its name, slow start actually increases the sending rate quite aggressively at the beginning of a connection or after a timeout.
At the start, $cwnd$ is small, often a few segments. For each acknowledgment that comes back, TCP increases $cwnd$ so that the number of segments in flight roughly doubles every round trip time. This is called exponential growth.
In simple terms, during slow start:
Each round trip time, $cwnd$ approximately doubles,
until it reaches a threshold called $ssthresh$ or until loss occurs.
This method allows TCP to quickly discover a rough upper bound of how much the path can carry. However, if $cwnd$ grows beyond the true capacity, queues overflow and packets are dropped, which triggers a transition out of slow start.
Congestion Avoidance
After $cwnd$ reaches the slow start threshold, $ssthresh$, TCP stops exponential growth and switches to a more careful phase called congestion avoidance.
In congestion avoidance, TCP increases $cwnd$ much more gradually, roughly by one maximum segment size per round trip time. This is called additive increase. The goal is to slowly test if the path can handle a little more traffic without pushing it into congestion again.
In simple form:
In congestion avoidance, $cwnd$ grows approximately linearly,
by about 1 segment per round trip time, as long as there is no sign of congestion.
With this behavior, TCP oscillates around the available capacity. It tries slightly higher rates, and if they cause loss, it backs off. Over time, this results in a balance where the link is fairly well used but not permanently overloaded.
Reaction to Packet Loss
The exact reaction to packet loss depends on how TCP detects it. Two important cases are timeout and triple duplicate ACKs.
If a timeout occurs, it means an acknowledgment took too long and TCP assumes a packet was lost and that the congestion is serious. TCP responds more aggressively:
- It sets the slow start threshold $ssthresh$ to about half of the current $cwnd$.
- It resets $cwnd$ to a small value, often one or a few segments.
- It reenters slow start and begins exponential growth again, but now up to the new, lower $ssthresh$.
If triple duplicate ACKs arrive, the receiver is repeatedly acknowledging the same old data. This indicates that one segment was lost, but other segments are getting through. TCP considers this a milder form of congestion and uses a less drastic reaction called fast retransmit and fast recovery.
In a typical approach:
On detecting loss, TCP reduces $cwnd$, often to about half its previous size,
and sets $ssthresh$ to this reduced value, then resumes growth cautiously.
This pattern is called multiplicative decrease, because the window is reduced by a multiplicative factor, usually around one half. Combined with the additive increase during congestion avoidance, this creates the well known additive increase, multiplicative decrease behavior.
Fast Retransmit and Fast Recovery
Fast retransmit is a mechanism to repair a lost segment quickly without waiting for a timeout. When three duplicate ACKs arrive, TCP assumes that the segment just before the acknowledged data was lost. Instead of waiting, it retransmits that missing segment at once.
Fast recovery then adjusts the congestion window while staying in congestion avoidance rather than dropping all the way back to the beginning.
A typical sequence looks like this:
- Triple duplicate ACKs are received.
- TCP sets $ssthresh$ to about half of the current $cwnd$.
- TCP reduces $cwnd$ so that it reflects this new, smaller capacity.
- The missing segment is retransmitted immediately.
- When ACKs resume, TCP continues in congestion avoidance instead of full slow start.
The advantage of fast retransmit and fast recovery is that TCP maintains better throughput when only a small amount of data is lost, and it still reduces its sending rate to relieve congestion.
AIMD and Fairness
The combination of additive increase and multiplicative decrease is called AIMD. It has two important goals: stability and fairness.
Stability means that the network does not stay permanently overloaded. When congestion appears, each TCP connection cuts its window significantly. When the network is free again, each connection increases gradually. This keeps the total load fluctuating around the available capacity.
Fairness means that multiple competing TCP flows sharing the same link tend to converge toward using similar amounts of bandwidth, assuming they have similar round trip times. Because each flow grows its $cwnd$ linearly and cuts it by a similar factor when loss occurs, no single flow is allowed to permanently dominate the others.
Modern Variants of Congestion Control
The basic ideas of slow start, congestion avoidance, and AIMD are present in many TCP implementations, but different variants use different details to improve performance in real networks.
Examples include algorithms that:
Use more advanced rules for how quickly to increase $cwnd$ when there is no loss, in order to better match the available bandwidth.
Estimate the bandwidth or the capacity of the path more directly, instead of relying only on loss.
Use delay as an early congestion signal, attempting to keep queues shorter and reduce latency.
These variants still share the central principle that TCP must adapt its own sending rate based on inferred congestion, rather than sending at a fixed, unlimited rate.
Interaction with the Network and Other Flows
Congestion control is not just a local behavior inside one connection. It interacts with every other flow sharing the same routers and links. When many TCP connections use standard congestion control, they coordinate indirectly. When congestion appears, they all reduce their rate, and when the network clears, they all increase.
If some applications ignore congestion control, for example by using protocols that send at a fixed rate without reacting to loss, they can harm other flows by filling queues and using bandwidth unfairly. This is one reason why TCP congestion control is considered essential to the stability of the public Internet.
In practice, the exact behavior you see depends on the TCP variant used by your operating system, the characteristics of the path, and how many other flows are competing for the same resources. However, the core ideas of congestion windows, slow start, congestion avoidance, and AIMD remain the foundation for how congestion control works in TCP.