On Tue, 5 Oct 1999, Tim Wolfe wrote:

On Tue, 5 Oct 1999, Charles Sprickman wrote:

...

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.

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

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

On Tue, 5 Oct 1999, Sam Thomas wrote:

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 ============================================================= | Timothy M. Wolfe | Wireless Internet = Get Some | | Chief Network Engineer | 1.800.338.2629 tim@clipper.net | | ClipperNet Corporation | http://www.clipper.net/services/ | =============================================================

...

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)