TCP Configuration: Windows Scale Options

There are many ways to configure the way TCP/IP operates on specific networks.  Some of these parameters are rarely used but when you’re running fast Gigabit networks with a wide variety of network hardware and infrastructure some options are extremely useful.  One of those is the Windows Scale option which can be used to modify the definition of the TCP Window from it’s default of 16 bits.

For example in some environments it may be appropriate to increase the size of the TCP windows to 32 bits.   What actually happens is that instead of changing the size of the header to allow the larger windows, the header still holds a 16-bit value.   However an option allows a scaling parameter to be applied to the value which allows TCP to maintain the actual value of 32 bits internally.

The option for scaling can only appear in the SYN segment of the transaction which means that the scaling value by definition will be fixed in both directions when the connection is initially established.   In order for window scaling to be enable both ends of the connection must include the option in their SYN segments.   It should be noted thought that the scale option can be different in each direction.

There are methods for allowing suitable communication between different levels of hardware.   For example the scaling factor can be reduced by sending a non zero scale factor which cancels the scaling if a windows scaling option is not received in the return SYN.   This behaviour is specified in the relevant RFC which specifies that TCP must accept these options in any segment.   This includes all sorts of of connection remember these can be across wide areas, imagine a US IP address connecting to a Netflix server on super fast hardware.   However it should also be noted that TCP/IP will always ignore any option that it doesn’t understand.

For illustration, if the windows scale option is being used with a shift count of X for sending and Y for receiving.  This would mean that every 16 bit window which is advertised would be left shifted by Y bits to obtain the real advertised window.  So every time a windows advertisement is sent then we’d also take the 32 bit windows size and right shift by X bit to discover the real 16 bit value which is in the TCP header.

Any shift count is automatically controlled by TCP, which is because the size of the receiving buffer is important and cannot be controlled by the other size of the connection.

Further Reading

TCP Tricks, receiving BBC iPlayer in France – http://bbciplayerabroad.co.uk/how-do-i-get-bbc-iplayer-in-france/

 

Leave a Reply

Your email address will not be published. Required fields are marked *