TCP Throughput & Mathis Formula Calculator

1. The Physics of TCP Throughput: Why Packet Loss Destroys High-Speed WANs

A persistent frustration encountered by network engineers and systems administrators is discovering that a multi-gigabit WAN link—such as a dedicated 10 Gbps transcontinental circuit or an enterprise cloud interconnect—delivers only a fraction of its rated capacity on single-stream bulk data transfers. Even when CPU utilization is negligible and interface error counters remain low, throughput often collapses to tens of megabits per second.

The root cause lies in the fundamental congestion control mechanics of the Transmission Control Protocol (TCP). Standard TCP implementations (such as TCP Reno, NewReno, and to a lesser extent CUBIC) operate under the Additive Increase Multiplicative Decrease (AIMD) principle. AIMD relies on a core assumption formulated in the 1980s by Van Jacobson: any packet loss is unambiguous evidence of network queue exhaustion and incipient congestion collapse.

Consequently, whenever a single packet is dropped in transit:

• Multiplicative Decrease: TCP immediately cuts its Congestion Window (cwnd) in half (or by 30% under CUBIC), instantly halving the transmission rate regardless of whether the drop was caused by a full router buffer or a transient bit error on an optical amplifier.
• Additive Increase: During the ensuing Congestion Avoidance phase, TCP cautiously probes for available bandwidth by incrementing cwnd by exactly one Maximum Segment Size (MSS) per Round-Trip Time (RTT).

On a low-latency local network (e.g., Intra-DC with an RTT of 0.5 ms), recovering from a halved window takes only a few dozen milliseconds. However, on a Long Fat Network (LFN)—such as an 80 ms transatlantic subsea circuit—a sender with a 50 Megabyte window requires hundreds of round trips (tens of seconds) to ramp back up to its pre-loss speed. If another packet drops during this recovery phase, the window is halved again, driving throughput into a perpetual downward spiral.

2. Derivation & Proof of the Mathis Formula (1997)

In their seminal 1997 paper published in ACM SIGCOMM Computer Communication Review—titled "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm"—Matthew Mathis, Jeffrey Semke, Jamshid Mahdavi, and Kevin Ott established the definitive mathematical relationship between packet loss, round-trip time, segment size, and steady-state TCP throughput.

Under idealized conditions where packet loss occurs randomly with probability p (and assuming Selective Acknowledgments prevent retransmission timeouts), a TCP Reno session exhibits a deterministic sawtooth window profile:

• Between consecutive loss events, the sender successfully transmits exactly 1 / p packets.
• Let W be the peak congestion window size (in packets) achieved immediately before a packet drop occurs.
• Upon detecting the drop via triple duplicate ACKs, the window drops to W / 2.
• The sender increases its window by 1 packet every RTT. The number of RTTs required to grow from W / 2 back to W is exactly W / 2 rounds.

The total number of packets transmitted during this single sawtooth cycle corresponds to the trapezoidal area under the window curve:

Equating the delivered packets to the expected loss interval (1 / p):

The average congestion window size (cwndavg) over the cycle is the midpoint:

Multiplying the average window by the Maximum Segment Size (MSS in bits) and dividing by the Round-Trip Time (RTT in seconds), while incorporating the empirical delayed acknowledgment factor (b = 2), yields the classical Mathis Formula:

3. Beyond Reno: CUBIC (RFC 8312) vs. Google BBR

To address the sluggish recovery of AIMD on high-speed carrier circuits, modern operating systems have evolved beyond classical Reno.

1. Linux TCP CUBIC (RFC 8312):

Standardized in RFC 8312 and serving as the default congestion control algorithm in Linux, Android, and macOS, CUBIC replaces Reno's linear window ramp with a cubic function of elapsed time since the last congestion event (t):

Because window growth is governed by physical clock time rather than RTT, CUBIC ramps up aggressively on high-latency circuits. Near the prior peak window (W_max), the cubic curve flattens out, stabilizing the connection to probe for bandwidth with minimal packet drop risk.

However, CUBIC is fundamentally a loss-based algorithm. When a packet drop occurs, CUBIC still interprets it as congestion and reduces its window by β = 20-30%. Consequently, on lossy wireless, cellular, or congested subsea circuits, CUBIC's throughput remains mathematically bounded by the loss rate.

2. Google BBR (Bottleneck Bandwidth and Round-Trip Propagation Time):

Developed by Google engineers Neal Cardwell, Yuchung Cheng, C. Stephen Gunn, Soheil Hassas Yeganeh, and Van Jacobson in 2016, BBR abandons loss-based heuristics entirely.

BBR posits that maximum throughput and minimum latency are achieved when the volume of in-flight data exactly equals the circuit's Bandwidth-Delay Product (BDP = BtlBw × RTprop). To discover these two physical limits without creating standing queues, BBR continuously measures:

• Bottleneck Bandwidth (BtlBw): The maximum delivery rate observed over a moving time window.
• Round-Trip Propagation Time (RTprop): The minimum physical round-trip delay measured over a 10-second window.

Crucially, BBR paces outgoing packets at exactly the measured bottleneck rate. It completely ignores random packet loss up to approximately 15-20%, attributing drops to physical link impairments rather than network congestion. On a transpacific link with 0.5% packet loss where Reno and CUBIC collapse to under 50 Mbps, BBR routinely sustains the full 10 Gbps line rate.

4. The PFTK Equation & Retransmission Timeouts (RTO)

While the Mathis formula accurately models TCP performance under moderate loss rates, it breaks down when packet loss exceeds 1% to 2%. Under severe loss conditions, TCP Selective Acknowledgments (SACK) fail because duplicate ACKs themselves are dropped. When the sender exhausts all duplicate ACKs without receiving feedback, it experiences an RTO (Retransmission Timeout).

During an RTO, the TCP connection completely halts, drops its congestion window to 1 MSS, and backs off exponentially (doubling the timeout interval: 1s, 2s, 4s, 8s...).

To capture this catastrophic collapse, Jitendra Padhye, Victor Firoiu, Don Towsley, and Jim Kurose published the PFTK Model in 1998:

where T₀ is the base retransmission timeout (typically 4 × RTT, with a minimum floor of 200 ms) and b is the delayed ACK factor (typically 2). Under pristine conditions (p → 0), the right-hand RTO term vanishes, and PFTK reduces precisely to the Mathis formula. When packet loss climbs above 2%, the polynomial 32 × p2 term causes throughput to plummet exponentially, reflecting real-world connection freezes.