IP telephony traffic is rarely sufficient to create network problems by itself. Most IP telephony performance problems are caused by other traffic that loads the network to the point where IP telephony QoS suffers. Since IP telephony traffic is often more sensitive to QoS issues than Web or application traffic, voice managers should take QoS problems as a warning sign to review network traffic, capacity, and traffic management measures. Otherwise, problems are likely to spread to all applications on the network.
Are your IP telephony QoS symptoms caused by congestion?
Network performance problems are almost always caused by congestion. Congestion is nearly always a temporary condition created when the capacity of the network won't handle the presented traffic. The most obvious solution to congestion, and therefore to QoS problems, is to increase network capacity, but that may not always be economically realistic; and, in some cases, congestion may not be at the root of the problem. While IP telephony traffic levels may be too low to congest the network, the congestion created by other applications will affect IP telephony.
QoS normally measures packet loss and packet delay within a specified load or traffic volume. Congestion in the network will mean network routers or switches have to hold traffic for capacity to become available, and this will normally cause both packet delay (queuing delay) and packet loss (queue overflow). It's possible to measure delay and packet loss between various network points using tools ranging from simple to complex, and it's best to pick one that's familiar and apply it systematically to the routes taken by your IP telephony traffic.
If you see evidence of both delay and packet loss, then you can be sure you have a congestion problem. Packet loss is also sometimes identifiable by the fact that it creates "drop-outs" or clicks in the audio stream of voice calls, but delay can also cause strange speech artifacts, so it's best not to rely on subjective views of voice quality in diagnosing problems.
What you're looking for is peak-level utilizations over 70% or average utilization over about 35%. Either suggests that it is possible that the network is becoming congested under load.
When a congestion problem is suspected, the most important step is to analyze the link utilization along the route the traffic would be likely to take. Traffic routes can be determined by looking at the forwarding tables in switches/routers (directly or using tools like traceroute). Dynamic routing protocols can change routes over time, but most enterprise networks will have fairly static routes except during network failures. Check several times on several days to get a complete view. What you're looking for is peak-level utilizations over 70% or average utilization over about 35%. Either suggests that it is possible that the network is becoming congested under load. If you can correlate objective network load on various routes with subjective reports of call quality problems, you're definitely on the right track.
Video traffic hogs bandwith, hampers IP telephony QoS
If some of the links along a route are congested, the first thing to do is determine what traffic is causing the problem. Video traffic, in the form of collaboration/telepresence video or Internet video, is the most bandwidth-hogging application on most enterprise networks. It may be possible to compress collaboration traffic or take it off network into a telepresence service, and Internet video can be reduced by policing employee usage. In most cases, IP telephony quality can be improved simply by unloading unwanted traffic.
Where that doesn't work, look to see whether there are alternate routes for traffic that remain underutilized. If your network has such routes, you may be able to improve performance simply by utilizing them more effectively. How this can be done will depend on whether your network is based on Ethernet or IP and the specific routing protocol that you're using. In IP networks, it's fairly easy to establish multiple routes and control traffic flows, but for Ethernet, the standard spanning tree protocol won't allow multiple routes. See whether your vendor supports emerging data center Ethernet standards to provide alternatives to spanning tree.
When in doubt, apply compression
Another strategy to try in order to avoid having to increase link capacity is some form of data compression on applications that generate a lot of traffic and thus compete with IP telephony for capacity. Compression devices are available from many vendors, and some routers/switches may offer data compression options.
When used properly, compression can increase effective capacity by 30% or more.
While you might apply compression to selected congested links, most enterprises prefer to compress high-volume traffic at the point of arrival on the network. Compression works much like the popular archiving "zip" software except that it operates on traffic on the fly. Nearly all compression devices will introduce incremental delay (called "insertion delay"), and applying it selectively to points that introduce heavy traffic while avoiding interfaces with IP telephony traffic can help manage your delay budget while still gaining the additional transmission efficiency that compression can create. When used properly, compression can increase effective capacity by 30% or more.
The most important thing to remember in reviewing traffic, network load, and congestion issues in IP telephony service is that it's almost always other non-voice traffic that causes the problem. When congestion is a problem, it's best to try to alleviate it for all traffic types. When it's not practical to improve network performance overall, it may be necessary to try and bypass network congestion with IP telephony traffic through a form of routing or prioritization.
Next month, I will cover IP telephony QoS: Routing and prioritization.
About the author: Tom Nolle is president of CIMI Corporation, a strategic consulting firm specializing in telecommunications and data communications since 1982. He is a member of the IEEE, ACM, Telemanagement Forum, and the IPsphere Forum and is the publisher of Netwatcher, a journal in advanced telecommunications strategy issues.
This was first published in June 2010