Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

R E V I E W

Warding off WAN Gridlock

November 15, 2002
By Mike DeMaria

	Issue TOC
	Print full article
	Print this page
	Download as PDF
	E-Mail this URL
	Flame the author

	In this article
	Introduction
	Don't Say We Didn't Warn You
	Packeteer PacketShaper 4500
	Products Reviewed
	Executive Summary
	Politics, Law and the Traffic-Shaping Admin
	How We Tested
	SIDBAR: Make Your Case
	Report Card

Even as many enterprise LANs luxuriate in relatively inexpensive bandwidth, all too often WAN pipes can't keep up, meaning mission-critical and time-sensitive applications get bogged down. If you've experienced this on your WAN, you have two choices: Buy more bandwidth or use what you have better. The first option is a very expensive proposition. Moreover, latency- and bandwidth-sensitive applications, such as streaming video, must retain a minimum amount of throughput at all times--something you can't guarantee just by buying more bandwidth. And though there are QoS (Quality of Service) standards--such as DiffServ (Differentiated Services) and MPLS (Multiprotocol Label Switching)--these only prioritize traffic; they don't necessarily guarantee minimum bandwidth.

Traffic shapers, on the other hand, both prioritize traffic and guarantee minimum bandwidth, making them a cost-effective alternative. These devices limit bandwidth hogging by greedy applications, guarantee minimum throughput for users, groups or protocols, and better utilize wide-area connections by smoothing out bursty traffic. For example, you have plenty of bandwidth, but time-sensitive traffic like VoIP (voice over IP), which is extremely sensitive to latency, is being clobbered by traffic that is just as critical but less time-sensitive--FTP downloads or remote backups, perhaps.

Once we decided to test traffic shapers, we needed to develop criteria. In this case, we opted to focus on devices that specialize in QoS. Why a dedicated box when many routers have QoS capabilities? Because the added overhead can affect performance; more on this point later.

We tested dedicated traffic shapers on a T3 Internet link at 45 Mbps. Vendors usually offer multiple iterations of a product that use the same engine and interface but operate at different speeds. You can buy an inexpensive shaper for a 128-Kbps link, or an expensive unit that can handle 200 Mbps. We graded traffic shapers on their bandwidth-management, reporting, management-interface and protocol-recognition capabilities and price.

We invited Allot Communications, Lightspeed Systems, NetReality, Packeteer, Radware and Sitara Networks to participate in our tests. Only NetReality declined, and we later learned that it had been acquired by Allot.

FYI

If you see a VoIP implementation in your future, take note: Because VoIP packets can take separate paths and arrive for reassembly out of order, quality depends on reducing latency--throwing more bandwidth at the problem won't help. A packet shaper can make a difference here by ensuring voice packets don't get lost.

Snoop Time

Reporting is the first component you'll employ--even before you start shaping traffic. Job 1 is identifying bandwidth hogs that are trumping more mission-critical and latency-sensitive protocols. With good reporting, you see the most active protocols over time and the most active servers and clients. This is important: You can't effectively shape traffic if you can't identify the source of the troubles. Is Web traffic slowing down your network, or do you have just a few greedy users?

Layer 7 inspection is crucial. Once upon a time, we mapped ports to protocols, but that simple solution no longer works. For instance, nowadays almost everything runs over Port 80, the standard HTTP port. There is a good chance traffic over Port 80 will be allowed to pass through the firewall. The best example of this problem is P2P (peer-to-peer) software, which is notorious for generating a huge amount of traffic. Ask any college IT administrator: P2P is clogging schools' WAN links like cafeteria burgers clog arteries. Say you're in a situation where P2P is dominating and you want to allocate more bandwidth for Web browsing. If the P2P client runs, by default, on Port 80, and your traffic shaper inspects only at Layer 4, you have a problem. P2P traffic will fall under the same policy as Web traffic (for more on the legal aspects of P2P traffic, see "Politics, Law and the Traffic-Shaping Admin"). We replicated this problem by running non-HTTP traffic on Port 80 and finding it classified as HTTP. We also found that traffic shapers do a better job at Layer 7 inspection than others.