Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 17 Oct 2006 09:20:06 -0500

> There was a proposal for a QoS model on 3GPP QoS model, by the way.
> http://www.watersprings.org/pub/id/draft-jeong-nsis-3gpp-qosm-02.txt

Note the co-authors -- it would be good IMO to restart this 3GPP-QOSM
work.

Note also that this draft defines mappings between  TS 23.107 and Y.1541
QoS classes and between TS 23.107 and DiffServ QoS classes (see Section
4.1).  Mappings between Y.1541 and DiffServ QoS classes can be equally
well defined if need be by a particular QOSM.

> However, I think that we are going circular.  The QSPEC 
> defines a general model for being able to support different 
> QoS Models.  We were asked to look at how to support 
> different models, including Y1541, by our AD at the time and 
> by ITU-T liaisons.

Right.  

Most people on the list seem to support retaining the QSPEC-1 concept to
afford interoperability between QOSMs.  The original charge to design
the QSPEC template was to at least include DiffServ and IntServ/RSVP
QSPEC-1 parameters in NSIS QoS.  This approach was based on the premise
that these are the 'legacy' IETF QoS models and must be supported by
NSIS.  Note that the combination of RSVP and DiffServ *do* support most
or all of the QSPEC-1 parameters.  I believe they are 'mandatory'
parameters in the sense that DiffServ and RSVP implementations do
support most or all of these capabilities since various service
providers collectively require support for these various features.

OTOH if we only define QSPEC parameters as QSPEC-2 (optional)
parameters, and eliminate the concept of QSPEC-1 (mandatory) parameters,
then various QOSMs may support mostly disjoint sets of parameters, and
interoperability isn't helped.  That is, RMD-QOSMs only interwork with
other RMD-QOSMs, CL-QOSMs only interwork with CL-QOSMs, etc. because
there is little or no commonality in the parameters they support.

On balance I think Ruediger's post at
http://www1.ietf.org/mail-archive/web/nsis/current/msg06748.html has it
about right on this debate.

Thanks,
Jerry  

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Mon, 23 Oct 2006 10:18:21 -0400

The whole thing DOES boil down to the value-based system versus the
non-value-based system because of the following fact:

1. Why does the so-called Y.1541 implementation-specific specification use
value-based QOS classes that is the fundamental problems of the generic
standardization?

2. If the so-called Y.1541-implementation spec wants to be used as
generalized QOS model like DiffServ, RSVP, and IntServ, it MUST use for
example the spec of IntServ's QOS model like Guaranteed, Controlled, and
Best-Effort service classes without limited itself ONLY to a GIVEN set of
values. 

That is, it MUST leave the specific values of delay, jitter, and packet loss
to the end users who may use those as they like for the applications they
have in their mind. So, the values of any QOS parameters must NOT be
hard-coded in the spec. If QOS parameter values are hard-coded in the spec
it becomes only the implementation spec for a given set of values. Is it
clear?

3. If the so-called Y.1541 spec wants to be generalized like e2e QOS spec
like low delay class, high delay class or very high delay class, it MUST,
like IntSev's Guaranteed Class, Controlled Class, and Best-Effort Class,
define its PROPERTIES. That's all. 

So, the Y.1541 spec is ONLY good as long as the specific values that have
been defined in the spec. If one does NOT use those specific sets of values
any SINGLE parameter of any QOS parameter, they will NOT be Y.1541 QOS
classes. 

The bottom line is this: Y.1541 QOS classes is ONLY good for the values of
the QOS parameters specified in the spec. Therefore, it is the value-based
IMPLEMENTATION spec, not a generalized standard like low, medium or high
delay e2e QOS classes.

Best regards,
Radhika

PS: It is true that Y.1541 does not specify bandwidth, but it does specify
specific values for delay, jitter, and packet loss. Indirectly, the delay is
also a function of the bandwidth.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, October 20, 2006 12:37 PM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

For me this is definitely NOT about value-based vs. non-value based, it is
more about the fact that e2e QoS is not the same as, for example,
node-specific performance (e.g., PHBs).

We gave this a lot of thought in Y.1541, which gives examples of how
DiffServ PHBs can be used to address certain Y.1541 e2e QoS classes. For
example, if an application requiring interactivity is to be supported,
certain e2e QoS is needed (low delay), which translates into specific Y.1541
classes, supportable by EF DSCPs. One would thus want an NSIS QoS protocol
to help use nodal behavior to support e2e QoS needs.

BTW note that I did not say a thing about bandwidth. (Focusing on only
bandwidth is really missing all of what I thought NSIS was going to do!)

Chuck 

________________________________________
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, October 19, 2006 8:25 AM
To: [email-masked]; Dvorak,Charles A (Chuck);
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt

Again the same logic of generalization - Mixing "apples" with "oranges" when
"interworking" is concerned!
 
Is it an isolated stand-alone debate that people will "just" look into
Y.1541 value-based QOS class parameters all by itself?
 
If it is stand-alone Y.1541 value-based QOS implementations for using NSIS
QOS signaling protocol why a separate stand-alone Y.1541-specific drat is
not written? For example, people can "assume" a Y.1541 implementation-based
QOS policy "somehow" does magic to do so. What is the problem?
 
People can "carry" any values of any parameters in NSIS QOS signaling
protocol and, it could be 100s of any so-called QOS classes like Y.1541. It
is NOT a rocket science.
 
Why then so-called Y.1541 QOS value-based implementation-specific model is
drawn in the same level like that of non-value-based
non-implementation-based DiffServ and RSVP for interworking? It will NEVER
interwork.
 
Why do they need to be done in the same draft creating a problem of
generalization between apples and oranges?
 
The issue is interworking of the QSPEC template carry the QOS parameters:
Value-based and Non-Value-based.
 
Radhika

________________________________________
From: [email-masked] [mailto:[email-masked]]
Sent: Thu 10/19/2006 7:58 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [NSIS] I-D ACTION:draft-ietf-nsis-qspec-12.txt
I've got to agree with Chuck on this.   How Y.1541 fufills QoS classes is
not an NSIS issue.  I think it is clear how to carry them, but how the
domain deploying Y.1541 verifies things are fufilled is outslide of NSIS.
 
John