Last change to split the attribute table into a table of just integers
and a separate table of just OCTET STRINGs, as suggested by David
Perkins:
>>>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.
If there is no support, especially from applications writers, by Tuesday
noon, 7/29, the I-D draft for Munich will NOT be split.
Tom
At 12:20 07/25/97 PDT, Harry Lewis wrote:
>Tom, my apologies for assuming Dave Perkins and Xerox were one in the same.
>I only recall seeing Dave's comments in a note originating from you where you
>had performed some editing ... leading to my incorrect assumption. If Dave's
>note made it directly to the PWG I must have missed it.
>>In any case, are we in agreement to leave the Attribute table as one unit, as
>originally designed?
>>Harry Lewis - IBM Printing Systems
Harry,
Did you show this reply to your original analysis to splitting the
attribute table to your developers. Did any of this change any of
their minds?
If not, lets keep the table together. Our implementors thought that
it helped applications some to split, in that the application could
walk either table or both together, application's choice. However,
our implementors didn't feel that we absolutely must split the tables.
Any other implemntors have opinions, especially application writers,
since there is no burden or advantage or disadvantage to the agent
with splitting or not splitting.
Tom
>Return-Path: <jmp-owner at pwg.org>
>X-Sender: hastings at zazen>Date: Fri, 11 Jul 1997 13:32:04 PDT
>To: jmp at pwg.org>From: Tom Hastings <hastings at cp10.es.xerox.com>
>Subject: Re: JMP> ISSUE: split jmAttributeTable or not
>Sender: jmp-owner at pwg.org>>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.
>>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,
instead of 10-15.
>>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
>>>>