Many of you reading this have been mystifyed by terms like WFQ, WRED, Jitter, or DiffServ. My aim in Part I of QoS: Essentials, is to take some of the mystique surrounding Quality of Service away. Let’s get to it!

What is QoS?
While in Iraq, we stayed in tiny trailers with 2 soldiers sharing a room. It wasn’t horrible, but let’s just say you got to know your roommate a little bit more then you wanted to due to the close proximity. Two people was OK, compared to what some people had to do! Our commander was given his own trailer, because well, he was more important then the “foot soldiers” or “average joes”. If something happened to most people in my unit, the position can be filled. If something happens to the commander, it’s not quite as easy. Moving on, the commander receives his own room, thus putting a soldier out, and forcing him to move in with two guys already occupying a trailer. Their beds were nearly touching…for 15 months. What happened? QoS…sort of. Here’s what cisco has to say about QoS:

“QoS is the ability of the network to provide better or special service to a set of users or applications or both to the detriment of other users or applications or both.“

Based on that statement, we can agree that Quality of Service is essentially improving service for one service, while limiting the service of other users/applications. Think about it, you run a network with 1,000+ systems, and run a special application we’ll call AppX that the companies employee’s practically live on. You also have employee’s who are running P2P file transfer programs such as Gnutella, Kazaa, or Limewire. Without a QoS policy in place, heavy P2P use will prove to be detrimental to AppX, and thus decrease company productivity, resulting in less earnings, and ultimately hurt everyone! In the above scenario, using QoS, it would be completely possible to limit the P2P users to only using a percentage of the available bandwidth, and simultaneously guarantee a percentage of bandwidth to AppX..even in times of network congestion. Pretty outstanding!

Before we get into the options QoS provides you with, we must first understand the basic QoS models available to you as the network engineer.

• Best Effort: No QoS policy is implemented. All packets receive the same level of service.

• Integrated Services Model (IntServ): the first real end-to-end QoS solution. IntServ is based on a per-flow basis, where a “flow” is defined as a stream of packets with a common source, destination, and port number. Does not scale well, as each router using IntServ is required to maintain per flow state information.

• Differentiated Services (DiffServ): Not a guaranteed service model. Flows are combined into “classes”, and are treated on a per class basis. DiffServ is very scalable, and flexible. Packet classification, marking, and conditioning is done at the edge, where the core handles QoS on a Per-Hop Behavior (PHB) based on the packet’s class. DiffServ is highly scalable

QoS: Steps to implementation

There are three broad steps required to implement QoS. While the methods of implementation vary, the idea behind each is the same. They are as follows:

1. Identify traffic types and requirements

The first step consists of evaluating business requirements, and the applications/services currently in use on the network- then determining the requirements of each one. The idea behind this step is to later place apps/services with similar requirements into the same class, and then apply policies to each class. For example, if you have VoIP traffic, and have several other important, but not critical applications, you would give priority to the VoIP traffic (therefore getting it’s own class), and give the lower-priority traffic it’s own class.

2. Classifying traffic based on the requirements

Classifying traffic is essentially taking a group of applications and placing them into several classes. Marking is also usually done after classifying. Why should you mark? If you don’t, each device in your network that handles QoS will have to perform a deep-packet inspection along each hop. If you mark at the edge, each device that sees that marking (or “color”) after that will know what treatment it should receive already. Classification can be based on the incoming interface, Class of Service (CoS, Layer 2 marking) value, source or destination IP address, IP Precedence/DSCP value, MPLS EXP, or by the application type.

3. Define Policies for each class

Now that you’ve identified business/network requirements, we’ve classified and marked (you did mark your traffic, didn’t you?) our traffic..we must do something with all of it! This is where the action happens. This is where you can set a maximum/minimum bandwidth for a class to use, define a priority, or apply congestion management/avoidance (in other words, how to act when there is congestion present..which traffic should be dropped first, etc).

Trust Boundaries

So you know the steps to implementing QoS, and classifying/marking..but where do we start? The point at which traffic is marked in our network is defined as the “trust boundary”, or where the QoS markings are “trusted”. You should always try to mark closest to the source if possible. A common scenario I hear is network admins installing Cisco VoIP phones, with a PC connected to the 3-port switch on the phone. Most Cisco phones will provide a CoS (Layer 2 marking)/IP Precedence (Layer 3 marking) of 5 by default. If you “trust” the incoming values at the access switch, your trust boundary is at the IP phone/access switch.  This is ideal. This type of configuration ensures that all of your core/distribution nodes do nothing more then quickly read the markings, and act on the necessary policy for that class instead of deep packet inspection. In the diagram below, we see three different possibilities for trust boundaries:

A) In this scenario, the IP phone marks it’s own traffic. This is ideal, however not all IP phones can mark.

B) This option is still good, and is a pretty common place to mark- at the access layer. This is generally where you would mark if you just had a regular PC attached, or a phone not capable of marking it’s own traffic.

C) This one is OK. Generally the congestion in networks occur at the WAN links, so as long as you mark before it hits the WAN link, you should still be OK. This is why you generally want to mark as close to the source as possible.

Although this has not been a complete overview of QoS, I hope it’s cleared some things up for those new to QoS. In Part II we’ll discuss QoS policy, Congestion avoidance/management, and Queueing.