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

Re: Draft EOS minutes



> 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.

Ok, but in this case the holes could be removed from a response before it is
sent (or am I missing anything?).

> 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)

Ok, so this should be the explanation. So, manager applications do not have
problems - simply this approach improves consistency of data and is convenient
for new operations.

> Note that the virtual table approach as specified below doesn't
> seem to provide any benefits. A fuller description and examples
> would be helpful.

[...]

From the earlier post:

>>   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.

I was thinking recently on some possible improvements for exisitng protocol
operations. Assume we want to provide additional options for an operation (e.g.
"compess OIDs" for a Set operation). If we have a set-type operation, there is
no problem - just define in a MIB a special-purpose variable with values
carrying options. Setting this option would enforce special treatment for this
(the current one) operation. In this case, an agent's response will contain
compressed OIDs.

However, for get-type operations things do not look so well. We can only read
objects, so how can we provide values? (Assume we do not consider new
operations, but extend existing ones.) Still, we can define a purely virtual
table in a MIB and provide some values using index in OID. For example, to ask
an agent to compress OIDs in a get-bulk response, one could use:

 GetBulk(<request-id>,
    1,                                                        -- non-repeaters
    100,                                                    -- max-repetitions
    aTrickyColumnarObject.1:NULL,       -- a non-repeater: require compression
    ifType:NULL,                                     -- repetitors
    ifInOctets:NULL,
    ifName:NULL)

.1 index means "compress OIDs" using method A, .2 means use method B for this
purpose - just to explain things, no reason to provide the possibility of such a
choice. This is a bit tricky, indeed, but may work. Note that if an agent
returns noSuchInstance for aTrickyColumnarObject, it indicates that the agent
does not support this mechanism and the manager should expect a plain response.

What is another possible usage of such a mechanism? For example, for handling
the holes in a way a manager would like or - and this was my original idea - for
curing GetBulk from the "overshoot" problem.

Regards,

Marek