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?

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.

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?

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?

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.

5. Section 4.1.2 and 4.1.3:

What is the definition of Overload %? Please include actual definition
or reference to actual definition.

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?

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.

Also applies to two paragraphs down, that contains the same structure.

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.

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?

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?

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?

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.

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.

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.

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.

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?



16. Section A.4.1:

Why are there normative statements in the appendix? That doesn't seem
appropriate.

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