on - edited on by
ciscomoderator
The Secret to Successful QoS Deployments: A Well-Defined End-to-End QoS Strategy
Editor’s Note: TS Newsletter readers get a 35% discount on Tim Szigeti’s book, End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks. See discount code at the end of this article.
A chain is only as strong as its weakest link.
The same goes for successful QoS deployments. If any device in the path is not configured in a consistent and compatible manner with the rest, it can destroy the overall quality of service of the network infrastructure. Therefore, careful thought and planning has to be given to defining an end-to-end strategy to ensure the levels of service across the network. Especially is this important when considering that—unlike chains, where every link is typically identical—the devices in the network will vary considerably, from wireless access points to switches to routers to firewalls, and so forth. Each device will have their own capabilities and QoS feature sets, and yet these will all have to work together in a cohesive manner to achieve the end-to-end results.
So where to start?
The most successful QoS deployments are driven first and foremost by defining the business requirements of the network. For many network administrators this may require a paradigm shift, “zooming-out” as it were from a purely technical view of the network and seeing the network as a reflection of the overall business objectives of the enterprise. Questions that need articulated answers include: What does my business do? What types of applications do our users need to do their work? Which of these applications are realtime? Which are “foreground”? (Foreground applications require minimal latency from the network, as delays in their servicing will directly impact user productivity.) Which are “background”? (Background applications do not directly impact user productivity and mainly consist of machine-to-machine traffic; however, if left unchecked, such applications could dominate network resources.) Which applications on my networks have no business relevance and can be treated with a “scavenger” service? (Scavenger applications are typically entertainment-oriented and may also consume disproportionate amounts of network resources if unbridled.) Also a vital—but sometimes overlooked consideration is: What types of network control, signaling and management traffic is present over the network and how should it be serviced?
Each group of applications with similar service-level requirements will need a dedicated class of service from the network in order to achieve requisite end-to-end servicing. There’s simply no other way to guarantee levels of service. This fundamental aspect of QoS naturally leads to the question: how many levels of service should be provisioned?
To this end, Cisco advocates following relevant industry standards and guidelines whenever possible, as this extends the effectiveness of your QoS policies beyond your direct administrative control. That being said, it may be helpful to overview a relevant RFC for QoS marking and provisioning, namely RFC 4594, “Configuration Guidelines for DiffServ Service Classes.”
These guidelines are to be viewed as industry best-practice recommendations. As such, enterprises and service providers are encouraged to adopt these marking and provisioning recommendations, with the aim of improving QoS consistency, compatibility, and interoperability. However, since these guidelines are not standards, modifications can be made to these recommendations as specific needs or constraints require. To this end, to meet specific business requirements, Cisco has made a minor modification to its adoption of RFC 4594, namely the switching of Signaling and Broadcast Video markings (to CS3 and CS5, respectively). A summary of Cisco’s implementation of RFC 4594 is presented in Figure 1.
Figure 1: Cisco’s (RFC 4594-based) QoS Strategy
RFC 4594 outlines (up to) twelve classes of media applications that may require dedicated classes of service, due to their unique service level requirements:
VoIP Telephony—This service class is intended for VoIP telephony (bearer-only) traffic (VoIP signaling traffic is assigned to the “Signaling” class). Traffic assigned to this class should be marked Expedite Forwarding (EF/DSCP 46). This class is provisioned with an Expedited Forwarding (EF) Per-Hop Behavior (PHB). The EF PHB-defined in RFC 3246-is a strict-priority queuing service and, as such, admission to this class should be controlled. Example traffic includes G.711 and G.729a.
Broadcast Video—This service class is intended for broadcast TV, live events, video surveillance flows, and similar “inelastic” streaming video flows (“inelastic” refers to flows that are highly drop sensitive and have no retransmission and/or flow control capabilities). Traffic in this class should be marked Class Selector 5 (CS5) and may be provisioned with an EF PHB; as such, admission to this class should be controlled. Example traffic includes live Cisco Digital Media System (DMS) streams to desktops or to Cisco Digital Media Players (DMPs), live Cisco Enterprise TV (ETV) streams, and Cisco IP Video Surveillance.
Real-Time Interactive—This service class is intended for (inelastic) room-based, high-definition interactive video applications and is intended primarily for voice and video components of these applications. Whenever technically possible and administratively feasible, data sub-components of this class can be separated out and assigned to respective traffic classes. Traffic in this class should be marked CS4 and may be provisioned with an EF PHB; as such, admission to this class should be controlled. An example application is Cisco TelePresence.
Multimedia Conferencing—This service class is intended for desktop software multimedia collaboration applications and is intended primarily for voice and video components of these applications. Whenever technically possible and administratively feasible, data sub-components of this class can be separated out and assigned to respective traffic classes. Traffic in this class should be marked Assured Forwarding (AF) Class 4 (AF41) and should be provisioned with a guaranteed bandwidth queue with DSCP-based Weighted-Random Early Detect (DSCP-WRED) enabled. Admission to this class should be controlled; additionally, traffic in this class may be subject to policing and re-marking. Example applications include Cisco Jabber and Cisco WebEx, Cisco Unified Video Advantage, and the Cisco Unified IP Phone 7985G.
Multimedia Streaming—This service class is intended for Video-on-Demand (VoD) streaming video flows, which, in general, are more elastic than broadcast/live streaming flows. Traffic in this class should be marked AF Class 3 (AF31) and should be provisioned with a guaranteed bandwidth queue with DSCP-based WRED enabled. Admission control is recommended on this traffic class (though not strictly required) and this class may be subject to policing and re-marking. Example applications include Cisco Digital Media System Video-on-Demand (VoD) streams.
Network Control—This service class is intended for network control plane traffic, which is required for reliable operation of the network. Traffic in this class should be marked CS6 and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as network control traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes EIGRP, OSPF, BGP, HSRP, IKE, etc.
Signaling—This service class is intended for signaling traffic that supports IP voice and video telephony. Traffic in this class should be marked CS3 and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as signaling traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes SCCP, SIP, H.323, etc.
Operations/Administration/Management (OAM)—As the name implies, this service class is intended for network operations, administration, and management traffic. This class is critical to the ongoing maintenance and support of the network. Traffic in this class should be marked CS2 and provisioned with a (moderate, but dedicated) guaranteed bandwidth queue. WRED should not be enabled on this class, as OAM traffic should not be dropped (if this class is experiencing drops, then the bandwidth allocated to it should be re-provisioned). Example traffic includes SSH, SNMP, Syslog, etc.
Transactional Data (or Low-Latency Data)—This service class is intended for interactive, “foreground” data applications. Traffic in this class should be marked AF Class 2 (AF21) and should be provisioned with a dedicated bandwidth queue with DSCP-WRED enabled. This traffic class may be subject to policing and re-marking. Example applications include data components of multimedia collaboration applications, Enterprise Resource Planning (ERP) applications, Customer Relationship Management (CRM) applications, database applications, etc.
Bulk Data (or High-Throughput Data)—This service class is intended for non-interactive “background” data applications. Traffic in this class should be marked AF Class 1 (AF11) and should be provisioned with a dedicated bandwidth queue with DSCP-WRED enabled. This traffic class may be subject to policing and re-marking. Example applications include: E-mail, backup operations, FTP/SFTP transfers, video and content distribution, etc.
Best Effort (or Default Class)—This service class is the default class. The vast majority of applications will continue to default to this Best-Effort service class; as such, this default class should be adequately provisioned. Traffic in this class is marked Default Forwarding (DF or DSCP 0) and should be provisioned with a dedicated queue. WRED is recommended to be enabled on this class.
Scavenger (or Low-Priority Data)—This service class is intended for non-business related traffic flows, such as data or video applications that are entertainment and/or gaming-oriented. The approach of a “less-than Best-Effort” service class—such as defined in RFC 3662—as opposed to shutting these down entirely, has proven to be a popular, political compromise. These applications are permitted on business networks, as long as resources are always available for business-critical applications. However, as soon as the network experiences congestion, this class is the first to be penalized and aggressively dropped. Traffic in this class should be marked CS1 and should be provisioned with a minimal bandwidth queue that is the first to starve should network congestion occur. Example traffic includes YouTube, Netflix, Hulu, BitTorrent, Xbox Live, iTunes, etc.
Finally, while RFC 4594 outlines up to 12 classes of service, not all businesses may be ready for such a complex QoS model. Therefore a simpler class of service model may be better suited to meet current business needs without overwhelming the networking staff. In time, however, this class of service model may evolve, even as business requirements do. Network administrators then do well to plan ahead, deploying QoS in a phased approach—such as shown in Figure 2—to meet these evolving business needs.
Figure 2: QoS Class-of-Service Model Evolution
For further detail—including detailed platform-specific QoS design recommendations for the campus, branch, data center, WLAN and VPNs, refer to the recently updated Cisco Press book: “End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks.”
Tim Szigeti, CCIE No. 9794, is a technical leader at Cisco within the Enterprise Systems Engineering (ESE) team, where he has spent the last decade specializing in quality of service technologies. His current role is to design network architectures for the next wave of media applications, including TelePresence, IP video surveillance, digital media systems, and desktop video. He has coauthored many technical papers, including the Cisco Enterprise QoS Design Guide and the Cisco TelePresence Network Systems Design Guide, and the Cisco Press book End-to-End QoS Network Design. Tim holds a bachelor of commerce degree in management information systems from the University of British Columbia.
| End-to-End QoS Network Design: Quality of Service for Rich-Media & Cloud Networks, 2nd Edition By Tim Szigeti, Christina Hattingh, Robert Barton, Kenneth Briley Published Nov 26, 2013 by Cisco Press. Part of the Networking Technology series. Copyright 2014 Pages: 1040 Edition: 2nd
Book ISBN-10: 1-58714-369-0 ISBN-13: 978-1-58714-369-4 DISCOUNT: 35% off ciscopress.com for Cisco Technical Newsletter customers; use code CISCOTECH at checkout. |
This article is featured in the March 2014 issue of the Cisco TS Newsletter. Are you subscribed?
