[ NNSquad ] The myth of isochronous and the risk of baking-in the past

We keep getting told that P2P traffic interferes with isochronous IPTV.

Why this concern with isochronous (and its cousin QoS)? It misses the point of the Internet which is about learning to take advantage of opportunity. Isochronous was an issue in the early days of analog signaling when we had systems that barely worked and there wasn’t even the concept of buffering.

Today if you switch between an SD and an HD stream (AKA channel) on a cable system you’ll notice many seconds of difference between the two – we don’t really care. We also have the infamous “7-second” delay in US which is scared of dirty words.

So why not just have a buffer to absorb any jitter? In face now we have now protocols like SVC that are adaptive and will adjust the number of bits needed depending upon the capacity available so that you can fill the buffer and/or show more content or apply whatever clever approaches you are thinking of.

I notice that if I turn away from a stream on my Verizon FiOS connection and go back to it after a short time it will catch-up from where I left off! Clever – I presume it uses a simple algorithm to speed up the stream without any perceptual difference. Such techniques are not uncommon – you don’t notice them.

You’d think isochronous would be vital in sports but the US did fine with a 12 hour buffer when the Olympics was held in Sydney. We don’t depend on millisecond timing for watching sports – you don’t notice existing compression delays.

I argue that isochronous (and QoS) killed IEEE-1394 (AKA Firewire) by restricting it’s reach and over-defining the solution. It didn’t help that it was a silo with application protocols included. IEEE-1394 may be a good example of risk in the attitude that we know what the applications are and should bake them into the network.

The focus on Isochronous IPTV is problematic. It posits that we must design networks within the limitations of television circa 1940. It also presumes that the purpose of the network is television. As I explain in http://rmf.vc/?n=IAC that attitude is simply an artifact of the fact we discovered that if you repurpose a video distribution network you find it’s good for video distribution.

Instead we need to recognize that video distribution can be very tolerant of network behavior. With a little buffering we can stream in real time but as network capacity increases we can send the data faster than real time and have an arbitrary amount of buffering available. There are many ways to make video available depending on what tradeoffs you choose to make. As drive capacity goes to terabytes buffering becomes the norm. In fact, FiOS seems to buffer content “just in case” on their DVRs.

The best way to make this process fail is to fixate on isochronous and bake the past into the network architecture. Alas, just as we discovered that if you repurpose a broadcast network you find video distribution is its purpose – if you repurpose companies whose business is selling video distribution you get the misguided notion that the purpose of a network provider is to provide the same old services.

Let’s not forget video is just another app – it works better with more speed but if we restrict ourselves to video we won’t get other vital services.

Time to move on from network services to creating opportunity.