|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: multicast (was Re: Readiness for IPV6)
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
|