This post is the second post in a three-part series on QoS.  If you haven't read the first blog post, I highly recommend reading the first part here.

I just completed a Quality of Service, or QoS, assessment for a customer.  While I was writing the assessment, I decided to brush up on my knowledge of QoS best practice to better serve the customer.  While it's still fresh in my brain I figure I will explain QoS here and hopefully someone will get a better understanding from this.

Before we dive into the how, let’s talk about the why; why do we need quality of service?  QoS is a general term referring to a system that classifies traffic, then based on the classification applies a shaping and policing policy to it.  The point is to make sure that when there is congestion on the network that important or time sensitive traffic is prioritized before other non-important or time insensitive traffic.  The classic example of this is real-time traffic such as voice and video traffic should get priority over email traffic.  Voice traffic cannot handle delays or dropped packets the same way email can, if it takes a second or two more for the email traffic to get to the exchange server the end user would never know, while on the other hand its very noticeable when voice and video traffic is delayed as stutters and freezing occurs in real time.

When thinking about QoS I find it easier to break it up into two categories: Classification, and Policy shaping / Policing.  Now I could dive into every scenario and really explain the details around QoS, however, to keep this blog post from turning into a literal book (no really there are literal books written on this single subject.)  I'm going to keep it high level.  Check out these two resources if you want a deep dive into the world of QoS:

• End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks, 2nd Edition
• Cisco EasyQoS Solution Design Guide (Chapters 1-3,9)

In this post I will focus on a very common deployment of QoS; support of end-to-end voice and video deployments.  Additionally, I will focus on Cisco's newer MQC way of deploying QoS rather than the older MLS QoS, however we will talk about some differences between MQC and MLS QoS.

QoS Classification

Before traffic can be queued, shaped, and policed it must be sorted into different classes.  Classification is the first step to providing priority between different types of data.  In a quick overview of the QoS standards (RFC 4594), there are two modern ways you will denote different classes, Class of Service (CoS) which is a layer 2 classification and Differentiated Services Code Point (DSCP) which is a layer 3 classification.  In both cases these classifications are a manipulation of the ToS bits in the packet or frame header depending on if the header is at layer 2 or 3.  Think of CoS and DSCP as being two ways to display the same information but at different levels.

Most modern voice and video applications mark their traffic with DSCP markings before sending it to the network card.  Because I'm constraining this blog to end to end voice and video traffic we will mostly talk about DSCP and leave CoS to another blog.

To simplify the understanding of the QoS standards Cisco has created a list of recommendations.  (Being a network engineer at LookingPoint I tend to use Cisco's recommendations.)  It should be noted that these guidelines are not standards; as such, modifications can be made to these recommendations as specific needs or constraints require.  Note that the Per-Hop Behavior is using the DSCP class of markings.

We will be referring to this chart a lot in this blog post as it not only has what the different types of applications should be classified as, but also the different queues those classifications should use.  We will talk about queues later in this post.

Marking and Trusts

Now that we all have a better understanding of DSCP and the priority structure, let’s use it.  As I said earlier, classification is the first step to providing priority between different types of data.  So how do we classify the traffic?  Well, the first way we classify traffic is to identify the applications traffic, using ACLs or though protocol matching.  In both cases we use a policy-map to match either the ACL or protocol, then call a class-map to set the DSCP value.  Then once the policy-map is in place we need to call it on each interface that we expect that traffic to be on.  This method is considered marking.

The second way we classify traffic is to simply let the application tell us what DSCP markings to use.  QoS aware applications will mark their traffic with a DSCP value and all we need to do is trust that value once the traffic arrives at our switch.  Going back to our constraint of voice and video, this is the method we would use as voice and video applications are QoS aware.  Which brings me to the next issue; not all switches behave the same way when it comes to trusting QoS markings.

Remember when I said we will talk about the differences between MQC and MLS QoS?  Well now is the time to talk about it.  In Cisco's world the older switches that have the IOS firmware use the MLS method of QoS, while the newer IOS-XE switches use MQC.  Cisco created an article that compare the operation of each type, go ahead and check it out here for more details but for our sake we will focus on two items from this list; QoS default, and Trust Configuration.

By default MLS QoS is disabled on all IOS switches.  The default behavior then would be to pass traffic and not modify any markings.  This works great in our case because the voice and video traffic is already marked, however if there were any bottlenecks leaving the uplinks of the switch then queuing will be done because QoS isn't enabled.  Once enabled then all ports automatically drop any DSCP and CoS values that are marked.  To trust those markings, we need to explicitly configure each switchport to trust DSCP and/or CoS values.  The most common way of doing so is to use the auto qos command set.  By enabling here.

By contrast MQC is enabled on all IOS-XE by default.  Additionally, all ports default to a trusted state.  This means that out of the box, all newer Cisco switches come ready to handle basic QoS operations.  Obviously if you need to modify or expand those QoS settings to include more than just standard voice and video traffic then you will need to configure MQC.  Here is a configuration guide for auto qos in MQC if you would like more details.

I think at this point I will stop here; this post is getting long enough, and I decided to split my original idea up into a three-part series. Look out for my next post that will cover the next steps after classification, Queuing and Policing.

As always if you have any questions on Quality of Service for you and your business and would like to schedule a free consultation with us, please reach out to us at sales@lookingpoint.com and we’ll be happy to help!