[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Thoughts on the various EOS proposals
At the EOS working group yesterday, a plea was made for more active
discussion on the list of the various proposals under consideration.
I made a somewhat cryptic comment about "where do I start?", so
perhaps it might be useful if I expanded on that a bit.
In preparing for the IETF meeting, I spent a couple of days reading
through the various drafts, and the full archives of the mailing list.
It struck me that a number of the proposals seemed to be covering
similar ground, but that very little attempt had been made to try and
draw together the various alternatives for any particular requirement.
I would suggest that it is probably useful to try and decouple the
requirements as much as possible. Obviously, there is a certain
amount of interdependence - particularly to gain the full benefit of
these changes. But the various requirements are a lot easier to
understand if they can be considered independently. For example,
the GetCols proposal contains both a new protocol operation, and a
means of OID compression. It would actually be quite possible to
implement just the GetCols protocol behaviour, without using any OID
compression at all - less efficient, obviously - but they are logically
Particularly with the RowOps document, what came over was very much
a tightly-linked, all-or-nothing offering - which felt contrary to
the aims and structure of the working group charter and requirements.
I'd like to consider some of these specific aims individually.
There have been five proposals for OID compression - OID prefix
compression, OID delta compression, the table-based compression from
the GetCols draft, and two forms of compression (or "inheritance")
in the RowOps draft.
The first two are fundamentally similar - OPC is conceptually
simpler, while ODC handles single-row OIDs more efficiently.
The GetCols compression is specific to this particular operation,
and can't be used as a general-purpose OID compression mechanism.
It also _requires_ the manager to save state - the compression is
not self contained within the PDU.
The RowOps name-level inheritance is similarly restricted to a
subset of PDUs (the new operations defined in that document), and
only handles exact matches. I believe that either of the first two
OID compression techniques could handle this equally efficiently,
with the added flexibility of covering other situations as well.
The RowOps prefix-level inheritance is a very specific form of
compression, which could potentially be useful in a wider context.
But again, the dedicated OID compression approaches can probably
handle this more powerfully, without being restricted to these
particular PDU operations.
Turning to the general idea of row operations - I actually see
this as two distinct sub-problems:
- how to specify a row aggregation
(which table, index and subset of columns), and
- what operations are supported on such an aggregation.
I'd suggest that these be considered separately.
There have been two forms of row aggregation proposed - the RowOps
RowIdentifier mechanism, and the Appendix of the OPC document.
The RowIdentifier uses a sequence of existing varbinds to encode the
row aggregation information - the first holding the table and instance
information, followed by the individual columns (one per varbind).
The OPC Appendix proposal uses a single varbind, with a new value
structure to hold this list of columns. Coming in to this topic cold,
this second approach seemed much simpler to understand, being a
logical extension to the current, familiar mechanisms. By comparison
the RowIdentifier mechanism felt much more convoluted and hard to follow.
Yet I don't recall seeing any discussion of the OPC aggregation
syntax on the list. Is there a fundamental problem with extending the
definition of a VarBind in the way proposed?
Of the six new PDU operations proposed in the RowOps document,
three (EditRow, GetRow, and GetNextRow) appear to be exact analogies
of existing requests, one (GetBulkRow) is more-or-less a version of
the GetCols suggestion, and two (CreateRow, and DeleteRow) are new.
The RowOps document explicitly states that row aggregation can
only be used with the new operations. It seems to me that if the row
aggregation mechanism was designed such that it could be clearly
distinguished from traditional 'singleton' VarBinds, then perhaps
this restriction could be lifted. Having two PDUs (e.g. GET and
GetRow) with similar behaviour, but operating on different types
of data, seems unnecessarily complex.
The two Bulk data proposals appear to be addressing very different
aims. I believe the out-of-band approach is intended for use in
high- to very-high volume scenarios, where pure-SNMP may simply not
The GetCols proposal (with or without compression) feels a much
more general-purpose approach. As such, they are not mutually
incompatible, and it almost feels inappropriate to compare them
directly. Perhaps more useful would be to compare the functional
behaviour of GetCols and GetBulkRow, to see if there are features
of one that could be usefully included in the other.
OK - I've probably trodden on a number of toes by now. Now it's
time to tell me why I'm talking nonsense.