Welcome to the new ZDNet! Give feedback or learn more about our updated design here. Or, return to the classic view.

Packet Loss Meets 2012

What would happen if we couldn’t agree on the same time? Team meetings would never start on time.

What would happen if we couldn’t agree on the same time? Team meetings would never start on time. You might go catch a movie only to find it was over an hour earlier. Nothing would get done and the functioning of our society would grind to a halt.

A frightening picture that is more suitable for 2012, but applicable to our networks today. The problem stems from the overuse of packet buffers in our equipment, a problem called Bufferbloat. Developers are trained all too well to avoid dropped packets – and for good reason. A 200ms round trip delay can be turned into one second delay when packets need to be retransmitted due to packet loss. (To understand this better read this whitepaper.) So packet buffers were placed to accommodate for the overflow of packets occurs in all shared networks. Each buffer introduces some small amount of delay, though, but saves the much greater amount of delay caused by packet retransmission.

What’s happened though is that as the number of buffers have increased in our network the amount of delay they’ve introduced has also increased, explains Dave Taht, who helps run the site bufferbloat.net. The result? Left unchecked, Bufferbloat will only cause packet loss to get worse:

“As the total traffic becomes heavier, network traffic patterns will grow burstier and more chaotic. Usage of individual links will swing rapidly and crazily between emptiness and overload cascades. Latencies, and total packet times, will zig from instantaneous to check-again-next-week-please and zag back again in no predictable pattern.

Packet losses - the very problem all those buffers were put in to prevent - will begin to increase dramatically once all the buffers are full, because the occasional thousand car pileup is the only thing that can currently tell Internet routers to slow down their sending.

Bad consequences of this are legion. One of the most obvious is what latency spikes do to the service that converts things like website names to actual network addresses - DNS lookups get painfully slow. Voice-over-IP services like Skype and video streamers like YouTube become stuttery, prone to dropouts, and painful to use. Gamers get fragged more.

And it’s not just video that or gaming that going to suffer. The very functioning of the network is undermined: “NTP, ARP, DHCP, SSH, and various routing protocols. Yes, things as basic as your system clock time can get messed up!”

The folk at Buffer Bloat have their own ideas as to how to solve the problem. They identify three approaches - test for and fix Bufferbloat , decrease unmanaged buffer size, and use smarter rules in servicing the buffers.

There is a fourth approach, prevent packet loss altogether without adding delay. The WAN optimizers from Silver Peak Systems, for example, can reconstruct up to six lost packets in real time. Silver Peak does this by applying RAID-like technologies to packet transmission and insert a packet every “N” packets with a CRC check on the preceding packets. Should a packet be lost the receiving side can reconstruct the data with the help of the CRC check. You can read more about the details of the technology here. (Disclosure here: Silver Peak is a client of mine.)

Regardless of the approach, though, network architects need to pay attention towards the impact packet loss will have on your networks today – and tomorrow.


You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
Subscription failed.
See All