Contact Us   Archive   Sitemap

  

IP Video Task Force Report

Quality of Service (QoS)

No multiservice network can successfully be implemented without being able to provide a QoS or Class of Service (CoS) to preferred services. Due to wide diversity in design of Local Area Networks and Wide Area Networks, each will require its own unique solution.

PRIMARY QUESTIONS

ANSWERS

What Is QoS? QoS is the set of techniques to manage network resources in a manner that enables the network to differentiate and handle traffic based on policy. This means providing consistent, predictable data delivery to users or applications that are supported within the network. Achieving the required Quality of Service (QoS) by managing delay, delay variation (jitter), bandwidth, and packet loss parameters on a network becomes the secret to a successful end-to-end business solution.

Why implement QoS? Implementing a successful QoS policy will ensure a predictable, measurable, and guaranteed treatment of the communications on the backbone. This would provide a better means of handling specialized traffic on the limited and costly backbone resources. The demand for the use of bandwidth-intensive and delay/jitter-sensitive applications coupled with the ever-increasing use of backbone for “unsupported” traffic provides the need and reasoning for implementing QoS.

What creates QoS in H.323? There are many tools used to implement QoS in H.323. Some of these are: Differential Services Code Point (DSCP), Resource Reservation Protocol (RSVP), Priority Queuing (PQ), Committed Access Rates (CAR), and Weighted Random Early Detection (WRED), among others. Using many or all of these tools, in conjunction with other technologies, creates a working QoS.

Resource Reservation Protocol (RSVP) has been described by some as the magic cure of QoS. At this time, RSVP is being actively developed but is not ready for deployment on core networks.

Differential Services Code Point7 (DSCP) is a process that helps to classify or differentiate traffic. This is accomplished by setting the six MSBs of the Type of Service byte in the IP header.

Weighted Random Early Detection8 (WRED) is Cisco Systems’ version of Random Early Detection (RED). RED is designed for packet switched networks. RED will randomly drop packets when it senses a period of high congestion. TCP hosts and applications will respond to this by decreasing their rate of transmission (this is achieved through standard TCP window sizing). As congestion is reduced, the TCP window sizing process will gradually allow those hosts to increase their transmission rates again. This allows normalization of TCP traffic patterns, rather than the “peaks and valleys” that would occur without RED. WRED combines DSCP with RED to further insure that voice and video, which are time-sensitive applications, will receive priority over data.

How does a video call get priority over data traffic? This is accomplished through the use of precedence bits, which are set in the IP header. The precedence bits are the three most significant bits of the Type of Service byte in the IP header. The higher the number, the greater precedence one packet has over another. Due to the sensitivity of voice and video packets in relation to data packets, voice is given a precedence of 5, video is given a precedence of 4, and data a precedence of 0. This ensures that voice and video packets are given priority over data packets in the routers.

On which area, WAN or LAN, will a video call be most dependent? The ITN is working hard on a redesign of its core WAN. Once this is completed, QoS will be live on the Wide Area Network. (See Figure 9.)

How much bandwidth do I need? Video conferencing requires large amounts of bandwidth. A video application usually requires a minimum of 384 kbps bandwidth to support a call that is considered “minimally acceptable” for instruction. With addition of overhead, a 384 call actually uses 460 kbps of bandwidth. Cisco recommends that video and voice applications use no more than 33 percent of the capacity of a given link (See Figure 8). This means that a T1 (1.5 mbps) has the capacity to support only one or two video calls. Bandwidth limitations are the reason that video calls attempted over the commodity Internet are usually unsatisfactory.

Firewalls and NAT: How do they affect QoS? Firewalls are not part of the H.323 standard. Networks deploy firewalls in order to prevent unauthorized use of their network and to defend against hackers and others who might disrupt their network operations. Because their primary purpose is to limit access, this presents a problem for those who want to videoconference. Some workarounds are:

Those with firewalls should check with their vendor for the most current H.323 update. More information can be found at the following links:

http://www.iec.org/tutorials/h323/topic01.html Provides a series of tutorials on H.323

http://www.packetizer.com/iptel/h323/ Excellent short articles plus information regarding the status of the H.323 standard and its component standards. This also has links to other sites dealing with H.323

Recommendation: The IPVTF recommends that the ITN provide QoS throughout the network up to the point of demarcation for ITN, the LAN interface on the router. At this point, packets will continue to be “prioritized;” however, it will be up to the customer to decide how to act upon those packets.

Figure 8

QoS Provisioning

Figure 9

QoS Enabled

LAN Issues

Many factors come into play in implementing QoS, not least of which is the LAN. While ITN can design a network that will provide QoS out to the LAN interface on the switch, individual LAN administrators will have to consider how to allocate resources for voice, video, and data. Some of these issues are:

These are some of the questions that the network LAN designers will have to consider as they implement IP video conferencing on their networks.

Steps Necessary to Implement QoS on a Cisco Empowered Wide Area Network

Creating the Arena

Before implementing QoS, engineers must first establish an environment within the hardware making differentiated services possible. The equipment providing this environment must have adequate processor, memory, and back-plane resources. A very common problem, which must be corrected before implementing a working QoS solution, is Head-Of-Line-Blocking or HOLB. This issue is present in virtually all of the Cisco routing platforms on the market today.

HOLB comes into play on devices that do not use SSB (Single Stage Buffering). The issue presents itself when the output queues on an egress interface become exhausted and the hardware is unable to offload the input queue on the ingress interface. During this state of the problem, randomized delay is induced to the traffic stream. If this activity continues, the input queues on the ingress interface will become exhausted, thus causing an aborted or ignored data gram. At this stage of the problem, data grams (see Figure 10.) are being discarded randomly and may not even belong to the interface causing the problems.

Figure 10

HOLB

A technique allowing the Cisco routing platform to work around this design issue includes limiting the transmit queues, limiting the hold queues, and applying Committed Access Rates (CAR) to ALL interfaces on the chassis. (Cisco Express Forwarding (CEF) must be enabled before the functional use of CAR.) A successful implementation of these changes will not allow the initial overflow of the output buffer, which cures HOLB before it starts.

Using the 7200 VXR series as an example, the following commands would be issued to the device:

Tx-ring-limit 12
Hold-queue 30 out
Rate-limit output X Y Z conform-action transmit exceed-action drop
Where X 95% of capacity
Y Normal Burst Bytes
Z Maximum Burst Bytes

Implementing QoS

Creating a QoS or CoS on a Cisco routing platform is simply done by creating a service policy and applying the policy to the output side of the interface. Service policies can range from very simple prioritizations to complex queuing issues. This particular example will describe a service policy that not only supports prioritized traffic but also handles delay/jitter sensitive applications specially. This will be a Priority Queue (PQ) enabled Custom Queue (CQ) with Weighted Random Early Detection (WRED).

A Custom Queue is simply a queue strategy that is customized to meet the needs of the implementation. An example would be defining a queue that treats IPX traffic preferably over SNA.

A Priority Queue is a queue that has the capability to service traffic which matches a certain criterion before other traffic is serviced. This is a necessity to applications that are sensitive to jitter and delay variation. This queue should be less than 33 percent of the capacity of the connection that it services, thus giving the queue the ability to prioritize and interleave traffic.

The example provides 10kbs of ‘RAS’ or call-control traffic, 512kbs of low-latency Priority Queue, and the remainder to traffic based upon IP Precedence values 0 thru 3. Traffic with the Precedence value of 0 is 12.5 times more likely to be dropped than Precedence 4 traffic.

Policy assumptions before implementation:

Define “Priority” traffic as any traffic with the IP Precedence value of 5.
Define “RAS” traffic as anything flowing on UDP/TCP ports 1718-1720 and UDP ports 54000-56000.

Configuring the Router:

Defining RAS:
Class-map match-all ras
Match access-group 2222
Access-list 2222 permit udp any any range 1718 1720
Access-list 2222 permit udp any range 1718 1720 any
Access-list 2222 permit tcp any any range 1718 1720
Access-list 2222 permit tcp any range 1718 1720 any
Access-list 2222 permit udp any range 54000 56000 any
Access-list 2222 permit udp any any range 54000 56000

Defining Priority:
Class-map match-all priority
Match ip precedence 5

Building the Policy:
policy-map T1
class priority
priority 512
class ras
bandwidth 10
class default
bandwidth 600
random-detect
random-detect precedence 0 2 4 4
random-detect precedence 1 2 4 5
random-detect precedence 2 2 4 5
random-detect precedence 3 2 4 10
random-detect precedence 4 2 4 50
* In these statements we are increasing the mark probability as the precedence value decreases.

Applying the policy to the interface:
Interface X/Y.Z
Service-policy T1 out

References

1. “Recommendations for the Phase I Deployment of OSI Directory Services (X.500) and OSI Message Handling Services (X.400) within the ESnet Community”, ESCC X.500/X.400 Task Force, ESnet Site Coordinating Committee (ESCC), Energy Sciences Network (ESnet), RFC 1330, May 1992, http://www.cis.ohio-state.edu/Services/rfc/rfc-text/rfc1330.txt

2. T. Howes, “The Lightweight Directory Access Protocol: X.500 Lite”, July 27, 1995, http://www.stanford.edu/group/networking/directory/doc/ldap/ldap.html.3. “The SLAPD and SLURPD Administrators Guide, Release

3.3”, University of Michigan, April 30, 1996, http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html

4. W. Yeong, T. Howes, S. Kille, “Lightweight Directory Access Protocol”, RFC 1777, March 1995, http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1777.html

5. “Click To Meet and NAT/Firewall Solving the Security Dilemma”, First Virtual Communications, Inc., 31 May 2001.

6. G. Scheichl, “Using Click to Meet™ with the Cisco MCM and IP/VC 3500 Series Products”, Version 1.0 Application Note, First Virtual Corporation, Inc., 12 June 2001, http://www.fvc.com//products/whitepapers.htm

7. Cisco IP Telephony Network Design Guide, Cisco Call Manager Release 3.0(5), Cisco Systems, Inc, 2001, http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/index.htm

8. Implementing a Wide Area Network, Cisco Systems, Inc., Copyright© 1992-2001, http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/avvidqos/qoswan.htm#xtocid1116739

9. Deploying QoS for Voice and Video in IP Networks, Networkers Session VVT-213, Copyright © 1998, Cisco Systems, Inc., http://www.cisco.com/networkers/nw01/pres/preso/VideoandVoiceTechnologies/VVT-213.pdf

10. Designing and Deploying IP video conferencing, Enterprise Solutions Engineering, Networkers Session VVT-230, Copyright© 2000, Cisco, Systems, Inc., http://www.cisco.com/networkers/nw01/pres/preso/VideoandVoiceTechnologies/VVT-230.pdf

11. Quality-Of-Service, Random Early Detection (RED), Cisco Systems Inc., 1992-1999, http://www.cisco.com/warp/public/732/Tech/red



Last updated: September 01, 2006