Subject: [dtn] AMP comment on time encoding

From: Brian Sipos <[email-masked]>
Date: Thu, 7 Apr 2016 17:19:41 +0000

This is a comment against "draft-birrane-dtn-amp-02".

This may be a dumb question, but is there a driving reason why the AMP time encoding is different from the "DTN time" used for Bundle Protocol? Also, is there a reason for using an encoding magic number to distinguish between absolute and relative time vs. a more explicit mechanism (two types or an in-type flag)?

These are not questions about the value-being-encoded but on the encoding format itself.

---

From: Brian Sipos <[email-masked]>
Date: Mon, 18 Apr 2016 12:49:22 +0000

I agree with everything you have said, and I don't question that the encoding is unambiguous.

My main concern with both BP and AMP using offsets in UTC time but with different zero-offset epochs is that between the two times (DTN/PB time at 2000-01-01 and AMP at 2012-09-09) there have been three UTC leap seconds <http://maia.usno.navy.mil/ser7/tai-utc.dat>. This is not a huge discrepancy, but makes things more 'interesting' for systems which operate on both epochs.

I understand that these kinds of things have been argued to death before (and will continue for a long while). I also certainly prefer a working implementation with known issues than a theoretical target of perfection which is unusable. My only real request would to add some guidance to AMP spec in Section 3.1.3 to at least raise the issue to an implementer and possibly recommend a DTN-friendly course of action (ignore leap seconds, I suppose).

________________________________
From: Birrane, Edward J. <[email-masked]>
Sent: Sunday, April 17, 2016 16:13
To: Brian Sipos
Subject: RE: AMP comment on time encoding

Brian,

  A couple of things drove this decision:

- AMP doesn't require BP and so there was no reason to synchronize with BP time. For example, there are some potential AMP stakeholders who will not deploy BP.

- Since timestamps are encoded in SDNVs we are going to have (if I did my math right) exactly 5 byte timestamps for the next 1000 years or so whether we use the BP EPOCH or the UNIX EPOCH. This is because, with SDNVs, you only get 7 data bits per byte, so 4 bytes of SDNV gives you 28 data bits which only holds about 8.5 years of seconds. If we did not use SDNVs we could get by with 4 byte timestamps for ~90 years

- We saw no benefit in adding yet another byte beyond the one already imposed by SDNV encoding. The use of a magic number was suggested as it could be encoded in the spec and therefore allow for unambiguous determination of time type without adding any additional overhead.

In my view, the proposed mechanism is "explicit" in the sense that it is completely unambiguous. Adding extra bits or bytes and their associated processing would not yield a different result.

-Ed

---
Edward J. Birrane, III, Ph.D.

Embedded Applications Group Supervisor

Space Exploration Sector

Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839

From: dtn [mailto:[email-masked]] On Behalf Of Brian Sipos
Sent: Thursday, April 07, 2016 1:20 PM
To: [email-masked]
Subject: [dtn] AMP comment on time encoding