By Steven Maercklein and Zack Belcher
While we haven’t had a chance to play with Vista yet, (both of us are on the road all the time and we don’t have access to a lab,) we have been doing a lot of research on the new TCP/IP features of Vista and Longhorn.
We spent some time poring over a document from Microsoft’s Research Asia (the guys who designed the Compound TCP/IP [CTCP] algorithm) and it details how the algorithm works. It doesn’t detail how Microsoft has implemented the algorithm – there are alpha, beta, and gamma values that are tweakable, but it doesn’t go into how Microsoft has tweaked them. It looks like this was a document just to prove that CTCP was feasible and ready to be included in Vista.
It does teach you about the behavior of it and what to expect when seen in action, and it makes reference to the current technologies for congestion avoidance that CTCP is based on. However, there are several features of Vista of concern to those involved in network performance.
One of them is the 802.1x security features. Another is the feature – again, that we haven’t seen active in the field yet – that security policy will come from a centralized source. When you get your DHCP lease, your computer will report to the stack what OS you’re using, what version level, what patches, what anti-virus software that’s active – all that kind of stuff. It will have the ability to restrict your network access if you have a down-level machine. While this can be frightening from a privacy standpoint, this is a major boon to corporate network security – assuming malware doesn’t turn this feature against the user somehow. Either way, it’s really interesting technology.
As more companies (and consumers) adopt Vista as their primary OS, we (at NetQoS) need to be in a better position to explain the technology and what the impact on the network is going to be – especially with regards to bandwidth usage. We could see a lot of our customers with much higher WAN network utilization because of this new TCP/IP stack – or they might not see a difference in utilization at all because, while the traffic may “fill up the pipe” it’ll do so for a shorter period of time. If you cut the time in half and double the speed, it’ll just look like a steep spike. Over time, it still averages out to similar speeds.
CTCP is disabled by default for the home and enterprise licenses. For Longhorn Server, however, it is enabled by default, and that’s where it’s going to really affect things. People have been talking about the fact that Vista uses window scaling by default, and people expect that they’ll be able to send more data, but TCP still has to ramp up, and the send window has to get to a point to meet the advertised received window. Even if you’re advertising, say, a 16MB receive window (Vista’s default), it doesn’t matter if slow-start hasn’t allowed the server send window to get that high. It’s always going to use whatever window is smaller.
They also tweaked the loss base. It’s more graceful in a loss environment. Vista’s CTCP should induce less loss – or at least, that’s what Microsoft’s claims. They also claim that CTCP has been designed for “TCP fairness” to allow CTCP and regular TCP traffic to play nicely when sharing the same link – Microsoft’s data shows that CTCP doesn’t induce enough loss to wreak havoc with regular TCP allowing then to both maximize their throughput.
Again, we reiterate that as of yet, very few people outside of Microsoft and some of their enterprise partners have had the opportunity to test Vista deployment in a laboratory situation, so we don’t know about the viability of these claims (though we hope to be able to test them soon.)
We don’t imagine there’s going to be a lot of early implementers that will enable all these features and use them out of the gate, but by next summer, we will see a lot of interest in these subjects. Additionally, Longhorn server comes out in the first half of next year, and Longhorn enables this by default.
Now, CTCP isn’t entirely a new idea, although it has enough “new” in it to justify calling it, as Microsoft’s marketing folks do, a “Next Generation” stack. Microsoft’s CTCP builds upon a number of other TCP algorithms, including TCP Reno, TCP Vegas, Fast TCP and High Speed TCP. It’s as if they said: “We like how aggressive High Speed TCP is, but we don’t like the high rate of packet loss and the fact that it dominates regular TCP traffic.” Fast TCP has a delay based component in it – and they’ve essentially sought to combine the best traits of both of them. They freely admit that in their background information – still, though the concepts have been around a while, this is a new algorithm that uses both packet loss and network round trip time to determine how much data to send. They are taking a page out of those books – but not plagiarizing them wholesale.
This is not to say that a Vista rollout is not fraught with all sorts of peril.
Enabling or disabling CTCP or auto-window sizing are not, as they were in Windows XP, configurable from the registry – CTCP can be enabled/disabled from the command prompt but there has been no mention of tuning parameters which leads us to ask the question: How are you supposed to configure this setting in Vista? (Microsoft Employees: Please give us a comment if you know!) Our next steps are to get some boxes powerful enough to run Vista, get the time to do it and start looking at it for ourselves.
For companies with manually tuned network environments (with high-bandwidth and high-latency – such as satellite links) it should do a better job than window scaling alone, but the fact that it’s dynamic and self-tuning means you’ve lost control over it – that’s a scary position for a sysadmin.
What worries us – and NetQoS should jump on this immediately – is that Microsoft is basing this on packet round trip time. The round-trip time from the client-side will have the server processing time in it; but the clients aren’t likely going to be the running the CTCP at first. If you have a server-to-server backup running, for example, CTCP may think its part of the round-trip time and it’ll throw the delay window through the roof, this will be an important thing to watch for in enterprise environments. There are a lot of unpredictable scenarios that we’re just not going to know how to deal with until we see it.
We honestly don’t think that Microsoft is going to get it right for all environments on the first pass; it wouldn’t surprise me if there are follow-up maintenance releases. From the user side of it, CTCP’s impact probably won’t be felt until Longhorn Server comes out, but in that case, downloads at remotes sites will most likely see better utilization of the link and increased performance. Microsoft’s documentation shows that the last 5 years were well spent in the research department. On paper CTCP is a very well thought out and ambitious achievement for networking, it simply remains to be seen how well Microsoft can implement it.
Our advice to anyone considering a Vista rollout is just to do the common sense stuff – anytime you unleash a new technology, try it in small scale and do proof-of-concept first.
Steven Maercklein and Zack Belcher are network analysts at NetQoS.
For additional coverage on Windows Vista, please visit Ted Romer’s article on Vista’s Window Scaling capabilities.
On Network Performance Monitoring
On Application Performance Monitoring
Technorati Tags: Vista TCP/IP Compound+TCP Next+Generation+TCP/IP Vista+TCP/IP Network+Engineering IT IT+Management