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.