Hi - > From: "David W. Hankins" <David_Hankins@xxxxxxx> > To: <ietf@xxxxxxxx> > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf