In the mobile world, there is a lot of telco-led activity around providing streaming video ("TV"), which always seems to boil down to the following points:
1) Just unicasting it over the radio access network is going to use a lot of capacity, and latency will make streaming good quality tough.
2) Therefore, it has to be delivered in some sort of defined-QOS fashion or else over a dedicated, broadcast or one-way only radio link.
3) That means either a big centralised server we own, or another big radio network we own.
4)....
5) PROFIT!!
The unexamined assumptions are of course that:
1) Streaming is vital.
2) By definition, just doing it in TCP/IP must mean naive unicasting.
3) Only telco control can provide quality.
4) Mobile data latency is always and everywhere a radio issue.
Critique:
Why would you want to stream when you can download? *Because letting them download it means they can watch it again, share it with their friends, edit it perhaps?*
Why would you want to stream in unicast when there are already models for effective multicast content delivery (see Michael's list)? *See point above!*
In my own limited experience with UMTS IP service, it struck me that the biggest source of latency was the wait for DNS resolution, a highly soluble problem with methods known to us all. *But if it's inherent in mobility itself, then only our solutions can fix it...*
On 1/7/07, Michael.Dillon@btradianz.com <Michael.Dillon@btradianz.com
> wrote:
> > That might be worse for download operators, because people may
> > download
> > an hour of video, and only watch 5 minutes :/
> So, from that standpoint, making a video file available for download
> is wasting order of 90% of the bandwidth used
> to download it.
Considering that this is supposed to be a technically
oriented list, I am shocked at the level of ignorance
of networking technology displayed here.
Have folks never heard of content-delivery networks,
Akamai, P2P, BitTorrent, EMule?
--Michael Dillon