A network path can offer a gigabit per second of capacity while a single file transfer struggles to reach a tenth of that rate. The cable may be fine. The server may be capable. The missing ingredient can be surprisingly simple: enough data in flight.
To understand why, you need a concept called the bandwidth-delay product, or BDP.
BDP connects two familiar measurements—bandwidth and delay—and produces something less obvious: an amount of data. For TCP performance, it helps estimate how much data must remain unacknowledged to keep a path busy while feedback travels back to the sender.
Think of it as the network’s invisible cargo.
What Is the Bandwidth-Delay Product?
The bandwidth-delay product is a data rate multiplied by a delay.
For the TCP examples in this article, we use the path’s bottleneck capacity and its round-trip time, or RTT:
BDP in bits = bandwidth in bits per second × RTT in seconds
To express the result in bytes:
BDP in bytes = bandwidth × RTT ÷ 8
The units explain the idea. Bits per second multiplied by seconds gives bits: a quantity of data, rather than a transmission rate.
Different contexts can use different delay definitions. A physical link’s capacity multiplied by its one-way propagation delay describes the bits that can occupy that link. For TCP window sizing, the relevant feedback cycle is the round trip, so the calculations below consistently use RTT.
Our RTT overview explains that measurement in more detail.
Why Sending Faster Requires More Outstanding Data
Imagine a dispatch center that can send 100 parcels every second. Delivery confirmations take ten seconds to return.
To dispatch continuously at that rate, it must allow approximately 1,000 parcels to remain unconfirmed:
100 parcels per second × 10 seconds = 1,000 parcels
If the center permits only 100 unconfirmed parcels, it will repeatedly run out of permission to send—even though the dispatch equipment could handle more.
TCP faces a similar constraint. It can send multiple segments before receiving acknowledgments, but it cannot maintain an unlimited amount of outstanding data.
As acknowledgments arrive, the sender gains room to transmit more. When the allowed amount is too small for the feedback delay, the path can become underused.
This is pipelining: keeping useful work moving while earlier work awaits confirmation.
A Gigabit Path Can Need 12.5 MB in Flight
Consider an idealized path with:
- A bottleneck capacity of 1 Gbps.
- A baseline RTT of 100 milliseconds.
- One long-running TCP transfer.
Convert milliseconds to seconds:
100 ms = 0.1 seconds
Now calculate the product:
1,000,000,000 bits/s × 0.1 s = 100,000,000 bits
Divide by eight:
100,000,000 ÷ 8 = 12,500,000 bytes
That is 12.5 MB, using decimal units, or approximately 11.92 MiB.
The transfer needs permission and resources to sustain roughly that amount of unacknowledged data to approach the assumed rate under ideal conditions. Protocol overhead and other constraints reduce the application throughput achievable on a real link.
There is an important subtlety: unacknowledged does not mean every byte is still physically traveling toward the receiver. Some data may already have arrived while its acknowledgment is traveling back.
BDP describes the scale of the feedback pipeline, not simply the contents of one cable.
The Small Window That Leaves a Fast Path Idle
Suppose the same connection is effectively limited to 1 MiB of outstanding data.
An approximate steady-state ceiling for a window-limited transfer is:
Throughput in bits/s ≈ outstanding-data limit in bytes × 8 ÷ RTT
For our example:
1,048,576 × 8 ÷ 0.1 = 83,886,080 bits/s
That is approximately 83.9 Mbps.
The path offers 1 Gbps, but this particular connection’s outstanding-data limit allows only a small fraction of that capacity to be used.
Buying a faster access service would not remove that limit.
This calculation assumes the window is the binding constraint, RTT is reasonably stable, and the sender has enough data to send. It is a useful explanatory bound, not a universal formula for predicting every TCP transfer.
TCP Has Two Different Windows to Respect
The phrase “TCP window” can hide an important distinction:
- Receive window, rwnd: the receiver’s advertised limit, used to prevent the sender from overwhelming its available receiving capacity.
- Congestion window, cwnd: a sender-side limit controlled by congestion-control mechanisms.
The smaller of these constrains outstanding transmission, with the sender also accounting for data already in flight.
A large receive window cannot compensate for a small congestion window. Likewise, a generous congestion window cannot override the receiver’s advertised limit.
Socket-buffer limits, application behavior, and available memory can impose additional restrictions. Our TCP window article introduces the related flow-control concepts.
TCP’s Window Scale option supports receive windows beyond the unscaled 16-bit field’s maximum of 65,535 bytes. The scale factor is negotiated during connection establishment; the advertised receive window can subsequently change during the connection.
Window scaling makes larger windows representable. It does not automatically guarantee that a transfer will use them.
How Quickly the Requirement Grows
Here are four illustrative bandwidth-delay products:
| Assumed bottleneck capacity | RTT | BDP in bytes |
|---|---|---|
| 100 Mbps | 10 ms | 125,000 bytes — 125 kB |
| 1 Gbps | 10 ms | 1,250,000 bytes — 1.25 MB |
| 1 Gbps | 100 ms | 12,500,000 bytes — 12.5 MB |
| 10 Gbps | 100 ms | 125,000,000 bytes — 125 MB |
These are calculated examples using decimal bandwidth and storage units.
Increasing capacity tenfold increases BDP tenfold. Increasing RTT tenfold does the same.
This explains why a configuration that works well across a local network may struggle across a long-distance path. The distant path needs more outstanding data to sustain the same rate.
The bandwidth value must also represent the relevant end-to-end constraint. A 10 Gbps network interface does not establish that the complete path can deliver 10 Gbps. Shared traffic can further reduce the capacity available to one transfer.
Data in Flight Is Different from Data Waiting in a Queue
A tempting conclusion is that a large BDP means every router needs an enormous buffer.
BDP alone does not determine the correct router-buffer size.
Endpoint buffers support transmission and reception. Router queues hold packets waiting for an outgoing link. These serve different purposes.
A path can have a large BDP because its endpoints are far apart, without requiring a persistent backlog at a router.
Excessive standing queues add delay. That is the problem explored in our bufferbloat guide.
For a baseline BDP estimate, use an RTT representative of the path without substantial congestion. Multiplying capacity by an RTT inflated by a large queue can make the apparent requirement grow because of the very queueing problem you should investigate.
The objective is enough outstanding data to sustain useful throughput while controlling unnecessary delay.
How to Use BDP When Troubleshooting
Start by estimating the path’s capacity and baseline RTT. Calculate the BDP, then compare it with the connection’s observed behavior.
Useful questions include:
- Is the receive window restricting transmission? Examine the advertised window and whether window scaling was negotiated.
- Is congestion control limiting the sender? Loss, congestion signals, and startup behavior can keep the congestion window below the level needed to fill the path.
- Can the endpoints supply and consume data fast enough? Storage, CPU, encryption, and application behavior may become bottlenecks.
- Does RTT rise sharply during the transfer? Persistent queueing may be damaging responsiveness.
- Does a multi-connection test outperform one connection? Several connections have separate windows, so an aggregate result can conceal a limitation affecting an individual transfer.
Modern operating systems commonly support TCP buffer autotuning, but configured limits and application settings still matter. BDP gives you a scale to investigate—not a reason to copy an arbitrary buffer setting into every machine.
The Question Behind the Number
Bandwidth tells you how much data a path can carry per second. RTT tells you how long the feedback cycle takes.
BDP connects them by asking:
How much data must remain outstanding to keep this path working continuously?
Once you ask that question, a slow transfer over a fast network becomes less mysterious. Capacity is only useful when the connection can keep enough work in progress to use it.
References and Further Reading
- RFC 6349: Framework for TCP Throughput Testing — BDP calculations, baseline RTT, and window-limited throughput.
- RFC 5681: TCP Congestion Control — receive-window and congestion-window constraints.
- RFC 7323: TCP Extensions for High Performance — window scaling for paths with large bandwidth-delay products.
- RFC 9293: Transmission Control Protocol — TCP operation and acknowledgment mechanisms.
- RFC 7567: IETF Recommendations Regarding Active Queue Management — queue management and latency.
- ESnet Fasterdata: Host-Tuning Background — practical context for TCP buffers and autotuning.
