Bandwidth-delay product explained: how the TCP window limits a WAN transfer

By TechCompare · Updated · How we check

For 1 Gbps at 100 ms, the BDP is 12.5 MB. A persistent unscaled window of about 64 KiB gives a 5.24 Mbps ceiling, while modern autotuning can grow a scaled window toward the path requirement.

The bandwidth-delay product is link rate multiplied by round-trip time: the amount of data that must be in flight to fill the link. For 1 Gbps at 100 ms, it is 12.5 MB. A fixed unscaled window of about 64 KiB limits throughput to about 5.24 Mbps. This is a deliberately constrained example with scaling disabled and a fixed window of about 64 KiB, not a general OS default.

Windows normally enables receive-window autotuning, and Linux enables receive-buffer autotuning by default. A small initial advertised window need not remain a persistent cap.

Transfer time
17d 15h 51m 42s
Window-limited to 5.2 Mbps
File size
1 TB
1000 GB
Link speed
1 Gbps
Gigabit Ethernet
Effective throughput
5.2 Mbps
at 100 ms RTT
Link utilized
0.52%
Bottleneck: TCP window

How this is calculated

TCP can keep data in flight while earlier data is being acknowledged. The receive window and congestion window bound that outstanding data. If the receive window is smaller than the bandwidth-delay product, the receive-window ceiling is window bytes times 8 divided by RTT seconds.

Window scaling, specified by RFC 7323, permits advertised windows up to just under 1 GiB. It does not itself allocate that buffer or guarantee full link speed. A measured effective window, congestion control, packet loss, storage, and application behavior all matter.

Verdict

BDP is a sizing guide, not evidence that every distant transfer is window-limited. The 1 Gbps, 100 ms example needs 12.5 MB in flight to fill the link. This page deliberately holds the window near 64 KiB without scaling, which limits throughput to about 5.24 Mbps.

Check negotiated scaling and the effective window before blaming latency alone. In the calculator, scaling permits a larger entered window, and a window at least as large as BDP removes this one modeled bottleneck.

More WAN scenarios

100 GB over USB 3.0
A 100 GB transfer over USB 3.0 works out to 2 minutes 40 seconds at the interface's 5 Gbps peak rate.
View details
1 TB over USB 3.0
A 1 TB transfer over USB 3.0 works out to 26 minutes 40 seconds at the interface's 5 Gbps peak data rate.
View details
4 GB over USB 2.0
A 4 GB transfer over USB 2.0 works out to 1 minute 6 seconds at the interface's 480 Mbps peak rate.
View details

Frequently asked questions

What is the bandwidth-delay product formula?
BDP = link speed times round-trip time. For 1 Gbps at 100 ms that is 1,000,000,000 bits per second times 0.1 seconds = 100 million bits, or 12.5 MB. Your TCP window needs to be at least that large to fill the link.
Why does throughput drop on high-latency links?
TCP can only have one receive window of data in flight at a time. On a high-latency link the window takes longer to cycle because the acknowledgment takes longer to return, so the effective throughput drops to window size divided by RTT, regardless of the link rate.
What is TCP window scaling and how does it fix the BDP problem?
RFC 7323 window scaling permits advertised receive windows larger than the unscaled 65,535-byte limit, up to just under 1 GiB. The actual buffer still needs to be large enough for the path's bandwidth-delay product. Scaling alone does not allocate that buffer or guarantee full throughput.
Do all operating systems support TCP window scaling?
Current Windows and Linux support scaling and normally enable receive-buffer autotuning. A socket with a pinned receive buffer, disabled tuning, or a middlebox blocking negotiation can constrain a connection. Inspect the negotiated options and effective window rather than assuming every WAN connection stays near 64 KiB.