cost of doing business

Mailman List Mirror (Read Only)
1

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.

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.

Thomas

2

Hello;

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

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

3

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

4

Hi Marshall,

Hello;

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.

I agree. However, they've been warned.

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

They do indeed. I have been hearing this since 1999, in my first
negotiations with RIAA. My response has evolved to the
point that if they don't trust the end user and their
hard drive I now tell them they shouldn't be sending them content at all (or, at least, content
they don't trust them with). I have gotten tired of dealing with the value
subtracting effects of snake oil salemen.

I am involved with a project to do this (distributed storage / distribution a
la BT) in another country where the licensing
laws are more favorable.

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.

Which of course is not the same as saying that it can't be duplicated.

Thomas

Regards
Marshall