TCP Slow Start and Congestion Window Growth

29 Sep 2026 networkingperformance

TCP slow start is the phase in which a new TCP connection cautiously increases the amount of data it has in flight. It starts with a small congestion window, or cwnd, and expands that window as acknowledgements arrive—usually growing quickly until the network shows signs of overload.

The problem slow start solves

A sender cannot know in advance how much traffic a path can carry. The path may include a slow link, a busy router, or a queue that is already close to full. If a new connection immediately transmitted megabytes, it could fill those queues and cause packet loss for itself and other connections.

Older approaches often required a fixed sending rate or relied on the sender to guess a safe one. A guess that was too low wasted available bandwidth; a guess that was too high created congestion. Slow start lets TCP discover capacity from the network instead.

The name is slightly misleading: slow start grows exponentially, not linearly. It is “slow” compared with sending everything at once.

The windows that limit sending

TCP’s sender is constrained by two windows:

• The receiver window, or rwnd, is the amount of buffer space the receiving application has advertised.
• The congestion window, or cwnd, is the sender’s estimate of how much data the network can carry without excessive congestion.

The sender can have at most the smaller of these windows outstanding. “Outstanding” means sent but not yet confirmed by an acknowledgement.

An acknowledgement, or ACK, tells the sender which sequence number the receiver expects next. In normal operation, an ACK covering new data is also evidence that the data reached the receiver and that the path is currently making progress.

TCP measures cwnd in bytes, although explanations often express it in MSS, the maximum segment size: the largest TCP payload normally placed in one packet. If cwnd is 10 MSS, the sender may generally have about 10 segments in flight, subject also to rwnd.

How slow start grows the window

At the beginning of a connection, TCP sets cwnd to an initial window. Modern TCP implementations usually start with multiple segments, but the exact value depends on the implementation and protocol rules. The sender transmits up to that window, then waits for ACKs.

For each ACK covering new data, slow start increases cwnd by approximately one MSS. In simplified form:

on an ACK for new data:
    cwnd = cwnd + MSS

Suppose the initial window is 4 MSS and the receiver acknowledges each segment individually. After the first four segments are acknowledged, cwnd grows to roughly 8 MSS. During the next round of traffic, those eight acknowledgements grow it to roughly 16 MSS. One round-trip time, or RTT, is the time for data to travel to the receiver and for its acknowledgement to return, so cwnd approximately doubles each RTT during slow start.

That doubling is a consequence of ACK-driven growth, not a timer that blindly doubles the number. If fewer ACKs arrive because packets are delayed, lost, or the receiver uses delayed acknowledgements, the growth can differ. TCP implementations also use safeguards so that unusual ACK patterns cannot produce unlimited artificial growth.

This creates an ACK clock: arriving ACKs provide permission for the sender to put more data into the network. The sender’s burst pattern and the path’s RTT therefore affect how quickly the connection ramps up.

Leaving slow start

Slow start does not continue forever. TCP maintains a slow-start threshold, or ssthresh, which marks the approximate boundary between exponential growth and more cautious growth. When cwnd reaches that threshold, TCP normally enters congestion avoidance.

In congestion avoidance, each ACK increases cwnd by only a small amount—roughly enough for one additional MSS over a whole RTT. The result is approximately linear growth rather than doubling:

slow start:         cwnd grows by about one MSS per ACK
congestion avoidance: cwnd grows by about one MSS per RTT

The threshold is not a permanent measurement of the network. It is updated when TCP observes congestion, so later transmissions restart conservatively from what the connection learned.

What packet loss changes

Packet loss is a strong sign that the path could not carry the sender’s recent amount of traffic. TCP can infer loss in several ways. A retransmission timeout means an expected ACK did not arrive in time. Several duplicate ACKs—repeated acknowledgements for the same earlier sequence number—usually indicate that a later segment is missing while subsequent segments are still arriving.

The response depends on the signal:

• After a timeout, TCP retransmits the missing data, reduces cwnd substantially, and usually enters slow start again. The reduction is intentionally severe because the sender has lost evidence that the path is delivering traffic at all.
• After duplicate ACKs, TCP can often retransmit without waiting for a timer. This is called fast retransmit. Congestion-control algorithms commonly reduce cwnd substantially, but may retain a larger window than they would after a timeout while they recover.

The exact reduction depends on the congestion-control algorithm, such as Reno or a newer algorithm. The important point is that loss both triggers recovery of missing data and changes future sending: TCP lowers its estimate of safe capacity, then grows it again.

What an explicit congestion signal changes

Packet loss is a late signal: a queue may already have overflowed by the time a packet disappears. Explicit Congestion Notification, or ECN, lets a router mark a packet instead. The packet still reaches the receiver, but the receiver reports the mark to the sender in an ACK.

When the sender receives that congestion signal, it reduces its sending rate and cwnd according to its congestion-control algorithm, much as it would respond to detected loss. Because the packet was not necessarily lost, ECN can avoid some retransmissions while still warning the sender to stop increasing its window.

ECN must be supported and enabled by the endpoints and the intervening network. When it is not available, TCP relies mainly on loss and delay-related behavior.

In a performance incident, terms such as “slow start,” “cwnd,” “ssthresh,” “duplicate ACK,” or “ECN marked” describe this feedback loop. TCP is repeatedly testing the path: acknowledgements permit growth, while loss or an explicit congestion mark tells it that the recent growth went too far.