QoS Marking: How, Where, and Why

One of the follow-up questions I received from my last QoS post was:

Where is traffic marked?  Example: voice traffic marked at the IP phone or VX900.  What about other traffic?  What other types of traffic should get a class?  How many classes should I have?

To fully answer this question, we are going to have to start with a basic understanding of what marking is and what the significance of “marking a packet” plays in the grand scheme of things.  When you mark a packet, you are setting a value in the TOS (Type of Service) byte, which is in the IP (Layer 3) header.  Because this is a 8 bit (1 byte) field, you WOULD have 256 different combinations, but QoS is not actually employed that way.  The marking process will use the first six high order bits in the ToS field.  This new value is referred to as DSCP (Differentiated Services Code Point) values, and because it is a six bit field, will provide you 64 different marking possibilities.  This post could get excessive if I get too deep into the DSCP markings.  Your best bet is to google “DSCP values”.  There will be plenty of charts and explanations, which will be much prettier and more coherent than I would be able to provide.

The graphic above shows a Wireshark capture.  I’ve highlighted the DSCP field, which in this case is the default (a DSCP of 0).

Technically, you can mark at Layer 2 as well, but there are several reasons why it doesn’t make sense to do so.  First, there is no QoS related field in the frame header.  The 802.1Q “shim” has a 3 bit field for QoS, but that shim will only be applied to trunk ports (google 802.1P for more on this).  In addition to only existing on trunk ports, any value written will lose significance as soon as soon as you hit a Layer 3 device (the same way VLANs lose significance when you hit a Layer 3 device).  Lastly, in nearly all of our environments LAN congestion is not significant enough to warrant this level of configuration complexity.

Before we go into where you should mark, we need to go into how we can use the QoS marking.  If you refer back to the “QoS Demystified” post, you will discover the first step in QoS is classification.  One of the ways you an classify traffic is by the DSCP value.  Probably the most common misconception is: “this packet is marked EF (or insert other value here), therefore it will be given (insert mythical priority here)”.  Your marking does not have any intrinsic value, nor does it guarantee anything.  The marking allows whoever controls the router to easily classify traffic, what you do from there is your choice.  This concept is known as PHB (Per Hop Behavior).  It is recommended that you stay within the recommendations for DSCP marking, such as marking voice bearer traffic as EF (Expedited Forwarding), so a level of consistency can be maintained (but that would of course require everyone to be on the same page for marking AND prioritization).  Ask your friendly neighborhood Data Officer for the “QoS recommendations in a tactical environment” document for a good baseline.

So now that we know how you are able to mark and what it means, where should we mark?  Like a lot of questions in networking, the answer is that it depends.  The textbook definition is going to tell you to mark closest to the endpoint.  This allows for your core devices to concentrate on other tasks without needing to worry about re-writing.  I try to abide by this recommendation, but practical application makes it difficult to follow the recommendation.  As I have written in other posts, I strongly recommend you do not recommend you do QoS on your switches.  I can name a half a dozen instances where we’ve had a variety of issues and “no mls qos” fixed all that ailed us.  If you are really good with switch QoS and you’ve got an environment that is relatively stable (from a change standpoint), it could make sense to use switch QoS.  I would still caution you that whoever is coming out to relieve you is likely not familiar with this and it will just lead to issues after you are gone.  I’ve never altered the markings of Cisco IP phones, I let the phones mark their packets, and leave them be.  So that leaves the unique situations.  I like the MQC style of QoS, and  I’ll normally implement this on a centralized router on an internal interface.  This allows you to do your marking separate from other QoS features (like shaping or Low Latency Queuing).  Here is an example of what that would look like:

The last thing we need to address is how many classes of traffic you should have.  This is a really difficult question to answer because it varies so wildly based on how you will implement your QoS and what your mission requirements are.  What I like to do is baseline off of a PQ (Priority Queue) and four other classes (including the default class).  From there, I make adjustments where necessary.  With QoS, you can over-engineer, so only create what you deem as absolutely necessary.  Regularly check your Policy Maps and pay particular attention to how frequently you are dropping packets from each queue.  Most of the time I have had problems, there has been some issue that prevented proper classification, which in turn sent those packets to the default class instead of a class with specifically tailored bandwidth allocations.