Bandwidth-delay product explained: why a 1 Gbps WAN link only delivers 5 Mbps

How this is calculated

The BDP exists because TCP is a reliable protocol: it can only send a fixed amount of data (the receive window) before it must stop and wait for an acknowledgment from the far end. On a 1 ms LAN the acknowledgment comes back almost instantly, so even a small window cycles fast and the link fills. On a 100 ms transatlantic link that same window cycles 100 times more slowly, so the effective throughput drops by the same factor. The fix is to grow the window until it matches or exceeds the BDP. RFC 1323 window scaling lets the window expand up to 1 GiB by left-shifting the advertised 16-bit window value, which is enough to fill any realistic WAN link. The catch is that every device on the path, including firewalls and load balancers, must pass the TCP options through, and some older or misconfigured middleboxes silently strip them.

Verdict

The bandwidth-delay product is the single number that explains why long-distance network transfers run at a fraction of the link rate, and it is link speed times round-trip time because that product is how much data must be in flight at once to keep the pipe full. The 1 Gbps at 100 ms example is the canonical illustration: the BDP is 12 MB, the default unscaled 64 KB TCP receive window is about 0.5% of that, and the resulting throughput ceiling of 5.24 Mbps is 0.52% of the rated link. The fix is RFC 1323 window scaling, which lets the window grow up to 1 GiB and pushes the ceiling past the link rate so throughput stops being window-limited and starts being link-limited. The reason this matters for anyone planning a WAN or cloud migration is that a naive size-divided-by-speed calculator ignores the BDP entirely and returns the 2 hours 13 minutes that 1 TB over 1 Gbps would take in a zero-latency universe, which is the wrong universe for the internet.