Apr 2, 2012
You know the drill. The request comes down to run XYZ app between offices. You run it on the LAN and, of course it all looks fine, but when you put it on the WAN, performance drops about as fast Rich Eisen on the 40. Now you need to explain the problem to your users and come up with a solution. Let me save you the trouble. Here are the top five reasons why your users’ apps won’t run on the WAN – and some suggestions on what to do about it.
Not all applications were made for the WAN. Application developers like to assume optimum network conditions, but the WAN, we know, is the farthest thing from the truth. One of the major issues is that some protocols are way too chatty for their own good. And for each transmission they send, they wait for an acknowledgement. Given sufficient distance between locations the delay introduced by those acknowledgments adds up and undermines application performance.
TCP can cause big headache. The problems of TCP performance have been long known – limited window sizing issues, too many acknowledgements and more. Unless you address the underlying problems, TCP applications will continue to crawl along. That’s why many real-time applications, such as VoIP and videoconferencing, use UDP instead.
Bandwidth isn’t what the carrier says it is. Sorry, but just because your company purchased a 1 Gbps line between San Francisco and Atlanta doesn’t mean that your app can transfer 1 Gbps of data. Applications will spawn many connections but generally transfer data using only on one or two of them. The throughput of this connection, and by extension the application, is limited by the packet loss, latency and bandwidth of the WAN connection. There are plenty of online WAN throughput calculators that can show how a 1 Gbps line can be reduced to just 16.51 Mbps given 10ms of latency (insanely short for WANs in the US) and .5 percent packet loss.
Packet loss varies a lot. Getting an accurate read on packet loss rates can be incredibly difficult. Most carriers will site 0 percent packet loss in their Service Level Agreements (SLAs), but those rates are typically only for the backbone. They don’t cover the local loops and, when they do, carriers average loss rates over a period of time, a 24 hour period or a month. But the kicker for application performance, particularly as it relates to real-time application performance, is random loss not average loss. Random loss on a given connection can be much harder to find out. Generally, end-to-end loss rates on MPLS networks, for example, run .1% to .5% (very roughly).
The service provider is guilty! The real bummer in dealing with packet loss is that there’s not that much an enterprise can do once the packet leaves its premises. WAN congestion, which causes packet loss and out of order packets, is in the hands of the carrier, not the enterprise. Symptoms of sources that you can address are layer-2 errors at the switch, CRC errors caused by faulty physical plant (cables, transceivers, etc.) and non-standard frame sizes (e.g., frames being too long or short, generally as a result of bad drivers).
The good news is that those problems can be easily addressed. Silver Peak WAN optimizers can all eliminate packet loss, optimize TCP, and do a whole lot more that turn your application from Rich Eisen into Usain Bolt.