Most IP telephony Quality of Service (QoS) problems are created by congestion, which occurs when network load exceeds...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
network capacity for a period of time. The most effective method for managing congestion is to augment capacity in some way, as I discussed in my previous article, IP telephony QoS: Capacity planning and management.
Is your network experiencing voice quality problems because of congestion? If not, there may be fundamental design issues to address.
Sometimes, however, congestion isn't the problem with IP telephony QoS, and sometimes it's not practical to add capacity to alleviate IP telephony QoS issues. In these situations, VoIP traffic management and prioritization can help.
Achieving IP telephony QoS: Setting goals for VoIP traffic management
The first step in independent VoIP traffic management is to set the goals of the process. Is your network experiencing voice quality problems because of congestion? If not, then there may be fundamental design issues to address.
One indication that network congestion isn't the problem is unacceptable network delay, even when utilization on all of the links remains within design levels. In these cases, you will often see a relatively large delay without corresponding packet loss.
If that's the case, you may be experiencing a handling delay problem.
Identifying and prioritizing VoIP traffic can ease congestion
If you have IP telephony QoS issues created by congestion and can't attack the source by adding capacity or limiting traffic from competing applications, you may need to prioritize your VoIP traffic. Prioritization will let the traffic move to the head of the queue at any point where traffic is backed up, so the key to prioritization is to know where the backups are happening. Look at the interface statistics presented by your management system. Prioritization will help in spots where you find deep queues on an output interface.
To prioritize VoIP traffic to alleviate congestion delay, you'll need one of two things:
- A way to make your current devices understand traffic priority (e.g., through packet inspection, looking for VoIP packets), or
- A device designed to perform application-based optimization of VoIP traffic through priority handling.
In either case, you'll have to identify your VoIP traffic in some way and then apply handling rules for prioritizing that traffic. You'll need to do this wherever the VoIP traffic management system report indicates that your traffic is encountering deep queues.
Because most networks use faster trunks than ports, you'll probably find your congestion problem close to the network edge, where interfaces are slower. If that's the case, it may not be necessary to tinker with priority handling and routing deeper in the network.
Understanding delay and routing to improve IP telephony
Sometimes VoIP traffic is degraded -- and VoIP traffic management complicated -- not by congestion but simply because there are too many devices between the source and destination. Handling delay is the result of the normal process of switching a packet through a switch or router. The packet must be read from the input port, examined to make a forwarding decision, and then written to the output port. Serialization delay -- the time it takes to read or write a packet -- is dependent on packet size and link speed.
Routing delay is the time it takes to make the forwarding decision. This can sometimes be overlapped with the input read if the switch/router can examine the header only when it's been completely read. Faster ports and trunks will reduce serialization delay, so that may be a good option for the local area network (LAN) portion of any data path. Having fewer devices along a path reduces delay accumulation, so more direct routes may be a good strategy where route complexity is the problem.
In IP networks, there are various ways of providing Class of Service (CoS)-based routing, depending on how your VoIP traffic is identified. It may be necessary to tag the traffic near the network edge to make efficient use of the techniques. Remember: Too many routing table entries defining special handling for a given type of traffic will increase delay for all traffic. Try to use a tagging technique for VoIP traffic management that lets you manage internal traffic routes without adding discrete entries for each VoIP traffic flow.
In Ethernet networks, spanning tree limitations prevent the creation of alternate routes, but there are data center enhancements available for Ethernet that may allow you to create alternate paths that your VoIP traffic can then be directed to take. You'll need to check with your switch vendors to ensure that they all support these enhancements. If they do, you may be able to establish a separate virtual LAN (VLAN) for VoIP traffic management and create more direct routes to reduce latency.
With any form of prioritization and route optimization, you'll need to be especially cautious if your VoIP traffic is part of a unified communications and collaboration (UCC) application. Some collaborative applications, like whiteboard, are also delay-sensitive, and you may find that prioritizing only VoIP will create a disconnect between voice and whiteboard activity. If video is used in collaboration, the voice channel will most likely ride with the video, meaning that you'll have to prioritize the whole flow. Where networks are already congested, doing so may make other applications prohibitively slow when video is used.
VoIP traffic management and prioritization can improve IP telephony QoS but can also increase the overall complexity of the network, raising operations and support costs. It's important to assess the total impact of any proposed VoIP traffic management and prioritization solutions before implementing any and to try lowest-cost strategies first to ensure that overall return on investment meets company goals.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982. He is the publisher of Netwatcher, a journal in advanced telecommunications strategy issues.