TCP Window Scale

Frequently Asked Questions
Post Reply
Peter
Posts: 648
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

TCP Window Scale

Post by Peter » 11 Nov 2011, 12:48

This FAQ applies to:
  • Clavister CorePlus. Any version.
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 retransmissions
  • 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 retransmitted the SYN a few times. Per default Windows sends two SYNs with window scale option and the one SYN without the option, unless this behaviour 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 behaviour cause problems for any device on the path that tries to learn the result of the negotiation for instance our SGWs (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 retransmissions. 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:

    Code: Select all

    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 retransmitted SYN from the host without any window scale options. The value of effective indicates that the SGW 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 SGW might still be able to make the right decisions so that it can apply the same scaling as the hosts. If the SGW 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 SGW.

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 SGW to strip the window scale option.

Configuring the SGW to strip the window scale option can always be used to decide whether the SGW's handling of window scaling is the cause to the problem or not. If stripping the window scale does not help then it is not the SGW's handling of window scaling that causes the problem.

Peter
Posts: 648
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

Re: TCP Window Scale

Post by Peter » 20 Nov 2013, 16:31

Update 2013-11-20:

An example when you can get "Window_Scale_Adjust" in the logs is if you have the following rule configuration:

Code: Select all

SAT Wan All-nets Core IP_Wan Service=RDP SetDest=Server_2
Allow Wan All-nets Core IP_Wan Service=RDP
A basic setup where you allow RDP to an internal server using RDP. In this particular scenario a customer saw in the log events about "TCP_Window_Scale" and "old=8, new=not_used, effective=not_used. ". This log event was visible when using Win7, Win8 and Win2008, but not when using Windows XP.

The cause of the problem was a mistake in the SAT rule, destination server was supposed to be "Server_1" instead of 2.

It may be that Win7 and above is per default trying to use a high Window_Scale that results in an adjust log. It may also be that the log is always present but the administrator only takes notice of it when something is not working correctly.

Post Reply