Sponsored By

More on the Desktop Video ChallengeMore 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. Iit seems like there is either significant development or marketing work left to be done.

John Bartlett

November 3, 2008

3 Min Read
No Jitter logo in a gray background | No Jitter

I got a number of responses to my last post on the challenges that desktop video will create for the network. Iit seems like there is either significant development or marketing work left to be done.

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.I got a number of responses to my last post on the challenges that desktop video will create for the network. Iit seems like there is either significant development or marketing work left to be done.

About the Author

John Bartlett

John Bartlett is a principal with Bartlett Consulting LLC, where he provides technical, financial, and management leadership for creation or transition of Unified Collaboration (UC) solutions for large enterprises. John discovers the challenges in each enterprise, bringing disparate company teams together to find and execute the best strategy using Agile-based methodology to support quick wins and rapid, flexible change. John offers deep technical support both in collaboration solutions and IP network design for real-time traffic with global enterprises world-wide.

 

John served for 8 years as a Sr. Director in Business Development for Professional & Managed Services at Polycom. In this role he delivered, defined and created collaboration services and worked with enterprises to help them shorten time-to-value, increase the quality and efficiency of their UC collaboration delivery and increase their collaboration ROI.

 

Before joining Polycom, John worked as an independent consultant for 15 years, assessing customer networks for support of video applications and other application performance issues. John engaged with many enterprises and vendors to analyze network performance problems, design network solutions, and support network deployments.

 

John has 37 years of experience in the semiconductor, computer and communications fields in marketing, sales, engineering, manufacturing and consulting roles. He has contributed to microprocessor, computer and network equipment design for over 40 products.