May 2003

Quality of Service: A Has Been? Or Up And Coming?

BY JOHN WOOD

Quality of Service (QoS) is a technology that has seen a slow rise to fame. Even though it has been available to network administrators for some time, its lack of a killer application and the challenges associated with implementation have kept deployments to a minimum. However, with the increasing adoption of real-time applications, such as VoIP and streaming video, network QoS is finally becoming a reality.

APPLICATION PERFORMANCE
QoS is based on a simple concept: it gives one class of network traffic priority over another class of traffic to achieve acceptable application performance. To make it work, application traffic must be tagged with a priority identifier, and then the network must consistently handle the traffic in accordance with the tagging.

Tagging mechanisms and the ability to enforce priorities in network devices have been available for some time. But historically, neither tagging nor prioritization has been easy to implement because the network administrator has to understand all the complexity of QoS. Since application traffic is not automatically tagged, the administrator has to design the tagging for each application and make sure that it is applied at every network hop. This requires purchasing and installing a special box to tag packets, or configuring routers to do it.

That’s only half the battle. Once the packets are tagged, all the devices in the network must be set to prioritize the traffic consistently to apply an overarching QoS policy. To implement this, the administrator needs to understand different techniques for prioritizing, choose the best QoS mechanism for each network device, and then configure it on each network device. And the same QoS policy has to be maintained as new devices come online or are serviced.

Understandably, anyone considering implementing QoS has to be motivated by an urgent need. Performance for traditional business Transmission Control Protocol (TCP) applications such as SAP and Siebel is important, but even with slow performance the application will continue to work. If a SAP transaction sometimes takes 10 seconds instead of the normal one second, it may be irritating to the user, but all the data is there and they can still do their job. If the application stopped working when response time got to 10 seconds then the need would be more urgent.

Therefore, while some network administrators adopt QoS for their TCP applications, it hasn’t gained wide acceptance. The implementation cost is high, and it addresses a problem -- application response time -- which is more of a nice-to-have than a must-have.

But the QoS landscape is changing. With the growing popularity of VoIP and other real-time applications such as streaming video, QoS is becoming a necessity to achieve expected network performance. As a result, network vendors are working hard to lower the cost of implementation.

QoS AND VoIP
Unlike TCP business applications, which benefit from QoS, VoIP and video rely on it. Because VoIP and video are real-time applications, they require strict performance levels. Since users are accustomed to the high quality of the telephone network, their demands for VoIP performance are high. Where users of TCP applications are satisfied with response times of two or three seconds, a VoIP call begins to see degradation after one-way delay exceeds 150 ms. When one way delay on a VoIP call reaches 500ms the quality of the call becomes unusable. Because of the real-time nature of VoIP, if data is lost then it is never recovered. With a TCP business application the data will be retransmitted and the transaction is slower, but the data is not lost. VoIP also requires a small variation in the arrival time of packets (jitter). If the jitter on a network is too high then a packet is as good as lost. VoIP requires networks with low delay, low data loss, and low jitter.

VoIP implementations often require network upgrades to handle the additional demands. Additional bandwidth, conversion to an all-switched architecture, and equipment upgrades may all be needed. While most networks require upgrades to support VoIP, all networks require QoS to run VoIP with acceptable quality. The network may have plenty of bandwidth, but those big pipes feed into smaller pipes, and many pipes feed into a few. The potential for congestion arises at each such intersection. Even in a completely switched environment, a many-to-one case inevitably crops up. For example, say you have 24 users on 100Mb links, all talking to a server on a 100Mb link. If each person is using even 1/10th of the available bandwidth, the link will experience a serious congestion problem. In congested conditions, packets are either dropped or delayed. Those dropped or delayed packets will severely damage VoIP call quality.

Because VoIP and video require QoS to be successful, the developers of VoIP and video applications are very motivated to enable QoS mechanisms. Traditionally, the manufacturers of network equipment didn’t create the applications in use on the network. Now, however, the same vendors who build the network infrastructure are selling applications such as VoIP and video. Recognizing the importance of QoS to the success of a VoIP deployment, vendors have made great strides toward facilitating the deployment of VoIP QoS. The vendors have therefore successfully addressed both QoS tagging and implementing QoS policies in the network.

EASE OF QoS IMPLEMENTATION
The first step toward facilitating QoS is addressing the problem of tagging an application’s packets. VoIP phones automatically tag packets with bit settings that conform to the 802.1p and DiffServ Code Point (DSCP) QoS standards. 802.1p is a Layer-2 technology that places a four-byte tag on each Ethernet frame, allowing a switch to prioritize. DSCP operates at Layer 3 by setting six bits in the IP header, providing classes for router prioritization.

Since a VoIP phone sets 802.1p and DSCP automatically, a network that’s configured correctly can prioritize VoIP above other traffic at all points in the network. Prioritization is usually performed by means of queuing on a given device. In a switch or router, a special queue for VoIP will be set aside so the VoIP traffic can always flow through smoothly. Class-Based Weighted Fair Queuing is an example of the queuing performed by many routers. Cisco has implemented LLQ, which is essentially Class-Based Weighted Fair Queuing, but with a specific queue set aside for VoIP.

Vendors are also working to make the implementation of QoS policy easier in the network. Most vendors offer a QoS policy manager that will configure all the devices in the network to prioritize VoIP. Policy managers, along with automatic packet tagging, have greatly simplified VoIP QoS implementation. Cisco’s has implemented AutoQoS in their devices to automatically implement a “VoIP” policy consistently in the network. AutoQoS works in conjunction with Ciscoworks QoS Policy Manager to automate QoS policy settings. Nortel offers similar functionality through a product called Optivity Policy Manager.

Another reason QoS is becoming easier to deploy is that it’s getting easier to test, tune, and monitor. Verifying that QoS is operating as desired is a vital step in any deployment. This can be done by running traffic over the network and measuring its performance. Accurately emulating VoIP or video transmissions is the best way to determine whether a QoS policy is working correctly before deploying the VoIP or video application. In addition to testing, it’s also important to monitor specific devices to ensure that all QoS settings are implemented consistently, from one end of the network to the other.

Vendors have made great strides in recent years to make QoS easier to deploy and manage, but there is still work to be done. One problem with the current policy managers is that they work almost exclusively with a single vendor’s equipment. Users don’t typically replace all boxes in the network and instead tend to leverage as much of their network investment as possible; therefore, the vendor-specific policy managers often don’t handle their situations. QoS must be implemented consistently across a network for it to be effective.

With the increasing adoption of applications such as VoIP and video that require QoS, and with vendors’ desire to see these applications deployed as widely as possible, QoS is becoming much easier to implement -- not just for VoIP and video, but for all applications. No longer an afterthought or a painful undertaking for network administrators, QoS is becoming an integral part of application deployment.

John Wood is development manager at NetIQ Corp. NetIQ is a leading provider of Systems Management, Security Management and Web Analytics solutions. Historically focused on the Windows management market, NetIQ now delivers cross-platform solutions that enhance business performance resulting in higher returns on infrastructure and web investments. For more information, please visit the company online at www.netiq.com.

[ Return To The May 2003 Table Of Contents ]