Subject: [NSIS] Reintroduce QSPEC control information semantics back

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 8 Feb 2007 10:00:11 +0100

Hi all

I think that we have yet not solved the issue related to the fact that 
the QSPEC control information has been removed from the QSPEC template draft

In my opinion the concept of the QSPEC control information has been removed
from the current version of the QSPEC template draft.

This concept was included up to the previous version of the QSPEC template
draft and it is needed for the situations that this parameter is used for
providing signaling support for QSPEC/QOSM specific RMF functions, such as
initiation, refresh, release, modification for unidirectional and
bi-directional per traffic class RMF reservation states, per flow RMF
reservation states, per aggregated RMF reservation states, specified for
example, in [RMD-QOSM]. 

QSPEC control information examples used in RMD-QOSM are: <PHR container> and
<PDR container> <PHR container> = <Overload %>, <S>,<M>, 
   <Admitted Hops>, <B>, <Hop_U> <Time Lag> 

<PDR container> = <Overload %>  <S> <M> <Max 
   <Max Admitted Hops> <B> [<PDR Bandwidth>] For more details see: 
Sections 4.1.2 and 4.1.3 of:
http://www.watersprings.org/pub/id/draft-ietf-nsis-rmd-08.txt

The authors mentioned in previous e-mails that the QSPEC control information
concept is not removed but it is renamed to <Traffic Handling Directives>. 

If that is the case then the authors of the QSPEC draft will have to use the
same semantics for the QSEPC control information as used in the previous
versions of the QSPEc template draft.

Thus my proposal is to change section 4.3.3 as given in v.13 of the QSEPC
template draft and include the general concept of the QSPEC control
information that was given in Section 5.3.1 of version 12 of the QSEPC
template draft. Note that the name can be changed but the semantics should
remain the same. Thus please change Section 4.3.3 as follows:

FROM:

4.3.3 Traffic Handling Directives

   The <Excess Treatment> parameter describes how the QNE will process
   excess traffic, that is, out-of-profile traffic.  Excess traffic MAY
   be dropped, shaped and/or remarked. The excess treatment parameter is
   initially set by the QNI and cannot be overwritten.

INTO:

4.3.3  Traffic Handling Directives

The <Traffic Handling Directives> parameter is used for providing support
for 
QSPEC/QOSM specific RMF functions, such as initiation, refresh, release, 
modification for unidirectional and
bi-directional: per traffic class RMF reservation states, 
per flow RMF reservation states, per aggregated RMF reservation states, 
specified for example, in [RMD-QOSM].

An example of the <Traffic Handling Directives> parameter is 
the <Excess Treatment> parameter, see below:

   <Traffic Handling Directives> = <Excess Treatment>

   The <Excess Treatment> parameter describes how the QNE will process
   excess traffic, that is, out-of-profile traffic.  Excess traffic MAY
   be dropped, shaped and/or remarked. The excess treatment parameter is
   initially set by the QNI and is read-only.

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

Best Regards,
Georgios

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

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Thu, 8 Feb 2007 14:21:56 +0100

Hi Jerry and All, is it acceptable to introduce the text proposed by Georgios, or a similar one?

Best regards, Attila

-----------

The <Traffic Handling Directives> parameter is used for providing support for QSPEC/QOSM specific RMF functions, such as initiation, refresh, release, modification for unidirectional and
bi-directional: per traffic class RMF reservation states, per flow RMF reservation states, per aggregated RMF reservation states, specified for example, in [RMD-QOSM].

An example of the <Traffic Handling Directives> parameter is the <Excess Treatment> parameter, see below:

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

>-----Original Message-----
>From: Georgios Karagiannis [mailto:[email-masked]] 
>Sent: Thursday, February 08, 2007 10:00 AM
>To: [email-masked]
>Subject: [NSIS] Reintroduce QSPEC control information semantics back
>
>Hi all
>
>I think that we have yet not solved the issue related to the 
>fact that the QSPEC control information has been removed from 
>the QSPEC template draft
>
>In my opinion the concept of the QSPEC control information has 
>been removed from the current version of the QSPEC template draft.
>
>This concept was included up to the previous version of the 
>QSPEC template draft and it is needed for the situations that 
>this parameter is used for providing signaling support for 
>QSPEC/QOSM specific RMF functions, such as initiation, 
>refresh, release, modification for unidirectional and 
>bi-directional per traffic class RMF reservation states, per 
>flow RMF reservation states, per aggregated RMF reservation 
>states, specified for example, in [RMD-QOSM]. 
>
>QSPEC control information examples used in RMD-QOSM are: <PHR 
>container> and <PDR container> <PHR container> = <Overload %>, 
><S>,<M>, 
>The authors mentioned in previous e-mails that the QSPEC 
>control information concept is not removed but it is renamed 
>to <Traffic Handling Directives>. 
>
>If that is the case then the authors of the QSPEC draft will 
>have to use the same semantics for the QSEPC control 
>information as used in the previous versions of the QSPEc 
>template draft.
>
>Thus my proposal is to change section 4.3.3 as given in v.13 
>of the QSEPC template draft and include the general concept of 
>the QSPEC control information that was given in Section 5.3.1 
>of version 12 of the QSEPC template draft. Note that the name 
>can be changed but the semantics should remain the same. Thus 
>please change Section 4.3.3 as follows:
>
>FROM:
>
>The <Traffic Handling Directives> parameter is used for 
>providing support for QSPEC/QOSM specific RMF functions, such 
>as initiation, refresh, release, modification for unidirectional and
>bi-directional: per traffic class RMF reservation states, per 
>flow RMF reservation states, per aggregated RMF reservation 
>states, specified for example, in [RMD-QOSM].
>

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Fri, 9 Feb 2007 06:45:33 -0600

Georgios, All,

Regarding your proposed text for Section 4.3.3 Traffic Handling Directives in http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-14.txt:

"The <Traffic Handling Directives> parameter is used for providing signaling support for QSPEC/QOSM specific RMF functions, such as initiation, refresh, release, modification for unidirectional and bi-directional: per traffic class RMF reservation states, per flow RMF reservation states, per aggregated RMF reservation states, specified for example, in [RMD-QOSM]."

Dave commented in an earlier email that "I think it's a mistake to insert RMD-specific text in the QSPEC document the way this does. It also puts the excess-treatment parameter in the "QOSM-specific" bag, which is certainly is not."

I agree with Dave.  Furthermore, the references to 'signaling support' and 'reservation states' are problematic because of all our extensive discussions and current agreements RE 'QoS NSLP specifies NSIS QoS signaling' and an 'RMF/QSPEC/QOSM should not modify the QoS NSLP state machine'.  It's déjà vu all over again with this text, let's not restart the same discussion.

We (co-authors) agree that descriptive text of what Traffic Handling Directives are would certainly be preferable, how about this rewrite of Section 4.3.3:

"An application MAY like to reserve resources for packets and also specify a specific traffic handling behavior, such as <Excess Treatment>. In addition, an application MAY like to define RMF triggers that cause the QoS NSLP to run semantics within the underlying QoS NSLP signaling state and messaging processing rules, as defined in Section 5.2 of [QoS-SIG].  Note, however, that new QoS NSLP message processing rules can only be defined in Standards Track extensions to the QoS NSLP.

As with constraints parameters and other QSPEC parameters, traffic-handling-directives parameters may be defined in QOSM specifications in order to provide support for QOSM-specific resource management functions.  Such QOSM-specific parameters are already defined, for example, in [RMD-QOSM], [CL-QOSM] and [Y.1541-QOSM].

The <Excess Treatment> parameter describes how the QNE will process excess traffic, that is, out-of-profile traffic.  Excess traffic MAY be dropped, shaped and/or remarked. The excess treatment parameter is initially set by the QNI and cannot be overwritten."

Is it OK?

Thanks,
Jerry

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: Thursday, February 08, 2007 4:00 AM
To: [email-masked]
Subject: [NSIS] Reintroduce QSPEC control information semantics back

Hi all

FROM:

INTO:

Best Regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 9 Feb 2007 15:30:02 +0100

Hi Jerry

Before answering can you please inform me if 
the RMD-QOSM QSPEC parameters: <PHR container> and <PDR container>, 
see my previous e-mail, can then be seen as
<Traffic Handling Directives> QSPEC parameters.

If yes, then I agree with the text that you proposed!

Best Regards,
Georgios

> From: ASH, GERALD R (JERRY), ATTLABS [mailto:[email-masked]] 
> Sent: vrijdag 9 februari 2007 13:46
> To: Georgios Karagiannis; [email-masked]
> Cc: ASH, GERALD R (JERRY), ATTLABS; Attila Báder (IJ/ETH); 
> [email-masked]; Kappler, Cornelia
> Subject: RE: [NSIS] Reintroduce QSPEC control information 
> semantics back
> 
> Georgios, All,
> 
> Regarding your proposed text for Section 4.3.3 Traffic 
> Handling Directives in 
> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-14.txt:
> 
> "The <Traffic Handling Directives> parameter is used for 
> providing signaling support for QSPEC/QOSM specific RMF 
> functions, such as initiation, refresh, release, modification 
> for unidirectional and bi-directional: per traffic class RMF 
> reservation states, per flow RMF reservation states, per 
> aggregated RMF reservation states, specified for example, in 
> [RMD-QOSM]."
> 
> Dave commented in an earlier email that "I think it's a 
> mistake to insert RMD-specific text in the QSPEC document the 
> way this does. It also puts the excess-treatment parameter in 
> the "QOSM-specific" bag, which is certainly is not."
> 
> I agree with Dave.  Furthermore, the references to 'signaling 
> support' and 'reservation states' are problematic because of 
> all our extensive discussions and current agreements RE 'QoS 
> NSLP specifies NSIS QoS signaling' and an 'RMF/QSPEC/QOSM 
> should not modify the QoS NSLP state machine'.  It's déjà vu 
> all over again with this text, let's not restart the same discussion.
> 
> We (co-authors) agree that descriptive text of what Traffic 
> Handling Directives are would certainly be preferable, how 
> about this rewrite of Section 4.3.3:
> 
> "An application MAY like to reserve resources for packets and 
> also specify a specific traffic handling behavior, such as 
> <Excess Treatment>. In addition, an application MAY like to 
> define RMF triggers that cause the QoS NSLP to run semantics 
> within the underlying QoS NSLP signaling state and messaging 
> processing rules, as defined in Section 5.2 of [QoS-SIG].  
> Note, however, that new QoS NSLP message processing rules can 
> only be defined in Standards Track extensions to the QoS NSLP.
> 
> As with constraints parameters and other QSPEC parameters, 
> traffic-handling-directives parameters may be defined in QOSM 
> specifications in order to provide support for QOSM-specific 
> resource management functions.  Such QOSM-specific parameters 
> are already defined, for example, in [RMD-QOSM], [CL-QOSM] 
> and [Y.1541-QOSM].
> 
> The <Excess Treatment> parameter describes how the QNE will 
> process excess traffic, that is, out-of-profile traffic.  
> Excess traffic MAY be dropped, shaped and/or remarked. The 
> excess treatment parameter is initially set by the QNI and 
> cannot be overwritten."
> 
> Is it OK?
> 
> Thanks,
> Jerry
> 
> 
> In my opinion the concept of the QSPEC control information 
> has been removed from the current version of the QSPEC template draft.
> 
> container> and <PDR container> <PHR container> = <Overload 
> %>, <S>,<M>, 
> of the QSEPC template draft and include the general concept 
> of the QSPEC control information that was given in Section 
> 5.3.1 of version 12 of the QSEPC template draft. Note that 
> the name can be changed but the semantics should remain the 
> same. Thus please change Section 4.3.3 as follows:
> 
> FROM:
>

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Fri, 9 Feb 2007 10:00:29 -0600

Georgios,

> <Traffic Handling Directives> QSPEC parameters.

Yes, I can certainly see the RMD-QOSM draft defining these as <Traffic
Handling Directives> QSPEC parameters.  Of course these parameters, as
with all other QSPEC parameters, are all subject to the same caveats
mentioned in the suggested text for Section 4.3.3 (e.g., 'new QoS NSLP
message processing rules can only be defined in Standards Track
extensions to the QoS NSLP').
 
> If yes, then I agree with the text that you proposed!

OK, good.

Thanks,
Jerry

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Fri, 9 Feb 2007 18:08:07 -0600

Hi All,

Below is a summary of the recently agreed-to updates to the -14 QSPEC
document http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-14.txt.
Hopefully we can now proceed with the -15 QSPEC revision and then go to
working group last call.

Please review and signify either a) your agreement and/or b) any further
comments or suggestions.

Thanks,
Jerry

1. Section 4.1 (QoS Models), 2nd paragraph, 2nd sentence:

Change
"QOSMs all utilize the common data, state machines, and APIs of the
underlying NSIS protocols and are not expected to re-define or extend
these in any way."

to
"QOSMs all utilize the common data, QoS NSLP state machines, and APIs of
the underlying NSIS protocols and are not expected to re-define or
extend these in any way."

2. Section 4.1 (QoS Models), add this text following the 2nd paragraph:

"QOSM specifications may define RMF triggers that cause the QoS NSLP to
run semantics within the underlying QoS NSLP signaling state and
messaging processing rules, as defined in Section 5.2 of [QoS-SIG].  New
QoS NSLP message processing rules can only be defined in Standards Track
extensions to the QoS NSLP.  If a QOSM specification defines triggers
that deviate from existing standard QoS NSLP processing rules (must be
standards track in that case), the fallback for QNEs not supporting that
QOSM is to use the standard QoS NSLP state transition/message processing
rules."

3. Section 4.3.3 (Traffic Handling Directives), rewrite this section as
follows:

"4.3.3 Traffic Handling Directives

An application MAY like to reserve resources for packets and also
specify a specific traffic handling behavior, such as <Excess
Treatment>. In addition, an application MAY like to define RMF triggers
that cause the QoS NSLP to run semantics within the underlying QoS NSLP
signaling state and messaging processing rules, as defined in Section
5.2 of [QoS-SIG].  Note, however, that new QoS NSLP message processing
rules can only be defined in Standards Track extensions to the QoS NSLP.

As with constraints parameters and other QSPEC parameters,
traffic-handling-directives parameters may be defined in QOSM
specifications in order to provide support for QOSM-specific resource
management functions.  Such QOSM-specific parameters are already
defined, for example, in [RMD-QOSM], [CL-QOSM] and [Y.1541-QOSM].

The <Excess Treatment> parameter describes how the QNE will process
excess traffic, that is, out-of-profile traffic.  Excess traffic MAY be
dropped, shaped and/or remarked. The excess treatment parameter is
initially set by the QNI and cannot be overwritten."

4. Sections 5.3.1, 5.3.2, 5.3.3, add the following paragraph at the end
of each section:
 
"Regarding <Traffic Handling Directives>, the default rule is that all
QSPEC parameters that have been included in the RESERVE message by the
QNI are also included in the RESPONSE message by the QNR with the value
they had when arriving at the QNR.  When traveling in the RESPONSE
message, all <Traffic Handling Directives> parameters are read-only.
Note that a QOSM specification may define its own <Traffic Handling
Directives> parameters and processing rules."

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 12 Feb 2007 10:21:53 +0100

Hi Jerry

Great!
Assuming that all other of my comments are worked out then I think then that
all QSPEC open issues are closed!

Best regards,
Georgios

> Sent: vrijdag 9 februari 2007 17:00
> To: Georgios Karagiannis
> Cc: ASH, GERALD R (JERRY), ATTLABS; [email-masked]
> > Before answering can you please inform me if the RMD-QOSM QSPEC 
> > parameters: <PHR container> and <PDR container>, see my previous 
> > e-mail, can then be seen as <Traffic Handling Directives> QSPEC 
> > parameters.
> 
> Yes, I can certainly see the RMD-QOSM draft defining these as 
> <Traffic Handling Directives> QSPEC parameters.  Of course 
> these parameters, as with all other QSPEC parameters, are all 
> subject to the same caveats mentioned in the suggested text 
> for Section 4.3.3 (e.g., 'new QoS NSLP message processing 
> rules can only be defined in Standards Track extensions to 
> the QoS NSLP').
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 12 Feb 2007 10:51:39 +0100

Hi Jerry

I do not agree with the first update in Section 4.1, see below

> "QOSMs all utilize the common data, state machines, and APIs 
> of the underlying NSIS protocols and are not expected to 
> re-define or extend these in any way."
> 
> to
> "QOSMs all utilize the common data, QoS NSLP state machines, 
> and APIs of the underlying NSIS protocols and are not 
> expected to re-define or extend these in any way."

As you already proposed in the below e-mail you agreed to do the following
modification:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07586.html

Please CHANGE from:

> "QOSMs all utilize the common data, state machines, and APIs 
> of the underlying NSIS protocols and are not expected to 
> re-define or extend these in any way."

INTO:

Best regards,
Georgios

> Sent: zaterdag 10 februari 2007 1:08
> To: [email-masked]
> Cc: ASH, GERALD R (JERRY), ATTLABS
> Subject: [NSIS] Summary of Updates to QSPEC Document
> 
> Hi All,
> 
> Below is a summary of the recently agreed-to updates to the 
> -14 QSPEC document 
> http://ietf.org/internet-drafts/draft-ietf-nsis-qspec-14.txt.
> Hopefully we can now proceed with the -15 QSPEC revision and 
> then go to working group last call.
> 
> Please review and signify either a) your agreement and/or b) 
> any further comments or suggestions.
> 
> Thanks,
> Jerry
> 
> "QOSMs all utilize the common data, state machines, and APIs 
> of the underlying NSIS protocols and are not expected to 
> re-define or extend these in any way."
> 
> to
> "QOSMs all utilize the common data, QoS NSLP state machines, 
> and APIs of the underlying NSIS protocols and are not 
> expected to re-define or extend these in any way."
> 
> "QOSM specifications may define RMF triggers that cause the 
> QoS NSLP to run semantics within the underlying QoS NSLP 
> signaling state and messaging processing rules, as defined in 
> Section 5.2 of [QoS-SIG].  New QoS NSLP message processing 
> the QoS NSLP.  If a QOSM specification defines triggers that 
> deviate from existing standard QoS NSLP processing rules 
> (must be standards track in that case), the fallback for QNEs 
> not supporting that QOSM is to use the standard QoS NSLP 
> state transition/message processing rules."
> 
> An application MAY like to reserve resources for packets and 
> also specify a specific traffic handling behavior, such as <Excess
> that cause the QoS NSLP to run semantics within the 
> underlying QoS NSLP signaling state and messaging processing 
> rules, as defined in Section
> 5.2 of [QoS-SIG].  Note, however, that new QoS NSLP message 
> processing rules can only be defined in Standards Track 
> extensions to the QoS NSLP.
> 
> 4. Sections 5.3.1, 5.3.2, 5.3.3, add the following paragraph 
> at the end of each section:
>  
> "Regarding <Traffic Handling Directives>, the default rule is 
> that all QSPEC parameters that have been included in the 
> RESERVE message by the QNI are also included in the RESPONSE 
> message by the QNR with the value they had when arriving at 
> the QNR.  When traveling in the RESPONSE message, all 
> <Traffic Handling Directives> parameters are read-only.

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Mon, 12 Feb 2007 07:53:48 -0600

Georgios, All,

Well, the confusion is that we also had the 'Summary of QSPEC Call'
(point 2) from Martin, see
http://www1.ietf.org/mail-archive/web/nsis/current/msg07549.html:

">After all we agreed to these points that need to be changed in QSPEC  
 >or QoS NSLP document:
 ...

 > - The text in Section 4.1 "QoS Models", 2nd paragraph of the QSPEC  
 > draft needs to be changed so that "state machine" clearly references

 > to "QoS NSLP state machine"

 OK."

However, I'm OK with your comment/interpretation and will proceed
accordingly, unless someone objects.

Thanks,
Jerry

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: Monday, February 12, 2007 4:52 AM
To: ASH, GERALD R (JERRY), ATTLABS; [email-masked]
Subject: RE: [NSIS] Summary of Updates to QSPEC Document

Hi Jerry

> expected to re-define or extend these in any way."

As you already proposed in the below e-mail you agreed to do the
following
modification:
http://www1.ietf.org/mail-archive/web/nsis/current/msg07586.html

INTO:

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Tue, 13 Feb 2007 10:51:59 +0100

Hi Jerry

> However, I'm OK with your comment/interpretation and will 
> proceed accordingly, unless someone objects.
Thank you very much!

Best Regards,
Georgios

> Sent: maandag 12 februari 2007 14:54
> ">After all we agreed to these points that need to be changed 
> in QSPEC  >or QoS NSLP document:
>  ...
> 
>  > - The text in Section 4.1 "QoS Models", 2nd paragraph of 
> the QSPEC  > draft needs to be changed so that "state 
> machine" clearly references
> 
> However, I'm OK with your comment/interpretation and will 
> proceed accordingly, unless someone objects.
> 
> Thanks,
> Jerry
> 
> > "QOSMs all utilize the common data, QoS NSLP state 
> machines, and APIs 
> > Hopefully we can now proceed with the -15 QSPEC revision 
> and then go 
> > to working group last call.
> > 
> > Please review and signify either a) your agreement and/or b) any 
> > further comments or suggestions.
> > 
> > Thanks,
> > Jerry
> > 
> > "QOSMs all utilize the common data, QoS NSLP state 
> machines, and APIs 
> QoS NSLP 
> > to run semantics within the underlying QoS NSLP signaling state and 
> > messaging processing rules, as defined in Section 5.2 of 
> [QoS-SIG].  
> > New QoS NSLP message processing rules can only be defined 
> in Standards 
> > Track extensions to the QoS NSLP.  If a QOSM specification defines 
> > triggers that deviate from existing standard QoS NSLP 
> processing rules 
> > (must be standards track in that case), the fallback for QNEs not 
> > supporting that QOSM is to use the standard QoS NSLP state 
> > transition/message processing rules."
> > 
> > 3. Section 4.3.3 (Traffic Handling Directives), rewrite 
> this section 
> > as
> > follows:
> > 
> > that cause the QoS NSLP to run semantics within the underlying QoS 
> > NSLP signaling state and messaging processing rules, as defined in 
> > Section
> processing 
> > excess traffic, that is, out-of-profile traffic.
> > Excess traffic MAY be dropped, shaped and/or remarked. The excess 
> > treatment parameter is initially set by the QNI and cannot be 
> > overwritten."
> > 
> > 4. Sections 5.3.1, 5.3.2, 5.3.3, add the following paragraph at the 
> > end of each section:
> >  
> > QNI are also included in the RESPONSE message by the QNR with the 
> > value they had when arriving at the QNR.  When traveling in the 
> > RESPONSE message, all <Traffic Handling Directives> parameters are 
> > read-only.

---

From: "ASH, GERALD R \(JERRY\), ATTLABS" <[email-masked]>
Date: Wed, 14 Feb 2007 07:31:18 -0600

Georgios,

> Can I consider that you will include the following modification:

Yes, agree with the modification.  

I'll proceed with the QSPEC -15 revision now, given that there were no
further comments, suggestions, or objections on the summary.

Thanks,
Jerry

-----Original Message-----
From: Georgios Karagiannis [mailto:[email-masked]] 
Sent: Tuesday, February 13, 2007 4:52 AM
To: ASH, GERALD R (JERRY), ATTLABS; [email-masked]
Subject: RE: [NSIS] Summary of Updates to QSPEC Document

Hi Jerry

Thank you very much!

Best Regards,
Georgios