Subject: [IPFIX] dateTimeMicroseconds and Nanoseconds

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Sep 2010 15:32:29 -0400

Howdy,
RFC 5101 says dateTimeMicroseconds and dateTimeNanoseconds are encoded per NTP format of RFC 1305.  Since that format is known to wrap in 2036, why was this format chosen? 

-hadriel

---

From: Brian Trammell <[email-masked]>
Date: Fri, 24 Sep 2010 21:54:14 +0200

Hi, Hadriel,

Not sure as to the specific rationale behind this, but do note that the protocol itself is not 2036-clean: the Export Time field in the header is 32 epoch bits...

Best regards,

Brian

On Sep 24, 2010, at 9:32 PM, Hadriel Kaplan wrote:

> _______________________________________________
> IPFIX mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipfix

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Sep 2010 17:26:51 -0400

Yeah, but that's 2038 which is much later. ;)
Actually, is it a signed value?  It doesn't say, afaict.  If it's unsigned then we've got until 2106 or some such, I think. 

-hadriel

---

From: Benoit Claise <[email-masked]>
Date: Fri, 24 Sep 2010 23:45:29 +0200

> RFC 5101 says dateTimeMicroseconds and dateTimeNanoseconds are encoded per NTP format of RFC 1305.  Since that format is known to wrap in 2036, why was this format chosen?
Because, in 2036, retired, we will need one reason to be laughing about 
IPFIX  ;-)

Regards, Benoit.

---

From: Brian Trammell <[email-masked]>
Date: Sat, 25 Sep 2010 09:48:56 +0200

hi Hadriel,

Actually, yes, Export Time is unsigned, as is dateTimeSeconds. So the limits are:

IPFIX message, exportTimeSeconds, flow(Start/End)DeltaMicroseconds IE: 2106
dateTimeMilliseconds: 1970 + 2^64 milliseconds (practically unlimited, for purposes of this discussion)
dateTimeMicroseconds, dateTimeNanoseconds: 2036

In the seventy years between 2036 and 2106, we can handle microsecond and nanosecond resolution by deprecating the Information Elements based upon these types and either 1. following NTP's lead or 2. specifying microsecond and nanosecond resolution based on 32-bit or 64-bit deltas to the export time (as flowStartDeltaMicroseconds). I would recommend the former; dealing with message-relative timestamps is a pain. I presume NTP is already working on this, actually, as 26 years is a surprisingly short amount of time.

Before 2106, we will need to expand the Export Time header to 64 bits. Twenty years' lead time should be more than adequate, so we won't have to take this up as a working group until 2086. Since as Benoit notes we'll all be retired by then, we should make sure to leave a note of reminder somewhere to our successors. :)

Through all of these changes, millisecond-level timestamps can continue to use the dateTimeMilliseconds type. Since many network measurement devices _at present_ have difficulty with sub-millisecond precision, this is adequate for general use.

Cheers,

Brian