posted on Tuesday, July 20, 2010 1:21 PM
Anyone who has children and travels by car will tell you that there is no substitute for the mandatory array of bathroom breaks that must be taken by those children. One of the many reasons I prefer to travel at
night when driving long distances is that children who are asleep are not asking to pull into the next rest stop for yet another restroom break. And I was one of those children. My father once told me I had the smallest bladder on the planet… Right before my mother made him stop at a gas station for me.
Another favorite is the “tourist trap” stop, where someone in the car with authority decides to stop, even though everyone over the age of 12 knows that the stop will be wasted on sites like “The World’s only three horned steer!” or “The ultimate hedge maze!” These may be things I’ve seen. May be.
When driving, these stops slow your drive to your destination and if someone was waiting for you, ultimately make you late, but since you are on a discrete vacation, this is not terribly bad. You get less time on-site, but in the end return home and get into your old routine.
This is completely not true with your data.
STOP! GO! STOP! WAIT!
Every stop on the network path that your data makes is a small disaster for your overall network throughput. The closer your WAN is to capacity, the greater the impact of each stop. 
Those of us who have been hanging in the networking space for too long call it latency, and treat it as a bullet point on a brochure, but it’s a real beast that consumes resources, sometimes with horrendous effects on your network throughput.
The problem is basically the same one as a long car ride. You’re clipping along, someone sees a rest stop (in this case a network device of any kind – Application Acceleration, WAN Optimization, Encryption, whatever), and the packet stops off. The greater the latency, the longer the stop. And then it goes on until it sees the next one. Each stop may be small, but they’re stops that slow down the rate of the packet across the network/WAN/MAN/airwaves…
And because most network protocols require a response, and most network protocols are timed, that way lies doom. Imagine if there are 5000 cars behind you, and you have to stop at every restroom you pass, and they all have to follow you through the rest room. But there are 5000 cars coming the other way that have to wait for your cars to get off the road before they can take off. And if you’re too late they send a separate car to go check on you, and then a copy of you gets sent… Okay, maybe the car analogy is breaking down here… Because networks are more complex – there is one you, and you’re going to get to your destination. If a packet doesn’t make it to the destination in a timely manner, a request is sent to go get it, and then the packet comes again.
WHAT I WAS REALLY TRYING TO SAY WAS…
The more congested your network, the more problems latency causes, just because the chance of slowing things down too much grows (it’s not that simple, but close enough for this blog), and once you reach a certain level of packets not arriving in a timely manner, requests and retransmits start filling the rest of the over-burdened pipe and causing even more delays.
What can you do about it? First, make sure it is or might be a problem for you. Congestion and latency are measurable these days, and it should be pretty straightforward to determine if you have a device that’s gumming up the works. Figuring out where latency is introduced into a connection can be harder but is not insurmountable.
LESS STOPS, MORE GOODNESS
Also, combine functionality where it makes sense. Many years ago I came out against all-in-one security boxes because they offer a single point of failure for a whole array of security on your network, but if you already have a high latency link, they might just ease your pain by eliminating the time it takes to parse packets (among other things) multiple times. Several of our solutions act in much the same manner – utilizing TMOS on BIG-IP means that any of our solutions sold as a module - WOM, ASM, etc. can act on the packet in conjunction with load balancing requests. Other vendors do similar things by combining functionality (of course I believe not as well as F5, that’s why I work here), and each time you don’t have to touch the packet/envelope/etc, is one less tiny bit of latency you don’t have to worry about.
With multiple cores, SSL offload, and outrageously huge memory capacities, and Saas/Cloud making WAN communications a growing portion of our overall data communications, we have again turned the corner where the server doesn’t have to be the bottleneck, the network might well be. So it’s time to consider latency as more than a check-box again.
NOTE: There are many sources of latency, I’m merely drawing your attention to one that is completely within your control.
After all, the key difference between vacation and the network is that the packet doesn’t care if it stops or not, so don’t make it if you don’t have to.
Related Articles and Blogs
