Subject: [NSIS] updated comments on draft-ietf-nsis-qspec-13.txt

From: "Georgios Karagiannis" <[email-masked]>
Date: Mon, 22 Jan 2007 10:55:34 +0100

Hi all

After checking all the discussions that we have had in the 
nsis mailing list related to my comments on draft-ietf-nsis-qspec-13.txt
that 
I have sent on the 20th December 2006, I concluded that 
Most of my concerns are not yet solved.
Therefore, I will repeat my comments and I will try to provide 
a more detailed reasoning and argumentation.

Comment_1: Concept of QSPEC control information is removed
--------------
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 
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].

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.

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

Comment_2: The format that is required to specify the QSPEC control 
information is removed, see Section 7.1 of:
http://www.watersprings.org/pub/id/draft-ietf-nsis-qspec-12.txt

I think that this change will not have many consequences if the QOSM 
specifications will have the possibility to define their own 
<Traffic Handling Directives> parameters. 
Regarding to RMD-QOSM this means that the QSPEC 
parameters: <PHR container> and <PDR container> should be able 
to be specified in the RMD-QOSM specification.

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

Comment_3: The current version of the QSPEC template draft 
changed the definition of the QOS model, and the features that 
could be supported by a QOSM
----------
The main problem that I have with the QOSM definition given in the 
current version of the QSPEC template draft is related to the following:
Section 4.1 mentions:

"QOSMs affect the operation of the RMF in NSIS-capable nodes, the
   information carried in QSPEC objects, and may under some
   circumstances (e.g. aggregation) cause a separate NSLP session to be
   instantiated by having the RMF as a QNI. 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."

The last sentence is vague and one could interpret it as a limitation 
of what a QOSM is able to specify. As described in the QOS-NSLP draft 
the QOS-NSLP function, and thus also the QOS-NSLP state machine 
depends on the output events produced by the RMF operation. As already
 mentioned in this version of the QSPEC template draft the 
QOSMs affects the operation of the RMF in NSIS-capable nodes, thus the 
QOS-NSLP state machine can be affected in different ways by events 
generated by different RMFs.

Therefore, I would like that you add the following sentence after the 
second paragraph given in section 4.1:

 "However, the events generated by the operation of different RMFs may 
affect the QoS-NSLP common state machine in a different way. Therefore, 
a QOSM MUST define how and when the events generated by the RMF operation 
affect the operation of the QoS-NSLP state machine."

Furthermore, please add the following bullet in the list starting 
with the sentence "A QOSM specification MUST include the following":

"it specifies how and when the events generated by the RMF operation 
affect the QOS-NSLP state machine."

In order to motivate the above I will give two examples that could be 
used when for example, a new QOSM has to define the operation of a 
RMF that is similar to the RMF model defined in the RFC 3175 
(Aggregation of RSVP for IPv4 and IPv6 Reservations).
http://www.ietf.org/rfc/rfc3175.txt?number=3175

First example: 
Similar to the scenario given in "APPENDIX 1: Example Signalling 
Flow For First E2E Flow", specified in RFC 3175, the following scenario 
can be defined for NSIS. For more details on the RMF operation please see 
APPENDIX 1 of RFC 3175.
>From this example can be seen that the events of the RMF operation 
described for the below scenario will impact the QOS-NSLP processing 
from the point of view of when and how the different QUERY, RESERVE 
and RESPONSE messages have to be initiated and sent.

             Aggregator (ingress)          Deaggregator (Egress)

    E2E QUERY
   ---------------->
                (1)
                           E2E QUERY
                     ------------------------------->
                                                        (2)
                      E2E RESPONSE(New-agg-needed, DCLASS=x)
                     <-------------------------------
                      E2E RESPONSE(New-agg-needed, DCLASS=y)
                     <-------------------------------
                (3)
                           Aggregated QUERY(DSCP=x)
                     ------------------------------->
                           Aggregated QUERY(DSCP=y)
                     ------------------------------->
                                                        (4)
                                                           E2E QUERY
                                                           ----------->
                                                        (5)
                           Aggregated RESERVE (DSCP=x)
                     <-------------------------------
                           Aggregated RESERVE (DSCP=y)
                     <-------------------------------
               (6)
                           Aggregated RESPONSE (DSCP=x)
                     ------------------------------>
                           Aggregated RESPONSE (DSCP=y)
                     ------------------------------>
                                                        (7)
                                                           E2E RESERVE
                                                           <----------
                                                        (8)
                           E2E RESERVE (DCLASS=x)
                     <-----------------------------
               (9)
       E2E RESERVE
   <---------------

Second example: 
Similar to the scenario given in "APPENDIX 2: Example Signalling 
Flow For Subsequent E2E Flow Without Reservation Resizing", 
specified in RFC 3175, the following scenario can be defined for NSIS. 
For more details on the RMF operation please see 
APPENDIX 2 of RFC 3175.
>From this second example can be seen that the events of the RMF 
operation described for the below scenario are different than the 
ones given in the first example and will impact the QOS-NSLP processing 
in a different way than the way described in the first example given above. 

          Aggregator (ingress)           Deaggregator (egress)

    E2E QUERY
   ---------------->
                (10)
                           E2E QUERY
                       ------------------------------->
                                                      (11)
                                                         E2E QUERY
                                                         ----------->
                                                          E2E RESERVE
                                                         <-----------
                                                      (12)
                           E2E RESERVE (DCLASS=x)
                     <-----------------------------
                 (13)
       E2E RESERVE
   <---------------

Note that the same effect can be seen in the RMD-QOSM specification 
related to the different reservation scenarios explained in detail in 
Section 4.6, see:
http://www.watersprings.org/pub/id/draft-ietf-nsis-rmd-08.txt

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

Comment_4:
-------------
Section 5.1 Local QSPEC definition and processing

By reading this section it gives the impression that 
the two methods a) and b) cannot be used by the same QoS model. 
Method a): translate the
   initiator QSPEC into a local QSPEC and encapsulate the initiator
   QSPEC in the RESERVE message
Method b): b) tunnel the initiator QSPEC
   through the local domain and reserve resources by generating a new
   RESERVE message through the local domain containing the local QSPEC.

Note that according to the discussions that we have had until now 
method a) should be able to be used in combination with method b) by the
same QoS model 
for the situation that the local QSPEC encapsulates the initiator QSPEC 
in order to satisfy requirement 5.4.2 that is specified in 
RFC 3726, see:
http://www.ietf.org/rfc/rfc3726.txt
Note that this is required in the RMD-QOSM to reduce the number 
of the local RESPONSE messages. Instead of sending additional local 
RESPONSE messages, the egress edge encapsulates the initiator QSPEC 
and includes the required local QSPEC parameters on the end to end 
RESPONSE message that is bound to the given local RMD-QOSM session.

Please add the following sentence at the end of the first paragraph of
Section 5.1.
"Note that when method b) is used, the encapsulation of the initiator 
QSPEC into a local QSPEC should also be possible when the local QoS model 
needs to satisfy Requirement 5.4.2 specified in RFC 3726, by adding 
and removing local QOSM-specific <Traffic Handling Directives> 
parameters on top of the initiator QSPEC."

I believe that Jerry mentioned that this sentence will be 
included in the text.

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

Comment_5:
-----------
Section 5.1, last paragraph:

Please change the following:
"For example, RMD can define a local QSPEC that contains 
TMOD = bandwidth (sets r=p, b/m to large)."

Into:
"For example, in RMD the TMOD parameters contained in the original initiator
QSPEC 
are mapped into the equivalent TMOD parameter representing only the peak
bandwidth 
in the local QSPEC."

Note that this change is required in order to clarify in more detail 
the described example. Jerry agreed to modify this already.

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

Comment_6:
-------------
The previous versions of the QSPEC draft included how 
the <QSPEC control information> are processed by the QNEs.

For the same reasons given in Comment_1, the semantics of the 
<QSPEC control information> given in the previous versions of 
the QSPEC template draft has to be kept also in the current/future 
versions of the QSPEC template draft, even if the name is changed 
from <QSPEC control information> to <Traffic Handling Directives>.

Therefore, the rules that have to be followed regarding
the <Traffic Handling Directives>  should be described 
in Section 5.3.1, 5.3.2, 5.3.3:

Please include the following paragraph at the end of each of the 
Sections: 5.3.1, 5.3.2, 5.3.3: 
"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."

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

Comment_7:
------------
Section 6.1:
I do not understand the second sentence from the below two sentences:
"N Flag: Not-supported QSPEC parameter flag (see Section 5.2.2).
           For QSPEC parameters the value of this flag is always zero."

Jerry already mentioned that this comment will be worked out.
---------------------

Best Regards,
Georgios

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

---

From: Lars Westberg <[email-masked]>
Date: Tue, 23 Jan 2007 08:40:57 +0100

I agree with the conclusions and the suggested comments.

regards Lasse

---

From: Attila Báder (IJ/ETH) <[email-masked]>
Date: Tue, 23 Jan 2007 10:51:37 +0100

Hi All, 
 
I also agree with these comments and I think we should include the proposed texts into QSpec doc.
 
Best regards, Attila

________________________________

	From: Lars Westberg [mailto:[email-masked]] 
	Sent: Tuesday, January 23, 2007 8:41 AM
	To: Georgios Karagiannis
	Cc: [email-masked]
	Subject: Re: [NSIS] updated comments on draft-ietf-nsis-qspec-13.txt

	regards Lasse

		Hi all

		

		

		FROM:

		INTO:

		

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

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

		

		

		First example:

		    E2E QUERY
		   ---------------->
		                (1)
		                           E2E QUERY
		
		Second example:

		    E2E QUERY
		   ---------------->
		                (10)
		                           E2E QUERY

		------------------
		
		Comment_4:
		-------------

		

		
		Comment_5:
		-----------

		Into:

		
		Comment_6:
		-------------

		

		Comment_7:
		------------
		Section 6.1:

		Best Regards,
		Georgios