RE: RMD Comments

Hi Hannes

Regarding the below comment:
> While it appears that it is a single QSPEC parameter it really isn't.
> It is, in fact, a request to IANA to allocate 3 QSPEC 
> parameters, as shown above.

Yes you are right, there are 3 containers!

Best regards,
Georgios





> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email protected]] 
> Sent: donderdag 22 november 2007 17:45
> To: Georgios Karagiannis
> Cc: [email protected]
> Subject: Re: [NSIS] RMD Comments
> 
> Hi Georgios,
> 
> Georgios Karagiannis wrote:
> > Hi Hannes
> >
> > Thank you very much!
> > Please see some answers in line!
> >
> > Best regards,
> > Georgios
> >
> > On 11/1/2007, "Hannes Tschofenig" <[email protected]> wrote:
> >
> >   
> >> Hi Georgios,
> >> Hi all,
> >>
> >> I am working my way through the RMD QOSM specification. I 
> have a few comments:
> >>
> >> Major comment:
> >> --------------
> >>
> >> * From the IANA registry I understand that the PHR Container is a 
> >> QSPEC parameter. Correct?
> >>
> >> If it is then there is a problem since the "Container ID" 
> is supposed 
> >> to be a single value registered for the name of the object. You 
> >> cannot assign different IDs to it, such as PHR_Resource_Request, 
> >> PHR_Release_Request, PHR_Refresh_Update
> >>     
> >
> > Georgios: Not really!
> > The Container ID is similar to Parameter ID. You can have 
> as many as 
> > many values as the containers you want to have!
> >
> >   
> 
> Section 4.1.2. of
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-12.txt
>  defines the PHR Container.
> Here is the relevant text:
> 
>      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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |M|E|N|r|       Container ID    |r|r|r|r|          2            |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |S|M| Admitted  Hops|B|U| Time  Lag     |  Overload %   |K|     |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     | Max Adm  Hops |                                               |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>         Figure 6: PHR container
> 
>    Parameter/Container ID:
>    8 bit field, indicating the PHR type: PHR_Resource_Request, 
>    PHR_Release_Request, PHR_Refresh_Update.  
> 
> 
> While it appears that it is a single QSPEC parameter it really isn't.
> It is, in fact, a request to IANA to allocate 3 QSPEC 
> parameters, as shown above.
> 
> I don't know whether anyone in the group considers this to be 
> a problem. 
> So far, nobody raised some concerns. 
> 
> 
> >> To resolve the problem I would put the "Container ID" into 
> a separate 
> >> field. Not a big change.
> >>     
> >
> > Georgios: I am not sure that this is a problem, since, similar to 
> > Parameter ID, you can use more values for the Container ID.
> >
> >   
> >> -------------------
> >>
> >> * The IANA consideration section is a mess.
> >>
> >> 6. IANA Considerations
> >>
> >> RMD-QOSM requires a new IANA registry for the RMD QoS Model 
> >> Identifier. It is a 8-bit value, carried in the <QSPEC
> >> Type> field of
> >> the QSpec object [QSP-T].
> >>
> >> [hannes] I think you want to say that
> >>
> >> "
> >> 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 
> >> [ref-to-QSPEC].
> >> "
> >>     
> >
> > Georgios: Agree! thank you very much!
> >
> >   
> >> RMD-QOSM defines 2 new objects for the QSpec Template: PHR 
> container 
> >> and PDR container, see 4.1.2 and 4.1.3. For these new 
> containers, new 
> >> IDs in the QSpec Template Object Type registry should be assigned.
> >>
> >>
> >> [hannes] You should write:
> >>
> >> "
> >> The following new parameters are registered in the Parameter ID 
> >> registry that was created with [ref-to-QSPEC]:
> >>
> >> Value Parameter ID
> >> --------------------------------+------------------------
> >> To-be-assigned-by-IANA | PHR Container To-be-assigned-by-IANA | 
> >> Bandwidth To-be-assigned-by-IANA | PDR Container
> >>
> >> ---------------------------
> >>     
> >
> > Georgios: Agree! thank you very much!
> >
> >   
> >>
> >> Minor comments:
> >> ---------------
> >>
> >> * Figure 4 and Figure 5
> >>
> >> I don't know what format is described with this figure. Is 
> Figure 4 a 
> >> snippet of <PHB Class> Parameter defined in the QSPEC?
> >>     
> >
> > Georgios: Yes! We can mention this in the text!
> >
> >   
> >> --------------------
> >> * Delete the following sentence:
> >>
> >> Note that the Parameter ID is equal to Bandwidth_ID. After IANA 
> >> assigns the proper ID value to the <Bandwdith> parameter then the 
> >> Bandwdith_ID term has to be replaced accordingly.
> >>
> >> Just replace the "Parameter ID" in the figure with "Bandwidth ID".
> >>     
> >
> > Georgios: Okay
> >
> >   
> >> ----------------------
> >>
> >> * The figure with <Bandwidth> parameter format has no figure #.
> >>
> >> * <K>: 1 bit. When set to "1" it indicates that the 
> >> resources/bandwidth carried by a tearing RESERVE MUST not be 
> >> released.
> >>
> >> --> MUST NOT be ...
> >>     
> >
> > Georgios: Okay!
> >
> >   
> >> ----------------
> >>
> >> More comments
> >>
> >> ---------------------------------------------------------
> >>
> >> * I am curious what the per flow intra-domain QoS-NSLP states 
> >> actually mean. I thought that RMD is particularly 
> targeting non-per 
> >> flow intra-domain states.
> >>     
> >
> > Georgios: It is related to the per flow states that are 
> maintained at 
> > the edges!
> > The per-flow intra-domain QoS-NSLP means that there are per flow 
> > states at the edges that are used to store information 
> associated with RMD-QOSM.
> >
> >   
> 
> That might be good to mention somewhere. For example, in the 
> terminology section.
> 
> >   
> >> -----------
> >>
> >> * The protocol has a number of options.
> >> A couple of very fundamental deployment choices are listed at 
> >> beginning of Section 3.2.3. Is there are single 
> >> mandatory-to-implement variant?
> >>     
> >
> > Georgios: We have not defined a single 
> mandatory-to-implement variant!
> > We, however identified which deployment choices can be combined 
> > together in Section 3.2.3.
> >
> >   
> I see.
> 
> >> -----------------
> >>
> >>
> >> * I don't understand this sentence:
> >>
> >> " The RMD QoS model functionality is notified by reading the <M>
> >>   parameter of the "PDR Container" that the reservation has been
> >>    successful. "
> >>     
> >
> > Georgios: We can chnge it as:
> > "The reservation has been successful if the <M> bit carried by the 
> > "PDR Container" is not set and equal to "0"."
> >
> >   
> Sounds good.
> 
> >> -----------------
> >>
> >> * I am not sure what you mean by "QoS-NSLP" functionality in the 
> >> following sentence:
> >>
> >> "
> >> Furthermore, the INFO_SPEC object SHOULD be read by the QoS-NSLP
> >>    functionality.
> >> "
> >>     
> >
> > Georgios: What about:
> > "The "INFO_SPEC" is processed as defined in the QoS-NSLP 
> > specification."
> >
> >   
> Sounds good.
> 
> >> * Why do you say that the values of the INFO_SPEC object 
> "SHOULD" be:
> >>
> >> "
> >> In case of successful reservation the INFO_SPEC object
> >>
> >>    SHOULD have the following values:
> >>
> >>    * Error Severity Class: Success
> >>    * Error Code value: Reservation successful "
> >>
> >> rather than MUST.
> >>     
> >
> > Georgios: Okay!
> >
> >   
> >> ---------------------------
> >>
> >> * "the SCOPING flag MUST not be set, meaning that a default
> >>       scoping of the message is used.
> >> "
> >>
> >> ... flag MUST NOT ...
> >>     
> >
> > Georgios; Okay!
> >
> >   
> >> -----------------------------------
> >>
> >>
> >>
> >> *  Section 4.6.1.1.2:
> >>
> >> * " Note that the DSCP value MUST be obtained from the
> >>       MRI values obtained from GIST. The value of the DSCP value 
> >> SHOULD
> >>       be obtained via the MRI parameters that the QoS-NSLP 
> receives 
> >> from GIST.
> >>
> >> Duplicate sentence. Why not to say "MUST" instead of SHOULD?
> >> Where else would you get the prarameters from.
> >>     
> >
> > Georgios: Okay!
> >
> >   
> >> * "   *  If the bandwidth allocated for the PHB_high_priority
> >> traffic is fully utilized, and a high priority request 
> arrives, other 
> >> policies can be used, which are beyond the scope of this document."
> >>
> >> ... other policies can be used for what? For granting the request ?
> >>     
> >
> > Georgios: we have to clarify that the policies are related 
> to how the 
> > allocated bandwidth is allocated, rather than policies that e.g., 
> > grant the request
> >
> >   
> OK.
> 
> >> * Furthermore, the "B" (BREAK) QoS-NSLP flag in the end to end
> >>    RESERVE message MUST not be set and it MUST be unset if 
> it was set,
> >>    see QoS-NSLP-RMF API described in QoS-NSLP.
> >>
> >>
> >> ... MUST NOT ...
> >>     
> >
> > Georgios: Okay!
> >
> >   
> >> Why do you want to clear the B flag?
> >>     
> >
> > Georgios: You are right! The text "and it MUST be unset if 
> it was set"
> > should be removed.
> >
> >   
> >> * "   *  the value of the <M> field of the PDR container MUST
> >> be equal to
> >>       the value of the <M> parameter of the PHR container that was
> >>       carried by its associated intra-domain RESERVE(RMD-QSpec)
> >>       message."
> >>
> >> Why is this necessary?
> >>     
> >
> > Georgios: because the PDR container will be sent to the ingress and 
> > the M value should be the same as the M value contained in the 
> > intra-domain RESERVE message. We will clarify this!
> >
> >
> >   
> Thanks.
> 
> >> *  the value of the Parameter/Container ID field of the 
> PDR container 
> >> MUST be set "PDR_7" (i.e., PDR_Reservation_Report);
> >>
> >> Why is this specific value used?
> >>     
> >
> > Georgios: This is a temporary value, that should be used until IANA 
> > assigns the values required by RMD-QOSM. In Section 4.1 we explain 
> > this point.
> >
> >   
> Got it.
> 
> >> *    * Furthermore, an initial QSpec object MUST be included in the
> >>      RESPONSE message. The parameters included in the QSPEC <QoS
> >>      Reserved> object are copied from the original <QoS 
> Desired> values.
> >>
> >> About what RESPONSE message are we talking about? In all 
> other cases 
> >> so far you distinguished between the e2e and the intra-domain 
> >> RESPONSE.
> >>     
> >
> > Georgios: The bullet is associated with the end-to-end RESPONSE.
> > We can emphasize this even more!
> >
> >   
> Ok.
> 
> >> --------------------------------------------------
> >>
> >> *  Section 4.6.1.4:
> >>
> >> If a QNE edge or QNE Interior node is not able to reserve 
> the number 
> >> of requested resources, the "PHR_Resource_Request" that is 
> associated 
> >> with the <Bandwidth> parameter MUST be marked.
> >>
> >> How is it marked?
> >>     
> >
> > Georgios: You are right! It should say "MUST be <M> marked 
> (i.e., <M> 
> > bit MUST be set)
> >
> >   
> >> -------------------------
> >>
> >> * Section  4.6.1.5
> >>
> >> "If a refresh RESERVE message does not arrive at a QNE 
> Interior node 
> >> within the refresh time-out period then the resources 
> associated with 
> >> this message are removed."
> >>
> >> How do you remove resources based on a non-received message?
> >>     
> >
> > Georgios: It should say "then the resources associated with this 
> > message are not updated. This will mean that the reserved bandwdith 
> > associated with the reduced state is decreased in the next refresh 
> > period by the corresponding bandwidth that was not 
> refreshed, see Section 4.3.3."
> > We will clarify this, thanks.
> >
> >   
> Ok.
> 
> >> "However, in the situation
> >> that an end-to-end (tear) RESERVE is retransmitted, see 
> Section 5.2.4 
> >> in [QoS-NSLP], then this message MUST not initiate an intra-domain
> >> (tear) RESERVE message. This is because the RMF values 
> related to the 
> >> end-to-end (tear) RESERVE message have been already 
> released during 
> >> the process of the original (initial) end-to-end (tear) RESERVE 
> >> message."
> >>
> >> In short you want to say that when resources have been released 
> >> already then you do not release them again.
> >>
> >> ... use MUST NOT .... if you want to keep the above listed text.
> >>     
> >
> > Georgios: Agree!
> >
> >   
> >> * In Section 4.6.1.5 you do a lot of calculation on the T_Lag.
> >> Unfortunately, you do not expain why you do all the calculation.
> >>     
> >
> > Georgios: You are right! We will do that!
> >
> >   
> >> --------------------------------------------------
> >>
> >> * 4.6.1.2.3
> >>
> >> " The QSpec that was carried by the end to end RESERVE 
> belonging to 
> >> the same session as this end-to-end RESPONSE is included in this 
> >> message."
> >>
> >> When you say "this message" then to what message do you refer?
> >>     
> >
> > Georgios: We refer to the end-to-end RESPONSE message. We 
> will include 
> > end-to-end RESPONSE message.
> >
> >   
> >> * To which context does this statement refer "
> >> The "E" flag associated with
> >> the QSpec <QoS Reserved> object and the "E" flag 
> associated with the 
> >> <TMOD-1> parameter are set. "
> >>     
> >
> > Georgios: The above paragraph refers to the generation of the 
> > end-to-end RESPONSE message.
> > Note that <QoS Desired> values are carried by the 
> end-to-end RESERVE 
> > and the values of the <QoS Reserved> are carried by the 
> end-to-end RESPONSE.
> > We will clarify this.
> >
> >   
> >> This paragraph is totally confusing.
> >>     
> >
> > Georgios: We will try to clarify it!
> >
> >   
> >> --------------------------------------------------------
> >>
> >>
> >> * 4.6.1.3.1
> >>
> >> * Up to this section I have not understood what the "single-" vs.
> >> "multiple-" domain stuff is about .
> >>
> >> " In a single-domain case the PDR container field
> >>       is not needed in the message. "
> >>     
> >
> > Georgios: I see what you mean! We will clarify this!
> >
> >   
> >> *  "the PDR has to be processed and removed by the RMD-QOSM
> >>       functionality in the QNE Ingress node.  The RMD-QOSM
> >>       functionality is notified by the <PDR M> parameter 
> of the PDR 
> >> container
> >>       that the refresh procedure has been successful or 
> unsuccessful."
> >>
> >> Does the first ingress node remove the PDR container?
> >> What does the last sentence mean?
> >>     
> >
> > Georgios: Yes, there is only one ingress node.
> > The second sentence should actually be used as first sentence.
> >
> >   
> >> More comments ---------------------------------
> >>
> >> * Section 4.6.1.4.
> >>
> >> * "If a QNE edge or QNE Interior node is not able to
> >>      reserve the number of requested resources, the
> >>      "PHR_Resource_Request" that is associated with
> >>      the <Bandwidth> parameter MUST be marked."
> >>
> >> How is it marked?
> >>     
> >
> > Georgios: Agree, we will fix this! It should say that it is 
> <M> marked 
> > (i.e., <M> bit is set).
> >
> >   
> >> ------------------------------------------
> >>
> >> * PDR container and a PHR Container.
> >>
> >> Section 4.1.2. and 4.1.3 just say "This is the container."
> >> but do not really explain why they need to exist.
> >>
> >> I think that it would be really important to say something 
> about it.
> >>     
> >
> > Georgios: Agree, we will fix this!
> >
> >   
> >> -----------------------
> >>
> >>
> >> * Why do you need the <Admitted Hops> value? For 
> statistical purposes?
> >>     
> >
> > Georgios: No, this is used during the partial release procedure!
> > I thought that we gave examples for the use of each 
> parameter in the 
> > containers!
> >
> >   
> I have to re-read that part.
> 
> >>
> >>
> >> More comments:  -------------------
> >>
> >> With an aggregate reservation the timeout for a 
> reservation refers to 
> >> the entire aggregate.
> >> Hence, if there is a timeout then the entire aggregate is removed.
> >>
> >> Correct?
> >>     
> >
> > Georgios: yes it is correct!
> > We will include a procedure that solves this issue.
> >
> >   
> >> ------------------------
> >>
> >> Is the <PHB Class> object mandatory in an intra-domain RESERVE?
> >>
> >> Reading Section 4.6.1.1. I didn't get the impression.
> >>
> >> Reading Section 4.6.1.3.2 I got the impression it is mandatory:
> >>
> >> " Any QNE edge or QNE Interior
> >>    node that receives a "PHR_Refresh_Update" field
> >>    MUST identify the traffic class state (PHB) (using the
> >>    <PHB Class> parameter). "
> >>     
> >
> > Georgios: Thanks, we will fix this!
> >
> >   
> >> -----------------------
> >>
> >> In  Section 4.6.1.3.1 you write:
> >>
> >> "
> >>    Most of the non-default values of the objects contained in this
> >>    message MUST be used and set by the QNE Ingress in the same
> >>    way as described in Section 4.6.1.1.  The following objects are
> >>    used and/or set differently:
> >> "
> >> Still, you list the following statement although it is 
> written in the 
> >> same way in Section 4.6.1.1:
> >>
> >> *  The flag REPLACE MUST be set to FALSE = 0;
> >>     
> >
> > Georgios: You are right! We will have to remove the sentence above!
> >
> >   
> >> ----------------------------------
> >>
> >> * "When the RMD-RMF of a QNE edge or QNE Interior node processes a 
> >> "PHR_Release_Request"  PHR container it MUST identify the 
> <PHB Class> 
> >> parameter and estimate the time period that elapsed after the 
> >> previous refresh, see also Section 3 of [CsTa05].
> >>
> >>
> >> The sentence should say "QNE egress and interior nodes ..."
> >> The ingress is not included since it sends the PHR_Release_Request.
> >>     
> >
> > Georgios: Yes, you are right!
> >
> >   
> >> -------------------------
> >>
> >> * There is something wrong with the description of the Partial 
> >> Release Procedure since the description assumes that the PHR 
> >> container contains the <Max_Admitted_Hops> parameter.
> >>
> >> The PHR container only contains the <Admitted Hops> parameter.
> >>     
> >
> > Georgios: You are right! We assumed that this will be 
> carried by the 
> > PDR container. However, there is a mismatch in the text. We 
> will fix 
> > this by including the <Max_Admitted_Hops> parameter into the PHR 
> > container and fixing the text where needed.
> > Thus the PHR container will include, in addition to the 
> common header, 
> > 2 words, instead of one.
> >
> >   
> >> Example:
> >> "
> >> * the value of the <Max Admitted Hops> parameter of the PDR  
> >> container included in the received PDR container (with <M>=1 and
> >> <S.=0) carried by the intra-domain RESPONSE message, MUST be  
> >> included in the <Max_Admitted_Hops> parameter of the "PHR  
> Container".
> >> "
> >>
> >> The following text only works if the RESERVE message 
> contains a PDR 
> >> container, which is currently not mandated.
> >> "
> >>     
> >
> > Georgios: Yes! But it is better to include the <Max_Admitted_Hops> 
> > parameter into the PHR container.
> >
> >   
> >> Furthermore, the QNE MUST perform the following procedures.
> >> If the values of the <M> and <S> parameters included in the 
> >> "PHR_Resource_Release" PHR container are (<M=1> and <S>=0) 
> then the 
> >> <Max_Admitted Hops> value MUST be compared with the calculated 
> >> <Admitted Hops> value."
> >>     
> >
> > Georgios: Yes, you are right! we will modify it!
> >
> >   
> >> ---------------------------
> >>
> >> *  Furthermore, somewhere in Section 4.6.1.5.2 you write:
> >>
> >> "Note that the above described procedure applies to the situation 
> >> that the QNE edges maintain a per flow QoS-NSLP reservation state."
> >>
> >> It would be good to know which parts exactly relate to the 
> per-flow vs.
> >> the aggregate reservation state since there is obviously a lot of 
> >> text "above".
> >>     
> >
> > Georgios: Agree, we will make it more clear!
> >
> >   
> >> I am not sure why you think that the partial release 
> procedure would 
> >> only be applicable to the per-flow reservation state.
> >>     
> >
> > Georgios: This is because the aggregated reservation 
> procedure depends 
> > on more than one micro-flows and the way of adding or releasing 
> > aggregated resources is different than the method used for the 
> > per-flow reservation states.
> >
> >   
> Have to re-read that part again.
> 
> 
> Ciao
> Hannes
> 
> >> Ciao
> >> Hannes
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> nsis mailing list
> >> [email protected]
> >> https://www1.ietf.org/mailman/listinfo/nsis
> >>     
>