Re: Call for censensus on path forward

[Glenn Mansfield Keeni <glenn@cysols.com>]

Wes Hardaker wrote:
> > > > > > On Sat, 21 Sep 2002 20:18:34 +0900, Glenn Mansfield Keeni <glenn@cysols.com> said:
> Glenn> So the question is, why do we need Aggregate MIBs ?
>
> My view on Glenn's draft is that if small-sampling-period data
> gathering is needed, then we need something "like" Glenn's MIB.
> Defining new PDUs which are still subject to network transmission
> delays will not help if micro-second sampling is needed.
I need to clarify one thing - Aggregate MIB is not specifically
designed to solve the problem micro-sampling neither is it trying
to solve the problem of polling (vs trap/informs). Yet, it is
effective in both cases.
Aggregation provides a mechanism by which an application designer
or operator can define Aggregate MOs based on the MOs that the
protocol/device/application designers have developed. This mechanism
of using "Macro" MOs yields performance.
It enables applications to suck more data from agents. Operators
will not have to turn off small interval polling. And developers
will not cringe at the idea that more MOs need to be polled at
smaller intervals.
If you are interested in MO1, MO2, ... MOn  (whether at 1 second
or at 1 minute or at 1 hr interval) repeatedly, is it not a good
idea to define a Macro object MMO that represents MO1,... MOn so
that applications can send the query
         Get MMO
instead of sending the query
         Get MO1, ... MOn

[The similar trend in application development, you will agree, is
to build in mechanisms/APIs that can simplify the often repeated
operations. I see this as an evolution in the same direction.]

The Time based aggregation proposed in the TAggregate-MIB works
just as well whether you want sampling at 1ms or at 5 minutes. The
point is that as the interval gets smaller - it gets to be difficult
to do polling using the avaliable MOs. So either you do not poll at
smaller intervals or you use techniques like Aggregation.

> I do not know if micro-sampling itself is needed, as I've never needed
> it, but I can see cases where it might be useful.  It's likely to be a
> chicken-and-egg problem as well, because it certainly won't be usable
> until a solution is designed for it.
>
> Now, my personal view of the MIB itself is that the goal is right, but
> the particular data delivery mechanism is not what I would have
> picked.  I would prefer to see data delivered via normal operations
> (eg, a TRAP/INFORM or their replacements [note that I was intending to
I do not get the point. The Aggregate MIB proposal is not tied to any
data deliver mechanism - "get" or "inform". The performance benefits are
the same in both cases. The performance is for every PDU. Instead of
'N' MO instance identifiers you use 1 MOInstance  identifier. Irrespective
of whether it is a Get/Response PDU or a trap/Inform PDU.

> put a replacement in my draft]) rather than compressed into an OCTET
> STRING.  The notifications that went out would likely need contain
> repeated instances of data, or else you'd have to handle micro-second
> delivered INFORMs.  As an example, I think if you wanted to measure
> something every 1ms you should then do so and then send out the
> combined/conglomerate results every 1s in one large notification.
That is correct.

> As far as archiving the data so that if the network was down and thus
> the notification was unable to be successfully delivered, there are
> two ways of solving this problem that already exist and I'm not sure
> we need another one.  The first is that INFORMs typically allow the
> notion of a retry, but that's not necessarily a solution people want
> to use if the downtime is long.  However, we already have the
> NOTIFICATION-LOG-MIB which is designed for archiving notifications for
> later retrieval [although some people have found problems with it, it
> doesn't mean we should abandon it for a new approach.  We should fix
> any problems with it as it'll benefit more than just this single
> problem-area].
>
> So, if a need is demonstrated for fast-polling, then I do see
> something "like" Glenn's MIB as being necessary.  Glenn is right in
> the fact that it doesn't "conflict" with the other operation documents
> on the table.  They'd likely work together.
I do not understand why you say the proposal good ONLY for fast polling?
As I have mentioned above that the Aggregation improves performance when
there is
         repeated polling of the same object
         repeated polling for multiple objects
irrespective of what the polling interval is and irrespective of what
the MOs are. Have I missed something ?


Glenn