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
Attachment:
pgpPXFka7gz6w.pgp
Description: PGP signature
_______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf