by Dr. Cathy Fulton
WAN optimization devices are certainly great pieces of technology. They do much to alleviate the problems that companies have with keeping applications which travel over the WAN responsive. But deployment is not without risks and companies need to look at cost vs. performance benefits.
There are several benefits to WAN optimization. One is offloading WAN links – when there is less congestion every application performs better. Another benefit is minimizing the impact of latency on the network. Even if it doesn’t reduce the traffic on the network, TCP and application optimizations can reduce the effective latency experienced by your data.
You might even get a benefit from increasing WAN utilization while still receiving good performance – by fulfilling a latent demand. A good example of this would be a company that receives orders over a network. With WAN optimization, the holy-grail scenario is that people who had been frustrated because of poor performance would now place orders on a more responsive order system. You have to have exactly the right circumstances and environment to hit the points where utilization goes up while end-to-end response time decreases, but it is certainly possible.
But WAN optimization is not a panacea. It works well on a subset of performance issues, but can actually be detrimental for others. In terms of mitigating the effects of congestion, it works best on small to mid timescales; it certainly does not eliminate the need for longer timescale techniques including capacity planning. And it does not work well with every application – some perform worse when “optimized”. If you’re interested in what sort of benefit you’re going to get from your WAN optimization efforts, you need to look at the amount of congestion on your link and the composition of that traffic.
(Continued…)
There are two ways WAN optimization vendors try to reduce traffic on the link. One is compression, but generally the more powerful method is suppression through byte-level, object-level, or application-level caching. If a WAN optimization device sees the same bit pattern on the wire, instead of transferring the bit pattern, it can transfer an index to the remote database cache of data. That’s where you tend to get the real reduction in traffic.
But there’s still overhead associated with WAN optimization and often people don’t think about it. Nothing’s for free, and WAN optimization reduces traffic volumes by doing additional processing and through the exchange of additional data. You have to make sure that the additional processing delay and overhead does not outstrip the gains you get from optimization.
You need to know what applications are running on your network, and once you do, you can get an idea which applications will benefit from WAN optimization. For example, certain applications actually have worse performance under WAN optimization. A number of vendors, for example, bypass VoIP traffic altogether because they don’t want to add any extra latency. And highly interactive applications with low volume exchanges tend to do poorly when optimized – both response times and traffic volumes may actually increase.
What you should do up front is an assessment to identify the nature of the performance issues and the applications – to evaluate where WAN optimization techniques are appropriate. After you deploy, you need to measure the results to validate the impact. And, you still need to maintain visibility into your network to handle those issues untreated by WAN optimization – which can be tricky because of TCP termination and the use tunnels that mask the real applications, hosts and behavior.
When deploying, bring in different WAN Optimization vendors to test what works best on your setup – different vendors excel at different techniques. And don’t forget that there’s also the management overhead. Some vendors products are easier to manage than other vendors – and management is a recurring cost.
Ultimately, it all comes down to monitoring what’s on your network before and after WAN optimization device deployment. If you see an improvement that’s significant enough to justify the cost and can retain sufficient visibility to manage the future, then you should deploy. If not, it’s time to seek another solution to the problem.
Dr. Cathy Fulton is CTO at NetQoS.
No comments yet.