As a voice manager, you have probably heard the term Quality of Service (QoS) and probably have a good idea that it's a set of technologies whose goal, as far as you're concerned, is protecting voice traffic on data networks. But when discussions about QoS turn technical, it's easy to get lost in the terms and concepts, many of which are rather complex mathematically.
This complexity is compounded by the confusing relationships between some of the key mechanisms, like IP Precedence and DiffServ and terms like Class of Service and Quality of Service. Worse, providers mix up conventional acronyms and terminology with their marketing terms. And then there are the bizarre analogies, like "leaky buckets." In this tip, we'll try to cover the most important and basic elements you need to know to stay out of trouble, and also suggest a few terms and concepts to read up on as you have time.
First, when people tell you they have QoS in their network or that their network is QoS-enabled, that's insufficient information because it doesn't necessarily tell you which applications are given priority, or whether they've allocated enough bandwidth for your application, or that they've deployed appropriate mechanisms, because there's a wide variety from which to choose. So without digging into the bits and bytes, you want to understand precisely:
- Where in the network they mark or re-mark packets.
- Whether they trust your packets or not.
- What scheduling or queuing techniques are used at each point in the network.
Specifically, you want to ask about QoS in the LAN. You want to ask about QoS on your WAN backbone (in the provider's cloud). And you want to ask about QoS on the WAN access circuit. If your LAN is complex, you may want to get more granular information about the LAN core or backbone versus the distribution and access layers.
Expect fairly different answers for each question, as it's normally appropriate to use different techniques in each location. However, these techniques should all work together and not conflict with one another. The techniques available on Layer 2 devices like switches will usually be less robust than those on devices that look deeper into packets, like routers. Also, some network technologies such as ATM (and ironically, Token Ring) have very robust QoS mechanisms built in, while others, like Ethernet and 802.11 wireless, do not. You should also make an effort to appreciate the difficulty carrier backbone engineers have trying to design a scheme that works with thousands of different customers, many of whom have radically different needs or opinions.
The next thing to understand -- which you've probably figured out by now -- is that there's a difference between marking and queuing or scheduling. Marking is how you identify packets (e.g., distinguishing a voice packet from a packet carrying email), by flipping bits in the packet header, which remain flipped as the packet traverses the network until some other device un-flips them. The terms "queuing" and "scheduling" refer to how each device in the path acts, based on the marking. Thus, it's possible to mark packets and not configure scheduling, or configure scheduling without marking. Both of those scenarios are obviously ineffective.
If you want to dig a little deeper into the queuing side, familiarize yourself with the differences between congestion avoidance and congestion management techniques, where one attempts to fix the problem before it starts, and the other deals with unavoidable congestion.
Finally, as the voice manager, you should be hearing the words "priority queue" and/or "Low Latency Queuing" fairly regularly in your discussions with network administrators. These techniques are widely accepted as best-practice for providing service to VoIP. If you're not hearing them, inquire.
About the author:
Tom Lancaster, CCIE# 8829 CNX# 1105, is a consultant with 15 years of experience in the networking industry. He is co-author of several books on networking, most recently,CCSP: Secure PIX and Secure VPN Study Guide, published by Sybex.
