Bandwidth-Delay Product

Also known as BDP · bytes in flight · long fat network · TCP window size · pipe capacity · in-flight data

BDP=RRTT\mathit{BDP} = R\,\mathit{RTT}

Enter your known values, leave one input blank, and solves for the missing one. Try different units for next level excitement!

Learning zone

Multiply the link rate by the round-trip time and you get the number of bits in flight: sent, but not yet acknowledged. A gigabit link with a 40 ms round trip holds 109 imes0.04=4 imes10710^9 \ imes 0.04 = 4 \ imes 10^7 bits, which is 5 MB sitting in the wire and the switches at any instant. That is not a metaphor. It is genuinely how much data is out there unaccounted for.

This number is the minimum window a sender needs in order to keep transmitting. With a smaller window the sender fills the window, stops, and waits for an acknowledgement that cannot arrive sooner than one round trip, so throughput collapses to window divided by RTT no matter what the link can do. Original TCP capped the window at 64 KB, which over that same 40 ms path limits you to about 13 Mbit/s on a gigabit link. Window scaling, RFC 1323, exists purely to raise that ceiling, and a long fat network with scaling disabled is still one of the most common causes of a fast link that transfers slowly.

The part worth internalising is that latency does not shrink. You can buy more bandwidth; you cannot buy a shorter path than light allows, and Toronto to Sydney is about 160 ms of round trip before any equipment touches it. So as links get faster the bandwidth-delay product grows in proportion, buffers must grow with it, and the amount of unacknowledged data in flight keeps climbing. Every congestion-control problem of the last twenty years, bufferbloat included, is downstream of that single fact.

Bandwidth-Delay Product
BDP=RRTT\mathit{BDP} = R\,\mathit{RTT}
Where
  • BDP\mathit{BDP}= Bandwidth-delay product (bits)
  • RR= Bit rate (bit/s)
  • RTT\mathit{RTT}= Round-trip time (ms)
Missing one of these? Work it out first, then come back