Updating a QoS strategy for VoIP traffic

Most organisations have quality of service (QoS) configured to support their VoIP traffic by now. In many cases, these configurations have been in place for a long time and are based on QoS strategies constrained by the capabilities of previous generations of network hardware and WAN technologies. If you have relatively modern equipment or are evaluating new hardware to upgrade your old routers and switches, there are a few relatively new trends in QoS you should be aware of. One of the most popular is the "scavenger class."

The scavenger class is any one of the classes in a Class-Based Weighted Fair Queuing (CBWFQ) scheme, and it is so called because of its purpose. "Scavenger" is not really a technical term, and you probably won't find the word in your vendor's command line interface. It's really just a component of a QoS strategy implemented on routers and switches.

The basic idea of a scavenger class is to profile your traffic so that you know what "normal" is, and then to mark traffic that exceeds normal so that you can drop it later in the event of congestion. This is primarily a defense against worms and other distributed denial-of-service (DDoS) attacks, but it can be useful for other things.

The scavenger class is also an example of a class sometimes called "less than best-effort." As you may already know, in the network world, "best-effort" is a bit of jargon that means something closer to "worst" than "best." It means that there are no guarantees that packets in this class will be delivered. It generally refers to the class that gets served at the lowest priority. So the concept of something being less than the lowest might be hard to wrap your head around initially.

A better way to think of it may be that your default class is no longer your lowest priority, although that's not really technically correct either because the traffic isn't so much prioritised as it is weighted, in your typical CBWFQ schemes. What really happens with less than best-effort and the scavenger class is that you have dedicated the smallest percentage of bandwidth possible to this class. For instance, Cisco recommends on IOS-based systems that you assign a CBWFQ of 1% to the scavenger class. Of course, depending on how generous you are, and exactly what sort of stuff you put in the scavenger class, you might give it more bandwidth.

In addition to DDoS traffic, this concept can also be the foundation of a useful strategy for non-business-related traffic, such as streaming video, and for legitimate business traffic like doing server and workstation backups over the WAN during business hours. In those cases, it's just not good enough anymore to have that traffic in a regular class that gets 30-70% of your bandwidth. It's much better to let those applications run on the network when there's no other traffic, and essentially shut them off when there is other traffic.

This is particularly important because a lot of these servers-to-server applications are getting better at hogging bandwidth. That means better performance for them, but it can kill normal user traffic. For instance, you might want to run backup jobs or some other scripted or batched data transfer across your WAN. Maybe you want to run this job overnight when there aren't any users on the network, but you don't know how long it will last -- and if it's still running at 8 a.m. the next day, you don't want it to affect your users' interactive traffic. Putting this traffic in a scavenger class can be a good solution.

These strategies aren't for everyone, and it takes quite a bit of coordination between devices from the access layer to the WAN, so it is a little more difficult to implement than just configuring a few simple commands on the WAN router interfaces.

About the author: Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.