One of the problems network administrators deal with on a daily basis is poor application performance. Generally,...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the network "looks great". Your routers and switches will be at <10% bandwidth, memory and CPU utilization. And yet, someone's application just isn't quite fast enough. This is particularly annoying when the connection travels over a large WAN link, such as a T3. In this case, the fingerpointing generally begins. Your server people blame the network. Your equipment looks ok, so you start talking to your WAN service provider. If this sounds familiar, read on. And while you're reading, send a copy of this link to your server administrators:
This document helps explain why the default settings for TCP's "Window" are inadequate for long-distance, high-bandwidth networks. The crux of the problem is that you can only send 65KB of data before you receive an acknowledgement. If you have a 45Mb/s pipe, and a 200ms round-trip time, then in 1/5th of a second, you could send 9Mb/s but if your TCP window only allows you to send 65KB, it's not hard to see why we have so many users standing around, scratching their heads and wondering why they're not filling that T3.
So, Windows 2000 introduced support for several RFCs, and as you'll read in the link above, there are many features that can make high-speed data transfers a reality now.
First on the list is "Window Scaling" from RFC 1323. This allows that window to go past 65KB, which is actually a limitation of the field size in the TCP header, all the way up to 1 Gigabyte.
Second are "Delayed Acknowledgements" which reduce the number of ACKs required. This was specified a long time ago, but is now a configurable timer in Windows 2000.
Third, "Selective Acknowledgements" allow you to acknowledge non-contiguous data. This is specified in RFC 2018, and occasionally referred to as SACKs.
Another interesting addition is the TCP Timestamp from RFC 1323. This puts an actual timestamp in the TCP header, which can be used to figure out what the RTT is in a much better way than simple PING.
Unfortunately, all of these are turned off by default. Your server administrators must specifically enable them, usually by editing the registry, which is never a good thing. And while this is very good information, it's not exclusive to Windows operating systems; most others, including Linux, AIX, Solaris, etc. have the same problem and have to be enabled manually.
So next time you are asked to deal with a slow network (probably a few minutes from now), share this link with your people and remind them that: "Throughput can never exceed window size divided by round-trip time."
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years experience in the networking industry, and co-author of several books on networking, most recently, CCSPTM: Secure PIX and Secure VPN Study Guide published by Sybex.