Subject: [Diffserv] Fwd: Two DiffServ MIB comments

From: Fred Baker <[email-masked]>
Date: Fri, 16 Mar 2001 11:56:25 -0800

I have no idea why Bob doesn't post his comments to the list.

>Importance: Normal
>Subject: Two DiffServ MIB comments
>To: [email-masked], [email-masked], [email-masked],
>         "Robert Moore" <[email-masked]>, [email-masked],
>         [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked], [email-masked], 
> [email-masked],
>         [email-masked], [email-masked],
>         [email-masked], [email-masked]
>X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000
>From: "Robert Moore" <[email-masked]>
>Date: Thu, 15 Mar 2001 09:34:13 -0500
>X-MIMETrack: Serialize by Router on D04NM200/04/M/IBM(Release 5.0.6 
>|December 14, 2000) at
>  03/15/2001 09:27:47 AM
>
>I have two concerns related to the -09 version of the
>DiffServ MIB, which we should discuss at the "summit"
>next week.  I don't think either of these should take us
>a great deal of time to resolve.
>
>1. Back around the time of the San Diego IETF, we talked
>    quite a bit about cross-interface linkages, where, for
>    example, traffic from two ingress interfaces is
>    aggregated together and passed to a meter.  As I read
>    the -06 Informal Model (section 3.2), it says that
>    while it doesn't address this case, the model could
>    be "easily extended" to do so.  This is fine for the
>    Informal Model.
>
>    For the MIB, though, it makes a real difference
>    whether cross-interface linkages are allowed for the
>    *Next pointers of the datapath elements.  I'd like
>    the MIB document to say, clearly and explicitly,
>    either that linkages of this type are allowed, or
>    that they are not allowed.  This topic is ignored
>    completely in section 5.1, which is where I'd expect
>    it to be addressed.  There is a fairly explicit
>    statement in the pre-table comments on p. 29, in the
>    actual MIB module.  But based on my own MIB editing
>    experience, I know that comments like these can very
>    quickly get out of date.  So I don't know whether to
>    trust these words.
>
>    So, first we need to make a conscious decision
>    whether to allow cross-interface linkages in the MIB,
>    and then we need to insure that the document is very
>    clear in reflecting this decision.
>
>2. While the diffServCountAct counters now have their
>    own discontinuity indicator
>    diffServCountActDiscontTime, the counters embedded in
>    the algorithmic droppers are still tied to
>    ifCounterDiscontinuityTime.  This seems wrong, since
>    it suggests that the only discontinuity events for
>    these counters involve resetting the entire interface.
>    I have been assuming all along that the DiffServ
>    configuration for an interface, including both the
>    sequence of datapath elements handling the traffic
>    and the parameterizations for these element reached
>    via the *Specific pointers, could be changed on the
>    fly, without resetting the interface.  (If this is
>    not the case, then there's no need for the
>    diffServCountActDiscontTime object either -- those
>    counters could also use ifCounterDiscontinuityTime.)
>    My expectation is that a change either to the traffic
>    flow(s) coming into an algorithmic dropper, or to the
>    dropper's own parameterization, would result in a
>    discontinuity for the dropper's embedded counters.
>    Otherwise, these counters would be combining apples
>    and oranges into a single count.
>
>    One approach would be simply to add a discontinuity
>    indicator into the diffServAlgDropTable, right
>    alongside the counters.  A more appealing approach
>    (except that I'm not sure we can make it work!)
>    would be to introduce a discontinuity indicator into
>    the diffServDataPathTable.  The idea of such an
>    indicator would be that if *anything* about the data
>    path's DiffServ configuration changed, then
>    management applications would be warned not to trust
>    counter deltas spanning the change.  (Regular
>    interface counters, tied to ifCounterDiscontinuityTime,
>    would still be fine, though.)  This one discontinuity
>    indicator would apply equally to CounterAction
>    counters on the datapath and to embedded algorithmic
>    dropper counters.  The problem with this approach is
>    that there's no easy way to say *which* discontinuity
>    indicator instance applies to a given counter.  *We*
>    know that it's the one for the datapath that includes
>    the counter.  But this means that a management
>    application needs to understand which datapath a
>    counter belongs to (which is available to it only by
>    chasing *Next pointers -- it's not discernible from
>    the counter's index value) before it can know whether
>    it's safe to use deltas from the counter.
>
>    Maybe we can become comfortable with the idea of having
>    these counter discontinuity indicators at the datapath
>    level.  But we need to think this through.
>
>Regards,
>Bob
>
>Bob Moore
>Advanced Design and Technology
>Application Integration Middleware Division
>IBM Software Group
>+1-919-254-4436
>[email-masked]

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2001 17:43:29 -0600

You can blame me. Obviously any proposed resolution of his points
has to be agreed by the WG but it seemed like a good idea to get
consensus among those most actively involved first.

   Brian