[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft EOS minutes



HI,

On the holes issue....

The elimination of holes is for the following reasons:
1) it allows a much for efficient agent implementation.
   why? because holes cause a break down in caching
   by an agent, resulting in potentially multiple 
   resource manager calls to retrieve the same data.
   The multiple calls and the supporting skewed rows
   will consume much more CPU resources of the system.
2) it allows new operations to be created where the
   duplication of the index portion and the OIDs identifying
   the columns can eliminated, resulting in a much greater
   number of rows to be packed in each response. This
   results in a much smaller number of network operations,
   which means that retrieving the selected columnar values
   for all rows is significantly faster.
3) it simplifies processing of the returned values by manager
   applications
4) it improves consistency of data (as you specified below)
   
Note that the virtual table approach as specified below doesn't
seem to provide any benefits. A fuller description and examples
would be helpful.

At 11:13 AM 8/14/2002 +0200, Marek Malowidzki wrote:
>RE: Draft EOS minutesI am a new subscriber of this list so I would like to greet
>everybody.
>
>>   b)  Filling holes in tables
>>       using either 'noSuchInstance' or a new Exception value
>>
>>   This has been suggested in a number of the current proposals
>>   (GetCols, Row Aggregation, OOPS), and would potentially be
>>   useful with the existing GetNext/GetBulk operators as well.
>>     I'm currently discussing adopting an adaptation of this
>>   for the net-snmp agent anyway - just to simplify the normal
>>   GetNext/Bulk operation.
>
>Could anyone explain to me why filling the holes is so useful? In a few
>documents I have read it was stated that "manager applications have problems
>with putting data in the right order". I personally do not think there is such a
>problem at all. Perhaps a more serious thing is that row data may come from
>different "time instants", so a row may be unsynchronized. Moreover, a row that
>existed during the first get-type operation, which returned a part of its data,
>might disappear later, so it may provide partial obsolete data. On the other
>hand, are SNMP agents required to treat a single get/get-bulk etc. operation as
>atomic?
>
>Leaving holes as they are allows to limit the amount of data that need to be
>sent. I am not any strong supporter of the holes, but it seems that there is a
>general agreement about that they should be fixed. The original explanation
>(problems with putting data in the right order) is a bit funny - can't
>programmers do that? Implementation of a procedure for table retrieval using
>GetNext/GetBulk with correct holes (and endOfMibView errors) handling is
>relatively easy. If this is the main reason, perhaps it is not worth doing. If
>there are other reasons (e.g. to minimize the "unsynchronized data" effects),
>perhaps the statements in the drafts should be made clearer?
>
>>   The other thing that would be necessary is some sort of mechanism
>> for negotiating the use of such enhancements.  Reporting which
>> enhancements are available could be handled via a suitable MIB, but
>> requesting the use of an individual facility is a harder problem.
>>   Ideally, we should develop a flexible mechanism that could also
>> accomodate subsequent enhancements.  That might indicate something
>> based on tag types and/or "control" varbinds, rather than distinct
>> PDU types (which wouldn't really scale very well).  I've got some
>> ideas about various possibilities, and will try to put together a
>> fuller proposal, if there's any interest in this sort of approach.
>
>A possibility to provide options for a single get-type operation is to use a
>virtual table for this purpose and treat the index part of a table variable OID
>as the data used to specify how this request should be handled (a fake get
>operation on a table, used for providing an index with operation-related data).
>For example, this could be used to negotiate OID compression and/or the places
>in a MIB where get-bulk should stop - this would allow to get rid of the
>"overshoot" problem. Quite tricky, but feasible.
>
>Marek
Regards,
/david t. perkins