ddivinia@broadcast.com (Darin Divinia) wrote:
Caching doesn't work for live content.
Why? (And what is "live content"? You mean interactive?
Or "live" TV coverage?)
--vadim
>Caching doesn't work for live content.
Why? (And what is "live content"? You mean interactive?
Or "live" TV coverage?)
And wouldn't a cache box with multiple people watching "live content"
basically bring us right back to multicasting? One stream to the cache
operator, multiple streams out to the clients... Multicasting.
There's at least one commercial service that does this with RV and
NetShow.
Charles
Conceptually, is it that much more effort for a server/router/device to store a
local copy of a packet as it passes through the server/router/device than it
is to simply forward said packet? Admittedly, the client to cache
interaction is somewhat more complicated but would seem to be addressable
using (mostly) existing technology. Would "Live" content be incredibly
hampered by a 500 ms (or less) delay so that the cache could receive the
data and distribute it to the appropriate users locally?
Maybe I am just not smart enough to understand your (Darin) point about
caching not working, but I just don't see what the huge obstacle is..
Tim
What would be the point of this?
What you would accomplish with this setup compared to multicasting is
moving the redundant parallel data streams closer to the receiver, inside
the provider's network. For n receivers, the cache still has to send out
n streams, and if the data truly is treated as "live/real-time", it ends
up sending n identical (except for destination address) packets out its
outbound interface. This is n*bitrate of traffic that has to travel from
wherever the "packet-cache" is, accross the internal network to wherever
the recipients are. With multicast, if there is a large enough collection
of receivers to justify a cache, there will be at most 1*bitrate on any
single connection on the internal provider network. The cache solution is
less optimal in this case. If you suggest a hierachical cache (i.e. main
cache takes a feed, replicates to n distributed caches closer to the
receivers) you have just re-invented multicast, and not very well. 
party on,
Sam
What would be the point of this?
The point is that
1. It saves you external (transit) bandwidth, which for smaller/non-US
providers is one of the larger expenses, for on-demand types of services, eg
Real Video/Audio. This is one of the key factors, in my opinion, of really
getting to the goal of an internet that is equally accessible to most/all
locations globally.
2. It allows you to control the quality of service, due to the fact that
the server (cache) to client connection is all inside your own network,
unlike the multicast scheme which relies on (possibly) many external
networks to deliver the content.
With multicast, if there is a large enough collection
of receivers to justify a cache, there will be at most 1*bitrate on any
single connection on the internal provider network.
You seem to be basing your calculations on the fact that all of the intended
recipients would be capable of receiving native multicast, which I haven't
found to be the case..
The cache solution is less optimal in this case.
Forcing me to point out once again that multicast does little or nothing for
on-demand services, which contrary to popular opinion will be a much more
significant percentage than live multimedia, in my opinion.
If you suggest a hierachical cache (i.e. main
cache takes a feed, replicates to n distributed caches closer to the
receivers) you have just re-invented multicast, and not very well.
A heirarchical caching scheme would be similar to multicast in that you'd
only need 1 stream from the source into your top level cache, but with the
added benefit that you would be able to deal with on-demand services as well
as live.
At least that's how it would all seem to me. I'm not claiming to be an
expert on this topic, I'll leave that to Alex and Vadim.. 
Tim
Yes except that it wouldn't be reliant on X number of backbone providers
playing nicely in the multicast arena to work and a provider could to a much
larger extent retain control of their own destiny..
Tim
Thus spake Tim Wolfe
At the rate merger-mania is going there isn't going to be more than one
backbone provider in a few years anyways.... 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell
"This is our time. It will not come again."
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Yes.
I prefere to ask the WEB or RV server about the live content, using normal
IP addresses (DST and SRC), normal DNS, normal URL's. etc.
Then, if my request was catched by the _on-the-fly-cache_ or
_on-the-fly-repeater_, it can propose me (my client) to use multicast
(xx.xx.xx.xx) instead of unicast data stream. My client can aggree or
disaggree. The replicator can not propose me multicast, multicast can be
unreachable, etc.
If MCAST is ONE-OF-A-FEW-OPTIONS, why not? This days, when your NETSCAPE
request something by http, it send _the set of possible encoding_ and some
other _possible options_, and it's doing transparently for you. We have a
lot of GREAT multimedia clients and servers this days; some of them can
use multicast as one of the options; and we have a global, stable, well
hierarhied (L2, IP, TCP, DNS-names, HTTP-names, HTTP-like-requests)
Internet. If you start from this, and use MCAST in some cases 0 why not.
But if everyone ask me _do you want to read this doc? Please, install
China fonts and learn China language_ - sorry, I better search something
else (I do not know China).
Date: Tue, 5 Oct 1999 17:34:45 -0400 (EDT)
From: Charles Sprickman <spork@inch.com>
To: Vadim Antonov <avg@kotovnik.com>
Cc: alex@Relcom.EU.net, andym@ntt.net, ddivinia@broadcast.com,
nanog@merit.edu, randy@psg.com
Subject: Re: Real Media and M-Bone feeds
>
> >Caching doesn't work for live content.
>
> Why? (And what is "live content"? You mean interactive?
> Or "live" TV coverage?)And wouldn't a cache box with multiple people watching "live content"
basically bring us right back to multicasting? One stream to the cache
operator, multiple streams out to the clients... Multicasting.There's at least one commercial service that does this with RV and
NetShow.Charles
> --vadim
>
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
> is to simply forward said packet? Admittedly, the client to cache
> interaction is somewhat more complicated but would seem to be addressable
> using (mostly) existing technology. Would "Live" content be incredibly
> hampered by a 500 ms (or less) delay so that the cache could receive the
> data and distribute it to the appropriate users locally?What would be the point of this?
What you would accomplish with this setup compared to multicasting is
moving the redundant parallel data streams closer to the receiver, inside
the provider's network. For n receivers, the cache still has to send out
n streams, and if the data truly is treated as "live/real-time", it ends
up sending n identical (except for destination address) packets out its
outbound interface. This is n*bitrate of traffic that has to travel from
wherever the "packet-cache" is, accross the internal network to wherever
the recipients are. With multicast, if there is a large enough collection
of receivers to justify a cache, there will be at most 1*bitrate on any
single connection on the internal provider network. The cache solution is
less optimal in this case. If you suggest a hierachical cache (i.e. main
cache takes a feed, replicates to n distributed caches closer to the
receivers) you have just re-invented multicast, and not very well.
Yes, when you have the _caching-replicators_ and you see some parts of
your network became a _bottlechecks_, and this parts have multicast
(local) option, you can use mcast (i.e. use L2 packet repliation instead
of L4 replication).
This schema should work well from the very first days, and should be
improved in time if the multicast-able area will increase. Note - it don't
need inter-AS-es multicast at all, don't need any modification on the data
sources (except may be some priority for the replicators), don't need
(almost) any modification for the clients, and provide bandwidth economy
from the first days.
MCAST - work only where it exists, have un-resolved problems, can hardly
be installed over the AS boundaries, need to modify data sources and
clients, can't work for the on-demand streams.
Of course, until no one made attempt to build such
_cache-and-replicate-on-the-fly_ engine (as CISCO built their WEB CACHE
engine) - it's not more then theory.
party on,
Sam--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer
Aleksei Roudnev, Network Operations Center, Relcom, Moscow
(+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager)
(+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)