Congestion Control

1. What is Network Congestion?

In any network, from a small home LAN to the global internet, resources are finite. Network links have a maximum bandwidth, and devices such as routers have limited memory and processing capacity. A bottleneck appears when an incoming rate exceeds the service rate of an output link. Network congestion occurs when demand for these resources exceeds their available capacity.

When a router receives packets faster than it can forward them out of the appropriate interface, it stores the excess packets in a temporary memory buffer called a queue. If traffic continues to arrive at this high rate, the queue will grow. This is the root of congestion. Its symptoms are immediately apparent to users and applications:

• Increased Latency (Delay): Packets spend more time waiting in the queue, so it takes them longer to reach their destination.
• Increased Jitter: The length of the queue can fluctuate rapidly, causing the delay to vary from packet to packet, which is detrimental to real-time applications.
• Packet Loss: Eventually, the queue becomes completely full. New packets that arrive do not fit in the buffer and are discarded by the router.

If left unmanaged, severe congestion can lead to congestion collapse, where useful throughput falls as retransmissions consume capacity. Senders that detect loss retransmit data, adding traffic to an overloaded path. A large share of the available capacity can then carry packets that are lost again, leaving little capacity for new useful data. Congestion control provides mechanisms for limiting this feedback loop and sharing network resources.

2. Congestion Control vs. Flow Control

Congestion control and flow control address different limits and should be considered separately. TCP can apply both at once, so the sender is constrained by the smaller congestion and receive windows.

• Flow Control

  Flow control is a local mechanism that operates between a single sender and a single receiver. Its purpose is to ensure that the sender does not transmit data faster than the receiver can process it. The receiver advertises its available buffer space (the receive window in TCP), and the sender adjusts its transmission rate to avoid overflowing that buffer. Flow control protects the receiver.

• Congestion Control

  Congestion control concerns the path shared by many flows. A sender may communicate with a fast receiver that has a large buffer, so the receive window permits a high rate. If the path contains a slow or congested link, congestion feedback makes the sender reduce its rate. Congestion control protects the network.

3. The Goals of Congestion Control

Effective congestion control algorithms balance several objectives. The chosen balance depends on the traffic mix, path delay, and capacity available at the bottleneck:

• Efficiency: The network should provide high throughput, meaning a high rate of successful data delivery, while available capacity remains usable.
• Fairness: The algorithm should allocate a fair share of the network bandwidth to competing data flows. The definition of "fair" can vary, but typically it means that flows sharing the same bottleneck link should receive a roughly equal portion of the capacity.
• Stability: Network performance should remain predictable, with limited oscillation in throughput and delay.
• Low Delay: Especially for interactive and real-time applications, keeping queueing delays low is a primary goal.

4. TCP Congestion Control: A Cooperative Approach

The most widely deployed congestion control mechanisms include those specified for the Transmission Control Protocol (TCP). TCP uses an end-to-end strategy in which the sender infers path conditions from acknowledgments, loss, and ECN signals. The central state variable is the congestion window (cwnd).

The cwnd limits data in flight together with the receiver's advertised flow-control window (rwnd); the usable limit is the smaller value. TCP algorithms adjust cwnd from acknowledgments (ACKs), loss indications, or ECN feedback. The sender also uses the retransmission timeout (RTO) to detect missing feedback on the path. Classical TCP congestion control follows AIMD (Additive Increase, Multiplicative Decrease), while other controllers use different growth rules.

The lifecycle of TCP congestion control can be broken down into distinct phases.

Phase 1: Slow Start

When a TCP connection begins, the sender has limited information about path capacity. Slow Start probes the path by increasing the sending window quickly. Under the usual per-ACK rule, the window growth is approximately exponential until a threshold or congestion event is reached.

• The session starts with a small cwnd; values such as 1 to 10 Maximum Segment Sizes (MSS) occur in descriptions of initial windows, while the applicable standard and implementation determine the exact value. MSS is the largest TCP segment payload for the path. For the example, assume cwnd = 1 MSS.
• The sender transmits one segment. When an acknowledgment (ACK) for new data arrives, Slow Start can increase cwnd by up to 1 MSS.
• With one ACK for each newly acknowledged segment, cwnd approximately doubles during one round-trip time (RTT). Sending 1 segment can make the window 2, then 2 segments can make it 4, subject to the applicable limits.
• This growth continues until loss or another congestion signal occurs, or until cwnd reaches the slow start threshold (ssthresh).

Phase 2: Congestion Avoidance

Once cwnd reaches the ssthresh, the sender enters the more cautious Congestion Avoidance phase. The threshold selects the algorithmic region; it is not a direct measurement of link capacity.

• Instead of exponential growth, the sender now uses an additive increase.
• The cwnd is increased by at most approximately 1 MSS for every full round-trip time. A complete window of acknowledgments therefore increases the window by about one segment under the standard rule.
• This is a slower, linear growth phase that probes for additional capacity while limiting the increase per RTT.

Phase 3: Congestion Detection and Reaction

Congestion Avoidance continues until the sender detects loss or another congestion signal. TCP has two primary loss indications in this simplified model, and the response depends on how the signal arrived.

• Reaction to a Timeout: This is a strong indication that the sender has not received timely feedback. A timeout occurs when no ACK for a transmitted segment arrives within the calculated retransmission timeout (RTO). The sender retransmits and reduces its sending window.
  • The ssthresh is derived from the flight size, commonly as the larger of half the outstanding data and 2 MSS. Flight size means unacknowledged data still in the network.
  • The cwnd is drastically reduced, resetting to 1 MSS.
  • The sender re-enters Slow Start with cwnd = 1 MSS; this is the classic Tahoe-style response.
• Reaction to Triple Duplicate ACKs (Fast Retransmit/Fast Recovery): TCP can infer a likely loss earlier from duplicate ACKs. If a sender transmits segments 1, 2, 3, 4, 5 and segment 3 is lost, the receiver gets 1, 2, 4, 5. It acknowledges segment 2, then sends duplicate ACKs for 2 when segments 4 and 5 arrive. After three duplicate ACKs for the same sequence point, the sender performs Fast Retransmit without waiting for the RTO. The duplicate ACKs also show that later segments reached the receiver, so Reno-style recovery keeps sending with a reduced window:
  • This is the multiplicative-decrease part of AIMD. ssthresh is derived from the flight size as the larger of half the outstanding data and 2 MSS.
  • During Reno fast recovery, cwnd is temporarily inflated by the duplicate ACKs and then reduced to the new ssthresh after the loss is recovered.
  • The sender then continues in Congestion Avoidance rather than restarting Slow Start; exact behavior depends on the TCP loss-recovery variant.

5. Modern TCP Congestion Control Algorithms

Classical Reno AIMD increases the window linearly during Congestion Avoidance. Fast paths with long round-trip times can require many RTTs to recover a large window after a congestion event, which motivated other congestion-control algorithms.

• TCP CUBIC

  CUBIC is deployed as a default congestion-control algorithm in Linux, Windows, and Apple stacks. Instead of a purely linear increase, it uses a cubic window function. After a congestion event, it reduces the window, remembers the pre-event value as a target, grows with a concave profile toward that value, and then uses a convex profile beyond it. This design targets scalability and stability on fast, long-distance paths.

• BBR (Bottleneck Bandwidth and Round-trip propagation time)

  Developed by Google, BBR uses a model of the path rather than treating loss as its only congestion signal. It estimates bottleneck bandwidth and a minimum propagation RTT, then paces transmissions using those measurements. Its controller periodically probes for bandwidth and updates the model. BBR aims to reach high delivery rates without maintaining a persistent queue; its behavior and fairness depend on the BBR version and competing traffic.

6. Network-Assisted Congestion Control

End-to-end mechanisms such as TCP's handle congestion at hosts, while network devices can play an active role in managing congestion.

• Active Queue Management (AQM)

  AQM refers to router algorithms that manage queue length proactively. Instead of waiting for a queue to become full and then dropping arriving packets through tail-drop, an AQM algorithm can drop or mark packets earlier. The best-known example is Random Early Detection (RED). RED estimates the average queue length and increases the probability of an early drop as the average grows, giving responsive senders a congestion signal before the queue reaches its limit. AQM and scheduling address different functions: AQM controls queue size, while scheduling selects which queued packet is served next.

• Explicit Congestion Notification (ECN)

  ECN is a separate congestion-signaling mechanism that can be used with AQM. An endpoint first marks packets as ECN-capable with an ECT codepoint. Instead of dropping such a packet, a router marks the IP header with the Congestion Experienced (CE) codepoint and forwards it. The receiver reports the indication with the ECE flag in a TCP acknowledgment. The sender reduces cwnd and ssthresh as it would for a congestion loss, while the marked packet does not need retransmission solely because of the mark.

Congestion control therefore combines end-system algorithms with queue management and explicit signals from the network. TCP adjusts its sending window from feedback, while routers can control queue growth through AQM or mark ECN-capable traffic. Together these mechanisms limit queue growth, loss, and unfair use of shared capacity on shared paths.