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

Hi Magnus

Thank you very much for the comments!
We tried to answer all your questions, please see below!
Can you please inform us if our answers satisfy your comments?


Best regards,
Georgios 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Magnus Westerlund
> Sent: vrijdag 19 februari 2010 18:53
> To: [email protected]; NSIS
> Subject: [NSIS] AD evaluation comments on draft-ietf-nsis-rmd-15
> 
> Hi,
> 
> Here are my comments from the AD evaluation:
> 
> 0. Worth to discuss also for this QoS Model. Is it actually 
> right to publish these as Informational? Isn't experimental a 
> more suitable status considering that they do define both 
> protocol extensions and behavior?


Georgios: Yes we agree with your proposal!

> 
> 1. Section 3.1:
> "The measurement-based algorithm continuously measures traffic levels
>    and the actual available resources, and admits flows whose resource
>    needs are within what is available at the time of the request. Once
>    an admission decision is made, no record of the decision need be
>    kept at the interior nodes.  The advantage of measurement-based
>    resource management
>    protocols is that they do not require pre-reservation state nor
>    explicit release of the reservations at the interior nodes.
>    Moreover, when the user
>    traffic is variable, measurement based admission control could
>    provide higher network utilization than, e.g., peak-rate
>    reservation.  However, this can introduce an uncertainty in the
>    availability of the resources."
> 
> Please fix the line breaking.

Georgios: Thanks, we will do that!

> 
> 2. Section 3.1:
> 
>    In this scenario
>    an end-to-end NSIS message is used as a probe packet, meaning that
>    the DSCP field in the header of the IP packet that carries the NSIS
>    message is re-marked when the predefined congestion threshold is
>    exceeded. Note that when the predefined congestion threshold is
>    exceeded all packets are remarked by a node, including NSIS
>    messages. In this way the edges can admit or reject flows that are
>    requesting resources. The rate of the re-marked data 
> packets is used
>    to detect a congestion situation that can influence the admission
>    control decisions.
> 
> I find the above statement to have several contradictions. 
> The first one is that the the NSIS messages is used as probe 
> packets, but still all packets are remarked. Secondly, it 
> states that all packets are remarked when the congestion 
> threshold is passed, then it is stated that the "rate of the 
> re-marked data packets" is used. If all packets are remarked, 
> then how can a rate of re-marked packets be used? Are you 
> meaning the frequency and durations when the congestion level 
> is above the threshold resulting in remarking is tracked?

Georgios: Thanks! We will do the following change:

From:
“The rate of the re-marked data packets is used to detect a congestion
situation that can influence the admission control decisions.”

Change INTO:
“The frequency and durations that the congestion level is above the
threshold resulting in remarking is tracked and used to influence the
admission control decisions.”


> 
> 3. Section 4.1.1:
> 
>      0                   1                   2                   3
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |1|E|0|r|       Bandwidth_IDID    |r|r|r|r|          1    
>         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Peak Data Rate-1 (p)  (32-bit IEEE floating point number)     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>             <Bandwidth> parameter format
> 
> 
> There are som alignment error in the first 32-bit word, Is it 
> the Parameter ID (IDID) that is wrong?

Georgios: Yes the Parameter ID (IDID) field is wrong. We will correct this
such 
that it can align with what is specified in the QSPEC draft.

> 
> 4. Section 4.1.2 and 4.1.3:
> 
> Parameter/Container ID: 8 bit field, indicating the PHR type:
>    PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update.
> 
> In the figure the Container ID is 12 bits.

Georgios: The text is wrong. We will change it into:

“Container ID: 12 bit field, indicating the PHR type:
   PHR_Resource_Request, PHR_Release_Request, PHR_Refresh_Update.”

> 
> 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
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. 


> 
> 7. Section 4.3.2:
> 
> It is important to emphasize that in this case, the operational
>    state (at QNE ingress and QNE egress) that is maintained 
> by the end-
>    to-end session bound to the per-flow intra-domain session it MUST
>    contain in the BOUND_SESSION_ID, the SESSION_ID value of the bound
>    tunnelled per-flow intra-domain session.
> 
> "it MUST" seems strange. Also, "important to empahsize" and 
> MUST in the same sentence doesn't make sense. Normative 
> statement needs to be crisp.

Georgios: Thanks! The identified paragraph is a modified duplication of the
paragraph given above. Therefore we will remove the following paragraph:

"It is important to emphasize that in this case, the operational 
   state (at QNE ingress and QNE egress) that is maintained by the end-
   to-end session bound to the per-flow intra-domain session it MUST 
   contain in the BOUND_SESSION_ID, the SESSION_ID value of the bound 
   tunnelled per-flow intra-domain session. The BINDING_CODE associated 
   with this BOUND_SESSION_ID is set to code (Tunnelled and end-to-end 
   sessions)."


> 
> Also applies to two paragraphs down, that contains the same structure.

Georgios: Thanks! The same observation given above holds for the two
paragraphs down. We will remove the following paragraph:

"It is important to emphasize, in this case, that the operational 
   state (at ingress and egress) that is maintained by the end-to-end 
   session bound to the per-flow intra-domain session MUST contain two 
   types of BOUND_SESSION_IDs.  One of the BOUND_SESSION_IDs MUST 
   contain the SESSION_ID of its bound end-to-end session that is using 
   a BINDING_CODE with value set to code (Tunnelled and end-to-end 
   sessions).  Another BOUND_SESSION_ID maintains the SESSION_ID of the 
   bound bidirectional end-to-end session. The BINDING_CODE associated 
   with this BOUND_SESSION_ID is set to code (Bi-directional sessions)."

> 
> 8. Section 4.3.2:
> For each traffic belonging to a PHB traffic class a
>    predefined congestion threshold is set.
> 
> "each" traffic? Please reword this sentence so that is is 
> clear what is meant.

Georgios: We will change the sentence in the following way:

Change From:
“For each traffic belonging to a PHB traffic class a 
   predefined congestion threshold is set.”

INTO:
“For each PHB traffic class a predefined congestion notification threshold
is set.”


> 
> 9. Section 4.3.2
> 
>    In this scenario end-to-end NSIS message is used as a probe packet.
>    In this case the DSCP field of the GIST message is re-marked when
>    the predefined congestion notification threshold is exceeded in an
>    interior node. In this way it is ensured that the end-to-end NSIS
>    message passed through the node that it is congested. This feature
>    is very useful when ECMP (Equal Cost Multiple Path) based 
> routing is
>    used to detect only flows that are passing through the congested
>    node. Note that in this situation, not only the probe packet is
>    remarked, but also data packets passing though the congested node
>    are re-marked.
> 
> If I understand this method correct, it does require that the 
> remarking happens to all packets that are in the congested 
> traffic class so that the probe can't pass the congested 
> router without being remarked? Can the text be made clearer 
> on that aspect?


Georgios: 
Yes you are right! We would like to do the following change into the
mentioned text:

In this scenario end-to-end NSIS message is used as a probe packet. In this
case the DSCP field of the GIST message is re-marked when the predefined
congestion notification threshold is exceeded in an interior node. It is
required that the remarking happens to all packets that are belonging to the
congested PHB traffic class so that the probe can't pass the congested
router without being remarked.  In this way it is ensured that the
end-to-end NSIS message passed through the node that it is congested. This
feature is very useful when ECMP (Equal Cost Multiple Path) based routing is
used to detect only flows that are passing through the congested node. 


> 
> 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."


> 
> 10. Section 4.6.1.1.1
> 
> If the initial QSpec carries the <Excess Treatment> parameter,
>    then the QNE ingress and QNE egress nodes MUST control the excess
>    traffic that is entering or leaving the RMD domain in accordance to
>    the <Excess Treatment> parameter. Note that the RMD-QSpec does not
>    carry the <Excess Treatment> parameter. However, by using the <PHB
>    class> parameter the RMD domain uses the excess treatment 
> procedures
>    specified by the particular PHB standard.
> 
> 
> The second sentence appears very strange. What are you trying 
> to express?

Georgios: We will remove the second sentence can be removed, since it does
not add anything!

> 
> 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."



> 
> 12. Section 4.6.1.1, page 31:
> 
> Furthermore, in this case the retransmission within the RMD domain
>    SHOULD NOT be disallowed and the procedures described in Appendix
>     A.5 SHOULD be used on QNE Interior nodes.
> 
> Double negation, is unnecessary and makes it more difficult 
> to understand. It would also be clearer if the text intendeds 
> to recommend retransmission usage or simply say MAY be used. 
> Instead of recommending against not using it.


Georgios: We will do the following change:

"Furthermore, in this case the retransmission within the RMD domain
is allowed and the procedures described in Appendix A.5 SHOULD be used on
QNE Interior nodes."


> 
> 13. Page 33:
> 
> *  the PHR resource units MUST be included into the <Bandwidth>
>    parameter of the "<QoS Desired> object. When the QNE edges
>    use per flow intra-domain QoS-NSLP states, then the value of the
>    <Bandwdith> parameter can be obtained by using the method of
>    copying the peak rate (p) field included in the <TMOD-1> parameter
>       carried by the initial QSpec into this <Bandwidth> parameter,
>       which is described above in this subsection. When the QNE edges
>       use aggregated intra-domain QoS-NSLP operational 
> states, then the
>       value of the <Bandwdith> parameter can be obtained by using the
>       bandwidth aggregation method described in Section 4.3.1;
> 
> 
> Strange indentation, please address.

Georgios: Thanks we will do that!

> 
> 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?


"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."


> 
> 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>

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)

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.

6.3.  PHR_Release_Request Container Registry
We will fill this section in a similar way as Section 6.2.

6.4.  PHR_Refresh_Update Container Registry
We will fill this section in a similar way as Section 6.2.

6.5.  PHR_Reservation_Request Container Registry
We will fill this section in a similar way as Section 6.2.

6.6.  PDR_Reservation_Request Container Registry
We will fill this section in a similar way as Section 6.2.

6.7.  PDR_Refresh_Request Container Registry
We will fill this section in a similar way as Section 6.2.

6.8.  PDR_Release_Request Container Registry
We will fill this section in a similar way as Section 6.2.

6.9.  PDR_Reservation_Report Container Registry
We will fill this section in a similar way as Section 6.2.

6.10.  PDR_Refresh_Report Container Registry
We will fill this section in a similar way as Section 6.2.

6.11.  PDR_Release_Report Container Registry
We will fill this section in a similar way as Section 6.2.

6.12.  PDR_Congestion_Report Container Registry
We will fill this section in a similar way as Section 6.2.

> 
> 
> 
> 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!

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
>