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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Fri, 21 Nov 2003 16:13:14 -0500

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

---

From: Falko Dressler <[email-masked]>
Date: Tue, 25 Nov 2003 18:33:45 +0100

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:
>   Various options for managing timestamps from a resolution, encoding 
> and information model perspective.
>  
>   Original e-mail:

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