The TCP Window Scale Log Event

Question

I’m getting “TCP window scale” log events, what is the cause of this?

Answer

Unfortunately there is no simple answer to this question and in order to give a more detailed answer to what this is we have to go deeper in explaining the function itself.

Overview

TCP window scale is used to extend the range of the announced receive window. TCP window scale is an option that is negotiated between the client and the server.

Example of successful negotiation

• 1. The negotiation begins when a client includes the TCP window scale option in its SYN packet(s). This means that the client is prepared/supports window scaling and it also contains the scale that the client will use if window scaling is successfully negotiated. The window in the SYN, any packet with the SYN flag set, is never scaled.
  
  2. If the server that receives the packet supports window scaling (and is configured to allow/use window scaling), then it will include a window scale option in the SYN-ACK that it send as reply to the received SYN. The scale in the SYN-ACK is the scale that the server will use. As far as the server is concerned, window scale is now negotiated.
  
  3. The client receives the SYN-ACK with window scale option from the server and concludes that window scaling has been successfully negotiated and from here on applies the scale announced in step 1 to all window announcements that it sends.

Example of failed negotiation

• 1. The negotiation begins when a client includes the TCP window scale option in its SYN packet(s). This means that the client is prepared/supports window scaling and it also contains the scale that the client will use if window scaling is successfully negotiated. The window in the SYN, any packet with the SYN flag set, is never scaled.
  
  2. The server does not support window scaling so it ignores the options and sends a SYN-ACK without window scaling option.
  
  3. The client receives the SYN-ACK without window scale option from the server and concludes that the window scaling negotiation has failed and continues to send window announcements without applying any window scale.

Possible issues

Hosts stop sending the option after a few retransmission’s

• TCP window scaling is an extension to the TCP protocol. This means that there might be network devices that does not support this option. This should not be a problem as long as they have the generic support for TCP options, which all implementations should have. However, it is possible that some devices will not be able to handle SYNs with this option at all. This is probably the reason why some clients, for instance, Microsoft Windows, and even some servers will stop including any window scale option once it has re-transmitted the SYN a few times. Per default Windows sends two SYNs with window scale option and the one SYN without the option, unless this behavior has been changed recently.
  
  Even if the SYN that is eventually sent without window scale option makes it to the peer ,in contrast to SYNs sent with the option, this would still introduce a noticeable delay in establishing the connection. This behavior cause problems for any device on the path that tries to learn the result of the negotiation for instance our Firewall's (Security Gateway) and commonly results in Mismatching TCP window scale logs.

Log entry: “Mismatching TCP window scale”

This log is triggered when not all SYNs in one direction are identical with respect to TCP window scale options. Usually caused by the workaround to stop sending the option after a few retransmission’s. The log tells what the previous decision regarding window scale was (old), what the new packet claims (new) and what the new decision is (effective).

Example:

old=8, new=not_used, effective=not_used.

In this case the host has previously announced that it is going to use 8 as window scale but we have now received a re-transmitted SYN from the host without any window scale options. The value of effective indicates that the Firewall will act as if all SYNs from that host (on this particular connection) did not include any window scale option.

This log is not necessarily a sign of problems; the Firewall might still be able to make the right decisions so that it can apply the same scaling as the hosts. If the Firewall makes the wrong decision then that should result in “TCP sequence number too high” logs and reduced throughput on the connection. This log is vital information when investigating such logs.

Can this cause connection failures/delays?

If the systems are unable to establish any TCP connection at all then this is likely not the cause; the log is just a sign that the client (or server) is trying to use the fall-back to not use window scaling to see if the use of the window scale option is the reason it can’t connect. The real problem is likely something else, for instance, routing, or somewhere outside the Firewall.

If there is a significant delay in establishing the connection but the connection eventually gets established the there might be some other device in the network (or even the server) that can’t handle window scaling resulting in that the first SYNs with window scaling are dropped. This can be fixed by configuring the clients to not use window scaling or configuring the Firewall to strip the window scale option.

Configuring the Firewall to strip the window scale option can always be used to decide whether the Firewall’s handling of window scaling is the cause to the problem or not (this is done with the TCP advanced setting WSOPT). If stripping the window scale does not help then it is not the Firewall’s handling of window scaling that causes the problem.

Related articles