Receive Window Auto-Tuning on Vista.

Hi, my name is Katarzyna and I am the Program Manager within the Internet Protocols team. I have been asked a few times about the Receive Window Auto-Tuning feature on Vista and some associated issues people are having.

One of the many cool new features on Windows Vista, Receive Window Auto-Tuning enables the networking stack to receive data more efficiently than on XP. Auto-Tuning allows the operating system to continually monitor the routing conditions (bandwidth, network delay, application delay) and configure connections (scale the TCP Receiving Window) so as to maximize the network performance.In some high bandwidth, high latency links, we have seen SMB performance improvement up to 20 times!

In every TCP packet there is a “window” field, which informs the receiver how much data the sender can accept back. This window controls the flow by setting a threshold on data kept “in flight” and prevents overwhelming the receiver with data that it cannot accept.

The TCP window field is 16 bits wide, allowing for a maximum window size of 64KB, which used to meet requirements of many older networks. Nowadays, however, network interfaces can handle larger packets and keep more of them in flight at any given time. Thus, a larger TCP window has become necessary; especially on high-speed, high latency networks. To fill such a long, fat pipe and make use of the available bandwidth, the sending system can often require very large windows for good performance.

The solution to this demand is called “window scaling”, described back in 1992 in RFC 1323. It introduces an eight-bit scale factor, which serves as a multiplication factor for the window width. After the factor has been negotiated, window values used by that system on a given connection will be shifted to the left by that scale factor; a window scale of zero, thus, implies no scaling at all, while a scale factor of six implies that window sizes should be shifted six bits, thus multiplied by 2^6 = 64. Now a window greater than 64KB can be easily expressed (e.g., 128KB) by setting the scale factor (e.g., 6) and keeping the window field under the original 16 bits (here, 2048).

The window size included in all packets is modified by the scale factor, which is negotiated once at the very beginning of a TCP connection. The connection requestor suggests window scaling factor in its original SYN packet and if the SYN+ACK packet sent in response contains the option, then this particular value will be used on this connection. The scale factor cannot be changed after the initial setup handshake; remaining data transfers on this connection will implicitly use the negotiated value.

Older routers and firewalls however do not handle window scaling correctly leaving the option in the original SYN packet but setting the connection’s scale factor to zero. Seeing the option on, the receiver responds with its own window scale factor. Believing that its scale factor has been accepted, the initiator scales the window appropriately while the receiver thinks that a scale factor of zero is applied and thus a small window of data should follow. As a result, the communication is slow at best. Sometimes, small window packets are dropped by the routers, essentially breaking the connection.

The resulting slow data transfers or loss of connectivity, users may experience as slow or hung networking applications. Remote Desktop Connection and network file copy are two scenarios particularly hurt by misbehaving routers.

If your connection from a Vista machine appears slow or hung, here are some steps to isolate the cause:

  • First, make sure that your firewall and router can support window scaling. Some devices from Linksys, Cisco, NetApp, SonicWall, Netgear, Checkpoint, D-Link were reported as having problems with window scaling. (Some of the incompatible devices are given here. You can check with the manufacturer or run the connectivity diagnostic suite (especially, TCP High Performance Test) provided by Microsoft to determine your gateway device’s compliance.
  • Second, check with the manufacturer if a firmware update has been issued for your device that can fix the problem. Replace the problematic device or update the firmware as suggested by the manufacturer. If the router cannot be replaced or if it the device is remote (e.g., a firewall of your ISP or corporation)
  • Third, If the problem still persists, you can restrict autotuning by running “netsh interface tcp set global autotuninglevel=restricted” from the command prompt. We have found that restricted mode will often allow some of the benefits of autotuning with a number of problematic devices.
  • Lastly, if all else fails, in order to disable this feature, run “netsh interface tcp set global autotuninglevel=disabled“.
  • (In order to reenable autotuning, run “netsh interface tcp set global autotuninglevel=normal”.)

Please refer to the following KB articles for more information:

— Katarzyna

Updated: Broken link to KB 932170
Update 2: Changed the guidance to do restricted before disabled.
Update 3: tunning doesn’t have two “n”s. 🙂
Update 4: no really, tuning doesn’t have two “n”s.

Comments (28)

  1. Sooner Al [MVP] says:

    The first link to KB932170 is broken. Here is the correct link…

  2. Thank you — these comments have saved us from some prolonged Windows Vista copy experiences. Another thing that seemed to help was avoiding ZIP archives, which seem to delay coming into Vista machines, but not as much when being copied from said machines.

  3. A very interesting thread brought out some interesting differences in the networking stack in Windows

  4. Jorge Eduardo says:

    Autotuninglevel must be disabled for Ibackup otherwise you get a blue screen of death. The problem is you need to remember to disable this manually from command prompt every time you boot.

  5. wndpteam says:


    I would not expect that the autotunning level is related to Backup. If you have a few momements, would you so the following:

     *Open up "Problem Reports and Solutions"

     *Click on "View Problem History"

     *Find the blue screen entry and double click it

     *Scroll down and find the BucketID and let us know what it is?


       — Ari

  6. After reading about it on Microsoft’s public newsgroups, it seems that setting “AutoTuningLevel=normal” or generally something other than disabled, causes Windows Live Messenger to NOT connect, producing the error 0x81000306, which seems to be a plague these days! So, if anyone receives this error, they could just type (as admin) “netsh int tcp set global autotuninglevel=disabled” to fix Messenger!

    It depends on the NAT device and it’s firmware. I would suggest “netsh interface tcp set global autotunninglevel=restricted” before a complete disable as the post tries to explain. — Ari
  7. Tim Wilde says:

    I’ve experienced and find many postings in the Vista Community that some PCs running Vista seem to be forced to use the Public Location settings, Local access only, which causes them to be unable to connect to a LAN or the Internet. By adding a static local ip address, gateway address, DNS addresses, etc. to the Alternate IP Address settings for TPC v4 these PCs are able to connect fine. I wonder if window scaling is causing these Vista PCs to be unable to work with some router’s DHCP function?

    “Local Access Only” is a sign that the machines are either not receieving a DHCP response, or that with the settings recieved they are unable to access beyond the local router. Public Location is the default location until a user selects an option that tells Vista that the network is a private one (Home or Work). DHCP runs in parallel to TCP instead of ontop of TCP, so TCP Window Scaling should not affect it. — Ari
  8. Dean says:

    So Windows Scaling is supposed to also be in Windows 2000, Windows 2003 and XP. So why didn’t those products feel the effects of routers that didn’t support scaling ? Also, since it seems that a lot of routers don’t support this ( even though the RFC has been around since 1992 ) is it even worth turning on untill all hardware supports it.

    Do the main routers on the Internet support it ?

    The Cable Guy January 2007 article attempts to explain the difference.– Ari
  9. ASPInsiders says:

    I posted earlier about copying files across my new Gigabit home network . I was getting about 10 MB/s

  10. There is a typo in the blog!

    its not “autotunninglevel” but “autotuninglevel”!

    [Fixed. Thanks -Ari]
  11. MarkDubya says:

    How ’bout find and replace all “tunning” with “tuning”

    Sure. — Ari
  12. Mike says:

    Sections of this article sounds hauntingly familiar:

  13. iain says:

    tried this and received this error…found the same on two vista machines:

    “Set global command failed on IPv4 The requested operation requires elevation”

    Yes, this is a change to the underlying OS settings and requires you to run as administrator. Open a cmd shell by Right Click -> Run as administrator. Depending on your account type you either need to approve or type in the an administrator account password. Once the administrator cmd shell is open, you can use the netsh cmds

    — Ari

  14. Cecil Ward says:

    Could Microsoft do more to help get this issue resolved. Suggestions: post a list of broken routers w. firmware versions; have a campaign to reach out to router mfrs to get firmware updates ready; ship a small tool that definitively tests for the issue on a vista client machine.

  15. Are you kidding? How could possibly Microsoft test all the network devices on the market (not even talking about firmware versions)? There are millions of them.

    It is not their responsibility to make sure that network equipment vendors do their job correctly.

    And as written in the article, Microsoft does offer a tool it is called Internet Connectivity Evaluation Tool and can be freely downloaded from their website.

    I bet if they were shipping it with Vista, they would get an antitrust law suit from European Union or somebody.

  16. Well, after a few months of quiet, I am back. Interesting article about Models and Specifications 4 ways

  17. It’s interesting that IE 7+ seems to set “autotuninglevel=restricted” programmatically on Vista, as other browser vendors have been forced to do as well.  If there is a reliable way to only do this if required due to buggy routers, it would be useful to know about how.

    Well the mechanism is WSAIoctl SIO_SET_COMPATIBILITY_MODE with WsaBehaviorAutoTuning option. I believe Vista SP1 introduced some general mechanisms to reduce autotuning when it sees slow connections with small window sizes for sockets that do not set that option. Even with that, it’s still a reactive test, the user still has to experience the bad network behavior before the stack can attempt to adapt to it.
  18. Michael L. Croswell says:

    Is there a netsh.dll so that this could be called programmatically (as opposed to using ShellExecute or CreateProcess)?

    Also, will this be fixed in Vista?  Wouldn’t it make sense (!) if the OS had just set this to Restricted or Disabled by default.  Or perhaps, like DirectX, there would be a way to set it without going to a command-line program?

    We’ve done work in SP1 to lessen the impact for users with problematic network devices. We’ve heard general feedback about the lack of more programatic access to network settings and enjoy getting more information about specific scenarios that are intresting to our customers. I’d also like to point out one more type of control of the AutoTunning setting, Group Policy. gpedit.msc -> Computer Configuration -> Windows Settings -> Policy Based QoS -> Right Click: Advanced Qos Settings -> Inbound TCP Traffic is a set of levels that map 0 -> diabled, 1 -> highlyrestricted, 2->  restricted and 3 -> normal. This allows bulk deployment of the settings in a domain.

    — Ari

  19. Mark Wall says:

    Whats the difference between "RWND Auto-Tuning" and "Window Scaling Option"(RFC 1323)?

    Does Auto-Tuning adjust the max. RWND (or the scaling factor) while the connection is already established?

    How does this work technically?

    Or does "Auto-Tuning" just mean that "Window Scaling Option" is used per-connection (while it is established) and not globally for all connections?


  20. adamsalah says:

    So I decided to reorganize my laptop running VISTA ultimate. First things first, make room on the system…

  21. Cecil Ward says:

    18 months on, there are still major router manufacturers who have yet to release fixes to their firmware to resolve window scaling issues.

    Microsoft could help its customers by (i) liaising with manufacturers to exert some gentle pressure, and (ii) also publicising those who do the right thing and reminding the rest of how they are missing out on the benefits of getting listed amongst the righteoud and acquiring a "logo".

    Suggestion. What about a patch for vista that adds a new ‘split’ pair of two ‘subnet-vs-global’ autotuning parameters to control the behavior independently wrt subnet-local vs external ip addresses? That would allow users on a fast LAN to benefit without problems caused by routers or bad servers out on the internet.

  22. R Sherwood says:

    So, is there a QoS policy that may be applied to set the autotuninglevel on Vista? Or is this only set through netsh? And, I believe the change to be persistent when set through netsh – is this the case?

  23. An existing connection was forcibly closed by the remote host

  24. Mark says:

    I’m trying to RDP from a Vista x 64 machine into a Server running XP Pro 64.

    Its so slow (even locally) as to be unusable. It works fine from an XP machine and I can RDP from this Vista machine into other  XP machines without a problem.

    I tried the fixes mentioned here but it doesn’t solve the problem. Please advise.

  25. S H says:

    Seeing similar issues with Vista (with latest updates/S.Pack etc.) and using a Dlink DWA-547 Wireless N card to connect to a Dlink DWA-615 N-class router.  

    The machine ticks away quite merrily on the web/using online apps etc. and streams media down over the air to a PS3 (physically connected to the router).  It can run fine for a while or start dropping out after 30 minutes or so, and the Wireless connection changes to “Local only” and the PS3 can’t see the media server.  Also, Was streaming BBC I-Player traffic to the PS3 which kept pausing (on a 20MBps link) until the Vista machine dropped off the network, the PS3 advised it had lost connectivity to the Media server and all of a sudden it sprang into life.  

    No errors at all (bar a browser re-election) in any of the event logs on the PC.  disconnecting and re-connecting to the network restored service.  The Event logs showed the reconnection and so did the Router.  no errors though shown as to what caused the drop off.

    I’ll try disabling the auto-tuning to see if it makes a difference.  Is there a way to set this option to disabled permanently?  Also, would this option being enabled conflict with QoS settings (for media streaming/Online gaming traffic etc.) being set on the Router?  Currently I have those enabled.


  26. jm says:

    You do seem to have it right, but many websites and commenters mix up window scaling vs. Auto Tuning.  TCP window scaling is not new with Visa.  Older systems like Windows 98 support TCP window scaling.  TCP window scaling is enabled for any window size greater than 64kb.  On those old systems users can specify window sizes greater than 64kb, but the window size is fixed until a registry edit changes it.   What Vista introduced is Auto Tuning.  What that does is dynamically change the window size (the scale factor) on the fly to try and make each TCP connection as ideal as possible.  There can be an issue with older routers because the dynamic window size can get enormous and cause a problem.  Many websites suggest to disable Auto Tuning.  I don't like that because disabling it fixes the TCP window (Rwin) to 16kb, which is not very good for broadband.  I like the HighlyRestricted option instead.  The window can grow, but is limited, but can get into where it's better for broadband and doesn't cause problems with older routers in my testing.