Subject: Re: Table Indices in AgentX MIB

From: Randy Presuhn <[email-masked]>
Date: Mon, 3 Aug 1998 14:38:11 -0700 (PDT)

Hi - 

> Date: Mon, 03 Aug 1998 17:06:09 -0400
> To: "Smitha Gudur" <[email-masked]>
> From: Bob Natale <[email-masked]>
> Subject: Re: Table Indices in AgentX MIB
> Cc: [email-masked]
...
> Where each table has a simple *unique* natural index, there
> is (IMHO) only cost incurred (and no value derived) from
> requiring other index elements to access a row.
...

There are other good reasons for using multiple indexes.  For example,
since multiple sessions can be multiplexed over a single connection,
if the session table is singly indexed it will be necessary to walk the
whole table to determine which sessions are multiplexed over a particular
connection.  If the table is indexed by both connection and session
identifiers, the retrieval takes far fewer transactions.

This depends on the kinds of usage scenarios the MIB is intended to
support.  Ones that I've found useful in the past with other subagent
protocols:

    1) determine the current membership of the set of subagents

    2) "disconnect" a particular session or connection

    3) "delete" (render ineffective) a specific registration

    4) determine what mib regions a particular subagent has claimed
       responsibility for (actually more interesting than finding
       out what subagent has claimed responsibility for a particular
       mib region)

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [email-masked]      http://www.bmc.com     
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

---

From: Bob Natale <[email-masked]>
Date: Mon, 03 Aug 1998 18:29:33 -0400

>At 8/3/98 02:38 PM, Randy Presuhn wrote:

Hi Randy,

>There are other good reasons for using multiple indexes.

There certainly are.  I don't think they apply here,
however.

>For example, since multiple sessions can be multiplexed over
>a single connection, if the session table is singly indexed
>it will be necessary to walk the whole table to determine
>which sessions are multiplexed over a particular connection.
>If the table is indexed by both connection and session

>From a practical perspective, the "whole table" in this case
(agentxSessionTable) will never be onerously large, hence
I do not think that "far fewer" transactions will be realized.
Furthermore, the frequency of this query is likely to be
extremely low.

>This depends on the kinds of usage scenarios the MIB is
>intended to support.

Yes, that is very important.

>Ones that I've found useful in the past with other subagent
>protocols:
>

One must walk the entire agentxSessionTable under either
approach to get this info; hence, the multiple indices on
that table provide no gain here.

> 2) "disconnect" a particular session or connection

To enable the master to close a session requires only
the single session's unique id into the agentxSessionTable
(with its agentxConnIndex given there); hence, the multiple
indices on that table provide no gain here.

To enable the master to close all sessions over a given
connection would require a scan of the agentxSessionTable
in the single index scheme to identify all those over the
single connection...however, again, I would judge this to
be non-onerous because (1) the table will be small and
(2) the frequency of the operation will be seldom.

> 3) "delete" (render ineffective) a specific registration

To enable the master to "delete" a specific registration
would require only the single unique agentxRegIndex value;
hence, the multiple indices on that table provide no gain
here.

> out what subagent has claimed responsibility for a particular

This would require a scan of the agentxRegistrationTable
in the single index scheme.  While this table may be a bit
larger on average than the agentxSessionTable, I do not
envision it hitting any formidable size in the real world
and, again, I see the frequency of this (and all other!)
operations against the AgentX MIB to be minimal.

For those kinds of reasons, I think extreme simplicity
of design is all that is called for here...we're not
really facing any serious performance or size constraints.

OTOH, I don't want to push my point too hard...I guess it's
safe to say the issue is still open...let's see if any other
opinions pop up over the next few days.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------