Re: multicast (was Re: Readiness for IPV6)

[Scott A Crosby <crosby () qwes math cmu edu>]

On Tue, 9 Jul 2002, Stephen Sprunk wrote:

> 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.

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