Heres why TcpWindowSize does not work in Vista

[Spooky]

I keep seeing numerous posts all across the internet about tweaking connections with various utilities. All of them swear that such and such utility improved their bandwidth raw speed, especially on broadband connections. All these have something in common, they try to use and set the TcpWindowSize registry entry for the raw speed, this doesn't work, it can't work, in Vista contrary to what people swear and heres why in plain english...

One of the new things in Vista is AutoTuning for TCP connections. Basically and taking everything into account, what AutoTuning does is tune individual connections initiated by a client for best performance and efficiency. It also tunes the Tcp Window Size. In WinXP and past MS Operating Systems we used the registry entry "TcpWindowSize" (a DWORD) and set its value to adjust our TCP window size for best raw connection speed which was an indication of taking advantage of available bandwidth. However, in Vista, this is no longer a valid registry entry to use because its not included as a registry variable in the Vista files that deal with TCP, if its not in the files the registry entry is not recognized by the OS. This is the reason the "TcpWindowSize" registry entry does not work in Vista.

Without an ability to control the Tcp Window Size all these utilities that swear they will increase your raw speed and bandwith in Vista are nothing but smoke and mirrors. It can't be done because the Tcp Window Size in Vista is based purely on AutoTuning being either on or off, and there is no 'magic' switch or registry entry to use. If you disable AutoTuning your Tcp Window Size will be at the default, with AutoTuning enabled Vista will tune your connection far more efficiently then any tweaker or registry entry adjustment could ever hope to do. If you want to play around with TCP and AutoTuning you can do so from an admin command prompt using the below commands:

(these are not the only TCP commands, there are still a few that can be set in the registry but they do nothing for raw speed and bandwidth as they only set vaious parameters of items in the TCP packet its self)

netsh int tcp set global autotuninglevel=normal
netsh int tcp set global autotuninglevel=disable


Usage: set global [[rss=]disabled|enabled|default]
			 [[chimney=]disabled|enabled|default]
			 [[autotuninglevel=]
				disabled|highlyrestricted|restricted|normal|experimental]
			 [[congestionprovider=]none|ctcp|default]
			 [[ecncapability=]disabled|enabled|default]
			 [[timestamps=]disabled|enabled|default]

Parameters:

	   Tag		   Value
	   rss			 - One of the following values:
						 disabled: Disable receive-side scaling.
						 enabled : Enable receive-side scaling.
						 default : Restore receive-side scaling state to
							 the system default.
	   chimney		 - One of the following values:
						 disabled: Disable Chimney offload.
						 enabled : Enable Chimney offload.
						 default : Restore Chimney offload state to the
							 system default.
	   autotuninglevel - One of the following values:
						 disabled: Fix the receive window at its default
							 value.
						 highlyrestricted: Allow the receive window to
							 grow beyond its default value, but do so
							 very conservatively.
						 restricted: Allow the receive window to grow
							 beyond its default value, but limit such
							 growth in some scenarios.
						 normal: Allow the receive window to grow to
							 accomodate almost all scenarios.
						 experimental: Allow the receive window to grow
							 to accomodate extreme scenarios.
							 WARNING: This can dramatically degrade
							 performance in common scenarios and should
							 only be used for research purposes.
	   congestionprovider - One of the following values:
						 none: Use the built-in standard congestion
							 control algorithm.
						 ctcp: Use the add-on Compound TCP congestion
							 control algorithm.
						 default: Restore the selected provider to the
							 system default.
	   ecncapability   - One of the following values:
						 disabled: Disable ECN Capability.
						 enabled : Enable ECN Capability.
						 default : Restore ECN Capability state to the
							 system default.
	   timestamps	  - One of the following values:
						 disabled: Disable RFC 1323 timestamps.
						 enabled: Enable RFC 1323 timestamps.
						 default: Restore RFC 1323 timestamps state to the
							 system default.

Remarks: Sets TCP parameters that affect all connections.

Example:

	   set global enabled enabled normal
	   set global rss=enabled chimney=enabled autotuninglevel=normal

Edited December 3, 2006 by Spooky

[Stoic Joker]

While it seems a safe assumption (I can't find anything one way or the other) ... Does the AutoTuning feature also adjust the MSS/MTU to match/balance with the RWIN?

[Spooky]

Let me see if I can say this correctly, if i made a mistake don't jump all over me

No, the AutoTuning does not adjust the MTU, it uses what ever is reported by the interface. Each interface used by TCP/IP may have a different MTU value specified. The MTU is usually determined through negotiation with the driver, using that driver reported value - for example...an ethernet connection (a NIC hooked to a cable modem for example) has an MTU of 1500. The link layer is responsible for discovering this MTU and reporting it to TCP/IP and since most (about 99.9% of whats commonly used) connection interfaces report thru their drivers what the MTU is from the interface and thats what TCP/IP uses as the MTU.

Basically; MSS tells the OS how large a packet it can create. MTU is used for routing that packet.

Using a 'Bucket' analogy; As far as MSS being affected by AutoTune it seems there wouldn't be any need for AutoTune to directly adjust the MSS because its already telling the OS how big of a 'packet bucket' there is to fill and the OS responds by filling up the bucket with ever how much AutoTune reported back was suitable to be sent for the connection at that moment in time according to the conditions AutoTune sees on the connection and the bucket is sent on its way. If too much is put in the bucket some of it spills out and this is where retransmits come in (another story) which causes the efficiency of the connection to suffer. This AutoTune method is a whole lot better than having a fixed MSS because a fixed MSS dosn't account for the most efficient packet size all the time where as AutoTune does. So I guess in a way AutoTune does affect the MSS but i've not had a reason to explore that yet as its been good enough that it just works the way its supposed to.

Just a quick word about Window Scaling and RWIN here also which plays a part. Window Scaling is a TCP option. AutoTuning is an algorithm that decides how much to increase and maintain the Receive Window (RWIN). Window Scaling only enables us to be able to increase the value all the way upto 16MB if needed, with a scale factor of 8. One is an option, the other is an algorithm which uses the option.

Hope I explained it properly. I know what I wanted to say but sometimes i don't explain it too well.

While it seems a safe assumption (I can't find anything one way or the other) ... Does the AutoTuning feature also adjust the MSS/MTU to match/balance with the RWIN?

Edited December 3, 2006 by Spooky

[Stoic Joker]

Okay... That's close to what I was looking for.

I'd already understood the relationship between MSS & MTU, MTU being MSS + the 40 byte TCP header. Most of the (till now) stack tuning consisted of balancing the best average MTU so that the MSS was an even multiple of the RWIN and would neatly and completely fill the RWIN without overflowing it, then letting PMTU and Window Scaling swing it to-and-fro if/as needed. So the stack tweaking really just sets a base-line that the other options then revolve around (for better or worse...).

What I was getting at (or pondering aloud) was, might the AutoTuning algorithm be using the PMTU option (among other things) to do an on-the-fly adjustment of the RWIN to more closely hit an ideal base-line and maintain that balance?

If so ... Then all of the previously popular stack tweaking options would become (/are) obsolete and rather detrimental to network/internet performance.

[Spooky]

EnablePMTUDiscovery and EnablePMTUBHDetect ? Are those the ones your asking about?

EnablePMTUDiscovery: TCP attempts to discover MTU automatically over the path to a remote host

EnablePMTUBHDetect: Allows "black hole" routers to be detected, it also increases the maximum number of retransmissions for a given segment.

And your question: "What I was getting at (or pondering aloud) was, might the AutoTuning algorithm be using the PMTU option (among other things) to do an on-the-fly adjustment of the RWIN to more closely hit an ideal base-line and maintain that balance?"

OK, I see now what you were getting at. The answer is basically I don't know for a fact. However, given the basic simple definitions of EnablePMTUDiscovery and EnablePMTUBHDetect above I would initially assume some type of interaction by AutoTuning due to the fact the window size is changed by AutoTuning. So...based upon this observation only, my initial answer to your question is - Yes, the AutoTuning algorithm is probably making adjustments on the fly using as part of its own parameters the PMTU option.

One of the problems with stack tuning in the past was that while one could set up the stack based upon the conditiions present when the stack was set up within its own network segment, once the packet left that network segment the adjustments to the stack really had little effect. One could just look at the number of re-transmissions and tell that something was happening to the packets once they left the network segment. If the stack tuning had any effect beyond the network segement then there would not have been any re-transmission problems. This is where AutoTuning, in my opinion, is really at its best - detecting those conditions and adjusting accordingly for the most efficient connection.

Will some of the past adjustments like PMTU have any effect and are those past stack tuning parameters obsolete? I don't know if all of them are obsolete except maybe the TcpWindowSize, but I do know that AutoTuning will have a far greater chance of tuning the connection at any point in time better, faster, and more efficiently then any manual adjustment could ever do.

Would those more traditional parameters be detrimental to a connection? Don't know really, but I will expect them to be detrimental based upon the fact, like anything, if you put a fixed parameter into something that supposed to automatically adjust you begin to limit its effectiveness to do its automatic adjustments by limiting its boundries.

OK, now that i've really mangled these explainations and confused even myself, forgive me if I got anything wrong. Its early and I need more coffee.

Okay... That's close to what I was looking for.

I'd already understood the relationship between MSS & MTU, MTU being MSS + the 40 byte TCP header. Most of the (till now) stack tuning consisted of balancing the best average MTU so that the MSS was an even multiple of the RWIN and would neatly and completely fill the RWIN without overflowing it, then letting PMTU and Window Scaling swing it to-and-fro if/as needed. So the stack tweaking really just sets a base-line that the other options then revolve around (for better or worse...).

What I was getting at (or pondering aloud) was, might the AutoTuning algorithm be using the PMTU option (among other things) to do an on-the-fly adjustment of the RWIN to more closely hit an ideal base-line and maintain that balance?

If so ... Then all of the previously popular stack tweaking options would become (/are) obsolete and rather detrimental to network/internet performance.

Edited December 4, 2006 by Spooky

[Gott]

Will some of the past adjustments like PMTU have any effect and are those past stack tuning parameters obsolete? I don't know if all of them are obsolete except maybe the TcpWindowSize, but I do know that AutoTuning will have a far greater chance of tuning the connection at any point in time better, faster, and more efficiently then any manual adjustment could ever do.

I'm currently struggling to to find any documentation about "TcpWindowSize" in Windows Vista. I really hope it still works when "Receive Window Auto-Tuning" is disabled.

AutoTuning currently actually has a far greater chance of completely messing up a connection than tuning it "better, faster, and more efficiently" (which indeed is its intended purpose) since a lot of routers and network-components simply don't know how to deal with it.

A lot of routers with statefull inspection firewalls will have serious problems dealing with Autotuning (e.g. most - if not all - current Draytech routers). The result is packet loss, blocked connections and severely reduced network performance.

I'm having a different problem though. I'm using a KISS DP-1500 networked DVD player to stream videos and music into the living room. With AutoTuning in its "normal" setting it is simply impossible to get a stable stream to this client. And it looks like this happens on all Vista installations with a lots of similar streaming clients.

While I simply cannot use the AutoTuning feature (or at least not until I can afford a better streaming client) in "normal" mode I'd still like to adjust the Receive Window manually. I'm also wondering where the default value that AutoTuning bases its analysis on is set and if this might still be "TcpWindowSize".

Update: I just answered my own question:

http://www.microsoft.com/technet/community...guy/cg1105.mspx

Can be manually configured The HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize and HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize registry values can be set to a maximum of 65,535 bytes (without window scaling) or 1,073,741,823 (with window scaling). Without window scaling, you can only achieve a throughput of approximately 5 megabits per second (Mbps) on a path with a 100 millisecond RTT, regardless of the path bandwidth.

Edited March 17, 2007 by Gott

[kickarse]

By default Vista has CTCP turned off and Server 2008 turned on

By turning this option on it can increase thorough put by aggressively increasing the send window...

http://www.microsoft.com/technet/community...guy/cg1105.mspx

Compound TCP

The existing algorithms that prevent a sending TCP peer from overwhelming the network are known as slow start and congestion avoidance. These algorithms increase the amount of segments that the sender can send, known as the send window, when initially sending data on the connection and when recovering from a lost segment. Slow start increases the send window by one full TCP segment for either each acknowledgement segment received (for TCP in Windows XP and Windows Server 2003) or for each segment acknowledged (for TCP in Windows Vista and Windows Server 2008). Congestion avoidance increases the send window by one full TCP segment for each full window of data that is acknowledged.

These algorithms work well for LAN media speeds and smaller TCP window sizes. However, when you have a TCP connection with a large receive window size and a large bandwidth-delay product (high bandwidth and high delay), such as replicating data between two servers located across a high-speed WAN link with a 100 ms round trip time, these algorithms do not increase the send window fast enough to fully utilize the bandwidth of the connection. For example, on a 1 Gigabit per second (Gbps) WAN link with a 100 ms round trip time (RTT), it can take up to an hour for the send window to initially increase to the large window size being advertised by the receiver and to recover when there are lost segments.

To better utilize the bandwidth of TCP connections in these situations, the Next Generation TCP/IP stack includes Compound TCP (CTCP). CTCP more aggressively increases the send window for connections with large receive window sizes and large bandwidth-delay products. CTCP attempts to maximize throughput on these types of connections by monitoring delay variations and losses. CTCP also ensures that its behavior does not negatively impact other TCP connections.

In testing performed internally at Microsoft, large file backup times were reduced by almost half for a 1 Gbps connection with a 50ms RTT. Connections with a larger bandwidth delay product can have even better performance. CTCP and Receive Window Auto-Tuning work together for increased link utilization and can result in substantial performance gains for large bandwidth-delay product connections.

CTCP is enabled by default in computers running beta versions of Windows Server 2008 and disabled by default in computers running Windows Vista. You can enable CTCP with the netsh interface tcp set global congestionprovider=ctcp command. You can disable CTCP with the netsh interface tcp set global congestionprovider=none command.

Edited September 20, 2007 by kickarse

[kartel]

I enabled CTCP netsh interface tcp set global congestionprovider=ctcp

and HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts to 1

and I had a increase in download speed.

Now I get 1000kbs more.

Holy crap, what ever that did its faster even uploading my screenshots now.

Edited September 21, 2007 by kartel

[Stoic Joker]

Interesting Stuff Guys, Thank You!

I guess not all thread resurrections are bad...

[Chrysalis]

the registry has many of the tcp settings present in XP but they are set to 255 decimal value and revert back to that value if you try to change them, mtu can be adjusted manually as normal tho.

Regards to mss mtu and automatic tcp tuning, my isp works best on a mtu of 1478, vista doesnt tune to this, when I set mtu to 1478 and rebooted the mss became 1438 and tcp auto tuning set a rwin to match mss so that was good but I did have to manually set the mtu.

I also did the ctcp setting as I believe that to improve performance.

[erpdude8]

Will some of the past adjustments like PMTU have any effect and are those past stack tuning parameters obsolete? I don't know if all of them are obsolete except maybe the TcpWindowSize, but I do know that AutoTuning will have a far greater chance of tuning the connection at any point in time better, faster, and more efficiently then any manual adjustment could ever do.

I'm currently struggling to to find any documentation about "TcpWindowSize" in Windows Vista. I really hope it still works when "Receive Window Auto-Tuning" is disabled.

AutoTuning currently actually has a far greater chance of completely messing up a connection than tuning it "better, faster, and more efficiently" (which indeed is its intended purpose) since a lot of routers and network-components simply don't know how to deal with it.

A lot of routers with statefull inspection firewalls will have serious problems dealing with Autotuning (e.g. most - if not all - current Draytech routers). The result is packet loss, blocked connections and severely reduced network performance.

I'm having a different problem though. I'm using a KISS DP-1500 networked DVD player to stream videos and music into the living room. With AutoTuning in its "normal" setting it is simply impossible to get a stable stream to this client. And it looks like this happens on all Vista installations with a lots of similar streaming clients.

While I simply cannot use the AutoTuning feature (or at least not until I can afford a better streaming client) in "normal" mode I'd still like to adjust the Receive Window manually. I'm also wondering where the default value that AutoTuning bases its analysis on is set and if this might still be "TcpWindowSize".

Update: I just answered my own question:

http://www.microsoft.com/technet/community...guy/cg1105.mspx

Can be manually configured The HKEY_LOCAL_MACHINE\System \CurrentControlSet\Services\Tcpip\Parameters\TCPWindowSize and HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Interface\InterfaceGUID\TCPWindowSize registry values can be set to a maximum of 65,535 bytes (without window scaling) or 1,073,741,823 (with window scaling). Without window scaling, you can only achieve a throughput of approximately 5 megabits per second (Mbps) on a path with a 100 millisecond RTT, regardless of the path bandwidth.

I use "GlobalMaxTcpWindowSize" instead of just "TcpWindowSize", Gott. try that one instead.

[epic]

Great post... lets not forget Host Resolution Priority.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ServiceProvider
LocalPriority=(DWORD, recommended: 4, default: 499) - LN cache
HostsPriority=(DWORD, recommended: 5, default: 500) - HOSTS file
DnsPriority=(DWORD, recommended: 6, default: 2000) - DNS
NetbtPriority=(DWORD, recommended: 7, default: 2001) - NetBT name resolution and WINS

[ahenderson]

Interesting results w/ compound TCP enabled - Has anybody tested this for larger delays and packet loss? Say Satallite sized RTT ~500MS and 1% packet loss?

My office ISP pays (some) attention to DSCP markings & you may be able to get better delay and drop characteristics for (a small part of) your traffic if you apply an AF or EF DSCP marking. I understand that you can do this w/ group policies in Vista and Win 7 but you'll need someone more expert to tell you how.

[Chrysalis]

I already played with DSCP/TOS in windows vista/win7 and seemed to get nowhere, when I changed it in the policy editor it seemed to have no affect. However windows 7 seems to improve my networking a lot so I am happy with using the default value now.

[LordWarlock]

Everything on one page:

SpeedGuide