Harry,
Thanks for your analysis. We've looked at the problem too and
think that splitting does have a few advanatages, but maybe not so
overwhelming. See what you think. If there is not substantive agreement
to split the table, then lets leave it the way it is. We'll need to
put forth our arguments to David and see whether he thinks our
arguments have merit or not.
If we don't split now, there is some risk that the IESG/Area Directors
might split the table for us.
The bottom line is that for SNMPv1 splitting the table has no real
advantages for simplifying the management applicationm, simplifying
the agent, or reducing network traffic.
However, for SNMPv2 where GetBulk can be used, the network traffic
is cut by 1/3 to 1/2 when the table is split vs. combined for applications
that want to get all the attributes (such as an accounting application).
This is because the management app can get as many attributes as can fit into
one PDU. Even with a limit like 540 bytes in a PDU, this means that
a single PDU can return 20-30 integers in one PDU.
Also a monitoring application is mostly interested in the integer values
that get updated during the job's life cycle. Strings are mostly
static, so even an application that was monitoring a single job,
could use GetBulk to get all the integer attributes in one or more
PDUs.
So even with SNMPv1 a monitoring application might want to use
Get Next to just walk the integer table and then look at one or
two strings explicitly that might change.
And a management application that is using Get Bulk is already storing
an entire table and then sorting through it. That is the cost to a
management application when using GetBulk.
See commments below.
Tom
At 18:20 07/09/97 PDT, Tom Hastings wrote:
>At 01:18 06/27/97 PDT, David T. Perkins wrote:
>>snip...
>>>There is one change that would affect any current implementations
>>that I strongly suggest that you do. Table jmAttributeTable has
>>three accessible columnar objects. The first tells you the "type"
>>(either integer, octet, or both) of the value of the attribute.
>>The second two columns are the attribute's value. I suggest that
>>instead of this single table, that you have two tables. Each table
>>would have a single accessible column. The first table would contain
>>integer valued attributes, and the second table would contain
>>octet string valued attributes.
>>[David did not mention that there is actually a fourth index which
>is an "instance" index for those attributes that can have more than
>one value per job. I'm not sure whether this fact changes the argument
>or not.]
>>snip...
>>We need to consider this suggestion and either accept it or justify
>why not. Lets get collected comments (such as Harry's below) and
>respond to David. David is a noted authority on SNMP, so accommodating
>his comments will help forward our document.
>>Xerox developers have several views and we are in the process of
>reaching a consensus (I'll send you results Thursday, 7/10).
>>Harry Lewis's developers have made a review and are not convinced that
>it is a good idea to split the table:
>>>Return-Path: <harryl at us.ibm.com>
>>From: Harry Lewis <harryl at us.ibm.com>
>>To: <hastings at cp10.es.xerox.com>
>>Cc: <jkm at underscore.com>, <rbergma at dpc.com>, <bpenteco at boi.hp.com>
>>Subject: Splitting the Attribute Table
>>Date: Wed, 9 Jul 1997 10:52:02 PDT
>>>Tom, we have conducted a review here, regarding your recommendation
>to split the attribute table into two tables - one for Integer values
>and one for Octets - and are of the opinion that the current attribute
>table is superior. Here is our summary.
>>1. First, we assume that attributes will have a null string for the
>valueAsOctet and -2 for valueAsInteger if appropriate.
Actually, its -1, not -2. -2 is for unknow, -1 for other.
(I'll clarify that in the document).
>>2. With GetNext, we do not believe network traffic is an issue because
>the "extra" null string or -2 will fit in the PUD packet.
Agree that when doing one or two GetNext in a single PDU it fits.
>>3. We believe, using get next, there are less calls required with the
>current scheme than would be needed if the table was split.
>>Example:
>> Integer Octet
> ------- -----
>> -2 X
> X Null
> X X
> X Null
> -2 X
>>>Consider the above excerpt. It will take 5 get next calls using the current
>method. But it would take 6 calls if the table were split (one for each X
>which represents a real value).
Actually, I would think that the application would two GetNext in each
PDU, one for the integer table and one for the string table (and then
have to merge the results, since the attributes that have both integer
and string value would not be together). So the number of calls would
be 3, in the example if we split, instead of 5. So spliting does
reduce the number of calls (at the expense of having to sort the results).
>>4. While, in most cases, the monitor will know whether or not the attribute
>is defined as Integer, Octet or Both... there are cases where it could
>be EITHER. With the current scheme, the monitor "finds out" what this
>particular device has instrumented in one get next (for each attribute).
>With split tables, you have to look in both tables to know (this may
>just be a restatement of (3) above).
Yes, more of a sorting is required. (Not unlike the sorting for
GetBulk in SNMPv2.
>>5. There is no storage savings in the agent if done properly, where the
>agent knows which syntax is being used.
We agree, that a good impelmentation doesn't cost any space with all the
not meangingful values (-2, 2, and zero-length string).
>>Tom, this is our summary. I think the ball is "in your court" to decide
>whether or not to open this problem to a wider audience, send us a
>DETAILED "rebuttal" or accept our findings.
Lets see what others think, especially the application writers, since
whether to split or not seems to affect them the most.
Our implementations use Get Bulk when SNMPv2 is being used and don't
when it is SNMPV1. How about others?
>>>Harry Lewis - IBM Printing Systems
>