Subject: RE: [ipfix] [issue] INFO-24 High-res time encoding

From: "Carter Bullard" <[email-masked]>
Date: Mon, 8 Dec 2003 14:27:43 -0500

Hey Nevil,
   This is an interesting question, as it assumes that
all the records are coming from a single IPFIX data
source.  What happens if IPFIX is transporting data
from multiple sources as they are received, but the
timestamps in the various records are not synchronized?

Carter

-----Original Message-----
From: Nevil Brownlee [mailto:[email-masked]]
Sent: Monday, December 08, 2003 1:34 PM
To: [email-masked]; 'Maurizio Molina'
Cc: [email-masked]
Subject: RE: [ipfix] [issue] INFO-24 High-res time encoding

Hi Carter and Maurizio

>    I have customers today that are using uSec granularity
> exclusively and we're moving to nSec granularity for some
> applications shortly.  So, these resolutions are not exotic
> for my customers, they are the norm.

OK, by all means let's keep all four of Jeff's timestamp formats.

Now what about the notion of having a dateTimeUsec timestamp in the
header and 32-bit offsets from that for timestamps in flow groups?
Would that save enough space to be useful?

CHeers, Nevil

-----------------------------------------------------------------------
   Nevil Brownlee                   Director, Technology Development
   Phone: +64 9 373 7599 x88941     ITSS, The University of Auckland
   FAX: +64 9 373 7021      Private Bag 92019, Auckland, New Zealand

-------------------------------------------------
This mail sent through University of Auckland
http://www.auckland.ac.nz/

--
Help        mailto:[email-masked] and say "help" in message body
Unsubscribe mailto:[email-masked] and say
"unsubscribe ipfix" in message body
Archive     http://ipfix.doit.wisc.edu/archive/

---

From: Nevil Brownlee <[email-masked]>
Date: Tue, 9 Dec 2003 11:07:20 +1300

> timestamps in the various records are not synchronized?

Sounds like a good reason not to do it.  
That would simply mean that timestamps in an IPFIX record would all 
be in whichever of the four encodings the meter was configured to 
send, right?

Cheers, Nevil

---

From: Mark Fullmer <[email-masked]>
Date: Tue, 9 Dec 2003 01:27:19 -0500

It depends on how smart the exporter is...A simple way to do this
would be to limit flows from each source to a single message.  Note, The
existing draft uses the term "packet" where it it should be message.

There appear to be some deeper problems with having multiple
data sources in a single IPFIX session though.  For example there
is currently no mechanism defined to describe where the data in a
template or multiple templates representing the same data source 
come from.

The protocol can move the data but reporting tools that work with
it don't know how its related.

mark

---

From: Maurizio Molina <[email-masked]>
Date: Tue, 09 Dec 2003 13:57:49 +0100

>>timestamps in the various records are not synchronized?
Having heard pros and cons on this issue, why not to let timestamps in 
the  flow records encoded in one of the formats that "allows" splitting 
in 32+32 bit to appear in the flow record either as 32 or as 64 bit? If 
they are of 64 bit, the first 32 bit override whatever value it's 
written in the header (but for the flow thery're relative to only) if 
they are 32 bit they refer to the common 32 bit in the header for the 
integer part (and for all flows making use of the  header portion 
synchronization is assumed).
In this way, even in the same message, we can have coexisting full 64 
bit timestamps and 32 (header) + 32 (flow rec) timestamps.
The cost of this is that in the type definition we must explicitly 
separate the "high" and "low" part for each encoding scheme that allows 
this splitting.
For 32 bit only encoding (e.g. dateTime) or 64 bit encoding schemes not 
allowing splitting (if we decide to support them...) the timestamp in 
the header is always ignored.
Maurizio