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 is lucky?

...

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.

-scooter

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)