QOS configuration on a VOIP only interface

[paul amaral]

Maybe this is a silly question, but what do most people do with QOS when a device is handling just VOIP packets. E.G, lets say you have a 100mbs line on a device that is handling just voip, how would you setup QOS in this situation, would you even set it up all. They way I have been doing this is taking 50% of the CIR and putting in the priority queue for VOIP, 5% for signal and the rest in the default class with WRED. I then have QOS in to the voip interface (LAN side) and outbound to the WAN. Just curious how some of you handle this situation as this has always been tricky for me for some reason.

TIA,

Paul 

[Elliot Dierksen]

Not all features are supported on all platforms, but here is a base template that I have used a number of times. No warranty expressed or implied, use at your own risk.

class-map match-any Routing-Traffic
 match ip precedence 6
class-map match-any Stream-Video
 match ip dscp af13
 match ip dscp cs1
class-map match-any VoIP-Control
 match ip dscp cs3
 match ip dscp af31
class-map match-any Video-Conf
 match ip dscp af41
 match ip dscp cs4
class-map match-any VoIP-RTP
 match ip dscp ef
 match ip dscp cs5
!
policy-map BASE-VOIP
 class VoIP-RTP
  priority percent 33
 class VoIP-Control
  bandwidth percent 5
 class Routing-Traffic
  bandwidth percent 5
 class class-default
  fair-queue
  random-detect
  random-detect ecn
  bandwidth percent 25

 Edit: This is targeted at a WAN interface. For internal switch ports, AutoQoS is (mostly) your friend.

[paul amaral]

Elliot I use this as well but my question is on an interface that only passes voip/signal traffic and no data expect keep alives etc. What is the consensus in this scenario, do most people setup QOS. Curious on what percent you would setup for voip/signal in such a case. 

Paul 

[Joseph W. Doherty]

Elliot, your suggested QoS policy-map looks to be much like "the book" would recommend, but in my, not so humble opinion (laugh), I think "the book" is (cough, cough) less than optimal.

My "generic" policy is:

policy-map Generic
class real-time
priority percent 35 !or 40
class foreground !or priority
bandwidth remaining percent 81
fair-queue
class background !or scavenger
bandwidth remaining percent 1
fair-queue
class class-default
bandwidth remaining percent 9
fair-queue

How do you use the above.  Well, you start with everything in class-default, unless you have a good reason to direct traffic to another class.  As you note, not all platforms support all QoS features, and for the above, things like class queue sizes and/or FQ sizes might need to be tweaked (if platform supports).

The foreground class should, generally, only have light bandwidth usage flows in it, those that really deserve/need better treatment.  For a "poster child" example, something like Telnet or SSH might use this class (but you got to watch for exceptions to the norm - in the past, my class-maps would dynamically chose policy class using some form of dynamic bandwidth usage beyond just the kind of traffic - you can also stub your toe on things like SCP and SSH "look alike").

(In fact, with so much done within NetBEUI and HTTP [and now HTTPS] it's difficult to "type" traffic.  So, FQ, at least, generally round-robins flows.  However, sometimes you can also [additionally] classify based on actual bandwidth usage [which encryption cannot hide] and/or other "hints", such as packet's size [non-max sized filled packets, often indicate a lower usage flow, but not always] and/or TCP push bit.)

The background class can be used for bandwidth hogs that don't need timely (as in interactive) response times.  "Poster children" for this class might be system backups, email server-to-server, etc.

FQ in class-default, generally does a very good job of keeping some (few) bandwidth hogs flows from being adverse to interactive type traffic flows.

Some problems with a "the book" approach, similar to what you posted, include:

As noted in a separate posting, low bandwidth allocations also make for low dequeuing priority relative to other classes.  So, for example, the 5% allocated to VoIP signally and routing protocol classes create a dequeuing ratio of 1:5 relative to class-default.  So, if a bandwidth hog fills class default, if signally and/or routing protocol classes' traffic is delayed, could that be a problem?

As also noted in a separate posting, I recommend against using RED.  But I didn't note why.

Well, for starters, it's curious there are so many proposed RED variants to "improve" (as in "fixing") RED, that alone should make one wonder.  Heck, Cisco has its own (better IMO) variant, FRED, but it's only provided, I recall (?), on Catalyst 4500s.

Some of the problems with RED, since it works on moving averages, it can actually drop packets even when queue is currently empty and conversely allow tail drops when queue rapidly fills.

As RED actual queues can be bigger than moving average value, actual packet drops can also be delayed resulting in a delay notification to sender to "slow" its transmission rate.

RED is only suitable for TCP and/or other flow rate adaptive traffic.  (Using it in class-default, may needlessly drop traffic where RED is of no benefit [for its intended purpose].)

Mixing FQ and RED is counter productive.  FQ will tail-drop specific flows filling flow queues [also against actual queue sizes], while RED drops against all traffic, globally.  Although bandwidth hog packets are more likely to be dropped, RED can drop packets from "innocent" (not filling pipe) flows.

I recall (?) Cisco's RED defaults don't generally correspond to Dr. Floyd's (creator of RED) recommendations, and often need some major adjustments to obtain optimal results (why I recommend RED only be used by QoS experts).

IMO (again, not so humble, laugh) FQ is much, much (much) better to use, in many cases, than WRED.  Cisco's FRED, though, being flow based, better targets the "guilty" bandwidth hogs, but it too takes some "tweaking" to work optimally.

Oh, one area RED can be used, it works well if you have need for WTD, although that too will require changing WRED settings.  But those are pretty easy to set for optimal usage (again, for WTD).

[Joseph W. Doherty]

For a port only handling VoIP, generally you wouldn't need any QoS.

However, if you already have a "generic" edge port policy that also handles VoIP, it might be less confusing to deploy it on all edge ports.  This way, you don't need to keep track of is this only a VoIP only port vs. a data only port vs. a VoIP/data port (or even a trunk port).

BTW, you mention allocating up to 50% of your CIR for PQ.  Cisco recommends not to exceed about 1/3 for PQ (or LLQ).  However, my experience has been often up to 50% is often okay, although I try not to exceed 35 to 40% for such an allocation.  (Cisco recommends 1/3 to provide sufficient bandwidth for other non-PQ traffic, but, generally, once you start to get above about 1/3, especially 1/2, you can start to bump into self queuing with the VoIP traffic itself.  I.e. another reason to avoid pushing too much beyond 1/3.)

You also mention using WRED.  I generally recommend against WRED unless you're a QoS expert.  RED is not quite as simplistic as its general documentation makes it out to be.

Regarding allocating a separate class for VoIP signalling, of about 5% allocation, yea that's the typical "book" recommendation.  However, since it's such light bandwidth usage, and sometimes VoIP phones don't, at least by default, mark it differently from VoIP bearer traffic, often it's not a problem to let it stay with its bearer traffic, or, if using FQ in another class, like the default class, it might also be directed there.

Also BTW, often not appreciated, when you assign something like VoIP signally 5%, that's probably enough bandwidth to protect it from drops, but bandwidth allocations also set dequeuing priority.  I.e. a small bandwidth allocation could delay the traffic.

[paul amaral]

Joseph always an insightful response. I am doing QOS at the edge and was going to leave the voip port without QOS, and may still do that, but for now I will leave it at 50% PQ and 5% for signal. Its interesting that Cisco never talks about the scenario or give us examples. I guess the thing to do, its QOS at the WAN/Edge port and leave the VOIP only port with FIFO If I understand you correctly!?

paul

[Joseph W. Doherty · Accepted solution]

Yea, you should be okay, for your VoIP ports, to use your "typical" QoS or none at all.

Remember, what QoS generally provides is a way to manage one class of traffic, relative to other classes, when there's congestion.  It can, also, be used to manage all the same class of traffic, when there's congestion, but for something like VoIP, if you need to manage congestion between VoIP flows, more likely you need additional bandwidth.  If you're wondering why, when you manage congestion between classes, you tend to treat some traffic better than other traffic (at the expense of the latter).  But, for something like all VoIP, what flows should be treated better than other flows?