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 to about as fast Rich Eisen’s 40-yard dash time. 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 your users’ apps won’t run on the WAN – and some suggestions on what to do about it.
RELATED: Demand growing for application performance management tools, experts say
1. 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, such as CIFS, 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 acknowledgements adds up and undermines application performance.
2. TCP can cause big headaches.
The problems of TCP performance have long been known – limited window sizing issues, too many acknowledgements, and so on. Unless you address the underlying problems, TCP applications will continue to crawl along. It’s one of the reasons real-time apps, such as VoIP and video conferencing, use UDP.
3. 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 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 U.S.) and .5% packet loss.
4. 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 not average loss, but random 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).
5. 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, are 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, say frames being too long or short, generally as a result of bad drivers.