cost of doing business

Tue Apr 19 13:46:58 UTC 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" <tme at multicasttech.com>
To: "Thomas Kernen" <tkernen at deckpoint.ch>; "Mike Macdonald" 
<mikemac at nortel.com>; <nanog at nanog.org>; "Andrew Odlyzko" 
<odlyzko at dtc.umn.edu>
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" <tkernen at deckpoint.ch> 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 ; nanog at nanog.org ; 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: owner-nanog at merit.edu [mailto:owner-nanog at merit.edu] On Behalf Of 
>> Thomas Kernen
>>   Sent: Tuesday, April 19, 2005 1:48 AM
>>   To: nanog at nanog.org; 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.
> 