The bandwidth delay product calculator above multiplies a link's bandwidth by its round-trip time to give the amount of data that is in flight on the path at any instant. That figure is the size a TCP window has to reach before a single connection can keep the pipe full, and it explains almost every case of a fast link delivering disappointing single-stream throughput.
Arb Digital builds free tools that answer one question precisely. This page answers the in-flight question and the window-sizing question that follows from it. It is not a capacity planner: the bandwidth requirement calculator is the tool for deciding what connection speed a group of users needs, and it deliberately leaves the bandwidth delay product out of scope. This page picks that up where the other one stops.
What the Bandwidth Delay Product Actually Is
Think of the path as a pipe. Bandwidth is the cross-section, delay is the length, and the product is the volume. Data you have sent but not yet had acknowledged is sitting somewhere in that volume, and a sender that is only allowed a smaller amount of unacknowledged data than the pipe holds must stop and wait, leaving the link idle for part of every round trip.
That is the whole of the sliding-window argument. Throughput for one connection is the window divided by the round-trip time. If the window equals the bandwidth delay product, the sender can keep transmitting continuously and the link runs at capacity. If the window is half the product, throughput is half the link rate, and no amount of extra bandwidth changes that.
The consequence people find counter-intuitive is that adding bandwidth to a long path can achieve nothing at all. A window-limited transfer at 400 Mbit/s on a 1 Gbit/s link will still run at 400 Mbit/s on a 10 Gbit/s link, because the limit was never the link. This is why the IETF's Framework for TCP Throughput Testing, RFC 6349, makes the bandwidth delay product the starting point of any throughput test rather than an afterthought.
How to Use It
- Enter the bottleneck bandwidth. The slowest hop on the path governs, so a gigabit interface at each end means nothing if the middle is a hundred megabits.
- Measure the round-trip time on an idle path. Queueing under load inflates latency, and a value measured during congestion overstates the product.
- Enter the window you actually have. On most systems this is the receive socket buffer, which the operating system may auto-tune within limits you can inspect.
- Set a realistic loss rate, or zero. Loss imposes a separate ceiling that a larger window cannot lift, and on long paths even a tiny rate matters.
- Compare the three ceilings. The lowest one is what you will actually see, and it tells you which knob is worth turning.
The Formula: How It Is Calculated
The bandwidth delay product in bits is the bandwidth in bits per second times the round-trip time in seconds. Divide by eight for bytes, and by 1,024 for kibibytes. The window scale factor needed is the smallest power of two that lifts the 65,535-byte unscaled window ceiling to at least the product, so it is the base-two logarithm of the product in bytes divided by 65,535, rounded up and clamped to the maximum of fourteen the protocol allows.
The window ceiling on throughput is the window in bytes times eight, divided by the round-trip time in seconds. The loss ceiling uses the Mathis relation, which approximates the average rate of a loss-driven TCP flow as the square root of three halves, times the maximum segment size, divided by the round-trip time and by the square root of the loss probability.
Work the defaults. A 1 Gbit/s link with an 80 ms round trip holds 1,000,000,000 times 0.08, which is 80,000,000 bits, or 10,000,000 bytes, about 9,765.6 KiB or 9.54 MiB. Dividing by 65,535 gives 152.6, whose base-two logarithm is 7.25, so a scale factor of 8 is needed. A 4,096 KiB window is 4,194,304 bytes, giving a ceiling of 4,194,304 times 8 divided by 0.08, which is 419.43 Mbit/s: well under half the link. At 0.001 per cent loss the Mathis ceiling is about 56.5 Mbit/s, which is lower still, so loss is the binding constraint in that scenario rather than the window.
Window Scaling, and the 65,535-Byte Wall
The TCP header's window field is sixteen bits wide, which caps the advertised window at 65,535 bytes. On a 100 ms path that is a hard ceiling of about 5.2 Mbit/s for one connection, which was generous in 1981 and is absurd now. RFC 7323, TCP Extensions for High Performance, defines the window scale option that fixes it, by negotiating a left-shift applied to the advertised value.
Two details of that mechanism cause real problems. The scale factor is exchanged only in the SYN and SYN-ACK, so both ends must support it and both must have it enabled at connection setup; it cannot be turned on later. And any middlebox that rewrites the handshake without understanding the option can leave the two ends disagreeing about the shift, which produces a connection that stalls or corrupts rather than one that simply runs slowly.
This is why the scale factor is worth reading off directly. A path needing a factor of eight is asking for a 256-fold multiplier on the window field, and if anything along the path is stripping the option, that path will be stuck at a few megabits per second while every interface counter looks healthy.
Why Loss Punishes Long Paths So Hard
The Mathis relation contains the round-trip time in the denominator and the square root of the loss rate as well, so doubling the latency halves the achievable rate and quadrupling the loss halves it again. On a short path a loss rate of a tenth of a per cent is barely noticeable; on a 200 ms intercontinental path it is catastrophic for a single classic TCP flow.
This is the mechanism behind the familiar observation that a transfer runs at full speed across the country and crawls across an ocean over the same nominal bandwidth. It also explains why parallel streams help: each flow gets its own window and its own loss-recovery cycle, so ten streams can collectively achieve what one cannot, without any change to the link at all.
The relation is an approximation for loss-based congestion control such as Reno and, roughly, CUBIC. Delay-based and model-based algorithms behave differently, and modern stacks may substantially outperform it. Treat the loss ceiling here as an order-of-magnitude warning rather than a prediction, and treat a measured result that beats it as evidence about the algorithm rather than an error.
Where the Simple Model Stops Being True
Buffers are the first complication. Setting a window far above the bandwidth delay product does not increase throughput; it fills queues along the path, inflates the round-trip time and makes everything else on the link feel worse. That is bufferbloat, and it is the reason the correct target is the product rather than the largest number the system will accept.
Autotuning is the second. Most modern operating systems adjust the receive buffer dynamically within a configured maximum, so the useful question is usually whether that maximum is above the bandwidth delay product, not what the buffer happens to be right now. The third is that a shared bottleneck means your fair share, not the link rate, is what should go into the calculation.
How This Page Sits Beside the Other Network Tools
The boundary in one sentence: this page explains why a single connection cannot fill a link, while the bandwidth requirement calculator decides how much link to buy for a population of users. The two answer opposite questions and share no inputs beyond bandwidth itself.
Rescale rate units with the bandwidth converter, size video streams with the streaming bitrate calculator, and look at the physical component of latency with the propagation delay calculator. For serial links where framing rather than window size sets the ceiling, the baud rate calculator covers the equivalent arithmetic, and the RAM latency calculator handles the same in-flight idea inside a machine.
Arb Digital builds free tools like this one because useful pages earn attention. If you want tools, calculators or content built for your own audience, we can help.
See Our Web Design Work Talk to Arb DigitalCommon Mistakes to Avoid
- Using the interface speed instead of the bottleneck — the slowest hop governs, and it is often nowhere near either endpoint.
- Measuring round-trip time under load — queueing inflates latency, so a congested measurement overstates the product and the window you need.
- Confusing bits with bytes — bandwidth is quoted in bits per second and buffers in bytes, and the factor of eight between them is the single most common arithmetic slip here.
- Setting the window as large as possible — anything above the product fills queues rather than adding throughput, and hurts every other flow on the path.
- Blaming the link when loss is the constraint — a tiny loss rate on a long path caps a single flow far below both the link rate and the window ceiling.
Related Free Tools From Arb Digital
Size a connection for a user population with the bandwidth requirement calculator, convert between rate units with the bandwidth converter, and plan video with the streaming bitrate calculator. The propagation delay calculator covers the physical part of latency, the baud rate calculator covers serial link throughput, and the RAM latency calculator applies similar reasoning to memory. Browse the full free online tools hub for everything else.
Frequently Asked Questions
It is the amount of data that fits on the path at one moment, found by multiplying the bottleneck bandwidth by the round-trip time. A sender has to be allowed that much unacknowledged data in flight before it can keep the link continuously busy.
Usually because the TCP window is smaller than the bandwidth delay product, so the sender stalls waiting for acknowledgements. Throughput for one connection is the window divided by the round-trip time, and no extra bandwidth changes that ceiling.
The window field in the TCP header is sixteen bits, capping the advertised window at 65,535 bytes. The window scale option defined in RFC 7323 negotiates a left-shift at connection setup so larger windows can be expressed. It must be agreed in the handshake and cannot be enabled later.
No. A window above the bandwidth delay product does not add throughput; it fills queues along the path, raises latency for everything sharing the link and can make performance worse. The product is the target, not a floor.
It is an approximation. The Mathis relation models loss-based congestion control and gives a useful order of magnitude, but modern algorithms behave differently and can exceed it. Treat it as a warning that loss is binding rather than as a predicted speed.
Because each connection has its own window and its own recovery cycle, so several flows can collectively occupy a pipe that a single window-limited or loss-limited flow cannot fill. The link has not changed; the number of independent ceilings has.
The in-flight arithmetic applies to any protocol with a bounded amount of unacknowledged data, including QUIC, which has its own flow-control limits. The window scale specifics are a TCP header detail and do not carry over.
Whichever is genuinely the bottleneck. If a path is shared, the honest input is your fair share rather than the physical rate, because that is what the connection can actually claim during a transfer.
