QoS: The 1998 Technology That’s Suddenly Cool Again(Thanks, AI)
TL;DR
- Quality of Service has been around for a while. It’s great but takes a bit of understanding
- AI is pushing the boundaries of speed. We’re at 800G to the host now and moving rapidly towards 1.6T
- Class of Service (Cos) operates at layer 2 and is only useful at that layer
- Differentiated Services Code Point (DSCP) operates at layer 3 and allows a more granular approach to QoS
A Brief History
Technically Quality of Service predates 1998, being around since 1981 with RFC791 and Type of Service (ToS), the framework we are all (hopefully) familiar with today really came about in late 1998 with RFC 2474 and RFC 2475. Around that time the introduction of latency sensitive applications like Voice over IP (VoIP) and early video conferencing solutions presented a challenge: not all network packets are created equally. When these applications were thrust into our day to day infrastructure we needed a way to solve for precedence. As an example, a delayed email is a minor inconvenience but a delay or drop of a voice packet means the difference in understanding the conversation vs just saying “sorry, you cut out a little there.”
For years we solved this problem a number of ways but, if we’re honest with ourselves, the most common was throwing more bandwidth at the problem. To me personally, it felt as though the need to have a thorough understanding of QoS, and all of its bag of tricks, fell to the wayside. And then…AlexNet has to come along and change everything.
(As an aside, look, I get it, QoS and congestion control mechanisms have been critical in tons of other workloads like storage, media and entertainment, HFT, and the list goes on and on. Basically anywhere where we have high priority traffic, QoS has been important for years but AI presents a good opportunity to return to the basics. Back to the program.)
Now we have hyperscalers racing to the largest clusters they can build and what moves to the forefront again…prioritizing traffic. So throw bandwidth at the problem, right? Well what happens when the data outpaces the bandwidth capability? This is where we find ourselves today but I digress. How can you, the reader, take something away from this? Simple, understand the fundamentals.
The Fundamentals
At the heart of a QoS implementation lies two critical concepts: Class of Service (CoS) and Differentiated Services Code Point (DSCP). While these two terms are sometimes used interchangeably, they each play a crucial, complementary role in network traffic prioritization, operating at different layers of the network stack.
Class of Service (CoS) operates at Layer 2 of the OSI model, embedded within the 802.1Q VLAN header. CoS uses a 3-bit field, giving us eight different priority levels (0-7), which helps boost switching efficiency on a LAN. As expected, or maybe sometimes not in networking, the higher CoS value, the higher the preference when traversing switches. The important thing to note with CoS is that these markings only persist within a L2 domain. Once a packet is routed, we need another mechanism to ensure the traffic is prioritized appropriately, which is where, you guessed it, DSCP comes in.
Differentiated Services Code Point (DSCP), in contrast to CoS, operates at Layer 3 within the IP header. DSCP uses a 6-bit field, allowing for 64 distinct classification values. This granularity enables far more sophisticated traffic differentiation strategies. Network devices can examine DSCP markings and apply corresponding per-hop behaviors, determining how packets are queued, scheduled, and potentially dropped during congestion.
Common DSCP values follow standardized patterns. Expedited Forwarding (EF, DSCP 46) provides low-latency, low-jitter service for voice traffic. Assured Forwarding classes (AF1x through AF4x) offer differing levels of priority with varying drop precedences. The default best-effort traffic (as seen below from my home network) uses DSCP 0. This allows interoperability between vendors when implementing QoS policies…you know standards.

The relationship between these two involves mapping. As a packet enters the network, the edge devices can mark traffic based on application type and/or other criteria and the process goes on from there. When implemented correctly this ensures that all of that sweet, sweet latency sensitive traffic gets through without disruption.
Often network switches will allow you to do all kinds of fun things when it comes to mapping. You can rewrite or remap as needed but at least now you should understand how QoS is used in networks today. If you’re interested in learning more about the DSCP mappings, check out this helpful guide from IANA or the aforementioned RFC 2474.
Closing
If you’ve made it this far, I appreciate it and I hope you found this content helpful. If so, I may do additional articles all around congestion control but until that time have a great day!
P.S. For the keen eyed observer, don’t mind the VLAN ID of 1 in that PCAP, I definitely wouldn’t just run things in VLAN 1 on my home network 😁.