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

From: "Carter Bullard" <[email-masked]>
Date: Mon, 8 Dec 2003 11:41:29 -0500

Gentle people,
   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.

Carter

-----Original Message-----
From: majordomo listserver [mailto:[email-masked]] On Behalf Of
Maurizio Molina
Sent: Monday, December 08, 2003 10:30 AM
To: [email-masked]'
Subject: Re: [ipfix] [issue] INFO-24 High-res time encoding

Nevil Brownlee wrote:

>Hi Jeff:
>
>Thanks for your description of the Java 64-bit ms since 1 Jan 1970,
>that does seem like a good compromise - to me, ms for flow times
>is about right (I need us for packets, but not flows), and I like its
>'no rollover' feature.
>
>
>
>>  So I would propose encoding formats of:
>>
>>   - dateTime (second resolution, using 32-bits representing unsigned
>>seconds since 1970 EPOCH)
>>   - dateTimeMsec (msec resolution, using 64-bits represening unsinged
msecs
>>since 1970 EPOCH)
>>   - dateTimeUsec (usec resolution using 2 32-bit quantities representing
>>seconds since 1970 EPOCH and another for the number of usec, i.e. range of
>>0-.999999)
>>   - dateTimeNsec (nsec resolution, using 2 32-bit quantities representing
>>seconds since 1900 (not 1970) EPOCH and another 32-bit for the fractional
>>component.  I.e. the 32-bit value 0x00000001 = 1*2**-32.  And the 32-bit
>>value of 0xFFFFFFFF = (2**32 - 1) * 2**-32, assuming standard C language
>>operator precedence.
>>
>>
>
>I agree we should support the first two, the others seem less useful to me.
>
Hi Nevil,
I think we should be careful with excluding encodings for resolutions
higher than the millisecond.
As Sebastian pointed out in some previous mail,
"Another type with at least microsecond resolution should
be available for cases where a higher granularity is required (e.g. delay
measurement)"
Delay measurements are actually considered in the IPFIX applicability
draft. Moreover, PSAMP is considering of  using IPFIX as a transport,
and PSAMP based applications are likely to include delay measurements.
Also, at the last meeting there was a hummmm in favour of microseconds.

I think this sentence from Jeff is the one that best captures the issue:

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

All that said, I'd be in favour of also keeping the support of encodings
for high time resolutions.
Cheers,
Maurizio

>
>
>
>
>>  I still believe there is a desire among some WG participants to leverage
>>per "flow group" compacting via the use of integral offsets from some time
>>stamp stored in a common format in the header.  E.g. header has
dateTimeUsec
>>format of some reference time and flows in that group specify times as
>>32-bit offset + or - from this value.
>>
>>
>
>I can see that it would save space to do this.  Would it be enough to
>have a dateTime (seconds) in the header, then 32-bit ms offsets from that
>in the flow groups?
>
>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/

--
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 07:34:04 +1300

Hi Carter and Maurizio

> 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