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