A single TCP flow cannot sustain more than about (MSS/RTT) × 1/√p, where p is the loss rate. At 1460-byte segments, a 100 ms round trip and one percent loss that is 1.168 Mbit/s — on a link of any capacity whatever. Filling a ten-gigabit link under those conditions needs 8 562 parallel streams, which is why a slow cross-region copy is usually a flow-count problem rather than a bandwidth one.
Core ideas
The hard idea is that a link’s capacity is an upper bound on what all flows together can do, and says almost nothing about what one flow will do.
A congestion-controlled sender grows its window until a loss, then cuts it. Averaged over that cycle the sustainable rate comes out proportional to MSS/RTT and inversely proportional to √p. The link capacity does not appear in the expression at all, which is the entire surprise.
Halving the round-trip time doubles the bound: the same 1460 B at 1% loss gives 1.168 Mbit/s at 100 ms and 11.680 Mbit/s at 10 ms. Halving the loss multiplies it by √2, about 1.414. Doubling the loss from 1% to 2% gives 0.826 Mbit/s, not 0.584 — and 0.584 is what doubling the round trip would give instead.
If one flow is bounded at 1.168 Mbit/s and the link carries 10 000 Mbit/s, then ⌈10 000 / 1.168⌉ = 8 562 concurrent flows are needed to use it. That figure is the honest reason bulk transfer tools open many connections, and it is a number to compute before concluding that a link was mis-sold.
The material
Where the square root comes from, what it does to the arithmetic, and the one place this course rounds.
A team copies a dataset between two regions over a ten-gigabit link and measures a little over a megabit a second. The link is not the problem, the disks are not the problem, and nothing is broken. The transfer is using one TCP connection over a 100 ms round trip with one percent packet loss, and that combination has a ceiling.
For a loss rate p, a maximum segment size MSS and a round-trip time RTT, a single congestion-controlled flow sustains at most approximately (MSS / RTT) × (1 / √p). It is a bound on the average rate over many congestion cycles, derived from the sawtooth of window growth and halving; it ignores timeouts, receive-window limits and the slow-start phase, so a real flow achieves this or less.
The bound is 1.168 Mbit/s and the link is 10 Gbit/s. The flow is using about one ten-thousandth of the capacity that was bought, and buying more capacity changes the numerator of nothing. What would change the answer is a shorter round trip, a lower loss rate, a larger segment, or more flows — and the 8 562 figure prices the last of those exactly.
Loss enters as 1/√p, so a factor of two in loss is a factor of √2 in throughput, not a factor of two. Going from 1% to 2% takes the bound from 1.168 to 0.826 Mbit/s — it multiplies by 1/√2 ≈ 0.707, and a reader who expected 0.584 has applied the wrong rule. Going the other way is the same story in reverse: halving the loss buys 41% more throughput, not 100% more, which is why loss reduction has diminishing returns and round-trip reduction does not.
At 1460 B and 1% loss, moving the round trip from 100 ms to 10 ms — a nearer region — takes the bound from 1.168 to 11.680 Mbit/s, exactly ten times, because RTT is in the denominator linearly. Moving the loss from 1% to 0.1% — a tenfold improvement in a much harder quantity — takes it to 3.694 Mbit/s, a factor of √10 ≈ 3.16. Distance is the more powerful lever by a factor of three, and it is also the one “The Speed-of-Light Floor” said was the only one physics cares about.
One honesty note about the arithmetic, because this lesson is the exception on this course. Every other figure in these eleven labs is an exact fraction: percentiles are ranks, convolutions are enumerated pairs, and budgets are subtractions. This bound contains √p, and a square root of a rational is usually irrational — √(1/50), the root needed at two percent loss, has no rational value at all. So the mathis mode computes its root by Newton’s method to fifteen decimal places and says on its face that it has done so. Every figure on that panel inherits the rounding, and no other page on the course does.
Two limits on the model itself. It is a bound on the average rate, so a real flow reaches it at best and usually less: retransmission timeouts, a receive window too small for the bandwidth-delay product, and slow start all cost more. And it describes loss-based congestion control; a flow using a rate-based or delay-based controller is not governed by this sawtooth and is not described by this formula. Read it as the ceiling a classical flow cannot pass, which is exactly the use it gets put to.
The misconception it exists to correct is short enough to state in one sentence: a ten-gigabit link does not give a ten-gigabit flow. The link capacity is a bound on the aggregate; a single connection is bounded by its own round-trip time and loss rate, and those two numbers were never on the invoice.
Interactive
One flow's ceiling, which the link rate has nothing to do with
Method
Four steps, and the fourth is the one that stops the wrong invoice being blamed.
The segment size is typically 1460 B on a standard ethernet path and larger with jumbo frames. The round trip and the loss rate come from measurement, not from the contract, and the loss rate is the one people most often do not have.
Keep the round trip in seconds for this line. 1460 B / 0.1 s is 14 600 B/s. This is the per-round-trip rate of one segment, and it is the whole of the bound when the loss rate is one hundred percent.
The square root is the step to do carefully: √0.01 = 0.1, so 1/√p is 10, not 100. Multiply by eight and divide by 10⁶ for megabits a second, and expect a figure far below the link rate.
Round up. ⌈10 000 / 1.168⌉ = 8 562 says how many concurrent flows the link needs before its capacity is reachable at all — and if that number is implausible, the fix is the round trip or the loss, not the link.
The link is enormous, the transfer is slow, and nothing is broken. The bound explains it in four lines.
The last line is the one to keep. Quadrupling the link changes the bound by nothing at all, because the link capacity does not appear in the formula. Every hour spent on a bandwidth upgrade for a single-stream transfer is an hour spent on a term that is not in the expression.
The × √10 ≈ 3.16 line is the one that gets misread. A tenfold reduction in loss — from one percent to one in a thousand, which is a serious network engineering achievement — buys a factor of three in throughput. Meanwhile moving the endpoint from 100 ms to 10 ms away buys a factor of ten. The square root is not a detail of the formula; it is the reason the two levers are ranked the way they are.
For a faded rehearsal, take a jumbo-frame path: MSS = 9000 B, RTT = 40 ms, p = 0.5%, over a 1 Gbit/s link. The supplied first move is MSS / RTT = 9000 / 0.04 = 225 000 B/s. Compute 1/√p, the bound in megabits a second, and the number of streams needed to fill the link. Then say which single change — halving the round trip or halving the loss — buys more, and by what factor. Check the figures on the lab’s sliders before opening the quiz.
You should be able to compute (MSS/RTT) × 1/√p for a described path, convert it to megabits a second, work out how many parallel streams a given link would need, and say which of the round trip and the loss rate is the more valuable thing to improve and by what factor.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.