Re: [dhcwg] Last Call: draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 Bulk

On Wed, Oct 22, 2008 at 09:15:01PM -0700, Randy Presuhn wrote:
> Uh...  One of the useful features of tables is to organize related information
> into conceptual rows with common INDEX values.  I'm not sure where
> "a single table of a single variable at a time" comes from - GetBulk
> certainly has no such limitation.
I don't remember referring to GetBulk, and I don't understand why I
would have.

If you don't know where "a single table of a single variable at time"
comes from, then walk the 'interfaces' mib on any system at your
convenience.  Note how 'ifDescr', 'ifInOctets', and etc are all
organized with spatial locality, but the data for "interface 5" is
not.  This spatial locality does not track with common application
temporal locality requirements, which wants all the details for one
conceptual object at once so that it may continue with processing it,
rather than waiting.

> > For example, you start by walking a table of "index" advertisements,
> > where you receive an 'index number' that can be used into other MIBs
> > to find variables associated with that database entry.
> >
> > For each of these indexes you discover, you could then queue single
> > GET PDU's for each separate variable you were interested in (lease
> > state, lease expiration time, ...).
> That would be a spectacularly inefficient implementation strategy.
> I should hope there's nothing in the SNMP RFCs that would be
> read as encouraging such wasteful behaviour.
Efficiency is often subjective.  Are you optimizing for simplicity
of design (using one walk to traverse an entire mib), or are you
optimizing for the lowest latency to complete configurations?  Are
you optimizing out variables you have no interest in (most MIBs are
half extra data you don't require)?  What kind of device are you
querying?

On some models of router, for example, a SNMP query causes a message
to be sent over their own 'control bus' to fetch all statistics for
a single interface.  The most recent control command is cached,
because it was designed to be used for a CLI command to display a
single interface's data.  The typical snmpwalk or even bulkwalk
scenario means every interface is queried multiple times; once for
each table they appear in.  This kills the cached object, by using
none of its locality, and overworks the command bus.  Even if the
router's cache were larger, it would have to be equal in size to the
number of (physical and virtual) interfaces in order to have even one
hit.

An application trying not to live in 1985 might find itself doing,
as I describe, a kind of dance to get out of SNMP's spatial locality
mindset.  In this case, you would query all the data you required
pertaining to one interface at a time, before moving on to the next
interface.

An application requiring not to live in 1985 definitely will find
itself queuing more than one packet to a single SNMP server at a
time.  In this case, walking some number of tables in one session,
while queuing query packets filled to the brim with GET's for all
specific relevant data for each interface in series.

Unless you're querying a Cisco Catalyst, in which case queuing more
than one packet at a time is foolish; the Cat will drop the second
packet if it is busy with a request already, and you'll have to sit
in retransmission hell.  But I'm getting sidetracked.


The advantages here I am describing are twofold;

1) The object for "interface 5" is read in the least time possible,
  even though the time to read the entire dataset remains constant
  (due more to RTT than to bandwidth).  "interface 5" can move on to
  the next stage in processing while SNMP data continues to flow,
  rather than waiting for the walk to finally reach the last table of
  variables.

2) The router is not flagellated needlessly, resulting in a lower
  time to complete the operation overall.

> I'm not sure what you're trying to say here.  An SNMP message (which
> would normally be carried in a single UDP datagram) by definition
> contains exactly one SNMP PDU.
Possibly this is a kind of brain damage that arises from the SNMP
library I once used, which describes multiple query commands in one
packet as PDU's, even if they are labeled internally to SNMP as being
'variable bindings' attached to the end of the PDU.  I wind up using
the terms interchangeably as a result.

> This depends on the design of the MIB module in general, and the
> selection of the INDEX elements in particular.
I don't see how any SNMP MIB design cleverness can get around "the
SNMP way" of requiring strictly ordered datasets for GETNEXT support.

But good luck with that, and I look forward to reading your DHCP MIB's
draft.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?  https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins        "If you don't do it right the first time,
Software Engineer                    you'll just have to do it again."
Internet Systems Consortium, Inc.               -- Jack T. Hankins

pgpS8_aj0h605.pgp
Description: PGP signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf