Subject: Re: [Diffserv] DiffServ MIB -06: statistics

From: "Robert Moore" <[email-masked]>
Date: Fri, 1 Dec 2000 10:02:35 -0500

Kwok,

No, I wasn't thinking of these objects as needing to go into
the DiffServ Policy MIB at all.  Rather, I was asking whether
DiffServ should have a set of "ordinary" interface counters,
just like many other protocols do.  For implementations that
supported these counters, no special configuration would be
needed.  The counters would just be there on each DiffServ-
capable interface, available for a manager to read, or not
read, as it chose.

Andrew has sent me off in another direction on this question:
to the RMON WG's DiffServ Monitoring MIB.  Since DSCPs are
visible in the packet headers, a probe-based approach is
certainly possible for determining the distribution of DSCPs
sent to or from a particular device via a particular
interface.

I think that we will probably end up putting a table of the
form I suggested into our hosts.  But I can understand that
router vendors might prefer to have the performance penalty
of what will ordinarily be an extra 64-way classification
fall onto a probe rather than onto their router interfaces.

Regards,
Bob

Bob Moore
IBM Networking Software
+1-919-254-4436
[email-masked]

"Kwok-Ho Chan" <[email-masked]>@ietf.org on 12/01/2000 05:49:56
AM

Sent by:  [email-masked]

To:   Robert Moore/Raleigh/IBM@IBMUS
cc:   [email-masked], "Kwok-Ho Chan" <[email-masked]>
Subject:  Re: [Diffserv] DiffServ MIB -06: statistics

Bob:
The DiffServ MIB is geared toward using COPS-PR or SNMPCONF
for configuration/provisioning.  Hence the setting up of the data path
per interface using straight SNMP may not be as optimized but
do-able.
With use of COPS-PR and SNMPCONF for the setting up, all interfaces
of the same Role/RoleCombination will need one and only one set of
commands from the Management Server/Station, the duplication/cloning
will be done at the Network Device, hence it may not look as bad.
Hope this is sufficient to answer your concerns.

If  the addition you suggest is added to the DiffServ MIB, then this will
need to be duplicated in the SNMPCONF DiffServ Policy MIB.  Correct?

Thanks!
-- Kwok --

At 03:33 PM 11/29/00 -0500, Robert Moore wrote:
>The approach to statistics in the DiffServ MIB, where
>a set of counters is represented as a particular type of
>Action element, is very general and very flexible.  It
>strikes me, though, that it makes some ordinary types of
>statistics gathering *mighty* hard to set up.
>
>To take one example that our developers have asked about,
>suppose I want byte and packet counts for packets that
>come in / go out over an interface for each of the 64
>DSCP values.  If I want these counts on an ingress
>interface, I need to build something like this ahead of
>any other DiffServ elements on the interface:
>
>                +-----+
>                |   / |--->CountAct --\
>                | /   |--->CountAct ---\
> DataPathStart->|->-- |--->CountAct ----->NextElement
>                | \   |--->CountAct ---/
>                |   \ |--->CountAct --/
>                +-----+
>                64-way             64-way
>                classifier         fan-in
>
>This involves a whole lot of retrieving the various
>NextFree objects, creating the rows in four tables,
>and linking them up.  Plus, there are those ominous
>words before the diffServCountActTable, saying that
>in any case, implementations either support counters
>(at specific points in their datapaths?) or they
>don't.
>
>The case of an egress interface looks essentially
>the same, but with an additional oddity:  the
>classify/count/fan-in logic would need to sit
>after the last scheduler, which is ordinarily
>thought of as the last DiffServ element on the
>interface.
>
>If we think that this particular set of statistics -
>per-DSCP counts for an interface - are sufficiently
>useful that they'll often be needed, they could be
>explicitly addressed in the MIB.  This would not
>mean removing the existing CountAction objects,
>which would still be useful for capturing data at
>arbitrary points in a DiffServ processing path.
>But a structure of the following sort could be
>added to the MIB:
>
>+++++++++++++++++++++++++++++++++++++++++++++++++++++
>dscpStatsTable OBJECT-TYPE
>      SYNTAX SEQUENCE OF DscpStatsEntry
>      MAX-ACCESS not-accessible
>      STATUS current
>      DESCRIPTION
>          "."
>
>      ::= { xxxObjects 1 }
>
>dscpStatsEntry OBJECT-TYPE
>      SYNTAX DscpStatsEntry
>      MAX-ACCESS not-accessible
>      STATUS current
>      DESCRIPTION
>          "."
>
>      INDEX { ifNumber,
>              dscpStatsDirection,
>              dscpStatsDscp }
>
>      ::= { dscpStatsTable 1 }
>
>DscpStatsEntry ::= SEQUENCE {
>        dscpStatsDirection              IfDirection,
>        dscpStatsDscp                   Dscp,
>        dscpStatsPackets                Counter32,
>        dscpStatsOctets                 Counter32,
>        dscpStatsHCPackets              Counter64,
>        dscpStatsHCOctets               Counter64,
>        dscpStatsDiscontinuityIndicator DateAndTime }
>+++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>If it's going to be the case that implementations either
>do or don't support these counters at this point in the
>DiffServ processing on an interface, then why not make

>it easy to get the data from those that do?
>
>Does anybody (besides me) think this would be a
>worthwhile addition to the MIB?
>
>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://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.h

tml

_______________________________________________
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

_______________________________________________
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: Jon Saperia <[email-masked]>
Date: Fri, 01 Dec 2000 11:15:37 -0500

> fall onto a probe rather than onto their router interfaces.

Kwok, we may want to move this to some other list since this is not
specific to 06. 

I agree with the observation that one might want policy level counters
that are the aggregate of the queues used to deliver a service. One
could add these as extensions to policy configuration objects as in the
DiffServ Policy MIB (or other places). The information on how these
queues work together is almost certainly not going to be available
'outside' the device that contains the queues. So while you can do some
great things with a probe there are some things that will have to be
counted inside the router. Just as we aggregate configuration operations
we may aggregate the counters as well.

/jon

---

From: Andrew Smith <[email-masked]>
Date: Fri, 01 Dec 2000 10:48:21 -0800

Bob,

> fall onto a probe rather than onto their router interfaces.

I think it's wrong to think of DSMON (and RMON) as just something for "probes" 
to implement: these days, the only viable place to put such probes is often 
inside the router/switch. The vendors of such boxes do make value judgements as 
to how much or little RMON-like functionality to build in (and their customers, 
historically at least, always *want* more but are seldom willing to pay for it) 
e.g. in this case I think it quite likely that they might put in such counters 
for each DSCP that they are currently handling, even if they don't have them 
there for all DSCPs all of the time - any MIB for this purpose should reflect 
such implementation options to be useful (and the -06 DS MIB does allow this 
with the "Counter Action" elements).

Andrew