TCP Congestion Control

The Congestion Window (CWND)

Regardless of the algorithm, TCP uses a Congestion Window to limit how many packets can be 'in flight'—sent but not yet acknowledged.

The Receive Window (RWND) is the receiver's buffer advert. In the original 1981 TCP specification (RFC 793), this was limited to 16 bits (64 KB). In modern high-speed networks, this is a massive bottleneck.

1. Window Scaling Math ($2^n$)

To overcome the 64 KB limit, RFC 1323 introduced Window Scaling. It uses a bit shift count in the TCP options during the 3-way handshake.

With a maximum Scale Factor of 14, the TCP window can grow up to 1 GB ($65,535 \times 2^{14} \approx 1,073,725,440$ bytes). This is essential for filling the Bandwidth-Delay Product (BDP) on long-haul fiber links.

The difference between congestion algorithms lies in how they grow and shrink the Congestion Window (CWND) in response to the network's feedback loop.

2. CUBIC: Growing until Failure

CUBIC is a loss-based algorithm and the current default in Linux. It increases the window according to a cubic function of the time since the last congestion event ($t$).

• $W_{max}$: The window size before the last reduction.
• $K$: The time period it takes to reach $W_{max}$ again.
• $C$: A scaling constant (typically 0.4).

2.1. The Math of $K$ (Convergence Time)

CUBIC calculates the time $K$ it should take to reach the previous $W_{max}$ using the following derivation:

Where $\beta$ is the multiplicative decrease factor (typically 0.7 or 0.8 in modern kernels). This ensures that the time to recover from a drop is independent of the RTT, preventing the "RTT Fairness" problem where short-latency flows starve long-latency flows.

3. BBR: Bottleneck Bandwidth & RTT

Developed by Google, BBR is model-based. Unlike CUBIC, which reacts to loss, BBR attempts to find the Kleinrock optimal operating point where the delivery rate is maximized and the round-trip time is minimized.

BBR iterates through four states to maintain its model:

• Startup: Exponentially increases pacing rate until delivery rate plateaus (similar to Slow Start).
• Drain: Lowers the rate to drain any queues built up during Startup.
• ProbeBW: Most steady-state time. It cycles its gain (e.g., 1.25, 0.75, 1.0) to probe for bandwidth while clearing potential queues.
• ProbeRTT: Every 10 seconds, it reduces the window to just 4 packets to measure the true physical $RTT_{min}$.

4. Loss Recovery Forensics: Beyond Duplicate ACKs

Modern TCP stacks no longer rely solely on the simple "3 Duplicate ACKs" rule from the 1980s. Two critical technologies have revolutionized how TCP handles packet loss in high-stakes environments:

5. Kernel-Level Tuning: The Data Plane

If you are engineering for 100G or 400G NICs, the default Linux kernel settings will throttle you. You must tune the Socket Buffer Memory limits to accommodate the massive BDP.

6. Case Study: The "LFN" Satellite Challenge

Consider a LEO satellite link (e.g., Starlink) with a bandwidth of 200 Mbps and an RTT of 40ms.

• BDP Calculation: $200 \times 10^6 \times 0.040 / 8 = 1,000,000$ bytes (1 MB).
• The Forensic Problem: Rain fade causes a burst loss of 1%.
• CUBIC Reaction: Detects loss, cuts window by 20%, takes $K$ seconds to recover. Throughput drops to $\approx 40$ Mbps.
• BBR Reaction: Detects that RTT is stable and delivery rate is unchanged by the burst. It maintains the 200 Mbps pacing rate.

In this forensic scenario, BBR provides a **5x throughput advantage** by correctly identifying that the loss was "stochastic" (noise) rather than "structural" (congestion).

Optimization is not a one-size-fits-all process. Understanding the physical constraints of your path—latency, jitter, and buffer depth—is the first step toward effective transport layer engineering.

Choosing the right congestion algorithm is a critical step in Reliability Engineering for long-distance data centers.