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

From: [email-masked]
Date: Thu, 31 Aug 2000 11:01:10 -0400

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/

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 31 Aug 2000 11:50:42 -0400

Actually, given the consistency problems implicit in having ifNumber and 
ifDirection in each of these tables, I do think it would be better if they 
were removed.  My concern is almost the opposite of Bob's.  To paraphrase, 
Bob is suggesting that leaving these indices in the table allows one to 
detect misconfiguration.  The alternative view is that having them in the 
table makes possible inconsistent setting.  What should the system do if 
the "next" pointer from IfNumber 1, IfDirection In is pointing to a row 
with IfNumber 6, IfDirection Out?  Is this an error?  Is this to be 
ignored?  Having these fields produces inconsistency for little value.

Yours,
Joel M. Halpern