QoS Design Guidelines for Voice and Video

674 Chapter 9: Management Tools and QoS Design

The challenge with voice delay relates to the overall budget versus the fact that only some of the delay components can be lowered using QoS tools. Looking at Figure 9-5, for example, you can see typical values for the voice delay components for a call from one IP Phone to another IP Phone. The variable delay components have actually been constrained pretty well in this case. The first point of delay is the originating IP Phone. In this example, a 10-ms delay occurs for the codec and a 20-ms delay occurs for packetization, bringing the initial delay to 30 ms. For the purposes of this example, assume that there is no delay experienced on the Ethernet interfaces of the switches or routers. The next point of delay is experienced on the egress interface of R1. Here there is a 15-ms queuing delay, 9-ms serialization delay, and a .5-ms propagation delay, bringing the delay experienced up to this point to 54.5 ms. The next point of delay is experienced on the egress interface of R2. Here there is a 15-ms queuing delay, 4-ms serialization delay, and a .5-ms propagation delay, bringing the delay experienced up to this point to 74 ms. The next point of delay is experienced as the packet crosses the IP network. Here a 50-ms delay occurs, bringing the total delay up to this point to 124 ms. The last point of delay that the packet experiences is in the jitter buffer of the remote IP Phone. Here the delay experienced is 40 ms, bringing the one-way delay to 164 ms end to end.

676 Chapter 9: Management Tools and QoS Design

Table 9-8 Bandwidth Requirements for Various Types of Voice Calls (Continued)

For DQOS test takers: These numbers are extracted from the DQOS course.

Interactive (two-way) video requires delay, jitter, and loss behavior similar to voice traffic. Video uses more bandwidth than voice, in some cases far more bandwidth, and the amount of bandwidth varies over time. Table 9-9 displays some of the bandwidth requirements for video of some popular formats.

Table 9-9 Video Codecs and Required Bandwidth

For one-way streaming video, the QoS characteristics differ when compared to two-way video and voice. The de-jitter buffer can expand from tens of milliseconds to tens of seconds, removing most of the jitter consideration. In addition, with very large de-jitter buffers, and because there is no need for interactive responses, one-way delay can be very large. For oneway video, as long as the video gets enough bandwidth, and there is low loss, the video stream works well.

Voice and Video QoS Design Recommendations

Cisco makes recommendations for how to apply QoS to voice and video in the QoS course books and in several documents on the Cisco website. This section summarizes many of the recommendations made in the QoS courses, because the QoS exams are based on the courses. As with all recommendations, these are not the only ways to apply QoS for voice and video— but they are the ways specifically listed in the design chapter of the Cisco DQOS course.

For those of you who want more information, a particularly good source is the Cisco AVVID Network Infrastructure Enterprise QoS Design Guide, which you can find at www.cisco.com/warp/customer/771/srnd/qos_srnd.pdf.

QoS Design for the Cisco QoS Exams 677

The QOS recommendations for voice and video are listed by category of QoS tool:

•Classification and marking—Cisco suggests three classes for voice and video traffic:

—One class for voice payload, marked with DSCP EF/CoS 5/precedence 5

—Another class for video payload, marked with DSCP DSCP AF41/CoS 4/precedence 4

—A third class for both voice and video signaling, marked with DSCP AF31/CoS 3/precedence 3

Table 1-13 in Chapter 1 outlines the protocols to watch for when classifying voice and video payload and signaling.

•Queuing—The biggest dilemma when thinking of voice and video in the same network is whether video is placed into a low-latency queue with the voice. The course book recommends that voice only be placed into the low-latency queue, with video payload being placed into another queue. The general recommendations are as follows:

—Use Class-Based Weighted Fair Queuing (CBWFQ) with LLQ; if the IOS does not support it, use IP RTP Priority for voice.

—Place voice payload (DSCP EF) into the low-latency queue.

—Place video payload into another class queue.

•Shaping and policing—Shaping slows down traffic when congestion occurs, and policing discards packets when congestion occurs. Voice and video both do not like packet loss or delay. (The exception is one-way video, which tolerates delay.) However, shaping may be usefully applied to a site to throttle the transmission of traffic to prevent overrunning the ingress circuit at the remote site. If you apply shaping to traffic on a Frame Relay virtual circuit (VC), also apply queuing to the shaping queue, to minimize the extra delay added for voice. The following list summarizes the recommendations:

—Use FRTS as necessary, particularly if FR fragmentation is also needed.

—Set Tc to 10 ms (Tc = CIR/Bc).

—Set excess burst (Be) to 0 (no excess burst).

—Shape strictly to committed information rate (CIR) to avoid drops in the Frame Relay cloud.

—When using adaptive shaping, set mincir to a large enough value to support all voice and video traffic.

—Avoid egress blocking pitfalls.

—Use queuing on shaping queues to improve delay, jitter, and loss for voice and video.

678Chapter 9: Management Tools and QoS Design

•Link efficiency—Link fragmentation and interleaving (LFI) reduces one of the variable delay components, namely serialization delay, while compression techniques reduce the bandwidth required. Both types of tools can help. The following list summarizes the recommendations:

—Fragment to a size equal to or slightly larger than the size of the voice packet.

—Use LFI on links with clock rates of 768 kbps or less (1500-byte frame at 768 kbps takes about 15 ms).

—Ensure that the voice packets are smaller than the fragmentation size, so that the voice packets are not fragmented.

—If several VCs use the same access link, and at least one has voice, fragment on all VCs using that access link.

—Use Real Time Protocol header compression (cRTP).

•Call admission control—Without CAC, all the other work to design and implement QoS can be wasted. If you choose your configuration options expecting one range of concurrent calls and video conferences, and twice as many happen, the users and the network will suffer. Use any and all methods available, depending on the topology, as described in Chapter 8, “Call Admission Control and QoS Signaling.”