Subject: Re: caching on-demand transmissions

From: [email-masked] (Kevin C. Almeroth)
Date: Wed, 5 Nov 1997 09:26:12 -0800

>>exactly. imagine a different scenario:
>>
>>"Dear user, i'm your C-VOD  server. I'll let you watch the video,
>> but only when there are more  viewers in your area. Please let me
>> know your acceptable times for viewing this and I'll schedule
>> the retransmission, so that you can share it with other users."

Well, the scenario I envisioned was something like:

    "Dear user, sorry, but the movie you just requested is unavailable.
     However, if you find something in the following list you would
     enjoy, we would gladly offer that movie to you for 1/2 price."

If we are using the batching model then movies start every 5, or 10,
or whatever minutes.  If resources were not available to schedule yet
another movie channel, you would try and get the user to join a movie
group that had the resources but hadn't actually started playing.

You don't actually have to do variable pricing...  in fact, the service
provider would jump at the chance to get more people into the same
group because the service provider gets an additional 50% revenue for
almost zero marginal cost.  Cost to the user wouldn't have to reflect
actual marginal costs (and in most current industries, it doesn't).

-Kevin

---

From: [email-masked] (Kevin C. Almeroth)
Date: Wed, 5 Nov 1997 09:34:32 -0800

>>It seems to me that one could play funny games with the playout speed
>>on individual streams, so that eventually one or more playout streams
>>could be aggregated (i.e. speed one up, slow another down, until they
>>both play the same content.)

The paper you are looking for is...

   author = "Golubchik, L. and Lui, J. and and Muntz, R.",
   title = "Reducing {I/O} demand in Video-on-Demand Storage Servers",
   booktitle = "ACM SIGCOMM 95",
   address = "Boston, MA",
   month = "August",
   year = "1995"}

They do stream combining via stream speed-up and slow-down.  The big
challenge of course is doing this in a real system.  I remember one of the
arguments against this sort of thing is that in large-scale VoD servers,
content is organized to provide highly optimized sequential access for
large numbers of streams.  Messing around with speed-up and slow-down 
complicates issues like server storage, content retrieval, and receiver 
playback.  But the idea is still sound.

-Kevin