Polycom and Juniper jointly announced work they are doing to connect the Polycom video conferencing infrastructure to the Juniper policy server. What does this dynamic connection between the application and the network do that supports all this marketing hype? Let's take a look.Polycom and Juniper are working on dynamic signaling between the application (video conferencing ) and the network. The key development is shown in the diagram below as the "Dynamic Signaling" occurring between the Polycom DMA and the Junos Space SRC.
This "Dynamic Signaling" is the application letting the network know that it would like to start up a high bandwidth, high priority application (a video call), and the endpoints involved in that call. The network then has the opportunity to determine if sufficient resources exist to properly support that call, and then either OKs it, or denies it. Deny the call? How does this help us?
It's all about bandwidth management. I have posted on this topic before, here and here. Bandwidth management is critical for video conferencing because video consumes a lot of bandwidth, wants to actually use all that bandwidth, and requires high priority treatment at the same time. When the demand for bandwidth is higher than the supply, a mechanism is needed to provide feedback to the application to either get it to downgrade its demands or to not initiate the next call, e.g. call-admission-control (CAC).
Up until now the primary mechanism enterprises have had for bandwidth management is the call manager or gatekeeper within the enterprise infrastructure. With this announcement, Polycom and Juniper are offering a new option, using intelligence in the service provider infrastructure for bandwidth management within the wide area network. Service providers may choose to offer this functionality as an additional value for using their network.
In turn, this may change the way enterprises do gatekeeper deployment within their own infrastructure. Previously, I have always recommended designs with a single gatekeeper so that bandwidth management can be done across the entire enterprise. However with this new BW management capability, it's now possible to deploy regional gatekeepers or campus-based gatekeepers and allow them to do local management and leave the WAN bandwidth management to the service provider. This helps with the resiliency of the design because a centralized gatekeeper has always been a single point of failure.
But there's an additional capability that's being offered here with this Polycom-Juniper connection, and that is the ability for the service provider to optimize the use of their network. The service provider can now utilize a higher percentage of their network because they can control peak usage with call admission control. This may mean that during a peak traffic time an enterprise is denied a call, even though their own bandwidth utilization maximums have not been exceeded. It will be interesting to see how that deal is negotiated.
There's another value created by this interconnection between the video conferencing infrastructure and service provider that has to do with QOS marking. Today, traffic streams have to be identified by the local area network or at least by the WAN edge router, and marked appropriately before being passed to the service provider network. With a dynamic interaction between the infrastructure and the service provider, it is now possible for the service provider to dynamically identify the specific endpoints and port values associated with high-priority video streams.
This may simplify the tricky QOS problem associated with desktop video conferencing, because the enterprise infrastructure can identify a videoconferencing stream at the application level, and pass this information to the service provider, where the service provider can dynamically mark that stream as it enters the wide area network. This solves the problem within the wide area network and on the receiving local area network, but does not solve the problem on the transmitting local area network. Nevertheless this is an interesting step in the right direction.
For the last 30 years, we have taken the approach that we supply some amount of bandwidth between endpoints, and the applications have to fit into that bandwidth. If it gets crowded in there, things slow down a bit, but no one is excluded. Because these applications have been predominantly data applications, this approach has worked fine.
But if we look across the fence at the PSTN, we see that traditional voice communications has taken a different approach. For voice we always allocated a fixed amount of bandwidth across the network to support the call (64 Kbps) and the network checked to make sure it was free, available, and dedicated to this call. If the bandwidth was not available, the network delivers the bad news in the form of a trunk-busy signal.
Video conferencing has characteristics that fall somewhere in between. A video conferencing call can run at a lower bandwidth, but video quality and motion handling suffer. Enterprises may be willing to allow some classes of video to be forced down in bandwidth (e.g. desktop video) while wanting others (e.g. Telepresence) to maintain full rate. To really make this work well, we need communications in both directions between the network and the application. The application requests the bandwidth it needs, and the network tells it how much it can have. And the network may downgrade bandwidth availability in the middle of a call as network demand increases.
It will be critically important in this kind of environment to have good reporting tools so both the service provider and enterprise can understand how often they are getting full rate and how often calls are being run at a lower rate. Correlation between network conditions and video conferencing (application) information will be critical to understanding if it is time for upgrades or policy changes to better optimize the environment or the ROI.
