Re: Is anyone actually USING IP QoS?
Just bare logics (a lost art in the modern datacom world, i guess).
logics/insanity, l2/l3, no real difference, right...
Make this gedunkenexperiment: take each mcast packet replicating point and replace it with a cache with very small retention time. The thing will replicate data in exactly the same way; and the packets will flow along the same paths. Therefore it is _at least_ as efficient
So you're saying that an application-specific cache would be more efficient than non-application-specific multicast? OK, let's consider this. How would distribution/replication be done? What was the destination address of the original packet .. let's say, 225.X.X.X? Wow!
(Note that i do not consider possibility of building mcast trees dependent on traffic or bandwidth reservation - the algorithmic complexity involved makes that an intractable problem (it is believed to be NP-complete in general case); even the best heuristic algorithms for such planning place it beyond realm of computable for the networks fraction of size of present Internet).
But we're not discussing that. we're discussing multicast v/s unicast (or was it QoS?), but you're somehow tying the two together when they're completely different things. and are you suggesting that dense-mode (blindly distributing), to coin the term, is more efficient than say, sparse-mode (multicast?) .. not even in your bare logics world.
Caching is not employing any routing information exchange. Therefore it is a) oblivious to the state of other caches or to the changes in network topology and b) is invulnerable to the bogus routing information and flap-like DoS attacks.
a) Yes, it indeed does have different challenges than multicast. It still relies on the underlying layers which b) are not oblivious to such DoS attacks .. in todays Internet (maybe not yours, but todays) where 2 million line prefix filters are about as real as millions of multicast groups.
99% of Web content is write-once. It does not need any fancy management. The remaining 1% can be delivered end-to-end.
I don't recall scoping this to only "Web", but it does seem to best augment your argument, better stick to it :-) I'm of the opinion that an application-agnostic approach is a better idea.
(BTW, i do consider intelligent cache-synchronization development efforts seriously misguided; there's a much simpler and much more scalable solution to the cache performance problem. If someone wants to invest, i'd like to talk about it :)
Ahh, I see. Everything sux, but give me cash (pun intended :-) and I'll give you cold fusion.
It is not that caching is a silver bullet, it is rather that multicating is unuseable at a large scale.
many to many, perhaps it does have it's challenges. one to many, it works today.
Well, philosophical note: science is _all_ about generalizing. For an inventor of perpetuum mobile the flat refusal of a modern physicist to look into details to assert that it will not work sure looks as an oversimplifying. After all, the details of actual construction sure are a lot more complex than the second law of thermodynamics.
Second law of thermodynamics: OK, coke loses it's fizz, but putting a cap on the bottle wasn't that hard.
In this case, i just do not care to go into details of implementations. The L2/L3 mcasting is not scalable and _cannot be made_ scalable for reasons having nothing to do with deficiencies of protocols.
Summary: It sux, I can't can't tell you why, but it just sux!
Caching algorithms do not have similar limitations, solely because they do not rely on distributed computations. So they have a chance of working. Of course, nothing "just works".
PS To those who point that provider ABC already sells mcast service: there's an old saying at NASA that with enough thrust even pigs can fly. However, no reactively propulsed hog is likely to make it to an orbit all on its own.
However, if he sends enough mail to NANOG, he'll likely find someone to fund even shoving a rocket up a dogs ass :-) -danny (who won't waste any additional time in this thread)
First of all, may be there is some other place for this, _more theoretical_, discussion? On the other hand, I do not want to lost this thread. Then, what I and Vadim are speaking about, it is not _efficiency_. No one bother on _efficiency_ in the real life, all (at least network admins) are bothered about _enougph/not_enougph_ issue. It's a difference. For now, there is the source of multimedia - different HTTP sites over the world; there is a beatiful protocols like realvideo or streamvideo, used by the thousands. And there is bottlechecks - not the LAN's but inter-domain links, not the ethernet's but inter-sea cables. Then, I'd like to make one issue clean enougph. If your LAN is not the bottlecheck, the difference between multicasting and packet replication became nonimportant (except may be the server power). On the other hand, the packet replication is the caching with the zero expiration time. And (on the third hand -:)) the 90% of existing multimedia context is ON-DEMAND context, not the live context. This resumes into the conclusion - it's much more efficient to start from L4 replication or reflection, may be _ON THE FLY, HIDDEN_ reflection. This technique can be implemented on the single ISP and allow him to improve access to the ALL over-world multimedia sources, just at once. Then, if sometimes LAN became bottlecheck, just the same replication server can be used to translate unicast to multicast. Anyway, our (ISP) experience show us _not to allow the customers to ask multicasting at the L2/L3 level_, and don't use multicasting over the domain/AS boundaries - let's it be for the _future generation_ internet. And then, if we replace _on-the-fly_ replication to the _short expiration time caching_, we'll cover _multimedia on demand_ requests as well. Note - this do not need extra routing schemas, extra routing protocols (except, may be, some fixed reservations done for the cache itself), no extra inter-domain negotiations, etc etc. And it can be easily converted to the local multicasting in the future. And L4 replication/caching means _you have the same name space as http, you have a flexible control protocols like SIP, etc etc - you can control this service as well_. Not as in L2/L3 case (someone ask 224.1.2.3/255 multicast, should I allow it or not - nobody know; who should pay for this - nobody know, how to stop this - nobody know...). Just as it was saying, _even elephant can fly_. But starting multimedia services from the multicasting is _to send elephant to fly_. May be, in future, we'll need an elephant to fly; for now, we need something like the _flying bat_ - but we need it just in time, not since 20 years. We have 'played' with MBONE, we have 'played' with WebTV. But we just 'work' with RV and such services, just this days. May be, we'll stop to play with the _flying elephants_ and start from the _flying bat's_ first?
But we're not discussing that. we're discussing multicast v/s unicast (or was it QoS?), but you're somehow tying the two together when they're completely different things. Yes, we changes the subject during this discussion. -:)
But this is _an answer_ - no one use QoS because it meant _multicasting_ mainly, and multicasting can't be deployed over the global internet this days. But no one need QoS inside their internal network (usially, there is exceptions); and we can't provide inter-domain QoS yet.
and are you suggesting that dense-mode (blindly distributing), to coin the term, is more efficient than say, sparse-mode (multicast?) .. not even in your bare logics world. Just again. It'e enougph in our world to use the dense-mode, except some special cases, If it should be not enougph, we'll say it -:).
relies on the underlying layers which b) are not oblivious to such DoS attacks .. in todays Internet (maybe not yours, but todays) where 2 million line prefix filters are about as real as millions of multicast groups. And show me this millions of multicast groups -:). There is 10 - 20 such groups over the whole russia. Try to get one or two - and you'll get an angry message from the network admin. Etc. It's _play_ for now, not the real work yet.
I'd like to stopp this thread here too; but I think this _replication_ and _short-time-caching_ must be concerned in the new session-initiation protocols. It's easy to start from this end. 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)
participants (2)
-
Alex P. Rudnev -
Danny McPherson