fair-queue (WFQ): a tool with limited value for VoIP

In experimenting, I've had trouble saturating T1's to demonstrate QoS. It turns out that fair-queue is really the problem.

fair-queue is an active-queue management (AQM) scheme applied to the network interface on a Cisco router. It's on by default on cisco boxes. It attempts to divide the bandwidth evenly among the flows on the link.

A "flow" is described by the four-tuple of source IP, source port, dest IP, and dest port.

After dividing the link evenly among N flows so that each one gets 1/N of the link capacity, if there's some capacity left over, fair-queue lets the hungrier flows use the link bandwidth.

Under limited circumstances, fair-queue can actually protect phone calls and ensure they get enough bandwidth. I.e., it can provide a type of QoS guarantee. But for that to work, the number of flows through the link must be few enough.

What's "few enough"? Well, for link with capacity C (kbps), and using a VoIP call codec with that uses unidirectional bandwidth of B (kbps) per call, and where F is the number of flows on the link, then for fair-queue to guarantee adequate bandwidth to VoIP calls if F<=floor(C/B).

For example, A DS1 provides 1536 kbps of capacity; a G.711 call needs about 87 kbps in each direction, so fair-queue will guarantee bandwidth for calls as long as the total number of flows is floor(1536/87)=flood(17.655)=17 or fewer. If the total number of flows on the link exceeds 17, then there are no guarantees that each phone call will get the 87 kbps it needs.

How many "flows" is normal? My laptop currently has 24 flows active. My upstream bandwidth is around 1500 kbps. So if I added a VoIP phone call, and depend on fair-queue to protect the bandwidth, then I'm out of luck. In another test, I was able to generate 9 new flows just by visiting http://youtube.com/

You can disable it on an interface with "no fair-queue". However, some other commands, such as "max-reserved-bandwidth" automatically restore fair-queue. So be sure to double-check check your config when you're done.

Flooding packets for VoIP testing

It's sometimes useful to saturate a network with simple traffic to test your QoS measures. What you want is something that'll send a controlled amount of bandwidth. A TCP-friendly connection won't work, because TCP slows down to the available amount of bandwidth. iperf from NLANR is one such tool. However, you have to have it running on both the sender and the receiver.

I couldn't find anything quick and easy that would do it. Here's a tool that does it. You'll need Perl and Time-HiRes to use it.

#!/usr/bin/perl -w 
## Mark R. Lindsey, lindsey@acm.org
## Flood a destination with fixed-sized UDP packets.

use Time::HiRes qw( usleep ualarm gettimeofday tv_interval );
use IO::Socket; 

$number_of_args = $#ARGV + 1;
if ($number_of_args < 3) {
 print "Usage: flood_udp.pl target_ip target_udp_port packets_per_second\n" ;
 die "Not enough arguments"
}

$target = $ARGV[0]; 
$target_port = $ARGV[1];
$packets_per_second = $ARGV[2];

$interpacket_delay_microseconds = 1 / $packets_per_second  * 1000000;

socket(BLAST, PF_INET, SOCK_DGRAM, getprotobyname("udp")); 

## This assumes a 1500-byte path MTU. The idea is to make a maximum-sized packet without fragmentation. 
## But if there's some fragmentation, that's not all so terrible.
my $payload_size = 1472;  
my $ip_packet_size = $payload_size + 8; ## assuming Ethernet
$msg = "u" x $payload_size;

my $bytes_per_second = $ip_packet_size * $packets_per_second;
my $bits_per_second = $bytes_per_second * 8;

print "$bits_per_second bits/second, $bytes_per_second bytes/second\n";
print "Sending to $target at UDP port $target_port\n";

## Send the UDP packet 
$ipaddr = inet_aton($target); 
$sendto = sockaddr_in($target_port,$ipaddr); 

while (1) {
 send(BLAST, $msg, 0, $sendto) ;
 usleep ($interpacket_delay_microseconds);
}

Getting VoIP Equipment Documentation

VoIP software and hardware vendors come from two camps: There are those who hide their documentation from the general public, and those who are open.

Too many hide their documentation. Even if you register on their site as a guest, you can't get it. You usually have to be a customer with a paid support agreement. This includes Sylantro, BroadSoft, MetaSwitch, Acme Packet, General Bandwidth, PolyCom, and Alcatel-Lucent. Your equipment may ship with a CD-ROM of old documentation, if you're lucky.

Others open up their documentation. Cisco and Juniper are in this group. Cisco is notable, because they have documentation on all their VoIP products available online for free. Aastra, Polycom, Snom and Adtran have their documentation available, as well. Of course, Asterisk's documentation -- and source code! -- is available. From an engineer's perspective, this gives them a definite competitive advantage.

I care about this because I spend time configuring and troubleshooting equipment that belongs to other companies. For example, when fictional company name Stratum(3) had problems with their Acme Packet SD, I didn't have access to their support agreement. Because of that, I didn't have access to the documentation on the SD. Stratum(3) is willing to hire me for my expertise, but not willing to give me access to their support agreements.

Closed documentation just makes it hard to get support; it makes products hard to use. The documentation is not google-able. If you hire a new staff member, it's harder for them to get docs on the equipment you have. And if you bought the product in the past, but you're not maintaining active support, you don't have access to documentation on software that you did buy.

Recently, I noticed that BroadSoft Inc has made a bold step toward publishing their documentation: BroadSoft University is operated by VoIP Training LLC. For a small fee, you can do an online course, and become a BroadSoft Certified Platform Administrator, BCPA. The online course lets you download some of the key BroadSoft documentation. This means that an outside party who's interested in BroadSoft can now access actual useful information without signing a BroadSoft support agreement.


I doubt that this release of info is part of any grand strategy by BroadSoft. Most of the people taking the course likely already have BroadSoft support agreements, and thus have the documentation already. But the BroadSoft University site is separate from BroadSoft's own site, requires a separate login, and separate payment. The technical information on the product is getting out there where technicians can get to it and use it more easily. This is a small step, but an encouraging one for anyone trying to learn about or troubleshoot BroadSoft platforms.