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





More information about the NANOG mailing list