There's an ancient legend about the inventor of chess presenting his game to a king. When offered any reward, the inventor asked for something seemingly modest: one grain of rice on the first square, two on the second, four on the third, and so on—doubling for each of the 64 squares.

The king initially laughed at this modest request. By the end of the calculation, he owed 18,446,744,073,709,551,615 grains—far exceeding all the rice in history.

This same mathematical principle powers TCP slow start. The exponential growth of the congestion window isn't just a convenient choice—it's a precisely calibrated mechanism that balances aggressive capacity discovery against catastrophic network overload. Understanding exponential growth deeply reveals why slow start works as well as it does.

This page dissects the mathematics, visualizes the behavior, analyzes the theoretical foundations, and explores how exponential growth manifests in real networks. By the end, you'll understand why doubling is the optimal growth rate for network probing.

Before analyzing slow start's growth, let's establish the mathematical framework:

The basic recurrence:

Let cwnd(n) represent the congestion window after n round-trip times. During slow start:

cwnd(n) = cwnd(n-1) × 2

Within each RTT, the sender transmits cwnd segments and receives cwnd acknowledgments. Since each ACK increases cwnd by 1 MSS, the total increase per RTT equals the window size itself—hence the doubling.

The closed-form solution:

Solving this recurrence relation yields:

cwnd(n) = cwnd(0) × 2^n

Where cwnd(0) is the initial window (typically 10 MSS in modern implementations).

Growth rate analysis:

The growth factor per RTT is exactly 2 (or 100% increase). Expressed logarithmically:

log₂(cwnd(n)) = log₂(cwnd(0)) + n

This means the number of RTTs required to reach any target window size T is:

n = log₂(T / cwnd(0)) = log₂(T) - log₂(cwnd(0))

The choice to double cwnd per RTT isn't arbitrary. It represents a multiplicative probe that minimizes worst-case wasted bandwidth while maintaining rapid discovery.

The multiplicative probe principle:

Imagine you're searching for an unknown capacity C somewhere between 1 and 1,000,000 segments. You probe by sending increasingly larger bursts until you find C (through packet loss).

With any multiplicative factor k > 1:

• After n probes, your probe size is k^n
• When you finally exceed C, your probe size is between C and k×C

The waste analysis:

The "waste" occurs in the final probe—you send up to k×C data but only C can get through. The excess (k-1)C is lost to congestion.

Waste fraction = (k-1)C / (total probed) = (k-1)C / C = (k-1)

For k=2 (doubling), maximum waste is 50%. For k=3 (tripling), maximum waste is 67%. For k=1.5, maximum waste is 33% but requires more probes.

The k=2 equilibrium:

Doubling strikes a balance optimized for real network conditions:

1. Time-to-capacity: With k=2, reaching 10 Gbps from 14 KB takes ~20 RTTs. At 50ms RTT, that's 1 second. Tripling saves only ~7 RTTs (0.35 seconds) but increases waste by 50%.

2. Buffer sizing: Network buffers are typically sized to hold about one bandwidth-delay product. Doubling means exceeding by 1× BDP, which stressed buffers can usually absorb. Tripling means exceeding by 2× BDP, which may cause multiple drops.

3. Fairness: Multiple connections entering slow start simultaneously will interleave their probes. Doubling provides predictable behavior that allows fair sharing as flows complete slow start at similar rates.

Mathematical proof of optimality:

For a given number of probes n and starting value W₀:

• With factor k, final probe size = W₀ × k^n
• Waste bounded by (k-1) × [capacity reached]

Minimizing total RTTs while bounding waste to 50% requires k ≤ 2. Maximizing k (speed) subject to this constraint gives k = 2.

This is why Van Jacobson's original choice of doubling has proven robust for 35+ years.

Understanding how exponential growth appears visually helps diagnose real network behavior. Let's examine several perspectives:

Linear-scale graphs:

When plotting cwnd vs time on a linear scale, slow start produces the characteristic "hockey stick" shape:

• The curve appears nearly flat initially (changes from 10 to 20 are visually small)
• Then it appears to explode upward as the window grows large
• The inflection point where growth becomes visible is deceptive—the rate of increase has been constant all along

Logarithmic-scale graphs:

Plotting cwnd on a log scale reveals the true nature:

• Slow start appears as a straight line with slope log₂(e) per RTT
• Deviations from this line indicate non-slow-start behavior
• The transition to congestion avoidance (linear growth) appears as a curve bending right

Packet-level visualization:

Viewing individual packets on a time-sequence plot shows:

• Clusters of segments sent, followed by gaps waiting for ACKs
• Each cluster is roughly twice the previous
• ACKs arrive in spacing determined by the bottleneck link's serialization delay

Expected cwnd trajectory example:

For a 100 Mbps path with 50ms RTT (BDP = 625KB ≈ 428 segments at 1460 MSS):

Time (ms)   cwnd     State
───────────────────────────────
0           10       Slow start begins
50          20       First ACKs received
100         40       Doubling continues
150         80       Approaching capacity
200         160      Still doubling
250         320      Almost at BDP
300         640      Exceeds BDP!
300+        ~428     Loss occurs, cwnd adjusts

Notice that cwnd exceeds the BDP (428 segments) at RTT 6. At this point, the network cannot forward packets as fast as they arrive, queues build, and eventually loss occurs. This is the expected termination of slow start—the protocol successfully discovered the path capacity.

The effective speed of slow start's exponential growth depends on network parameters. Let's analyze how RTT and bandwidth affect the ramp-up:

RTT determines wall-clock growth speed:

Since cwnd doubles per RTT, the actual time to reach a target capacity is:

Time to capacity = RTT × log₂(Target / Initial)

For the same target:

• 10ms RTT: 200ms to reach 1 Gbps-worth of window
• 50ms RTT: 1000ms to reach the same
• 200ms RTT (satellite): 4000ms to reach the same

This has profound implications for high-latency networks.

Bandwidth determines target window size:

Higher bandwidth links require larger cwnd to fully utilize. The number of doublings increases logarithmically:

• 10 Mbps at 50ms RTT: BDP = 62.5 KB, ~5 doublings from IW=10
• 1 Gbps at 50ms RTT: BDP = 6.25 MB, ~12 doublings from IW=10
• 100 Gbps at 50ms RTT: BDP = 625 MB, ~19 doublings from IW=10

Combined effect:

The time to fully utilize a link is:

Time = RTT × log₂(BDP / Initial_cwnd)
Time = RTT × log₂(Bandwidth × RTT / Initial_cwnd)

Interestingly, this means higher RTT actually speeds up slow start in terms of bytes per RTT (since more bytes can be in flight), but slows it down in wall-clock time (since each doubling takes longer).

Practical implications:

The exponential growth formula assumes one ACK per segment sent. In reality, ACK behavior varies significantly and affects growth rate:

Delayed ACKs:

Most TCP implementations use "delayed ACKs" (RFC 1122): instead of ACKing every segment immediately, the receiver waits up to 200ms or until a second segment arrives. This means:

• If sender transmits 10 segments, receiver might return only 5 ACKs
• Each ACK still increments cwnd by 1 MSS
• Net result: cwnd grows by 5 instead of 10 per RTT

With delayed ACKs, growth factor becomes approximately 1.5× per RTT instead of 2×.

Appropriate Byte Counting (ABC):

RFC 3465 introduced Appropriate Byte Counting as a countermeasure. Instead of incrementing cwnd by 1 MSS per ACK, the sender increments based on bytes acknowledged:

cwnd += min(N, SMSS)

where N is the number of previously unacknowledged bytes covered by this ACK. This restores the intended doubling behavior even with delayed ACKs.

ACK Division Attacks:

Before ABC was widely deployed, malicious receivers could exploit ACK-based cwnd growth:

1. Receiver splits one segment's ACK into multiple ACKs ("ACK splitting")
2. Sender increments cwnd once per ACK
3. cwnd grows faster than intended
4. Result: receiver induces sender to overwhelm network

ABC and later defenses (limiting cwnd increment per ACK) mitigated this attack.

Modern behavior:

Most current TCP stacks use some form of byte counting or hybrid approach:

• Linux: Uses a variant of ABC with limits
• Windows: Bounds cwnd increment per ACK
• FreeBSD: Configurable byte counting

The net effect is that modern implementations achieve close to the theoretical 2× growth per RTT regardless of receiver ACK behavior.

To appreciate why exponential growth (specifically doubling) is optimal, let's compare it against alternative strategies:

Strategy 1: Linear Growth (Additive Increase)

Add one MSS per RTT regardless of ACKs:

• cwnd(n) = cwnd(0) + n × MSS
• Time to reach capacity C: O(C) RTTs
• Waste at overshoot: 1 MSS (minimal)

Strategy 2: Quadratic Growth

Double the increment each RTT:

• cwnd increase per RTT: 2^n
• Time to reach capacity C: O(sqrt(C)) RTTs
• Growth is polynomial, not exponential in cwnd itself

Strategy 3: Multiplicative Growth (Slow Start)

Multiply cwnd by k each RTT:

• cwnd(n) = cwnd(0) × k^n
• Time to reach capacity C: O(log C) RTTs
• Waste at overshoot: (k-1) × C

The Goldilocks principle:

Exponential growth with k=2 represents the "just right" balance:

1. Fast enough — 17-20 RTTs to reach almost any practical capacity
2. Safe enough — At most 50% overshoot limits damage
3. Simple enough — Implemented as cwnd += MSS per ACK
4. Fair enough — Concurrent slow starts converge to equal rates

Why not mix strategies?

Some protocols use hybrid approaches (e.g., slow start then linear). The transition point (ssthresh) captures where exponential growth becomes too risky. This hybrid is exactly what TCP does—slow start finds the rough capacity, then congestion avoidance fine-tunes around it.

Pure exponential (slow start with no ssthresh) would repeatedly overshoot, causing periodic heavy losses. Pure linear (no slow start) would waste link capacity for minutes on high-speed connections. The combination leverages each strategy's strengths.

Let's examine how exponential growth manifests in practical scenarios:

Example 1: Loading a web page

A user in New York requests a page from a server in San Francisco (RTT ≈ 70ms). The HTML document is 100KB.

Time 0ms:    Connection established, cwnd=10 (14.6KB)
Time 0ms:    First 10 segments sent (14.6KB)
Time 70ms:   ACKs arrive, cwnd=20 (29.2KB), next 20 segments sent
Time 140ms:  ACKs arrive, cwnd=40 (58.4KB), next 40 segments sent
Time 210ms:  All 100KB sent and acknowledged
Total time: ~210ms (3 RTTs)

Without slow start (linear growth from 1):

• Would need ~68 RTTs to send 100KB
• Total time: ~4.8 seconds

Example 2: Large file download

Downloading a 1GB file over a 100 Mbps connection (RTT 30ms, BDP = 375KB ≈ 257 segments).

RTT 0: cwnd=10, throughput≈3.9 Mbps (10×1460×8/0.03)
RTT 1: cwnd=20, throughput≈7.8 Mbps
RTT 2: cwnd=40, throughput≈15.6 Mbps
RTT 3: cwnd=80, throughput≈31.1 Mbps
RTT 4: cwnd=160, throughput≈62.2 Mbps
RTT 5: cwnd=320, exceeds BDP, loss likely
RTT 6: cwnd stabilizes around 257, full 100 Mbps
Total ramp-up: ~180ms (6 RTTs)
Remaining transfer at full speed: 1GB/100Mbps ≈ 80 seconds
Slow start overhead: <0.3%

Example 3: Short API call

A microservice makes a request to another service (RTT 1ms, response 2KB).

Time 0ms:   cwnd=10 (14.6KB), request+response fits in one RTT
Time 1ms:   Response complete

With IW=10, the entire exchange fits in the initial window. Slow start never actually "starts"—it's effectively bypassed. This is why modern IW=10 dramatically helps microservices architectures.

Example 4: Video streaming

Streaming 4K video at 25 Mbps (RTT 50ms).

RTT 0: cwnd=10, throughput≈2.3 Mbps
RTT 1: cwnd=20, throughput≈4.7 Mbps
RTT 2: cwnd=40, throughput≈9.4 Mbps
RTT 3: cwnd=80, throughput≈18.7 Mbps
RTT 4: cwnd=160, throughput≈37.4 Mbps (exceeds 25 Mbps needed)
Time to sustainable rate: ~200ms

Video players buffer ahead to absorb this ramp-up time, typically keeping 2-10 seconds buffered.

We've deeply analyzed the exponential growth behavior of TCP slow start. Let's consolidate the key insights:

What's next:

Exponential growth cannot continue forever—at some point, it must stop to prevent repeated losses. The next page explores ssthresh (slow start threshold), the mechanism that captures network capacity estimates and controls when slow start yields to the more conservative congestion avoidance phase.