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

Bob,

Let’s come back to the real world. Here are the facts.

P2P (even 10% of capacity) induces massive jitter on the order of 50 milliseconds to 1000+ milliseconds on the broadband segment. Based on my tests, higher P2P utilization causes more frequent spikes in packet delay and lower P2P utilization causes lower frequency but often the same amplitude in delay which is still very problematic. This makes gaming, VoIP, IPTV, video conferencing, or any other isochronous real-time application unbearable.

We can use jitter adaptation techniques on VoIP and video conferencing to minimize packet discards, but it is severely limited in how much jitter it can mitigate and there are tradeoffs even when the jitter adaptation works. If you adapt the buffer to 200 milliseconds just for the occasional spike in packet delay due to jitter, you’re causing the base latency to rise 200 milliseconds which gets tacked on to the 20 ms packetization delay and the network latency which could be as high as 200 ms when doing intercontinental calls. 400 ms lag time between the time you say something and the time you hear something back is not a desirable way to make a phone call. Now what happens when the jitter goes up to 1000+ ms? Are you going to jack up the base latency 1000 milliseconds or just discard those packets? I suppose you could, but that wouldn’t be what people expect from a phone call, their television service, their video call, their online game. I don’t want to just “absorb” the jitter. I can, but I won’t. We’re not talking about playing online chess where the delay could be one minute long for all I care; we’re talking about a game of human reaction times to see who can virtually kill their opponent.

Now the solution is to simply fix it in the network with multiple transmit queues or we can insist on the end-to-end dumb pipe dogma (not to be confused with the end-to-end arguments) and give people a crappy experience. As someone who uses P2P, VoIP, video communications, and online gaming, I prefer using the intelligent network to make the network more efficient. Without it, I and everyone else I know simply shut P2P off during the day which ultimately harms the health of P2P because I’m no longer seeding. I’d rather not make idiotic compromises by insisting on a dumb network to satisfy someone’s delusional concept of what the Internet is supposed to be.

George Ou

From: nnsquad-bounces+george_ou=lanarchitect.net@nnsquad.org [mailto:nnsquad-bounces+george_ou=lanarchitect.net@nnsquad.org] On Behalf Of Bob Frankston
Sent: Sunday, October 04, 2009 8:42 AM
To: nnsquad@nnsquad.org
Cc: 'ip'
Subject: [ 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.