Network end users to pull down 2 gigabytes a day, continuously?

Sun Jan 7 13:59:21 UTC 2007

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 at btradianz.com <Michael.Dillon at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20070107/5623abdd/attachment.html>