We always talk about implementing Quality of Service (QoS) to support voice or video, but the most prominently used approach is DiffServ, which is really a Class of Service (CoS) mechanism. What is going on here? What we really want is Quality of Service (QoS), but as noted, what DiffServ offers us is Class of Service (CoS) The key difference for voice and video is the guarantee of available bandwidth. A true QoS mechanism will guarantee that the network has sufficient bandwidth to support our call request. DiffServ does not do this and so we have to build in this mechanism somewhere else.
Let's take a closer look. What DiffServ does for us is set up the network to give preferential treatment to some traffic flows over others. Because they are loss and delay sensitive, voice and video are given high priority treatment; like flying first class. Packets are identified by the endpoint or by the network edge router as being voice or video packets, and are given a DiffServ marking (DSCP or DiffServ Code Point) to reflect their status. Each router and switch then reads that marking and gives that packet preferential queuing on its output ports as it is forwarded to the next network segment. This is like having a first-class waiting line at the airport check-in counter. These packets are serviced quickly and sent on their way.
However, to prevent high priority traffic from consuming too much of the network's resources, the network (router) also limits the total bandwidth available for this high priority service. Here is where my airline analogy breaks down. The airlines know that first class will be a small percentage of their flyers because they only have a few first class seats in each airplane. But in the network we don't have that built-in limitation. Unknowing users can overload the network with high volumes of high priority traffic, especially when high-definition video conferencing or telepresence systems are deployed. If the network does not protect itself, this high priority load will crush other applications, giving users very poor performance and making them unusable.
To protect against this, the network administrator configures a bandwidth limit for each class of service. Voice over IP (VoIP) is often configured at only 10% of a link's bandwidth. Video conferencing often needs more than this due to its higher bandwidth requirement. But in either case, a hard bandwidth limit is configured into the router. The router will only forward the class at its maximum configured bandwidth, and so when an overload occurs, queues start to fill up (causing jitter) and then overflow (causing packet loss). Poor quality voice and video result.
So we must manage the bandwidth used by voice and video applications to stay within the assigned bandwidth limits imposed by the network. This problem today is handled by the application, meaning the voice call manager or the video gatekeeper, and is done through Call Admission Control (CAC). By limiting the number of simultaneous calls on any given network link, the application can keep the bandwidth within the defined limit.
This approach requires the application to understand the network topology and to know the specific bandwidth assigned for voice and video on each link. This is a problem, because these two pieces of technology are not well integrated. They taught us in engineering school not to store the same information in two different places at once because they can get out of sync. But this is exactly what we are doing in this situation. Both the information about the topology of the network and the bandwidth allocated on each link are stored in the network and stored again in the voice and video application. It is easy for them to get out of sync, especially when the two systems are managed by different teams.
So there is work yet to be done in this area to make CoS into a QoS that will work reliably and simply. But for today, the vast majority of deployments of voice and video use DiffServ, which is a CoS system, and rely on the application to manage the bandwidth. So pay close attention to the parameters that are set in the call manager or gatekeeper, and make sure you have a process that keeps them synchronized with the real network behavior.
