A surgeon performing microsurgery doesn't make sweeping gestures—each movement is measured in millimeters, precisely controlled, with full awareness of the consequences of even slight errors. The stakes demand patience over speed.

TCP's linear growth during congestion avoidance embodies this same philosophy. After the rapid capacity discovery of slow start, TCP shifts to incremental probing—adding exactly one segment per round-trip time. This seemingly slow approach is precisely what enables the Internet to remain stable while billions of connections compete for bandwidth.

This page provides a deep dive into linear growth: its mathematical foundations, its impact on throughput and recovery time, its role in network stability, and how it compares to alternative approaches. Understanding linear growth completes your knowledge of TCP's fundamental congestion control mechanisms.

Let's formally analyze the mathematics of TCP's linear growth during congestion avoidance. Unlike slow start's exponential behavior, linear growth has predictable, tractable properties.

The fundamental equation:

During congestion avoidance, the congestion window follows:

cwnd(t) = cwnd₀ + t × MSS

where:

• cwnd(t) = congestion window at time t (measured in RTTs)
• cwnd₀ = initial window when entering congestion avoidance
• MSS = Maximum Segment Size (typically 1460 bytes)
• t = number of RTTs since entering congestion avoidance

Comparison with exponential growth:

The key insight:

The asymptotic difference is profound:

• Linear: O(n) to reach window size n
• Exponential: O(log n) to reach window size n

For large windows, this difference spans orders of magnitude. A 10 Gbps link with 100ms RTT has a BDP of ~85,000 segments. Linear growth from 1 segment would take 85,000 RTTs (2.4 hours!) while exponential would take only 17 RTTs (1.7 seconds).

Why TCP accepts this trade-off:

1. Congestion avoidance typically starts near the target, not from 1 segment
2. The risk of repeated losses from aggressive probing exceeds the cost of slow recovery
3. Linear growth ensures network stability through bounded per-RTT increase
4. Fair bandwidth sharing requires all flows to grow at the same rate

A critical concern with linear growth is recovery time after a congestion event. Let's analyze how long it takes to return to full capacity after various scenarios:

Scenario: Recovery after cwnd halving

After loss, cwnd is typically halved. With linear growth:

Pre-loss cwnd:  W (at capacity)
Post-loss cwnd: W/2 (halved)
Growth rate:    1 MSS per RTT
Recovery time:  (W - W/2) = W/2 RTTs

In other words: recovery time equals half the window size in segments.

Concrete examples:

The LFN (Long Fat Network) problem:

The table reveals a striking issue: high-capacity, high-latency networks have unacceptably long recovery times. A 10 Gbps transatlantic link takes over an hour to recover from a single loss event!

This is the primary motivation for TCP variants like CUBIC and BBR:

CUBIC's solution:

• Uses cubic function instead of linear
• Grows faster when far from previous peak
• Slows near the previous peak (where loss occurred)
• Recovery time: O(∛W) instead of O(W)

BBR's solution:

• Doesn't use loss-based congestion control
• Estimates bandwidth and maintains target rate
• Recovery is immediate (rate is recalculated, not rebuilt)

The fundamental trade-off:

Faster recovery means more aggressive probing, which risks causing more losses. Linear growth's slow recovery is the price of its stability guarantee.

Linear growth affects not just recovery time but also the average throughput a connection achieves. Let's analyze this relationship:

Average throughput during steady state:

In the classic sawtooth pattern, cwnd oscillates between W/2 and W (where W is the capacity-limited window). The average window is:

avg_cwnd = (W + W/2) / 2 = 3W/4

Average throughput:

avg_throughput = (3W/4) × MSS / RTT

This is 75% of the theoretical maximum—a 25% "tax" on efficiency due to the probing behavior.

Derivation of the 75% efficiency:

The cwnd follows a sawtooth:

1. Linear rise from W/2 to W over W/2 RTTs
2. Instantaneous drop to W/2
3. Repeat

The data transferred in one cycle:

Data = ∫(W/2 to W) cwnd d(RTT) = area under the sawtooth
     = (W + W/2)/2 × (W/2) = 3W²/8 segment-RTTs
     
time per cycle = W/2 RTTs

Average cwnd = (3W²/8) / (W/2) = 3W/4

The TCP throughput equation:

A famous result from network analysis gives TCP throughput as a function of loss rate:

Throughput ≈ (MSS × C) / (RTT × √p)

where:

• MSS = Maximum Segment Size
• C = constant (approximately 1.2 for standard TCP)
• RTT = Round Trip Time
• p = packet loss probability

Key insights from this equation:

1. Throughput is inversely proportional to RTT — High-latency links achieve lower throughput
2. Throughput is inversely proportional to √p — Higher loss rates severely impact performance
3. The MSS multiplier — Larger MSS improves throughput (up to path MTU)

Example calculation:

Link: 100 Mbps, 50ms RTT, 0.1% loss rate

Throughput = (1460 × 1.2) / (0.05 × √0.001)
           = 1752 / (0.05 × 0.0316)
           = 1752 / 0.00158
           = 1.1 Mbps (only 1.1% of capacity!)

This demonstrates how sensitive TCP is to loss. Even 0.1% loss reduces a 100 Mbps link to barely 1 Mbps!

Let's examine how linear growth manifests at the packet level, which is essential for understanding and debugging network behavior:

Per-ACK behavior:

During congestion avoidance, the cwnd update rule is:

cwnd = cwnd + MSS × MSS / cwnd

This adds a fractional MSS per ACK. For cwnd = 50 segments:

Increment = 1460 × 1460 / (50 × 1460)
          = 1460 / 50
          = 29.2 bytes per ACK
          
After 50 ACKs:
Total increment = 50 × 29.2 = 1460 bytes = 1 MSS

Practical implementation:

Some implementations avoid fractional bytes using a counter:

// Linux-style congestion avoidance
if (tp->snd_cwnd_cnt >= tp->snd_cwnd) {
    tp->snd_cwnd++;          // Integer increment
    tp->snd_cwnd_cnt = 0;
} else {
    tp->snd_cwnd_cnt++;
}

This counts ACKs and increments cwnd by 1 MSS when enough ACKs accumulate.

ACK clock effect:

The arrival rate of ACKs "clocks" the transmission of new segments. This creates a natural pacing:

Sender → Network → Receiver → ACKs back to Sender
           ↓ bottleneck spaces packets
                              ↓ ACKs arrive spaced out

If the bottleneck link serializes packets with gaps, ACKs will arrive with corresponding gaps. The sender transmits new segments as each ACK arrives, naturally pacing at the bottleneck rate.

Burst behavior in linear growth:

Unlike slow start (which creates growing bursts), congestion avoidance tends toward steady transmission:

Slow start RTT n:   |segment burst of 2ⁿ|............wait............|
Congestion avoid:   |steady stream: segment-gap-segment-gap-segment-gap|

This smoother pattern reduces queue oscillation and improves coexistence with other flows.

The choice of linear growth during congestion avoidance isn't just about individual connections—it's crucial for network-wide stability. Let's analyze why:

The stability requirement:

A stable network system must have a bounded response to perturbations. When N flows share a bottleneck:

Total traffic at time t = Σᵢ cwndᵢ(t)

For stability, perturbations (flows starting/ending, route changes) should decay rather than amplify.

Why exponential growth threatens stability:

With exponential growth during steady state:

• Flow adds 2×, 4×, 8× traffic on consecutive RTTs
• If many flows do this simultaneously: multiplicative explosion
• Aggregate traffic can exceed capacity by orders of magnitude
• Result: massive queue buildup, timeouts, global synchronization

Why linear growth ensures stability:

With linear growth:

• Each flow adds constant 1 MSS per RTT
• N flows add N × MSS per RTT
• Aggregate growth is bounded: O(N) per RTT
• Network can absorb this: buffer depth ~ BDP

Global synchronization prevention:

Linear growth helps prevent global synchronization, where many flows simultaneously experience loss and recover in lockstep:

Synchronized (bad):
  Time 1: All flows hit capacity, all drop
  Time 2: All flows halve
  Time 3: All flows grow linearly
  Time 4: All flows hit capacity together again
  → Periodic surges and crashes

Desynchronized (good):
  Flows enter/exit at different times
  Linear growth means flows grow at same rate but start from different points
  Losses spread over time as flows hit capacity individually
  → Smooth aggregate traffic

Random Early Detection (RED) reinforces this:

RED routers probabilistically drop packets before the queue fills. This desynchronizes flows by causing losses at different times for different flows. Combined with linear growth's gradual probing, RED creates smooth aggregate behavior.

Controlled system analysis:

From a control theory perspective, TCP congestion avoidance is a distributed feedback control system:

• Plant: The network queue
• Sensor: Loss detection
• Controller: AIMD algorithm
• Actuator: cwnd adjustment

Linear growth (additive increase) provides a bounded slew rate, preventing oscillations that faster controllers might cause.

While linear growth is the foundation, several alternatives have been developed to address its limitations on high-BDP networks:

CUBIC's Cubic Growth:

CUBIC (Linux default since 2006) uses a cubic function:

W(t) = C × (t - K)³ + Wmax
where K = ∛(Wmax × β / C)
      C = CUBIC constant (0.4 by default)
      Wmax = window size before last loss

This creates three growth regions:

1. Concave region (below Wmax): Fast recovery, growing faster than linear
2. Plateau (near Wmax): Slow, cautious probing
3. Convex region (above Wmax): Accelerating to find new capacity

High-Speed TCP (RFC 3649):

HSTCP adjusts the growth rate based on current cwnd:

Small cwnd: Normal linear growth (1 MSS/RTT)
Large cwnd: Faster growth (up to 1000× linear)

This addresses the recovery time issue on high-BDP networks while maintaining compatibility with standard TCP flows.

BBR's Departure from AIMD:

BBR (Bottleneck Bandwidth and RTT) fundamentally abandons loss-based congestion control:

Classic TCP: cwnd = f(loss events over time)
BBR:         pacing_rate = estimated_bandwidth
             cwnd = BDP + extra_for_variations

BBR doesn't "grow" linearly or otherwise—it estimates the path's characteristics and paces at the estimated rate. Recovery after loss is simply recalculating the estimate.

Why linear remains relevant:

Despite advanced alternatives:

1. Linear growth is the fallback when variants behave poorly
2. Many networks still use Reno-compatible algorithms
3. Fairness analysis and network modeling often assume linear
4. CUBIC includes a "TCP mode" that uses linear growth when appropriate
5. Understanding linear is prerequisite to understanding variants

Understanding linear growth helps diagnose real-world TCP performance issues. Here's how to apply this knowledge:

Recognizing linear growth in practice:

Use Linux's ss command to observe cwnd progression:

# Watch cwnd changes over time
watch -n 0.1 'ss -ti dst example.com'

# Output includes:
# cubic wscale:8,7 rto:220 rtt:109.375/54.688 ...
# ato:40 mss:1460 pmtu:1500 rcvmss:1460 ...
# cwnd:42 ssthresh:36 bytes_sent:1234567 ...

During congestion avoidance:

• cwnd should increase by ~1 per RTT
• ssthresh should be stable (only changes on loss)
• If cwnd is growing faster, you're in slow start
• If cwnd is stuck, you're application-limited or receiver-limited

Common issues related to linear growth:

Issue 1: Throughput stuck at low value

Symptom: Connection never reaches expected throughput.

Diagnosis:

# Check cwnd vs ssthresh
ss -ti | grep -E 'cwnd|ssthresh'

# If cwnd << ssthresh: Still in slow start, or...
# If cwnd ≈ ssthresh: ssthresh is too low (from past loss)
# If cwnd limited by rwnd: Receiver is bottleneck

Fix: Clear cached metrics, increase receiver buffers, or debug past loss events.

Issue 2: Very long recovery times

Symptom: After brief congestion, throughput stays low for minutes.

Diagnosis: Calculate expected recovery time = (old_cwnd - new_cwnd) × RTT

Fix: Switch to CUBIC or BBR for high-BDP networks.

Issue 3: Sawtooth amplitude too large

Symptom: Throughput oscillates wildly between high and very low.

Diagnosis: May indicate buffer bloat (large buffers delay congestion signal) or synchronized losses.

Fix: Enable ECN, reduce buffer sizes, or deploy AQM (RED, CoDel).

We've completed our deep exploration of linear growth during TCP congestion avoidance. Let's consolidate the key insights:

Module Complete!

You have now mastered the fundamentals of TCP slow start and congestion avoidance—the algorithms that prevent the Internet from collapsing under its own traffic. You understand:

• Slow start: Exponential discovery of network capacity
• ssthresh: The memory of past congestion events
• Congestion avoidance: Conservative linear probing
• Linear growth: The mathematical and practical implications

This knowledge forms the foundation for understanding advanced TCP variants, diagnosing network performance issues, and designing systems that work efficiently at scale.