Why a gigabit line delivers a fraction of that across an ocean

The most useful single fact about long-distance transfers is a 1997 result usually called the Mathis equation. For a TCP connection in its steady state, throughput is at most approximately the maximum segment size divided by the round-trip time times the square root of the packet-loss rate. Written out:

throughput ≲ MSS / (RTT × √p)

MSS  maximum segment size, about 1,460 bytes on an ordinary path
RTT  round-trip time in seconds
p    fraction of packets lost

Nothing in that expression is the capacity of the link. A 100 Mbps line and a 10 Gbps line have the same bound for the same RTT and loss. The link only matters once the bound is above what the link can carry, which on a short, clean path it usually is. That is why the problem is invisible inside a building and dominant across an ocean.

Take the conditions from our published benchmark, because they are representative of a trans-Pacific path with some congestion: 150 ms round trip and 3% loss.

MSS = 1,460 bytes = 11,680 bits
RTT = 0.150 s
p   = 0.03,  √p ≈ 0.173

bound ≈ 11,680 / (0.150 × 0.173) ≈ 450,000 bit/s per connection

That is under half a megabit per second for one connection. Real transfers do better than this worst case because loss is rarely that high for the whole transfer and because tools open several connections, but the point stands: the number is set by distance and loss, not by the line. It is also why 'just open more streams' has a ceiling. Each stream pays the same RTT-per-loss tax, and many streams contend with each other and with everyone else on the path.

The same path at 3% loss and 10 ms RTT, the kind of RTT you see inside a metro area, gives a bound fifteen times higher. Distance is the variable that changed.

The coupling between RTT and loss comes from how TCP reacts to a lost segment: it treats loss as a congestion signal, cuts its sending rate, and recovers that rate over multiple round trips. On a long path each of those round trips is expensive and each loss triggers the cycle.

RIPT, the transport under RIPTON CLOUD, is built on UDP with its own rate control and block-level retransmission. The sender paces packets at a rate it sets from measured conditions rather than from a loss-triggered window; a lost block is re-requested and re-sent without the whole stream slowing to recover. Loss still costs the bytes that have to be re-sent, but it no longer costs a multi-RTT recovery cycle. On a short clean path that gains little. At 150 ms and 3% loss it is the difference between a 1 GB file finishing in 4 minutes and in 30, which is the published EC2 result.

• Distance and loss set the ceiling for a TCP stream; capacity only matters below that ceiling.
• Adding streams helps until the streams start competing; it does not remove the tax.
• A paced UDP transport removes the RTT-per-loss recovery cycle. The gain scales with RTT and loss, which is why we publish the benchmark conditions rather than a single multiplier.

The honest way to know what this means for you is to measure your own route. The file transfer calculator estimates it from your RTT, loss and link speed, and the proof-of-concept page describes the two-week test we run on a real route against the tool you use today.