RMD Comments
Hannes Tschofenig <[email protected]>
| Newsgroups | gmane.ietf.nsis |
|---|---|
| Message-ID | <[email protected]> |
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