TCP Bandwidth-Delay Product

Bandwidth-Delay Product: sizing the TCP pipe

The BDP multiplies link bandwidth by round-trip time: BDP = bandwidth · RTT. Think of it as the size of the pipe, meaning how many bytes can sit on the wire in flight at any given moment. Take a 1 Gbps link with 100 ms RTT: that works out to 10⁹ · 0.1 / 8 ≈ 12.5 MB. If you want to fill the link, the TCP receive window has to be at least as big as the BDP. Fall short and the sender ends up idle, waiting on ACKs. The old 16-bit window field tops out at 64 KB, and that limit is exactly what RFC 1323 Window Scaling works around by adding a shift option that pushes windows up to 1 GB. Skip scaling and that same 1 Gbps × 100 ms link is stuck near ~5 Mbps no matter how much bandwidth you actually have.

Applications: long-haul, satellite and CDN tuning

It comes up when you size TCP buffers on long-haul WAN links between data centers, on satellite paths where RTT runs past 600 ms, and on CDN origin pulls that cross continents. Scientific networks like ESnet and Internet2 lean on it heavily for high-BDP tuning. There's a congestion-control angle too: engineers check the BDP before settling on an algorithm, since BBR and CUBIC don't behave the same way once the path gets fat.

FAQ

Why does my 1 Gbps link only deliver 100 Mbps? Odds are your receive window sits under the BDP. Turn on Window Scaling and bump up net.ipv4.tcp_rmem/tcp_wmem.

Is BDP relevant on LANs? Not really. Sub-millisecond RTT keeps the BDP tiny, so the default buffers already cover you.

Bandwidth in bits, BDP in bytes? Right. Bits over 8 gives you bytes, and this tool already hands back the BDP in bytes/KB/MB.