App Accel and Microsoft's stack attack

App Accel and Microsoft's stack attack

Finally Microsoft has paid attention to rewriting and optimizing core networking components

"Niche killer" has been an oft-encountered modus operandi of Microsoft over the years. Whether it is disk defragmentation, disk compression, firewall or antispyware, Microsoft has eventually decided to play the game and, in the process, change the game. While in the past these forays were limited, Microsoft is now poised to potentially shake up a much bigger space -- the world of application acceleration.

With the introduction of the Windows Vista client OS and the Windows Server 2008 (Longhorn) server OS, Microsoft has, at long last, paid attention to rewriting and optimizing core networking components that have been mostly ignored for a decade or more. And, given that Microsoft clients and servers are likely to be on one or both ends of most corporate WAN connections, the benefits will likely overlap some of the benefits offered by specialized application acceleration solutions.

In the early to mid-1990s, stack optimization was a thriving business. I recall benchmarking competing TCP stacks in DOS and Windows 3.x environments. As with other technologies, different implementations of standard protocols could produce dramatically different performance.

Around the time that Windows NT was introduced, however, the third-party stack builders went the way of the dinosaurs. For better or worse, the TCP stack provided by Microsoft became the one-and-only stack. Ironically, Windows "New Technology" did not contain any new technology when it came to the heart and soul of IP networking.

Weaknesses in the TCP protocol were recognized long ago. For instance, TCP worked best when the characteristics of the networking connection never changed after the initial handshake. Nice, but hardly representing the real-world condition out on the Internet.

RFC 1323 "TCP Extensions for High Performance" dealt with many of these performance issues. The RFC was officially dated May 1992 -- more than a year before the first release of Windows NT -- but far too late to make it in.

For reasons known only to Microsoft, the 1992 enhancements would not become a part of the plan until Vista and Windows 2008 introduced the "Next Generation" TCP/IP stack.

Specifically, Microsoft's new operating systems optimize the TCP/IP stack and the Server Message Block protocol to improve performance over networks that are low bandwidth and/or have high latency. Receive windows, once static, are now dynamic. Slow-start recoveries from lost packets can now be handled by the new Compound TCP support that will allow the send window to be increased for high-latency and/or high-bandwidth environments.

Furthermore, the new stack implements other IP performance enhancements like RFC 1368 Explicit Congestion Notification defined in 2001.

On top of this is Version 2 of the SMB protocol (aka known as CIFS). Version 1 appeared in the earliest versions of IBM's LAN support in the 1980s. It was never meant for a high-delay, low-bandwidth environment and was extremely chatty.

It did, however, become the de facto standard for file server access in the enterprise. And, when those servers were accessed remotely its limitations were widely observed.

And for high-latency and/or low-bandwidth environments, the new networking support makes a dramatic difference. Microsoft commissioned us to benchmark the "before" and "after" performance, and our tests confirmed the significant performance benefits. (See Microsoft's Web to download.)

What we are missing, and what you need to see, is how the new stack impacts any application-acceleration devices you plan to implement. While certain acceleration features like data compression and traffic management will be needed just as much as previously, those related to TCP and SMB acceleration might now largely be obviated by the presence of an inherently more efficient stack on the Microsoft endpoints.

Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments