But multicst suppose to do perlication at the L2 level, where you have no information about the context, about _time to expire_ (how multicast helps you to decrease traffic in case of AUDIO-ON-DEMAND_ if I ask some nw song, and you ask the same song 10 seconds later - but remember, such requests are no popular then _Live audio_ requests except some events). If case of _caching on the fly_ you have all L4 (not L3 but L4) information, it's flexible level and vendor can easily add _time to expire_ into his live stream.
Layer 2, Layer 3 - there is a difference but I'll not go into that now. In the case of the "ON-DEMAND" scenario, you are basically talking about unicast no matter how you slice it. It by "ON-DEMAND" you are speaking of a window of subscription, then you could still use multicast. However, when you are speaking of just caching without multicast, your asking for NxT (where N is the number of caches and T is the time that it takes to send one packet to *each* cache) of delay between the first recipient and the last. Of course if NxT is greater than the actual packet gap that is being utilized, then you are pretty much screwed with just one stream. Add a couple of simultaneous streams and it gets pretty funny. However, lets assume that you are really doing this same dispersion of information via multicast, the need for dealing with NxT is removed as well as the inter packet gap problem being reduced. Of course this doesn't fit your unicast "ON-DEMAND" model - but that's why it's called multicast.
Just again, multicasting is the END of L4 caÓhing, not the beginning. And when I analyse existing network, I saw the useless of multicasting _except_ some special cases (such as some live streams in case of important events).
I wouldn't say "end vs beginning" as much as I would say - "different applications." The only thing that caching really does is aggregate the source of collection. It has moved from many hosts gathering the unicast information to many servers gathering it. It really has changed the crux of the problem since the more servers you end up having the more it looks like hosts again. And remember this is still with regard to a single *stream* of info that without multicast is being sent N times.
And I think the idea _to start from multicsting_ was wrong from th first moment of time.
Unless of course your intention is to reduce bandwidth consumption as much as possible and also maintain some reasonable degree of latency. If none of this is your issue, then caching (unicast) is just fine.
You should END by multicasting - when you ahev a network of media sources, a network of media customers, the set of policies installed over the world - you can use multicasting locally to improve the local throughput. But try to build multicast network this days - the thouthand of hackers will be happy -:), and a lot of ISP refuse to cooperate...
Yea, fortunately hackers leave unicast and caches alone...
PS. I never saw the multimedia really need multicasting on the L2 level -:). But I see a lot of multimedia where L4 caching can improve quality dramatically. Every day.
However, I have never seen a cache make more efficient use of a LAN either. And yes if you have bandwidth problems then caching can make things look much better. However, if your bandwidth problems are because you are unicasting all that multicast capable traffic (say maybe sending the same update to a thousand different servers) then you could save money on bandwidth, have shorter update times, and not worry so much about QoS - That was the source of this thread wasn't it :-)
I think blaming vendors for inability to build products which run faster than the proven lower boundaries for the required kind of algorithms is, er, strange.
i won't deny the potential scalability problems but i think your generalizing/oversimplifying to say caching just works and has no security or scalability concerns. It's amazing, but please name ANY securyty concern appeared due to WWW caching -:). It's not ideal solution (you can't cache SSL sessions, for example, through you can cache signed or crypted sessions - image PRP crypted multimedia session, for example), but I can't remember any security problem with it.
WWW traffic sucks for multicast and I think it's a poor example. However, since multicast is really only concerned with layer three, then the security of it needs to be done with the application. Hey, kind of like security for caching :-) Oh, and could you send back some *live* video from the moon - via multicast. I wouldn't want you to have to update all those individual caches via unicast over that 1200 baud connection from the space ship :-) Barry