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

From: Josh Bailey <[email-masked]>
Date: Tue, 11 Oct 2011 23:54:19 -0700 (PDT)

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

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.

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.

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.

> On Tue, Oct 11, 2011 at 05:49:13PM -0700, Josh Bailey wrote:
>
>> I think it'd be good thing to specify an association between a
>> timestamp, and an exported OID, flow, etc. When exporting an OID,
>> for example, I would like a way to know within some limit of
>> certainty when that OID value was actually sampled.
>>
>> A problem I find with SNMP is that the client can only use its own
>> timestamp of the server's reply to guess when the requested variable
>> was sampled. If there is uncertainty in the server implementation
>> that adds some delay between sampling and sending the response
>> (without even addressing variable network delay), there's no way to
>> know when the object was sampled with any certainty.
>
> In SNMP land, you typically fetch sysUpTime together with the counters
> (also to detect discontinuities). This means you get a timestamp that
> is attached to the counter by the 'server' and this timestamp can take
> care of the network delay part. That said, implementations sometimes
> for efficiency reasons do not read out hardware registers on every
> request if you poll very fast - so there might be some notable delay
> in how counter changes are reported (but then typical SNMP poll cycles
> are counted in minutes).

--
Josh Bailey

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Oct 2011 09:33:38 +0200

On Tue, Oct 11, 2011 at 11:54:19PM -0700, Josh Bailey wrote:
> 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.
 
> 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/>