Re: draft-qosmodel-controlledload-04

Hi Jerry,

it is true that I haven't read the most recent QSPEC draft when I sent 
this mail. In the meanwhile I did. Please find a few comments below:

Ash, Gerald R (Jerry), ALABS wrote:
> Hi Hannes,
> 
> See below. 
> 
> 
>>-----Original Message-----
>>From: Hannes Tschofenig [mailto:Hannes.Tschofenig <at> gmx.net] 
>>Sent: Friday, June 30, 2006 8:43 AM
>>To: Bernd Schloer
>>Cc: nsis <at> ietf.org
>>Subject: Re: [NSIS] draft-qosmodel-controlledload-04
>>
>>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.
>>>
>>>Does a QOSM have to understand (and provide information about) all 
>>>mandatory 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.
> 
> 
> 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.

I don't understand this sentence. What does it mean that a QNI "SHOULD" 
populate parameters if applicable?

>    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

What is the difference  between 'strictly interpret' and 'interpret'? In 
the rest of the document you use 'interpret'.

>    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.
I noticed this text improvement and I am happy to see more text about it.

Still, I have some issues with the section:

I had a problem with this paragraph following the previous one in the 
section. The previous paragraph said
"
However, if a QSPEC arrives at a QNE that does
    not support the QOSM being signaled, it can still understand the
    QSPEC content, at least to a basic degree.
"

When I read through the text I got the impression that the two sections 
relate to each other and in fact they do not. Hence, I suggest to delete 
the previous paragraph since this one contains the info already. You 
might also want to delete the second paragraph as well since it is far 
too obvious to use RFC2119 language: If you don't support even a single 
QOSM then why are you a QOS NSLP node in the first place.

You might want to highlight the following sentence, tough:

"
A QNE MUST interpret all mandatory parameters from this document even
if it does not support the received QoS NSLP message with the indicated 
QOSM.
"

Here is my proposal for the section:

"
4.2 QSPEC Processing

    The QSPEC is opaque to the QoS NSLP processing.  The QSPEC control
    information and the QoS description are interpreted and MAY be
    modified by the RMF in a QNE (see description in [QoS-SIG]).

    The QSPEC contains a QOSM ID, i.e. information on what QOSM is being
    signaled by the QNI.  However, if a QSPEC arrives at a QNE that does
    not support the QOSM being signaled, it can still understand the
    QSPEC content, at least to a basic degree.  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.

    A QNE MUST either

    a) interpret a mandatory parameter carried in the QSPEC object, 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 'interpret' means that
    the parameter is implemented according to the references given for 
each QSPEC parameter.

    If a QSPEC arrives at a QNE that does not support the QOSM being
    signaled, it can still understand the QSPEC content, at least to a
    basic degree. Hence, with case (a), a <Token Bucket> parameter
    must be strictly interpreted as a token bucket.

    In case b), a <token Bucket> parameter may be remapped, perhaps to a
    <Bandwidth> parameter.
"

Btw, have you noticed that the draft has
* a <NON QOSM HOP> flag (Section 5.1)
* a <NON QOSM HOP> parameter (Section 7.2.1)

I think they refer to the same concept...

> 
>    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.

The text in the new draft has improved a lot.
Thanks for the update.

> 
> 
>>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".
> 
> 
> 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.

I understood the token bucket to bandwidth example.

Would the RMD draft, for example, list all mandatory parameters and 
indicate whether it can map them (and how) to parameters used in the RMD 
specification?

Do you think it is awfully realistic for all QNEs to understand all 
mandatory parameters? I could imagine that Attila and Georgios are not 
going to implement stateless interior QNEs in such a way that they 
understand all the mandatory QSPEC parameters. In fact they don't have 
todo it since only edge routers are likely to ever see QoS NSLP messages 
that contain QOSM IDs that they do not understand (otherwise something 
go terribly wrong).

Ciao
Hannes

> 
> Thanks,
> Jerry
>  
> 
>>Ciao
>>Hannes
>>
>>  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
> 
> 
>