Last week, I explained the growing importance of understanding TCP basics -- specifically, TCP windowing. As companies deal with ever larger amounts of data that need to move across the WAN, whether between premises or between a premise and the cloud, it becomes increasingly important to optimize the basics to achieve the best performance. To ease this process, a variety of networking vendors sell so-called WAN accelerators. However, they're no panacea, suitable to only certain environments.
The truth is that these vendors and their customers are often plagued by a general lack of understanding about what the devices can and can't do. You might even assume WAN accelerators to be the snake oil of the Internet age -- surely you can't get more than 10Mbps of throughput on a 10Mbps circuit, right? On the other hand, you often hear the notion that WAN accelerators are techno-magic devices that can make anything faster. As is usually the case, neither extreme turns out to be true.
WAN accelerators are great in some situations and at best unhelpful in others. Furthermore, not all WAN acceleration devices and software stacks do the same things. Read on to understand when WAN accelerators really deliver faster WAN networking.
WAN acceleration basics
The first thing to understand is that most WAN acceleration devices are deployed in pairs, one at each of the sites between which the bandwidth is to be optimized. You need a device at each site because WAN acceleration devices optimize traffic in a way that renders such traffic unintelligible to the original destination. It's like encryption, where you need a companion decryptor at the other end to make the encrypted data intelligible. Thus, a WAN accelerator must be present at the receiving end to return the network traffic to its original form.
Optimizing congestion-avoidance mechanisms can include much more aggressive responses to packet loss, and window rescaling can decrease the impact of small amounts of congestion-related packet loss.
What's key is that these optimizations can be used regardless of whether the endpoints on either side of the connection are configured to implement them. Because the devices are deployed in pairs, they will negotiate those optimizations themselves. Thus, that Windows Server 2003 machine with the default 64KB maximum window size I used in my example last week could send and receive data as if it was configured for a much larger window size, if it and the connection at the other end both used WAN acceleration.
These optimizations can work extremely well when the connection between the appliances is highly reliable and where packet loss is seldom seen. But if the connection is frequently unreliable, the optimizations can result in strange endpoint and application behavior. In many cases, from the sending endpoint's perspective, data appears to have already been received by the receiving endpoint. But in reality, the local acceleration appliance has sent acknowledgements to the sending endpoint to convince it to transmit more data. If packet loss occurs between the appliances and results in a connection timeout, an application could assume that the receiving endpoint has collected the data -- even when it hasn't. You may not be able to use WAN acceleration for applications sensitive to such packet-loss scenarios.
When simply optimizing TCP isn't enough, some WAN accelerators will translate TCP data flows into a different protocol between the appliance pairs. As in the simple connection optimization examples, the appliances will terminate TCP connections locally at each site, but instead of speaking optimized TCP between each other, they translate the data flow into a connectionless protocol such as UDP.
Does it actually work?
Nobody likes to hear the answer as to whether WAN optimization works in the real world, but it's the truth: It depends.
The variable you have to carefully consider is what kind of traffic you're trying to optimize. If the traffic is real-time data such as VoIP or remote display protocols like RDP and ICA, traffic optimization and deduplication aren't likely to have any real effect. However, if the data flow is bulk data -- especially repetitive bulk data -- a deduplicating WAN accelerator can magnify the observed throughput of a WAN circuit many times over.
A particularly good example of this is inefficient IP-based SAN replication. Dell's EqualLogic SANs are a good example of where WAN acceleration can help: I've seen a good WAN accelerator handle what would have been a constant 100Mbps with less than 10Mbps of actual WAN bandwidth (a multiple making even pricey WAN accelerators worth the investment).
However, many other SAN platforms have implemented the bulk of the TCP optimizations, compression, and deduplication that most WAN accelerators bring to the table. Adding a WAN accelerator for these platforms won't yield much of a benefit -- it's already embedded in the SAN platforms.