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

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