Subject: RE: [NSIS] section 3.5 in nsis-req-00.txt

From: [email-masked]
Date: Sat, 16 Mar 2002 02:31:08 +0200

Hi Bob,

> Just a historical data point: when we designed the int-serv
> architecture, beginning in 1991 and culminating in RFC 1633, we
> considered the idea of QoS classes and rejected them in favor of the
> "flow spec" idea.  The reason we rejected the QoS class idea was that
> it seemed to be an invitation to massive non-interoperability.  The
> fear was that such classes would proliferate, with each application
> that needed QoS defining its own QoS class.  Which ones of the perhaps
> 50 such classes would a router vendor support?  These would often be
> minor variations on each other, but they would have to be registered,
> defined, documented, implemented, maintained, ... 
> individually.  Unless
> you have some standardization mechanism that keeps the number of such
> classes down to a few dozen or so, it seemed like a recipe for QoS
> chaos.

Agreed.  Additionally, I do think that offering many levels of QoS
can be a problem for a service provider as well.  Some models
have shown that a service provider cannot support offering
more than 4 levels of QoS reliably.  
 
> However, isn't this question outside the scope of a WG on signaling?

Well, I perhaps chose the wrong term, but I think we do have to decide
what to signaling.  Do we signal absolutely or relatively, or do 
we do a little of both.

Actually, with respect to this, I'd be very interested in see
real-world data on service providers who have provided or are
providing different levels of QoS & their experiences.

As an aside, someone to me suggested that NSIS should have a model
where there are 5 different QoS profiles (best effort, interactive,
voice, video and VPN), each profile have a level from 1 to 10
specifying the level of service, and optionally carrying specific
parameters ...

thanks,
John

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis

---

From: Paul Sijben <[email-masked]>
Date: Mon, 18 Mar 2002 11:48:54 +0100

Bob, John,

in my experience an application-level QoS class is (only) useful between
the user at the edge and the (first) application aware server. At the user
interface a set of classes is a useful shorthand to ask for what you want. 
This application specific thing should be converted to something that
provides a parameterized (sp?) description of the transport service you
need. 

Subsequently you need to consider what the scope of these parameters are.
In general the scope of the parameters is from here (for a suitable
definition of here) to the destiation. So the parameters will change at
each hop. 

So John, the parameters are absolutely relative. (excuse the pun)

Paul 

-- 
Paul Sijben                         Tel:+31 356874774 
Bell Labs - Advanced Technologies   Fax:+31 356875954
Lucent Technologies     (internal) http://voip.nl.lucent.com/~sijben 
Huizen, The Netherlands