Subject: RE: [Adslmib] Profile indexing

From: "Michael Sneed" <[email-masked]>
Date: Thu, 21 Nov 2002 11:02:05 -0500

Just to make sure my point was clear, I don't think the main issue is human 
readability.  The issue is having two independent ways to reference the same 
thing: one (an integer) by which the agent knows the profile, and one (a 
string) by which everyone else does. This is usually a bad thing.  And 
compensating for this is more of a burden than may be clear at first  blush.

The fact that there is an application which can translate does not help.

As for existing MIBs, most of the cases I am aware of are evolutionary, 
where the overloading of (non-standard) semantics onto an integer index in 
order to avoid the multiple-name problem was perceived later to be a 
problem.

Regards,

Mike

>From: "Umberto Bonollo" <[email-masked]>
>To: "'Bob Ray'" <[email-masked]>, "'Michael Sneed'" <[email-masked]>
>CC: <[email-masked]>
>Subject: RE: [Adslmib] Profile indexing
>Date: Thu, 21 Nov 2002 16:59:01 +1100
>
>We'd basically support Bob Ray's retention of the integer indexing.
>The average size of PDUs containing string VARBINDS in the index part is
>also quite
>messy and can exceed default packet sizes...
>
>On the human readable angle,
>there's usually a manager application interposed rather than
>an SNMP-Walker used by developers,
>and SNMP readability won't change much because this VDSL
>MIB aimed for readability [there's so many other cryptic ones :-) ].
>
>The pool of current prior-art MIBs is overwhelmingly
>weighted towards the integer indexing approach,
>correctly in our view.
>
>Umberto Bonollo
>NEC Australia ([email-masked])
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]On Behalf Of
>Bob Ray
>Sent: Thursday, 21 November 2002 6:11
>To: Michael Sneed
>Cc: [email-masked]
>Subject: RE: [Adslmib] Profile indexing
>
>
>
> >If there is not a something different about the VDSL MIB that requires
> >changing the indexing for profiles, I think it should remain consistent
>with
> >the other DSL MIBs.
>
>My opinion is that the indexing should remain as Unsigned32, and here is
>why.
>
>At issue is whether vdslLineConfProfileTable should be indexed by
>
>             vdslLineConfProfileIndex               Unsigned32
>
>or by
>
>             vdslLineConfProfileName                SnmpAdminString
>
>In either case, the index of the profile table is also used to index the
>remaining profile tables in the MIB:
>
>	vdslLineMCMConfProfileTable
>	vdslLineMCMConfProfileTxBandTable
>	vdslLineMCMConfProfileRxBandTable
>	vdslLineMCMConfProfileTxPSDTable
>	vdslLineMCMConfProfileMaxTxPSDTable
>	vdslLineMCMConfProfileMaxRxPSDTable
>	vdslLineSCMConfProfileTable
>	vdslLineSCMConfProfileTxBandTable
>
>Note that these eight tables are line code specific configuration profile
>tables.  The ADSL MIB did not have line code specific configuration 
>profiles
>(although the document alludes to some work in that direction by the DSL
>Forum).
>
>An agent may have many profiles.  Imagine a table of such profiles with
>a primary index of type Unsigned32.
>
>    index  name        x    y   z
>   +-----+------------+---+---+---+
>   |  1  | gold       | 1 | 2 | 3 |
>   +-----+------------+---+---+---+
>   |  2  | silver     | 1 | 1 | 3 |
>   +-----+------------+---+---+---+
>   |  3  | bronze     | 1 | 1 | 2 |
>   +-----+------------+---+---+---+
>
>As the name is required to be unique (a "candidate key"), the index is
>superfluous and the table can be simplified as follows:
>
>    name        x    y   z
>   +------------+---+---+---+
>   | gold       | 1 | 2 | 3 |
>   +------------+---+---+---+
>   | silver     | 1 | 1 | 3 |
>   +------------+---+---+---+
>   | bronze     | 1 | 1 | 2 |
>   +------------+---+---+---+
>
>This, I believe, is the crux of the argument to retrace the MIB back to
>using SnmpAdminString as the index of the profile table.
>
>However, there are several issues not addressed in the above example but
>brought immediately to the fore by the existance of the eight subordinate
>tables.  The first of these is profile storage.  With a string index
>(IMPLIED
>or otherwise), each profile entry in each subordinate table must have as
>an attribute of each row with each table the string index associated with
>the row.  For a large MCM band table collection (both tx and rx, psd tables
>included) for multiple profiles, this can be fairly large.  Imagine a
>collection of ten profiles for a MCM modem with 100 band entries per
>direction
>per profile.  Further, imagine a limit of 30 characters per profile name.
>A simple (perhaps tool generated) agent would store the profile name within
>each row.
>
>1) Do the math.
>
>Such an implementation might be quite acceptable for a PC-based proxy agent
>with dual Pentium Xeon processors and an Oracle database (forgive the name
>brands - there is no intention to identify any vendor whatsoever in the
>above).  However, a stand alone unit housing an 68HC12B32 controller and
>VDSL chipset would have a difficult time supporting even one such profile.
>
>Obviously, one could use a small look-up table to store the profile names
>within the agent: when a object identifier arrives, look up the profile
>name in the look-up table, retrieving an unsigned integer index to access
>some internal representation of the tables sans string index.
>
>But, a curiously cynical programmer might ask, "What have you 
>accomplished?"
>Isn't this going full circle?  Rather inefficiently at that.
>
>Examine the processing time required to determine which row in whatever
>number of tables one has (perhaps the above "efficient" implementation,
>perhaps a somewhat less "efficient" toolset generated implementation) a
>received object id is associated with.
>
>Imagine an agent receives an object with a string index.  To determine
>which row(s) the string is associated with, the agent must perform a
>string comparision with the entries in the table(s).  Imagine an adroit
>programmer implements this via a tree structure, arriving at a log(n)
>search for a given string.  Imagine, further, that the agent identifies
>the object as being in a given band table with 500 rows (5 profiles, 100
>entries per profile).  Nine string compares (log(500)) must be done to
>determine which row is associated with the object (assuming a simple agent
>with a simple implementation).  Compare this with a bounded integer lookup
>function.
>
>2) Compare and contrast these approaches in an agent which supports many
>such modems and profiles.  Consider two management stations simultaneously
>executing getnext walks against the agent.
>
>Yet another consideration should be bandwidth.  Imagine a get request of
>
>        1.3.6.1.4.1.4.1.1.someprofilestringname.1.1
>vs.
>        1.3.6.1.4.1.4.1.1.n.1.1
>
>[the actual numbers are typed at random by this ranting and arguably
>deranged author]
>
>3) Compare and contrast the impact of the two indexing schemes on
>network usage.  Consider again two management stations simultaneously
>executing getnext walks against the agent.
>
>For these reasons, I support retaining the indexing method of the
>current draft (Unsigned32 vs SnmpAdminString).  But, if you've read
>this far, you know that. :)
>
>Bob Ray
>
>
>_______________________________________________
>Adslmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/adslmib
>
>_______________________________________________
>Adslmib mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/adslmib

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

_______________________________________________
Adslmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/adslmib

---

From: "Bob Ray" <[email-masked]>
Date: Thu, 21 Nov 2002 10:26:24 -0600

>The fact that there is an application which can translate does not help.

I think computers are just wonderful things for translating numbers
to strings and back again.  I use them every day.

Why, just now, I used one of these wonderful inventions to tell me that
1.3.6.1.2.1.10.9999.1.1.6.1.9.1.1.1 meant vdslIntervalInits...

Bob Ray