Bandwidth Delay Product Calculator
Find out how big a receive window a link needs, and what a small window costs you in throughput.
What it does
A link with a lot of capacity and a long delay has a trap in it. The sender cannot send more than a window of data before it has to wait for an acknowledgement, so if the window is smaller than the amount of data in flight when the acknowledgements come back, the link sits idle. The size of that amount is the bandwidth delay product, and the older tuning guides from Lawrence Berkeley National Laboratory put it plainly: buffer size equals bandwidth times round trip time.
The arithmetic is short. Multiply the bandwidth in bits per second by the round trip time in seconds and you get the number of bits that have to be outstanding, and divide by eight for bytes. A 100 megabit link with a 50 millisecond round trip time gives 5,000,000 bits, which is 625,000 bytes.
The consequence shows up as a throughput ceiling. A sender with a 64 kilobyte window and a 50 millisecond round trip time can have 65,536 bytes in flight, and the rule of thumb for the rate is the window divided by the round trip time, so the link can never carry more than about 10.7 megabits a second even though it could carry 100.
TCP copes with this by scaling its window field. RFC 7323 explains that the header carries a 16 bit window field, and that the extension expands the definition of the window to 30 bits, with a scale factor of up to 14 giving a maximum of one gibibyte. RFC 6928, on the other hand, is about the initial congestion window, which is a different problem from a long fat network.
Real paths are not so tidy. Loss, congestion control, the speed of the receiver and any middlebox that does not understand window scaling all pull the real number down, and RFC 7323 warns that a firewall which strips the window scale option leaves the two ends with different ideas about the window.
How to use
- Enter the bandwidth of the slowest link on the path.
- Enter the round trip time, which is the ping time, not the one way delay.
- Enter the receive window in kilobytes, or leave it at zero to see what is needed.
- Read the bandwidth delay product and the window the link needs.
- Compare the window you have with the window you need.
- Read the throughput ceiling that the window imposes.
Formula
- BDP
- Bandwidth delay product, the bytes that must be in flight to fill the link.
- Window
- TCP receive window, the amount of unacknowledged data the sender may have outstanding.
- RTT
- Round trip time, the time for data and its acknowledgement to make the round trip.
The throughput rule is a ceiling rather than a promise. Congestion control, packet loss and the processing speed of the receiver can all hold the real rate below it, and the window on one end of the path is what limits the sender. The largest window TCP can express is one gibibyte, which is the field value of 65,535 multiplied by a scale factor of 16,384.
Worked example
Example: 100 Mbps with a 50 ms round trip time
Defaults: 100 Mbps, 50 ms and a 65,535 KB window, which is the largest an unscaled 16 bit field can carry.
- Bandwidth delay product: 100,000,000 x 0.050 = 5,000,000 bits.
- In bytes: 5,000,000 / 8 = 625,000 bytes.
- So the window has to be at least 625,000 bytes, which is 610.4 KB.
- With a 65,535 KB window the throughput ceiling is 65,535 x 1024 x 8 / 0.050, which is far above the link, so the link is the limit.
- The window is 107 times what the link needs, so it is big enough.
- The tool shows 625,000 bytes, 610.4 KB, 100.00 Mbps and a window that is big enough.
Reference table
| Round trip time | Window needed | Throughput with a 64 KB window |
|---|---|---|
| 10 ms | 122.1 KB | 52.43 Mbps |
| 50 ms | 610.4 KB | 10.49 Mbps |
| 100 ms | 1,220.7 KB | 5.24 Mbps |
| 200 ms | 2,441.4 KB | 2.62 Mbps |
Limits
- Describes the window limit only, so it is an upper bound on the throughput rather than a prediction.
- Assumes one window scaling factor for the whole path, which is how TCP negotiates it.
- Says nothing about the actual round trip time changing, which is what congestion looks like.
- Leaves out any middlebox that removes the window scale option and caps the connection much lower.
Common mistakes
- Using the one way delay instead of the round trip time, which halves the product.
- Mixing megabits and megabytes, which changes the answer by a factor of eight.
- Reading the throughput ceiling as the speed the link will actually give you.
- Forgetting the overhead of the headers and the acknowledgements, which eat into the useful data rate.
- Ignoring that a long path with many hops can still have a small window if a middlebox removes the scale option.
Try it yourself
Quick checks. Answers sit tucked under each question.
What window does a 1 Gbps link with a 10 ms round trip time need?
The product is 1,250,000 bytes, so the window has to be at least 1,220.7 KB.
What does a 64 KB window allow on a 100 Mbps link with a 50 ms round trip time?
65,536 bytes divided by 0.050 seconds is 1,310,720 bytes a second, which is 10.49 Mbps, about a tenth of the link.
Why do long distance links need bigger windows?
Because the product grows with the round trip time. At 200 ms the window has to be 2,441.4 KB, and a 64 KB window would then limit the link to 2.62 Mbps.
Questions
What is the bandwidth delay product?
The bandwidth times the round trip time. It is the amount of data that has to be in flight at once for a link to run at its full speed.
Why does a long delay need a bigger window?
The sender has to wait for each acknowledgement before it can send more. A longer round trip time means more data is outstanding at any moment, so the window has to grow to match.
What is the largest TCP window?
One gibibyte. The 16 bit header field is scaled by a factor of up to 2 to the power 14, so 65,535 x 16,384 gives the maximum.
Is the throughput ceiling the real speed?
No, it is the most the window allows. Loss, congestion control and the receiver all pull the real rate below it, and on a long path a middlebox that strips the scaling option can cap it far lower.
What is window scaling for?
It is the TCP extension that lets the receiver advertise a window bigger than 64 kilobytes by sending a scale factor in the handshake. RFC 7323 describes the limits and the middlebox problems.
Does this apply to everything on the internet?
It applies wherever the round trip time is long enough for the window to be the limit, which is why it matters on satellite and long distance paths and much less on a local network.
Sources
- RFC 7323: TCP window scale option
- RFC 6928: increasing the TCP initial window
- Lawrence Berkeley National Laboratory: TCP tuning guide background