TMCnet
ITEXPO begins in:   New Coverage :  Asterisk  |  Fax Software  |  SIP Phones  |  Small Cells
 
 


VoIP and the Myth of QoS Dude

By Eric Bear

 

I have many conversations with enterprises first deploying VoIP, and when I ask if they are concerned about the performance of their voice application, I occasionally get an answer like, No, I have QoS in my network. Unfortunately, the gap between that confidence and deployment reality is sometimes quite large, due to the fact that QoS is not a set-and-forget network option. It takes careful initial planning, ongoing monitoring and a precise management strategy to sleep well at night.

What do I mean by QoS?

Quality of Service (QoS) is one of high-tech marketings favorite words of the last ten years. One of the few terms I can think of with more usage and meanings is dude. My buddy from the mail room, who happens to be an ex-southern California surfer dude, can change dude into seven different meanings just by slightly changing the way he pronounces it. Maybe QoS is not quite as utilitarian a term, but the several ways it is used can be confusing if you are not already a certified networking dude.

The term QoS is commonly mixed between two concepts; 1. The measurement of quality the user experiences with a particular application (i.e., I am measuring the quality of service of my voice calls and it sounds awesome, dude) and 2. The underlying mechanics in the network that assure a specific application is given a priority to the resources it needs to deliver a good quality.

For the purposes of this article, I am going to talk about QoS in the second context the network mechanics that prioritize traffic for special treatment. Volumes could be written about all the technology options available for managing QoS today, and the fervor with which some support one approach versus another, borders on religious devotion. Intserv versus diffserv, Layer 2 and Layer 3 QoS, call admission control, trust boundaries; combinations of these techniques work well for different people in specific applications. I wont try to cover the specific QoS options in detail, but I will talk about a deployment and management strategy that works regardless of the underlying QoS techniques chosen.

Is QoS necessary for VoIP deployments?

QoS doesnt magically create high-quality VoIP. What it does is spread the pain of a lack of bandwidth across network applications in the way you choose. If your network is overprovisioned with extra bandwidth, the need for QoS diminishes, but does not go away.

QoS is typically needed to solve a few potential link oversubscription or high utilization scenarios. One is where you have an aggregation of traffic sources into a single link where the link speed is lower than the sum of all the aggregated links into it. A typical example is two gigabit LANs plugged into a router that has a T1 WAN interface for uplink traffic. You cant fit 10 pounds of stuff into a five pound sack. QoS methods like prioritization and queuing can help balance spikes of traffic that cause oversubscription.

Another scenario is a mismatch of data link speeds between two communicating points in a network. A typical case of this is a headquarters location with a T3 WAN link connecting to a remote office that has a T1 WAN link. A chain is only as strong as its weakest link. QoS techniques like call admission control can ensure that that traffic volumes dont exceed the allocated capacity on the slower links.






A third scenario happens when a low priority application is transmitting a very large packet and a high priority application wants to transmit. The high priority application might have to wait until the large packet is completed. A typical example of this is sharing a converged Ethernet link to your desktop between your IP phone and your computer sending large e-mail attachments. The voice packets will make it through the IP phone and into the network, but the time the VoIP packet waited to be sent through the phone cable creates jitter on the packet. Fragmentation and interleaving of the large packets and VoIP packets will minimize this jitter.

Plan Your Network Deployment

To begin, before you deploy VoIP on your data network you should perform a predeployment assessment. Most VoIP equipment vendors and some service providers require this be done today, and some have even developed specific procedures so that your network is certified by that vendor. To the best of my knowledge, no vendor requires QoS to be enabled in your network infrastructure today, but all will highly recommend it. During your VoIP assessment, you should not only load test the network to verify VoIP calls can be carried with the desired quality, but if QoS is enabled, you should test to make sure that VoIP and VoIP signaling are given the priority that you expect.

This test of QoS priority can be performed roughly by generating synthetic VoIP traffic over your network with QoS tagging enabled on the synthetic traffic and then rerunning the test with the QoS tagging turned off and comparing the results. Some VoIP management vendors also have very specific tests to deduce the level of priority that VoIP traffic is given over the enterprise network or even on service provider networks being traversed, but it should be augmented by a level of granular management visibility to be comprehensive.

The output of an assessment is a clear understanding of the VoIP traffic load that can be supported by the network and an identification of any issues that need to be corrected.

Determine the Baseline

The predeployment assessment might turn up network problems that need to be corrected before the VoIP equipment is installed. These issues might include duplex mismatches, link capacities, or configuring QoS within the network.

When these issues are corrected and the new VoIP equipment is installed, its time to take a snapshot. Not a picture of all the victorious networking dudes involved around a celebratory beer keg, but a baseline test of your network. As stated earlier, VoIP is a real-time, ongoing initiative, its not plug-and-play. This baseline will ensure that the VoIP network works as expected and also gives you a benchmark to compare back to as you move forward into the operational stage.

To perform the baseline test, the management system needs to generate the maximum VoIP traffic load planned for and verified in the predeployment assessment. It is important that the synthetic traffic type matches the actual traffic exactly so that it gets the same network treatment. Some management vendors will use echoed UDP or ICMP traffic to simulate a VoIP call. This technique will allow for testing without software agents in the network, but does not guarantee that the tests are handled by QoS queues, firewalls, and other network elements in the same manner.

Monitor on an Ongoing Basis

Networks are not static. New VoIP and data users are added, new sites are added, users find new applications on a regular basis. These changes can cause network problems, which result in poor application performance, user complaints or lost revenue. QoS, if configured properly, will make sure that the lower priority traffic is punished first.

It is important to put in place a monitoring and management strategy that keeps a watchful eye on the operating network. Slight degradations in call quality can be caught before the problem becomes serious and users complain or revenue is lost. The management system should be able to not only notify that there is a problem, but it must be able to help troubleshoot, diagnose, and suggest reasons for the problem.

Make Adjustments to QoS as Needed

Changing network conditions certainly require changes to QoS policies. Some of the basic QoS configurations can remain static, like IP phone traffic will always be treated at the same QoS level and large low priority data packets will be fragmented into smaller packets. However, many of the original assumptions made when QoS was first deployed, such as the percentage of bandwidth on each link dedicated to each priority traffic type, will definitely need to be continuously reassessed.

To be truly effective, the management system needs to draw on a combination of passive real world monitoring and active synthetic testing data to understand fully and proactively when issues are occurring, and have the capability to diagnose the problem quickly.

Summary

QoS is necessary for almost all VoIP deployments in some form. Because IP networks are very dynamic, QoS is not a set and forget solution to your VoIP application working. Ongoing monitoring and management is a necessity before VoIP is even deployed. Networks and network traffic loads change, so QoS needs to change too.

Good luck with your VoIP deployment, dude! IT

Eric Bear is vice president of product management and business development at Viola Networks (news -Viola+Networks). For more information, please visit the company online at www.violanetworks.com.

If you are interested in purchasing reprints of this article (in either print or PDF format), please visit Reprint Management Services online at www.reprintbuyer.com or contact a representative via e-mail at [email protected] or by phone at 800-290-5460.

[RETURN TO THE TABLE OF CONTENTS]



Today @ TMC
Upcoming Events
ITEXPO West 2012
October 2- 5, 2012
The Austin Convention Center
Austin, Texas
MSPWorld
The World's Premier Managed Services and Cloud Computing Event
Click for Dates and Locations
Mobility Tech Conference & Expo
October 3- 5, 2012
The Austin Convention Center
Austin, Texas
Cloud Communications Summit
October 3- 5, 2012
The Austin Convention Center
Austin, Texas