Subject: [NSIS] severe change on QoS Model definition and capabilities

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 22 Dec 2006 03:55:33 +0000

Hi all

Version 13 of the QSPEC template draft introduces a severe change in the
capabilities and definition of a QoS Model.
This implies that a lot of work that has been done until now on QoS
models might be considered to be useless.

These changes are related to the following text that is included in
Section 4.1 of version 13 of the QSPEC template draft:

"QOSMs affect the operation of the RMF in NSIS-capable nodes, the
   information carried in QSPEC objects, and may under some
   circumstances (e.g. aggregation) cause a separate NSLP session to be
   instantiated by having the RMF as a QNI. QOSMs all utilize the common
   data, state machines, and APIs of the underlying NSIS protocols and
   are not expected to re-define or extend these in any way.", from
draft-ietf-nsis-qspec-13.txt

The changes are also related to the fact that the following QoS Model
capability that was supported by all the previous versions of the QSPEC
template draft is currently removed:
"- it specifies how to use QOS NSLP to signal for this QOSM"

My proposal is to either reuse the QoS model definition (including
apabilities) that was given in the previous versions of the QSPEC
template draft or use the following QoS Model definition that is
currently given in the QOS-NSLP draft.
Anyway, I believe that the QoS-NSLP draft is responsible on specifying
what a QoS model is allowed to do and not the QSPEC template draft.

---------

"3.1.2.  QoS Models and QoS Specifications

   The QoS NSLP provides flexibility over the exact patterns of
   signaling messages that are exchanged. The decoupling of QoS NSLP and
   QSPEC allows the QoS NSLP to be ignorant about the ways in which
   traffic, resources, etc. are described, and it can treat the QSPEC as
   an opaque object.  Various QoS models can be designed, and these do
   not affect the specification of the QoS NSLP protocol. Only the RMF
   specific to a given QoS model will need to interpret the QSPEC.  The
   Resource Management Function (RMF) reserves resources for each flow.

   An ongoing effort attempts to specify a QSPEC template [I-D.ietf-
   nsis-qspec]. The QSPEC template contains object formats for generally
   useful elements of the QoS description, which is designed to ensure
   interoperability when using the basic set of objects.

   The QSPEC fulfills a similar purpose to the TSpec, RSpec and AdSpec
   objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC
   2210 [RFC2210]. At each QNE, the content of the QSPEC is interpreted
   by the Resource Management Function and the Policy Control Function
   for the purposes of traffic and policy control (including admission
   control and configuration of the packet classifier and scheduler).

   The QoS NSLP does not mandate any particular behavior for the RMF,
   instead providing interoperability at the signaling protocol level
   whilst leaving the validation of RMF behavior to contracts external
   to the protocol itself. The RMF may make use of various elements from
   the QoS NSLP message, not only the QSPEC object.

   Still, this specification assumes that resource sharing is possible
   between flows with the same SESSION_ID that originate from the same
   QNI or between flows with a different SESSION_ID that are related
   through the BOUND_SESSION_ID object. For flows with the same
   SESSION_ID, resource sharing is only applicable when the existing
   reservation is not just replaced (which is indicated by the REPLACE
   flag in the common header. We assume that the QoS model supports
   resource sharing between flows. A QoS Model may elect to implement a
   more general behavior of supporting relative operations on existing
   reservations, such as ADDING or SUBTRACTING a certain amount of
   resources from the current reservation. A QoS Model may also elect to
   allow resource sharing more generally, e.g., between all flows with
   the same DSCP.

   The QSPEC carries a collection of objects that can describe QoS
   specifications in a number of different ways. A generic template is
   defined in [I-D.ietf-nsis-qspec]. A QSPEC describing the resources
   requested will usually contain objects which need to be understood by
   all implementations, and it can also be enhanced with additional
   objects specific to a QoS model to provide a more exact definition to
   the RMF, which may be better able to use its specific resource
   management mechanisms (which may, e.g., be link specific) as a
   result.

  A QoS Model defines the behavior of the RMF, including inputs and
   outputs, and how QSPEC information is used to describe resources
   available, resources required, traffic descriptions, and control
   information required by the RMF. A QoS Model also describes the
   minimum set of parameters QNEs should use in the QSPEC when signaling
   about this QoS Model.

   QoS Models may be local (private to one network), implementation/
   vendor specific, or global (implementable by different networks and
   vendors).  All QSPECs must follow the QSPEC template [I-D.ietf-nsis-
   qspec].

   The definition of a QoS model may also have implications on how local
   behavior should be implemented in the areas where the QoS NSLP gives
   freedom to implementers. For example, it may be useful to identify
   recommended behavior for how a RESERVE message that is forwarded
   relates to that received, or when additional signaling sessions
   should be started based on existing sessions, such as required for
   aggregate reservations. In some cases, suggestions may be made on
   whether state that may optionally be retained should be held in
   particular scenarios.  A QoS model may specify reservation
   preemption, e.g., an incoming resource request may cause removal of
   an earlier reservation." from draft-ietf-nsis-qos-nslp-12.txt.

Best Regards,
Georgios

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

---

From: "Roy, Radhika R." <[email-masked]>
Date: Thu, 21 Dec 2006 23:20:00 -0500

Georgios:
 
Definitely, you have raised the most important point. Again, it is not an isolated case. I agree with you.
 
Let me rephrase it. What is this QSPEC draft for? Is it not a template of QOS parameters? If it is so, why does it deal with how a OQS model should use this QSPEC template does not have any knowledge how a QOS model works or how QOS-NSLP will instruct QOS models to use the QSPEC template based on the circumstances (e.g., applications' needs, networks' needs, etc.)?
 
Now, you can see why we are saying that this draft must NOT deal with any extensions of any parameters for using by any specific QOS SLAs like so-called non-standard Y.1451, DSTE, etc.
 
More is coming on this ...
 
Thanks to you for reading this highly confused and technically inconsistent draft so carefully. More importantly, when people want to mix between "apples" and "oranges" using brutal force ignoring all technical justification just because they have been the EDITORs (God knows why still they want to be the editors!!!) for the last couple of years, it will end like this.
 
Best regards,
Radhika
 
PS: 
 
1. There is also a new term "standard QSPEC." We will talk about this later as well.
 
2. We will talk about: What a QOS model is and what are its properties. Do Y.1451 and DSTE QOS SLA have the same properties like those of RSVP, DiffServ, and IntServ?
 
3. Do they use the brute force through technical misinterpretation of the very QOS model definition so that "apples" and "oranges" can be mixed?

________________________________

From: [email-masked] on behalf of Georgios Karagiannis
Sent: Thu 12/21/2006 10:55 PM
To: [email-masked]
Subject: [NSIS] severe change on QoS Model definition and capabilities

Hi all

---------

Best Regards,
Georgios

---

From: <[email-masked]>
Date: Fri, 22 Dec 2006 06:35:13 +0200

Georgios,

It might make some sense to attach some more technical reasoning
behind your request.  

>Version 13 of the QSPEC template draft introduces a severe 
>change in the capabilities and definition of a QoS Model.
>This implies that a lot of work that has been done until now 
>on QoS models might be considered to be useless.

Can you explain why you think this?

John

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 22 Dec 2006 07:05:03 +0000

Hi John

I do not understand your question.
Do you mean that no change is introduced in the QSPEC template draft or
do you mean why should the until now supported QoS Model and
capabilities should comply with the ones given in the previous versions
of the QoS Template draft.

If you refer to the latter, I think that the QSPEC template draft authors
should give a technical reasoning for doing this severe change in the
QoS Model definition and capabilities.
Please note that the QoS Model definition and capabilities given in the
previous versions of the QSPEC template draft and the QoS-NSLP draft are
supported by the NSIS WG group until now!

Best Regards,
Georgios