In this sample chapter from Designing for Cisco Network Service Architectures (ARCH) Foundation Learning Guide: CCDP ARCH 300-320, 4th Edition, the authors cover some best practice QoS design principles and QoS strategy models that are used to implement the numerous QoS tools we have at our disposal. Remember that usually, more than one solution fits the given QoS requirements, so simplifying the models leveraged can significantly accelerate and ensure proper QoS deployment.
Upon completing this chapter, you will be able to
Describe basic classification and marking design principles
Describe basic policing and remarking design principles
Explain queuing design principles
Explain basic dropping design principles
Explain what are per-hop behavior queue design principles
Explain the role of RFC 4594 recommendation
List and describe QoS strategy models
Describe the 4-class QoS strategy model
Describe the 8-class QoS strategy model
Describe the 12-class QoS strategy model
Now that we have covered the various tools for enabling quality of service (QoS) in the network, it is possible to create a QoS strategy that best meets an organization’s requirements. This chapter presents some best practice QoS design principles and QoS strategy models that are used to implement the numerous QoS tools we have at our disposal. Remember that usually more than one solution fits the given QoS requirements, so simplifying the models leveraged can significantly accelerate and ensure proper QoS deployment.
QoS Overview
Quality of service is critical to ensuring application performance consistency and optimized end-user experiences. As discussed in Chapter 15, “QoS Overview,” the fundamental purpose of QoS is to manage contention for network resources while addressing applications that require differentiated levels of service. Prior to developing a QoS strategy, you must perform the proper discovery to identify current and future applications and application characteristics within the environment. This information, coupled with an understanding of the end-to-end network design and traffic patterns, will drive the QoS design strategy model that is most appropriate for the business. Following are some common questions that you need to answer:
What traffic needs to be classified and marked?
Is it possible to leverage a 4-class, 8-class, or 12-class QoS strategy model from end to end?
Will traffic-marking characteristics stay in place as data traverses the infrastructure?
What traffic needs to be prioritized?
What traffic requires bandwidth reservations?
What traffic needs to be policed?
Is shaping required at the WAN edge or at other places within the infrastructure such as the Data Center Interconnect (DCI)?
How can congestion management and congestion avoidance techniques be leveraged to optimize TCP traffic?
Classification and Marking Design Principles
The first fundamental design principle is that QoS policies should always be enabled in hardware whenever possible. Some Cisco routers perform QoS in software, and such behavior can increase the load on the CPU. Cisco Catalyst switches have dedicated hardware called application-specific integrated circuits (ASIC), which are used to perform QoS operations. Switches can perform complex QoS policies under maximum traffic load without any marginal CPU spike. Some platforms, such as the Cisco ASR, can perform QoS operations (such as queuing) in dedicated hardware ASICs, but other functions (such as deep packet inspection) are still processed in software via the CPU.
Based on design recommendations, classification and marking should be done closest to the source of traffic as administratively and technically possible. This design principle promotes DiffServ and per-hop behaviors (PHB) as the recommended end-to-end design.
As a rule, it is not recommended to trust markings set by end users leveraging PCs or other endpoint devices. End users can intentionally or unintentionally abuse QoS policies that trust markings of end devices. If users and unclassified applications take advantage of the configured QoS policy as a result of trusting end devices, this can result in easily starving priority queues with nonpriority traffic, ruining quality of service for real-time applications. However, if QoS markings for end devices and associated applications are administered centrally across the enterprise, this can be an acceptable design option. An additional area of exception might also include wireless devices that can leverage Wireless Multimedia (WMM) QoS provisioning in the upstream direction.
The next important recommendation is to use Differentiated Services Code Point (DSCP) marking whenever technically possible. DSCP markings are the recommended method for marking IP traffic for the following reasons:
It has support for end-to-end Layer 3 marking.
It is a more granular method of marking that supports 64 levels as compared to class of service (CoS) and MPLS Experimental EXP, which have 8 levels.
It is more extensible than Layer 2 markings as these markings are lost when media changes.
To provide interoperability on the border between enterprise and service provider networks, you should use standard-based DSCP PHB markings because the use of such markings can streamline interoperability and compliance with service provider classes of service. Classification and marking design principles covered in this section are illustrated in Figure 16-1.
)
Figure 16-1 QoS Classification and Marking Architecture
Policing and Remarking Design Principles
Traffic that is unwanted should be discarded as soon as possible to preserve network resources from unnecessary consumption. Undesirable traffic can be the result of denial of service (DoS) or worm attacks. Furthermore, excessive unwanted traffic could cause a network outage as a result of high impact on the CPU and memory resources of network devices. Malicious traffic can mask under legitimate TCP/UDP ports that are used by well-known applications, and this traffic can create large amounts of unwanted traffic. Traffic behavior must be monitored and marked down as close as possible to the source under such circumstances.
Traffic should be marked down using RFC recommendations. Those recommendations ensure interoperability and end-to-end QoS network design. Examples of these recommendations are RFC 2597 and RFC 2698, where excess traffic with marking of AFx1 should be marked down to AFx2 or AFx3. Note that 2 or 3 in AFx2 and AFx3 represent drop probability. This markdown principle should be combined properly with other QoS tools. For example, with DSCP-based WRED, AFx2 should be dropped more aggressively than AFx1 but less aggressively than AFx3. Figure 16-2 illustrates the policing and remarking design principles covered in this section.
)
Figure 16-2 Policing and Remarking Concepts
Queuing Design Principles
The only way to provide QoS service guarantees to business-critical applications is to enable queuing to every node that has the potential for congestion. Queuing should be enabled regardless of whether congestion is occurring rarely or frequently. Although frequently deployed at the WAN edge, this principle must be applied not only to congested WAN links but also within the campus network. Speed mismatch, link aggregation, and link subscription ratios can create congestion in the network devices by filling up queuing buffers.
Because each distinctive application class requires unique QoS service requirements, it is recommended you provide a distinctive queue for each traffic class. One of the main justifications for leveraging distinctive queues is that each QoS service class can accept certain QoS-enabled behaviors such as bandwidth allocation and dropping ratios.
It is recommended you use a minimum of four standards-based queuing behaviors on all platforms and service provider links when deploying end-to-end QoS across the network infrastructure:
RFC 3246 Expedited Forwarding PHB (used for real-time traffic)
RFC 2597 Assured Forwarding PHB (used for guaranteed bandwidth queue)
RFC 2474 Default Forwarding PHB (default nonprioritized queue, best effort)
RFC 3662 Lower Effort Per-Domain Behavior (less than best-effort queue, bandwidth constrained)
Dropping Design Principles
As covered in Chapter 15, congestion avoidance mechanisms are used to selectively drop packets when a predefined limit is reached. As a review, by dropping packets early, congestion avoidance helps prevent bottlenecks downstream the network. Congestion avoidance mechanisms include RED and WRED. If WRED is designed per recommendations where every traffic class has its own queue, WRED should be used for only some types of queues (not necessarily all of them).
It is recommended that WRED not be used for the strict-priority queue, scavenger traffic queue, and control traffic queue. Traffic for the strict-priority queue and control traffic queue are highly sensitive to dropping. Scavenger traffic is often provisioned with a small amount of bandwidth, typically below 1 percent, and for this type of queue, WRED is not needed. Considering that the WRED feature is performed in software, enabling WRED for scavenger traffic class will consume additional CPU resources with no significant gain.
For AF-marked queues with DSCP-based WRED, typically traffic marked with AFx3 is more aggressively dropped than AFx2, which is in turn more aggressively dropped than AFx1.
All traffic types that are not explicitly defined in other queues fall into default (DF) traffic class. For this traffic class, it is recommended to enable WRED. WRED should be enabled in the default queue because, as explained in Chapter 15, it increases throughput by reducing the TCP synchronization effect. In the case of the default queue where all different traffic types are equally marked with a DSCP value of zero, there is no mechanism to fairly weight less aggressive applications when WRED is not enabled.
Per-Hop Behavior Queue Design Principles
The goal of convergence in the network is to enable voice, video, and data applications to seamlessly coexist in the network by providing each with appropriate QoS service expectations and guarantees.
When real-time applications are the only ones that consume link bandwidth, non-real–time applications’ performance can be significantly degraded. Extensive testing results show that there is significant performance impact on non-real–time applications when more than one-third of the links is used by real-time applications as part of a strict-priority queue. Thus, it is recommended that no more than a third of link bandwidth be used for strict-priority queuing. This principle prevents non-real–time applications from being dropped out of their required QoS recommendations. In other words, it is recommended that no more than 33 percent of the bandwidth be used for the expedite forwarding (EF) queue. It is also important to note that this 33 percent design principle is simply a best practices design recommendation and not necessarily a mandatory rule.
It is recommended that a minimum of one queue be provisioned for assured forwarding per-hop behavior (AF PHB), but up to four subclasses can be defined within the AF class: AF1x, AF2x, AF3x, and AF4x. Each queue belonging to the specified AF subclass must have a bandwidth guarantee that corresponds to the application requirements of that traffic subclass.
The default forwarding (DF) class consists of all traffic that is not explicitly defined in other queues. If an enterprise is using many applications, it is important to have adequate space for those traffic types. It is recommended that typically 25 percent of link bandwidth be used for this service class. Figure 16-3 illustrates an example of bandwidth allocation leveraging these recommended best practices.
)
Figure 16-3 Bandwidth Allocation Example
RFC 4594 QoS Recommendation
RFC 4594 QoS provides guidelines for marking, queuing, and dropping principles for different types of traffic. Cisco has made a minor modification to its adoption of RFC 4594, namely the switching of Call-Signaling and Broadcast Video markings (to CS3 and CS5, respectively). A summary of Cisco’s implementation of RFC 4594 is presented in Figure 16-4.
)
Figure 16-4 QoS Marking—RFC 4594
RFC 4594 is the recommendation but not the standard; it resides in the category of draft proposal RFCs. It recommends guidelines on how to configure 14 traffic classes that are associated with 28 different code-point marking values. Note that some of the PHBs shown in Figure 16-4 include multiple DSCP-associated values. For example, the AF class for multimedia streaming can have AF31, AF32, and AF33 DSCP values. RFC 4594 includes information on which PHBs should be used for certain traffic types and also what queuing and dropping mechanism should be used for that same traffic class.
Some sample recommendations highlighted in Figure 16-4 include
Voice traffic should be marked to EF/DSCP 46.
Voice should be queued using strict-priority queuing.
Broadcast video traffic should be marked to CS5/DSCP 40.
Multimedia conferencing should be treated with an AF PHB, provisioned with a guaranteed-bandwidth queue.
RFC 4594 is not a final RFC standard and will more than likely continue to be developed considering that needs and trends for QoS application requirements change over the time.
QoS Strategy Models
Before applying any QoS tools, organizations need to define the strategy and goals for different applications running in their network. This will result in defining a certain number of traffic classes to meet the end-to-end QoS objectives of an organization. Three basic QoS strategy models can be deployed, depending on the granularity of applications running within an organization’s network:
4-Class QoS Strategy Model
8-Class QoS Strategy Model
12-Class QoS Strategy Model
Although the more classes you define, the more specific and granular traffic treatment will be per application, the selection of a certain strategy model must be based on application requirements coupled with the WAN provider QoS model (if there is any WANs with QoS). The following sections provide a detailed view into each of these QoS strategy models.
4-Class QoS Strategy
The 4-class QoS strategy model is the simplest of the three models (in terms of QoS polices) and typically accounts for telephony, signaling, transactional/mission-critical, and best-effort data. When businesses deploy telephony applications in their network, three classes of traffic are typically required (telephony, signaling, and default/best effort).
Typically, the fourth class is the Assured Forwarding (AF) class. The AF class is used for transactional and mission-critical data applications such as SQL databases. The AF class can also be used for multimedia conferencing, multimedia streaming, and bulk data applications.
The 4-class QoS strategy model, as shown in Figure 16-5, is an example of where an organization has deployed IP telephony. In addition to separating telephony, signaling, and default/best-effort traffic, the organization has defined one mission-critical transactional data class.
)
Figure 16-5 The 4-Class QoS Strategy Model
The four traffic classes of QoS markings and guarantees are as follows:
Voice (Real time): Marked with EF and provisioned to leverage up to one-third of link bandwidth
Signaling: Marked with CS3 and provisioned to leverage a minimum of 7 percent of link bandwidth
Mission-critical data (Transactional Data): Marked with AF31 and provisioned to leverage 35 percent of link bandwidth
Default (best-effort data): Marked with DF and provisioned to take advantage of 25 percent of link bandwidth
Voice and signaling guarantees must be selected based on the volume of voice calls and the VoIP codec that is used through the given link. Mission-critical data is selected based on the decision of the director of each company department who has given info about critical business application needs to the networking team.
8-Class QoS Strategy
The 8-class QoS strategy model builds upon the 4-class model and includes the following additional classes:
Multimedia conferencing
Multimedia streaming
Network control
Scavenger
The two additional multimedia traffic types in this model are multimedia conferencing and multimedia streaming. The explicitly defined network control traffic class is used for applications such as network routing protocol updates or network infrastructure control traffic such as OAM. The 8-class QoS strategy model is illustrated in Figure 16-6.
)
Figure 16-6 The 8-Class QoS Strategy Model
As can be seen from Figure 16-6, the recommendations for each traffic class in this model are as follows:
Voice: Marked with EF and limited to 10 percent of link bandwidth in a strict-priority queue
Multimedia conferencing (Interactive video): Marked with AF41 or sometimes as EF and limited to 23 percent of link bandwidth in a strict-priority queue
Multimedia streaming: Marked with AF31 and guaranteed 10 percent of link bandwidth with WRED enabled
Network control: Marked with CS6 and guaranteed 5 percent of link bandwidth
Signaling: Marked with CS3 and provisioned with minimum of 2 percent of link bandwidth
Transactional data: Marked with AF21 and provisioned with 24 percent of link bandwidth with WRED enabled
Default (best-effort data): Marked with DF and provisioned with 25 percent of link bandwidth
Scavenger: Marked with CS1 and provisioned with a maximum of 1 percent of link bandwidth
12-Class QoS Strategy
The 12-class QoS strategy model builds upon the 8-class model and includes the following additional classes:
Real-time Interactive
Broadcast Video
Management/OAM
Bulk Data
The 12-class QoS strategy model represents Cisco’s interpretation of the RFC 4594 recommendation and, as previously noted, incorporates a slight modification by swapping the markings used for signaling and broadcast video. The 12-class QoS strategy model is illustrated in Figure 16-7.
)
Figure 16-7 The 12-Class QoS Strategy Model
As can be seen from Figure 16-7, the recommendations for each traffic class in this model are as follows:
Voice: Marked with EF and limited to 10 percent of link bandwidth in a strict-priority queue
Broadcast video: Marked with CS5 or sometimes as EF and limited to 10 percent of link bandwidth in a strict-priority queue
Real-time interactive: Marked with CS4 or sometimes as EF and limited to 13 percent of link bandwidth in a strict-priority queue
Multimedia conferencing: Marked with AF41 or sometimes as EF and limited to 10 percent of link bandwidth in a strict-priority queue
Multimedia streaming: Marked with AF31 and guaranteed 10 percent of link bandwidth with WRED enabled
Network control: Marked with CS6 and provisioned as guaranteed bandwidth 2 percent of link bandwidth
Signaling: Marked with CS3 and provisioned with a minimum of 2 percent of link bandwidth
Management/OAM: Marked with CS2 and provisioned with a minimum of 3 percent of link bandwidth
Transactional data: Marked with AF21 and provisioned with 10 percent of link bandwidth with WRED enabled
Bulk data: Marked with AF11 and provisioned with 4 percent of link bandwidth with WRED enabled
Default (best-effort data): Marked with DF and provisioned with 25 percent of link bandwidth
Scavenger: Marked with CS1 and provisioned with a maximum of 1 percent of link bandwidth
Summary
Use QoS policies in hardware rather than in software whenever possible.
Classify, mark, and police applications as close to the source as possible.
Use DSCP marking whenever possible.
Define a queue for the traffic class and enable queuing on each node that has potential congestion.
Limit the strict-priority queue to one-third of the link bandwidth.
Do not use WRED for priority or scavenger traffic classes.
Use one of the three QoS strategy models to govern end-to-end QoS design.
Review Questions
After answering the following questions, please refer to Appendix A, “Answers to Review Questions,” for the answers.
Which of the following is recommended for a QoS queuing design?
You should implement queuing policy very selectively.
Classes should share queues in order to save resources.
You should use at minimum 4 classes of queuing behavior.
You should use at minimum 11 classes of queuing behavior.
Match the application classes with their PHBs as per RFC 4594.
Select the four classes of the 4-class QoS model.
Voice, signaling, mission-critical data, and best effort
Video, signaling, mission-critical data, and best effort
Voice, signaling, mission-critical data, and scavenger
Real-time interactive, signaling, mission-critical data, and best effort
Why is it recommended to leverage DSCP markings wherever possible?
Support for end-to-end Layer 3 marking.
It is a more granular method of marking that supports 64 levels as compared to CoS and MPLS EXP, which have 8 levels.
It is more extensible than Layer 2 markings because these markings are lost when media change.
All the above.
None of the above.
Traffic should be marked down using which RFC recommendations? (Select two.)
RFC 2957
RFC 2597
RFC 2698
RFC 2968
VoIP Telephony |
EF |
Transactional Data |
CS1 |
Network Control |
CS6 |
Call Signaling |
CS4 |
Real-time Interactive |
AF21 |