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

Hi Juergen;

I agree with your statement about SNMP not being designed for subsecond 
precision. And I definitely agree that there are things you can do to 
minimise potential delays and that often those delays are implementation 
specific.

I don't agree though that sysUpTime is when the packet left the agent; 
especially if the agent is running slowly for whatever reason, or if the 
sysUpTime reply happens to be part of a packet containing replies for 
other variables (perhaps from different CPUs in a typical distributed CPU 
router).

I also don't agree that cycles are usually measured in minutes. In my 
experience cycles are very much shorter on average.

As you say having a timestamp per counter while costly is ideal in some 
sense. However I am looking to explore different tradeoffs; for example, a 
timestamp followed by a list of OIDs all current at that same timestamp.

I am aware of counter implementations that could do such a "snapshot" 
operation for example.

Thanks,

>>
>> 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/>
>
>
>

--
Josh Bailey
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix