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