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.
Richard Bennett
· 3 years ago
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.
max
· 3 years ago
he 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 Ive done that stuff too.
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.
Richard Bennett
· 3 years ago
The stored program model is VoD; the PVRs will be inside the home but on a local net.
Dave Siegel
· 3 years ago
Richard says:
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.
Then maybe they need to consider changing the protocol/encoding so that the voice is encoded with the video. Its a shame when a poorly architected design puts excessive demands on the network infrastructure when it could have been avoided.
The Internet needs some enhancements to handle video, in the form of a reliable multicast protocol (with local retransmits),
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.
Dont you agree?
Richard Bennett
· 3 years ago
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.
max
· 3 years ago
The stored program model is VoD; the PVRs will be inside the home but on a local net.
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:)
Richard Bennett
· 3 years ago
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.
All Comments
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.
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.
Then maybe they need to consider changing the protocol/encoding so that the voice is encoded with the video. Its 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.
Dont you agree?
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:)