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

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 27 Jul 2006 09:27:20 +0100

jerry,

i think we are actually agreeing with each other, but I'm not
expressing myself very clearly. let me try a different tack.

1. one terminology issue (which may a general source of 
confusion) is that we tend to be a bit lax about saying
what "thing" the mandatory/optional distinction applies to -
QNIs, QNEs, QoSMs, reservations, whatever. IMHO in order to
achieve the interoperability goal (which is the main point)
the mandatory/optional wording applies to QNEs: in other
words, QNEs MUST understand and do something sensible with
the mandatory parameters whatever QoSM they support. I don't
see that it makes so much sense to say that a parameter is
mandatory or optional for a QoSM or for a QNI. (see further
below.)

whatever the actual resolution here, i think the Qspec could
do with more explanation of what 'mandatory' means conceptually.
and it may be that 'mandatory' is not a good word; perhaps 
something like 'basic' or 'fundamental' would be better.

2. to go to the first of your points below, my suggestion is
that QNEs MUST understand the mandatory parameters, but 
QoSMs do not have to use them if they do not want to. To me,
a QoSM is a document and a node is a piece of equipment;
we should specify what the equipment MUST do.

the underlying point here is: to what extent are we expecting
to define QNE behaviour by stating which QoSMs it supports.
I don't actually think this is entirely feasible. For example,
imagine a node that supports QoSMs A and B receiving a reservation
for QoSM C. It has to implement the reservation by using an
interpretation of the mandatory parameters in C, but which one
should it use? The one defined by A or the one defined by B?
Does it matter which? The only information propagated in the
reservation is that C was not supported, not which of A/B was
used as the definition for the mandatory parameter treatment.
So, all that matters here is that the QNE does something 
sensible with the parameter (and that is implicitly defined
in the Qspec itself).

to make a semi-sensible example: suppose you wanted to use
the QoS-NSLP to check for TCP QuickStart support along a 
path. Probably one would do this by defining a QuickStart
QoSM. Within that QoSM, none of the Qspec mandatory parameters
have any useful meaning, since QuickStart (AFAIK) just cares
about the existence of a traffic management mechanism. So,
saying that the QoSM MUST define a mapping for the mandatory
parameters does not seem reasonable. However, an actual node
MUST still support the mandatory parameters, so it can 
process a non-QuickStart reservation.

3. to go to the second point below, i think this is a matter
of phraseology. what i was trying to get at is that it might
be natural for a particular resource management mechanism
to be described in terms of (say) parameters X, Y and Z.
However, none of X/Y/Z relate directly to the existing 
Qspec parameters. Then, isn't it the case that we would expect
the QoSM authors to go back to the definitions of X, Y and
Z and say "aha, really this is equivalent to a token bucket
and a couple of other parameters P, Q" and to write the QoSM
document that way rather than directly in terms of X/Y/Z. 
in other words, the reformulation is a requirement on the
authors of new QoSMs, not on the QoSM itself.

sorry for such a long email,

r.

> -----Original Message-----
> From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
> Sent: 26 July 2006 14:15
> To: Hancock, Robert
> Cc: Ash, Gerald R (Jerry), ALABS; [email-masked]
> Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory 
> parameter list?
> 
> 
> Hi Robert,
> 
> I agree with most of what you said.  See below for a couple 
> of comments.
> 
> 
> > -----Original Message-----
> > 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]
> > Subject: RE: AW: [NSIS] Any resolution to the QSPEC mandatory 
> > parameter list?
> > 
> > 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"). 
> 
> 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
> > 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). 
> 
> 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
> > 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.
> 

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 29 Jul 2006 11:38:52 +0200

Hi Robert,

a minor comment below:

> process a non-QuickStart reservation.

This is somewhat a corner case given what I wrote in my previous mail.
The QSPEC template draft needs to indicate that this case can happen and 
hence it does not make sense to interpret mandatory parameters if there 
aren't any.

> authors of new QoSMs, not on the QoSM itself.

Alternatively, a QoSM could define how their parameters can be mapped to 
the mandatory parameters instead of rewriting the document to use 
different parameters since in most cases it is not just the terminology 
that is different (e.g., the name of the bandwidth parameter) but the 
range of possible might, for example, be different.

As an example: Every SDO uses some form of priority values. The name of 
the attribute is different and the number of possible priority values as 
well. Still, there might be a way to map them to the priority values 
defined in the QSPEC template.

When I tried to map the IEEE 802.16e QoS parameters to the parameters in 
the QSPEC template I had a really hard time because they did not match 
100%. Sure, you can attempt to use the QSPEC parmeters with some 
additional wording but try to convince folks in Wimax that this is a 
good approach.

Ciao
Hannes