Subject: RE: caching on-demand transmissions

From: [email-masked] (Kevin C. Almeroth)
Date: Tue, 4 Nov 1997 08:10:41 -0800

>>Right. I really fail to see the point in using multicasting for
>>on-demand applications.

Basically, it depends on whether you can generate enough requests
and in a large enough system, that's a piece of cake.  Look at all
the work that has been done in grouping requests in Video-on-Demand
systems.  Those same concepts are being applied to things like
WWW traffic, etc.

-Kevin

<plug>
The following reference was the culmination of our VoD batching work...

K. Almeroth and M. Ammar, "On the Use of Multicast Delivery to Provide
a Scalable and Interactive Video-on-Demand Service", Journal on Selected
Areas of Communication (JSAC), August 1996.

Abstract:

levels of interactivity.

---

From: Karl Auerbach <[email-masked]>
Date: Tue, 4 Nov 1997 13:21:42 -0800 (PST)

> systems.  Those same concepts are being applied to things like

That's the key -- By juggling the delay between the time a request is made
and the time that the on-demand program is actually played one possibly
accomodate multiple requests.

The key is to try to supress or deflect the user's perceived need for
"yuppie mode networking", i.e. "I want it, and I want it now!". 

If the demands are relatively few and far between, then multicasting isn't
going to help much because, on average, there will be only one request
(and probably one listener) per transmission.

Of course, that situation isn't any worse than if all streams were
unicast.  So the downside potential of multicasting is nill.

But if one can do things through advertising or billing rate advantages to
get people to somewhat synchronize their demands, then IP multicast can be
used to advantage.  For example, one can price true on demand at $10 and
also have a mode in which demands will be played at the next 30 minute
boundary for a price of $3.  The price differential may cause some people
to say "I can wait a few minutes to save $7".

But this tends toward marketing rather than technology.

		--karl--

---

From: Petri Helenius <[email-masked]>
Date: Tue, 4 Nov 1997 23:43:03 +0200 (EET)

> accomodate multiple requests.

It would make an interesting statistic to count how many episodes of
various soaps that are continously being re-run on US television there
are in total. The same for movies. Then imagine an audience of 300M
users distributed fairly evenly across the timezones (which they are
not). What's the average number of hits every piece of programming
would get at any time?
 > (and probably one listener) per transmission.

Here, I think everyone is in violent agreement.
 > unicast.  So the downside potential of multicasting is nill.
At least currently multicast requires more state in the routers than
unicast. Depending on your cost metrics, this might not neccessarily
need to be true.

 > to say "I can wait a few minutes to save $7".
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: "[email-masked]" <[email-masked]>
Date: Tue, 4 Nov 1997 23:27:37 +0100 (MET)

> "yuppie mode networking", i.e. "I want it, and I want it now!". 

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

Now - how would we convince end-user that this is what he should do,
when he has there RealVideo at hand ?

The problem is that VOD is driven by end-users' demand,
and these will always neglect all the benefits of bandwidth
sharing, until it strikes back on them :-(

so it seems that any successful solution here should be transparent
for users. or at least they need not to be aware of what's happening.

This is the same (anti)social behaviour that we have seen
with http before (remember netscape opening dozens of simultaneous
http connections). And this is also why caching on Internet is not very
popular unless end-users see clear benefits for them
(gee, I can get these pages faster through the cache).

--w

---

From: Petri Helenius <[email-masked]>
Date: Wed, 5 Nov 1997 09:08:37 +0200 (EET)

> when he has there RealVideo at hand ?

Actually, I'm not sure if you are posing this question as an excercise
or for real. Anyway... RealVideo as it's there today in 5.0 beta
still leaves a lot of to be desired quality-wise. So if I would have a
choice of waiting 15 minutes for my movie to play in high-definition
with six channel audio or take it now in smaller size and stereo, I'd
spend the 15 minutes to get the chips and put popcorn into the
microwave. Remember that at the state of art in current technology,
you can't do entertainment quality video with much less than 2
megabits per second. Serving full-length features at 2 megabits to
tens of thousands of users costs you a fortune not only in server
hardware, but in infrastructure, unless you put a server up to each
neighborhood crossconnect. And I would imagine, since we're not
limited by the deployment of very expensive hardware orbiting the
earth that the bandwidths and with them, the resolution, would go up
to 4 to 16 Mbps range _PER_STREAM_ fairly soon.
 > sharing, until it strikes back on them :-(

Your average "media streaming" site today usually provides you with
all kinds of "too busy" messages and currently we're running at a
fraction of the bandwidths required for real stuff.

 > for users. or at least they need not to be aware of what's happening.
Exactly. That has been my point all along.

 > (gee, I can get these pages faster through the cache).
There is no need for end-user setting any "cache" settings in
intelligently developed multicast application. This goes for both
non-realtime stuff like all the push-media and audio/video.

Pete