[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Draft EOS minutes
on the following....
At 05:38 PM 8/14/2002 +0200, Marek Malowidzki wrote:
>> 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?).
You really are missing the major issue. Post processing a response
to "compress OIDs" or fill holes is a double loss.
>> 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
>> 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.
The gain is much more than "convenience".
>> 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).
Note that "compressing of OIDs" is not a big win. It may actually be
a double loss. And optimizing SETs, who cares?
>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
>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:
> 1, -- non-repeaters
> 100, -- max-repetitions
> aTrickyColumnarObject.1:NULL, -- a non-repeater: require compression
> ifType:NULL, -- repetitors
>.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.
Trying to come up with a backwards compatible approach is always
difficult. But, I'm not sure that the above solves a problem
without creating a lot more new problems.
If you are anyone else would like to work on a solution, I suggest
that you grab the NET-SNMP source code (or other SNMP agent
source code, but open source would be better) and work out the
impact any change would be on the agent. Yes, first the agent.
Then the number of messages sent over the network. And finally
the impact on the manager app.
PS Marek, please do not be discouraged by my comments. There has already
been much work in this area. There have been several proposals that
are optimizing the inappropriate parts. Repeat over and over
again. Reduce CPU and memory utilization in the managed system,
followed by network traffic. If you do so, then you will have
a winning solution. Optimize for well designed management apps.
/david t. perkins