QoS, prioritizing Voice, AutoQoS

[edhunterr]

Hi everyone, 

Not entirely sure this is the right sub-section for this but since i have switches + routers+ firewalls involved, I guess any one of these would do? 

Nevertheless, Im looking into introducing QoS to our very simple local lan, in order to just prioritize Voice traffic going towards our PBX which is hosted on the internet on the provider side.

While we have no congestion, no dropped packets, no errors on any of the interfaces in the path, we do experience robotic/choppy voice at times and i thought it would be a good idea to prioritize voice even when we have more than enough bandwidth and no drops or errors.

All IPs are made up.

My setup is as follows,

Agents (PCs) are running a softphone application. This application sends STUN requests to the PBX which is hosted on the VoIP provider side (55.55.55.55). From there on, when STUN is established, its pure UDP traffic with small 224 byte packets between the two. 

We have static routing which routes any traffic for 55.55.55.55 to our ASA 2 which is a clean ISP line. All the rest of the traffic goes through our ASA 1. 

While the softphone does not mark the packets by itself, we marked the packets using group policy and i checked a packet trace and I can clearly see the header -> Differentiated Services Field: 0xa0 (DSCP: CS5, ECN: Not-ECT)
1010 00.. = Differentiated Services Codepoint: Class Selector 5 (40)

Now, on our Cisco Switches, router and ASAs, everything is FIFO. We have no shaping, qos or policies to categorize, prioritize traffic.

My questions are, could AutoQos work in this scenario? Or is it best to be used with Cisco Softphone and Cisco IP phones? Since packets arrive marked at the switch, could i use AutoQos trust dscp on the interfaces? Or is that to be used on egress trunk interfaces? 

What would be the easiest implementation to carry marking throughout and prioritize the traffic towards that PBX in this network? 

Thank you.

[Joseph W. Doherty]

The VoIP issue(s) described might indeed be improved by using QoS, as VoIP is sensitive to delay and jitter (also drops, but you note that doesn't appear to be an issue for you).

As the early forms of AutoQoS, more or less, were designed to easily prioritize VoIP traffic, that something the later variants usually can still do well.  The latter variants, though, do "muck" with your traffic more than the earlier AutoQoS, if other traffic needs don't "agree" with the Cisco QoS "model", AutoQoS can make issues for such other traffic.  But, if you're not seeing drops, likely AutoQoS won't make anything else worse.

As to your more specific questions about how AutoQoS would support, or not, your environment, hard to say as over the years, Cisco has had different AutoQoS models, and how individual platforms support it, varies based on the specific device.

[Elliot Dierksen]

Even if AutoQoS doesn't meet your needs, it is a great place to start. You can turn it on for a single port to get it to build all the templates, and then you can tune them to your needs.

[Joseph W. Doherty]

Personally, unlike @Elliot Dierksen, unsure attempting to "tune" AutoQoS templates, especially based on the latest AutoQoS models, is a great place to start unless you're already pretty knowledgeable about QoS (possibly such as being a CCIE [this is not a ding against Elliot or CCIEs in general, just the opposite, i.e. they are so good, for such folk, AutoQoS templates might, indeed, be a great place to start]).  If you're knowledgeable enough to "tune" AutoQoS templates, possibly you're also knowledgeable enough to create your own QoS policy, unique to your needs.

BTW, I do think those template can be very useful to help you become knowledgeable about QoS, and possibly they can be useful, just as they are, i.e. w/o modification, for meeting certain QoS needs.

Disclaimer: I'm biased, as I believe Cisco's and RFC's latest QoS models are overly complicated.  Rather than a 11 or 12 class model, I've often recommended just a 4 class model (below) that is often effective for many QoS needs.

(logical) policy-map 4class
class real-time
priority percent 35
class foreground
bandwidth remaining percent 81
fair-queue
class background
bandwidth remaining percent 1
fair-queue
class default
bandwidth remaining percent 9
fair-queue

[edhunterr]

I guess I was going against my "experience" here with posting this early, of knowing that there are no shortcuts when it comes to these kind of implementations, i.e. you have to read through documentation a couple of times at least in order to even be able to draft a plan for implementing.

However, i truly appreciate the replies.

I do see your point with AutoQos. Falling into the same trap of rejecting my own intuition, i thought that maybe, AutoQos was an easy way out since my lan is "simple" and i only want to prioritze just one class of traffic.

I have fundamental gaps though that do not help here. I have the basics down and i was involved in telco QoS implementations with different vendors but, i think i need to revisit.. 

For example, a question i have is where do you have to carry markings across the path in order to be sure that traffic is indeed prioritized up and until leaving your network. Like for example, ingress and egress on every device? And how do you do egress? Is it just a matter of buffering at the egress? What about return traffic? What happens there, do you just dismiss that? 

[Joseph W. Doherty]

". . . i thought that maybe, AutoQos was an easy way out since my lan is "simple" and i only want to prioritze just one class of traffic."

Again, AutoQoS may, and likely would, prioritize your VoIP traffic just fine, also again, current implementations do more than that to your traffic.

To just prioritize VoIP, often:

(logical) policy-map 2class
class real-time
priority percent 35
class default
bandwidth remaining percent 100
fair-queue

will be enough.  FQ handles most other traffic, very, very well, unfortunately usually FQ isn't a switch feature.  However, often in a switch environment, just "protecting" VoIP traffic is sufficient (due the common abundance of bandwidth on many LANs).

As to your marking questions, realize a ToS marking is just a "short-cut" to identify the QoS "specification" of the traffic.  It's not needed, nor when present, guarantees any QoS treatment.

Ideally, when (L3) markings are used, they are generated by the source, and carried to the destination (unless changed in transit).

Generally, QoS is mostly done/concerned at egress.  Ingress QoS, often only deals with marking issues and/or policing.

Return traffic, depending on the needs of the traffic, can be just as important although, it might be treated totally differently for QoS purposes.  (Possibly surprising, sometimes "return" traffic should have better QoS treatment.  A possible example might be TCP ACKs.)