ietf
[Top] [All Lists]

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

2008-10-23 12:42:49
Hi -

From: "David W. Hankins" <David_Hankins(_at_)isc(_dot_)org>
To: <ietf(_at_)ietf(_dot_)org>
Sent: Thursday, October 23, 2008 8:47 AM
Subject: Re: [dhcwg] Last Call:draft-ietf-dhc-dhcpv6-bulk-leasequery(DHCPv6 
Bulk Leasequery) toProposed Standard
...
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.

An application that relies on "walking" a MIB to retrieve information
in this way is *seriously* broken, IMO.  The whole point of the way
INDEXes work in SNMP (and the reason the variable binding list
can hold multiple variable bindings) is so that one can access
a bunch of variables (with same or different index values, from
the same or from different MIB modules) in a single request.
SNMP has its limitations, but "spatial locality" is a non-issue here -
an application design that requests information it doesn't need in
an order which is not useful is the fault of the application designer,
not the protocol.

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

Spectacularly bad design.  It would make much more sense to only
ask for the interfaces of interest (if known) in the first place, and in
any case, asking for the individual variable bindings one at a time
is just silly, if you'll pardon the harsh language.

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

Hardly recommended, particularly since there are some boxes
which do not respond correctly to GetNext, resulting in a situation
where a naive GetNext walk won't terminate.  (Also, some
implementations which followed the letter of the early RMON specs
would result in the same behaviour.)

or are you
optimizing for the lowest latency to complete configurations?

Using multiple variable bindings does more that reduce
latency due to the number of round trips.  It also significantly
reduces the per-variable processing cost at both ends (encryption,
authentication, for example) subagent/master agent interaction
(AgentX exchanges, for example) and, for correlated indexes,
may also result in managed device cache advantages.

 Are
you optimizing out variables you have no interest in (most MIBs are
half extra data you don't require)?

Yet another reason why doing blind MIB walks doesn't make much sense
for management applications.

 What kind of device are you querying?

Shouldn't matter, though in general the more management information
available in the device, the bigger the advantages to being smart
about what one asks for.

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.

This is a good example of why asking for one variable binding at a time
in a MIB walk is not a good idea, and why asking for multiple variables
with correlated indexes in a single SNMP PDU makes sense.

 The typical snmpwalk or even bulkwalk 
scenario means every interface is queried multiple times; once for
each table they appear in.

Which is why I claim that applications that indulge in such silly behaviour
should not be encouraged.

 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.

All very good reasons why doing blind, single-variable MIB walks
makes no sense.   Are there any commercial products that
do this routinely?  I'm not aware of any.

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.

This is normal practice - get all the information in one or two requests.

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.

No.  More normal behaviour is to put multiple variable bindings into
a single Get request.  It's perfectly reasonable to request data from
multiple tables in a single Get request, or to walk multiple tables
concurrently using GetNext or GetBulk.

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.

It sounds like you're assuming a strawman implementation strategy
that one might find in "toy" scripts, rather than an industrial strength
product.  Despite its warts, it's unfair to dismiss SNMP just because
it's possible to use it in spectacularly inefficient ways.  It'd be like
dissing HTTP because it can carry web pages that have no
useful content.

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.

You're attacking a strawman.  Any sane implementation would request
all the interesting "interface 5" variables in a single PDU.

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

You're atacking a strawman.  Blind MIB walks are not "management".
A sane implementation limits itself to asking for the information
it needs.

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.

Variable bindings are contained inside the variable binding list, which is
contained inside and SNMP PDU, which is contained inside an SNMP
Message, which is transported using UDP or whatever.  If you're worried
about cache locality, RTT, or amortization of security costs, it makes
a huge difference.

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

The requirement for ordering is inherent in the protocol, and I agree
it makes interfacing with, e.g., an underlying SQL infrastructure (for
which "ordering" entails extra processing) a pain.  But the point is
that deciding which indexes to use needs to be driven by management
use cases, in order to minimize the situations in which one would need
to walk through an entire table to find the useful bits.

But for the most part you seem to be attacking a strawman - an
implementation strategy contrary to long-understood practice
in building SNMP-based management applications.

Randy

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

<Prev in Thread] Current Thread [Next in Thread>