When it comes to video, the network ain't so great afterall.
And the attempts to make it great that we have been hearing about, maybe even trying to use, for the last three or four years, haven't worked. How else to explain the email I just received?
It is an invitation to a seminar from a major video conferencing equipment vendor and I do mean major. (No naming names, now. Let’s not go there.) This vendor has partnered with a network monitor-and-measure system vendor because, and I quote, “IT departments are striving to improve the quality of their existing video conferencing and telepresence deployments” and this network monitor-and-measure system vendor offers ways of showing you where the network ain't so great for video.
But wait a minute... I thought the major video conferencing system vendors had built-in ways to fix network problems. Have I been mis-lead?
No, no. Of course not. It's just that those built-in ways are or were the products of old thinking that was thought to be “okay” back in the day but not anymore. The old built-in ways do things like downspeeding--they reduce frame rate and resolution in order to reduce the bandwidth requirements on the assumption that the problem is the available pipe. (It's not, actually, or at least not anymore. In most of today’s video conferencing system and telepresence systems deployments, there's plenty of cheap and cheerful bandwidth. The problem is not the amount of bandwidth but the poor quality of the Internet.) Needless to say, reacting to poor network quality by downspeeding is not only a little bit silly, it is no longer unacceptable. When you buy a 720/30 or 1080/60 capable system it's because you want video conferences at that resolution and that speed. You want your HD. I know I do.
The other thing that the old built-in ways do is pile on the legacy Forward Error Correction (FEC): block encoding FEC that adds latency. In video conferencing as in any real-time two-way communications, latency is not good. Have you ever been frustrated in your attempts to make your point because your audience is talking at the same time? That’s what latency does for video conferencing and people won't stand for it. The video conferencing system gets pushed in to the corner of the board room.
What is becoming increasingly clear is that the old built-in ways don't work and even if you implement the same thing in a different way, and give it new name, sending less information (whether frames or layers or whatever) more slowly is not what anybody is looking for in these modern times.
Here's an observation that seems useful: the old built-in ways are application level attempts to conceal, avoid, run away from network quality problems but the problem is a network problem, not an application problem. In fairness, there wasn’t much choice back in the day. The video conferencing guys had to try to do something to fix the problem. Today, though, we know better, and that could be the reason that this un-named major video conferencing system vendor is partnering with a network monitor-and-measure system vendor, i.e., with the people who know the network. Is this finally an admission that network problems are best solved at the network level and not at the application level? Works for me.
Of course, monitoring and measuring an IP video network can point out where things are broken but that's just the beginning. That's when the heavy lifting starts. And if the broken network is the Internet? How ya gonna fix that?
You know what comes next, right? Sure you do, and like I said, I don't name names but when it comes to optimizing the Internet for video, the initials to know are IPQ (TM).
