TCP Window BDP Calculator

TCP Window and Bandwidth-Delay Product (BDP)

Think of the Bandwidth-Delay Product as how much data is sitting on the wire at any given instant. The math is just BDP = bandwidth × RTT. Take a 1 Gbps link with a 100 ms round-trip and you get BDP = 10⁹ bits/s × 0.1 s = 10⁸ bits = 12.5 MB. To actually fill that link, TCP needs a receive window at least as big as the BDP. Make it smaller and the pipe runs half-empty while the sender sits around waiting on ACKs.

Plain TCP stores the window in 16 bits, so it tops out at 65 535 bytes. That was fine for a 1990s LAN, but you blow past it without trying these days. RFC 1323 (now RFC 7323) added the Window Scale option, which shifts the window left by up to 14 bits and lets it grow to 1 GB. When a link has a high BDP — satellite with its long RTT, trans-oceanic fibre combining long RTT and high bandwidth, 10/100 GbE WAN — people call it a “long fat network” (LFN). Those need window scaling, and selective acknowledgment (SACK, RFC 2018) on top, to bounce back from packet loss without crawling.

Applications

Network engineers reach for this when tuning Linux (sysctl net.ipv4.tcp_window_scaling, tcp_rmem, tcp_wmem). So do CDN and cloud operators sizing per-flow buffers, the video-streaming and bulk-transfer crowd (rsync, aspera, GridFTP), and HFT shops trying to shave their tail latency.

FAQ

Why does my 1 Gbps link only reach 100 Mbps? Nine times out of ten the OS receive window is too small for the BDP. Confirm that window scaling is on and that the tcp_rmem max is at least as large as the BDP.

Does the BDP matter on a LAN? Not usually. When RTT is sub-millisecond, even 10 Gbps works out to a BDP of around 1 MB, which sits well under the default window sizes.

What about UDP and QUIC? QUIC carries its own flow-control window, both per stream and per connection. The BDP logic still holds, but here the congestion control (BBR, CUBIC) is what does the real work.