More Bandwidth ManagementMore Bandwidth Management

At the end of my last post I mentioned that there were some issues with bandwidth management that make it more complex than my simple explanation would lead you to believe. Rich wrote in and pointed out the issue of VPN's encrypting the QoS tags, just one of the issues to be overcome.

At the end of my last post I mentioned that there were some issues with bandwidth management that make it more complex than my simple explanation would lead you to believe. Rich wrote in and pointed out the issue of VPN's encrypting the QoS tags, just one of the issues to be overcome.Bandwidth management is not well integrated into our network infrastructure yet. One of the results of poor integration is the same information being stored in multiple places. I recently worked with a client using VoIP and found that the IP-PBX was allowing too many calls to be placed across the WAN for the bandwidth that was allocated. The customer told me that they had received too many trunk busy signals, so they raised the limit in the PBX. The problem was that there were two places that this information was stored, in the PBX and in the router QoS configuration. Just increasing the number of calls that the PBX allowed did not increase the bandwidth allocated by the routers. Perhaps in the future we will have tools that cross check these items, or allow us to store the information in one place and have it manage both the call volume and the traffic flow limits.

A second set of problems arises when we look at the topology of the network over time. Today's IP-PBXs and video gatekeepers make bandwidth decisions about links by having an internal map of the network topology, and thus knowing that a call from point A to point B will cross links X and Y. This network topology is statically configured into the device. Unfortunately, the network topology may not be so static. Network changes and network link failures both change the characteristics of the network. When these occur, the IP-PBX or gatekeeper is out of date; making decisions with a topology that no longer is correct. Perhaps in the future we will have more integration between the application's view of topology and the routing layer of the network.

This model of limiting calls to the available bandwidth introduces another problem, especically in video conferencing. With the IP-PBX and gatekeeper models described in my previous post, when the call that will exceed available bandwidth is placed the call is given a busy signal and denied. In telephony we are used to this result and we use another method or try again in a few minutes. Or perhaps the PBX routes the call over the PSTN.

For video conferencing calls this may not be possible. For a standard definition 384K call, the enterprise may have ISDN capabilities in place and may be able to reroute the call over the PSTN in a similar way. But for HD calls at 2 Mbps or 4 Mbps, the PSTN is not an option. So consider the video conferencing call (really a meeting) that has been scheduled for 2 weeks with important players in 3 parts of the globe gathering for an important decision. When the call is dialed, the network says 'I'm too busy, please try later'. This is probably not an acceptable mode of operation.

So now we need a bandwidth management system that knows about future requirements and is able to schedule bandwidth needs. Such a system must be connected to the scheduling service, the application and the network. And it needs some clever and diplomatic ways of managing the conflicts when they arise so that users get the best service possible with the limited resources available. There is a challenging piece of communications infrastructure design!