Desktop video conferencing has the potential of creating large bandwidth demands on the enterprise network. Everyone wants a high definition video connection, and these connections can require 1 Mbps or more of traffic. Some hardware-based codecs have been able to reduce this to a half a megabit, but we are still talking about a lot of traffic.
A typical voice call consumes either 85 Kbps or 30 Kbps, depending on the codec being used. At 1 Mbps for a video call, it is consuming either 11 or 33 times as much bandwidth per call depending on your starting point.
Enterprises are rightly concerned that a rapidly expanding base of users of desktop video conferencing could impact VoIP deployments, high-end video (room-based or telepresence) or the critical data applications of the enterprise. Careful QoS design is the answer, but how should desktop video be classified and managed?
This makes sense, as the VoIP and the hardware-based video have high visibility, need to provide consistent high quality, and are reasonably manageable. Room-based and telepresence systems are added systematically and under the management of the video or network team. Network planning and call admission control can be modified to keep up with increasing demand from this class of traffic.
Desktop video, on the other hand, tends to grow virally within an organization. Users only need a web camera and a software license, and they are up and running. All of a sudden a whole department that used to make their calls using 30 Kbps of traffic is doing video at 1 Mbps.
The network team could just force desktop video to run at best effort, and some companies propose this solution. I believe that traffic should be prioritized not based on its "importance", but instead based on the network loss and jitter characteristics it requires. Desktop video running at best effort will not have consistent quality. So the company needs to decide if they are supporting desktop video, in which case it should be given a decent priority, or if they are trying to discourage desktop video. If the latter, perhaps an edict is a better approach than a poor classification on the network.
So this opens the question, should desktop video have its own class, where the bandwidth can be managed to some reasonable level, but the priority can be reasonably high to maintain quality? With proper network design and call admission control, this should work well.
But now we have a problem. The video conferencing vendors' equipment is not designed to understand two classes of traffic for the video conferencing application. Figure 1 below shows the typical gatekeeper configuration for a four-facility enterprise with an MPLS WAN. The gatekeeper is configured with this simplified topology, and given the video bandwidth allowed on each link.
Figure 1: Single class-of-service CAC diagram
Typically endpoints are identified as belonging to one of these groups (e.g. BOS) by IP address or subnet. A call being placed from BOS to LAX for example, will then consume bandwidth on the BOS and LAX links. The gatekeeper tracks all concurrent calls per link, and blocks calls if the bandwidth of a link will be exceeded by allowing the next call.
If there are two classes of service (e.g. desktop video and room-based video), then the gatekeeper needs to have a more complex network topology like the one shown in Figure 2 below. This diagram shows the WAN cloud as two separate clouds, one supporting EF traffic and one supporting AF41 traffic. The bandwidth on the links into the WAN clouds represent the amount of bandwidth allowed per traffic class.
Figure 2: Two class of service CAC diagram
To know if a video endpoint is a desktop or a room-based system, the gatekeeper will have to put them into separate groups by location. Then as they are connected, the gatekeeper needs to understand which path they will take. This network has multiple paths between each location.
The problem is further complicated when a desktop endpoint wishes to call a room-based endpoint. If the traffic markings are not modified, one direction of the call will flow over the lower priority class (e.g. the desktop -> room-based system) and the other direction will flow over the higher priority class (e.g. the room-based system -> desktop). This will consume bandwidth (logically) in both classes, not a great result. If the network is configured to upgrade the desktop to the higher class when connecting to the room-based system it will prevent this double use, but potentially confound the gatekeeper CAC.
Last but not least we have the video MCU or bridge, which needs to connect both to room-based systems and desktop systems on a regular basis. Do we consider the bridge as being a high-priority device so it will work correctly with the telepresence and room-based systems (certainly desirable), or do we classify it with the desktops so that every desktop-to-bridge connection is not using high priority bandwidth?
One thing I like about this business is that the technical challenges keep on coming. Hey vendors, when can we get a common bandwidth management server that dynamically understands network topology and can act as a broker for this kind of problem? Is it time to go back and visit RSVP? Are there some better solutions coming?
I think this challenge of desktop video bandwidth management is real and will pop up more and more as this technology gets rolled out. The SVC vendors claim you can just run it all at best effort and it will be fine, but we have other apps running at best effort that also should not be crushed. I think we need an active solution for desktop video conferencing bandwidth management.
