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

From: "Hancock, Robert" <[email-masked]>
Date: Wed, 26 Jul 2006 10:21:09 +0100

hi,

just to add my two [small currency units]: i also still think
that the mandatory/optional parameter concept is the right way
to proceed. it was developed in order to guarantee some minimal
level of interworking even if the flow path crosses some very
disparate set of regions with different QoS management techniques
without requiring a heavyweight implementation of all options in
each of them; at the same time, it allows for more optimised QoS
treatment in more homogeneous environments. we would have to 
think very carefully before concluding that there are alternative
solutions to that pair of problems.

it may be that there are some QoS models which don't need some of
the mandatory parameters. i don't see that as a problem; for 
those models, the parameter mapping that the model has to define
is just very simple (it is "ignore"). in other cases, they may
natively use some different formulation than the QSPEC mandatory 
parameters; in that case, the requirement to fit into the QSPEC
is that the parametrisation should be re-formulated into 
(existing mandatory parameter)+(new optional parameter). i think
that is a fair constraint to impose - it's just to stop there
developing 15 different ways of expressing the concept 'bandwidth'
and so on.

cheers,

robert h.

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: 25 July 2006 17:05
> To: Roland Bless
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory 
> parameter list?
> 
> 
> Hi Roland,
> 
> See below. 
> 
> > -----Original Message-----
> > 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,
> > 
> > > I've been off-list for the last 10 days and may have difficulties
> > > 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_ accommodate the key ideas of typical QOSMs.
> >
> > Now I'll repeat what I already said in Dallas:
> 
> Where/when did you say this, I don't recall hearing this 
> comment in the
> NSIS meetings, but maybe I missed it?
> 
> > 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. 
> 
> 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 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 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
> 
> > 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
> > 
> 
> _______________________________________________
> nsis mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nsis
> 

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

---

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

Hi Robert,

I agree with most of what you said.  See below for a couple of comments.

> From: Hancock, Robert [mailto:[email-masked]] 
> Sent: Wednesday, July 26, 2006 5:21 AM
> To: Ash, Gerald R (Jerry), ALABS; Roland Bless
> Cc: [email-masked]
> is just very simple (it is "ignore"). 

Right now it's not allowed to 'ignore' a mandatory parameter.  Section
4.2, 4th paragraph specifies:

"   Mandatory parameters provide a minimal subset of parameters. A
   QNE MUST either a) strictly interpret a mandatory parameter, or
   b) remap the parameter and raise the <NON QOSM HOP> flag defined in
   Section 5.1, where the remapping MUST be specified in the QOSM
   specification.  Here the terminology 'strictly interpret' means that
   the parameter is implemented according to the commonly accepted
   definition and/or as specified by references given for each QSPEC
   parameter.  This means that in case a), a <Token Bucket> parameter
   must be strictly interpreted as a token bucket.  However, in case b),
   a <token Bucket> parameter may be remapped, perhaps to a <Bandwidth>
   parameter." 

The above does not allow an option to 'ignore' a mandatory parameter.
However, there may be cases perhaps where a mandatory parameter must be
ignored by a QOSM.  In that case your suggestion may be a way to go: if
a mandatory QSPEC parameter must be ignored by a QOSM, that needs to be
specified in the QOSM specification document.  In that case the QOSM
would be allowed to set the N-flag ('not supported' flag) for the
mandatory parameter.  In that scenario (mandatory parameter is ignored)
the QNI most likely would reject the reservation anyway.

> in other cases, they may
> (existing mandatory parameter)+(new optional parameter). 

Such a mapping isn't allowed right now.  A mandatory parameter may be
remapped (and the remapping must be specified in the QOSM specification
document), but there is no such thing as remapping a mandatory parameter
into an optional parameter.  That sounds pretty complex IMO.

Thanks,
Jerry

> i think

---

From: Roland Bless <[email-masked]>
Date: Wed, 26 Jul 2006 15:47:07 +0200

Hi Robert,

> solutions to that pair of problems.

My misunderstanding was actually the scope of the
meaning of "mandatory". I thought it means mandatory for a
QoS model, not mandatory for all QOSMs.

> is just very simple (it is "ignore"). in other cases, they may

So the mandatory parameters are ignored in this particular
QOS...hmmm.

> (existing mandatory parameter)+(new optional parameter). i think

Ok, but then maybe new optional parameter means required for this
particular QOSM (i.e. mandatory within the QOSM). I also can think
of QOSMs that specify parameters as additional information which are
then optional within the QOSM itself. This is, however, not explicitly
expressed within the QSPEC syntax.

> developing 15 different ways of expressing the concept 'bandwidth'

That's fine.

Regards,
 Roland

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 26 Jul 2006 17:41:51 +0200

Hi all,

when I re-read the QSPEC template draft in detail this year again I was 
confused as well. Hence, we scheduled a breakfast meeting in Dallas to 
discuss various aspects. In many discussions a few things changed in the 
draft and I learned new things as well.

Here is what I understand, which seems to be different to Roberts and 
Rolands understanding:

* The QSPEC template draft defines mandatory QoS parameters. The meaning 
is that they must be understood by every QNE (not matter which QOSM they 
implement). It does not mean that every QOSM needs to carry all 
mandatory parameters. In fact it might not even carry a single one of 
them (I don't think that the QSPEC template draft talks about this aspect).

Small note: In a previous mailing list discussion I argued that the 
wording for 'mandatory parameter' is strictly speaking not realistic and 
I gave the example of interior nodes in an RMD domain. Let us see 
whether something will change with the next draft update.

I agree with Robert that the concept itself is very important. Defining 
mappings between different QOSMs is still useful (although not done 
today in NSIS). For example, there is no description of RMD to Y.1541 
QOSM mapping.

The choice of mandatory parameters is obviously extremely important to 
the usefulness of the entire concept. With the recent discussion it 
seems that the list of the mandatory parameters will become smaller. I 
am not sure we have already defined the minimum set of useful parameters.

What is missing today in QOSMs is a mapping of mandatory parameters to 
the QOSM behavior. If you look at the QOSMs being standardized today 
then they do not necessarily use all mandatory parameters. It is, IMHO, 
important to specify what a node that implements a particular QOSM would 
do when it receives a message with a QSPEC object that contains an 
unknown  QOSM. For example, what do all the currently specified 
mandatory parameters mean in the context of RMD? I have asked this 
question in the past already; I never saw an answer.

* The optional parameters in the QSPEC template draft only serve the 
purpose of a "common language for QoS parameters". This is not really 
important since a QOSM might want to describe their parameters anyway 
even if they are available in the QSPEC. The same is true for the 
parameter format.

Ciao
Hannes

---

From: Janet P Gunn <[email-masked]>
Date: Fri, 28 Jul 2006 18:32:50 -0400

I think that, if a QNE is allowed to "ignore" a Mandatory parameter, it
ceases to be "Mandatory" (at least as defined here).

It seems that the only two options for a QNE which receives a Mandatory
parameter are to "act on it as originally intended/defined" or "map it to
one of the other permitted values for that Mandatory parameter.

The example given was mapping between "bandwidth" and "token bucket" for
the "Traffic Description" mandatory parameter.  This means that every QNE
MUST support  either  "bandwidth" or "token bucket".  That SEEMS reasonable
to me.   If you don't support one, the QNE should map it into the other,
and then apply it.   This sounds OK too.

But  "Priority" is also a Mandatory parameter, and the two possibilities
are (Preemption Priority/Defending Priority ) and (Admission Priority (with
or without  RPH)).

First of all, I don't think it is reasonable to assume that EVERY QNE
supports either "Preemption/ Defending" or  "Admission Priority".  I think
it is quite likely that there will need to be QNEs that support neither
(possibly because of local laws or regulations).

Secondly, I do not think it is a good idea to have QNEs mapping arbitrarily
between the two cases.  Apart from anything else, if you map from
"preemption/defending" to "admission priority" in one local domain, and
then back to "preemption/defending" in another local domain,  it is going
to be very difficult to ensure that you end up with the original
"preemption" value, and the original "defending" value.

If the preemption and defending values are the same, you might be able to
carry it in the RPH.  But if the defending value is different, I don't see
how you would preserve it.

Thanks

Janet

--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit written
agreement or government initiative expressly permitting the use of e-mail
for such purpose.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

"Ash, Gerald R \(Jerry\), ALABS" <[email-masked]> wrote on 07/26/2006

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 28 Jul 2006 18:58:56 -0500

Janet,

See below. 

> From: Janet P Gunn [mailto:[email-masked]] 
> Sent: Friday, July 28, 2006 6:33 PM
> To: Ash, Gerald R (Jerry), ALABS
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]; Hancock,Robert

Agree.  However, they may be circumstances where it is necessary to
ignore a mandatory parameter (e.g., where preemption in illegal, see
below).
 
> how you would preserve it.

A few comments on the above:
1. I don't think there should be any remapping of parameters between
preemption/defending priority and admission/RPH priority. These are two
different things IMO and don't map to each other directly.
2. If it is illegal to use preemption (e.g., in the US PSTN), that is
probably sufficient reason to allow a QNE to ignore the parameter.
3. IMO <priority> should be mandatory.  For one thing, IntServ/RSVP uses
these parameters (preemption/defending; admission priority extension in
progress in TSVWG), and the set of mandatory parameters is based on
IntServ/DiffServ.

Thanks,
Jerry