Back in No Jitter's early days (early 2008) I wrote a piece on bandwidth management that talks about a couple of problems that were not addressed in the market. The first is the sharing of a common bandwidth pool by multiple applications, such as room-based and desktop video conferencing. The second is the reservation of bandwidth for a future event.Well the problem is still there, and the need for this bandwidth management tool has only increased. Today we have many different types of video traffic that would like to share a class of service on the enterprise network including:
* Telepresence * Room-based video conferencing * Desktop-video * Streaming video
There is usually only one class of service for video, and sometimes it even shares a class with other applications (which I do not recommend.) Voice may soon have multiple application types trying to use its class of service as well. Some enterprises promote the audio portion of video calls into the voice class. We may want to consider VoIP streams from UC endpoints differently than the standard VoIP telephone. Or we may want to give priority to some VoIP streams over others (e.g. emergency services, customer call centers, key management calls or briefings, SIP trunks, etc.).
Today we have bandwidth management within applications, done by the IP-PBX or Call Manager for VoIP and done by the gatekeeper for video conferencing. It takes the form of call admission control.
This bandwidth manager (the call manager or gatekeeper) needs to understand the network topology because the available bandwidth is often constrained by the specific access links in use for a call. Thus the bandwidth manager needs to know a call from Joe to Fred will cross the Chicago access link, the MPLS cloud and the New York access link (for example.) If the network is more complex, more hops are needed and more information is needed in the bandwidth manager.
VoIP and video bandwidth managers today are statically programmed to understand the network topology. This can easily cause problems because the bandwidth manager and the network may be in the hands of different teams or even different companies. Changes in the network may not make it into the bandwidth manager if the right internal processes are not in place.
So I am hoping the industry will build a new device that is a central resource for bandwidth management within classes of traffic on the network. Here is what it ought to do.
Dynamic Connection to Network: The first problem that should be solved is a more dynamic connection between the network topology and the bandwidth manager. This dynamic connection would allow the bandwidth manager to discover both topology and available bandwidth per class per link. Automating this connection will prevent the change problem I mentioned above. Furthermore, with automation, we can expect the bandwidth manager to respond quickly to a network outage. It would automatically discover that a key link is down and can scale back voice and/or video use of the links until repairs are made. This is a more dynamic form of topology change.
Open Interface: The next challenge is to have the bandwidth manager support multiple applications. This means the bandwidth manager is not a vendor-specific box like the call manager or the gatekeeper, but is instead something with an open API that can communicate with different applications trying to share the same bandwidth pool. Not a hard job, but a solution that has been missing in the industry to date. With an open API the bandwidth manager could allocate bandwidth to different applications on a dynamic basis. So if there are lots of phone calls running on the Chicago access link, perhaps the bandwidth manager does not let video run at a full 4 Mbps rate, but instead only allows it to run at a lower 2 Mbps rate. Later in the day when fewer phone calls are being made video can again be allowed to use its full rate.
This functionality will be critical as we begin to adopt desktop video conferencing. Most room-based video designs allocate sufficient bandwidth to run all rooms at the same time. But the usage model of desktop video will be much more like the use of telephones where we can work with the statistics and allocate less than full use bandwidth knowing that not everyone is using their desktop video systems at the same time. But of course there will be peak usage times when many folks want to be on video at the same time; the video equivalent to Mother's Day on the phone network. During these times the bandwidth manager will need to allocate bandwidth across the whole mix of video applications outlined above. My guess (and hope) is that bandwidth managers will come with lots of management options for determining the best algorithm for allocating bandwidth in your specific enterprise situation.
Bandwidth Scheduling: Lastly we need the ability to schedule future bandwidth. Consider the problem of the CEO's important telepresence call, scheduled for next Thursday at 2:00 PM. But at 1:45 a large ad hoc engineering meeting starts up to solve the latest product problem. When the CEO starts his call at 2:00 the bandwidth manager declines his call because there is insufficient bandwidth in the network available for his high bandwidth telepresence call. Heads roll.
The idea of being able to schedule future bandwidth naturally brings with it the concept of priority. So now the bandwidth manager needs to determine who has priority when there is more demand than bandwidth, and also has the ability to either downgrade call bandwidths (e.g., move existing video calls from 2 Mbps down to 1 Mbps), or kill sessions currently in progress (with a nice message to indicate what happened?)
The bandwidth manager may also want to be able to start declining calls in advance of a scheduled call to "save" some bandwidth for the scheduled call on the appropriate links.
Lots of space for innovation here I should think. And probably a hard business model since the BW manager is a kind of middleman between vendors. At least the big all-inclusive vendors who think they can solve your entire communications needs ought to have such a device.
Does it exist? We have a session at VoiceCon San Francisco in a couple of weeks where we will review the need for QoS & QoE in enterprise networks to support voice and video conferencing. Chris Lauwers, CTO of Avistar is going to talk about the bandwidth manager they have developed and how it addresses the issues above. Come by on Monday Nov. 2nd to VoiceCon and join in the discussion to see if Avistar has solved this problem and whether it will address the needs of your company.
