Subject: [NSIS] QSPEC Issue #2 -- Remapping of QSPEC Parameters

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Mon, 14 Aug 2006 16:45:47 -0500

Hi All,

One of the issues identified in the updated 'QoS NSLP QSPEC Template'
I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is
as follows:

2. agreement/consensus on what is allowed by remapping QSPEC parameters;
see Section 4.3.1

There was extensive discussion on the list RE remapping QSPEC
parameters.  Various examples of such remapping are given in Section
4.3.1.  It is further required that procedures for any such remapping
must be documented in a QOSM specification document, and any remapped
parameter must be flagged with the "Remapped Parameter R-flag", as
specified in the QSPEC draft.

The common example used in the QSPEC I-D is remapping of a <Token
Bucket> parameter to a <Bandwidth> parameter, which is straightforward.
However, what should be allowed in the general case is unclear, such as
whether to allow remapping between QSPEC parameter types, e.g.,
remapping <QoS Class> to a <Token Bucket>.  Indeed, the remapping
concept may be a bit theoretical and some remappings would probably not
make sense.

A proposed resolution is to give a few examples of remapping, as
currently included in Section 4.3.1, and specify the above requirements
for the QOSM specification document and setting of the R-flag.  It is
further proposed in Section 4.3.1 that "We should have a separate
document that defines typical remapping of QSPEC parameters, perhaps
included in a QOSM definition document.  This is to avoid
misinterpretation of what is allowed by remapping QSPEC parameters."

Please express any further comments in support of the proposed
resolution, or otherwise, so that we may reach consensus on this issue.

Thanks,
Regards,
Jerry

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 25 Aug 2006 11:53:57 +0200

Hi Jerry

I agree on the need of including the "Remapped Parameter R-flag".

However, I would very much appreciate if you could change the text in
Section 4.3.2, page 15:
In the last paragraph of bullet a) you mentioned:
"The local QSPEC is interpreted by the QNEs in the local domain, and the
egress QNE in the local domain pops the local QSPEC and populates token
bucket in the initiator QSPEC with just the bandwidth parameter for the
token bucket (and not the other token bucket parameters)."

I would very much appreciate if the remapping procedure (at the ingress and
egress) should be 
Defined by the QoS models.

You could for example replace the above sentence with:
"The local QSPEC is interpreted by the QNEs in the local domain, and the
egress QNE in the local domain pops the local QSPEC and remaps the bandwidth
parameter into the token bucket parameter in the initiator QSPEC."

Best regards,
Georgios

-----Original Message-----
From: Ash, Gerald R (Jerry), ALABS [mailto:[email-masked]] 
Sent: maandag 14 augustus 2006 23:46
To: [email-masked]
Cc: Ash, Gerald R (Jerry), ALABS
Subject: [NSIS] QSPEC Issue #2 -- Remapping of QSPEC Parameters

Hi All,

One of the issues identified in the updated 'QoS NSLP QSPEC Template'
I-D http://www.ietf.org/internet-drafts/draft-ietf-nsis-qspec-11.txt is as
follows:

2. agreement/consensus on what is allowed by remapping QSPEC parameters; see
Section 4.3.1

There was extensive discussion on the list RE remapping QSPEC parameters.
Various examples of such remapping are given in Section 4.3.1.  It is
further required that procedures for any such remapping must be documented
in a QOSM specification document, and any remapped parameter must be flagged
with the "Remapped Parameter R-flag", as specified in the QSPEC draft.

The common example used in the QSPEC I-D is remapping of a <Token
Bucket> parameter to a <Bandwidth> parameter, which is straightforward.
However, what should be allowed in the general case is unclear, such as
whether to allow remapping between QSPEC parameter types, e.g., remapping
<QoS Class> to a <Token Bucket>.  Indeed, the remapping concept may be a bit
theoretical and some remappings would probably not make sense.

A proposed resolution is to give a few examples of remapping, as currently
included in Section 4.3.1, and specify the above requirements for the QOSM
specification document and setting of the R-flag.  It is further proposed in
Section 4.3.1 that "We should have a separate document that defines typical
remapping of QSPEC parameters, perhaps included in a QOSM definition
document.  This is to avoid misinterpretation of what is allowed by
remapping QSPEC parameters."

Please express any further comments in support of the proposed resolution,
or otherwise, so that we may reach consensus on this issue.

Thanks,
Regards,
Jerry