Subject: [NSIS] AD evaluation comments on draft-ietf-nsis-rmd-15

From: Magnus Westerlund <[email-masked]>
Date: Fri, 19 Feb 2010 18:53:27 +0100

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?

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.

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?

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?

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.

5. Section 4.1.2 and 4.1.3:

What is the definition of Overload %? Please include actual definition
or reference to actual definition.

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?

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.

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

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.

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?

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?

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?

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.

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.

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.

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.

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?

16. Section A.4.1:

Why are there normative statements in the appendix? That doesn't seem
appropriate.

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Feb 2010 18:01:41 +0100

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-masked] [mailto:[email-masked]] On 
> Behalf Of Magnus Westerlund
> Sent: vrijdag 19 februari 2010 18:53
> To: [email-masked]; NSIS
> Subject: [NSIS] AD evaluation comments on draft-ietf-nsis-rmd-15
> 
> Hi,
> 
> 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!

> Please fix the line breaking.

Georgios: Thanks, we will do that!

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

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

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

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

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

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

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

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

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

> The second sentence appears very strange. What are you trying 

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

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

> Strange indentation, please address.

Georgios: Thanks we will do that!

> 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

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

---

From: Gerald Ash <[email-masked]>
Date: Thu, 25 Feb 2010 11:09:23 -0800 (PST)

A few additional comments:
 
1. Section 4.1.1 (http://tools.ietf.org/html/draft-ietf-nsis-rmd-15#section-4.1.1) defines a <bandwidth> parameter, which appears is intended to replace the mandatory TMOD parameter for use in the RMD-QOSM.  The QSPEC specifies in Section 3.1.1. (http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.3.1) 
"   The <Traffic Model> (TMOD) parameter is mandatory for the QNI to
   include in the initiator QSPEC and mandatory for downstream QNEs to
   interpret. "
and
"   All 5 of the sub-parameters MUST be included in the TMOD parameter.
   The TMOD parameter can be set to describe the traffic source.  If,
   for example, TMOD is set to specify bandwidth only, then set r = peak
   rate = p, b = large, m = large. "
 
Hence the RMD-QOSM MUST use the TMOD parameter and can use it to specify "bandwidth" only, as per the second statement above (recall that the second statement was specifically included with RMD-QOSM in mind).  The <bandwidth> parameter is therefore unnecessary in RMD-QOSM.
 
2. Section 4.1.1 appears to specify a new QSPEC object combination called "RMD-QOSM object combination".  If so, then this new object combination/message sequence needs to be defined in the IANA Considerations Section.
 
3. In Section 6/IANA Considerations (http://tools.ietf.org/html/draft-ietf-nsis-rmd-15#section-6) it says
"  A new QOSM ID ("RMD QOSM") needs to be assigned by IANA. The value
   Has to be placed into the QSPEC Type registry that was created with
   [QSP-T]."
 
This statement can be removed since in QSPEC Section 7/IANA Considerations (http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-7) a QSPEC Type is already defined for the RMD-QOSM, as follows:
"   QSPEC Type (5 bits):
   The following values are allocated by this specification:
   0: Default
   1: Y.1541-QOSM [Y.1541-QOSM]
   2: RMD-QOSM [RMD-QOSM]"
 
Thanks,
Jerry

--- On Thu, 2/25/10, Georgios Karagiannis <[email-masked]> wrote:

From: Georgios Karagiannis <[email-masked]>
Subject: Re: [NSIS] AD evaluation comments on draft-ietf-nsis-rmd-15
To: "'Magnus Westerlund'" <[email-masked]>
Cc: [email-masked], "'NSIS'" <[email-masked]>
Date: Thursday, February 25, 2010, 12:01 PM

Hi Magnus

Best regards,
Georgios 

From:

Change INTO:

<Overload %>: 

Change From:

INTO:

Georgios: 

   

Georgios: 

Section 6.

<PHR_Resource_Request> 
<PHR_Release_Request> 
<PHR_Refresh_Update>

6.2.1.  Reserved Bits

Best regards,
Georgios

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 25 Feb 2010 21:47:48 +0000

Hi Jerry

>Hence the RMD-QOSM MUST use the TMOD parameter and can use it to specify "bandwidth" only, as per the second statement above (recall that the second statement was specifically included with RMD-QOSM…

Georgios: Thanks! You are right, but we still need that IANA assigns the
<Bandwidth> parameter. In order to satisfy your comment, we will
redefine the <Bandwidth> parameter in the following way:

  The bit format used for the <Bandwidth> parameter is identical to the
  bit format of the <TMOD-1> parameter format specified in [QSP-T] but the
  fields are set in the following way:
   o  TMOD Rate-1 (r)= Peak Data Rate-1 (p)
   o  TMOD Size-1 (b) = large
   o  Minimum Policed Unit-1 (m) = large

The <Bandwdith> parameter figure in Section 4.1.1 will be removed!

>2. Section 4.1.1 appears to specify a new QSPEC object combination called "RMD-QOSM object combination".  If so, then this new object combination/message sequence needs to be defined in the IANA Con…

Georgios: Actually is not a new object. We will change the title of
Section 4.1.1 in:

4.1.1 QoS Desired and QoS Available

Furthermore, the expression:

"RMD-QOSM object combination" will be removed from the draft and in its
place we will use <QoS Desired> when the above expression is used within
a RESERVE and we will use <QoS Available> when the above expression is
used within a RESPONSE message.

Best regards,
Georgios

>>    needs are within what is available at the time of the request Once
>>       which is described above in this subsection When the QNE edges
>      )

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 26 Feb 2010 14:15:44 +0100

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.

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

> information container, see Section 4.6.1.5.

Okay, but how is that encoded into the 8 bits and in what units?

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

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.

> For more details, please see Section 3.2.3."

Thanks, I think this will be an improvement.

> Will the answer that we already gave to your comment 9, be satisfactory, see

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.

> <PDR_Reservation_Request>

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.

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

This looks good.

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

Cheers

Magnus Westerlund

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 26 Feb 2010 17:11:51 +0000

Hi Magnus

Thank you very much!

Please see in line!

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

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

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

>this area, which the "SHOULD" implies. Thus you need to document the

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

>Thanks, I think this will be an improvement.

Georgios: Thanks!

>something else, like "have any built in channel security mechanisms" and

Georgios: Okay we will do that!
>with additional fields which would be required if you don't specify the

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

     <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_Congestion_Report> container (Section 4.1.3 above, suggested
ID=27)

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

>to the main text? What is the motivation to have this hidden in the

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

---

From: Gerald Ash <[email-masked]>
Date: Fri, 26 Feb 2010 14:06:01 -0800 (PST)

Hi Georgios,
 
>>1. Section 4.1.1 (http://tools.ietf.org/html/draft-ietf-nsis-rmd-15#section-4.1.1) defines
>> a <bandwidth> parameter, which appears is intended to replace the mandatory TMOD
>> parameter for use in the RMD-QOSM.  The QSPEC specifies in Section 3.1.1. 
>>(http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.3.1) 
>> Hence the RMD-QOSM MUST use the TMOD parameter and can use it to
>> specify "bandwidth" only, as per the second statement above (recall that the second
>> statement was specifically included with RMD-QOSM in mind).  The <bandwidth>
>> parameter is therefore unnecessary in RMD-QOSM.

>   o  Minimum Policed Unit-1 (m) = large
 
It wouldn't be appropriate to have IANA specify the values of the sub-parameters of TMOD-1.  I suggest that you define these TMOD-1 sub-parameter values in Section 4.1.1, and remove references to a new "<bandwidth>" parameter.  You might also want to specify a specific value for "large".
 
Thanks,
Jerry

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 27 Feb 2010 07:24:38 +0000

Hi Jerry

Please see in line!

>It wouldn't be appropriate to have IANA specify the values of the sub-parameters of TMOD-1.  I suggest that you define these TMOD-1 sub-parameter values in Section 4.1.1, and remove references to a…

Georgios: I do not think that IANA will specify the values TMOD-1
sub-parameter values.

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

The bandwidth parameter is just the translation of the T-MOD parameter to
the bandwidth paramter. I will include the following information in the
draft:

   The bit format used for the <Bandwidth> parameter is shown below and
   it is a translation of the <TMOD-1> parameter, see [QSP-T], to
   specify bandwidth only, by setting, see [QSP-T]:
     o  TMOD Rate-1 (r)= Peak Data Rate-1 (p)
     o  TMOD Size-1 (b) = large
     o  Minimum Policed Unit-1 (m) = large

    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 ID         |r|r|r|r|          5            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Peak Data Rate-1 (p) (32-bit IEEE floating point number)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  TMOD Size-1 (b) (32-bit IEEE floating point number)          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Peak Data Rate-1 (p) (32-bit IEEE floating point number)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Minimum Policed Unit-1 (m) (32-bit unsigned integer)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Maximum Packet Size-1 (MPS) (32-bit unsigned integer)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Regarding the "large" values, I will specify them in Section 4.6.

Best regards,
Georgios

---

From: Gerald Ash <[email-masked]>
Date: Sat, 27 Feb 2010 09:55:51 -0800 (PST)

Georgios,
 
See below.
 
>     o  Minimum Policed Unit-1 (m) = large

Just to be clear, the "Bandwidth ID" = 1, which is the same value as the TMOD-1 parameter ID (= 1), as already assigned by IANA.  It is not necessary to define another QSPEC parameter ID.  What you are calling the "<bandwidth> parameter" is actually the TMOD-1 parameter with particular values.  Once again, it is required that all NSIS/NSLP/QOSM implementations send the TMOD-1 parameter in their QSPEC's. 

> Regarding the "large" values, I will specify them in Section 4.6.
 
OK.
 
Thanks,
Jerry

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 27 Feb 2010 20:18:35 +0200

Agree with Jerry.

A minor note: The question we got during the review of the DIME 
documents was: "What is large? State the value."

 >     o  Minimum Policed Unit-1 (m) = large

Ciao
Hannes

Gerald Ash wrote:
> Just to be clear, the "Bandwidth ID" = 1, which is the same value as 
> the TMOD-1 parameter ID (= 1), as already assigned by IANA.  It is not 
> necessary to define another QSPEC parameter ID.  What you are calling 
> the "<bandwidth> parameter" is actually the TMOD-1 parameter with 
> particular values.  Once again, it is required that all NSIS/NSLP/QOSM 
> implementations send the TMOD-1 parameter in their QSPEC's. 
>
> ------------------------------------------------------------------------
>

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 27 Feb 2010 20:08:38 +0000

Hi Jerry

See below!

>Just to be clear, the "Bandwidth ID" = 1, which is the same value as the TMOD-1 parameter ID (= 1), as already assigned by IANA.  It is not necessary to define another QSPEC parameter ID.  What you…

The Bandwidth ID = 17.

This parameter is different then the definition of TMOD, since it is
specifying bandwidth only, see the particular paragraph in the QSPEC
draft:

   "The TMOD parameter can be set to describe the traffic source.  If,
   for example, TMOD is set to specify bandwidth only, then set r = peak
   rate = p, b = large, m = large.  As another example if TMOD is set
   for TCP traffic, then set r = average rate, b = large, p = large."

The bit format of Bandwidth is representing the semantics of the above
paragraph. As you can see here the difference in the bit format is that
the  TMOD Rate-1 (r) field is replaced by the  Peak Data Rate-1 (p) field.

Best regards,
Georgios

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 27 Feb 2010 22:58:21 +0200

Btw, for the Diameter work we specified a separate "Bandwidth" AVP since 
folks thought it was too complicated to specify bandwidth with the TMOD 
parameter.

See Bandwidth AVP in http://www.ietf.org/rfc/rfc5624.txt

Ciao
Hannes

Hannes Tschofenig wrote:
>> the TMOD-1 parameter ID (= 1), as already assigned by IANA.  It is 
>> not necessary to define another QSPEC parameter ID.  What you are 
>> calling the "<bandwidth> parameter" is actually the TMOD-1 parameter 
>> with particular values.  Once again, it is required that all 
>> NSIS/NSLP/QOSM implementations send the TMOD-1 parameter in their 
>> QSPEC's.

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Sat, 27 Feb 2010 21:13:30 +0000

Hi Hannes,

Thank you very much!
I think that it is good to define the Bandwidth parameter in the same way
as in RFC 5624, which also defined the TMOD-1 AVP and the Bandwidth AVP,
where the description of the Bandwdith AVP, see RFC 5624, is:

3.3.  Bandwidth AVP (from RFC 5624)

   The Bandwidth AVP (AVP Code 502) is of type Float32 and is measured
   in octets of IP datagrams per second.  The Bandwidth AVP represents a
   simplified description of the following TMOD setting whereby the
   token rate (r) = peak traffic rate (p), the bucket depth (b) = large,
   and the minimum policed unit (m) = large when only bandwidth has to
   be expressed.

My new proposal is to define the Bandwidth parameter in RMD-QOSM in a
very similar way as defined in RFC 5624 and as it was defined since 5
years now in:
http://www.ietf.org/id/draft-ietf-nsis-rmd-15.txt:

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

   The <Bandwidth> parameter (ID=17) is of type Float32 and is measured
   in octets of IP datagrams per second.  The <Bandwidth> parameter
   represents a simplified description of the following <TMOD-1> parameter
   setting, specified in [QSP-T], whereby the token rate (r) = peak
traffic
   rate (p), the bucket depth (b) = large, and the minimum policed unit
   (m)  = large when only bandwidth has to be expressed.

   The bit format used for the <Bandwidth> parameter is shown below and it
   is a translation of the <TMOD-1> parameter, see [QSP-T], to specify
   bandwidth only, by setting, see [QSP-T]:
    o  TMOD Rate-1 (r)= Peak Data Rate-1 (p)
    o  TMOD Size-1 (b) = large
    o  Minimum Policed Unit-1 (m) = large

     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|       17              |r|r|r|r|          1            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | Peak Data Rate-1 (p)  (32-bit IEEE floating point number)     |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Best regards,
Georgios

---

From: Gerald Ash <[email-masked]>
Date: Sat, 27 Feb 2010 16:51:07 -0800 (PST)

Georgios,
Hannes,
 
Once again, the QSPEC specifies in Section 3.1.1. (http://tools.ietf.org/html/draft-ietf-nsis-qspec-24#section-3.3.1) 
 
Hence the RMD-QOSM MUST send the TMOD-1 parameter in the initiator QSPEC and downstream QNEs MUST interpret TMOD-1.  As per the second statement, the way to use TMOD-1 to specify "bandwidth" is by setting sub-parameters as follows:
 
r = peak rate
p = peak rate
b = large
m = large
 
Since the TMOD-1 parameter must be used, there is no point in defining a separate <bandwidth> parameter; it will be redundant with TMOD-1.
 
Thanks,
Jerry

--- On Sat, 2/27/10, Georgios Karagiannis <[email-masked]> wrote:

From: Georgios Karagiannis <[email-masked]>
Subject: Re: [NSIS] AD evaluation comments on draft-ietf-nsis-rmd-15
To: "Gerald Ash" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "'NSIS'" <[email-masked]>
Date: Saturday, February 27, 2010, 4:13 PM

Hi Hannes,

Thank you very much!

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

     0                   1                   2                   3

Best regards,
Georgios