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

Mailman List Mirror (Read Only)
1

A remark and a question:

1. 2 GB/day per user would indeed require tossing everyone's CURRENT
baseline network usage metrics out the window, IF IT WERE TO BE ACHIEVED
INSTANTANEOUSLY. The key question is, how quickly and widely will this
application spread?

Back in 1997, when I first started collecting Internet usage statistics,
there were concerns that pre-fetching applications like WebWhacker (anyone
remember that?) would lead to a collapse of networks and business plans.
With flat rate dial access, staying connected for 24 hours per day would
have (i) exhausted the modem pools, which were built on a 5-10 oversubscription
ratio, and (ii) broken the aggregation and backbone networks, generating
about 240 MB/day or traffic per subscriber (on a 19.2 Kbps modem, about
standard then). But the average user was online just 1 hour per day, and
download traffic was about 2 Kbps during that hour, leading to about 1 MB/day
of traffic, and the world did not come to a halt. (And yes, I am suppressing
some details, such as ISPs TOSs forbidding applications like WebWhacker, and
technical measures to keep them limited.)

Today, download rates per broadband subscriber range (among the few industrialized
countries for which I have data or at least decent estimates) from about 60 MB in
Australia to 1 GB in Hong Kong. So 2 GB/day is not that far out of range for
Hong Kong (or South Korea) even today. And in a few years (which is what you
always have to allow for, even Napster and Skype did not take over the world
in the proverbial "Internet time" of 8 months or less), other places might
catch up.

2. The question I don't understand is, why stream? In these days, when a
terabyte disk for consumer PCs is about to be introduced, why bother with
streaming? It is so much simpler to download (at faster than real-time rates,
if possible), and play it back.

Andrew

  Note that 220 MB per hour (ugly units) is 489 Kbps, slightly less =20
  than our current usage.

  > The more popular the content is, the more sources it can be pulled =20
  > from
  > and the less redundant data we send, and that number can be as low as
  > 220MB per hour viewed. (Actually, I find this a tough thing to explain
  > to people in general; it's really counterintuitive to see that more
  > peers =3D=3D less bandwidth - I'm still searching for a useful =
  user-facing
  > metaphor, anyone got any ideas?).

  Why not just say, the more peers, the more efficient it becomes as it =20=

  approaches the
  bandwidth floor set by the chosen streaming ?

  Regards
  Marshall

  >
  >>> If this application takes off, I have to presume that everyone's
  >>> baseline network usage metrics can be tossed out the window...
  >
  > That's a strong possibility :slight_smile:
  >
  > I'm currently the network person for The Venice Project, and busy
  > building out our network, but also involved in the design and planning
  > work and a bunch of other things.
  >
  > I'll try and answer any questions I can, I may be a little =20
  > restricted in
  > revealing details of forthcoming developments and so on, so please
  > forgive me if there's later something I can't answer, but for now I'll
  > try and answer any of the technicalities. Our philosophy is to pretty
  > open about how we work and what we do.
  >
  > We're actually working on more general purpose explanations of all =20
  > this,
  > which we'll be putting on-line soon. I'm not from our PR dept, or a
  > spokesperson, just a long-time NANOG reader and ocasional poster
  > answering technical stuff here, so please don't just post the archive
  > link to digg/slashdot or whatever.
  >
  > The Venice Project will affect network operators and we're working =20
  > on a
  > range of different things which may help out there. We've designed =20=

  > our
  > traffic to be easily categorisable (I wish we could mark a DSCP, =20
  > but the
  > levels of access needed on some platforms are just too restrictive) =20=

  > and
  > we know how the real internet works. Already we have aggregate per-AS
  > usage statistics, and have some primitive network proximity =20
  > clustering.
  > AS-level clustering is planned.
  >
  > This will reduce transit costs, but there's not much we can do for =20
  > other
  > infrastructural, L2 or last-mile costs. We're L3 and above only.
  > Additionally, we predict a healthy chunk of usage will go to our "Long
  > tail servers", which are explained a bit here;
  >
  > http://www.vipeers.com/vipeers/2007/01/venice_project_.html
  >
  > and in the next 6 months or so, we hope to turn up at IX's and arrange
  > private peerings to defray the transit cost of that traffic too.
  > Right now, our main transit provider is BT (AS5400) who are at some
  > well-known IX's.
  >
  >> Interesting. Why does it send so much data?
  >
  > It's full-screen TV-quality video :slight_smile: After adding all the overhead =20=

  > for
  > p2p protocol and stream resilience we still only use a maximum of =20
  > 320MB
  > per viewing hour.
  >
  > The more popular the content is, the more sources it can be pulled =20
  > from
  > and the less redundant data we send, and that number can be as low as
  > 220MB per hour viewed. (Actually, I find this a tough thing to explain
  > to people in general; it's really counterintuitive to see that more
  > peers =3D=3D less bandwidth - I'm still searching for a useful =
  user-facing

2

2. The question I don't understand is, why stream?

There are other good reasons, but fundamentally; because of live
telivision.

In these days, when a terabyte disk for consumer PCs is about to be
introduced, why bother with streaming? It is so much simpler to
download (at faster than real-time rates, if possible), and play it
back.

That might be worse for download operators, because people may download
an hour of video, and only watch 5 minutes :confused:

3

Dear Andrew;

A remark and a question:

<snip>

2. The question I don't understand is, why stream? In these days, when a
terabyte disk for consumer PCs is about to be introduced, why bother with
streaming? It is so much simpler to download (at faster than real-time rates,
if possible), and play it back.

I can answer that very simply for myself : We are now making a profit with streaming from advertising.

To answer what I suspect is your deeper question : Broadcast is a push model, and will
not go away. If fact, I think that the Internet will revitalize the "long tail" in video content, and
broadcast will be a crucial part of that. It, after all, has been making more for over a century now.
Download appears to be very similar, but is really not the same business model at all IMHO.
Doesn't mean it's bad or worse, it may even be better, but it's different.
And as long as you can make a profit from broadcasting / streaming...

Andrew

Regards
Marshall

4

.. right until the ISP says "Oi, you changed my business model, you
cough up the money to do so please, or the customer 'gets it'."

Where have I heard companies wishing to do that before..

Adrian

5

2. The question I don't understand is, why stream?

There are other good reasons, but fundamentally; because of live
telivision.

In these days, when a terabyte disk for consumer PCs is about to be
introduced, why bother with streaming? It is so much simpler to
download (at faster than real-time rates, if possible), and play it
back.

That might be worse for download operators, because people may download
an hour of video, and only watch 5 minutes :confused:

Our logs show that, for every 100 people who start to watch a stream, only 2 or 5 % watch over
30 minutes in one sitting, even for VOD where they presumably have some interest in the movie up front, and
more more than 9% will watch all of VOD movie, even over multiple viewings. This is also very consistent
with time, but I don't have any pretty plots handy. (Our cumulative audience in 2006 was 2.74 million people, I have lots of statistics.)

So, from that standpoint, making a video file available for download is wasting order of 90% of the bandwidth used
to download it.

Regards
Marshall

6

2. The question I don't understand is, why stream? In these days, when

a

terabyte disk for consumer PCs is about to be introduced, why bother

with

streaming? It is so much simpler to download (at faster than real-time

rates,

if possible), and play it back.

Very good question. The fact is that people have
been doing Internet TV without streaming for years
now. That's why P2P networks use so much bandwidth.
I've used it myself to download Russian TV shows
that are not otherwise available here in England.
Of course the P2P folks aren't just dumping raw DVB
MPEG-2 streams onto the network. They are recompressing
them using more advanced codecs so that they do not
consume unreasonable amounts of bandwidth.

Don't focus on the Venice project. They are just one
of many groups trying to figure out how to make TV
work on the Internet. Consumer ISPs need to do a better
job of communicating to their customers the existence
of GB/month bandwidth caps, the reason for the caps,
how video over IP creates problems, and how to avoid
those problems by using Video services which support
high-compression codecs. If it is DVB, MPEG-2 or MPEG-1
then it is BAD. Stay away.

Look for DIVX, MP4 etc.

Note that video caching systems like P2P networks can
potentially serve video to extremely large numbers of
users while consuming reasonably low levels of upstream
bandwidth. The key is in the caching. One copy of BBC's
Jan 8th evening news is downloaded to your local P2P
network consuming upstream bandwidth. Then local users
use local bandwidth to get copies of that broadcast over
the next few days.

For this to work, you need P2P software whose algorithms
are geared to conserving upstream bandwidth. To date, the
software developers do not work in cooperation with ISPs
and therefore the P2P software is not as ISP-friendly as
it could be. ISPs could change this by contacting P2P
developers. One group that is experimenting with better
algorithms is http://bittyrant.cs.washington.edu/

--Michael Dillon

7

> That might be worse for download operators, because people may
> download
> an hour of video, and only watch 5 minutes :confused:

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

8

Dear Michael;

That might be worse for download operators, because people may
download
an hour of video, and only watch 5 minutes :confused:

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?

Most of the video sites I know of in detail or have researched
do not use Akamai or other local caching services. (Youtube uses Limelight for delivery, for example, as AFAIKT they do no caching outside of that network. Certainly, the Youtube video
I have looked at here through tcpdump and traceroute seems to transit the network.)
And P2P services like BitTorrent do not conserve network bandwidth. (Although, they might in the future.)

What does save network bandwidth is progressive download; if people actually look at what they downloading,
they may stop it in progress if they don't want it. (I know I do.)

--Michael Dillon

Regards
Marshall

9

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)…

  1. 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…

10

Dear Alexander;

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:

We (AmericaFree.TV) simulcast everything in 3GPP and 3GPP2 at a lower bit rate for mobiles.
At present, the mobile audience for our video is

- 0.3% of the total for the last month
- doubling every 2 months or less.

It's not clear if this glass is mostly empty or half full, but there is a data point FWIW.

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!!

I have heard that several big mobile providers are shortly going to come out with 802.16 networks in support (I
assume) of point 3.

Regards
Marshall

11

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!*

The word "multicast" in the above quote, does not refer
to the set of protocols called "IP multicast". Content
delivery networks (CDNs) like Akamai are also, inherently,
a form of multicasting. So are P2P networks like BitTorrent
and EMule. If this sounds odd to you, perhaps you don't really
understand the basics of either multicast or P2P. Check out
Wikipedia to see what I mean:

If your data absolutely, positively, must be delivered
simultaneously to multiple destinations, i.e. time is
of the essence, then I agree that P2P and IP multicast
are not comparable. But the context of this discussion
is not NYSE market data feeds, but entertainment video.
The use-cases for entertainment mean that timing is
of little importance. More important are things like
consistency and control.

--Michael Dillon

12

Michael Dillon said:

The word “multicast” in the above quote, does not refer
to the set of protocols called “IP multicast”. Content
delivery networks (CDNs) like Akamai are also, inherently,
a form of multicasting. So are P2P networks like BitTorrent
and EMule.

That’s precisely what I mean.

Marshall Eubanks said: I have heard that several big mobile providers are shortly going to
come out with 802.16 networks in support (I
assume) of point 3

I don’t know whether Sprint Nextel’s big 802.16e deployment is going to be used for this, although their keenness on video/TV argues for it. A wide range of technologies are in prospect, including DMB, DAB-IP, DVB-H, Qualcomm’s MediaFLO and IPWireless’s TDTV.

These are radio broadcast systems of various kinds - MediaFLO and TDTV are adaptations of 3G mobile technologies, from the CDMA2000 world and UMTS respectively. TDTV, the one I am most familiar with, is essentially a UMTS-TDD network with all the timeslots set to send (from the base station’s viewpoint). 3GPP and 3GPP2 are standardising a Multimedia Broadcast-Multicast Subsystem as an add-on to the R99 core network, expected in 2008.

From an IP perspective, most of these are fairly orthogonal, being essentially alternative access networks on the other side of the MBMS control function.

13

I'm confused why high latency makes "streaming good quality tough"?

Perhaps this goes back to the "streaming" vs. "downloading" problem, but every player I've ever seen on a personal computer buffers the content for at least a second, and usually multiple seconds. Latency is measured in, at most, 10th of a second, and jitter another order of magnitude less at least.

High latency links with stable throughput are much better for streaming than low latency links with any packet loss, even without buffering.

IOW: Latency is irrelevant.

14

Yes, on reflection that should also have been filed under “unexamined assumptions.”

15

That's because most of these people are watching the stream
on their computer (Mac or PC).

Bring that box to the living room in an attractive package and
the stats will be very different.

16

This isn't part of the same project, but I suspect this will more or
less bring a video stream from a Slingbox (in the other room or
halfway around the earth) to the living room:

http://www.zatznotfunny.com/2007-01/slingcatcher-is-real/

Regards,
Al Iverson

17

I'm working on it.

18

Bring that box to the living room in an attractive package and
the stats will be very different.

This kind of box is very popular in England. It
is called a digital TV receiver and it receives
MPEG-2 streams broadcast freely over the airwaves.
Some people, myself included, have a receiver that
with a hard disk that allows pausing live TV and
scheduling recording from the electronic program
guide which is part of the broadcast stream.

Given that the broadcast model for streaming content
is so successful, why would you want to use the
Internet for it? What is the benefit?

--Michael Dillon

19

How many channels can you get on your (terrestrial) broadcast receiver?

If you want more, your choices are satellite or cable. To get cable, you
need to be in a cable area. To get satellite, you need to stick a dish on
the side of your house, which you may not want to do, or may not be allowed
to do.

With IPTV, you just need a phoneline (and be close enough to the exchange/CO
to get decent xDSL rate). In the UK, I'm already delivering 40+ channels over
IPTV (over inter-provider multicast, to any UK ISP that wants it).

Simon

20

Simon

An additional point to consider is that it takes a lot of effort and
$$$$ to get a channel allocated to your content in a cable network.

This is much easier when TV is being distributed over the Internet.