Subject: RE: [ipfix] [issue] INFO-19 Timestamps

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Tue, 25 Nov 2003 10:05:44 -0800

Hi,

  Given the varied requirements of the group, my advice would be to maintain
all 4 resolutions of time.  Keep in mind that from an information model 
perspective, knowing the maximal precision or scale of IE's is important
to downstream elements like collectors and their subsequent consumers.

  I have tried to separate the concern of time resolution (a info model
issue) from that of time encoding (a protocol issue).

  Resolutions that increment at 10**-3 notches seem to capture the range
of what folks may be interested in:

  - dateTime - second resolution is typically sufficient for billing and
   historical recording.

  - dateTimeMsec - millisecond resolution is what NFvX uses today, and
allows
   for more accurate calculation of flow bandwidth.

  - dateTimeUsec and Nsec - micro and nano second resolution are too exotic
for
   the majority of my customers, but there appears to be interest from the
   group.

  Personally being consistent w/ NFv2-9 in terms of using millisecond
resolution
on the default flowCreationTime and flowEndTime would be my preference.
Adding
additional flowCreationTimeUsec or flowCreationTimeNsec would be the way I
would
see addressing use cases which require finer time granularity.  NOTE:
today's
info model calls these out as simple "dateTime" which should be changed.

  This still leaves the encoding open.  NTP format in 8 bytes, milliseconds
since
EPOCH in 8 bytes (java time), microseconds relative to a timestamp in a
message
header is another alternative, which may require only 4 bytes per flow,
simple
seconds since EPOCH can also use 4 bytes, but may be considered too coarse.

Regards,

  Jeff Meyer

-----Original Message-----
From: Falko Dressler [mailto:[email-masked]]
Sent: Tuesday, November 25, 2003 1:06 AM
To: 'Ipfix Wg' (E-mail)
Cc: MEYER,JEFFREY D (HP-Cupertino,ex1)
Subject: Re: [ipfix] [issue] INFO-19 Timestamps

I believe that Simon's proposal for replacing the dateTime type (seconds 
since epoch) by timeStampUsec (msec since epoch) does not meet all the 
requirements of flow information.
If such information are used for security issues, a correlation of 
different flow data in a much larger interval that about one hour is 
required. On the other hand, if higher resolution really is required, a 
NTP time stamp can be used.

Nevertheless, I totally agree with replacing ipdr:*** types by a more 
appropriate type such as dateTimeNsec or the NTP version. The latter 
probably fits much better because most protocols relying on a high 
precision timestamp employ the NTP time stamp format.

Cheers,
Falko.

MEYER,JEFFREY D (HP-Cupertino,ex1) wrote:
> Issue:  INFO-19  Timestamps
> Description: 
>   Various options for managing timestamps from a resolution, encoding 
> and information model perspective.
>  
>   Original e-mail:
>   http://ipfix.doit.wisc.edu/archive/2056.html
>  
>   - various resolutions and encoding formats can be specified:
>     o seconds      - 32 bit since EPOCH
>     o milliseconds - 64 bit since EPOCH  (no rollover)
>     o microseconds - ?
>     o nanoseconds  - ? ** Use for NTP **
>     o NTP format  - 232 picosecond resolution (1/2**32)
>    
>     Encoding options include:
>    
>       - simple 32-bit time (sec)
>       - simple 64-bit time (msec)
>       - high res 32-bit time (m or usec) relative to header time
>       - very high res 2*32-bit time in NTP format sec.fraction
>    
>   Alternate interpretation from Simon Leinen:
>  
>     http://ipfix.doit.wisc.edu/archive/1928.html
>    
>   Doesn't want absolute time, but some relative, i.e. are we wasting the
>   32-bits?  This seems like an encoding/protocol vs. information model
>   issue.
>  
>   More from Simon:
>  
>         http://ipfix.doit.wisc.edu/archive/1927.html
>  
>   Alternate suggestion on dateTimeNSec, cites Posix 1b struct:
>  
>   struct timespec{
>           time_t tv_sec;          /*seconds*/
>           long    tv_nsec;        /*nanoseconds*/
>   };
>  
>  
>   Effectively similar to NTP time, although your divisor for the
>   second factor is 10**9 vs. 2**32
>  

-- 
Dr.-Ing. Falko Dressler
Computer Networks and Internet
Wilhelm-Schickard-Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70522 / Fax: +49 7071 29-5220
EMail: [email-masked] / [email-masked]
http://net.informatik.uni-tuebingen.de/members/dressler/

--
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: Falko Dressler <[email-masked]>
Date: Tue, 25 Nov 2003 19:39:23 +0100

Perhaps you are right in deciding that all dateTime variants should be 
kept in the model...

Regarding the question "which encoding to be used for high-res times" 
I'd like to prefer the NTP version. It offers a very high resolution 
while being a common fundament for many IETF-made protocols.

Cheers,
Falko.