Subject: Re: Table Indices in AgentX MIB

From: "Smitha Gudur" <[email-masked]>
Date: Mon, 03 Aug 1998 13:41:53 PDT

Hi, Bob,

>From [email-masked] Mon Aug  3 11:17:55 1998
>Received: from [192.152.208.5] (helo=acecomm.com)
>	by relay1.smtp.psi.net with smtp (Exim 1.90 #1)
>	id 0z3PB4-0005Mf-00; Mon, 3 Aug 1998 14:17:47 -0400
>Received: from bnatale by acecomm.com (5.65/3.2.083191-ACE*COMM)
>	id AA10947; Mon, 3 Aug 1998 14:20:02 -0400
>Message-Id: <[email-masked]>
>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.1
>Date: Mon, 03 Aug 1998 14:20:14 -0400
>To: "Smitha Gudur" <[email-masked]>
>From: Bob Natale <[email-masked]>
>Subject: Table Indices in AgentX MIB
>Cc: [email-masked]
>In-Reply-To: <[email-masked]>
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>
>>At 8/3/98 09:58 AM, Smitha Gudur wrote:
>>Subject was: Re: open issues in agentX MIB
>
>Hi Smitha,
>
><...>
>>>	agentxConnectionTable
>>>	agentxSessionTable
>>>	agentxRegistrationTable
>>>
>>>In thinking through the relationships, it seems that we
>>>need to add agentxConnIndex to the AgentxSessionEntry and 
>>>agentxSessionIndex to the AgentxRegistrationEntry.  In this
>>>way, each registration entry can point to the session in
>>>which it lives and each session can point to the connection
>>>in which it lives.
><...>
>>Currently, the agentxConnIndex is one of the indices for 
>>agentxSessionEntry, and agentxSessionIndex is also one of
>>the indices for agentxRegistrationEntry.
>
>Implicit in my comments was the notion that each of the
>three tables needs only a single simple index, respectively:
>
>   agentxConnectionTable     agentxConnIndex
>   agentxSessionTable        agentxSessionIndex
>   agentxRegistrationTable   agentxRegIndex
>
>I can see no need for the multiple indices on agentxSessionTable

The reason for adding multiple indices goes back to Jurgen posting
as on Tue, March 17 1998 and the follow up discussion.

Jurgen's posting:

>The AgentX MIB <draft-ietf-agentx-mib-01.txt> has three tables:

>1) agentxConnectionTable
>2) agentxSessionTable
>3) agentxRegistrationTable

>There is a 1:n relationship between 1) and 2) and another 1:n
>relationship between 2) and 3). Further, every session is bound to a
>single connection and every registration is bound to a single
>session. This means that the relationships between the tables can be
>modeled by the indexing structure (a):

> agentxConnectionTable
>        INDEX { agentxConnIndex }

> agentxSessionTable
>        INDEX { agentxConnIndex, agentxSessionIndex }

> agentxRegistrationTable
>        INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex }
       
>The draft of the AgentX MIB <draft-ietf-agentx-mib-01.txt> uses a
>different approach (b). Every table has a single index and there is a
>to the agentxConnectionTable. There is also a column 
>agentxRegSessionIndex in the agentxRegistrationTable which points
>back to the agentxSessionTable.

>I think approach (a) has nice properties: First, you can use the
>natural order to easily get all registrations for a given session or
>all sessions on a given connection. Second, you don't need to make
>additional lookups if you want to know the connection associated with
>a given registration. Third, you save two columns. Finally, it
>simplifies the description of some object types (e.g. agentxRegStart
>and agentxRegEnd) because the subagent is implicitely identified by
>the instance identifier.  Of course, the cost of approach (a) is that
>each instance identifier gets two more components, which means at
>least 2 additional bytes per instance identifier. 

And it was agreed at that time that approach (a) is a beter way
to implement this. 

regards 
smitha

>(agentxConnIndex, agentxSessionIndex) or agentxRegistrationTable
>(agentxConnIndex, agentxSessionIndex, agentxRegIndex).
>
>It would lead to unnecessary ambiguity about the semantics
>of some of the protocol elements (SessionID, in particular);
>it would preclude certain useful queries (due to the
>not-accessible max access clauses of the index elements);
>and it just violates Occam's razor--using an (effectively)
>unique integer valued primary index for each table solves
>the problem w/o further adornment.
>
>The key relationship is on the agentxSessionIndex (SessionID).
>The registration info clearly depends on it and *if* we add
>the traffic/error info via the proposed agentxResponsesTable
>that would also tie to the agentxSessionIndex (indeed, it
>could be added directly to the agentxSessionTable as is...
>we would keep it separate only if we want to allow it to
>be a MODULE-COMPLIANCE option).
>
>>Do we still need each of these object-type for the
>>respective entries?
>
>Yes, but not as an "in addition to" (obviously) but
>(IMHO) rather "in lieu" of the multiple indexing.
>
>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 -------------
>
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

---

From: Bob Natale <[email-masked]>
Date: Mon, 03 Aug 1998 17:06:09 -0400

>At 8/3/98 01:41 PM, Smitha Gudur wrote:

Hi Smitha,

<...much of helpful summary deleted...>
>>This means that the relationships between the tables can be

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.

Perhaps we were not considering the uniqueness requirement
or implications at the time Juergen made his suggestion (a)...?

>>The draft of the AgentX MIB <draft-ietf-agentx-mib-01.txt>
>>uses a different approach (b). Every table has a single index
>>and there is a to the agentxConnectionTable.
  ???????????????????????????????????????????
>>There is also a column agentxRegSessionIndex in the
>>agentxRegistrationTable which points back to the
>>agentxSessionTable.

Even though I might be missing something important that I
cannot understand in the ?-lined phrase, I think we were on
the right (or at least a preferable) track with this
approach (b).

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 Aug 1998 10:08:12 +0200

>>>>> Bob Natale writes:

Bob> Where each table has a simple *unique* natural index, there is
Bob> (IMHO) only cost incurred (and no value derived) from requiring
Bob> other index elements to access a row.

I am quoting the complete email send on Tue, 17 Mar 1998 18:27:05
+0100 on this subject in order to make it clear what the trade-offs
are:

: The AgentX MIB <draft-ietf-agentx-mib-01.txt> has three tables:
: 
: 1) agentxConnectionTable
: 2) agentxSessionTable
: 3) agentxRegistrationTable
: 
: There is a 1:n relationship between 1) and 2) and another 1:n
: relationship between 2) and 3). Further, every session is bound to a
: single connection and every registration is bound to a single
: session. This means that the relationships between the tables can be
: modeled by the indexing structure (a):
: 
:  agentxConnectionTable	
: 	INDEX { agentxConnIndex }
: 
:  agentxSessionTable
:  	INDEX { agentxConnIndex, agentxSessionIndex }
: 
:  agentxRegistrationTable 
: 	INDEX { agentxConnIndex, agentxSessionIndex, agentxRegIndex }
: 
: The draft of the AgentX MIB <draft-ietf-agentx-mib-01.txt> uses a
: different approach (b). Every table has a single index and there is a
: column agentxSessionConnIndex in the agentxSessionTable which points 
: to the agentxConnectionTable. There is also a column
: agentxRegSessionIndex in the agentxRegistrationTable which points 
: back to the agentxSessionTable.
: 
: I think approach (a) has nice properties: First, you can use the
: natural order to easily get all registrations for a given session or
: all sessions on a given connection. Second, you don't need to make
: additional lookups if you want to know the connection associated with
: a given registration. Third, you save two columns. Finally, it
: simplifies the description of some object types (e.g. agentxRegStart
: and agentxRegEnd) because the subagent is implicitely identified by
: the instance identifier.  Of course, the cost of approach (a) is that
: each instance identifier gets two more components, which means at
: least 2 additional bytes per instance identifier.
: 
: Approach (b) does not lead to a natural sorting order, which means
: that in most cases the complete tables have to be read in order to get
: e.g. all registrations for a given session. Are there any reasons for
: choosing approach (b)?

There are additional benefits of using the indexing structure I
proposed in March. For example, you can use VACM efficiently to define
access control rules for particular connections or sessions over a
particular connection.

Anyway, you claim that the indexing approach b) is simpler. Please
explain where you see the benefits. I argue that option b)

- needs more objects (to establish the relationships);
- makes manager interactions more expensive in some situations;
- makes VACM configuration harder.

So, where are the benefits of b)? Is it that your getnext function is
slightly more complex? This really depends on the data structures you
use. In some cases, option a) might even be simpler to implement. Is
there something else which makes option b) more expensive than option
a). Given the advantages cited above, do you think the trade-off
justifies to use b)?

I still believe that the hidden costs of choosing b) can in the long
term cause us serious problems (and therefore costs) and we should be
very carefull to not make the wrong decision here.

							Juergen

Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: Mike Daniele <[email-masked]>
Date: Wed, 05 Aug 98 10:48:21 -0400

>: modeled by the indexing structure (a):

I agree.  It seems to me where there is such a natural containment
hierarchy, the MIB's indexing should reflect it.  It seems like
better design to me.

>use. In some cases, option a) might even be simpler to implement.

Agreed.

>very carefull to not make the wrong decision here.

We don't know what configurations will happen in the future.
So it seems to me that if we can provide the ability to directly
lookup all As in B, or all Bs in C, at virtually no cost to
agent implementors, we should do so.

Mike

---

From: Bob Natale <[email-masked]>
Date: Wed, 05 Aug 1998 12:55:24 -0400

>At 8/5/98 10:48 AM, Mike Daniele wrote:

Hi Mike,

I will use your posting to try to present my thinking on this
and, thereby, also answer the comments from Juergen and Martin.
This gets a bit "didactic" in spots...forgive me...it's not
a deliberate effort to be pompous or anything...just trying
to explain some thinking.  It's intended as much as a learning
experience for me as anything else.  If the exposition proves
either fatally flawed or unpersuasive, I'll drop my pitch on
the indexing of tables in the AgentX MIB.  (As always, I use
an awful lot of words to say what others could express in
many fewer...I am sorry for that.)

>>relationship between 2) and 3). Further, every session is bound
>>to a single connection and every registration is bound to a
>>single session. This means that the relationships between the
>>tables can be modeled by the indexing structure (a):

"Can be" and "should be" are two different things.  As engineers,
we often gravitate toward the "can be" irrespective of the "should
be?" considerations.

>hierarchy, the MIB's indexing should reflect it.  It seems like

I do not agree with that conclusion.  Such a "natural containment
hierarchy" may be taken as one data point in such a design
decision, but it alone is not sufficient to make such a decision.
What constitutes a "better design" for a MIB is whatever serves
to maximize the result of some complex value function dealing
with the full range of operations that will be useful to existing,
conceived, or even as yet unimagined, management applications
while at the same time keeping the corresponding impact on the
managed element as minimal as possible.  No one is saying that
one can usually/often/(maybe even)ever know that one has come
up with the absolute best result ahead of time.

>>So, where are the benefits of b)? Is it that your getnext
>>function is slightly more complex?

It would be slightly less complex...but, no, that is not
the main benefit...the main benefit would come from not
imposing a pre-defined set of constraints on all management
applications.

>>This really depends on the data structures you use.

True in either case.

>In some cases, option a) might even be simpler to implement.

True (without signifying anything, one way or the other).

>Agreed.

Not much was said there to agree with (not a cut, Juergen)...
we all know that a good implementation might be able to turn
a bad design into a workable solution and a bad implementation
might be able to muck up a good design.  That will always be
true (I fear), no matter what design decisions are made.

What we (as a community) need is more specific guidance on
MIB design decisions.  Given the amount of time that we (the
SNMP community) have been doing MIBs, we ought to be close to
the level of demonstrated wisdom of, say, normalization rules
for relational databases.  I have looked at some of the
latest sources available that might offer such guidance...
I have found some, but it seems to be widely scattered and
not totally consistent.

>>I still believe that the hidden costs of choosing b) can in
>>the long term cause us serious problems (and therefore costs)
>>and we should be very carefull to not make the wrong decision
>>here.

Again, the exact same statement could be made if "b)" were
replaced with "a)" and it would be exactly as true (or false).
There is no basis for decision there.  In general, however,
it can be assured--given our stated objectives for this MIB
from the beginning--that even the worst design decision we
could possibly make would not lead to truly "serious problems".
I am not arguing for consciously making the wrong decisions,
obviously...just recalling that the purpose and scope of this
MIB are intentionally quite limited.  That fact plays a role
in my rationale (below).

>We don't know what configurations will happen in the future.

*That*, Mike, is a *key* design guideline in this case, IMO.

>agent implementors, we should do so.

That seems like an incongruous deduction from your previous
statement to me, Mike.  If one does not know what configurations
might make sense in the future, one perhaps should *avoid*
leveraging the "natural containment hierarchy" of the moment.

Such "leveraging" serves the needs of only a small number
of obvious queries--esp., what sessions belong to this
connection; what registrations belong to this session;
and what registrations belong to this connection.  Other
potential queries on the session and registration tables
may be constrained by need for multiple index values
when a single (unique) row identifier exists and/or by
the NOT-ACCESSIBLE MAX-ACCESS nature of these indices.

Anyway, here's how I break out the general case:

1.  If a table has a unique-valued columnar object
    suitable for use as an index, using other/additional
    objects as indices into this table requires special
    justification.

2.  A justification based on "natural containment
    hierarchy" is not prima facie sufficient, unless
    it can be shown that:

	a.  Queries which depend on such "containment"
	    will dominate management operations; and/or

	b.  the cost of not having such "containment"
	    when performing the queries in 2a would have
	    a significantly negative impact on the
	    managed element.

Applied specifically to AgentX, 2a is not known to apply
and 2b is known not to apply (since all tables will be
"small" in any reasonable meaning of that vague term).

3.  The original SNMP philosophy of not encasing "meta-"
    and "pseudo-" data within an agent is still valid
    as a starting point in MIB design...the identified
    "containment hierarchy" is an example of such meta
    or pseudo data...(I agree that today there are a
    growing number of manageable elements that can support
    agents that go beyond the original SNMP agent role
    philosophy...there is no need for the AgentX MIB to
    do so, however).

>From that, I draw the conclusion that the indexing design
in the original version of the MIB (single, unique index
per table) is preferable to that in the current version
("grouping" indexes added to the single unique index in
the session and registration tables...and presumably to
any other similar tables we might want to include future
revs of the MIB).

Leveraging the "natural containment hierarchy" as represented
via the multi-indexing in the current version, IMVHO, adds
some complexity and overhead to (virtually) all potential
management operations against this MIB (including the many
that might not care about the "containment hierarchy" but
benefits only a small number of known queries that will not
be made all that frequently and would not incur exorbitant
costs to satisfy in the absence of the multiple indexes.

Well, is anyone persuaded? :-)

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------