Cisco Bursty Telepresence and Overlay NetworksCisco Bursty Telepresence and Overlay Networks

Burstiness in your telepresence traffic stream is not a feature.

Last week I wrote about the tradeoff between an overlay network and a converged network for carrying telepresence or high-end video conferencing traffic. Sorrell left a comment saying that "Telepresence video networks are challenging because of their low jitter (<10ms) and high burstiness (3M to 6M)." This brings up an issue that I think has been a well-kept secret among the carriers, and that is that Cisco telepresence has a bursty profile that has been giving network operators fits. And the other video vendors don't have this problem. What is going on here?Those of you who have been following my postings know that I talk about how video and voice traffic is "well behaved" in terms of how it uses bandwidth on the IP network. Well behaved means that these applications use bandwidth in a very predictable, consistent way. A G.711 voice codec uses 85 Kbps of network bandwidth (64 Kbps of transport with 54 bytes of overhead on each packet). It never bursts more data than this. Video conferencing is not quite as constant, but it has a very level profile. A 384K video conference uses a consistent 460 Kbps of network bandwidth for the duration of the call.

But I have heard from a number of folks that this is not true of Cisco Telepresence. Two different (unnamed) WAN service providers whispered in my ear that the burstiness of Cisco Telepresence gives them real problems. I found an online white paper where they make it sound like a feature:

I think Cisco is the exception. I have not had the opportunity to capture a Cisco Telepresence trace (if you have, send me an email!). I have looked at many traces from Polycom and Tandberg endpoints, and there is no such burstiness in evidence. They have very well-behaved video streams. Why the difference?

I suspect it has to do with history and experience. The traditional video conferencing vendors come from a legacy of working with ISDN, where a fixed bandwidth was the norm. A 384K call running on a 384K ISDN circuit has exactly 384Kbps to work with and no more. So the codec designers worked hard to never exceed 384K, but at the same time to take as much advantage of the bandwidth as they could. So the compression algorithms are designed to make a dynamic tradeoff between frame rate (which translates into motion handling) and resolution, and do the best job they can with the available bandwidth.

Cisco may have decided that since their product was intended for an IP network, and an IP network can often manage bursty data, that they would not work so hard on making the codec use bandwidth smoothly, and would instead optimize the image for motion and resolution. This decision may now be causing some blowback. When you run between 10 and 20 Mbps for a single telepresence suite, the network is often configured to handle only as much bandwidth as it needs, and having to support a 50% or higher burst capability adds significant cost.

For those readers who are saying "Well, that's the difference between Telepresence and traditional video conferencing," I will point out that Tandberg, Lifesize and Polycom are all offering telepresence suites that provide the same high-end immersive experience as Cisco, using those same high bandwidth connections (about 5 Mbps per screen) but doing so with well-behaved codecs. Oh, and they are all standards compliant as well.

Burstiness in your telepresence traffic stream is not a feature.Burstiness in your telepresence traffic stream is not a feature.