Subject: [NSIS] draft-qosmodel-controlledload-04

From: Bernd Schloer <[email-masked]>
Date: Thu, 29 Jun 2006 15:01:21 +0200

Hi,

the first open issue in the appendix B is about what to do with mandatory QSPEC 
parameters which are not needed for CLS.

Does a QOSM have to understand (and provide information about) all mandatory
parameters, even if they are not used? The QSPEC-draft says in section 5 that
all parameters listed in the next sections are mandatory. The QSPEC-draft also
says in section 4.1 that "a given QOSM defines which of the mandatory and
optional parameters it uses, ..."

Are there any specific parameters which makes the open issue B.1.1. clearer? 
Following the QSPEC-draft there doesn't seem to be a conflict, if nothing is
done with the unneeded parameters.

Thanks,
Bernd

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 30 Jun 2006 14:42:33 +0200

Hi Bernd,

Bernd Schloer wrote:
> Hi,
> 
> the first open issue in the appendix B is about what to do with 
> mandatory QSPEC parameters which are not needed for CLS.
> 
> parameters, even if they are not used?

I think the question is wrong. What about the following question:
"
Does a node that implements a particular QOSM has to understand all
mandatory parameters listed in the QSPEC template draft (even if the 
QOSM does not make use of them)?
"

The answer would be "YES" since the QSPEC template draft says that 
mandatory parameters have to be understood by every NSIS QoS node.

There is only the question what "understands" means.

Another possible question would be:
"
Does a node that implements a particular QOSM has to define mappings 
from all mandatory parameters listed in the QSPEC template draft to the 
QOSM draft (even if the QOSM does not make use of them)?
"

The answer is "I don't know".

Ciao
Hannes

  The QSPEC-draft says in section 5
> that
> Are there any specific parameters which makes the open issue B.1.1. 
> clearer? Following the QSPEC-draft there doesn't seem to be a conflict, 
> if nothing is

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Fri, 30 Jun 2006 11:01:05 -0500

Hi Hannes,

See below. 

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Friday, June 30, 2006 8:43 AM
> To: Bernd Schloer
> Cc: [email-masked]
> Subject: Re: [NSIS] draft-qosmodel-controlledload-04
> 
> Hi Bernd,
> 
> Bernd Schloer wrote:
> > Hi,
> > 
> > Does a QOSM have to understand (and provide information about) all 
> > mandatory parameters, even if they are not used?
> 

IMO you need to more carefully read the QSPEC I-D document.  All
mandatory QSPEC parameters that are populated in the QSPEC must be
interpreted by every QNE, which is explained in the QSPEC I-D:

It says in Section 4.4.1 (Mandatory and Optional QSPEC Parameters) of
the QSPEC I-D
http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-10.txt:

"  Mandatory QSPEC parameters are treated as follows:

   o A QNI SHOULD populate mandatory QSPEC parameters if applicable to
     the underlying QOSM.
   o QNEs MUST interpret mandatory QSPEC parameters, if signaled."

Furthermore, it says in Section 4.2 (QSPEC Processing):

"  a QNE
   MUST at least interpret all the mandatory parameters in a QSPEC even
   if it does not support the corresponding QOSM.

   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.

   In the latter case, the remapping of the <Token Bucket> to
   <Bandwidth> must be specified in the QOSM specification document.
   For example, QOSM X exclusively uses the parameter <Bandwidth>.  It
   must define a mapping of the mandatory parameter <Token Bucket>.
   The mapping consists of interpreting the Token Bucket Rate as
   the <Bandwidth> parameter and disregarding the other Token Bucket
   parameters.  Clearly, some information contained in the <Token
   Bucket> parameter is lost by this mapping, and the resulting QoS may
   not be quite what was intended by the QNI.  Therefore, QOSM X also
   specifies that the <NON QOSM HOP> flag be raised.  Thus, a QNE using
   QOSM X is able to make an informed decision whether to admit a
   reservation described in terms of <Token Bucket>, and at the same
   time (by means of <NON QOSM HOP>) signals to the QNI/QNR that the
   exact intention of the QNI may not be met."

I think this text is pretty clear as to what is required regarding
interpreting mandatory parameters.  If not, please suggest
clarifications.

> from all mandatory parameters listed in the QSPEC template 
> draft to the QOSM draft (even if the QOSM does not make use of them)?
> "
>

A QNE must interpret all mandatory parameters, if populated, as
explained in the above text I quoted.  If a QOSM re-maps a mandatory
QSPEC parameter, that re-mapping must be defined in the QOSM
specification.  As stated in Section 4.7 (QOSM Specification
Requirements):

"   A QOSM specification MUST define QSPEC parameter behavior for these
   cases: a) new optional QSPEC parameters the QOSM specification
   defines, and b) remapping of existing mandatory or optional QSPEC
   parameters, as described in Section 4.2.  Unless otherwise specified
   in the QOSM specification document, the behaviors to strictly
   interpret the mandatory and optional QSPEC parameters are defined in
   this document through the references to RFCs that precisely define
   the QSPEC parameter behaviors.  

   A QOSM specification MUST define how the mandatory parameters are to
   be mapped onto the QSPEC parameters used by the QOSM, however the
   mapping MAY result in slight modification to the intended
   specification when an exact mapping is not possible.  This definition
   MUST allow a QNE implementing this QOSM to make a decision as to
   whether a reservation described in terms of mandatory parameters can
   be admitted.  If for a particular mandatory parameter no mapping can
   be found that guarantees the desired QoS, the QNE is advised to raise
   the <NON QOSM HOP> flag.  In other words, for all mandatory
   parameters a mapping must be defined, but it is acknowledged that
   this mapping may result in slightly bending the original intention of
   the QNI."

I think this text is pretty clear as to what is required.  If not,
please suggest clarifications.

Thanks,
Jerry