Subject: Re: [Diffserv] Comments on the -04 Diffserv MIB

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 01 Sep 2000 11:07:59 -0400

Bob:
Thank you very much for your detailed comments.
Some of the issues you indicated has already been addressed
in the -05 draft, close to its final stage before "list-ready".
Other points you made indicate the write up needed some
clarification.  I'll add these in.
You have a pretty long list :), I'll give you an itemized reply when
I get thru this in detail.
Thanks again.
-- Kwok --

At 11:01 AM 8/31/00 -0400, [email-masked] wrote:
>
>
>I've got a number of comments on the -04 version
>of the Diffserv MIB.  I've divided them into two
>groups:  Major/Technical and Minor/Editorial.
>
>Major/Technical:
>
>1. Section 3.2.1, elsewhere:  Just a reminder of
>   the previous agreement to change all of the
>   OIDs pointing to tables to RowPointers.  (In
>   section 3.2.2 this particular one is already
>   characterized as a RowPointer.)
>
>2. Section 3.4.1, first paragraph:  The last
>   sentence says that an algorithmic dropper's
>   Next pointer [always] points to a queue.  The
>   object definition (p. 45) says that *for
>   example* it points to a queue.  On page 10
>   (section 3.4.2), the first full paragraph says
>   that each dropper is associated with a queue
>   (because its Next element points to a queue?),
>   but it also says that "sequences of multiple
>   droppers" can be represented (by having one
>   dropper's Next element point to the next
>   dropper?).
>
>   In the -04 versions of the Model and the MIB
>   the constraints on TCBs were tightened up
>   somewhat.  Neither document says it in
>   this way, but I think the "language" for
>   describing a path through a single TCB now
>   looks like this:
>
>      [C]*[M]*[A]*[AD]*[Q]*[S]*
>
>   That is, 0 or more Classifiers, followed by
>   0 or more Meters, followed by 0 or more
>   Actions, etc.  If there are further constraints
>   on these paths (for example, "an algorithmic
>   dropper can be followed only by a queue", or
>   "an algorithmic dropper can be followed only
>   by a queue or by another algorithmic dropper"),
>   then these need to be stated explicitly.
>   The general path description says only that:
>
>     - Within a single TCB, any element can
>       be followed by another one of the same
>       type, or by one of any type further down
>       the list.
>
>     - With cascaded TCBs, any element at the
>       "right" end of the first TCB can be
>       followed by any element at the "left"
>       end of the second TCB.
>
>   See also Major/Technical #5 below.
>
>3. Section 4.1, plus the *Next object descriptions:
>   When elements are inactive, or when a *Next
>   pointer is bad, it's not clear what happens to
>   the traffic:
>
>     > diffServClassifierNext:  "If the row pointed
>       to does not exist, the classifier element is
>       ignored."  What happens to the traffic
>       selected by this element, especially if it
>       is not selected by any other element?  Is the
>       traffic just dropped?  If not, how does it
>       get merged back in with the traffic that's
>       getting to the output queue via valid paths
>       through the TCB?
>
>     > diffServMeterSucceedNext and ...FailNext:
>       "The value zeroDotZero in this variable
>       indicates no further Diffserv treatment is
>       performed on this traffic by the current
>       interface for this interface direction. If
>       the row pointed to does not exist, the meter
>       element is considered inactive."  Again, if
>       no further Diffserv treatment is performed
>       on the traffic, how is it merged back with

>       the traffic for which further treatment is
>       performed?  Second, what are the implications
>       of an inactive meter element:  where does
>       the traffic stream that the meter was going
>       to split go?
>
>     > diffServActionNext:  "The value zeroDotZero
>       in this variable indicates no further
>       Diffserv treatment is performed on this
>       traffic by the current interface for this
>       interface direction. If the row pointed to
>       does not exist, the action element is
>       considered inactive."  First sentence:  same
>       question as before.  Second sentence:  for
>       action elements, I can understand what an
>       inactive element does -- an inactive marker
>       doesn't mark, an inactive counter doesn't
>       count, and an inactive dropper doesn't drop.
>       But where does the traffic go after the
>       non-action, since the Next pointer is bad?
>
>     > diffServAlgDropNext:  The value zeroDotZero
>       in this variable indicates no further
>       Diffserv treatment is performed on this
>       traffic by the current interface for this
>       interface direction. If the row pointed to
>       does not exist, the algorithmic dropper
>       element is considered inactive."  Same
>       questions.
>
>     > diffServQNext:  "If the row pointed to does
>       not exist, the queue element is considered
>       inactive."  What does this mean?  What
>       happens to the traffic?
>
>     > diffServSchedulerNext:  "The value
>       zeroDotZero in this variable indicates no
>       further DiffServ treatment is performed on
>       this flow by the current interface for this
>       interface direction.  For example, for an
>       inbound interface the value zeroDotZero
>       indicates that the packet flow has now
>       completed inbound DiffServ treatment and
>       should be forwarded on to the appropriate
>       outbound interface.  If the row pointed to
>       does not exist, the scheduler element is
>       considered inactive."  What does zeroDotZero
>       mean on an *outbound* interface, where the
>       final queue is modeled as part of the TCB?
>       How does this "zeroDotZero" traffic get
>       merged in with traffic that made it all the
>       way through the TCB?  Second, what does it
>       mean for a scheduler to be inactive?  What
>       happens to the traffic on the queues it
>       should be servicing?
>
>4. Section 4.2:  Arbitrary integer indexes.  These
>   are all described as being unique across the
>   entire agent, when they clearly don't have to
>   be.  Will this cause coordination problems in
>   subagent environments?  Would it be better to
>   define the *NextFree objects as being in a table
>   indexed by ifNumber + ifDirection?  Then each
>   subagent would be able to manage its index
>   values independently of the other subagents.
>
>   Note that a single table would be sufficient
>   to contain all of the *NextFree objects.  Note
>   also that if it wanted to, a monolithic agent
>   could still return index values that are unique
>   across the entire agent.  It just wouldn't

>   be required to any more.
>
>5. Page 23, diffServClassifierTcb object:  The
>   second paragraph doesn't really fit here.  It
>   sounds like all that a manager needs to worry
>   about is getting a unique TCB number.  But
>   these aren't arbitrary integers -- they
>   indicate order of processing for the traffic
>   on an interface/direction.  What is a manager
>   supposed to do if it finds a TCB numbered 1
>   on an interface/direction, and it wants to
>   create a new TCB ahead of it?
>
>   Also, how can a single TCB number handle the
>   case where traffic is fanned out to multiple
>   peer TCBs?, If, for example, the Succeed
>   and Fail streams for a meter in TCB 1 each
>   needs to be passed through a classifier,
>   which TCB/classifier will be numbered 2 and
>   which will be numbered 3?
>
>   Given these problems with TCB numbers, I
>   think that the MIB should go back to modeling
>   only the datapath elements, and not attempting
>   to model TCBs.  One problem with doing this
>   is that it's no longer easy to identify the
>   first datapath element for a given interface/
>   direction combination.  (With the current MIB
>   this is easy only when this first element is
>   a classifier, since classifiers are the only
>   elements that have TCB numbers associated
>   with them.)   This problem is easily solved,
>   though, by adding one more column to the
>   ifNumber + ifDirection table I proposed
>   above in Major/Technical #4:  a RowPointer
>   to the first element for that interface/
>   direction.  This, in fact, is exactly what
>   Joel suggested back in Pittsburgh.  I'm not
>   sure I agree with his reason for suggesting
>   it, though:  to make it possible to remove
>   ifDirection as an index from all of the
>   element tables.  If we follow this approach
>   to its logical extreme, then we might as
>   well go ahead and remove ifNumber as well,
>   and use only an arbitrary integer for
>   indexing each of the element tables.
>
>   The problem with doing this is that if a
>   RowPointer ever gets set incorrectly,
>   there's no scoping the problem:  any
>   element entry for the entire device might
>   have been its intended target.  With
>   ifNumber and ifDirection included as element
>   indexes, the search for the "misplaced"
>   target of the RowPointer is much narrower.
>   To be fair, Joel didn't suggest that we
>   remove ifNumber as an index, just
>   ifDirection.  I'm inclined, though, to leave
>   both ifNumber and ifDirection in as indexes
>   for the element tables.
>
>   Note that unlike the other configuration
>   objects in the MIB, this RowPointer pointing
>   to the first element for an interface/direction
>   has read/write access rather than read/create.
>   The rows of the ifNumber + ifDiretion table
>   will always exist, so a manager can get the
>   *NextFree objects when it needs to.  The
>   RowPointer will need to be initialized with a
>   value like zeroDotZero, meaning that there is
>   no Diffserv treatment currently configured for
>   that interface/direction.
>

>6. Page 41, diffServCountActStatus object:  Can
>   you really have a RowStatus object for a row
>   containing only counters and a discontinuity
>   indicator?  It seems like deactivation /
>   reactivation of a row would just be an indirect
>   way for a manager to do what it isn't allowed
>   to do directly:  reset the counters in the row.
>   In any case, the last sentence of the
>   description for this object makes no sense,
>   because there aren't any writable objects
>   in the table other than the RowStatus object
>   itself.
>
>7, Pages 46-47, diffServAlgDrop counters:  For
>   the same reason that the action counters
>   needed to use their own discontinuity indicator
>   rather than ifCounterDiscontinuityTime, these
>   counters need their own discontinuity indicator
>   as well.
>
>8. Page 55:  diffServSchedulerEntry:  Why isn't
>   there a diffServSchedulerSpecific object here,
>   to point "down" to additional configuration
>   parameters for other types of schedulers?
>   The QoS Device Information Model already has
>   definitions for several specific types of
>   schedulers that this MIB does not cover.
>
>9. Pages 58-69, MIB Compliance section:
>
>     > The comment (p. 58) referring to the
>       ifCounterDiscontinuityGroup is wrong.
>       You need a group in this MIB containing
>       diffServCountActDiscontTime, since it
>       currently does not appear in any group.
>
>     > It's possible that there are other
>       accessible objects not included in
>       any conformance group.  The only way
>       to be sure is to run the module through
>       a MIB compiler.
>
>     > The six mandatory groups for the module
>       don't leave room for implementations
>       that support only a subset of the Diffserv
>       functions, for example, classifying and
>       marking packets.  Such implementations
>       clearly should not have to support the
>       groups related to monitoring and
>       configuring the other Diffserv functions.
>
>     > Why is an implementation that supports
>       only the actions defined in this MIB
>       required to implement the
>       diffServActionSpecific object?
>
>Minor/Editorial:
>
>1. To position the document more clearly, the first
>   sentence in the Abstract should say "This memo
>   describes an SMIv2 MIB for monitoring and
>   configuring a device ...."
>
>2. You need to add the SHALL, SHOULD, ... sentence,
>   and the corresponding reference to RFC 2119.
>
>3. Section 2.1:  The sentence "When a TCB performs
>   no classification the literal TCB of the
>   succeeding elements is not used in their instance
>   (index) as there is no need to distinguish them -
>   each element is unique already" is confusing.
>   Whether or not a TCB includes a classifier, the
>   indexes of the other elements do not include the
>   TCB number.
>
>4. Section 3.2:  [SRTCM] and [TRTCM] look like
>   references, but there are no entries corresponding
>   to them in the References section.
>
>5. Figure 2:  The names and order of the attributes
>   shown for the Scheduler don't match those in the
>   Scheduler table in the MIB.

>
>6. Section 4.2:  The special semantics for the value
>   0 in the *NextFree objects should be stated in the
>   objects' descriptions, not just here.
>
>7. Page 9, diffServSixTupleClfrSrcL4PortMax object:
>   the name for the ...PortMin object in the
>   description is incorrect.  Also, "order" is
>   misspelled.
>
>8. Page 34, diffServTBMeterBurstSize object:  a
>   comment "-- INTEGER (0..'7FFFFFFF'h)" after
>   the SYNTAX line would save the reader a trip to
>   the RFC repository.
>
>9. Page 44, diffServAlgDropType object:  the second
>   sentence should also mention the value
>   randomDrop(4).
>
>10. Page 49, diffServRandomDropMaxThreshBytes and
>    diffServRandomDropMaxThreshPackets objects:
>    The descriptions for these objects refer to a
>    diffServRandomDropInvMaxProb object that is
>    not defined in the table.
>
>11. Page 52, diffServQPriority object:  Is the
>    sentence in the description really correct?
>    If the traffic path is
>
>       Q1--->Q2--->S1
>
>    then the scheduler S1 is "the next scheduler
>    element downstream" from Q1.  Does Q1's
>    priority parameter really get all the way to
>    S1?  (If the answer is that this is not an
>    allowed sequence of elements, then that is
>    part of the answer to Major/Technical #2.
>    Note that the description for the
>    diffServQNext object, also on page 52, says
>    that the element after a queue is *for
>    example* a scheduler.)
>
>12. Page 57, diffServSchedulerNext object:  The
>    description should make it clear that when
>    the Next pointer points to anything other
>    than another scheduler, then the element
>    pointed to must be in a different TCB from
>    the scheduler that's doing the pointing.
>
>13. Pages 58-69, MIB Compliance section:
>
>      > diffServMIBSixTupleClfrGroup (page 66):
>        what do the words "and upper-layer
>        protocol" in the description refer to?
>        Aren't these objects just for
>        classifying packets based on the fields
>        in their IP headers?
>
>      > The descriptions for the three Counter
>        groups (pages 67-68) are all the same.
>
>
>Regards,
>Bob
>
>Bob Moore
>IBM Networking Software
>+1-919-254-4436
>[email-masked]
>
>
>
>_______________________________________________
>diffserv mailing list
>[email-masked]
>http://www1.ietf.org/mailman/listinfo/diffserv
>Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/
> 

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www-nrg.ee.lbl.gov/diff-serv-arch/