Subject: [NSIS] Any resolution to the QSPEC mandatory parameter list?

From: Jukka MJ Manner <[email-masked]>
Date: Thu, 13 Jul 2006 17:18:57 +0300 (EEST)

I think the discussion on the mandatory and optional parameters ended
without a clear resolution. I think there were good notes on making the
list of mandatory parameters shorter and/or allow an "ignore"  
interpretation of a mandatory parameter, and other ways to make the
template less strict. I also support these comments.

Any views from the QSPEC people on how to resolve these comments?

Regards,
Jukka

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Jul 2006 16:25:25 +0200 (MEST)

Hi all

There are many discussion showing that the interpretation of mandatory
parameters
may problems. It has been requested to decrease the number of mandatory
parameters to 4. However, I think that such decissions cannot be made in
the QSpec template draft. It will be better that each QOSM specification
MUST specify which parameters are mandatory and which are optional.
Thus the QNEs that will support a QOSM will also have to support the
mandatory and optional parameters specified in each QOSM.

Thus my proposal is that the QSepc template should list the QSpec
parameters, but each QOSM specification MUST specify which of them are
mandatory and which are optional!

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 13 Jul 2006 16:42:11 +0200 (MEST)

Hi Jerry, Cornelia and Attila

Regarding downgrading the Token Bucket parameter. What does this exactly
mean?
When you remap the per flow token bucket to an aggregate token bucket.
Is this also a downgrade?

When a QNE is only using the token bucket burst size. Does this mean
downgrading?

When a QNE is only using the average rate from the Token Bucket. Does
this mean downgrading?

So, when a QNI receives the Token Bucket in the above examples with the R
bit flag set, how the QNI will know which of the token Bucket variables
where used during the downgrade?

What I would like to propose is a sentence like the following that can be
used in the QSpec template draft:

"Downgrading the Token Bucket means that the Token Bucket MUST be
remapped to Bandwidth."

Best Regards,
Georgios

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Thu, 13 Jul 2006 16:29:07 -0500

Hi Jukka,

See below. 

> -----Original Message-----
> From: Jukka MJ Manner [mailto:[email-masked]] 
> Sent: Thursday, July 13, 2006 10:19 AM
> To: [email-masked]
> Subject: [NSIS] Any resolution to the QSPEC mandatory parameter list?
> 
> 

I'm not in favor of fundamentally changing the definition of mandatory
and optional QSPEC parameters, as I think is being proposed.  In effect,
to allow a mandatory parameter to be ignored would eliminate the
distinction between mandatory parameters (MUST interpret if populated)
and optional parameters (SHOULD interpret if populated).  The original
idea of the QSPEC template is to provide a common set of mandatory
parameters that would be interpreted (if populated by the QNI) by all
QOSMs.  This would allow a degree of interoperability.  The set of
mandatory parameters is based in part on parameters from the INTSERV and
DIFFSERV models that should be commonly interpreted by all QOSMs (that
was the original charge to the QSPEC template draft approach).

The other alternative (i.e., to be able to 'ignore' mandatory
parameters) is essentially to make all parameters optional parameters
(SHOULD interpret if populated).  Optional parameters allow the N-flag
(not supported flag) to be set if a QOSM wishes to 'ignore' (not
interpret) a parameter.  

I'm not clear on the motivation for this other alternative.  Perhaps
some particular QOSM wants to introduce the possibility of 'ignoring'
mandatory parameters.  Y.1541-QOSM doesn't require this nor does the
CL-QOSM (AFAIK).  Perhaps the RMD-QOSM for some reason requires this --
if so, I'm not clear what is the justification?  

I haven't seen that much support for a major change in the QSPEC
template approach to be able to 'ignore' mandatory parameters.  

Thanks,
Jerry

---

From: Jukka MJ Manner <[email-masked]>
Date: Fri, 14 Jul 2006 00:46:30 +0300 (EEST)

Hi,

I think the problem is that setting too many mandatory parameters
effectively limits people to define new QOSMs (even the current ones) -
all QOSMs must be based on IntServ or DiffServ. Interworking is an
important issue, I fully agree. That is why I'm not sure which way we
should actually go: more or less mandatory parameters. (I think I'm
inclined towards more flexibility)

About the need for a change, I haven't seen any comment so far for keeping 
the longish list of mandatory parameters. All messages have been about 
introducing more flexibility. We should have had a hummm at the meeting to 
see what people would want.

Maybe people could speak up about what they want?

Jukka

---

From: Bernd Schloer <[email-masked]>
Date: Sat, 15 Jul 2006 19:32:06 +0200

Hi,

it would be easier to define new QOSMs, when the mapping of mandatory parameters 
is listed in a central draft. This would also ensure interoperability.

Bernd

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 15 Jul 2006 19:57:46 +0200

Hi 

Okay, but how many mandatory parameters should the central draft contain?

Best Regards,
Georgios 

-----Original Message-----
From: Bernd Schloer [mailto:[email-masked]] 
Sent: zaterdag 15 juli 2006 19:32
To: Jukka MJ Manner
Cc: Ash, Gerald R \(Jerry\), ALABS; [email-masked]
Subject: Re: [NSIS] Any resolution to the QSPEC mandatory parameter list?

Hi,

it would be easier to define new QOSMs, when the mapping of mandatory
parameters is listed in a central draft. This would also ensure
interoperability.

Bernd

Jukka MJ Manner wrote:
> effectively limits people to define new QOSMs (even the current ones) 
> - all QOSMs must be based on IntServ or DiffServ. Interworking is an 
> About the need for a change, I haven't seen any comment so far for 
> keeping the longish list of mandatory parameters. All messages have 
> been about introducing more flexibility. We should have had a hummm at 
> the meeting to see what people would want.
> 
>>>without a clear resolution. I think there were good notes on making 
>>>the list of mandatory parameters shorter and/or allow an "ignore"
>>and optional QSPEC parameters, as I think is being proposed.  In 
>>effect, to allow a mandatory parameter to be ignored would eliminate 
>>the distinction between mandatory parameters (MUST interpret if 
>>populated) and optional parameters (SHOULD interpret if populated).  
>>The original idea of the QSPEC template is to provide a common set of 
>>mandatory parameters that would be interpreted (if populated by the 
>>QNI) by all QOSMs.  This would allow a degree of interoperability.  
>>The set of mandatory parameters is based in part on parameters from 
>>the INTSERV and DIFFSERV models that should be commonly interpreted by 
>>all QOSMs (that was the original charge to the QSPEC template draft
approach).
>>CL-QOSM (AFAIK).  Perhaps the RMD-QOSM for some reason requires this 
>>-- if so, I'm not clear what is the justification?
>>

---

From: "Kappler, Cornelia" <[email-masked]>
Date: Mon, 17 Jul 2006 14:12:24 +0200

Dear all, 

I've been off-list for the last 10 days and may have difficulties grasping the real point of the debate. 

I'd prefer some concrete suggestions to which parameters should not be mandatory. Rather than blanket statements "List is too long" or "List is too short" or "we should have N parameters". 

The question is not really whether it should be 2 or 8 or 20 mandatory parameters. It is _which_ parameters are necessary to _just_ accomodate the key ideas of typical QOSMs. 

Cornelia

> -----Ursprüngliche Nachricht-----
> Von: Georgios Karagiannis [mailto:[email-masked]] 
> Gesendet: Samstag, 15. Juli 2006 19:58
> An: 'Bernd Schloer'; 'Jukka MJ Manner'
> Cc: 'Ash, Gerald R \(Jerry\), ALABS'; [email-masked]
> Betreff: RE: [NSIS] Any resolution to the QSPEC mandatory 
> parameter list?
> 
> Hi 
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 17 Jul 2006 15:07:44 +0200 (MEST)

Hi Cornelia

>From my point of view the only mandatory parameters are the Traffic
specification parameters i.e., <Token Bucket>, <Bandwidth> and the "Non
QoSM Hop", assuming that the QoS-NSLP will include the "non QoS-NSLP
Hop" parameter, see my previous e-mail on this!

Best regards,
Georgios

---

From: Roland Bless <[email-masked]>
Date: Tue, 25 Jul 2006 17:09:19 +0200

Hi all,

> grasping the real point of the debate.

Sorry, I missed the discussion, though we had some
informal discussion in Dallas one morning at a
roundtable :-)

> I'd prefer some concrete suggestions to which parameters should not
> be mandatory. Rather than blanket statements "List is too long" or
> "List is too short" or "we should have N parameters".
> 
> The question is not really whether it should be 2 or 8 or 20
> mandatory parameters. It is _which_ parameters are necessary to
> _just_ accomodate the key ideas of typical QOSMs.

Now I'll repeat what I already said in Dallas:
I'd prefer to not prescribe any mandatory parameters for all
QoS models. Thus I don't actually like the approach:
"Mandatory parameters in the QSPEC must be
meaningfully interpreted by all QNEs in the path, independent of
which QOSM they support." I disagree,
because we may have different QoS models that not even
require these parameters or future QoS models that require
even more mandatory parameters which are not covered by
the QSPEC template anyway. But trying to be constructive:
I would rather prefer to leave it up to each QoS model
which parameters are mandatory and which are not, like
defining a profile (e.g. similar to MPEG profiles).
Furthermore, interworking between different QoS models
can be defined that describes which parameters can
mapped onto which in the other QoSM.
I agree on this statement in the introduction:
"  A particular QOSM
   specifies a) a set of mandatory and optional QSPEC parameters, and
   b) how the QSPEC information is interpreted by the RMF with respect
   to the QoS description, resources desired, resources available, and
   control information."
The value of the QSPEC is still retained, because a QoSM only
needs to pick certain parameters of the QSPEC which are already
defined therein.

Just my two cents,
 Roland

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Tue, 25 Jul 2006 11:05:21 -0500

Hi Roland,

See below. 

> From: Roland Bless [mailto:[email-masked]] 
> Sent: Tuesday, July 25, 2006 11:09 AM
> To: Kappler, Cornelia
> Cc: Georgios Karagiannis; Bernd Schloer; Jukka MJ Manner; 
> Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: Re: AW: [NSIS] Any resolution to the QSPEC mandatory 
> parameter list?
> 
> Hi all,
> 
> > _just_ accommodate the key ideas of typical QOSMs.
>

Where/when did you say this, I don't recall hearing this comment in the
NSIS meetings, but maybe I missed it?

> the QSPEC template anyway. 

The concept is that a QNI initiates a reservation according to its QOSM.
It may populate one or more mandatory parameters, and perhaps some
optional parameters in its QSPEC object.  Mandatory parameters only must
be interpreted by downstream QNEs if populated by the QNI.  

Right now there are only 3 mandatory QoS description parameters:
<traffic>, <QoS class>, and <Priority> (see previous thread discussion
on this topic).  Several people agreed this is a minimal set of
mandatory parameters.  It seems to me that most QOSMs will want to
support some version of these 3 parameters.  They provide a common
language for QOSMs, based on IntServ and DiffServ, as originally agreed
in NSIS when the QSPEC was formulated.

If a local domain supports a different QOSM than the QNI QOSM, it may
remap (approximately interpret) the mandatory parameters that are
populated, and may ignore the optional parameters, and flag those
parameters it remaps or ignores.  The QNI makes a decision on whether to
accept or reject the reservation based on the RESPONSE.

If for example the QNI populates <Traffic> and the local domain QNEs
ignore <Traffic> (assuming that <Traffic> is not mandatory in the local
QOSM, as you propose), the QNI is going to probably reject the
reservation anyway.  At best, the reservation will not be what is
intended/desired by the QNI.

> But trying to be constructive:

I don't agree with this approach, I think it would be overly complex for
QOSMs to define all that detail for all 14 QSPEC parameters.  A also
don't think it would provide meaningful new functionality.  E.g., if
some QOSMs said <Traffic> is mandatory, and others said it was optional,
what would be the difference anyway if a local QOSM didn't support the
<Traffic> parameter as mandatory, if it was populated in the QNI-QSPEC?
The local domain would merely respond that it ignored the <Traffic>
parameter and the QNI would probably reject the reservation in any case.

If we decide to not have the mandatory/optional parameter concept, I
would prefer to just have all parameters be treated as 'optional', as
currently defined in the QSPEC document.

Thanks,
Jerry

---

From: Roland Bless <[email-masked]>
Date: Wed, 26 Jul 2006 14:02:08 +0200

Hi Jerry,

maybe I'm a little confused about what the mandatory concept
exactly means in the QSPEC document. I guess there are actually two
different meanings of "mandatory" intermixed in the document (or only
in my mind).
a) mandatory to be supported by _all_ QOSMs (that's how I read phrases
   like
   "Mandatory and optional QSPEC parameters provide a common
   language for QOSM developers to build their QSPECs and are likely to
   be re-used in several QOSMs." or
   "This is because mandatory
   parameters have been defined as a common language.  Therefore, a QNE
   MUST at least interpret all the mandatory parameters in a QSPEC even
   if it does not support the corresponding QOSM.")
b) mandatory parameter with respect to a specific a QoS model.

Maybe I have missed the point in the document which clearly or
explicitly says a). Most of the time my understanding was b).
It is perfectly fine to let a QOSM signal that a certain parameter is
mandatory to support for itself.

But I had concerns with this:

   Additional mandatory parameters may be defined in the future.
   However, since this requires an update of all QNEs, this should be
   considered carefully.  The definition of new mandatory parameter
   requires standards action and an update of this document.  Such an
   update also needs a new QSPEC version number.  Furthermore, all QOSM
   definitions must be updated to include how the new mandatory
   parameter is to be interpreted in the respective QOSM.

As far as I understand the spec now, it's like:
1) each QOSM specifies the required parameters
(mandatory for this particular QOSM) so each QOSM
implementation MUST understand and interpret these
parameters. Some of these parameters may be mandatory
in the QSPEC meaning and others are optional in the
QSPEC meaning but all are required (mandatory) for the
QOSM.
2) mandatory parameters are a means of interworking
between QOSMs.
3) there is no concept of having additional
   (optional) parameters within a QOSM.

See further comments inline.

> NSIS meetings, but maybe I missed it?

Not in the official NSIS meeting. We had an informal
discussion one morning before the sessions began in
the atrium. You were sitting directly next to me
IIRC. Hannes actually brought up the question.

> be interpreted by downstream QNEs if populated by the QNI.  

That's ok.

> in NSIS when the QSPEC was formulated.

That's fine. QSPEC should be a common language for QOSMs.
So if I need a bandwidth parameter, I know how to specify that.
But I simply don't want that the QSPEC states which of them
are mandatory for QOSMs. That should be specified by each QOSM
itself. IMHO it's useless to prescribe what should be mandatory
in the QSPEC, because future QOSMs may have even more mandatory
parameters which are not supported by older QOSMs anyway.
But maybe I'm only confused by terminology, what mandatory
actually means (see above).

> accept or reject the reservation based on the RESPONSE.

Ok, so:
if I populated a "mandatory by QSPEC" parameter,
it must be "understood" by the QOSM which may also
finally ignore it?

> intended/desired by the QNI.

My case was the other way around: If a future QOSM has a required
(mandatory in meaning b)) parameter that is not supported by other
QOSMs, the current mandatory parameter set by QSPEC doesn't help
anyway.

> QOSMs to define all that detail for all 14 QSPEC parameters.  A also

No, you only need to define what is actually mandatory or optional,
you don't need to list parameters that are not used by the QOSM.

> currently defined in the QSPEC document.

I guess it's fine to keep most of the stuff if that's the
consensus. Maybe there could
be clarifying text that "mandatory" actually means:
mandatory to be understood and supported by all QOSMs
and not mandatory within the QOSM itself.

Regards,
 Roland

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 26 Jul 2006 08:19:21 -0500

Hi Roland,

See below. 

> Sent: Wednesday, July 26, 2006 8:02 AM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: [email-masked]

Yes, the document clearly is specifying (a).  See, for example, Section
4.4.1, which pretty clearly defines mandatory and optional parameters.
I don't think this at all implies interpretation (b).  I don't know
where in the document you see any hint of interpretation (b)?
 
> QSPEC meaning but all are required (mandatory) for the

Again, this is not at all the definition in the document (see Section
4.4.1).  Where in the document does it say anything like this?

> 2) mandatory parameters are a means of interworking

Right.

>    (optional) parameters within a QOSM.

What does this mean?  There certainly is a concept of having additional
optional parameters within a QOSM (and a QOSM specification can define
additional optional parameters).
 
> IIRC. Hannes actually brought up the question.

Roland, that meeting in the atrium was in Dallas (IETF-65).  I do recall
of course sitting next to you at that meeting, but I don't recall any
discussion on the number of mandatory parameters (perhaps I missed it).
However, I heard no discussion of this topic in Montreal (IETF-66).
 
> it must be "understood" by the QOSM which may also

Right now it is not allowed to 'ignore' a mandatory QSPEC parameter, it
MUST be interpreted.
 
> and not mandatory within the QOSM itself.

We can try to clarify the text.  Please let us know if you have
suggested clarifying text (this would be especially helpful in the
place(s) in the document where you have inferred interpretation (b)).

Thanks,
Regards,
Jerry

---

From: <[email-masked]>
Date: Thu, 27 Jul 2006 02:14:14 +0300

Hi all,

Just bumping up a bit.  

Generally, QoS models will address specific QoS deployements (at least
mostly currently defined by different SDOs). These QoS Models don't
necessarily scale or are applicable Internet-wide.  (this is a rough
generalization).

In order to ensure some level of interopation, the Qspec contain should
contain some basic information understood by all QoSM's so that
signaling between different QoS deployments is possible.  

I don't (currently) think it is possible to define 1 universal QoSM -
but the Qspec should define a basic template for signaling QoS across
the Internet and different deployments.

The Mandatory parameter SHOULD (well, MUST) be understood by the
different QoSMs - enough so they can either accept or reject a certain
QoS flow.

John

>From: ext Roland Bless [mailto:[email-masked]] 
>Sent: 25 July, 2006 11:09
>To: Kappler, Cornelia
>Cc: Georgios Karagiannis; Jukka MJ Manner; [email-masked]; 
>Ash,Gerald R ALABS
>Sorry, I missed the discussion, though we had some informal 
>discussion in Dallas one morning at a roundtable :-)
>
>> I'd prefer some concrete suggestions to which parameters 
>should not be 
>> mandatory. Rather than blanket statements "List is too long" 
>or "List 
>> is too short" or "we should have N parameters".
>> 
>mandatory 
>> parameters. It is _which_ parameters are necessary to _just_ 
>> accomodate the key ideas of typical QOSMs.
>
>"Mandatory parameters in the QSPEC must be meaningfully 
>interpreted by all QNEs in the path, independent of which QOSM 
>they support." I disagree, because we may have different QoS 
>models that not even require these parameters or future QoS 
>models that require even more mandatory parameters which are 
>not covered by the QSPEC template anyway. But trying to be 
>constructive:
>I would rather prefer to leave it up to each QoS model which 
>parameters are mandatory and which are not, like defining a 
>profile (e.g. similar to MPEG profiles).
>Furthermore, interworking between different QoS models can be 
>defined that describes which parameters can mapped onto which 
>in the other QoSM.
>needs to pick certain parameters of the QSPEC which are 
>already defined therein.
>
>Just my two cents,
> Roland
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 31 Jul 2006 16:35:22 +0200 (MEST)

Hi John

Actually I agree with the comment of Roland, however, if it is to use the
concept of understanding the basic information, then IMHO the basic
information should be as much as basic as possible, i.e., Token Bucket,
Bandwidth, Non QOSM Hop.
In addition by using the additional flags proposed by Jerry, including
the R (remapping bit) the QNI that initiated the end to end reservation
can detect which of the mandatory/optional parameters where tunneled,
remapped or not interpreted at all!

Best Regards,
Georgios