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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Mon, 8 Dec 2003 22:57:32 -0500

Resending to full mail list...

-- Jeff

-----Original Message-----
From: MEYER,JEFFREY D (HP-Cupertino,ex1) 
Sent: Monday, December 08, 2003 3:53 PM
To: 'Nevil Brownlee'
Subject: RE: [ipfix] [issue] INFO-24 High-res time encoding

Hi,

  Here's a proposal for encoding:

   - dateTime -> 32-bit integer seconds since 1970
   - dateTimeMsec -> 64-bit integer msec since 1970 (Java format)
   - dateTimeUsec -> split 32-bit integer seconds since 1970 carried in 
                   IPFIX flow header and 32-bit integer count of (signed)
                   microseconds offset from the header.  **This would
                   imply that all events for a flow set using this
optimization 
                   would need to occur w/in about 2000 seconds before or
                   after the sentinel time in the header. [+/- 2000 seconds
                   is +/-2,000,000,000 usecs, around the signed int32 limit]
   - dateTimeNsec -> 64-bit time in NTP format with 32-bits of seconds since
                   1900 (NOT 1970!) and 32-bit fraction of a second
component.
                   Both values occur in the flow record.

  Note a separate issue is what type should the basic flowCreationTime
and flowEndTime information elements should have?  Currently Info-02 has
them
as dateTime, but should probably be dateTimeMsec to reflect current
information
content of deployed netflow, or perhaps dateTimeUsec, if folks prefer to
only use 32-bits to achieve some size reduction when passing many
timestamps.

  My preference would be dateTimeMsec.

-- Jeff

> -----Original Message-----
> From: majordomo listserver 
> [mailto:[email-masked]]On Behalf
> Of Nevil Brownlee
> Sent: Monday, December 08, 2003 2:07 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [ipfix] [issue] INFO-24 High-res time encoding
> 
> 
> Hello Carter:
> 
> >    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?
> 
> 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
> 
> --------------------------------------------------------------
> ---------
>    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/
> 

--
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: Mark Fullmer <[email-masked]>
Date: Tue, 9 Dec 2003 00:31:10 -0500

Do we really need four ways to represent time?  How about one 32 bit
format and one 64 bit format?

The existing NetFlow 32 bit msec Start/End time stamps + header
real time offset gives you msec real time resolution.  Implementations
that can not support / don't need msec resolution can just leave the low
order bits 0.  So this covers dateTime and dateTimeMsec with one 32
bit encoding.

64 bit NTP format format with nanosecond resolution covers microsecond
resolution implementations.  Again, implementations that want microsecond
just leave the low order fractional bits 0.

mark

---

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

>just leave the low order fractional bits 0.
I think this opens an interesting issue:
Should IPFIX explicitly define a method for letting the exporter 
indicating the precision of its clock, e.g. via this zero-padding you 
mention?
In this case, how do we deal with the case the exporter has, for 
example, millisecond resolution but it has by chance  to fill a record 
exacly with three zeros in the fractional part, i.e. 12345.000? Should 
IPFIX specify that it has to force it 12345.001? Or should this 
precision indication be sent once and for all, e.g. in an option record? 
Or shouldn't it be sent at all?
Maurizio