No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

More on the Desktop Video Challenge

I got a number of responses to my last post on the challenges that desktop video will create for the network, some from the vendors telling us how all this will work just fine, one from an enterprise who had a very poor experience and one from an enterprise explaining why existing solutions won't address the real need. So it seems like there is either significant development or marketing work left to be done.First, looking at the bandwidth issue, one of the vendors suggests that the management systems allow call bandwidth to be limited, and limit calls to within a building or campus. I agree that limiting call bandwidth is useful, especially for desktop video where the small image size should not require a high bandwidth transport. Limiting video to the building or campus, however, seems defeating. Its like limiting air travel to be within the state (and I live in New England where the states are very small.) There are many other options for having a meeting within the building or campus. Video is most useful when the distance or difficulty of travel is high. So this is the video that really should be supported.

Another point made in the comments is that not all the desktop users will be using their video at the same time. I have seen published articles that suggest desktop video utilization will be much more like telephone calls where we can estmate load based on Erlangs, which account both for utilization and for the duration of calls. While I agree that desktop video may be used somewhat differently than conference room video, I don't think it will look like telephony. We will still be having meetings. And we will tend to have meetings at the same time of day for certain geographical connections (morning for US to Europe, evening for US to APAC, etc.) So the concurrent demand on the WAN may be much higher than Erlangs would predict.

Many of my customers also expect video to support a one-to-many type of configuration so that the boss can hold an all-hands meeting. This configuration will create a high demand, perhaps aiming for all desktops to participate simultaneously. There we are back at the peak bandwidth number. Perhaps desktop video will be the application that finally convinces enterprises to enable multicast addressing so that the total network bandwidth can be kept manageable.

Another challenge of desktop video is the demands it places on the desktop itself. Some vendors are talking about HD capability on the desktop. I know that the room-based conferencing systems have multiple dedicated signal processing engines running full tilt to generate and decode HD images. On the desktop this compute power has to come out of the PC's CPU. So you have to know your PC will be taxed when video is running and the rest of those apps will slow down. Maybe as Intel adds more CPU cores to the computer we will have enough power so that we won't care, but it hasn't happened yet.

But the key network issue I raised in my last post was the challenge of properly classifying the video traffic from the desktop. This is still an open issue in my mind, and I have not seen any good scaleable solutions yet. We may need to get Microsoft involved in this one, and then who knows what direction it will take?

We are going to be wrestling with many of these issues at my tutorial on Monday afternoon at VoiceCon in San Francisco next week, so come on over and throw your opinion into the mix.