Window Scaling was first introduced in RFC 1072 and refined in RFC 1323 which was then refined further in RFC 7323.

Essentially Window Scaling simply extends the 16-bit Window field to 32-bits in length.

It would not be possible to just insert an extra 16-bits to the TCP header as this would render it incompatible with other existing implementations.

The solution was to define a TCP option to specify a count by which the TCP header field should be bitwise shifted to produce a larger value.

NOTE: Window scaling can only be used when RFC-1323 is enabled as outlined here (https://support.symantec.com/en_US/article.TECH246298.html)

A count of one shifts the binary value of the field to the left by one bit, doubling it.

A count of two shifts the value two places to the left, quadrupling it.

A count of seven multiplies the value by 128.



In this manner, the 16-bit header field can be multiplied along an exponential scale to achieve more than sufficiently high values.

The image above has a Window Scale of 7.

To calculate the Window Size after the Window Scale value has been set the following formula would be used:

2^Window Scale * current Window Size = New Window Size


e.g.

If the Window Scale value is set to 6 and the current Window Size is 65,536 then the new Window Size would be:

2^6 * 65,536 = 4,194,304

The largest Window Scale value that can be set is 14; this would then allow a max Window Size of:

1,073,741,824


The Windows Scale option may only be set once during the connection by each host, in the SYN packet. The Window Size can be dynamically adjusted by modifying the value of the Window field in the TCP header, but the scale multiplier remains static for the duration of the TCP connection.

Scaling is only in effect if both ends include the option; if only one end of the connection supports Window Scaling, it will not be enabled in either direction.


To calculate the most efficient Window Size and Window Scale for a network, it is first required to know the RTT (Round Trip Time) and the Bandwidth.



The image above shows the one way delay over the network is 80ms so to get the RTT you will times this value by 2:

2*0.08 = 0.16 seconds

The Bandwidth is 10Mbps which needs to be converted to "bps":

10,000,000

0.16*10,000,000 = 1,600,000

This value is then divided by 8 (8 bits in a byte) to provide the ideal Window Size:

1,600,000/8 = 200,000 bytes

If the ideal Window Size for the communication between the two devices is 200,000 bytes, then the receiving device will need to increase its Window Size as by default with out Window Scaling configured the default Window Size is 65,536.

Below is one way that a valid Window Scale value can be calculated that will suit this environment:

Window Size set to 3,125
Window Scale set to 6

2^6 * 3,125 = 200,000

When the Window Size is set to 3,125 and the Window Scale is set to 6 then the new Window Size is 200,000.



With the ProxySG if RFC-1323 is enabled (which it is by default) the ProxySG will accept any Window Scale value set by the clients inbound connection.

For outbound connections if ADN is enabled then the SG will use the Window Scale of 6 by default.

But if ADN is disabled then the ProxySG will use the Window Scale of 1.

If ADN is disabled and it is required that the ProxySG has a larger Window Size, you cannot edit the Window Scale on the ProxySG but it is possible to change the Window Size:

#(config)tcp-ip window-size 4194304

The above example will increase the Window Size to 4,194,304. From this value it is possible to calculate what Window Scale value would be used:

2^6=64

4,194,304/64 = 65,536

So for the above example the ProxySG would be using a Window Scale value of 6.

 

Note 1: It is not possible to enable ADN on ASG proxies or SG-VA virtual appliances.

Note 2: SGOS 6.7.3.x and older - default TCP window size is 64K. Starting with SGOS 6.7.4.1 - default TCP window size has been increased from 64K to 256K. Starting with SGOS 7.2.1.1 - default TCP window size has been increased from 256K to 1MB