What is bandwidth-delay product used for?

Bandwidth-delay product tells you how much data a network path must carry in flight to use its advertised capacity. Multiply bandwidth by round-trip time, then compare that value with the effective send, receive, or protocol window. If the window is smaller, the link cannot be filled.

Why can a high-bandwidth connection still be slow?

A high-bandwidth path can be idle much of the time if acknowledgements take a long time to return and the sender is not allowed to keep enough data outstanding. The bottleneck is then not the pipe size, but the combination of round-trip time and the configured or negotiated window.

Do I need packet loss to explain poor long-distance throughput?

No. Loss makes things worse, but it is not required. Even a clean path can underperform when the amount of data allowed in flight is below the bandwidth-delay product. This is common on cross-region transfers, object storage uploads, and service-to-service calls with conservative flow-control windows.

The Network

03.03 · Concept

Connections Cost Something

Use the bandwidth-delay product to explain why a fat pipe underperforms over distance, and why throughput is window divided by RTT.

No video curated for this lesson yet

This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Deployment lesson by lesson; 29 of 56 have their video so far.

The written notes below cover this idea in full - you lose nothing by reading instead of watching.

High-bandwidth links need enough unacknowledged data in flight to stay full. Bandwidth-delay product gives that required window, while achievable throughput is bounded by window divided by round-trip time. A distant fat pipe can look slow without loss or saturation because the sender keeps waiting for acknowledgements.

What this lesson answers

why does a fat pipe underperform over distance
how does bandwidth delay product affect throughput
why is TCP throughput window divided by RTT

Notes

Bandwidth-Delay Product — Bandwidth-delay product exists to quantify how much data must be in flight to fill a network path; without a large enough send/receive window, a high-bandwidth long-distance link sits idle between acknowledgments.

Key Concepts: - Bandwidth-delay product is $B D P = ban d w i d t h \times R T T$ ; a $1 G b p s$ link with $80 m s$ RTT needs $1, 000, 000, 000 \times 0.08 = 80, 000, 000$ bits = $10 M B$ in flight. - Throughput is capped by $t h r o ug h p u t \leq \frac{w in d o w}{R T T}$ ; a $256 K B$ TCP window over $100 m s$ RTT gives $\frac{256\,KB}{0.1s} = 2.56\,MB/s \approx…

References

Wikipedia - Bandwidth-delay product

Common questions

What is bandwidth-delay product used for?: Bandwidth-delay product tells you how much data a network path must carry in flight to use its advertised capacity. Multiply bandwidth by round-trip time, then compare that value with the effective send, receive, or protocol window. If the window is smaller, the link cannot be filled.
Why can a high-bandwidth connection still be slow?: A high-bandwidth path can be idle much of the time if acknowledgements take a long time to return and the sender is not allowed to keep enough data outstanding. The bottleneck is then not the pipe size, but the combination of round-trip time and the configured or negotiated window.
Do I need packet loss to explain poor long-distance throughput?: No. Loss makes things worse, but it is not required. Even a clean path can underperform when the amount of data allowed in flight is below the bandwidth-delay product. This is common on cross-region transfers, object storage uploads, and service-to-service calls with conservative flow-control windows.

Short definition: what is Connections Cost Something?

03.02 · The NetworkDNS 03.04 · The NetworkTLS