What the bandwidth-delay product is
A network link is like a pipe: bandwidth is its width and the round-trip time (RTT) is its length. The bandwidth-delay product (BDP) is the amount of data that fills the pipe:
BDP (bytes) = bandwidth (bit/s) × RTT (s) ÷ 8
To keep the link full, a sender must have at least that much data in flight, sent but not yet acknowledged.
Why the TCP window matters
TCP limits data in flight to the receiver’s window. A single connection therefore cannot exceed:
Throughput ≤ window ÷ RTT
The original TCP header allows a window of only 64 KB. On a 100 Mbit/s link with 80 ms RTT, the BDP is 1 MB, but a 64 KB window caps one stream at about 6.6 Mbit/s, 7% of the link. Window scaling (RFC 7323), on by default in modern systems, allows windows up to 1 GB, but buffers, middleboxes and application settings still cap it in practice.
Packet loss
TCP congestion control slows down when packets are lost. The Mathis formula gives an approximate ceiling for classic Reno-style TCP:
Throughput ≤ (MSS ÷ RTT) × 1.22 ÷ √loss
With 1,460-byte segments, 80 ms RTT and 0.01% loss, the ceiling is about 17.8 Mbit/s. Newer algorithms such as CUBIC and BBR handle loss better, so treat this as a conservative estimate.
Example summary
| Item | Value |
|---|---|
| BDP | 1 MB (977 KB) |
| Window limit (64 KB) | 6.6 Mbit/s |
| Loss limit (0.01%) | 17.8 Mbit/s |
| Expected throughput | 6.6 Mbit/s |
How to go faster
- Raise socket buffers so the window can grow to at least the BDP.
- Reduce latency, for example with a closer server or CDN.
- Fix packet loss on Wi-Fi or congested links.
- Use several parallel streams, as many download managers and backup tools do.