Subject: [NSIS] RMD comments

From: [email-masked]
Date: Wed, 22 Mar 2006 20:41:43 -0500

These are intended to be WG Last Call comments on the 
RMD draft, but I held them back until this afternoon's
bar-free Bar BoF was over with in the hopes of avoiding
confusion/entanglement with that set of concerns.  The
resulting short notice prior to tomorrow's meeting is an
unfortunate result.

I have two major concerns, plus some less important comments.

--- (1) RMD is subset of diffserv ---

Overall, RMD is about use of a subset of diffserv, specifically
EF or a class selector that has EF-like behavior.  It does not
support AF-like functionality where multiple PHBs/DSCPs are
used to encode drop precedence for at least the following reasons:

(a) <QoS Desired> contains only a Bandwidth element.  It does
not contain the two token buckets needed to signal AF in full
generality (cf. the QSpec Template draft which does contain
these two token buckets).

(b) The PHB_Class parameter is not capable of signaling a
PHB set, such as the various AF sets - see Section 2 of
RFC 3140.  A DSCP is ok to use here, as these messages should
not be crossing diffserv domain boundaries.  This
"should not be crossing" needs to be stated as a "MUST NOT
cross" restriction.

(c) The severe congestion remarking algorithm destroys the
drop precedence markings on AF traffic.  There may be situations
in which this is acceptable (e.g., the egress node will meter
and remark drop precedence anyway), but it is not always the
case.

I recommend simply removing AF from this draft, and adding/
rewriting portions of the introduction and other material to
make it clear that RMD is a diffserv-based bandwidth management
methodology, including avoiding any claim or implication of
full diffserv support.  It would be possible to say that a
single AF PHB with overprovisioning to deliver an EF-like
behavior, but this would need to be carefully stated to avoid
implying support for full AF drop precedence behavior. 

--- (2) Severe Congestion measurement/notification issues ---

Sections 4.6.1.6 and 4.6.1.7 appear to be problematic.

Section 4.6.1.6.2.1 recommends (SHOULD) that two DSCPs be
allocated per traffic class, but only uses one of them (for
proportional marking).  That's wasteful, although it looks
like the other one may be intended for probe-based congestion
notification (Section 4.6.1.7).  Section 4.6.1.6 should limit
itself to one DSCP per traffic class for proportional
congestion measurement, and leave threshold marking to 4.6.1.7.

The following sentence on max number of DSCPs is problematic
and misuses RFC 2119 terminology:

   It is RECOMMENDED that the total number of additional DSCPs within a 
   RMD domain, needed for severe congestion handling MUST not exceed the 
   limit of 16.

The word "MUST" ought to be deleted to correct the RFC 2119
terminology issue.  In addition, the limit of 16 is too high -
that's 25% of a scarce resource, and implies that it's usually
acceptable in general to use up to 25% of that space for this
purpose, which is not a good idea in full generality.  I would
prefer a recommendation that as few as possible be used, and
in particular that the number not exceed one per PHB.

The algorithms in Section 4.6.1.6.2.1 and 4.6.1.6.2.2 appear
to be incomplete in that they don't specify the range of bytes
over which the algorithms are to operate - is this a moving window
vs. a succession of fixed windows, and what are appropriate window
sizes?  For the latter, the window size may need to be much smaller
than a typical flow duration in order to be able to make decisions
faster than load conditions change.  How should the sizes of the
Interior and Egress node windows compare?  At best, these algorithms
are examples, and might be better qualified as such, as the marking
framework is probably amenable to other algorithms.

Section 4.6.1.7 appears to be somewhat confused - on the one
hand, it describes the interior nodes as NSIS-unaware, but on the
other hand is using an NSIS-specific threshold-based DSCP remarking
scheme in those interior nodes.  After this afternoon's session,
it's fairly clear that the PCN work is digging in about the same
place - using thresholds more aggressive than ordinary ECN to
communicate interior congestion to the edges - it might be a *very*
good idea to drop this section and refer to the appropriate CL/PCN
drafts as work in progress.

I'm not comfortable with these two sections and would prefer to
see them removed, so that the resulting document is focused on the
signaling aspects.  Based on past interactions, I suspect that's not
going to happen, and hence I would like to see these two sections
moved to an appendix to clearly separate them from the NSIS signaling
focus of the bulk of the draft.  That appendix needs to state that
for congestion management/signaling, no more than one additional
DSCP per traffic PHB SHOULD be used, and also discuss the fact
that DSCPs are a scarce resource.

--- IANA Considerations ---

The IANA considerations section is essentially missing - it does not
tell IANA what is in the registry, what to do to establish the registry,
or how to manage it.  See the rfc2434bis draft.

--- Nits ---

p.11 and p.13 - encoding of Overload % is not stated - e.g.,
what percent level of overload does the value 0x10 represent?

p.17 - The term "PHB group" shows up on this page without prior
explanation or definition.  It should not be used due to the lack
of support for AF.

p.17 - At the end of Section 4.3.3, the text should be clarified
to make it clear that the multiple classes are for admission
control (and possibly preemption?) only, as they share a single
PHB (and hence forwarding treatment) within the network.

p.22 - The next to last bullet says that <Admission Priority>
processing is described in the following bullet, but it's actually
described in the second following bullet.

Thanks,
--David
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

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

---

From: Paulo Mendes <[email-masked]>
Date: Thu, 23 Mar 2006 16:30:51 +0100

Dear David and all,

A very brief comment. I agree with David's suggestions of removing any 
allusion to AF from this draft and of clearly stating the support of RMD 
to a subset of Diffserv (actually that should also be done in I-D name 
to avoid misunderstandings).  Moreover, IMO, it would be nice if any 
solution that proposes signalling triggered per-flow (although aiming to 
maintain per-class state) would present some proofs - references -  that 
there is not a better approach to control Diffserv classes (EF in this 
case).
 
Cheers
Paulo