Slow Start & Congestion Avoidance

In October 1986, the Internet nearly collapsed. Network throughput plummeted to barely 100 bits per second—a catastrophic 1000-fold reduction from normal capacity. The culprit wasn't hardware failure or malicious attack; it was congestion collapse, a phenomenon where networks become so overwhelmed that useful throughput approaches zero even as traffic demand soars.

This crisis forced Van Jacobson, a researcher at Lawrence Berkeley Laboratory, to fundamentally rethink how TCP connections should behave when joining a network. His solution, published in his landmark 1988 paper "Congestion Avoidance and Control," introduced slow start—arguably the most important algorithm in modern networking.

Despite its name, slow start isn't actually slow. It's a carefully engineered mechanism that allows new TCP connections to rapidly discover available network capacity without overwhelming intermediate routers. Understanding slow start is essential for any engineer working with networked systems, as it directly impacts application performance, server scalability, and network stability.

Before understanding slow start, we must first understand the problem it solves. Consider what happens when a new TCP connection starts transmitting data without any awareness of network conditions:

The naive approach:

Imagine a sender with a 1 Gbps connection to its local switch. Without congestion control, this sender might immediately begin transmitting at full speed—up to 1 million packets per second. But the path to the receiver might traverse dozens of routers, each with different capacities. A core router might handle hundreds of gigabits per second, while an edge router serving a residential connection might only handle 100 Mbps.

What happens next is predictable and devastating:

The core insight:

The fundamental problem is that a sender has no inherent knowledge of the path's capacity or current load. The sender might be communicating with a server on a different continent, traversing undersea cables, satellite links, and networks in countries with varying infrastructure quality.

The sender needs a way to:

1. Discover the available bandwidth without causing congestion
2. Adapt when network conditions change
3. Cooperate with other connections sharing the same path

This is precisely what slow start achieves.

To implement slow start, TCP introduces a critical state variable called the congestion window (cwnd). This variable represents the sender's estimate of how many bytes (or segments) it can safely have "in flight" on the network at any given time.

The congestion window is entirely local to the sender. Unlike the receiver's advertised window (rwnd), which is communicated in TCP headers, cwnd exists only in the sender's TCP stack. The receiver has no visibility into the sender's cwnd value.

The effective sending rate:

The actual amount of data a sender can transmit is constrained by both windows:

Effective Window = min(cwnd, rwnd)

This means the sender cannot exceed either:

• The congestion window (network capacity estimate)
• The receiver's advertised window (receiver buffer capacity)

Why two windows?

These two windows address fundamentally different constraints:

• rwnd prevents the sender from overwhelming the receiver's ability to buffer and process incoming data
• cwnd prevents the sender from overwhelming the network's ability to transport data

A receiver might have plenty of buffer space (large rwnd), but the network path might be constrained (small cwnd). Conversely, the network might have abundant capacity, but the receiver might be slow at processing data.

Modern initial cwnd values:

Historically, TCP started with cwnd = 1 segment (typically 536 or 1460 bytes). This was extremely conservative and penalized high-latency connections significantly.

Modern implementations (since RFC 6928, adopted around 2013) use an initial window of 10 segments (~14,600 bytes with standard MSS). This change alone improved web page load times by 10-15% for typical browsing scenarios by allowing more data to be transmitted before the first RTT completes.

The slow start algorithm operates with elegant simplicity, yet produces powerful emergent behavior. The core rule can be stated in one sentence:

For each acknowledgment received, increase cwnd by one Maximum Segment Size (MSS).

While this rule appears to produce linear growth (one ACK = one segment increase), the actual effect is exponential. Here's why:

Step-by-step example (initial cwnd = 1 MSS):

The mathematical pattern:

After n round-trip times, the congestion window is:

cwnd = initial_cwnd × 2^n

This is exponential growth—the window doubles every RTT. Starting from 1 MSS:

• After 1 RTT: 2 MSS
• After 2 RTTs: 4 MSS
• After 10 RTTs: 1,024 MSS (~1.5 MB)
• After 20 RTTs: 1,048,576 MSS (~1.5 GB)

This exponential growth is why slow start isn't actually slow—it's remarkably fast at finding available capacity. A connection can grow from 1 segment to utilizing a 10 Gbps link in roughly 24 RTTs, which might be just 2-3 seconds even with moderate latency.

The pseudocode implementation:

Here's how slow start is typically implemented in a TCP stack:

The choice of exponential growth in slow start isn't arbitrary—it represents an optimal balance between probing speed and congestion risk. Let's analyze why this matters:

The probing dilemma:

A new connection faces a fundamental uncertainty: the network might have 1 Kbps available or 10 Gbps available. The difference spans seven orders of magnitude. Any probing algorithm must be able to discover this capacity efficiently while avoiding catastrophic over-injection.

Why not linear growth?

With linear growth (adding one segment per RTT), reaching a 10 Gbps capacity from a standing start would take thousands of RTTs—potentially minutes. For short-lived connections (like HTTP requests), linear growth would mean the connection terminates before ever discovering available capacity.

Why not immediate maximum rate?

Sending at maximum rate immediately is exactly what caused the 1986 congestion collapse. The sender has no information about path capacity and could inject thousands of packets into buffers that can only hold dozens.

The mathematical elegance:

Exponential growth has a crucial property: the amount of "wasted" transmission when you overshoot is bounded.

When slow start continues until packet loss occurs, the sender has pushed cwnd to approximately 2× the path capacity (since it doubled from a working value to a failing one). This means at most half the transmitted data in the final RTT is wasted—a constant fraction regardless of the path's actual capacity.

This is fundamentally better than linear probing, where overshooting by even one segment could represent a tiny percentage (wasting little but taking forever) or aggressive initial transmission, where overshooting could waste thousands of segments (immediate but catastrophic).

Real-world impact:

For a 100 Mbps path with 50ms RTT (BDP = 625 KB):

• Linear growth from 1 MSS: ~428 RTTs = ~21 seconds to utilize fully
• Exponential growth from 1 MSS: ~9 RTTs = ~450ms to utilize fully

The difference is dramatic and directly affects every TCP connection's performance.

Understanding how slow start manifests in real network traces is essential for diagnosing performance issues. Let's examine what slow start looks like in practice:

Observing slow start with packet captures:

When you capture TCP traffic (using tools like Wireshark or tcpdump), slow start has a distinctive pattern:

Key observations in traces:

1. Clustered transmissions — Segments are sent in bursts equal to cwnd, then the sender waits for ACKs

2. Burst doubling — Each round of ACKs enables double the previous transmission burst

3. ACK clocking — The arrival rate of ACKs "clocks" the transmission of new data

4. RTT visibility — The spacing between clusters reveals round-trip time

Common diagnostic scenarios:

Slow start doesn't continue indefinitely—exponential growth must eventually stop. There are three conditions that terminate slow start:

Termination Condition 1: Packet Loss

The most common termination is packet loss. When a segment is lost (detected by timeout or duplicate ACKs), it indicates the network cannot handle the current transmission rate. In classic TCP:

• The ssthresh is set to half the current cwnd
• cwnd is reset to 1 MSS (on timeout) or reduced (on fast retransmit)
• Slow start may resume until cwnd reaches the new ssthresh

Termination Condition 2: ssthresh Reached

If the sender has prior knowledge (from an earlier loss), the ssthresh variable stores an estimate of the network's capacity. When cwnd reaches ssthresh, TCP transitions from slow start to congestion avoidance (linear growth). This prevents the aggressive exponential growth from inevitably overshooting.

Termination Condition 3: Receiver Window Limit

If the receiver's advertised window (rwnd) is smaller than cwnd, the sender is limited by the receiver, not the network. Slow start effectively pauses—further cwnd increases don't translate to additional transmissions.

The interplay of termination conditions:

In practice, these conditions interact:

1. A new connection starts with a very high ssthresh (often 65535 or "infinity"). Slow start continues until loss occurs, which sets ssthresh to a reasonable estimate.

2. After recovery from loss, slow start resumes but only until cwnd reaches the new ssthresh. This prevents repeating the exact same overshot that caused the original loss.

3. Once in congestion avoidance (cwnd ≥ ssthresh), the connection probes for additional capacity linearly, which is far less likely to cause loss.

This adaptive behavior means TCP "learns" about the path over time. Initial connections may experience loss during slow start, but subsequent data transfers on the same connection benefit from the learned ssthresh value.

The original slow start algorithm from 1988 has been refined considerably. Modern TCP implementations incorporate several enhancements:

RFC 6928: Initial Window Increase (2013)

The most significant change increased the initial window from 1-4 segments to 10 segments. This change alone:

• Reduced page load times by 10-15% for average web pages
• Allowed typical HTTP responses to begin transferring meaningful content immediately
• Reduced the number of RTTs needed before useful throughput

HyStart (Hybrid Slow Start)

Developed for CUBIC TCP (Linux default), HyStart attempts to detect when slow start is approaching capacity before packet loss occurs. It monitors:

• Delay increase — If RTT samples during slow start show increasing delay, it suggests buffer filling
• ACK train length — If ACKs become more spaced out, it indicates growing queues

When HyStart detects these signals, it exits slow start early, avoiding the packet loss that would otherwise reduce cwnd.

Pacing during slow start:

Modern kernels (Linux 4.13+) can pace segments during slow start rather than sending bursts. Instead of transmitting 10 segments back-to-back when the window allows, the sender spaces them across the RTT estimate. This:

• Reduces burst-induced congestion
• Smooths queue occupancy at intermediate routers
• Improves coexistence with other traffic

RACK-TLP (Recent ACK and Tail Loss Probe):

Modern loss detection uses timing information rather than just duplicate ACK counts. During slow start, this means:

• Faster loss detection
• More accurate ssthresh estimation
• Reduced unnecessary retransmits

These enhancements preserve the core slow start principle—exponential probing with cwnd—while addressing practical limitations discovered through decades of operational experience.

We've thoroughly explored slow start—the mechanism that saved the Internet from congestion collapse and continues to enable reliable high-speed data transfer. Let's consolidate the key insights:

What's next:

Now that we understand the slow start phase itself, the next page dives deeper into the exponential growth pattern—examining its mathematical properties, visualizing its behavior, and analyzing why this specific growth rate represents an optimal tradeoff between speed and safety.