QoS (Quality of Service) Fundamentals for the CCNA

As complex has a network might be, it has a simple purpose. Networks must deliver data from point A to point B, as simple as that. However, this requires performing devices and connections with good bandwidth. When the bandwidth runs out, and the link is full, something goes lost. Quality of Service – QoS – allows you to decide what data to prefer so that routers will drop only traffic we can accept to lose. Implementing QoS is a complex task, and you don’t have to do it for the CCNA. However, we still need to get the basics of it, both for the certification and our real-life job.

Introducing Quality of Service (QoS)

If you send on a network an amount of data that it can handle, everything goes smoothly. In fact, if your network is capable of a 100Mbps throughput, but you are only using 20Mbps, you will enjoy a perfect experience. If there are no interferences, routers don’t drop any packet, and everything reaches its destination. In this kind of environment, you don’t need Quality of Service. Instead, QoS makes sense when congestion happens. If you are trying to send more data than the link can handle, like 120Mbps against the 100Mbps capacity, something won’t pass.

Quality of Service allows you to define what is the treatment a specific packet will have during congestions. You can define which packets the router can drop, which should be stored and sent later, and which must be sent now.

Packet Marking Basics

Okay, the concept is very simple: during congestion, we can take different actions on different packets. However, we need to define a way for the router to identify packets that should have different treatments. If we don’t tell the router the priority level of each packet, it won’t know what to do with them.

To do that, we need to mark each IP packet with a priority. Luckily, the header of the IP packet contains 8 bits that we can use to specify the priority: the Type of Service (ToS) field. This field (which you can read about in the article just linked), contains two sub-fields: DSCP and ECN. The first 6 bits are the Differentiated Serviced Code Point (DSCP), the true priority of the packet. The last two bits refer to the Explicit Congestion Notification (ECN), and we use them to tell other devices that we have a congestion

Since we mark each packet with a DSCP value, the routers will know how to deal with it.

In this example, we have three packets coming. The first to enter the router (on the right) as a middle-tier priority of four. Then, we have a packet top priority, and a low priority on the left. In case of congestion, the middle packet is the most likely to be dropped is the red one.

Explaining DSCP Values

Now that we know each packet comes with a priority, a good question could be what these priorities are exactly. Since we have 6 bits to play with inside the DSCP field, we can have up to 64 combinations (2⁶=64). We can group priorities in three macro-categories: Best-Effort, Assured Forwarding, and Expedited Forwarding.

Best-Effort is the default behavior, and means “no QoS”. Routers will drop these packet as soon as a congestion happens: they forward them only if they have resources to do it.

Assured Forwarding (AF) is somehow tricky. This categorization defines that the network will assure delivery unless traffic exceeds a specific rate. The more the traffic exceeds that rate, the more the router will be inclined to drop it during congestions. However, during non-congestion periods, the traffic can easily exceed the rate. Now, you can’t just mark a packet as “AF”. Instead, you need to specify a class and an intra-class priority. So, we mark packets with AFXY, where X is the class number and Y is the intra-class number. The value of X ranges from 1 to 4 (included). Instead, Y can be 1 (low drop probability), 2 (medium drop probability), and 3 (high drop probability).

We use the class to prioritize some AF traffic over some other, and the drop probability to prioritize traffic within the same class.

Finally, we have the Expedited Forwarding (EF). This is basically the best class: low delay, low jitter. We often see that for VoIP and Video, because it allows the fast transfer.

The DSCP Table

For convenience, here we have a table of the most used DSCP values. Have a look at it to understand how QoS works.

Device Trust

At this point, we know each packet comes with a QoS marking. The value in this field is not automatic, some device has to put it there. In fact, devices can perform QoS packet marking. This means that the device generating the traffic can send it out with a QoS mark, but also that intermediary devices can change their value.

Since QoS allows you to define which traffic has which priority, we need to control who can apply QoS. The devices that we allow to set/change the DSCP value are part of a device trust domain. In the example above, all the cables with a green underlay represent such a domain. In a good network, we don’t want to trust the user’s PC. Instead, we want to trust IP phones, or better yet access switches.

Cisco switches and routers can set the DSCP value of a packet, or override it. You can define rules that set a specific value based on source and destination IP addresses, ports, and protocols. This way, you can configure your network to put your critical applications in a priority class, and VoIP in the EF class.

QoS Actions

Now that we know how and when we can mark packets, we need to cover the other parts of QoS. As soon as the congestion happens, routers can take different actions based on the marking. In this section, we will cover these actions.

QoS is only outgoing

Before starting with the explanation of different actions, we need to introduce the interface buffer. Each interface has two buffers: incoming and outgoing. These are portions of memory where we store packets waiting to be processed. Specifically, in the incoming buffer, you will find packets the router received and that are waiting to be processed. Instead, in the outgoing buffer, you will see packets that were processed and that are waiting for the link availability to be sent out.

If the outgoing buffer is full, it means the router is going faster than the link can handle. If the incoming buffer is full, it is the link to the one going faster.

Since the router has not processed the packets in the incoming buffer, we can’t apply QoS on them. We haven’t read them and therefore we don’t know their priority just yet. Instead, we can apply QoS rules on the outgoing buffer, before placing packets right here.

So, we can tell a packet to skip the buffer and go immediately on the link, and to some others to wait in the buffer a little bit longer.

Policing and Shaping

We have two major approaches for QoS: Policing and Shaping. Of course, they both act on the traffic exceeding the limit.

Policing is the simplest approach: the router will drop any traffic exceeding the limit. The result is a graph with a cap on the limit, and traffic that never exceeds it.

Shaping, instead, is a different approach that leverages queuing (buffers). As the name might suggest, it aims to change the shape of the traffic graph. In fact, the router stores traffic exceeding the limit in the buffer, and as soon as the traffic returns in the normal range, it starts sending the traffic stored. The result for that is that traffic isn’t dropped, but just delayed. Of course, if the excess is too big, the router will drop some traffic anyway. Note in the chart below (for shaping), that traffic reduces slowly after touching the limit. This is because the stored traffic is being sent.

You might think that shaping is the best approach in any case, but it isn’t. Buffer aren’t infinite, they have a very specific size. Since shaping leverages those buffers, you should queue only traffic that can benefit from that. For example, VoIP is delay-sensitive, and a delayed packet will be unusable just like a dropped one. So, just police VoIP and Video traffic.

QoS Tips

Below, some concepts that you might want to know about QoS.

• QoS is a bit-bucket mechanism. Imagine a water bucket filled with traffic instead of water. QoS is triggered only when the traffic goes outside the bucket. Of course, this a simple approach of a much wider concept.
• QoS supports bursts, this means that it can bend its rules if traffic exceeding the limit quickly returns back into the allowed range. You can tune these rules, effectively customizing the approach to bursts.
• Since Quality of Service starts to work during congestions, you want to use it on limited-bandwidth networks. Designing and implementing QoS requires time. Because of that, you shouldn’t waste time implementing such technology in a high-speed LAN. Instead, focus on optimizing a limited-bandwidth private WAN link.

With these concepts in mind, you can define a better approach to QoS.

Conclusion

Quality of Service is an awesome mechanism that allows a better use of WAN links. With it, you can fine-tune how to deal with your traffic during congestion periods. Below a recap of what we have learnt today.

• QoS starts to work only during congestion periods, so it decides what to drop and what to keep. When the link isn’t full, there’s no need for QoS.
• Quality of Service takes its decisions based on a field in the IP packet (DSCP), that indicates the priority of the packet.
• You should have switches and routers set the DSCP value, based on source and/or destination IP addresses, ports, and protocols.
• We can group DSCP values in three major branches: Expedited Forwarding (EF) for low-delay, Assured Forwarding (AF) for delayable but critical traffic, and Best Effort for no QoS. The device that sets the QoS is part of the device’s trust.
• Quality of Service leverage outgoing buffers to prioritize traffic.
• With policing, routers will just drop exceeding traffic.
• With shaping, routers will store for delayed forward the exceeding traffic.

With this knowledge, you are ready to discuss some cutting-edge technologies for your network, like cloud and network programmability. But that’s for another article, continue following the CCNA course!