Is anyone actually USING IP QoS?

Barry Dykes barry at qwest.net
Tue Jun 15 19:47:59 UTC 1999



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








More information about the NANOG mailing list