All the standard references on how to build your QoS model put Voice (VoIP) in the highest priority queue and relegate video conferencing to the next one down. Most network routers have a single Low Latency Queue (LLQ) so this means voice gets the LLQ and video gets carried in a Class-Based Weighted Fair Queue (CBWFQ). Is this application priority based on the needs of the application or is it a hold-over from a time when video conferencing was not considered a necessary application?One of the standard misconceptions I often discuss in presentations and client engagements is that network priority should be related to the importance of an application to the enterprise. This incorrect approach would prioritize applications based on their effect on the bottom line or based on who is using them (management versus individual contributors) or whatever other financial, political or hierarchical process was at work in the enterprise to determine what is more or less important. This approach does not work.
The reason we prioritize certain applications over others is because those applications are sensitive to packet loss and/or jitter, latency and perhaps throughput. Queuing priority helps traffic streams have low loss, low jitter and low latency. Some applications need this and others do not.
Think about Citrix as an example. The Citrix client communicates with the Citrix server passing keystrokes and mouse movement information. The server then interprets this information to run the application itself, which is on the Citrix server. The performance of this application is dependent on the small and relatively low bandwidth packet streams between client and server having low latency and low loss. If the delay between client and server increases due to loss (and loss recovery time) or due to latency from network congestion, the user perceives slow responsiveness in the application. Worker productivity is affected as responsiveness slows down and frustration rises.
So it is an easy decision to give priority to the Citrix packets over applications that do not need this immediate response, like web browsing, database lookup, email, and backup. Giving priority to the low bandwidth Citrix streams means maintaining good performance even when the network is congested. And there is very little impact on other applications because the Citrix bandwidth is low.
Voice and video conferencing have this same need for timely delivery. With voice and video we are trying to reproduce a real-time event and so the receiving codec has to receive a constant stream of new information to continue to reproduce the audio and visual information representing the original event. If packets are lost then quality degrades because the sound or images are reproduced without having all the original information. If packets are late (this is jitter) they may be too late to be useful. Their moment on the stage may have passed, and so the data they carry is no longer useful.
So standard practice today is to give voice the high priority queue. It is very important to the organization that voice quality is high, and the application needs to have low loss, latency and jitter, so this makes sense.
But now we introduce video conferencing. Video has the same requirements as voice, but has the unfortunate characteristic that it also requires much larger bandwidths to transport the visual information. Does this mean it should be in a lower class than voice?
The LLQ provides the best (lowest) jitter because it has absolute priority. Any time a packet arrives in the LLQ, it will be the next packet to be sent on the wire. So this means that packets using the LLQ wait for the least amount of time possible. They only have to wait for the packet currently being transmitted to finish, and then they exit the queue and are sent. Voice traffic needs low jitter, so it makes sense that voice uses the LLQ.
But wait, video needs low jitter as well. In fact most video conferencing systems today have tighter jitter specifications than voice. Cisco's telepresence solution gives a warning when jitter of 20ms is experienced. Most VoIP phones have a jitter buffer that allows up to 50ms of jitter, and in some cases they are dynamic and grow much larger as needed to support higher jitter values.
So my question is this. Are we allocating video conferencing to the CBWFQ because of its legacy as not being important to the enterprise? Or is there a legitimate technical reason why video should be at a lower priority class when it seems that its jitter requirements are at least equal to, and in many cases tighter than those of VoIP? Maybe it is time to rethink this hierarchy.
And if you want to pay attention to enterprise priority, do that through bandwidth allocation. Giving greater bandwidth allocations to the applications that support the boss or the revenue stream will ensure they perform well even if they are not using the highest priority queue.
