TCP Bandwidth-Delay Product Calculator

Works out how much data can be "in flight" on a link at once, and whether the TCP window size in use is actually big enough to use the bandwidth you're paying for. This is the calculation behind the classic "why is my high-bandwidth satellite link so slow" problem — and it has nothing to do with the bandwidth number on the spec sheet being wrong.

What bandwidth-delay product actually means

BDP = Bandwidth × RTT. It's the amount of data that fits "in the pipe" between sending it and getting an acknowledgment back — think of it as the pipe's volume, not its width. A 100 Mbps link with an 80ms round trip has a BDP of roughly 1MB: that's how much data needs to be outstanding, unacknowledged, at any given moment to keep the link continuously busy rather than sitting idle waiting for ACKs.

Why the TCP window size is the actual bottleneck, not the link

TCP will never have more unacknowledged data in flight than the receive window allows — it's a hard ceiling by design, there for flow control. The classic default window, without RFC 1323 window scaling enabled, tops out at 65,535 bytes (64KB). If the BDP exceeds that window, the connection physically cannot use the full link no matter how much bandwidth is actually available — it sends a window's worth of data, then has to sit and wait for an ACK before sending more, and that wait time is dominated by RTT, not by how fast the link could theoretically move data.

Where this actually bites, concretely

A geostationary satellite link with ~600ms RTT and a 64KB window caps out at roughly 0.87 Mbps of single-stream throughput — regardless of whether the link is rated for 50 Mbps or 500 Mbps. This is exactly why satellite and other high-latency links feel dramatically slower than their advertised bandwidth for a single download, while running several parallel connections (which many download managers and browsers already do) can use dramatically more of the actual available bandwidth, since each stream gets its own window.

The actual fix

Window scaling (RFC 1323) is the real solution — it lets TCP negotiate a scaled window up to roughly 1GB instead of being capped at 64KB, and it's been supported and enabled by default in essentially every OS for well over a decade at this point. If you're still seeing throughput capped well below link bandwidth on a high-latency connection, the actual things worth checking are whether window scaling is genuinely enabled end-to-end and whether a middlebox somewhere on the path (a firewall, an old proxy) is stripping the scaling option or otherwise capping the window — that's a far more common real-world cause than the window scaling feature simply not existing.