Bandwidth is infinite and we never need to worry about congestion, slowness, and packet drops, right? Of course, the answer to this is “no”. Networks transport many different kinds of data, and the different types may need to be handled in different ways to provide the best user experience during times of congestion. When I state “times of congestion”, I’m referring to periods of time in the network in which the amount of traffic is greater than the amount of available bandwidth. This is where Quality of Service (QoS) becomes very important. QoS consists of a modular framework of classifying traffic, creating a policy on how to handle the different traffic classes during congestion, then applying that policy to an interface. That policy can include marking classified packets, dropping certain types traffic while allowing others, queueing traffic until bandwidth is available, and setting aside amounts of bandwidth for different traffic classed during congestion. I think it’s important to note that the actual enforcement of the traffic policy only engages when there is congestion, or essentially, not enough bandwidth to server the current amount of traffic. In the rest of this post, we will take a deeper dive into the modular QoS approach.
Traffic Classification
In order to provide proper service and experience during congestion, to certain traffic types, you need to have a way to categorize, or classify, different traffic types. From a configuration standpoint, this is where class maps come in. Class maps provide you a way to match on certain traffic. You can then call on those class maps when creating policy (policy maps) in the next step. There are many different options for traffic classification at the different layers of the OSI model. Here is a high level look.
- Layer 1 – interface/subinterface or port selection.
- Layer 2 – MAC address, class of service (CoS) markings.
- Layer 3 – IP address, IP Precedence (IPP) markings, Differentiated Services Code Point (DSCP) markings.
- Layer 4 – TCP/UDP port.
- Layer 7 – Application recognition with deep packet inspection – Network Based Application Recognition (NBAR).
Policy Creation
Once you have the important traffic classified that needs to be handled certain ways during times of congestion, you now need to figure out what that specific handling is going to be. As stated earlier, this is where we can leverage policy maps in the configuration. At a high level, policy maps call upon the created class maps, then define policy to be enforced when needed. Here are some examples of policy actions.
- Traffic marking – Marking is used to apply a tag to packets. These tags signify specific classified traffic and can be used by other network devices to apply policy.
- Layer 2 – At Layer 2, these are called CoS markings and are made across 802.1Q trunk links.
- Layer 3 – At Layer 3, packets can be marked in the type of service (ToS) field in the header and can be the following.
- IP Precedence (IPP) – IPP is the legacy method which uses three bits of the type of service (ToS) field in the packet header. This allows for up to eight different markings and was designed to be a direct mapping of CoS markings at Layer 2.
- Differentiated Services Code Point (DSCP) – DSCP uses six bits of the type of service (ToS) and allows for up to sixty four different QoS markings.
- Policing – With policing, packets are dropped to conform to the set bandwidth limitation.
- Shaping – With shaping, packets are queued during congestion so that they can be held and sent as bandwidth becomes available. Shaping is typically done at the edge of the network when connecting to service providers. It is best to be done with TCP applications that are not sensitive to latency and jitter. UDP applications such as voice and video are sensitive to latency and jitter, so we want those packets to get through as soon as possible and not be queued.
Policy Application
Alright, so we’ve classified our traffic and created a QoS policy, now what? Now, the policy map must be applied to an interface so that it can be enforced. In Cisco IOS, this is referred to as the service policy and is applied to the interface in either an input or output direction.
Conclusion
One of the biggest things for me to remember around QoS is that the policy enforcement only needs to kick in during times of congestion. If there is always enough bandwidth, then packets never need to be policed or shaped. QoS is there to insure that the most important traffic is given preferential treatment during those heavy utilization times when there is not enough bandwidth to service all of the current traffic.
Netication 