Re: AD evaluation comments on draft-ietf-nsis-rmd-15

Hi Magnus

Thank you very much!

Please see in line!

On 2/26/2010, "Magnus Westerlund" <[email protected]>
wrote:

>Hi Georgios,
>
>I have removed the parts where there seems to be agreement on what to do
>and your proposal for fixes resolves the issue.
>
>Georgios Karagiannis skrev 2010-02-25 18:01:
>
>>>
>>> 5. Section 4.1.2 and 4.1.3:
>>>
>>> What is the definition of Overload %? Please include actual
>>> definition or reference to actual definition.
>> 
>> 
>> Georgios: Okay! We would like to change the definition of the Overload % as
>> follows:
>> 
>> <Overload %>:
>>    8 bits In case of severe congestion the level of overload is indicated by
>> the Overload %.  Overload % is the percentage of the measured PHB rate that
>
>Which rate is meant here. Bit rate or packet rate or some other rate?

Georgios: It is Bit rate, we will add this to the description.


>
>> is above the rate that is used to detect a severe congestion. Overload %
>> SHOULD be higher than 0 if  S bit is set.  If overload in a node is greater
>> than the overload in a previous node then Overload % SHOULD be updated. For
>> more details see Section 4.6.1.6.1. Note that this field represents a real
>> parameter.
>> 
>
>
>
>> 
>>>
>>> 6. Section 4.1.2:
>>> <Time Lag>: 8 bit field.  The time lag used in a sliding window
>>>    over the refresh period.
>>>
>>> What is the definition of the value?
>> 
>> Georgios: Okay! We will change the definition of the <Time Lag> as follows:
>> 
>> <Time Lag>: 8 bit field. Time Lag represents the time difference between the
>> departure time of the last sent "PHR_Refresh_Update" control information
>> container and the departure time of the "PHR_Resource_Release" control
>> information container, see Section 4.6.1.5.
>
>Okay, but how is that encoded into the 8 bits and in what units?

Georgios: Sorry I have copied a wrong definition from Section 4.6.1.5.
That was the definition of T_Lag.

Below is the right definition:

<Time Lag>:  8 bit field. It represents the ratio between the "T_Lag"
parameter, which is the time difference between the departure time of
the last sent "PHR_Refresh_Update" control information container and
the departure time of the "PHR_Resource_Release" control information
container,and the length of the refresh period, "T_period", see
Section 4.6.1.5.

>
>
>
>
>>>
>>> 9. Section 4.4:
>>>
>>> * When the QNE Ingress has to send an initial intra-domain RESERVE
>>>      message, the QoS-NSLP sends this message by including in the GIST
>>>      API SendMessage primitive, the Unreliable and No security
>>>      attributes.
>>>
>>> I can understand the need for datagram mode if the goal is to
>>> measure on the traffic. However, I don't  understand why you
>>> can't use security functions that work with datagrams?
>>>
>>> Also, if you are not using the NSIS messages for measuring
>>> the capacity in the domain, why are you forcing unreliable usage?
>> 
>> Georgios: Is the below text that we would like to include in Section 4.4
>> satisfying your comment?:
>> 
>> "The RMD-QOSM aims to be very lightweight signaling with regard to the
>> number of signaling message roundtrips and the amount of state established
>> at involved signaling nodes with and without reduced state on QNEs. The
>> actions allowed by a QNE Interior node are minimal (i.e., only those
>> specified by the RMD-QOSM). For example, only the QNE Ingress and the QNE
>> Egress nodes are allowed to initiate certain signaling messages. QNE
>> Interior nodes are, for example, allowed to modify certain signaling message
>> payloads, see Section 5. Moroever, RMD signaling is targeted towards
>> intra-domain signaling only. Therefore, RMD-QOSM relies on the security and
>> reliability support that is provided by the bounded end-to-end session,
>> which is running at the boundaries of the RMD domain (i.e., the RMD-QOSM QNE
>> edges). This implies the usage of the Datagram Mode, see Section 5."
>> 
>
>I think the design and its underlying requirement on the signalling
>transport is not well presented. Lightweight is a design goal, not a
>requirement. I am not trying to invalidate the model you have chosen
>here. However I think it should be better documented what is actual
>requirements and what is design goals.
>
>I think what I am missing is the following flow of reasoning in the
>document. We have the following requirements and design goals, thus the
>transport mechanism that can fulfill them are X. Thus X MUST be used by
>RMD-QOSM supporting nodes ...

Georgios: I understand the concern. Will your comment be satisfied if we
will introduce the following text in section 1. Here is the text that
describes the additional requirements:

-------------
Many network scenarios, such as the "Wired Part of Wireless Network"
scenario, which is described in section 8.4 of [RFC3726] require that
the  impact of the used QoS signaling protocol on the network
performance should be minimised. In such network scenarios, the
performance of each network node that is used in a communication path
has an impact on the end-to-end performance. As such, the end-to-end
performance of the communication path can be improved by optimizing the
performance of the interior nodes. One of the factors that can
contribute to this optimization is the minimization of the QoS
signalling protocol processing load on each interior node.

Another requirement that is imposed by such network scenarios is that
whenever a severe congestion situation occurs in the network, the used
QoS signaling protocol shoud be able to solve them. In case of a route
change or link failure a severe congestion situation may occur in the
network. Typically, routing algorithms are able to adapt and change
their routing decisions to reflect changes in the topology and traffic
volume. In such situations the re-routed traffic will have to follow a
new path. Interior nodes  located on this new path may become
overloaded, since they suddenly might need to support more traffic than
they have capacity for. These severe congestion situations will severely
affect the overall performance of the traffic passing through such nodes.

The RMD-QOSM is an edge-to-edge QoS Model that in combination
 with the QoS-NSLP and QSPEC specifications is designed to support the
requirements mentioned above, i.e.:

 o Minimal Impact on Interior Node Performance

 o Ability to deal with severe congestion

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


Moreover, in section 4.4. we will introducre the following text, that
will also refer to the Minimal Impact on Interior Node Performance
requirement that introduced in section 1. The additional text in section
4.4. will be:

"As mentioned in Section 1, The RMD-QOSM aims to support a number of
additional requirements, e.g., Minimal Impact on Interior Node
Performance. Therefore, RMD-QOSM is designed be very lightweight
signaling with regard to the number of signaling message roundtrips and
the amount of state established at involved signaling nodes with and
without reduced state on QNEs. The actions allowed by a QNE Interior
node are minimal (i.e., only those specified by the RMD-QOSM). For
example, only the QNE Ingress and the QNE Egress nodes are allowed to
initiate certain signaling messages. QNE
Interior nodes are, for example, allowed to modify certain signaling
message
payloads. Moroever, RMD signaling is targeted towards
intra-domain signaling only. Therefore, RMD-QOSM relies on the security
and
reliability support that is provided by the bound end-to-end session,
which is running between the boundaries of the RMD domain (i.e., the
RMD-QOSM QNE edges). This implies the usage of the Datagram Mode."


>
>And Actually it might be the first paragraph that needs the most fixing:
>
>   The intra-domain messages used by the RMD-QOSM SHOULD operate
>   in the NTLP/GIST Datagram mode (see [GIST]).  Therefore, the NSLP
>   functionality available in all QoS NSLP nodes that are able to
>   support the RMD-QOSM MUST require, via the QoS-NSLP RMF API, see
>   [QoS-NSLP], from the intra-domain GIST functionality available in
>   these nodes to operate in the datagram mode, i.e., require GIST to:
>
>It is strange to use uppercase SHOULD and then "MUST require" in the
>next sentence. I think it is appropriate to mandate the support of one
>particular solution. If you intended to allow for any future changes in
>this area, which the "SHOULD" implies. Thus you need to document the
>requirements for that.

Georgios: You are right! I think that the first "SHOULD" should not be
used since a QoS Model cannot mandate the use of the Datagram Mode. We
could replace the first SHOULD by "are intended".

Will the following change help:

"The intra-domain messages used by the RMD-QOSM are intended to operate
in the NTLP/GIST Datagram mode (see [GIST]).  Therefore, the NSLP
functionality available in all RMD-QOSM aware QoS NSLP nodes requires,
via the QoS-NSLP RMF API, see [QoS-NSLP], from the intra-domain GIST
functionality to:"



>
>
>
>
>>>
>>> 11. General comment:
>>>
>>> Due to the different options in how to setup RMD the
>>> specification is difficult to follow. There are a lot of
>>> exception text, and it is not always really clear to which
>>> configuration this particular text belongs to. I wished there
>>> really where fewer alternatives. However, I am not going to
>>> demand a massive rewrite this would require.
>> 
>> Georgios: Section 3.2.3 RMD-QOSM Applicability and considerations,
>> identifies which
>> combination of sections are used for the specification of each
>> RMD-QOSM/QoS-NSLP signaling scheme.
>> Would it help if in Section 1 Introduction, we include the following text:
>> 
>> "This document specifies several RMD-QOSM/QoS-NSLP signaling schemes.
>> Section 3.2.3 identifies which combination of sections are used for the
>> specification of each RMD-QOSM/QoS-NSLP signaling scheme."
>> 
>> Moreover we would like to add a paragraph in each relevant sub-section (of
>> Section 4.6) as below:
>> 
>> "It is important to emphasize that the content of this section is used for
>> the specification of the following RMD-QOSM/QoS-NSLP signaling schemes:
>> * here we will list the relevant RMD-QOSM/QoS-NSLP signaling schemes
>> relevant for that section.
>> 
>> For example, in Section 4.6.1.6.2 we can write:
>> 
>> "It is important to emphasize that the content of this section is used for
>> the specification of the following RMD-QOSM/QoS-NSLP signaling schemes:
>> * "per flow congestion notification based on probing",
>> 
>> * "per flow RMD NSIS measurement based admission control",
>> 
>> 
>> * "per flow RMD reservation based" in combination with "severe
>>      congestion handling by proportional data packet marking" procedure,
>> 
>> * "per aggregate RMD reservation based" in combination with
>>      "severe congestion handling by proportional data packet marking"
>>      procedure.
>> 
>> For more details, please see Section 3.2.3."
>> 
>> 
>
>Thanks, I think this will be an improvement.


Georgios: Thanks!

>>>
>>> 14. Section 5:
>>>
>>> This implies the usage of the Datagram Mode which
>>>    does not allow channel security to be used.
>>>
>>> Is this really true? Isn't the correct description that none
>>> is specified yet for GIST.
>> 
>> Georgios:
>> I think that we were not clear on why we are requiring the dagram mode!
>> Will the answer that we already gave to your comment 9, be satisfactory, see
>> also below?
>
>I would suggest that you simply change "allow" in the above sentence to
>something else, like "have any built in channel security mechanisms" and
>remove the last words.

Georgios: Okay we will do that!
>
>
>>>
>>> 15. Section 6:
>>>
>>> A. I would recommend to create two subsections to make it
>>> clear that there are registration actions in two different registries.
>>>
>>> B. Secondly, I don't get the second registration request to
>>> match what is described in the document. I would create a
>>> table where IANA can easily fill in all the container ID
>>> values needed. IS it 10 of these + the bandwidth?
>> 
>> We will do the following changes in section 6:
>> 
>> Section 6.
>>    This section defines additional codepoint assignments in the QSPEC
>>    Parameter ID registry and requests the establishment of one new
>>    registry for each of the following parameters (and assigns initial
>>    values), in accordance with BCP 26 [RFC5226].  It also defines the
>>    procedural requirements to be followed by IANA in allocating new
>>    codepoints for the new Registries. The parameters that require a registry
>> 
>>    are the following containers:
>> 
>> <PHR_Resource_Request>
>> <PHR_Release_Request>
>> <PHR_Refresh_Update>
>> <PDR_Reservation_Request>
>> <PDR_Refresh_Request>
>> <PDR_Release_Request>
>> <PDR_Reservation_Report>
>> <PDR_Refresh_Report>
>> <PDR_Release_Report>
>> <PDR_Congestion_Report>
>> 
>
>I get the impression that this is an introduction. I think it can be
>slimmed down a bit without loss of any relevant information. The details
>on the registries are present in the later section. Thus stating that it
>establish registries for the reserved bits for the here in defined
>containers are likely sufficient.
>
>> 6.1.  Assignment of QSPEC Parameter/Container IDs
>> 
>> This document specifies the following QSPEC parameters to be assigned
>>    within the QSPEC Parameter ID registry created in
>>    [I-D.ietf-nsis-qspec]:
>> 
>>    <Bandwidth> parameter (Section 4.1.1 above, suggested ID=17)
>> 
>>    <PHR_Resource_Request> container (Section 4.1.2 above, suggested ID=18)
>> 
>>    <PHR_Release_Request> container (Section 4.1.2 above, suggested ID=19)
>> 
>>    <PHR_Refresh_Update> container (Section 4.1.2 above, suggested ID=20)
>> 
>>      <PDR_Reservation_Request> container  (Section 4.1.3 above, suggested
>> ID=21)
>> 
>>      <PDR_Refresh_Request> container (Section 4.1.3 above, suggested ID=22)
>> 
>>      <PDR_Release_Request> container (Section 4.1.3 above, suggested ID=23)
>> 
>>      <PDR_Reservation_Report> container (Section 4.1.3 above, suggested
>> ID=24)
>> 
>>      <PDR_Refresh_Report> container (Section 4.1.3 above, suggested ID=25)
>> 
>>     <PDR_Release_Report> container (Section 4.1.3 above, suggested ID=26)
>> 
>>     <PDR_Congestion_Report> container (Section 4.1.3 above, suggested ID=27)
>> 
>
>This looks good.
>
>> 6.2.  PHR_Resource_Request Container Registry
>> 
>> The Registry for the PHR_Resoure_Request container contains assignments for
>> nine
>> fields in the two 32-bit container payload words, and two Reserved sections
>> of the
>> two 32-bit container payload words, see Section 4.1.2.
>> 
>> This specification creates the registry over the remaining Reserved bits,
>> i.e.
>> bit 29-31 in the first 32-bit word of the container payload, and bits 8-31
>> in the
>> second 32-bit word of the container payload.
>> 
>> 6.2.1.  Reserved Bits
>> 
>> The remaining Reserved bits in the PHR_Resource_Request container payload,
>> i.e. bit 29-31
>> in the first 32-bit word of the container payload, and bits 8-31 in the
>> second 32-bit word
>> of the container payload are Reserved.  The Reserved bits MAY be designated
>> for other uses
>> in the future. The registration Procedure is: IETF Review.
>
>I think the registry creation text is descent, except missing a
>reference to the policy directly after the policy statement.
>
>However, my big question is: Is this registry needed? Are you expecting
>extensions that adds fields to the containers? Can the extensions really
>be easily utilized from the perspective of interoperability? Yes an
>non-upgraded node will ignore the field and the message it forwards may
>not contain the unknown fields.
>
>So is the establishment of the registry really a benefit, compared to
>having to rely on new experimental RFCs that updates this specification
>with additional fields which would be required if you don't specify the
>registries.

Georgios: Agree with your proposal regarding the registry. The new
section 6 will look as follows:

Section 6.
      This section defines additional codepoint assignments in the QSPEC
      Parameter ID registry, in accordance with BCP 26 [RFC5226].

6.1. Assignment of QSPEC Parameter/Container IDs

This document specifies the following QSPEC parameters to be assigned
   within the QSPEC Parameter ID registry created in
   [I-D.ietf-nsis-qspec]:

   <Bandwidth> parameter (Section 4.1.1 above, suggested ID=17)

   <PHR_Resource_Request> container (Section 4.1.2 above, suggested ID=18)

   <PHR_Release_Request> container (Section 4.1.2 above, suggested ID=19)

   <PHR_Refresh_Update> container (Section 4.1.2 above, suggested ID=20)

     <PDR_Reservation_Request> container (Section 4.1.3 above, suggested
ID=21)

     <PDR_Refresh_Request> container (Section 4.1.3 above, suggested
ID=22)

     <PDR_Release_Request> container (Section 4.1.3 above, suggested
ID=23)

     <PDR_Reservation_Report> container (Section 4.1.3 above, suggested
ID=24)

     <PDR_Refresh_Report> container (Section 4.1.3 above, suggested ID=25)

    <PDR_Release_Report> container (Section 4.1.3 above, suggested ID=26)

    <PDR_Congestion_Report> container (Section 4.1.3 above, suggested
ID=27)


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

>
>>>
>>> 16. Section A.4.1:
>>>
>>> Why are there normative statements in the appendix? That
>>> doesn't seem appropriate.
>> 
>> Georgios! Okay! We will make all statements in the Appendices informative!
>
>To make it clear, normative statements aren't forbidden in appendices,
>however with this document structure it didn't appear appropriate.
>However, the question is if it wouldn't be clearer to move A.4 and A.5
>to the main text? What is the motivation to have this hidden in the
>appendix?

Georgios: The information included in the appendices present examples of
how the descrined algorithms in the main text can be implemented. That
is why we moved these descriptions to the appendices.

Is it okay to still use the normative references, but at the begining of
each appendix section add a sentence like:

"This appendix section describes a possible alternative of how the xxxx
solution can be implemented."

Where xxxx will be filled at each section accordingly!


Best regards,
Georgios

>
>Cheers
>
>Magnus Westerlund
>
>IETF Transport Area Director
>----------------------------------------------------------------------
>Multimedia Technologies, Ericsson Research EAB/TVM
>----------------------------------------------------------------------
>Ericsson AB                | Phone  +46 10 7148287
>Färögatan 6                | Mobile +46 73 0949079
>SE-164 80 Stockholm, Sweden| mailto: [email protected]
>----------------------------------------------------------------------
>_______________________________________________
>nsis mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/nsis