Click for larger view.
Congestion also affects WAN performance, of course. Congestion occurs when no bandwidth-allocation policy has been applied to traffic on the WAN. Traffic flows can be bursty, such as when one user tries to retrieve a large
e-mail attachment while another user logs in to a CRM portal. With no bandwidth management, the download can bring the smaller link to a grinding halt.
P.G. Narayanan, CEO of Allot Communications, believes that much of the congestion problem can be solved by applying QoS to the traffic. “The problem most of these networks have, though, is temporary … that second, or that minute it’s congested, you can get away with just prioritizing applications. So what you can do is put a gigabit box at the central site to prioritize those applications, the critical applications, on a temporary basis, and you can avoid the congestion, and all other times you’re OK anyway,” says Narayanan.
Prioritizing application flows is an important part of managing your WAN traffic, but it isn’t going to solve TCP’s inherent limitations when latency creeps in. On shorter links where latency isn’t an issue, simply preallocating your bandwidth will help keep important packets moving, regardless of what else is in the pipe. But on LFNs, latency, not congestion, is the culprit.
Talk, talk, talk
From the end-user point of view, latency gets less tolerable as the back-and-forth communication required for some action increases. And layer 7 protocols — where applications live — are chatty, requiring an absurd number of round-trips to complete a single task. Much like TCP, protocols such as CIFS and MAPI (mail application programming interface) were designed to run inside the LAN, not over the WAN.
The chattiness reaches a crescendo when users map drive letters over the WAN using CIFS (used in Windows networks). Any user that has had to open, edit, and save a Microsoft Word or Excel document from a remote file server knows how long this simple task can take, even over a fat WAN connection. By the same token, users of Microsoft Outlook and Exchange 2000 suffer when they open an e-mail with an attachment over a WAN link. The message appeared to be in their inbox, but in reality it was still on the server waiting to be retrieved.
Microsoft Exchange Server 2003 was designed to mask this problem by downloading messages and attachments in the background (cached Exchange mode). Although this is great for the end-user, it adds additional traffic on the WAN. For example, Outlook now downloads all attachments to your inbox, regardless if you were going to open them in the first place. This places an additional load on the WAN link, which should never happen.
Out with the old…
Traditionally, WAN performance was attacked at the packet level. Back in 1998, Expand Networks was one of the leaders in WAN compression. Liad Ofek, vice president of technical services at Expand Networks, says that, at the time, the goal was to “squeeze as much data as possible” into existing links.