Subject: RE: caching on-demand transmissions

From: Dwight Spencer <[email-masked]>
Date: Wed, 5 Nov 1997 11:25:57 -0400

Akin the logic behind cable co's "movie channels".  A subscription
based charge rate. Users pay x dollars per month for a service
and watch (a limited?) number of movies for this fee.

A user coould do the "on demand / pay per view" method, or wait 
until the broadcast currently being sent is "restarted" ... A request 
stream could be built that shows the most popular requests
and are then played at the end of the current broadcast.

The multicast "ondemand" service could be designed to take
requests from an  interface (on the network) then
poll all the requests, and play the top (x) requested streams in
the next play period, depending on bandwidth availability.

What would be ideal here is that the requestor be notified
that their request is starting at/in whatever time.

dwight s.
_________________________________________________________________
dwight spencer                			phone:  506 444 5389
internet services manager			fax:    506 444 4232
[email-masked]

TeleEducation NB, 500 Beaverbrook Court, Fredericton, NB, Canada, E3B 5H1

-----Original Message-----
From:	Petri Helenius [SMTP:[email-masked]]
Sent:	Tuesday, November 04, 1997 5:43 PM
To:	[email-masked]
Cc:	Kevin C. Almeroth; [email-masked]; [email-masked]
Subject:	RE: caching on-demand transmissions

Karl Auerbach writes:

Sounds like incentive enough. Since there is cost involved in the
dedicated transmission that cost should be transferred to the
subscriber. However, in the case of multicast we need to do an
"estimated cost" since it's not acceptable to have a varying cost
depending on how many of your neighbors are watching the same
programming at any given time. This has been argued here before, but I
think one can land at a reasonable figure fairly easily based on
operating statistics.

 > But this tends toward marketing rather than technology.
 > 
Pete

---

From: Petri Helenius <[email-masked]>
Date: Wed, 5 Nov 1997 19:54:36 +0200 (EET)

> that their request is starting at/in whatever time.
This could be easily either unicast directly to the user or multicast
on the group where the content would start momentarily. Meanwhile the
client program would either tune to some generic content like CNN, MTV
or just play a soundtrack which can be shared with all the people
currently "on-hold" to a movie start. A little piece of music or news
hardly ever hurts. The bad thing might be that in middle of an
interesting news item the movie starts, but that's why client
buffering is there so you can hold the start for a minute or two.

This is all doable today and there are some companies heading this
way. I'm anxiously waiting for the first one to deliver a piece of
software that would do all this.

Pete