Re: Call for censensus on path forward

Bob,
    I like hearing the performance issues that you have raised.
I think that the Aggregate MIB proposals addresse the points that
you have mentioned in items 2 through 6 below. Namely, that of
retrieving valuse of any MOs (not necessarily in the same table)
very frequently.
    There are actually two issues
     1. specifying a group of objects and
     2. fetching the values of a group of objects

In Aggregate MIB this is handled separately. One specifies (defines)
the Aggregate MO once and reuses it over and over again. That yields
better performance.

Glenn M Keeni

Robert Moore wrote:

> First the business part: I think the WG should focus on Wes's draft as the
> base, and merge in any unique ideas (like logical filter expressions) from
> Dave's draft.  If we're going to muck with the PDU structure at all, then
> we should try to do a reasonably complete job of it.
> 
> Regarding Wes's question about how rich to make filtering, I have what I
> think is a logically prior question: can we do *any* filtering that will
> really be useful?  I'll construct a strawman argument that reaches the
> conclusion that we can't, since I think it will be instructive for people
> to say where they think the argument breaks down.  Here it is:
> 
> 1. Filtering is being introduced to solve the performance problem of having
> to retrieve all the rows of a really big table (i.e., lots of rows, not
> lots of columns), in order to get a relatively small number of rows that
> we're really interested in.  (My understanding of the requirement for
> filtering.)
> 
> 2. We want any filtering solution to work for tables in existing MIBs.
> (Any eos solution that worked only for new MIBs wouldn't be very
> interesting.)
> 
> 3. Where filtering is really needed is when a management application needs
> to poll the same table repeatedly, especially if the polling needs to be
> done frequently.
> 
> 4. Polling, especially if it's frequent, is interested in state data from a
> table, not in configuration data that rarely changes.
> 
> 5. A large percentage of the state data in existing MIBs is in the form of
> counters.  (Superficial examination - I haven't tried to compare with any
> precision the mix of counters, gauges, and state enumerations in existing
> MIBs.)
> 
> 6. A single value of a counter is meaningless - to derive any meaning from
> a counter, you've got to take the delta of two values.  (SNMP orthodoxy.)
> 
> 7. A filter can only compare an asserted value to the single current value
> of a MIB object.  (Obvious.)
> 
> ERGO: A filtering solution cannot select table rows based on comparisons
> with meaningful values of a large percentage of the state data in the rows.
> If we want to achieve the effect of filtering on counter values, we need
> some sort of Disman solution like the script MIB, rather than just a new
> filter element in the SNMP PDU.
> 
> The discussion might proceed in either (or both!) of two directions here:
> 
>  - Your argument is wrong, because one of the premises is wrong, or because
> the logic itself is flawed.
> 
>  - Your argument is correct, but it's still useful to pursue filtering
> because even though they're rare, gauges and state enums are important
> enough in existing MIBs to make it worthwhile to add a discrimination
> capability that works only for them.  If this is what we do, though, then
> we'd better be very clear about what filtering can do, and what it can't
> do.
> 
> Glenn, I know this may be jumping the gun a bit, by diving down into a
> technical discussion.  But, hey, Wes did it first :-)
> 
> Regards,
> Bob
> 
> Bob Moore
> Advanced Design and Technology
> Application Integration Middleware Division
> IBM Software Group
> +1-919-254-4436
> [email protected]