Video on Demand over TCP and Jitter

A recent question to me from a "born back bencher" eavesdropping on the end-to-end groups musings asked "...how they can even believe they can accomplish a good result with TCP for VOD [Video On Demand]? Yeah they gave me good on SACK and NACK and no matter how many RFCs and drafts they quote, which I have never read, the logic still seems obtuse if the window is end to end". Actually, this isn't a silly question - it's a good one in that we need to examine our environment and definitions carefully and has a lot of richness. Just what a physicist loves!

VOD isn't just TCP, although end-to-end quality is very much based on how the customer perceives the stream (if you're truly streaming). If you're transiting through wireless, all bets are off - no one does good work in this area (yet) as I discuss in Buffer, Buffer, Where is the Buffer? on Byte.

But to get to the gestalt, in a video quality study I conducted several years ago we found you had to deal with VOD at several levels, from production of video for the Internet to TCP streaming optimization - in this case we used InterProphet's SiliconTCP here at the datacenter as well as client end (see SiliconTCP, EtherSAN, and Scalability). It's really the big pipe / little pipe problem at the customer end that's the bigger issue here - but we're now in Internet infrastructure land, and that's a hard-fought area. But in all cases, jitter is the key!

Why jitter for video? Well, the answer falls out of some work we did on making very small packets (ATM cell-like) work as efficiently as ATM with better cost-benefits for telecom. Turns out true VOD demands are equally significant. Of course, now we get to some interesting crossroads, such as whether you are concerned about quality and VOD over TCP because you are trying to stream videos for sale as a content provider? Or are you wanting to develop a video distribution business? Or are you trying to develop the Internet infrastructure necessary for the performance and outcompete the Cisco's of the world? They're really very different businesses, and have different cost structures. Now it's what you're willing to pay for.

Do not fall back on the chimera of UDP as an "easier solution". Everyone likes to fall back to creating their own layer4 on top of layer3. They don't rely on the scaling of what's already in place on the network to gracefully handle TCP, so they lose scalability. To buy back some of that scalability deficit, they often try to do a "more efficient" job by cutting out key elements of TCP (such as checksumming and windowing), only to find it works inefficiently and breaks for others. As Rocky says to Bullwinkle "That trick never works". TCP has been shown to be superior as a VOD protocol going head-to-head with UDP for many years. It's an old argument that never panned out.

So if TCP is really is good enough as a protocol, why do we have problems with VOD. It's not the protocol itself - it's the complexity that magnifies the problem. The Internet isn't just two tin cans and a string - it's a interconnected network of networks. To maintain end-to-end semantics, one has to find a way so that the semantics are preserved throughout the sytem. Simplistically, this means we only crack, assemble, and checksum at the end-points. We've always done this.

However, we could use the same mechanism throughout the Internet itself, using a form of divide and conquer. In this manner, we view the Internet today as if it was composed of smaller portions, each independently solved, so the problem of jitter, complexity, and overhead is mitigated. In other words, we're back to scaling, and high to low capacity at the edge causes the congestion.

But why is production important if we're talking about jitter? In both video and audio, if you're doing near realtime (so to speak) the problems are easily seen by the end viewer, but the problems induced by this can't be easily remedied. That's why production is so important as the first step if you're a content provider. You've got that much control in terms of tech - understanding your QOS and end-to-end quality issues, you can produce to mitigate some of these issues. The actual bigger problem of Internet jitter is the second step of control. This is much harder - you can control how you produce a video piece for the Internet, but you can't control the Internet itself.

If you're doing video downloads as a content provider, but don't control the end-to-end distribution (e.g. you use colo and service providers and proxies), there are also good mitigation strategies as well on the edge, but the problem here isn't really technical (it's pretty straightforward) - the problem is the bizdev deals to handle the edge. But that's not really worrying about the protocol. My husband William Jolitz worked at Tandem with the earlier VOD biz deals (dealt with the Hollywood studio crowd) - so I learned about what *not* to do as well as what's needed. VOD isn't new. :-)

So the question really is - what is your goal? Reliable video streaming? Reliable wireless video streaming? Unreliable video downloading / offloading from a central site? Centralized versus distributed video vault / synchronization / integrity issues? They really run the gamut here. And they are all interesting.