Re: AD evaluation comments on draft-ietf-nsis-rmd-15
"Georgios Karagiannis" <[email protected]> Thu, 25 Feb 2010 21:47:48 +0000
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
Hi Jerry Thank you very much for the comments! On 2/25/2010, "Gerald Ash" <[email protected]> wrote: >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. 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 Considerations Section. 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. > >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]" Georgios: Thanks, we will do that! Best regards, Georgios > >Thanks, >Jerry > > >--- On Thu, 2/25/10, Georgios Karagiannis <[email protected]> wrote: > > >From: Georgios Karagiannis <[email protected]> >Subject: Re: [NSIS] AD evaluation comments on draft-ietf-nsis-rmd-15 >To: "'Magnus Westerlund'" <[email protected]> >Cc: [email protected], "'NSIS'" <[email protected]> >Date: Thursday, February 25, 2010, 12:01 PM > > >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 >> > > >_______________________________________________ >nsis mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/nsis > > > > )