What is "Window Scaling" (RFC 1323) and how does it affect the ProxySG?



What is "Window Scaling" (RFC-1323)?

The RWIN value in the initial TCP specifications was limited to 2^16 (or 65535, if you start with 0). With today's fast connections, this value has proven inadequate, however the 20-byte TCP header did not have spare room for larger numbers. RFC 1323 defines some "TCP Options" to overcome limitations to the original specs. Those TCP Options are in addition to the 20-byte TCP header.

One of the most notable TCP Options is window scaling. It introduces a scale factor, by which the original RWIN value should be multiplied, in order to get the full receive window.
For example, to achieve 256960 RWIN value, TCP headers actually contain 64240 and scale factor of 4 (64240*4=256960). Any nodes that do not understand TCP Options (as defined in RFC 1323) would ignore them, and simply use the un-scaled RWIN value.
What impact might the disabled option have as a side effect?
A system wanting to use window scaling sets a TCP option containing an eight-bit scale factor. All window values used by that system thereafter should be left-shifted by that scale factor; a window scale of zero, implies no scaling at all, while a scale factor of "WS=5" implies that window sizes should be shifted five bits, or multiplied by 32. With this scheme, a 128KB window could be expressed by setting the scale factor to five and putting 4096 in the window field.
To keep from breaking TCP on systems which do not understand window scaling, the TCP option can only be provided in the initial SYN packet which initiates the connection, and scaling can only be used if the SYN+ACK packet sent in response also contains that option. The scale factor is thus set as part of the setup handshake, and cannot be changed thereafter.
It appears that some routers on the Internet or network are rewriting the window scale TCP option on SYN packets as they pass through. In particular, they seem to be setting the scale factor to zero, but leaving the option in place. The receiving side sees the option, and responds with a window scale factor of its own. At this point, the initiating system believes that its scale factor has been accepted, and scales its windows accordingly. The other end, however, believes that the scale factor is zero. The result is a misunderstanding over the real size of the receive window, with the system behind the router or firewall believing it to be much smaller than it really is. If the expected scale factor (and thus the discrepancy) is large, the result is, at best, very slow communication. In many cases, the small window can cause no packets to be transmitted at all, breaking TCP between the two affected systems entirely.
SGOS behaviour and compatibility
In all versions of SGOS 5.x higher than or equal to and, and in all versions of SGOS 6.x higher than, a ProxySG will set the window scale option to "6" on all outbound SYN packets, only if both the following are true:
RFC1323 is enabled, and
TCP window size is set higher than the default of 65535
Otherwise, the ProxySG will set a window-scale of  "0" (if RFC1323 is enabled, but TCP window-size is default or smaller), or send no window-scale option at all (if RFC1323 is disabled).
Compatibility issues were more likely to arise in earlier versions of SGOS that supported RFC1323 than those listed, where it was necessary to disable the feature entirely to achieve default behaviour of window-scale being set to "0" for outbound SYN packets. The reason for these ssues are already  described above. You (or someone upstream) might have a router or firewall not providing full RFC 1323 compatibility; hence the bad performance. If you take a PCAP (TCP-Dump) on the interface of a system, you might see a SYN packet that looks like this:
1              2010-04-14 13:42:29.003000         TCP        50704 > http [SYN] Seq=0 Win=102400 Len=0 MSS=1460 WS=6 TSV=14897848 TSER=0
The option "WS=6" means the system has RFC 1323 enabled and provides a scale factor of "6".  In a scenario where this was causing a problem, the source system would be seen to send a SYN packet with the option WS=6, but the option would be received as WS=0 at the far end of the connection. In this case, there would be a number of possible solutions. Either disable window scaling on the ProxySG, or set a default TCP window-size, or identify and replace the incompatible system.
Is it possible to disable RFC 1323 for a single connection on the ProxySG?
No it is not possible to disable RFC 1323 for just one website. The setting is a global setting and would impact all connections to and from the proxy.
How can RFC 1323 be disabled on the ProxySG?
To disable RFC 1323 on the ProxySG, you need to login to the ProxySG via serial console or via SSH session.
Enable Password:
ProxySG#config t
Enter configuration commands, one per line.  End with CTRL-Z.
ProxySG#(config)show tcp-ip
  RFC-1323 support:             enabled
ProxySG#(config)tcp-ip rfc-1323 disable
How can RFC 1323 be re-enabled on the ProxySG?
Enable Password:
ProxySG#config t
Enter configuration commands, one per line.  End with CTRL-Z.
ProxySG#(config)show tcp-ip
  RFC-1323 support:             disabled
ProxySG#(config)tcp-ip rfc-1323 enable


For information regarding RFC 1323 support on our PacketShaper product, please see 000008263.

Additional Information
Bug Number
InQuira Doc IdFAQ1006

Article Feedback

Did this Article solve your issue?
Additional Comments:
Previous MonthNext Month