TCP Window Size Calculator – Optimal Buffer and Scale Factor

This tool helps with one of the reasons why long distance file transfers are slow: the TCP window size. One reason is that the window size is often set too low for the network you’re using. The window determines how many bytes of data a sender can send across the network without getting an acknowledgement back. If the window is less than the maximum amount of data the network link holds, the link will be sitting idle waiting for acknowledgments rather than pushing more data across.

This tool figures out the right window-size based off your round-trip time and bandwidth. It will tell you what the window scale-factor should be to get this window-size. And if you know size of your window, it’ll work in reverse to show you how much throughput that window can actualy sustain. It’ll also work the other way by showing you how fast a given window will let you transfer data.

How This Tool Helps You

The TCP protocol involve a sliding-window mechanism. When a sender sends a full window of bytes, it has to stop sending them until it receives an acknowledgement. And that waiting period matter on long, high-speed connections. Consider a 30 millisecond round trip time and a 1 Gbps link. In 30 milliseconds, that link could transmit 3.75 megabytes. Now say the window size is the old default of 64 kilobytes. The sender fires off 64 KB and stops sending until acknowledgement comes back. It’s using only slightly over two percent of its possible bandwidth. The problem isn’t the wire; it’s the window.

The right window size is equal to the bandwidth-delay product. That’s the bandwidth (multiplied by the round-trip time) expressed in bytes rather than bits. To compute optimal window in bytes, take the bandwidth in bits per second, multiply it by the RTT in seconds, and divide the result by 8. In our 1 Gbps, 30 ms example, that would be: 1,000,000,000 x 0.030 / 8 = 3,750,000 bytes, which is roughly 3.75 MB. That’s how much data will be in flight if the pipe is full. That’s size needed for both the receiver’s advertised window and the sender’s socket buffer to operate the link at full speed.

You can use this calculator to instantly compute the number. You can even include imperfect conditions and some discount for header overhead. The TCP header has a window field. However, this field is just 16 bits wide, and hence the window can only be advertized as up to 65535 bytes (a.k.a. It is about 64KB. While that was OK back in 1981, this size can be stretched much higher using window scaling.

How do we solve this problem? There’s an option called window scaling defined in RFC 7323. This option are negotiated at the time of the three-way handshake, and essentially multiplies by two to the power of S bits the value of the window being advertised. Hence the maximum becomes 65535 * 2^S, where S ranges between 0 and 14. So it goes from 64KB to approximately one gigabyte.

This does one thing: it will report back to you the minimum scale factor necessary for your desired window size. The math looks like this: S = Ceiling [log base 2 (desired window size/65535)]. In the case of our 3.75 MB window we have above, we take 3,750,000 / 65535, yielding ~57. The closest power of two greater than 57 is 64, or 2 raised to the sixth power. So that means a scale factor of 6. Setting the receiving host to scale by six allow it to increase its window up to around 4 MB. That’s well over the 3.75 MB you require. If you pick an incorrect value, the window simply clamps lower but silently. By showing you the precise shift alongside the needed window size, the calculator protect against such a mistake.

Want to know the limit? Sometimes you don’t get to change the window size. In that case, you can switch over to throughput mode, which turns relationship around. Throughput in bits per second = (window in bytes × 8) / (round-trip time in seconds). So if you type in a 64 KB window on a 50 ms path, it tells you a max of roughly 10.5 Mbps. That’s a stark reminder of how badly an untuned buffer throttles your connection. It also allows you to disable window scaling so you can watch the 65535-byte cap at work. Prove exactly what an old or misconfigured stack is costing you.

Each calculation is summed up on four cards: the best-fit window; the scale-factor that unlocks a specific ceiling; the bandwidth-delay product (in both raw bytes and convenient units); and throughput (either the specified rate itself if specified, or what selected window will sustain in reverse mode). To help visualize this, the segments card calculates how many full TCP segments are flying around. A window of 250 KB with a typical MSS of 1460 bytes contains roughly 176 segment. The bottom panel breaks down all numbers we substitute into the formulas for your reference in case you want to do math yourself.

Those presets cover many common problematic cases. They include cross-country data-center replication links and geostationary satellite hops with a 600 ms round trip. They also include transatlantic transfers, metro fiber, office Wi-Fi, and a gigabit LAN where the default window isn’t a problem. And they demonstrate how rapidy the needed scale factor and window rise as your latency increases.

The message is clear. Wherever you have a long fat network, buffer both ends up to at least the bandwidth-delay product. Verify that window scaling is enabled. And ensure that packet loss remains extremely low since a big window only benefits if those packets aren’t constantly getting retransmitted. Com. Pick a preset, tweak the RTT and bandwidth to fit your link, then read off what window and scale factor will be needed for TCP to hum along at full speed.

You should of used this earlier!