I have been investigating network performance problems on a W2k8-R2 system and found they are due to TCP Window Scaling NOT always being enabled when a Win7 client connects to a W2k8-R2 server. Similar behavior has been observed between two W2k8-R2 servers. Below is a description of a test that can be used to reproduce the problem, as well as a summary of a Wireshark capture taken on the client. All systems have the latest service pack and hot fixes installed. Test: Win7 client connects, disconnects, and reconnects to a file share on a W2k8-R2 server. Both systems are connected directly to the same 1 Gb Ethernet switch on a private LAN. Initially both systems are shutdown. Prior to being shutdown the server shared a folder. The client is booted, logged in, and Wireshark is started. Then the server is booted and logged in. · The first time the client connects it negotiates window scaling in the SYN segment, with an initial window size of 66048. · The second time the client connects, it does not include the scaling option in the SYN segment. · A disconnect and third connect negotiates window scaling again. · Another disconnect and re-connect does not use scaling. This cycle is quite reproducible. Operation Flags Window size Calculated window size Window Scale (Shift Count) Scaling Factor Multiplier RTT (seconds) RTT Msec Win7 client maps share on W2k8-R2 server SYN 8192 8192 8 256 Server response SYN, ACK 8192 8192 8 256 0.000108 0.108 Client ACK 258 66048 256 0.000150 0.150 Lots of SMB and SMB2 packets Disconnect the share RST, ACK Win7 client maps the same share on the W2k8-R2 server SYN 8192 8192 N/A N/A Server response SYN, ACK 8192 8192 N/A N/A 0.000082 0.082 Client ACK 64800 64800 N/A 0.000110 0.11 After confirming that scaling was enabled, Robocopy was used to push a 3 Gb iso file from the client to the server. Initially the calculated window size was 66048. This varied throughout the copy, reaching values in excess of 13,000,000. Prior to the SYN, I observed several packets being exchanged (LLMNR, ICMPv6, ARP, NBNS) which I assume determine whether or not scaling is used. When scaling is NOT enabled, it takes three times longer to copy the same file. This is a major performance problem. What if anything can be done to force scaling to always be used? Thank you, David Schwartz

Hi David, Thank you for your post. By default, TCP Window autotuning feature is enabled for all windows connections. I'd like to know two things listed below: 1. Run command "netsh int tcp show global" on your servers and clients, check if Windows Auto-Tuning Level set to normal and post the result to us 2. Although you mentioned that all systems have the latest patches installed, please double check or try to install KB983528 on your systems If there are more inquiries on this issue, please feel free to let us know.Regards, Rick Tan

Hi Rick, I did quite a bit of research on this prior to posting, and verified the server and client auto-tuning settings, as well as the hot fixes and version information for Tcpip.sys and Fwpkclnt.sys. netsh output on Server: >netsh int tcp show global Querying active state... TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : enabled Chimney Offload State : automatic NetDMA State : enabled Direct Cache Acess (DCA) : disabled Receive Window Auto-Tuning Level : normal Add-On Congestion Control Provider : ctcp ECN Capability : disabled RFC 1323 Timestamps : disabled netsh output on client: Querying active state... TCP Global Parameters ---------------------------------------------- Receive-Side Scaling State : enabled Chimney Offload State : automatic NetDMA State : enabled Direct Cache Acess (DCA) : disabled Receive Window Auto-Tuning Level : normal Add-On Congestion Control Provider : none ECN Capability : disabled RFC 1323 Timestamps : disabled The file properties details version info shows newer versions than those described in KB983528: W2k8-R2 Server Tcpip.sys: Version 6.1.7601.17514, Date 11/20/2010 Fwpkclnt.sys: Version 6.1.7601.17514, Data 11/20/2010 Win7 Client Tcpip.sys: Version 6.1.7601.17638, Date 6/21/2011 Fwpkclnt.sys: Version 6.1.7601.17514, Data 11/20/2010 The hot fix msu file is dated 5/13/2010 which is older than the installed drivers. If I try to install the hot fix I get a message that it is not applicable to my computer. Window scaling is enabled 50% of the time I map the share, and of course is disabled the other 50%. I am using the same client, server, and private LAN (and not running any load), so this makes no sense. Can you tell my what criteria are used to determine whether to enable scaling in the SYN packet? I have searched all over the web and read the applicable sections in the Microsoft Press Book "W2k8 TCP/IP Protocols and Services" and can find no documentation on this. You should be able to use the test I described above to reproduce the problem. While this is a contrived test, I do have customers that are experiencing real world performance problems when Windows decides not to enable scaling in the SYN segment. Thank you, David Schwartz David Schwartz

I am seeing similar issues on wireshark captures from a Windows Server 2008 R2. I'm curious as to why the window is being set so low with a 256 multiplier. The 256 multiplier seems to be consistent.

I was able to repro the issue, I Set the Autotuning level to restricted and tested and the problem did not occur. can you test that at your end? Sumesh P - Microsoft Online Community Support

In my testing, when we set the Autotuning level to restricted, we did not see the issue. I am only able to reproduce this with IPv6. Are you seeing this behavior with IPv4? Also can you confirm that you are testing this on a Physical machine?Sumesh P - Microsoft Online Community Support

Hi, We are not able to reproduce this issue. This will requres us to get more data and do inhouse repro and in-depth investigation to get to the root cause. Looking at the complexity, we suggest you get a phone call support case.Ketan Thakkar | Microsoft Online Community Support

An MSDN membership used to provide several support incidents per year. I haven't logged a support call with Microsoft in many years. What is the current process, and will this be a paid incident? Thank youDavid Schwartz

David, Did you ever get a resolution on this issue? I am seeing the same thing with Windows 7 64-bit (latest updates applied). I am developing a device that expects window scaling, but it is not always in the SYN packet. Thx, Pete

Ketan, Microsoft needs to fix this. You don't need a phone call support case. What you need is to network a Windows 7 PC to a non-Microsoft device and use Wireshark (or similar) to monitor (more than once) Windows TCP SYN packets on connection to the device. In my case, I see the TCP window scaling option active in the PC's SYN packet only part of the time. This is unacceptable, especially when the device needs to send a lot of data and cannot buffer it itself.

I reproduced this between Win7 and W2k8-R2. So you don't even need a non-Microsoft device.David Schwartz