Subject: [IETFMIBS] Data caching with SNMPv3

From: Hamid Mukhtar <[email-masked]>
Date: Wed, 22 Jul 2009 21:30:11 +0900

Dear all,

Does SNMPv3 specify any way of maintaining a temporary state (a cache) for a
frequently queried object(s) at the agent side to reduce the management
traffic.
There are some implementations which support object caching, however, I am
not sure if that is specified in the current SNMPv3 or the sub-agent
protocols.

Kindly help me in this regard.

Thanks,
Hamid

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 22 Jul 2009 15:01:04 +0200

On Wed, Jul 22, 2009 at 02:30:11PM +0200, Hamid Mukhtar wrote:
 
> Does SNMPv3 specify any way of maintaining a temporary state (a
> cache) for a frequently queried object(s) at the agent side to
> reduce the management traffic.

> There are some implementations which support object caching,
> however, I am not sure if that is specified in the current SNMPv3 or
> the sub-agent protocols.

>From the protocol perspective, the originating data source is the
instrumentation of the agent (or a sub-agent). Implementations often
to cache information in the instrumentation in order to reduce
overhead but that is clearly an implementation decision - nothing the
protocol cares about.

A feature that does exist and may or may not be relevant is the notion
of time filtered tables that allow to retrieve only those data objects
that changes since the last poll. But this is at the end a matter of
MIB design - not the protocol itself.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Steve Moulton <[email-masked]>
Date: Wed, 22 Jul 2009 10:53:49 -0400

> MIB design - not the protocol itself.

Expanding on Juergen's excellent response ...

Management applications can also have implementation tweaks to 
take advantage of what caching comes naturally to agents.  In many
cases, a single row of data for a particular table may be cached
in the agent (though not so often for multiple rows, as the magnitude
of the cache coherency problem increases dramatically here).    
For tables with many rows (I'm thinking about 
route or arp tables in a router) significant performance improvements
can be attained by retrieving entire rows at a time, rather than
following the lexicographical ordering (which follows "columns"
in tables, rather than "rows").

This kind of caching is by no means an implementation universal, nor 
is it enshrined in any standard document (of which I am aware).  
The point is that agent cache implementation patterns often follow the pattern 
of the data that is being instrumented.

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
moulton at snmp.com  Knoxville, TN 37920-9716 USA  http://www.snmp.com