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

From: "Kwok-Ho Chan" <[email-masked]>
Date: Fri, 01 Dec 2000 05:49:56 -0500

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