QoS Tools Overview and QoS Models (Part 2)
In this article we will look at the main tools for QoS, and examine IntServ and DiffServ. QoS tools are used to preform QoS functions such as marking packets, classifying packets, queuing packets, etc.
Classification and Marking
Classification is the process of examining some aspect of a packet and categorizing it into a single class. By defining multiple classes, you can treat each class differently in regards to QoS. You can classify traffic based on layer 3/layer 4 information, or even preform deeper application recognition to classify traffic based on application data. You can also classify traffic based on markings in the packet such as the DSCP value, and MPLS EXP value. Classification is the process of differentiating traffic into administratively defined groups for the purpose of treating each group differently.
Marking is the process of changing a field in the packet’s header in order for network devices upstream to more easily classify the traffic. For example, a device might classify traffic based on SIP characteristics, and then mark the IP header’s DSCP value with EF. Or it may detect torrent traffic and mark it with DSCP CS1 which is scavenger class.
An example will help solidfy this concept. In this simple topology I will ping from R1 to R3, and mark the ping packet on R2.
On R2 I simply create a policy-map that matches the class-default, which is any traffic. Packets matching this class will have the DSCP value set to CS4. (More on DSCP at the end of this article).
The ping leaves R1 with no marking:
When it arrives ingress at R2, the router marks the DS field with CS4 and sends it towards R3:
You can see from the matching IPv4 ID of 35 (0x0023) that both packets are the same packets.
For reference, if I set the IP Precedence a value of 4 it will have the same result: a DSCP value of CS4. This is because the ToS byte is depreciated and DSCP is backwards compatible with IPP. Much more on this at the end of the article when we look at DiffServ.
Besides IPP and DSCP, you can mark the CoS, MPLS Exp value and QoS group. CoS is present on an 802.1Q frame and is three bits just like IPP. We will explore MPLS Exp and QoS groups much later in this series when looking at QoS for MPLS.
Queuing
Queuing tools are used to reorder packets to give preferential treatment to one queue over the other. Queuing almost always refers to output queuing on an interface. There is not usually a reason to preform input queuing on an interface, because once the traffic is received at an interface you should just switch it immediately to the output interface. You can then do output queuing on the egress interface.
Classification is used to place packets into separate queues. Depending on the queuing tool, there are different algorithms for what order to empty queues in. There is low latency queuing (LLQ) and priority queuing (PQ) in which a single queue, such as for VoIP, has priority and is emptied before other queues. There is also WFQ (weighted fair queuing) and CBWFQ (class-based WFQ). We will look at these in more detail in a future article in this series.
Queuing is what allows high priority traffic to “cut ahead” in line and be transmitted on the wire before a lower priority packet that arrived before it. Queuing is frequently used for voice traffic to reduce queuing delay that would result in poor jitter.
Shaping
Traffic shaping delays packets by placing them in an output queue and withdrawing packets at a rate that is slower than the line rate. You can generally only shape traffic outbound on most network device platforms. You will often shape packets outbound on a customer WAN interface that has a CIR less than the line rate. Without shaping, the service provider would drop any traffic that exceeds the CIR, possibly even if it is only a short burst. By shaping the traffic, you can control the rate at which it is sent, smoothing out bursts of traffic. Shaping introduces queuing latency to any excess traffic, but at the alternative of it dropping.
Shaping is generally required when there is a speed mismatch between the rate at which traffic is arriving on an ingress interface, and the rate at which that traffic is sent out the egress interface. Imagine a router that has two interfaces, one towards a LAN switch operating at line rate of 1Gbps, and one WAN interface that is 1Gbps but has a CIR of 500Mbps. Even if traffic never averages close to 500Mbps, you can still have short bursts that happen from the LAN at 1Gbps. Therefore when a speed mismatch exists, you should shape on the slower output interface so that traffic does not get discarded.
Because traffic shaping can hold excess traffic in a queue, it smoothes out traffic like this:
Traffic exceeding the configure rate is held in a queue and transmitted when there is bandwidth available
Policing
Policers are generally applied inbound on an interface to enfore a CIR. The same service provider which is providing the example 500Mbps service would apply a policer inbound on the interface facing the customer equipment so that any traffic over 500Mbps is discarded.
The difference between shaping and policing is that shaping smooths out traffic that exceeds the CIR. It holds excess traffic in a queue and transmits it when there is bandwidth available. Policing simply discards any traffic exceeding the CIR. (It is a little more complex than this due to the token bucket system and bursting tolerance, but for now we will use this simple defintion).
If the customer did not shape their traffic, the excess traffic would simply get dropped by the provider, like this:
In policing, any excess traffic is simply discarded, resulting in packet loss.
Congestion Avoidance
While shaping does help reduce the likleihood of packet loss, queues only have a finite amount of space. When a queue is filled, the router simply has to start dropping traffic. This is called tail drop, because packets arriving at the tail end of the queue are dropped. The problem with this, is that when traffic congestion occurs, lots of packet loss might happen at once, causing TCP streams to slide their window down agressively. This reduces congestion dramatically, and the TCP streams all start increasing their window as they no longer experience packet loss. The streams all may hit congestion again, and the cycle of sliding the window down repeats. This process is called TCP global synchronization because the separate TCP streams are producing a synchronized behavior in which they all slide their windows up and down together. See this youtube video for an explanation: https://www.youtube.com/watch?v=64yrWsQFIek&ab_channel=Net4LifeTeam
To avoid this problem, we can randomly drop traffic before getting to the point of complete congestion. We could start dropping some traffic at 80% congestion for example. This seems counter-intuitive, but it will result in better utilization of bandwidth because we will avoid the global synchronization problem.
WRED (Weight Random Early Detection) is a congestion avoidance tool that drops traffic in certain classes based on weight. You can prefer to drop data traffic more often than voice traffic, for example.
IntServ (Integrated Services)
IntServ (Integrated Services) predates DiffServ, which is the model used in today’s networks. IntServ is an end-to-end resource reservation protocol. When a host wants to start a flow, it first reserves the resources in the network using RSVP. This lets an application define the bandwidth and delay requirements that it needs.
IntServ also defines admission control which prevents too many requests from being accepted. If enough flows reserve all available bandwidth, the routers need to eventually start rejecting new flows because they cannot gaurantee bandwidth any longer.
As you can imagine, this does not scale well. RSVP requires state in the network - not only when a resource reservation is created, but this state needs to be constantly refreshed. Additionally, IntServ can result in unused bandwidth, because an application may greedily reserve more bandwidth than it actually uses.
Even though IntServ did not take off, RSVP was extended for use as RSVP-TE where it has had much success.
DiffServ (Differentiated Services)
DiffServ (Differentiated Services) was a solution to the poor scalability of IntServ. The idea behind DiffServ is that each router makes a separate QoS forwarding decision based off markings of the packet. This means that an end-to-end signalling protocol is not needed, because each router independently decides how to implement QoS functions. This is called PHB (per-hop behavior), because every single hop preforms its own QoS behavior.
Because of PHB, a single router in a flow can break QoS. If a single router does not apply the correct QoS treatment, the entire end-to-end flow quality may suffer.
While IntServ offers a gaurantee of bandwidth and delay for a flow, DiffServ is essentially best effort from the point of view of the application. A phone can mark packets for EF (Expediated Forwarding), but there are no gaurantees that the traffic will experience any preferential treatment. Each network device in the path of the flow needs to be configured to give special treatment to the traffic based on its marking in order for DiffServ to work.
However, DiffServ does not need to be concerned with each individual flow as with IntServ. Instead DiffServ can generalize traffic into groups of classes and treat all traffic in the same class identically. This is why DiffServ is scalable.
Differentiation refers to classifying traffic into different classes or queues based on some aspect of the traffic. For example, you can differentiate traffic based on layer 3/layer 4 information, CoS marking, DSCP marking, etc. Each class of service can be treated differently in regards to QoS forwarding behavior. This is entire concept is just classification as we covered at the beginning of this article.
DiffServ also redefined the ToS byte in the IP header. The ToS byte was the second byte in the IP header, behind the version and header length fields. The ToS byte defined the most significant bits for IP Precedence, and the remaining bits for type of service, such as low delay, or reliability:
DiffServ replaces this byte with the DS (Differentiated Services) Field, which you can find in any IP header today:
The DS field uses the most significant six bits for the DSCP (Different Services Codepoint) and least significant two bits for ECN (Explicity Congestion Notification). We will only focus on DSCP for now, and not ECN.
In order to stay backward compatible with routers that did not understand the new DS field, the first three bits of the DSCP are backwards compatible with IP Precendence (IPP). The DSCP values that map directly to IPP values are called Class Selectors (CS). CS0 through CS7 maps directly to IPP0 through IPP7.
IPP Binary | IPP Decimal Value | DSCP Name | DSCP Binary | DSCP Decimal Value |
000 | 0 | CS0 | 000000 | 0 |
001 | 1 | CS1 | 001000 | 8 |
010 | 2 | CS2 | 010000 | 16 |
011 | 3 | CS3 | 011000 | 24 |
100 | 4 | CS4 | 100000 | 32 |
101 | 5 | CS5 | 101000 | 40 |
110 | 6 | CS6 | 110000 | 48 |
111 | 7 | CS7 | 111000 | 56 |
As you can see, the DSCP value is just the IPP with three 0s in the remaining bits. A lower IPP/CS value indicates worse treatment, and a higher IPP/CS value indicates highest priority treatement.
Two out of the remaining three bits are used with CS1 through CS4 to indicate drop probability. This is called AF (Assured Forwarding). A higher value in the least significant (right-most) three bits indicates higher probability that the traffic will be dropped. The idea is that you would have four queues, one per class selectors CS1-CS4. Within each queue, when congestion happens, packets with the highest drop probability will be dropped first. When using AF, the drop probabilities are 1-3. So packets with AFx3 are dropped first, then AFx2, then AFx1.
| Class | Low drop probability | Medium drop probability | High drop probability |
|---|---|---|---|
Class 1 | AF11 | AF12 | AF13 |
Class 2 | AF21 | AF22 | AF23 |
Class 3 | AF31 | AF32 | AF33 |
Class 4 | AF41 | AF42 | AF43 |
What can be confusing about AF is that a higher value may indicate worse treatement. For example, AF33 receives worse treatment than AF31, because AF33 traffic will be dropped first when congestion occurs within the CS3 queue.
Below is the binary value and decimal value of each AF value:
AF Value | Binary Value | Decimal Value |
AF11 | 001010 | 10 |
AF12 | 001100 | 12 |
AF13 | 001110 | 14 |
AF21 | 010010 | 18 |
AF22 | 010100 | 20 |
AF23 | 010110 | 22 |
AF31 | 011010 | 26 |
AF32 | 011100 | 28 |
AF33 | 011110 | 30 |
AF41 | 100010 | 34 |
AF42 | 100100 | 36 |
AF43 | 100110 | 38 |
You generally don’t need to really worry about the decimal value. Within IOS you can refer to each traffic class as “IPP 3” or “AF 23” or “CS 2”, etc. Also note that the AF values are still roughly backwards compatible with IPP. If a router only understood IPP, then it simply wouldn’t be able to follow the drop probability in the next three bits. However these days you would be hard pressed to find a device that does not understand the DSCP field. Backwards compatibility was more important when DSCP was first standardized.
Finally there is the EF (expedited forwarding) value that DSCP defines. This is decimal 46 and is represented in binary as 101110. EF is not part of the AF values, so the least significant three bits have nothing to do with drop probability. Instead, EF is meant to indicate low latency and low bandwidth. The idea is that the EF queue should always be served immediately to reduce jitter, but also have low bandwidth so that it cannot starve out other queues.
In upcoming articles we will examine these tools more closely and learn how to configure QoS on Cisco routers.
Further Reading
Cisco QoS Exam Guide, Wendell Odom and Michael Vacanaugh, Ch. 2
Last updated
