Bandwidth-Delay Product Calculator — Bits in Flight and TCP Window Size

Background.

The bandwidth-delay product is the amount of data a network path holds in flight at any instant — bits that have left the sender and not yet been acknowledged. RFC 6349 defines it in one sentence: the product of a data link's capacity in bits per second and its end-to-end delay in seconds. Multiply, and you have the number of bits the pipe contains. It matters because TCP will only ever have one receive window of unacknowledged data outstanding, so if the window is smaller than the BDP, the sender stalls waiting for acknowledgements and the link sits idle no matter how fast it is.

That is the whole explanation for the most common complaint in networking: a fast link that feels slow over distance. The default here shows it in one line. A 1 Gbps path with a 100 ms round trip holds 100,000,000 bits — 12.5 million bytes — in flight. A TCP receiver that has not negotiated window scaling can advertise at most 65,535 bytes, because the header's Window field is 16 bits wide. Divide that window by the round trip and a single connection tops out at 5.24 Mbps: about half of one percent of a gigabit link. Nothing is broken, nothing is congested, and the file still crawls.

The fix is RFC 7323's window scale option, which multiplies the advertised window by a power of two agreed at connection setup. This calculator reports the shift count needed to cover the BDP — 8 at the defaults, meaning the window must be scaled by 256. The option's exponent is capped at 14, giving a maximum window of 1 GiB, so on extreme paths (400 Gbps across an ocean, say) even a fully scaled single flow cannot fill the pipe and parallel streams become the only answer. The calculator saturates the shift at 14 and says so rather than reporting an impossible value.

Units are given four ways on purpose, because this is where the arithmetic usually goes wrong. Link rates are always bits per second with decimal prefixes: a megabit per second is 10⁶ bit/s. Window sizes are always bytes. Dividing bits by eight is therefore mandatory, not optional. And once you are in bytes, kB and KiB diverge — 1,000 versus 1,024 — which is why the BDP appears here in both. RFC 6349 quotes its T3 example's required window as about 138 KB in the decimal sense; the same figure is 134.9 KiB in the binary sense your operating system's buffer settings probably use.

One scope note. The RTT you enter should be the one TCP actually experiences, which is not always the idle ping figure. Queueing at a congested hop inflates round-trip time, sometimes by an order of magnitude, and an inflated RTT inflates the BDP proportionally. Likewise, the bandwidth to use is the bottleneck — the narrowest hop on the path — not the capacity of your own access link. And the ceiling this page reports is a window-limited ceiling only: it assumes no loss. Real throughput on a lossy long path is usually far lower, because congestion control shrinks the effective window on every loss event, which is exactly why loss hurts long paths so much more than short ones.

What is bandwidth-delay product calculator?

The bandwidth-delay product is capacity multiplied by delay, and the result is a quantity of data rather than a rate. RFC 6349 gives the formula as BDP in bits equals round-trip time in seconds times bottleneck bandwidth in bits per second. Physically, it is the volume of the pipe: how many bits are simultaneously somewhere on the wire, in a queue, or in a buffer between the two endpoints. Its practical importance comes entirely from how sliding-window protocols work. TCP allows a sender to have at most one receive window's worth of unacknowledged data outstanding at any moment. If that window is smaller than the BDP, the sender transmits a window, stops, and waits a full round trip for the first acknowledgement before it can send more — so its maximum rate is window divided by round-trip time, regardless of how much capacity is available. Networks where the BDP is large relative to a default window are called long fat networks, and they are common: any intercontinental path, any satellite link, and any high-speed link over more than a few hundred kilometres qualifies. The historical constraint is the TCP header itself, whose Window field is only 16 bits wide and therefore cannot express a window above 65,535 bytes. RFC 7323's window scale option removes that ceiling by agreeing a left-shift at connection setup, up to a maximum exponent of 14, which allows windows up to 1 GiB.

How to use this calculator.

1. 01Enter the bottleneck bandwidth — the capacity of the slowest hop between the two endpoints, not your own link speed. If a 100 Mbps hop sits in the middle of a gigabit path, enter 100 Mbps.
2. 02Enter the round-trip time in milliseconds, as ping reports it. Prefer the RTT measured under load: queueing inflates delay, and the inflated figure is the one TCP experiences.
3. 03Enter the TCP receive window in bytes. Leave it at 65,535 to see what an unscaled connection can do; raise it to your configured buffer size to see what your actual system will reach.
4. 04Read the BDP in bytes — that is the minimum window a single flow needs to keep the path full — and compare it to the window you entered.
5. 05If the verdict says window-limited, use the reported window scale shift. A shift of 8 means the advertised window is multiplied by 256, so 65,535 becomes just under 16.8 MB.
6. 06If the shift reads 14, the path's BDP exceeds the largest window TCP can express. No single connection can fill it; use parallel streams or a protocol that is not window-bound.

The formula.

Start by putting both terms in base units. Capacity converts to bits per second with decimal factors — Kbps × 10³, Mbps × 10⁶, Gbps × 10⁹ — and round-trip time converts from milliseconds to seconds by dividing by 1,000. Multiply them and the result is bits, because bits-per-second times seconds cancels the seconds. That is the BDP, exactly as RFC 6349 writes it.

Divide by eight for bytes, because every window and buffer size in every operating system is in bytes while every link rate is in bits. This single division is the most common error in the whole topic, and it is a factor of eight in either direction. From bytes, divide by 1,000 for decimal kilobytes or by 1,024 for binary kibibytes; both are shown because the sources disagree — RFC 6349 quotes its own example in decimal KB, while socket buffer settings are conventionally binary.

The throughput ceiling comes from the sliding window. A sender may have at most one window of unacknowledged bytes outstanding, so in the worst case it sends a window, then waits one full round trip for the acknowledgement that frees it. Its long-run rate is therefore window ÷ RTT. Converted to bits per second that is window × 8 ÷ RTT. This calculator caps that at the link rate, because a window larger than the BDP does not make the link faster — it simply stops being the binding constraint — and reporting utilisation above 100% would be meaningless.

The window scale shift is found by iteration rather than by a logarithm, so the answer is an exact integer. It is the smallest exponent s from 0 to 14 for which 65,535 × 2ˢ is at least the BDP in bytes. Sixty-five thousand five hundred and thirty-five is not arbitrary: RFC 7323 states that the TCP header uses a 16-bit field to report the receive window, so the largest window that can be used is 2¹⁶, and the largest value the field can actually hold is 65,535. The exponent ceiling of 14 is also stated in that RFC, which caps the maximum permissible receive window at 1 GiB.

What this arithmetic does not model. It assumes a lossless path. Real TCP congestion control halves or otherwise reduces its effective window on loss, and on a long path each reduction costs a full round trip to recover from, so measured throughput on a lossy long fat network falls far below the window-limited ceiling — that sensitivity is the reason loss on intercontinental paths is so much more damaging than the same loss rate across a data centre. It also ignores the sender's own send buffer, which must be at least as large as the receive window for the window to be usable, and it assumes a single flow: n parallel connections each get their own window, which is precisely why download accelerators and parallel-stream file transfer tools exist.

A worked example.

Frequently asked questions.

References& sources.

1. [1]RFC 6349, 'Framework for TCP Throughput Testing' (IETF, 2011), §2. Source of the definition implemented here — 'Bandwidth-Delay Product (BDP) refers to the product of a data link's capacity (in bits per second) and its end-to-end delay (in seconds)' — the expression 'BDP (bits) = RTT (sec) x BB (bps)', and the worked example of a 44.21 Mbps T3 at 25 ms RTT giving approximately 1,105,000 bits and a minimum required receive window of about 138 KB. This calculator returns 1,105,250 bits and 138.15625 kB for those inputs.
2. [2]RFC 7323, 'TCP Extensions for High Performance' (IETF, 2014). Source of both window constants: 'The TCP header uses a 16-bit field to report the receive window size to the sender. Therefore, the largest window that can be used is 2^16 = 64 KiB', and 'The maximum scale exponent is limited to 14 for a maximum permissible receive window size of 1 GiB (2^(14+16))'. The shift count reported by this calculator is the smallest exponent in that range covering the computed BDP.
3. [3]RFC 9293, 'Transmission Control Protocol (TCP)' (IETF, 2022). The current TCP specification, which obsoletes RFC 793 and six other documents. Source of the header layout containing the 16-bit Window field and the Data Offset field discussed above.
4. [4]RFC 5136, 'Defining Network Capacity' (IETF, 2008). Establishes what the bandwidth term in the BDP formula must be read as — IP-layer capacity, 'the maximum number of IP-layer bits that can be transmitted … divided by I' — and warns that 'literature often overloads the term bandwidth to refer to what we have described as capacity in this document'.
5. [5]NIST, 'Prefixes for binary multiples'. Source of the kB versus KiB distinction the two byte outputs make explicit (kibi = 2¹⁰ = 1,024), and of the convention that for a megabit per second 'all telecommunications engineers use it to mean 10⁶ bit/s'.