QoS Requirements for Voice
Voice Bearer Traffic: Voice quality is directly affected by all three QoS quality factors: loss, latency and jitter. Cisco DSP can use predictor algorithms to compensate for up to 30ms loss of voice samples. So, two or more voice packets loss will cause noticeable voice quality degradation. A summary of the key QoS requirements for Voice (bearer traffic) are:
• Voice traffic should be marked to DSCP EF (46) per the QoS Baseline and RFC 3246.
• Loss should be no more than 1 %.
• One-way Latency (mouth-to-ear) should be no more than 150 ms.
• Average one-way Jitter should be targeted under 30 ms.
• 21–320 kbps of guaranteed priority bandwidth is required per call (depending on the sampling rate, VoIP codec and Layer 2 media overhead).
Jitter buffers (also known as play-out buffers) are used to change asynchronous packet arrivals into a synchronous stream by turning variable network delays into constant delays at the destination end systems. A jitter buffer set too large adds to the end-to-end delay, while too small jitter buffer can not accommodate the network jitter, then buffer underflows or overflows will occur. Thus Adaptive jitter buffers algorithms aim to overcome these issues by dynamically tuning the jitter buffer size to the lowest acceptable value.
VoIP is well suited to the Expedited Forwarding Per-Hop Behavior, and should therefore be marked to DSCP EF(46) and assigned strict priority servicing at each node, regardless of whether such servicing is done in hardware (as in Catalyst switches via hardware priority queuing) or in software (as in Cisco IOS routers via LLQ).
The amount of overhead per VoIP call depends on the Layer 2 technology used:
• 802.1Q Ethernet adds (up to) 32 bytes of Layer 2 overhead.
• Point-to-point protocol (PPP) adds 12 bytes of Layer 2 overhead.
• Multilink PPP (MLP) adds 13 bytes of Layer 2 overhead.
• Frame Relay adds 4 bytes of Layer 2 overhead; Frame Relay with FRF.12 adds 8 bytes.
• ATM adds varying amounts of overhead, depending on the cell padding requirements.
Call-Signaling Traffic: The following are key QoS requirements and recommendations for Call-Signaling traffic:
• Call-Signaling traffic should be marked as DSCP CS3 per the QoS Baseline (during migration, it may also be marked the legacy value of DSCP AF31).
• 150 bps (plus Layer 2 overhead) per phone of guaranteed bandwidth is required for voice control traffic; more may be required, depending on the call signaling protocol(s) in use.
Why the Signaling traffic is marked CS3 other than AF31: Call-Signaling traffic was originally marked by Cisco IP Telephony equipment to DSCP AF31. However, the Assured Forwarding classes, as defined in RFC 2597, were intended for flows that could be subject to markdown and – subsequently – the aggressive dropping of marked-down values. Marking down and aggressively dropping Call-Signaling could result in noticeable delay-to-dial-tone(DDT) and lengthy call setup times, both of which generally translate to poor user experiences. Now Call-Signaling traffic is marked as DSCP CS3 because Class Selector code points, as defined in RFC 2474, were not subject to markdown/aggressive dropping.
QoS Requirements for Videos: Video traffic includes Interactive Video and Streaming Video.
Interactive Video: When provisioning for Interactive Video (IP Video conferencing) traffic, the following guidelines are recommended:
• Interactive Video traffic should be marked to DSCP AF41; excess Interactive-Video traffic can be marked down by a policer to AF42 or AF43.
• Loss should be no more than 1 %.
• One-way Latency should be no more than 150ms.
• Jitter should be no more than 30ms.
• Overprovision Interactive Video queues by 20% to accommodate bursts
Because IP Videoconferencing (IP/VC) includes a G.711 audio codec for voice, it has the same loss, delay, and delay variation requirements as voice, but the traffic patterns of videoconferencing are radically different from voice. its packet sizes and rates vary, the header overhead percentage will vary as well, so an absolute value of overhead can not be accurately calculated for all streams. So overprovision the guaranteed/priority bandwidth by 20 percent will be the solution shown in lab testing. For example, a 384 kbps IP/VC stream would be adequately provisioned with an LLQ/CBWFQ of 460 kbps.
Streaming Video: When addressing the QoS needs of Streaming Video traffic, the following guidelines are recommended:
• Streaming Video (whether unicast or multicast) should be marked to DSCP CS4 as designated by the QoS Baseline.
• Loss should be no more than 5%.
• Latency should be no more than 4–5 seconds (depending on video application buffering capabilities).
• There are no significant jitter requirements.
• Guaranteed bandwidth (CBWFQ) requirements depend on the encoding format and rate of the video stream.
• Streaming video is typically unidirectional and, therefore, Branch routers may not require provisioning for Streaming Video traffic on their WAN/VPN edges (in the direction of Branch-to-Campus).
Non-organizational Streaming Video applications, such as entertainment videos, may be marked as Scavenger (DSCP CS1) and assigned a minimal bandwidth (CBWFQ) percentage.
Streaming Video applications are delay-insensitive (the video can take several seconds to cue-up) and are largely jitter-insensitive (due to application buffering). However, Streaming Video may contain valuable content, such as e-learning applications or multicast company meetings, and therefore may require service guarantees.
QoS Requirements for Data: The Cisco QoS Baseline identifies four main classes of data traffic; Best Effort, Bulk Data, Transactional or Interactive Data and Locally-Defined Mission-Critical Data.
Best Effort Data: The Best Effort class is the default class for all data traffic. An application will be removed from the default class only if it has been selected for preferential or deferential treatment.
Best Effort traffic should be marked to DSCP 0, and at least 25 percent of bandwidth should be reserved for Best Effort traffic:
Bulk Data: The Bulk Data class is intended for applications that are relatively non-interactive, delay-insensitive, drop-insensitive and that typically span their operations over a long period of time as background occurrences.
Bulk Data traffic should be marked to DSCP AF11, or AF12 and AF13 for Mark down, and have a moderate bandwidth guarantee, but should be constrained from dominating a link.
Transactional/Interactive Data: also referred to simply as Transactional Data, is a combination to two similar types of applications: Transactional Data client server applications and Interactive Messaging applications. Transactional Data Client Server applications require relative fast response thus different from other general Client Server applications such as E-mail.
Transactional Data traffic should be marked to DSCP AF21, or AF22 and AF23 for Mark down, and should have an adequate bandwidth guarantee for the interactive,foreground operations they support.
Locally-Defined Mission-Critical Data: Mission-Critical Data traffic should be marked to DSCP AF31 or AF32 and AF33 for Markdown. However, until all Cisco IPT products mark Call-Signaling to DSCP CS3, a temporary placeholder code point (DSCP 25) will be used to identify Mission-Critical Data traffic. Mission-Critical Data traffic should have an adequate bandwidth guarantee for the interactive, foreground operations they support.
QoS Requirements of the Control Plane: Control Plane includes IP Routing traffic and Network Management.
IP Routing: By default, Cisco IOS software marks Interior Gateway
Protocol (IGP) traffic such as Routing Information Protocol (RIP/RIPv2), Open Shortest Path First(OSPF), and Enhanced Interior Gateway Routing Protocol (EIGRP) to DSCP CS6. Exterior Gateway Protocol (EGP) traffic such as Border Gateway Protocol (BGP) traffic is also marked by default to DSCP CS6.
IGPs are usually adequately protected with the Cisco IOS internal PAK_Priority mechanism; but for EGPs such as BGP, Cisco recommends an explicit class for IP routing with a minimal bandwidth guarantee.
Network Management: Network Management traffic, containing SNMP, NTP, Syslog, NFS etc, should be marked to DSCP CS2, and should be explicitly protected with a minimal bandwidth guarantee.
QoS Requirements of the Scavenger Class: Applications assigned to this class have little or no contribution to the organizational objectives of the enterprise and are typically entertainment-oriented, for example, Peer-to-Peer (P2P) media-sharing applications, gaming applications and any entertainment video applications.
Scavenger traffic should be marked to DSCP CS1 and be assigned the lowest configurable queuing service which would mean assigning a CBWFQ of 1 % to Scavenger in Cisco IOS software.
As Scavenger traffic will dropped the most aggressively, Scavenger Class can be used to mitigate the DoS/Worm attacks with both Access-Layer policers and hardware or software queuing schemes.
DoS/Worm Attacks: There are two main classes of DoS attacks:
• Spoofing attacks—The attacker pretends to provide a legitimate service, but provides false information to the requester (if any).
• Slamming/flooding attacks—The attacker exponentially generates and propagates traffic until service resources (servers and/or network infrastructure) are overwhelmed.
Spoofing attacks are best addressed by authentication and encryption technologies. Slamming/flooding attacks, on the other hand, can be effectively mitigated through QoS technologies.
Worms, on the other hand, exploit security vulnerabilities in their targets and disguisedly carry harmful payloads that usually include a self-propagating mechanism. The rapidly multiplying volume of traffic flows eventually drowns the CPU/hardware resources of routers and switches in their paths of propagation, thus cause denial of service.
Access-Layer policers: In order to meter out-of-profile traffic volumes and respond to abnormally sustained high volumes as close to the source as possible, Access-Layer policers is deployed to remark these traffics to Scavenger (DSCP CS1). (Administrator profiles normal and abnormal traffics, and it is quite abnormal for PCs to generate sustained traffic in excess of 5 % of link capacity)
After the Access-Layer policers, it is necessary to enforce end-to-end “less-than-Best-Effort”Scavenger-class queuing policies within the Campus, WAN and VPN.
Cisco QoS Baseline model: