There is also a "cart and horse" issue here: Where is the pervasive
content?
Most content providers don't want multicast because it breaks their
billing model. They can't tell how many viewers they have at a given
moment, what the average viewing time is, or any of the other things
that unicast allows them to determine and more importantly bill their
advertisers for. There is no Nielsen's Ratings for multicast so that
advertisers could get a feel for how many eyeballs they are going to
hit.
Then add in the latest from Congress with regard to streaming audio over
the net, and you have a source payment issue making you not want to go
down the multicast path. (Leaving Congress living up to their name as
being opposite of progress.)
Multicast is a great technology. It just is stuck looking for a problem
to solve that doesn't create even more problems.
David
Thus spake "David Sinn" <dsinn@microsoft.com>
There is also a "cart and horse" issue here: Where is the pervasive
content?
No, it's a "chicken and egg" problem 
Most content providers don't want multicast because it breaks their
billing model. They can't tell how many viewers they have at a given
moment, what the average viewing time is, or any of the other things
that unicast allows them to determine and more importantly bill their
advertisers for. There is no Nielsen's Ratings for multicast so that
advertisers could get a feel for how many eyeballs they are going to
hit.
That assumes there is no signaling. Commercial content will be encrypted and
clients will have to get a key (possibly for free). Key distribution can be
tracked and billed perfectly. Even for cleartext content, clients should be
sending RTCP reports periodically.
I think a bigger issue is that multicast is only truly compelling for
high-bandwidth applications, and there's just not a critical mass of users with
enough bandwidth to justify deployment today.
Even worse, multicast is truly only suitable for live applications; on-demand
content can't be realistically mcasted, and users will not settle for "the movie
starts every 15 minutes" when they've been used to live VOD with unicast. The
only saving grace may be things like TiVo, where an intelligent agent slurps up
live mcasts in hopes that the user may want to watch it "live" later.
S
Even worse, multicast is truly only suitable for live applications; on-demand
content can't be realistically mcasted, and users will not settle for "the movie
starts every 15 minutes" when they've been used to live VOD with unicast. The
only saving grace may be things like TiVo, where an intelligent agent slurps up
live mcasts in hopes that the user may want to watch it "live" later.
Really? What about DF-like technologies?
Dave
There is also a "cart and horse" issue here: Where is the pervasive
content?
Most content providers don't want multicast because it breaks their
billing model. They can't tell how many viewers they have at a given
moment, what the average viewing time is, or any of the other things
that unicast allows them to determine and more importantly bill their
advertisers for. There is no Nielsen's Ratings for multicast so that
advertisers could get a feel for how many eyeballs they are going to
hit.
I worked for a startup in 1999 that was doing just that. Neilsen's for
multicast. It was cool while I was there, but it quickly became clear
that the product was ahead of it's time. They now do event streaming and
I think they support unicast and multicast. Without a network that
supports it, multicast apps are useless.
jas
Just for the sake of argument I'll point out that this is exactly
how DirecTV offers PPV movies... each of the 30-odd movies available
for viewing in a given month are listed on one or more channels
with defined start times. Obviously this may not translate to
on-demand movie streaming over the internet, but since DirecTV
seems to be at least a little bit successful with this approach
you may not want to be so quick to rule it out.
Whether people will pay money to watch movies streamed over the
Internet (as opposed to traditional media such as cable or satellite)
is an entirely different question, of course.
--Jeff
Multimedia is the common example but I actually find multicast more useful
for common administrative services like NTP. I've also done some simple
research into multicast DHCP (goodbye mandatory unicast proxies) and DNS
(goodbye mandatory unicast proxies) which has looked promising for the
small investigative work done. In this regard, multicasting the small
chatter stuff is actually much more compelling, although these examples
all apply to a local administrative scope and not to multicasting across
the Internet in general.
The issue with the latter is that there is no killer app which requires
it. As a result, ISPs don't offer it, firewalls/NATs don't support it, and
so forth. I've never had a network connection which supported it.
Thus spake "Jeff Aitken" <jaitken@aitken.com>
> Even worse, multicast is truly only suitable for live applications;
> on-demand content can't be realistically mcasted, and users will not
> settle for "the movie starts every 15 minutes"
Just for the sake of argument I'll point out that this is exactly
how DirecTV offers PPV movies... each of the 30-odd movies available
for viewing in a given month are listed on one or more channels
with defined start times.
Yes, that's the PPV model. AT&T Broadband calls it "InDemand" since it's
probably fraud to call it "on demand".
Most hotels have VOD now, and that tells me consumer acceptance is better for
VOD but the technology just doesn't scale yet.
Obviously this may not translate to on-demand movie streaming over
the internet, but since DirecTV seems to be at least a little bit
successful with this approach you may not want to be so quick to rule
it out.
They're certainly successful with big events like the Tyson/Lewis fight, but how
much money does a PPV movie really bring in? Obviously they wouldn't do it if
it were a total loser, but the cost to carry is near zero and $4.95/viewing is a
huge disadvantage vs. rentals.
Whether people will pay money to watch movies streamed over the
Internet (as opposed to traditional media such as cable or satellite)
is an entirely different question, of course.
The question, of course, is whether the cost people are willing to pay will
cover the cost of providing the service. Today, it's nowhere close.
S
I remember seeing a presentation about 3-4 years ago for techniques for
doing on-demand stream sending. They assume multicast, sufficient buffer
capacity on clients to hold the entire stream, and that clients have
enough bandwidth to recieve, say, 1.2-3.5 streams at once. There are many
techniques, but the basic idea is to 'merge' streams together...
Say, for example, you have two multicast streams *.1 and *.2
*.1 is free and unused.
*.2 is 2 minutes into a movie.
A client makes a request at T=0, and subscribes to *.1 and *.2. *.1 sends
the first 2 minutes of the movie then closes. The clients buffers *.2
during those 2 minutes to get minutes 2-4 of the movie. The client drops
*.1 which is now free. Now, at T=2, the client is listening on *.2 giving
it minutes 4-120 of the movie, and minutes 2-4 are buffered on its hard
drive. Now, stream *.1 is free, and two clients are on stream *.2.
Thats the idea, and it can be scaled up.. I think the presentation I saw
claimed that where clients listen to at most 2 streams, and servers send
out at most 8 streams, then the delay before starting a 2 hour movie can
be <12 seconds, instead of <15 minutes.
Some googling finds:
http://www.cs.washington.edu/homes/zahorjan/homepage/
Which can be read or mined for references.
Scott
an example of a on-demand reliable multicast transport application that
you can deploy is:
http://www.digital-fountain.com/technology/index.htm
in part it employs them mechanism you describe.
joelja