* If an application is deployed across the WAN, all protocol layers must be WAN-aware
In the past few newsletters, we described in considerable detail the mechanisms that are in place in TCP to ensure efficient transport of information. In particular, we concentrated on the ability of TCP to improve transmission efficiency by retransmitting only packets (using the broad definition of “packet”) that either had errors or were lost without retransmitting packets that had been subsequently received successfully.
Nevertheless, to see the positive impact of techniques like this, all layers of the protocol stack must behave in a manner that has been optimized for the WAN. For instance, when frame relay was first introduced, in addition to TCP/IP, IPX was commonly used on the LAN. And when the first implementations of IPX were extended to the WAN using frame relay, the resulting performance was far short of stellar. The reason was simple. The default implementation of IPX at that time was a “single window” protocol. That is, once a packet of information was sent out, an acknowledgement was expected before the next packet was sent. (By contrast, TCP, X.25, and other WAN-aware protocols already had provisions to have multiple outstanding unacknowledged packets of information.) IPX was modified to allow multiple windows, and all was copasetic.
This limitation was understandable. IPX was intended for the LAN, and LANs had (and still have) a couple of orders of magnitude higher speeds and lower latency than the WAN. And this is still the case; as WAN speeds have increased, so have LAN speeds.
So, having cut our teeth in the WAN world, you can imagine our surprise when we learned a couple of years ago that some of the more common protocols at the application layer – especially Microsoft’s CIFS and WAFS – behaved incredibly similarly to older versions of IPX. Single windows of outstanding requests? You’ve gotta be kidding!
All of which brings home the point. If an application is deployed across the WAN, all protocol layers must be WAN-aware and appropriately designed to deal with the real world of latency, lost packets, etc., that are encountered in the WAN. Fixing the lower layer protocols does little good if the higher layers are working from a different set of assumptions.
For a more detailed discussion of the Microsoft protocols in the WAN specifically, you may wish to take a look at a recent paper, “Why Centralizing Microsoft Servers Hurts Performance,” by NetForecast, available at Webtorials.
