Hello! Welcome to the final lesson in our Enterprise Network Architecture module.
In our last lesson, we focused on capacity planning—ensuring the network has enough resources to handle its workload. We learned how to baseline traffic, determine overprovisioning factors to meet performance SLAs, and plan for future growth.
However, simply having a large "pipe" isn't enough. When different applications compete for that bandwidth, how do we ensure a critical business video conference isn't disrupted by a large, non-urgent data backup? This is where Quality of Service (QoS) comes in.
This lesson directly addresses that challenge. Our goal is to describe the business need for Quality of Service (QoS) and compare different QoS models (Best Effort, IntServ, DiffServ). Understanding QoS is about aligning the network's behavior with business priorities, a crucial skill for any network architect or solutions engineer.
The Business Need for QoS: Why "Best Effort" Isn't Good Enough
By default, a network operates on a Best Effort basis. It treats all packets equally and forwards them in the order they arrive—a principle known as First-In, First-Out (FIFO). In a lightly used network, this works fine. But when the network experiences congestion, this "equal" treatment means every application suffers equally.
Imagine a modern enterprise network. It carries a diverse mix of traffic, each with different performance requirements.
For applications like email or file transfers, a small delay is usually unnoticeable. But for real-time applications, the impact is immediate and severe. The business need for QoS stems from the requirement to mitigate four key network impairments for these sensitive applications:
- Bandwidth (or Lack Thereof): Congestion occurs when a link's capacity is exceeded. Even on high-speed LANs, this is common at aggregation points or at the WAN edge, where a 10 Gbps LAN might feed into a 1 Gbps WAN link.
- Latency (Delay): The time it takes for a packet to travel from source to destination. High latency makes voice calls feel like a walkie-talkie and applications seem unresponsive.
- Jitter (Delay Variation): The variation in latency between packets in the same stream. High jitter is particularly damaging to voice and video, causing garbled audio and choppy video as the receiving end struggles to buffer and reassemble the stream smoothly.
- Packet Loss: When a router's queues are full during congestion, it has no choice but to drop incoming packets. For TCP-based applications, this triggers retransmissions. For real-time UDP-based applications like VoIP, that packet's data is lost forever.
To formalize these concepts, let's review a section from a Cisco NetAcad guide. It provides a clear breakdown of these four quality issues and their impact on applications.
Please read the section 'The Need for QoS' (slides 3-9). Focus on how each issue—lack of bandwidth, latency, jitter, and packet loss—directly impacts the user experience for voice and video.
In essence, QoS provides a set of tools to implement what one expert calls "managed unfairness." We intentionally treat traffic unfairly to protect the applications that are most important to the business.
The Architectural Models for QoS
Now that we understand why we need QoS, let's explore how it can be implemented. There are three main architectural models.
Mastering QoS Policy for CCNP ENCOR
This article from the AlphaPrep blog gives a concise, practical overview of the three QoS models. The table is particularly useful for a quick comparison.
Please read the sections 'Introduction to QoS' and 'QoS Architectural Models: Best Effort, IntServ, DiffServ'. Pay close attention to the table comparing the three models and the explanation of why DiffServ is the preferred choice for scalable networks.
Let's break down the models you just read about.
1. Best Effort
As we've discussed, this is the default model.
- Mechanism: First-In, First-Out (FIFO) queuing.
- Scalability: Very high (it's the simplest approach).
- Guarantees: None.
- Use Case: Suitable only for networks without congestion or where all traffic has the same low priority.
2. Integrated Services (IntServ)
IntServ is often called "hard QoS" because it provides strict guarantees.
- Mechanism: Applications use the Resource Reservation Protocol (RSVP) to request and reserve a specific amount of bandwidth along the entire path from source to destination.
- Scalability: Poor. Each router in the path must maintain state information for every individual reserved flow. In a large network with thousands of users and applications, this creates an enormous amount of state, consuming significant memory and CPU resources.
- Guarantees: Strong. If the reservation is successful, the application is guaranteed the requested bandwidth.
- Use Case: Due to its scalability issues, IntServ is rarely used in enterprise networks. You might see it in small, specialized environments like a dedicated video production network.
3. Differentiated Services (DiffServ)
DiffServ is the modern, scalable solution and the de facto standard for enterprise QoS.
- Mechanism: Instead of managing individual flows, DiffServ groups traffic into a small number of classes.
- Classification & Marking: Packets are classified (identified) and then "marked" (colored) with a value in the IP header, typically the Differentiated Services Code Point (DSCP) value. This marking happens once, as close to the source as possible.
- Per-Hop Behavior (PHB): At each subsequent router, the device simply looks at the DSCP marking and applies a pre-configured behavior (PHB) to that packet—such as placing it in a high-priority queue, a low-priority queue, or dropping it.
- Scalability: Excellent. Routers don't need to maintain state for individual flows. They only need to know how to treat a handful of traffic classes, making it highly efficient.
- Guarantees: "Soft QoS." It doesn't provide the absolute, end-to-end guarantees of IntServ, but it provides preferential treatment that is highly effective at protecting critical traffic.
To reinforce these concepts, let's watch a segment from a Kevin Wallace training video. He does an excellent job of explaining and contrasting these three models.
Please watch from 14:45 to 19:03. The presenter clearly differentiates IntServ (using RSVP), DiffServ, and Best Effort, highlighting their differences in strictness and efficiency.
A Closer Look at DiffServ Per-Hop Behaviors (PHBs)
Since DiffServ is the standard you will work with, it's worth briefly introducing the common behaviors (PHBs) that are applied based on a packet's DSCP marking.
| PHB Name | Typical DSCP | Description | Example Use |
|---|---|---|---|
| Expedited Forwarding (EF) | 46 (EF) | Provides the lowest loss, latency, and jitter. Meant for the most critical, delay-sensitive traffic. | VoIP (voice traffic) |
| Assured Forwarding (AF) | AFxy | Provides a guarantee of bandwidth with different levels of drop priority. | Video, critical data |
| Best Effort (BE) | 0 (CS0) | The default class. No special treatment. | Bulk transfer, browsing |
| Scavenger | 8 (CS1) | Less than Best Effort. This traffic is the first to be dropped during congestion. | P2P file sharing, gaming |
The key takeaway is that DiffServ enables a scalable QoS architecture by decoupling the complex task of identifying applications (classification) from the simple task of forwarding them based on a pre-assigned marking (PHB).
Test your understanding!
A large enterprise is deploying a new unified communications platform that heavily relies on VoIP and high-definition video conferencing across its global WAN. The WAN links frequently experience congestion during business hours due to large cloud backup jobs.
- Why is the default "Best Effort" model unsuitable for this deployment?
- An engineer initially proposes using the IntServ model with RSVP to provide hard guarantees for every voice and video call. What is the primary reason this is not a viable solution for a large enterprise?
- Explain how the DiffServ model would address this scenario in a scalable way.
Show answer
-
The Best Effort model is unsuitable because it treats all packets equally. During congestion, critical real-time voice and video packets would be delayed or dropped with the same probability as the non-urgent backup traffic, leading to poor call quality (jitter, loss, latency).
-
The primary reason IntServ is not viable is its lack of scalability. In a large enterprise, thousands of simultaneous calls would require every router in the path to create and maintain state for every single call via RSVP. This would overwhelm the routers' memory and CPU resources.
-
The DiffServ model solves this scalably.
- Classification/Marking: At the edge of the network, voice traffic would be classified and marked with DSCP EF (46), and video with an appropriate AF value (e.g., AF41). The backup traffic could be marked as Best Effort (CS0) or even Scavenger (CS1).
- Per-Hop Behavior: As these marked packets traverse the congested WAN, each router would simply read the DSCP value. It would place EF packets in a priority queue, give AF packets their assured bandwidth, and service the BE/CS1 packets with whatever bandwidth is left. The routers don't need to know about individual calls, only about how to treat the "EF" or "AF" classes, making it highly scalable.
Conclusion
In this lesson, we established the fundamental "why" and "what" of Quality of Service. We've seen that as networks carry more diverse and demanding applications, simply adding more bandwidth isn't always the answer. We need intelligent mechanisms to manage that bandwidth according to business priorities.
Key Takeaways:
- The business need for QoS arises from the requirement to protect performance-sensitive applications (like voice and video) from the negative effects of congestion: latency, jitter, and packet loss.
- Best Effort is the default "no QoS" model, treating all traffic equally and providing no guarantees.
- Integrated Services (IntServ) provides strong, end-to-end guarantees using RSVP but is not scalable for large networks due to its per-flow state requirement.
- Differentiated Services (DiffServ) is the industry standard. It offers a highly scalable solution by classifying traffic into classes, marking packets with a DSCP value, and applying a consistent Per-Hop Behavior (PHB) at each router.
Preview of the Next Lesson:
We have now completed the Enterprise Network Architecture module! We've covered design principles, high availability, capacity planning, and the foundational models of QoS.
Our next lesson will be the first in the "IP Services" module. We will move from high-level models to practical implementation and analyze the specific QoS mechanisms for classification, marking, queuing, policing, and shaping. This will build directly on the DiffServ model we discussed today, showing you the tools used to build a complete QoS policy.