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

From: "MEYER,JEFFREY D (HP-Cupertino,ex1)" <[email-masked]>
Date: Tue, 25 Nov 2003 13:43:17 -0500

Falko,

  I'm not sure how the other editors would like to manage issues (i.e.
issue identifiers, yes/no), but would you be willing to highlight this 
as a separate [issue] subject item for the protocol group?

Regards,

  Jeff Meyer

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

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.

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

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