North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: cost of doing business

  • From: Thomas Kernen
  • Date: Tue Apr 19 09:50:15 2005


Hi Marshall,

Thanks for the links and papers, actually I didn't want to expand into Zipf's law on NANOG, I felt it would be a little OT for most people.
In parallel to the "multicast patching" I mentioned before I'm also indirectly involved in the design of a P2P distribution model using the customers STB hard drive as part of the content source, ie: if you request a VOD content that other users connected to the same POP (or whatever your metric is) those STBs will be potential sources for providing the content to the end user who just requested it.

I personally don't feel this is the way to go based on the current discussions with content owners who seem to prefer models where they don't have to trust the end user's STB since in the short/medium/long run this can't be considered a secure device (too many students with too much time) and therefore would like everything to be sourced from the SP's network or even better from their infrastructure, in the same way this is done with inter-domain multicast for live TV content from those same content providers.

Thomas

----- Original Message ----- From: "Marshall Eubanks" <[email protected]>
To: "Thomas Kernen" <[email protected]>; "Mike Macdonald" <[email protected]>; <[email protected]>; "Andrew Odlyzko" <[email protected]>
Sent: Tuesday, April 19, 2005 3:28 PM
Subject: Re: cost of doing business


Hello;

May be off topic, especially if you do not care about the statistics of content distribution.

On Tue, 19 Apr 2005 07:59:00 +0200
"Thomas Kernen" <[email protected]> wrote:
RE: cost of doing business
That will not be the biggest issue since most of it is live TV hence multicast so that stream
will be used by another customer anyway connected to the same customer termination device in the
POP. Of course that will also be depended on the port density of the customer termination device.

To a point (see below)
The real issue is VOD since each stream is a unicast stream per customer and that currently there
is no valid implementation that allows one to actually reuse some of that unicast stream content
to deliver to other users. Since most VOD is currently on a pay per view model customers should
not be actually requesting those streams if not watching them, so for some time that will allow a
certain "limitation" in the usage.

Related to VOD and bandwidth usage there is some research carried out around the world to solve
this issue and one of these solutions might be the "multicast patching", from what I've seen
there is still a lot of work to be done before it can comply with an SP's network setup. The
other unknown factor is that until now the customer has never had the choice of viewing what he
wants when he wants so AFAIK there is no statistical model that exists in the video media field
that allows to derive a mathematical model related to VOD consumption.

There has been a lot of work on this - as far back as 1994 Ann Chervenak
analyzed results from a video on demand system for her PhD thesis

http://www.isi.edu/~annc/papers/ChervenakThesisNov94.ps.Z

Among the recent work, Johan Pouwese has a interesting paper
analyzing a long stretch of BitTorrent traffic

http://www.isa.its.tudelft.nl/~pouwelse/Bittorrent_Measurements_6pages.pdf

Basically, all of this research finds Pareto (Zipf's law) or modified
Pareto distributions in rank for streaming, Video on Demand, Video rentals, books, blogs

http://homepage.mac.com/kevinmarks/powerlaws.html

even video conferencing. (I found a Mandelbrot-Pareto distribution to be
an excellent match to the usage of VideoConferencing units, for example :
http://www.americafree.tv/rankings/vc_usage.total_hours.post_fit.rank_shift_8.png )

In many recent papers the Pareto distribution is taken for granted,
and may not even be mentioned, but it's there (Jan Pouwelse told me, for example, that
his large BitTorrent logs fit a Pareto distribution beautifully, but it's not even mentioned
in the paper IIRC).

What does this mean ? Well, in a study I did for a satellite startup (that never actually, um,
started), I looked at
video rentals from a large chain; with 13,000 titles, 10 titles get almost 9% of the rentals,
and the top 100 get ~ 22%, but there is a "long tail," and 50% of the traffic comes
from the least popular 11,700 titles.

It seems to me that this has a profound implication concerning both multicast bandwidth
savings and the ability to cache (dynamically or statically) video on demand - while
a lot of bandwidth can be saved by caching or multicast, there will be (if you are truly
offering a large number of titles / shows / channels) a lot of aggregate demand for
content that is not watched by many people, so you
will still need a lot of bandwidth / servers to
service the "long tail." In the above case study, for
example, content was at 5 Mbits/sec, and typically 2 hours long (i.e., movies).
While caching, say, 200 titles in a Terabyte of local storage
might service 28% of your "hits", and reduce your bandwidth load accordingly,
you still need the ability to provide 102,000 downloads of the other
12,800 titles daily if you have 1 million customers (assuming, BTW, that each one only
watches one movie per week), which requires 42 Gbps. As you expand the amount of content
and the size of the community, these numbers only get worse.

I expect to see BitTorrent type systems expand to include distributed storage. The
same 13,000 titles in the above study only require 60 Megabyte per user. Suppose
that this was a BitTorrent community instead, with distributed storage.
If every title was striped, duplicated 5 times, and stored across the community,
for only 300 Megabytes of storage every member of this community could have instant
access to every title. As these communities expand to include basically everyone
with suitable connections, storing and distributing
every piece of video content ever made for public release becomes technically
feasible.

To get back to Randy Bush's comment on Japanese bandwidth to the home, if everyone
has 100 Mbps symmetric, I expect ideas such as this to use it up.


Thomas


Regards
Marshall Eubanks
----- Original Message ----- From: Mike Macdonald
To: Thomas Kernen ; [email protected] ; Andrew Odlyzko
Sent: Tuesday, April 19, 2005 4:17 AM
Subject: RE: cost of doing business


The problem I see coming is simple bandwidth wastage driven by NA TV habits. Many homes have
TVs on during the day full time even when not watched. Now were talking about as much as 10-20
Mbps (depending in HDTV adoption) going into a void.



Mike



-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Kernen
Sent: Tuesday, April 19, 2005 1:48 AM
To: [email protected]; Andrew Odlyzko
Subject: Re: cost of doing business



>> fwiw, 100mb to the home costs about that in japan
>
>
>
> We are talking of two different things here, traffic versus access
> bandwidth.
> It will be a while before the average household generates 5 megabit/s
> traffic.
> Even in Korea and Hong Kong, where the average broadband link is in
> the 5-10 Mbps range, average traffic is about 0.1 Mbps. The main
> purpose of high speed links is to get low transaction latency (as in
> "I want that Web page on my screen NOW," or "I want that song for
> transfer to my portable device NOW"), so utilizations are low.
>

For those of us that are already running triple play architectures and working on the data
analysis related to the bandwidth usage growth (in my case over the last 18 months and adding
services one after the other) I see this with a different light:

I fully agree with the transaction latency syndrome, people are compulsive customers that want
to buy right now and you (as a service provider) want to see to them purchase the service before
they change their mind, just need to look at the ringtones market to see how much people are
willing to spend within seconds for a piece of music they will replace in a few days/weeks with
their next favorite tune from the charts that marketing is feeding them with.

Where I don't agree is on the bandwidth usage analysis, once you add the IP based TV/VOD*
services you will be carrying close to 5Mbps on average on your network in the near future.
Either for the one of the TV channels (currently the market is talking about 2 concurrent TV
channels down the same pipe to an end user's home in the North American model or 1 for the

European) or the VOD. So agreed this is not Internet traffic but you will need to carry it
beyond your access termination device (DSLAM/CMTS/ Ethernet

switch) since the economics of the IPTV/VOD market and (current?) technical scalability will
prevent you from being able to have a the full IPTV/VOD streaming (= unicast and/or multicast in
this case) in each POP to keep the traffic as local as possible. So anyhow within your metro area
network accessing and aggregating the customers the amount of bandwith required to service all
customers will grow quite a bit with IPTV/VOD services.

IMHO (of course)
Thomas

*Triple play IPTV/VOD = IP packets carrying a video signal using (name your favorite format)
either as unicast or multicast stream. This excludes the current hybrid HFC networks that still
provide digital TV via an HF stream using (insert your favorite standard here) and the Internet
access and voice service over IP. Anyhow they will migrate once DOCSIS 3.0 and the wideband
benefits have been marketed to all the cable operators as the "next big thing" they need to have
and hence run an IP only service for all the triple play services.