Neutrality ain’t exactly what you may think it is, you see:
The U.S. House of Representatives recently passed legislation allowing Internet Service Providers to do traffic shaping, giving some priority to certain types of content, which would presumably be either the ISPs’ own content or that of ISP customers paying a premium for such access. The U.S. Senate is considering similar legislation, as well as other legislation designed to do exactly the opposite — guarantee that all data packets receive equal service. The prevailing assumption, by the way, is that right now all packets ARE created equal, which of course they are not.
Some pretty good detail on how the Internet actually works follows, but he gets all conspiracy-freakish at the end.
IPTV and VoIP are two examples of applications that need priority service, and there’s also that whole issue of payment. Read a lot, you’ll get a little here and a little there that sheds light on the issue, and you’ll pay for your illumination with propaganda.
I’ve been thinking a bit about IPTV and its QoS requirements lately.
In a differentiated services model of QoS where traffic is place into classes, you can find three general ways to classify the needs of applications:
EF: latency, loss, and jitter sensitive
AF: latency and loss sensitive, but not jitter sensitive
BE: loss sensitive, but not latency or jitter sensitive
VoIP is definitely EF. Most Internet applications are BE. We’re all very familiar with this. IP Video conferencing is also EF. But IPTV, while extremely loss sensitive, is not especially jitter or latency sensitive. This suggests that maybe it doesn’t deserve to sit at the same level as VoIP, but maybe lower in the tree.
Because of it’s loss sensitivity, it either needs to have quality management built in at the application layer so that it shuts off channels if bandwidth isn’t available, or the network needs to have admission control capabilities more so than the ability to prioritize, otherwise IPTV is going to kill the whole pipe as well as itself when it overdrives the broadband connection.
I’m not sure anyone’s even been thinking about it from that perspective.
I’ve done consulting with one of the major Japanese consumer electronics companies and a couple of American chip company on video streaming over wireless LANs, and a bit less on IPTV.
The thing about TV is we have two models, a live broadcast model and a stored content (TiVo) model. An in the live broadcast area, we have unicast and multicast. Multicast on the Internet was originally about video-conferencing, and I’ve done that stuff too.
The Internet needs some enhancements to handle video, in the form of a reliable multicast protocol (with local retransmits), bandwidth-on-demand, and some infrastructure work for transrating. That’s a long-term problem, and the regulations in the neutrality bills threaten it, which is the main reason I oppose them.
Stored content is pretty easy, we just have to make sure it doesn’t drown the links.
For all forms of live video, Jitter is actually more sensitive than you might think because of the synchronization issues between the audio and video tracks and the fact that deep de-jittering buffers get in the way of fast channel surfing. The specs are actually very, very tight.
People are looking at video all the way to the application layer and applying transrating (AKA transcoding) to the problem to provide resilience on wireless networks, which show some similar effects as congested Internet routes.
Multicast works great for everything but video on demand, which is typically delivered Unicast. Most implementations of Cable-esque IPTV use multicast for the normal channels, and Unicast for the VOD channels.
One thing you probably won’t see in the US is network based PVRs, for some reason it’s considered “rebroadcasting”. Feh.
The stored program model is VoD; the PVRs will be inside the home but on a local net.
Richard says:
Then maybe they need to consider changing the protocol/encoding so that the voice is encoded with the video. It’s a shame when a poorly architected design puts excessive demands on the network infrastructure when it could have been avoided.
It is not the job of multicast, a layer 3 protocol, to handle things like error checking, sequencing, and retransmits…that belongs in layer 4, similar to what TCP does for IP Unicast.
Don’t you agree?
You’re making the assumption that ISO layering is perfect, but the example of mulitcast shows that it isn’t. A large multicast tree in the TV era may reach thousands, even millions of leaves. How in the world can one source computer handle all the error-recovery actions they need?
An Intelligent Network could, of course.
Yeah, which means you need to use expensive equipment as CPE. 🙁
It would be extra cool if I could use the ISP’s Storage, and have a cheapy set top box that can talk to the network server, like you’re able to do in other countries. Obviously other folks like having locally cached content, but it would be nice to have the option… You could theoretically have your TV shows follow you everywhere:)
If you have your shows on your own in-home server, they could also follow you if you have a static IP address of the Dynamic DNS hack.