Re: [dtn] [EXTERNAL] Re: DTN time and RFC8877

["Burleigh, Scott C (US 312B)" <[e-mail]>]

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 <[e-mail]> On Behalf Of R. Atkinson
Sent: Friday, December 4, 2020 6:52 AM
To: Brian Sipos <[e-mail]>
Cc: [e-mail]
Subject: [EXTERNAL] Re: [dtn] DTN time and RFC8877



> On Dec 4, 2020, at 08:25, Brian Sipos <[e-mail]> wrote:
> 
> 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."

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

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


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