Subject: [IPFIX] timestamps, exporters, and other animals

From: Josh Bailey <[email-masked]>
Date: Tue, 11 Oct 2011 17:49:13 -0700 (PDT)

Hi all;

So I wanted to start a discussion around timestamps when exporting flows 
or OID values (qv. http://www.ietf.org/proceedings/81/slides/ipfix-6.pdf).

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.

I have also seen this problem in various sFlow implementations. There, 
often the timestamp is added by the control plane an unknown amount of 
time after the sample was taken.

Has there been any prior work or discussion around this issue? I had a few 
of my own thoughts about how to approach it, but I thought it would be 
useful to start here.

PS. For background - I am looking at NMS/protocol implementation for 
OpenFlow devices, which might have very many distributed individual 
devices with very many ports and variables per port. Therefore I'd very 
much like to implement an efficient NMS "counter" protocol.

Thanks,

--
Josh Bailey

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 12 Oct 2011 07:56:39 +0200

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

/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: Benoit Claise <[email-masked]>
Date: Thu, 13 Oct 2011 12:33:51 +0200

Hi Josh,

Thanks for bringing up that point.
There are actually multiple cases

1.  Flow Records composed of MIB variables only.
Yes, we would need the time next to each counter, to be precise. At the 
minimum, a single time for all counters, assuming that all counters are 
read at the same time.
In this case, I believe that the Flow Records encoding have an advantage 
compared SNMP: the absolute timestamps.
I mean: when you receive a SNMP notification, you have the sysUpTime. 
Big deal! Hence some NMS just depends on the time the SNMP notifications 
arrives.

2. Flow Records composed of MIB variables completing the Flow IEs. 
Example: I want to poll my QoS class counters at the time of my flow
In this case, we need to pay attention to something else: we have to 
decide when to poll the counters: when the Flow started, when the Flow 
ended, multiple times along the Flow live, or ...?
Anyway, we would to attach the time next to the SNMP counters, exactly 
like in the first case.

Now, we still have the issue that some SNMP interface counters are not 
updated real-time! Obviously, this metering issue will not be solved 
with a new encoding.

Regards, Benoit.
>
> Hi all;
>
> So I wanted to start a discussion around timestamps when exporting 
> flows or OID values (qv. 
> http://www.ietf.org/proceedings/81/slides/ipfix-6.pdf).
>
> 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.
>
> 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
> Has there been any prior work or discussion around this issue? I had a 
> few of my own thoughts about how to approach it, but I thought it 
> would be useful to start here.
>
> devices with very many ports and variables per port. Therefore I'd 
> very much like to implement an efficient NMS "counter" protocol.
>
> Thanks,
>
> -- 
> Josh Bailey
> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix
>
>