[94033] in North American Network Operators' Group
Re: Network end users to pull down 2 gigabytes a day, continuously?
daemon@ATHENA.MIT.EDU (Alexander Harrowell)
Sun Jan 7 09:06:28 2007
Date: Sun, 7 Jan 2007 13:59:21 +0000
From: "Alexander Harrowell" <a.harrowell@gmail.com>
To: "Michael.Dillon@btradianz.com" <Michael.Dillon@btradianz.com>
Cc: nanog@merit.edu
In-Reply-To: <OF54E911CF.7BA5C3F3-ON8025725C.0048E39A-8025725C.00491AE5@btradianz.com>
Errors-To: owner-nanog@merit.edu
------=_Part_37800_29287543.1168178361696
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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
>
>
------=_Part_37800_29287543.1168178361696
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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:<br><br>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.
<br><br>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.<br><br>3) That means either a big centralised server we own, or another big radio network we own.
<br><br>4)....<br><br>5) PROFIT!!<br><br>The unexamined assumptions are of course that:<br><br>1) Streaming is vital.<br><br>2) By definition, just doing it in TCP/IP must mean naive unicasting.<br><br>3) Only telco control can provide quality.
<br><br>4) Mobile data latency is always and everywhere a radio issue.<br><br>Critique:<br><br>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?*
<br><br>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!*<br><br>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...*
<br><br><div><span class="gmail_quote">On 1/7/07, <b class="gmail_sendername"><a href="mailto:Michael.Dillon@btradianz.com">Michael.Dillon@btradianz.com</a></b> <<a href="mailto:Michael.Dillon@btradianz.com">Michael.Dillon@btradianz.com
</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>> > That might be worse for download operators, because people may
<br>> > download<br>> > an hour of video, and only watch 5 minutes :/<br><br>> So, from that standpoint, making a video file available for download<br>> is wasting order of 90% of the bandwidth used<br>> to download it.
<br><br>Considering that this is supposed to be a technically<br>oriented list, I am shocked at the level of ignorance<br>of networking technology displayed here.<br><br>Have folks never heard of content-delivery networks,
<br>Akamai, P2P, BitTorrent, EMule?<br><br>--Michael Dillon<br><br></blockquote></div><br>
------=_Part_37800_29287543.1168178361696--
