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.
Tuesday, January 29, 2008
fair-queue (WFQ): a tool with limited value for VoIP
Subscribe to:
Post Comments (Atom)
Mark Lindsey is a Senior Systems Engineer with ECG, Inc. 
1 comments:
Hi,
Good post thanks. Just wanting to check.
I'm currently on ADSL 1 and 800kb up seems to be about the best I get. So 800/87=9.
Currently I believe WFQ is off on my Cisco 857W. So from what you've said it's better to be off? Running 3 computers and SIP IP phone.
Spent the last couple of hours trying to work out if there was some sort of QOS I could turn on. All I've come across is WFQ. You've managed to explain its implications the best.
Thanks for the help!
Post a Comment