North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Is anyone actually USING IP QoS?

  • From: Brett_Watson
  • Date: Wed Jun 16 12:19:23 1999

On 06/15/99 01:23:16 PM Vadim Antonov  wrote:

>Brett_Watson@enron.net wrote:
>
>>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.

i'll give you that.  however, caches tend to run under unix-like os's which
are multi-user and multi-service machines.  they can be susceptible to DoS
attacks, and can be running services listening on a port which can
potentially be "hacked".  my only point is that you are trading a set of
security issues in multicast for *different* security issues with a cache.

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

it's very different in our network.  we have lots of static content
(on-demand real-video, mpeg, etc) which is injected to a set of distributed
servers around the network from content originators.  the content
originators may be traditional content providers such as those found on the
internet but they may be a 3-letter television networks (broadcast
television), post-production video houses, etc.  we have to do content
management, aging, etc for large volumes of data.  we also have to keep
systems synchronized with content (contrary to your next statement which i
don't agree with).

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

right, they don't have "similar limitation" they have *different*
limitations which wasn't what you seemed to be saying.

-brett