Re: Is anyone actually USING IP QoS?

[Vadim Antonov <avg () kotovnik com>]

Brett_Watson () enron net wrote:

> > Please.  Caching is _at least_ as efficient as multicasting (multicasting
> > _is_ caching, with zero retention time) - w/o associated security and
> > scalability problems.

> > research or data to support these assertions?

Just bare logics (a lost art in the modern datacom world, i guess).
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.

(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).

> and how does caching magically negate security and scalability concerns?

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.

> what tools are you using to do content replication/management that scale to
> thousands of hosts/caches?

99% of Web content is write-once.  It does not need any fancy management.
The remaining 1% can be delivered end-to-end.

(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 :)

> even if i assume caching is as efficient, or
> more so, than multicast, i'm still just trading one set of
> security/scalability concerns for others.  caching is no more a silver
> bullet than multicast.

It is not that caching is a silver bullet, it is rather that multicating
is unuseable at a large scale.

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

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.

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.

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

--vadim

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.