Is anyone actually USING IP QoS?
Alex P. Rudnev
alex at Relcom.EU.net
Wed May 19 18:38:35 UTC 1999
Sorry, but Windows-XXXX can realise not more than client's part of RSVP.
RSVP's troubles are not the protocol itself (through it's TERRIBLE); it's
not the problem for the router to realise some kind oc custom queuering
with some garanteed bandwidth and latency for the selected stream; the
problem is _how to make decision about such reservation_. And other
problem - I can easily use RSVP over the client's link, but i's easy and
more understandable to use some precedence with the static stream list,
to allow customer run VOIP or/and RV applications over the well loaded
link (note - RSVP is to complex for this case, 99% of such tasks can be
solved by the precedense or static access lists); I don't need RSVP on
the internal links because they can't be saturated (they are cheap); I
can't use RSVP on the inter-ISP links because there is nothing about
policy in RSVP standard and CISCO.
This means - Win-2000 can send RSVP requests, no doubt; but who is ready
to proceed such requests?
> > (RSVP).
> RSVP isn't dead. It'll be released in the next Windows 200x, which
> isn't to say that the implementation is good or bad, just that RAPI
> will finally be available to your average codesmith. The problem
> that this brings up is overuse of a good thing. For example, your
> Oracle application can signal a particular reservation but what
> happens when you have lots (10K) of users making that same reservation
> at once? It's a difficult problem because they're not all using that
The question is - how I prefere one user against another. While some
external (tac_plus daemon or radius daemon) process can't be used for
developing such requests, they are useless; and RSVP does not help to
solve this problem at all. May be, in future.
It's dead because no one use it now. May be, it'll be not dead in future.
_USE_ - I mean provider, not client's program.
Again - poit us ANYONE who does use QoS management other then CAR or
filtering or custom queuering. I could not found anyone; may be, someone
> > Anyway, no one answer to the initial question. I guess no one here use
> > complex QoS features, except primitive (CAR, RED, WFQ) ones.
> Actually, that's not particularly true. But I can't really speak on
> that subject other than to say that the people I work for are
> starting to see the light about ATM's weaknesses when "native" ATM
> applications are built. Unfortunately, I've yet to see an implementation
> of ISSLL adaptations.
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)
More information about the NANOG