[NSIS] updated comments on draft-ietf-nsis-qspec-13.txt
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
nsis at ietf.org
https://www1.ietf.org/mailman/listinfo/nsis