Re: [IPFIX] timestamps, exporters, and other animals (fwd)

On Tue, Oct 11, 2011 at 11:54:19PM -0700, Josh Bailey wrote:
> 
> Hi Juergen;
> 
> I assert that polling the sysUpTime does not take care of the core
> problem, because you cannot know when sysUpTime itself was sampled
> (eg. you received it after 1.5s because of network delay and because
> the packet was queued in the control plane kernel because the
> control plane CPU was busy).

The SNMP agents controls sysUpTime - so sysUpTime is pretty much the
time the packet left the agent. If you talk about delays in the
instrumentation, that is the delay to read the register, then you are
correct. But once again, SNMP polling cycles are usually counted in
minutes.
 
> I don't mind so much that the reply was delayed (though I like fast
> replies!), but I do mind that there can be a very large uncertainty.

Very large is relative to the precision you want. SNMP was not
designed with subsecond precision in mind.

> There is also the overhead of requesting sysUpTime itself, not to
> mention when walking a table, you may time slew over the course of
> walking the table.

For any counter, you need discontinuity detection. The way you walk a
table has indeed a big impact in terms of data consistency - the
recommendation here is to use getbulk and to walk the columns of
interest concurrently.

> I understand definitely re caching hardware counters, etc, and I
> think that's fine (and necessary in a system with multiple NMSes),
> and I don't mind that the counters are cached, but I do want to know
> when they were cached for me to recover maximum temporal
> information.

SNMP agents typically do not help you with that - caching is rather
something implementation specific. And yes, operators have complained
about SNMP counters on some boxes being less "precise" than what the
CLI shows. I am no way saying SNMP is a model to choose - I just
wanted to help making it clear what SNMP does and what not.

If you want high accuracy, then every counter reading must be
timestamped exactly when the counter is read. This of course has a
price.

/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/>
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix