[24306] in North American Network Operators' Group
Re: Is anyone actually USING IP QoS?
daemon@ATHENA.MIT.EDU (Barry Dykes)
Tue Jun 15 15:54:49 1999
To: "Alex P. Rudnev" <alex@Relcom.EU.net>
Cc: Brett_Watson@enron.net, nanog@merit.edu
From: Barry Dykes <barry@qwest.net>
Reply-To: barry@qwest.net
Date: Tue, 15 Jun 1999 13:47:59 -0600
Errors-To: owner-nanog-outgoing@merit.edu
> =
> 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, suc=
h =
> 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=D3hing, 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 firs=
t =
> 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 - th=
e =
> 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 fa=
ster
> > >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 sec=
urity
> > 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
