Bandwidth-Delay Product

The Pipe Analogy

Picture the connection between you and a server as a pipe. Its bandwidth is how wide the pipe is — how much can flow per second. Its latency is how long the pipe is — how long a drop of water takes to travel end to end. The bandwidth-delay product (BDP) is simply the volume of the pipe: width multiplied by length. It tells you how much data can be inside the pipe, in transit, at any single moment.

That volume matters because of how reliable transport works. To keep the pipe completely full, the sender must have enough data launched and not-yet-acknowledged to fill the entire length at all times. If it sends a burst and then waits, the pipe drains and bandwidth is wasted. The BDP is exactly how much data has to be "in flight" to avoid that.

The Formula

The bandwidth-delay product is bandwidth times round-trip time:

BDP (bits) = bandwidth (bits/sec) × RTT (seconds)

Divide by 8 for bytes. Round-trip time is used — not one-way delay — because the sender cannot free up "in-flight" data until an acknowledgement returns, which is a full round trip away. A worked example:

• Link: 100 Mbps = 100,000,000 bits/sec
• RTT: 100 ms = 0.1 sec
• BDP = 100,000,000 × 0.1 = 10,000,000 bits = 1.25 MB

So to keep that 100 Mbps link to a server 100 ms away fully busy, a connection must have about 1.25 MB of unacknowledged data in flight at every instant. That number is the crux of everything that follows.

Why the TCP Window Has to Match the BDP

TCP limits how much unacknowledged data a sender may have outstanding through the receive window. Here is the collision: if the window is smaller than the BDP, the sender fires off a window's worth of data, then must stop and wait for acknowledgements before sending more. During that wait the pipe empties and throughput falls — sometimes far below the link's rated speed.

The maximum throughput a single connection can achieve is therefore capped by:

Throughput ≤ window size ÷ RTT

Work the earlier example backward with the old default 64 KB window: 65,536 bytes ÷ 0.1 sec ≈ 5.2 Mbps. On a 100 Mbps link, a 64 KB window over a 100 ms path tops out around 5 Mbps — using just 5% of the available bandwidth. The link is not the bottleneck; the window is.

Same window, same link speed — only the distance changes, yet the achievable throughput collapses as RTT grows. This is the single clearest demonstration that latency, not just bandwidth, governs real-world speed.

Window Scaling: The Fix

The original TCP header reserved 16 bits for the window, capping it at 65,535 bytes — fine in the era it was designed, hopeless for today's long, fat links. The solution is window scaling, a TCP option negotiated during the handshake that multiplies the advertised window so it can reach hundreds of megabytes. With window scaling enabled (it is, by default, on every modern operating system), the window can grow to match the BDP, and a single connection can fill even a high-latency gigabit path. When you see a fast result on a speed test to a distant server, sufficiently large windows are part of why it is possible.

Long Fat Networks — and What Else BDP Explains

A path with both high bandwidth and high latency — a large BDP — is nicknamed a long fat network (LFN). Intercontinental fibre and satellite links are the textbook cases: an LEO satellite hop or a transoceanic route can demand many megabytes in flight. These paths need large windows, healthy buffers, and sometimes parallel connections to be used efficiently, which is exactly why download managers and browsers open several connections at once — collectively they keep far more data in flight than any single stream could.

The same arithmetic explains several everyday observations: why latency matters as much as bandwidth, why a nearby speed-test server posts higher single-stream numbers than a far one, and why TCP slow start feels slow over long distances — it takes several high-latency round trips for the window to ramp up to the BDP in the first place. Once you can compute a BDP, a lot of "my connection feels slower than it should" puzzles resolve themselves.

Frequently Asked Questions

What is the bandwidth-delay product?

The amount of data that can be in transit on a link at once — bandwidth multiplied by round-trip time. It is how much unacknowledged data must be in flight to keep a connection fully busy.

How do you calculate it?

Multiply bandwidth (bits/sec) by RTT (seconds), then divide by 8 for bytes. 100 Mbps with a 100 ms RTT is 10,000,000 bits, about 1.25 MB in flight to fill the link.

Why doesn't a single download reach my full speed over long distances?

A single TCP connection can only have one window of data unacknowledged at a time. If the window is smaller than the BDP, the sender stalls waiting for acknowledgements and the link sits idle. High RTT means a large BDP, so a small window throttles throughput.

What is TCP window scaling?

A TCP option, negotiated in the handshake, that lets the receive window grow far beyond the old 64 KB limit so it can match a large BDP. Without it, high-bandwidth high-latency connections would stall.

What is a long fat network?

A path with both high bandwidth and high latency, and therefore a large bandwidth-delay product — intercontinental and satellite links are typical. They need large windows, and often parallel connections, to be used efficiently.