1 Fundamental concepts

1.1 Definition and purpose

A congestion window, usually written as cwnd, is a sender-side limit on the amount of unacknowledged data that may be in transit on a network path. It is a central control variable in transport protocols such as TCP, where it helps regulate sending rate in response to network conditions. By adjusting this limit dynamically, the sender can avoid injecting more traffic than the path can carry efficiently.

1.2 Role in network flow control

Despite its name, the congestion window is not the same as end-to-end flow control. Its main function is to respond to congestion in the network rather than to the application or receiver. The sender uses cwnd to pace transmission so that routers, links, and queues are less likely to become overloaded. In this way, it supports smoother delivery and reduces the likelihood of loss caused by excessive load.

1.3 Relationship to acknowledgments

Acknowledgments provide the feedback that drives congestion window changes. When packets are acknowledged in a timely manner, the sender usually interprets this as a sign that the path can support more traffic and may increase cwnd. If acknowledgments arrive slowly, stop arriving, or are accompanied by indications of loss, the sender typically reduces cwnd. This feedback loop makes the window adaptive rather than fixed.

1.4 Difference from receive window

The congestion window should be distinguished from the receive window, often abbreviated rwnd. The receive window is advertised by the receiver and reflects how much buffer space is available on that end of the connection. By contrast, cwnd reflects the sender’s estimate of network capacity. The actual amount of data a sender may transmit is commonly limited by the smaller of these two windows.

2 Operation

2.1 Window growth

The congestion window generally grows when the network appears to be handling traffic successfully. Growth is usually gradual at first, then more controlled once the sender reaches a higher sending rate. This behavior is designed to probe for available capacity without causing abrupt overload.

2.1.1 Slow start

Slow start is an initial phase in which cwnd increases rapidly, often roughly doubling over each round-trip time when acknowledgments arrive normally. The name is somewhat misleading, since the growth can be aggressive. Its purpose is to discover available bandwidth quickly after a connection begins or after the sender has recovered from a major reduction in sending rate.

2.1.2 Congestion avoidance

After slow start, the sender typically enters congestion avoidance. In this phase, cwnd increases more conservatively, often by a small amount per acknowledgment sequence. The goal is to approach available capacity while minimizing the chance of persistent queue buildup or packet loss. This stage produces a steadier sending pattern than slow start.

2.2 Window reduction

When signs of congestion appear, the sender lowers cwnd to reduce pressure on the path. A decrease in the window acts as a corrective measure, allowing queues to drain and helping the network return to stable operation. The size of the reduction depends on the protocol and the severity of the event.

2.2.1 Packet loss response

Packet loss is commonly treated as a congestion signal in classic TCP behavior. When loss is detected through duplicate acknowledgments or other mechanisms, cwnd is usually reduced significantly. This response reflects the assumption that the network may be dropping packets because offered load exceeds capacity.

2.2.2 Timeout response

A retransmission timeout is often interpreted as a stronger sign of trouble than a simple duplicate acknowledgment pattern. In many implementations, a timeout causes cwnd to fall to a much smaller value, sometimes near the starting point. This conservative reset helps the sender re-enter the network more cautiously after a period of uncertainty.

2.3 In-flight data limits

The congestion window limits the number of bytes or segments that may remain unacknowledged at one time. If cwnd is small, the sender must wait for acknowledgments before sending more data. If cwnd is large, more data can be kept in flight, which may improve throughput when the path can support it. The effective transmission limit is therefore shaped by both cwnd and receiver-side constraints.

3 Congestion control algorithms

3.1 TCP Reno

TCP Reno is a classic congestion control approach that combines slow start, congestion avoidance, and recovery behavior based on loss detection. It is known for reducing cwnd in response to congestion signals and for using duplicate acknowledgments to infer certain losses. Reno helped establish the general window-based model used in many later systems.

3.2 TCP New Reno

TCP New Reno refines Reno’s loss recovery behavior, especially when multiple packets are lost within one window of data. It improves how cwnd and retransmissions are handled during partial acknowledgments. This makes recovery more robust in some loss patterns while preserving the basic window-control framework.

3.3 TCP Cubic

TCP Cubic uses a cubic growth function rather than the more traditional linear increase of congestion avoidance. It is designed to perform well on high-bandwidth, long-delay paths, where a more aggressive search for available capacity can be useful. Its cwnd growth pattern is shaped to recover faster after loss while still maintaining overall congestion control.

3.4 TCP BBR

TCP BBR takes a different approach by estimating bottleneck bandwidth and round-trip propagation delay rather than relying primarily on loss as a signal. Its congestion window is still important, but it is used within a model-based control scheme. BBR aims to send at a rate that matches the path’s delivery capacity while keeping queues relatively small.

4 Mathematical and implementation aspects

4.1 Window size measurement

Congestion window size is usually measured in bytes, although some descriptions use segments or packets for simplicity. Implementations often maintain cwnd in a fine-grained internal format and then convert it to a packet count when deciding whether to transmit. This allows more precise control across different segment sizes and path conditions.

4.2 Units and scaling

Because packet sizes can vary, cwnd may be scaled in relation to the maximum segment size, or MSS. The internal representation must account for the fact that a window of one segment on one path may correspond to a different number of bytes on another. Accurate scaling helps the protocol behave consistently across heterogeneous networks.

4.3 State variables in transport stacks

Transport implementations maintain several state variables related to congestion control, including the current cwnd, slow-start threshold, and counts of data in flight. These values are updated as acknowledgments arrive and as loss or timeout events occur. The stack uses them to determine when more data can be sent and how aggressively the sender should proceed.

4.3.1 Sender-side tracking

The sender keeps track of how much data has been transmitted but not yet acknowledged. This accounting is essential for enforcing the congestion window. By comparing in-flight data against cwnd, the sender can decide whether to transmit immediately or wait for additional feedback.

4.3.2 Packet accounting

Packet accounting records the status of each segment or data block, including whether it has been sent, acknowledged, or retransmitted. Such bookkeeping supports correct window updates and loss recovery. It also helps prevent duplicate transmissions from causing misleading changes in the congestion-control state.

4.4 Interaction with segment size

The congestion window works alongside segment sizing to determine actual send capacity. A larger segment size means that a given cwnd may represent more bytes per packet but fewer packets overall. Conversely, smaller segments can increase the number of packets in flight for the same cwnd value. This interaction affects both throughput and overhead.

5 Performance effects

5.1 Throughput implications

A well-tuned congestion window can improve throughput by allowing enough data to remain in transit to keep the path busy. If cwnd is too small, the connection may underutilize available bandwidth. If it grows too large, the sender may create congestion and reduce overall efficiency.

5.2 Latency and queueing

When cwnd expands beyond the path’s immediate capacity, packets may accumulate in queues. This can increase latency even before loss occurs. A more moderate window can lower queueing delay, while an excessively cautious window may keep latency low but limit data delivery rate.

5.3 Fairness among flows

Congestion control aims to share network resources among concurrent flows. If several connections compete over the same path, their cwnd behavior influences how fairly bandwidth is divided. Protocol design often balances efficiency with fairness so that one flow does not consistently dominate others.

5.4 Sensitivity to path conditions

The best cwnd value depends on the characteristics of the network path, including delay, available bandwidth, and loss behavior. Long-delay paths may need larger windows to achieve good throughput, while unstable or lossy paths may require smaller ones. As conditions change, the adaptive nature of cwnd helps the sender adjust.

6 Practical considerations

6.1 Tuning and defaults

Most systems rely on built-in defaults and algorithmic adaptation rather than manual tuning. However, implementations may choose different initial windows, growth rules, or recovery strategies. These choices can influence connection startup speed and responsiveness under load.

6.2 Impact of high-bandwidth networks

On high-bandwidth networks, a small cwnd can become the main bottleneck, especially when the round-trip delay is also substantial. In such environments, the sender may need a relatively large window to keep the path fully utilized. Modern congestion-control designs often aim to scale more effectively in these settings.

Wireless links and other error-prone paths may produce loss that is not solely due to congestion. Since many algorithms treat loss as a congestion signal, cwnd may shrink even when the network is not truly overloaded. This can reduce throughput and make performance less predictable on such links.

6.4 Congestion window in modern transport protocols

Many modern transport protocols retain a congestion-window concept, even when they differ in details from classic TCP behavior. The specific rules for increasing or decreasing cwnd may vary substantially across protocols and implementations. Nonetheless, the underlying idea remains the same: limit in-flight data to match the path’s ability to carry it.

7.1 Bandwidth-delay product

The bandwidth-delay product is the amount of data that can fill a path between sender and receiver. It helps explain why a certain cwnd size may be needed to fully utilize a link. A window smaller than this product may leave capacity idle.

7.2 Flow control

Flow control is a mechanism that prevents a fast sender from overwhelming a slow receiver. It is receiver-driven and usually based on buffer availability. Congestion control, by contrast, protects the network path from overload.

7.3 Send window

The send window is the effective transmission limit used by the sender, often determined by combining cwnd and the receive window. It represents how much data may be outstanding at once. In practice, it is the smaller of the congestion and receive constraints.

7.4 Sliding window protocols

Sliding window protocols are communication methods in which multiple packets may be sent before acknowledgment arrives. The congestion window is one important element in these systems. As acknowledgments advance, the sending window “slides” forward, allowing new data to enter the network.