Re: cost of doing business
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. 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 ----- Original Message ----- From: Mike Macdonald To: Thomas Kernen ; nanog@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@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Thomas Kernen Sent: Tuesday, April 19, 2005 1:48 AM To: nanog@nanog.org; Andrew Odlyzko Subject: Re: cost of doing business
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.
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@deckpoint.ch> wrote:
To a point (see below)
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_... ) 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
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@multicasttech.com> To: "Thomas Kernen" <tkernen@deckpoint.ch>; "Mike Macdonald" <mikemac@nortel.com>; <nanog@nanog.org>; "Andrew Odlyzko" <odlyzko@dtc.umn.edu> Sent: Tuesday, April 19, 2005 3:28 PM Subject: Re: cost of doing business
On Tue, 19 Apr 2005 15:46:58 +0200 "Thomas Kernen" <tkernen@deckpoint.ch> wrote:
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.
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.
Which of course is not the same as saying that it can't be duplicated.
Thomas
Regards Marshall
participants (2)
-
Marshall Eubanks -
Thomas Kernen