How this instrument works
The bandwidth-delay product (BDP) measures how much data can be traveling across a network link at any given instant, before the first bit sent has had time to be acknowledged back at the sender. It's simply bandwidth multiplied by round-trip time: a faster link or a longer round trip both mean more data is 'in flight' — sent but not yet confirmed received — at any one moment.
This number matters most for sizing TCP buffers. A TCP sender can only have as much unacknowledged data outstanding as its window size allows; if that window is smaller than the path's bandwidth-delay product, the sender is forced to pause and wait for acknowledgments even though the link itself has spare capacity, capping real throughput well below the link's rated speed. Networking engineers size TCP receive windows and router buffers using exactly this BDP figure, which is why RFC 1323 introduced TCP window scaling specifically to let window sizes grow past the original 65 KB ceiling on high-BDP paths.
Paths with a large bandwidth-delay product — a high-speed link combined with a long round-trip time, such as a satellite or transcontinental fiber route — are informally called 'long fat networks' (LFNs) in networking literature. These are exactly the paths where an undersized TCP window silently throttles a connection: the pipe is wide and long, but a small window only lets a trickle of unacknowledged data flow through it at once.
- Enter Link bandwidth (bits per second) — the link's rated capacity, for example 100,000,000 for a 100 Mbps connection.
- Enter Round-trip time (seconds) — the measured or estimated RTT for the path, such as 0.05 for a 50 ms round trip.
- Read Bandwidth-delay product (bits) and Bandwidth-delay product (bytes) — both are computed together, since buffer and window sizes are usually specified in bytes.
- Compare the bytes figure against a TCP window size to see whether that window is large enough to keep the link fully utilized without stalling for acknowledgments.
- Bandwidth must be zero or greater and round-trip time cannot be negative; the instrument will prompt you if either falls outside that range.
Worked example — a 100 Mbps link with a 50 ms round trip
Enter Link bandwidth (bits per second) = 100,000,000 and Round-trip time (seconds) = 0.05. Multiplying gives 100,000,000 x 0.05 = 5,000,000 bits of bandwidth-delay product. Bandwidth-delay product (bits) reads 5,000,000, and dividing by 8 gives Bandwidth-delay product (bytes) = 625,000.
That 625,000-byte figure is the TCP window size this path needs to keep the 100 Mbps link fully busy without stalling for acknowledgments — roughly 610 KiB. The original TCP specification capped window size at 65,535 bytes, well under this path's 625,000-byte requirement, which is exactly the kind of gap RFC 1323's window-scaling option was introduced to close on higher-bandwidth or higher-latency paths.
Questions
What is the bandwidth-delay product actually used for?
It's used to size TCP receive windows and network buffers so a connection can keep a link fully utilized. If a TCP window is smaller than the path's bandwidth-delay product, the sender runs out of permitted unacknowledged data and must pause, capping throughput below the link's rated speed even though the link itself isn't the bottleneck.
Why does the result come out in both bits and bytes?
Bandwidth is conventionally measured in bits per second, so multiplying it by round-trip time naturally yields a figure in bits. But TCP window sizes and buffer allocations are specified in bytes, so this instrument divides by 8 automatically to give the bytes figure most directly useful for sizing a window or buffer.
What counts as a 'high' bandwidth-delay product?
Networking literature calls a path with a bandwidth-delay product significantly above about 100,000 bits (12,500 bytes) a 'long fat network' (LFN), per RFC 1072 — these are typically high-speed links with long round trips, like satellite or transcontinental fiber paths, where the original 65 KB TCP window ceiling becomes a real bottleneck.
Why was the original TCP window limited to 65,535 bytes?
The original TCP header reserves a 16-bit field for the window size, and 2^16 − 1 = 65,535 is the largest value that field can hold unscaled. RFC 1323 introduced a window scaling option to multiply that value by a scale factor, letting effective window sizes grow up to roughly a gigabyte for paths whose bandwidth-delay product exceeds the original ceiling.
Does a higher bandwidth-delay product mean a worse connection?
Not by itself — it just means more data can be in flight at once, which is a property of the path (high speed, long distance, or both), not necessarily a problem. It becomes a practical issue only when the TCP window or buffer size in use is smaller than that BDP, since that mismatch is what actually throttles throughput below what the link could otherwise sustain.