Aron Smetana: Article: A Beginner's Guide To WAN Acceleration

A Beginner's Guide To WAN Acceleration
http://www.smallnetbuilder.com/index.php?option=com_content&task=view&id=31797&Itemid=55

A Beginner's Guide To WAN Acceleration

Apposite Technologies, WAN Acceleration

Prev - Page 1 of 2 - Next »

$Speed It Up$

Introduction

WAN acceleration products that optimize application performance have historically been the domain of huge enterprises connecting far-flung operations. But that is starting to change. Even small companies are becoming more dispersed, with employees working from home or local offices, making collaboration essential. And the types of applications that were previously reserved for large companies with immense budgets and entire IT departments to run them, are increasingly used by everyone.

For these reasons, smaller organizations are experiencing the same application performance issues that have long plagued their larger brethren. Fortunately, new acceleration products, available in an increasing variety of forms, are starting to offer suitable solutions.

To understand if a WAN acceleration system will provide useful benefits for your network, it's helpful to look under the hood to understand how these systems work and what they can accomplish.

It's Magic

Back in the olden days, I worked at an early WAN acceleration vendor. Whenever we first installed a demo unit on a customer's network and they saw how more responsive the applications suddenly became, their jaws would inevitably drop and they'd stare in amazement. "That's incredible," they'd gasp. "It's like magic!"

It reminded me of the movie "Mosquito Coast" where the cranky inventor played by Harrison Ford tells a band of natives in rain forest, agog over the ice he's created for them in a primitive freezer, "It's not magic – it's thermodynamics!"

So I would put on my best Han Solo voice (admittedly not distinct enough from my Luke Skywalker voice for anyone to notice the difference) and state, "It's not magic – it's WAN acceleration."

WAN acceleration can seem like magic to anyone previously stuck waiting for minutes in a hotel room for a Powerpoint presentation on the company file server to open. But once you understand how it works, conceptually it's not especially complicated. More importantly, if you understand how it works, you can ignore the vendor hype and determine the value WAN acceleration would bring to your network, as well as the best way to evaluate which products are the best fit for your applications.

So What's the Problem?

WAN acceleration solves two separate problems – insufficient bandwidth and the inability of applications to use all the bandwidth that's available.

The fact that low bandwidth WAN links causes sluggish performance is hardly surprising. On the LAN, files transfer quickly, videos play smoothly, and we usually don't need to play Angry Birds to keep ourselves occupied while waiting for applications to load. But try to download a gigabyte file over a DSL line, and anyone who expects it to arrive instantaneously is lacking a good understanding of either physics or math (or probably both.)

What is surprising is how much latency and packet loss can affect performance, preventing applications from using all the bandwidth. To illustrate, I'll show a few examples using a network emulator to simulate different WAN conditions.

This first graph shows throughput of an FTP file transfer between two Linux servers on a LAN. Since there is no latency or loss, the transfer uses all of the 1 Gbps bandwidth available.

LAN - LAN FTP transfer

Next, I add 40 ms of delay, the round-trip time between my home and my office only a few miles away. (Of course, the packets don't take the direct route of my commute, but instead follow the path the taxis use to ferry tourists from the airport by looping through a city an hour away.) To illustrate the point, I've left the bandwidth at 1 Gbps, but throughput is suddenly limited to only 55 Mbps!

(Note: The 20 ms delay shown in the screenshots is one-way. It is applied in each direction for a total 40 ms round-trip delay.)

LAN - LAN FTP transfer w/ 40 ms delay

Higher latency, for example, connecting from a local office to headquarters across country or to Europe or China reduces the throughput even further.

Delay (RTT) Throughput 0 ms 1 Gbps 40 ms 55 Mbps 100 ms 22 Mbps 250 ms 9 Mbps

Table 1: Delay vs. throughput

These tests assumed lossless links. But since I'm usually connected over Internet VPN, I should expect occasional packet losses. At 40 ms delay, even with a loss rate of only 0.1%, throughput drops from 55 Mbps to 14 Mbps, and becomes highly variable as shown below.

LAN - LAN FTP transfer w/ 40 ms delay, 0.1% loss

So what's going on? Fundamentally, most applications weren't designed to run over a WAN, and even the core networking protocols such as TCP, CIFS, and HTTP were created in an era when a 56K fixed line was a luxury and most remote users connected with modems measured in baud.

There may have been a few visionaries at the time who conceived of the modern, everything connected world. But they were too worried about making networking work at all to be concerned about optimizing performance for applications that wouldn't exist for another couple of decades.

Although this is a vast oversimplification that might get me fined by the Internet police, conceptually, TCP guarantees delivery of data across a lossy network. It does this by sending a block of data and waiting for acknowledgements to return from the destination before sending more data. This works great on the LAN where acknowledgements return quickly and data is rarely lost. But as these examples show, even a small amount of latency or loss can be disastrous for performance.

On top of that are limitations within the application protocols. On notorious example is CIFS, the Microsoft file sharing protocol used to access networked drives. CIFS adds another layer that limits how much data can be sent while waiting for acknowledgements. Every user who has tried to open a file on a shared drive physically located at a different site has screamed to the IT team, "our network is too slow!" But the problem is not the network. With 40 ms of latency between a file server and a Windows 7 PC, drag and drop of a file takes ten times longer than transferring the same file using FTP.

From these examples, you can see why we call latency the silent killer. It's not the delay itself that's the problem, but how the delay impacts the ability of protocols and applications to transmit data. Fortunately, that means solutions are possible by changing how the protocols and applications operate.

Discuss this in the Forums