Home > Articles > Quality of Service Design Overview

Quality of Service Design Overview

Chapter Description

This chapter provides an overview of the QoS design and deployment process. This process requires business-level objectives of the QoS implementation to be defined clearly and for the service-level requirements of applications to be assigned preferential or deferential treatment so that they can be analyzed.

Summary

This chapter began by reviewing the QoS requirements of voice, video, and data applications.

Voice requires 150-ms one-way, end-to-end (mouth-to-ear) delay; 30 ms of one-way jitter; and no more than 1 percent packet loss. Voice should receive strict-priority servicing, and the amount of priority bandwidth assigned for it should take into account the VoIP codec; the packetization rate; IP, UDP, and RTP headers (compressed or not); and Layer 2 overhead. Additionally, provisioning QoS for IP Telephony requires that a minimal amount of guaranteed bandwidth be allocated to Call-Signaling traffic.

Video comes in two flavors: Interactive-Video and Streaming-Video. Interactive-Video has the same service-level requirements as VoIP because embedded within the video stream is a voice call. Streaming-Video has much laxer requirements because of a high amount of buffering that has been built into the applications.

Control plane requirements, such as provisioning moderate bandwidth guarantees for IP routing protocols and network-management protocols, should not be overlooked.

Data comes all shapes and sizes but generally can be classified into four main classes: Best-Effort (the default class), Bulk Data (noninteractive background flows), Transactional/Interactive (interactive, foreground flows), and Mission-Critical Data. Mission-Critical Data applications are locally defined, meaning that each organization must determine the select few Transactional Data applications that contribute the most significantly to its overall business objectives.

A less-than best-effort Scavenger class of traffic was introduced, and a strategy for using this class for DoS and worm mitigation was presented. Specifically, flows can be monitored at the campus Access-Edge, and out-of-profile flows can be marked down to the Scavenger marking (of DSCP CS1). To complement these policers, queues providing a less-than best-effort Scavenger service during periods of congestion are deployed in the LAN, WAN, and VPN.

The chapter concluded with a set of general best-practice principles relating to QoS planning, classification, marking, policing, queuing, and deployment. These best practices include the following:

  • Clearly defining the organization's business objectives to be addressed by QoS

  • Selecting an appropriate number of service classes to meet these business objectives

  • Soliciting executive endorsement, whenever possible, of the traffic classifications, especially when determining any mission-critical applications

  • Performing QoS functions in (Catalyst switch) hardware instead of (Cisco IOS router) software, whenever possible

  • Classifying traffic as close to the source as administratively feasible, preferably at Layer 3 with standards-based DSCP markings

  • Policing traffic as close to the source as possible, following standards-based rules (such as RFC 2597, "Assured Forwarding Markdown"), whenever possible

  • Provisioning at least one-quarter of a link to service Best-Effort traffic

  • Provisioning no more than one-third of a link to service real-time and strict-priority traffic

  • Provisioning a less-than best-effort Scavenger queue, which should be assigned as low of a bandwidth allocation as possible

  • Understanding and thoroughly testing desired QoS features in conjunction with features already enabled on the production network

  • Deploying end-to-end QoS in stages during scheduled network downtime, with a recommended rollback strategy

9. Further Reading | Next Section Previous Section