Subject: [dtn] DTN time and RFC8877

From: Brian Sipos <[email-masked]>
Date: Fri, 4 Dec 2020 13:25:45 +0000

Scott,
Addressing to you since is directly a question on BP spec, but any BP implementor is also welcome to speak up.
A new recommendation for what to include in IETF specifications using timestamps is RFC8877 [1] and brings up a couple of points not addressed by current BPbis section on DTN Time [2].

I'm not suggesting any necessary changes, just questions about DTN Time as an intrinsic value (separate from the old SDNV or new CBOR encodings) relative to the aspects in RFC8877. I'm also not reopening the question of DTN epoch or leap seconds; those have been decided, and I'm looking to RFC8877 nomenclature for expressing those decisions.

  *   Epoch, resolution, and units: These are already well-defined.
  *   Leap seconds: There had been discussion on the mailing list about this and DTN Time does not consider leap seconds, though it does use a UTC epoch. This is not mentioned as explicitly as RFC8877 does for PTP, "This timestamp format is not affected by leap seconds."
  *   Size and wraparound: The encoded syntax has its properties, but it's not clear from [2] whether the DTN Time intrinsically does also. For RFC5050 the DTN Time used SDNV with an explicit restriction to 2^64-1 (seconds) for BPbis the time is a 'unit' so also limited to 2^64-1 (milliseconds). You caution implementors about values larger than 2^32-1.
Is there an intrinsic upper-limit or wraparound behavior to DTN Time?
Is it okay if an implementation stores DTN Time in way (e.g., signed 64-bit int) which does not have the full domain of CBOR uint?
  *   Synchronization: The BPbis doesn't get into the level of detail as Section 5 of RFC8877 about what is required of BP agents. The one notable part of BPbis is that it does allow for agents with bad clocks to represent that as a DTN Time value zero, which has the special interpretation of "unknown time". This is more of a suggestion in Section 4.1.7 and not really a requirement of Section 4.1.6, so is DTN Time of zero really a special sentinel value or a legitimate encoded time?

Thanks for any feedback,
Brian S.

[1] https://tools.ietf.org/html/rfc8877#section-3
[2] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-29#section-4.1.6

---

From: "R. Atkinson" <[email-masked]>
Date: Fri, 4 Dec 2020 09:52:24 -0500

> On Dec 4, 2020, at 08:25, Brian Sipos <[email-masked]> wrote:
> 
> 	• Epoch, resolution, and units: These are already well-defined.
> 	• Leap seconds: There had been discussion on the mailing list about this and DTN Time does not consider leap seconds, though it does use a UTC epoch. This is not mentioned as explicitly as RFC8877 does for PTP, "This timestamp format is not affected by leap seconds."

Brian,

To avoid an unexpected interoperability issue if/when a Leap Second occurs, I think DTN time should specify how leap seconds are handled (or specify that they are ignored).  

I don’t really care whether they are ignored or handled, but I think it ought to be clearly specified what happens if/when a leap second occurs (or explicitly what doesn’t happen in the case of “ignored” leap seconds).

This is merely a matter of specification completeness.

> 	• Size and wraparound: The encoded syntax has its properties, but it's not clear from [2] whether the DTN Time intrinsically does also. For RFC5050 the DTN Time used SDNV with an explicit restriction to 2^64-1 (seconds) for BPbis the time is a 'unit' so also limited to 2^64-1 (milliseconds). You caution implementors about values larger than 2^32-1.

Again, I’m open to any resolution the WG or authors choose, but I’d like it to be clearly specified — whichever resolution folks prefer needs to be clearly documented so all
implementations will behave the same way.

> 	• Synchronization: The BPbis doesn't get into the level of detail as Section 5 of RFC8877 about what is required of BP agents. The one notable part of BPbis is that it does allow for agents with bad clocks to represent that as a DTN Time value zero, which has the special interpretation of "unknown time". This is more of a suggestion in Section 4.1.7 and not really a requirement of Section 4.1.6, so is DTN Time of zero really a special sentinel value or a legitimate encoded time?

Again, please clearly specify one or the other behaviour, but I don’t care which choice is made.

Thanks,

Ran

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Dec 2020 16:40:55 +0100

On 2020-12-04, at 15:52, R. Atkinson <[email-masked]> wrote:
> 
> (or specify that they are ignored).

You can’t say just that, because there are two ways to handle “ignoring” leap seconds, and when you say they are “ignored”, you don’t say which one.

(One way of “ignoring" leap seconds is to stay in TAI, which has no concept of leap seconds.
The other way is actually being cognizant of them and doing work to “ignore” them, i.e., reset the clock after each of them.  This is what UTC does to be able to “ignore” leap seconds.)

Grüße, Carsten

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 4 Dec 2020 16:39:57 +0000

Hi, Brian and Ran.  One point to emphasize is that DTN time is not UTC time: as noted in 4.1.6, it is a count of milliseconds (formerly seconds) since the moment that we commonly identify as 2000-01-01 00:00:00 +0000 (UTC).

I thought we had agreed on this language long ago, but maybe it needs to be clarified further.  How about this (adapting from the language on the time(2) man page)?

	A DTN time is an unsigned integer indicating the number of milliseconds that have elapsed since the DTN Epoch, 2000-01-01 00:00:00 +0000 (UTC), which is exactly 946684800 seconds after the Unix Epoch.  DTN time is not affected by leap seconds.  Each DTN time SHALL be represented as a CBOR unsigned integer item.
Implementers need to be aware that DTN time values conveyed in CBOR representation in bundles will nearly always exceed (2**32 – 1); the manner in which a DTN time value is represented in memory is an implementation matter.  The DTN time value zero indicates that the time is unknown.

Just for reference, the following is text from version 15 of the bpbis draft (October 18, 2019) which I added in response to Magnus's comments in July 2019, was later urged to remove, and cited in my response to Ben Kaduk's DISCUSS on February 26, 2020.

> A DTN time is an unsigned integer indicating an interval of Unix epoch time [EPOCH] that has elapsed since the start of the year 2000 on the Coordinated Universal Time (UTC) scale [UTC], which is Unix epoch timestamp 946684800.  (Note that the DTN time that equates to the current time as reported by the UNIX time() function can be derived by subtracting 946684800 from that reported time value.)  Each DTN time SHALL be represented as a CBOR unsigned integer item.
> 
> Note: The choice of Unix epoch time as the scale on which time values in DTN are expressed may need some explanation.
> 
> The computation of time intervals is integral to several DTN protocol procedures.  Inconsistency in the results of these computations would result in inconsistent performance of those procedures and would compromise the operation of the protocol.
> 
> So the key qualities sought in selecting the time scale to be used for expressing DTN times were these: (a) the broadest possible access to the value of the current time on the selected time scale, enabling all nodes of the network to perform protocol procedures in the same way using the same information, and (b) ease of time interval computation.
> 
> UTC was an obvious candidate but fell short on both counts.  First, millions of devices can readily query the current UTC time, thanks to NTP, but spacecraft operating beyond Earth orbit cannot.  There is currently no adaptation of NTP that operates over the long and variable signal propagation delays between vehicles in deep space.
> 
> Moreover, computing the number of actual elapsed seconds between two UTC times is non-trivial because UTC times include leap seconds.  As an illustration of the issue, consider the passage of UTC and TAI time at a ground station antenna that began transmitting data at 8Kbps around midnight December 31, 2016 (UTC), when a leap second was added (*):
> 		      UTC			         TAI		Total bytes sent
> t1	2016-12-31 23:59:58	2017-01-01 00:00:34		   0
> t2	2016-12-31 23:59:59	2017-01-01 00:00:35		1000
> t3	2016-12-31 23:59:60*	2017-01-01 00:00:36		2000
> t4	2017-01-01 00:00:00	2017-01-01 00:00:37		3000
> t5	2017-01-01 00:00:01	2017-01-01 00:00:38		4000
> 
> Suppose we must compute the volume of data transmitted in the interval between t1 and t5.  If we use TAI time values, the elapsed time interval is 4 seconds (00:00:38 minus 00:00:34); at 8Kbps, the computed transmission volume is 4000 bytes, which is correct.  If we instead use UTC time values as stated, without special compensation for the insertion of the leap second, the elapsed time interval is 3 seconds (00:00:01 minus 23:59:58); the computed transmission volume is then 3000 bytes, which is incorrect.
> 
> TAI, then, would be an ideal time scale for DTN, as the interval in seconds between two TAI times can be computed by simply subtracting one from the other; there is no need to consult a table of leap seconds each time a time interval is computed.  Unfortunately the current value of TAI, as tracked by atomic clocks on Earth and carefully managed by the International Bureau of Weights and Measures, is likewise not directly accessible to spacecraft.
> 
> Unix epoch time is the next best option.  Like TAI, Unix epoch time is simply a count of seconds elapsed since a standard epoch.  Unlike TAI, the current value of Unix epoch time is provided by virtually all operating systems on which BP is likely to run.
> 
> Implementers of Bundle Protocol need to be aware that the difference between DTN time and UTC time will increase with the passing years as additional leap seconds are inserted into UTC.  Converting DTN time to the correct corresponding UTC time, in the event that such conversion is needed, will require an understanding of the leap second adjustments made to UTC over time; for software written in C, the widely supported gmtime() function provides this service.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of R. Atkinson
Sent: Friday, December 4, 2020 6:52 AM
To: Brian Sipos <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [dtn] DTN time and RFC8877

Brian,

> Is it okay if an implementation stores DTN Time in way (e.g., signed 64-bit int) which does not have the full domain of CBOR uint?

Again, I’m open to any resolution the WG or authors choose, but I’d like it to be clearly specified — whichever resolution folks prefer needs to be clearly documented so all implementations will behave the same way.

Thanks,

Ran

_______________________________________________
dtn mailing list
[email-masked]
https://urldefense.us/v3/__https://www.ietf.org/mailman/listinfo/dtn__;!!PvBDto6Hs4WbVuu7!anE-0lT7bWXQJTVmUsmgpinn30fNgAolng6E7em2FacXJ1-dcwFNApMWYOeTNTY6Gd5rxeGzRA4$

---

From: Brian Sipos <[email-masked]>
Date: Fri, 4 Dec 2020 17:10:01 +0000

Scott,
I think the current statement is fine, it's just unusual to mix UTC-the-datum with TAI-the-lack-of-leap-seconds.
Because TAI and UTC only differ by a time-varying offset [1] but use the same rate, these two are identical statements:

  1.  "time elapsed since the start of the year 2000 on the Coordinated Universal Time (UTC) scale" which is what BPbis currently states.
  2.  "time elapsed since 32 seconds after the start of the year 2000 on the TAI scale" which accounts for the TAI-UTC leap second difference of 32 on 1 Jan 2000.

In either case, a statement such as the RFC8877 phrasing of "DTN Time is not affected by leap seconds." would add clarity to the situation without affecting the current agreed requirement text.

[1] https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt
________________________________
From: Carsten Bormann <[email-masked]>
Sent: Friday, December 4, 2020 10:40
To: R. Atkinson <[email-masked]>
Cc: Brian Sipos <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [dtn] DTN time and RFC8877

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Dec 2020 18:19:26 +0100

On 2020-12-04, at 17:39, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote:
> 
> 	A DTN time is an unsigned integer indicating the number of milliseconds that have elapsed since the DTN Epoch, 2000-01-01 00:00:00 +0000 (UTC), which is exactly 946684800 seconds after the Unix Epoch.  

Not true.
(Unless you actively remove the leap seconds from the time elapsed.)

> DTN time is not affected by leap seconds.  

That is exactly the meaningless statement that causes all these misunderstandings.
Whatever you do around civil time, you will be affected by leap seconds, in one way or the other.  You can only choose how.

Grüße, Carsten

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 4 Dec 2020 17:23:00 +0000

Brian, I think it's actually not all that unusual: it's exactly the way the time() system call is defined on the time(2) man page.  Unix calendar time is a simple count of seconds, just as TAI is, and the starting point of the count is a moment in time that we commonly identify as a time value on the UTC time scale.

It's true that TAI and UTC both advance at the same rate, one second per second, but the offset between TAI and UTC changes as new leap second adjustments are made in UTC: as each leap second is declared, the offset between TAI and UTC increases by 1 second - TAI advances by 1 second and UTC does not.  In my proposed revised text I said "DTN time is not affected by leap seconds."  Does that address your concern?

Scott

From: dtn <[email-masked]> On Behalf Of Brian Sipos
Sent: Friday, December 4, 2020 9:10 AM
To: Carsten Bormann <[email-masked]>; R. Atkinson <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [dtn] DTN time and RFC8877

Scott,

[1] https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt<https://urldefense.us/v3/__https:/cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt__;!!PvBDto6Hs4WbVuu7!au7pNhZH89rogLdZXrVRil2SNQj43GU3wk2GEVPxFbfnbJc0enzoIwG6JJkLTO6LGLz7VB40fAU$>
________________________________
From: Carsten Bormann <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 4, 2020 10:40
To: R. Atkinson <[email-masked]<mailto:[email-masked]>>
Cc: Brian Sipos <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dtn] DTN time and RFC8877

> (or specify that they are ignored).

You can't say just that, because there are two ways to handle "ignoring" leap seconds, and when you say they are "ignored", you don't say which one.

(One way of "ignoring" leap seconds is to stay in TAI, which has no concept of leap seconds.
The other way is actually being cognizant of them and doing work to "ignore" them, i.e., reset the clock after each of them.  This is what UTC does to be able to "ignore" leap seconds.)

Grüße, Carsten

---

From: Brian Sipos <[email-masked]>
Date: Fri, 4 Dec 2020 17:59:52 +0000

Scott,
Your last revised text (in that email) is okay, except that I think it's best to avoid "unix time" or "unix epoch". Both "UTC" and "unix time" have a lot of baggage beyond using them as instant-of-time epoch references. And implementations of unix time seem to do all kinds of funny things that're not strictly in the specs.

Carsten,
The statement "... is not affected by leap seconds." is specifically the recommended language of RFC 8877 for describing this situation. DTN time uses a specific epoch instant as a zero reference and then uses TAI/UTC rate-of-time as its unit scale.
________________________________
From: Burleigh, Scott C (US 312B) <[email-masked]>
Sent: Friday, December 4, 2020 12:23
To: Brian Sipos <[email-masked]>; Carsten Bormann <[email-masked]>; R. Atkinson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: RE: [dtn] DTN time and RFC8877

Brian, I think it’s actually not all that unusual: it’s exactly the way the time() system call is defined on the time(2) man page.  Unix calendar time is a simple count of seconds, just as TAI is, and the starting point of the count is a moment in time that we commonly identify as a time value on the UTC time scale.

It's true that TAI and UTC both advance at the same rate, one second per second, but the offset between TAI and UTC changes as new leap second adjustments are made in UTC: as each leap second is declared, the offset between TAI and UTC increases by 1 second – TAI advances by 1 second and UTC does not.  In my proposed revised text I said “DTN time is not affected by leap seconds.”  Does that address your concern?

Scott

Scott,

[1] https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.us%2Fv3%2F__https%3A%2Fcdf.gsfc.nasa.gov%2Fhtml%2FCDFLeapSeconds.txt__%3B!!PvBDto6Hs4WbVuu7!au7pNhZH89rogLdZXrVRil2SNQj43GU3wk2GEVPxFbfnbJc0enzoIwG6JJkLTO6LGLz7VB40fAU%24&data=04%7C01%7CBSipos%40rkf-eng.com%7C34669fd5ab7740e52fb108d898794261%7C4ed8b15b911f42bc8524d89148858535%7C1%7C1%7C637426993859020246%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=286lwpqaYG0s9nlF9KZWHdgUWrs2CFPxa0RnxP9P8zA%3D&reserved=0>

Grüße, Carsten

---

From: "Burleigh, Scott C (US 312B)" <[email-masked]>
Date: Fri, 4 Dec 2020 18:13:27 +0000

Sure, I'm happy to remove "which is exactly 946684800 seconds after the Unix Epoch" from the proposed revised text.

Scott

From: Brian Sipos <[email-masked]>
Sent: Friday, December 4, 2020 10:00 AM
To: Burleigh, Scott C (US 312B) <[email-masked]>; Carsten Bormann <[email-masked]>; R. Atkinson <[email-masked]>
Cc: [email-masked]
Subject: [EXTERNAL] Re: [dtn] DTN time and RFC8877

Scott,

Carsten,
The statement "... is not affected by leap seconds." is specifically the recommended language of RFC 8877 for describing this situation. DTN time uses a specific epoch instant as a zero reference and then uses TAI/UTC rate-of-time as its unit scale.
________________________________
From: Burleigh, Scott C (US 312B) <[email-masked]<mailto:[email-masked]>>
Sent: Friday, December 4, 2020 12:23
To: Brian Sipos <[email-masked]<mailto:[email-masked]>>; Carsten Bormann <[email-masked]<mailto:[email-masked]>>; R. Atkinson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>
Subject: RE: [dtn] DTN time and RFC8877

Scott

From: dtn <[email-masked]<mailto:[email-masked]>> On Behalf Of Brian Sipos
Sent: Friday, December 4, 2020 9:10 AM
To: Carsten Bormann <[email-masked]<mailto:[email-masked]>>; R. Atkinson <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [EXTERNAL] Re: [dtn] DTN time and RFC8877

Scott,

[1] https://cdf.gsfc.nasa.gov/html/CDFLeapSeconds.txt<https://urldefense.us/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.us*2Fv3*2F__https*3A*2Fcdf.gsfc.nasa.gov*2Fhtml*2FCDFLeapSeconds.txt__*3B!!PvBDto6Hs4WbVuu7!au7pNhZH89rogLdZXrVRil2SNQj43GU3wk2GEVPxFbfnbJc0enzoIwG6JJkLTO6LGLz7VB40fAU*24&data=04*7C01*7CBSipos*40rkf-eng.com*7C34669fd5ab7740e52fb108d898794261*7C4ed8b15b911f42bc8524d89148858535*7C1*7C1*7C637426993859020246*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=286lwpqaYG0s9nlF9KZWHdgUWrs2CFPxa0RnxP9P8zA*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PvBDto6Hs4WbVuu7!b_MQpI1_GEOkrPGC_iJZXUN2j7_sA73Y-zu5PddwK3WKggS523TbFo2eEMhbYWgzzFMbAGEj-Ho$>

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Dec 2020 21:14:32 +0100

On 2020-12-04, at 19:13, Burleigh, Scott C (US 312B) <scott.c.burleigh=[email-masked]> wrote:
> 
> Sure, I’m happy to remove “which is exactly 946684800 seconds after the Unix Epoch” from the proposed revised text.

Makes sense; there is nothing related to 1970-01-01 in DTN time.
(Also, leap seconds didn’t exist before 1972-01-01, earth rotation adjustments before that were way more complicated.)

I would add a sentence like:

Example: The DTN time at 2020-01-01 00:00 UTC was 631152005000 (note the five leap seconds by which UTC was delayed during those 20 years; the fact that the calendar also inserted five days during leap years is an unrelated coincidence).

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Dec 2020 21:21:19 +0100

> The statement "... is not affected by leap seconds." is specifically the recommended language of RFC 8877 for describing this situation. DTN time uses a specific epoch instant as a zero reference a…

RFC 8877 provides the necessary context to make this a valid statement within the terminology of that document.  So if you need to make this statement, anchor it by “in the terminology of RFC 8877”.  And add the example I just provided, so people know that UTC then is very much “affected by leap seconds”.

Grüße, Carsten