Subject: [NSIS] RMD Comments

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 02 Nov 2007 00:25:22 +0100

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

 To resolve the problem I would put the "Container ID" into a separate 
 field. Not a big change.

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

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

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

 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?

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

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

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

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

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

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

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

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

* 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.
 "
 * 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.
---------------------------
 
 * "the SCOPING flag MUST not be set, meaning that a default
       scoping of the message is used.
 "
 
 ... flag MUST NOT ...
 
-----------------------------------

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

 * 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 ...
 Why do you want to clear the B flag?

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

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

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

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

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

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

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

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

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

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

This paragraph is totally confusing.

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

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

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

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?

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

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

 * Why do you need the <Admitted Hops> value? For statistical purposes?

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

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

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

 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;

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

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

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

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

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

*  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".
 I am not sure why you think that the partial release procedure would 
 only be applicable to the per-flow reservation state.
 
Ciao
Hannes

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

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Fri, 02 Nov 2007 07:11:25 +0000

Hi Hannes

Thank you very much!
Please see some answers in line!

Best regards,
Georgios

>I am working my way through the RMD QOSM specification. I have a few comments:

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!

> To resolve the problem I would put the "Container ID" into a separate

Georgios: I am not sure that this is a problem, since, similar to
Parameter ID, you can use more values for the Container ID.

Georgios: Agree! thank you very much!

> ID registry that was created with [ref-to-QSPEC]:

Georgios: Agree! thank you very much!

> Minor comments:

Georgios: Yes! We can mention this in the text!

Georgios: Okay

Georgios: Okay!

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.

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.

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

Georgios: What about:
"The "INFO_SPEC" is processed as defined in the QoS-NSLP
specification."

>    * Error Code value: Reservation successful "

Georgios: Okay!

Georgios; Okay!

Georgios: Okay!

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

>    see QoS-NSLP-RMF API described in QoS-NSLP.

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.

>       carried by its associated intra-domain RESERVE(RMD-QSpec)

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!

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

> so far you distinguished between the e2e and the intra-domain

Georgios: The bullet is associated with the end-to-end RESPONSE.
We can emphasize this even more!

Georgios: You are right! It should say "MUST be <M> marked (i.e.,
<M> bit MUST be set)

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.

> ... use MUST NOT .... if you want to keep the above listed text.

Georgios: Agree!

>Unfortunately, you do not expain why you do all the calculation.

Georgios: You are right! We will do that!

Georgios: We refer to the end-to-end RESPONSE message. We will include
end-to-end RESPONSE message.

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

Georgios: I see what you mean! We will clarify this!

> What does the last sentence mean?

Georgios: Yes, there is only one ingress node.
The second sentence should actually be used as first sentence.

>      the <Bandwidth> parameter MUST be marked."

Georgios: Agree, we will fix this! It should say that it is <M> marked
(i.e., <M> bit is set).

Georgios: Agree, we will fix this!

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!

> Hence, if there is a timeout then the entire aggregate is removed.

Georgios: yes it is correct!
We will include a procedure that solves this issue.

Georgios: Thanks, we will fix this!

Georgios: You are right! We will have to remove the sentence above!

Georgios: Yes, you are right!

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.

> container, which is currently not mandated.

Georgios: Yes! But it is better to include the <Max_Admitted_Hops>
parameter into the PHR container.

> <Max_Admitted Hops> value MUST be compared with the calculated

Georgios: Yes, you are right! we will modify it!

Georgios: Agree, we will make it more clear!

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 22 Nov 2007 17:44:54 +0100

Hi Georgios,

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

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

> We, however identified which deployment choices can be combined together
I see.

> "PDR Container" is not set and equal to "0"."
Sounds good.

> "The "INFO_SPEC" is processed as defined in the QoS-NSLP
Sounds good.

> how the allocated bandwidth is allocated, rather than policies that
OK.

> intra-domain RESERVE message. We will clarify this!
Thanks.

> IANA assigns the values required by RMD-QOSM. In Section 4.1 we
Got it.

> We can emphasize this even more!
Ok.

> We will clarify this, thanks.
Ok.

> I thought that we gave examples for the use of each parameter in the
I have to re-read that part.

> resources is different than the method used for the per-flow reservation
Have to re-read that part again.

Ciao
Hannes

---

From: "Georgios Karagiannis" <[email-masked]>
Date: Thu, 22 Nov 2007 17:57:33 +0100

Hi Hannes

Regarding the below comment:
> 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-masked]] 
> Sent: donderdag 22 november 2007 17:45
> To: Georgios Karagiannis
> Cc: [email-masked]
> Subject: Re: [NSIS] RMD Comments
> 
> Hi Georgios,
> 
> >> to be a single value registered for the name of the object. You 
> >> cannot assign different IDs to it, such as PHR_Resource_Request, 
> http://www.ietf.org/internet-drafts/draft-ietf-nsis-rmd-12.txt
>  defines the PHR Container.
> It is, in fact, a request to IANA to allocate 3 QSPEC 
> parameters, as shown above.
> 
> >> 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].
> >> "
> >>     
> >
> >> 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
> >>
> Figure 4 a 
> >> snippet of <PHB Class> Parameter defined in the QSPEC?
> >>     
> >
> >> 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.
> >>
> >> 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.
> 
> >   
> >> -----------
> >>
> >> beginning of Section 3.2.3. Is there are single 
> >> mandatory-to-implement variant?
> >>     
> >
> > We, however identified which deployment choices can be combined 
> > together in Section 3.2.3.
> >
> >   
> I see.
> 
> >> -----------------
> >>
> >>
> > 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.
> 
> PDR container 
> >> MUST be set "PDR_7" (i.e., PDR_Reservation_Report);
> >>
> > 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.
> 
> >> 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)
> >
> >   
> >> "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."
> >>
> > 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."
> >> (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."
> >>
> > Georgios: The above paragraph refers to the generation of the 
> > 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.
> >
> >   
> <PHB Class> 
> >> parameter and estimate the time period that elapsed after the 
> >> previous refresh, see also Section 3 of [CsTa05].
> >>
> >>
> >> * 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.
> >>
> > 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.
> >> * 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".
> >> "
> >>
> >> "Note that the above described procedure applies to the situation 
> >> that the QNE edges maintain a per flow QoS-NSLP reservation state."
> >>
> >> the aggregate reservation state since there is obviously a lot of 
> >> text "above".
> >>     
> >
> > 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.
> >
> >