Re: [dtn] BPbis

The primary block must remain immutable otherwise integrity mechanisms over the primary block will fail.

Specifically, if a source node creates a tag 1, some other waypoint node cannot recode it as a tag 1001 even if it represents the same data value (and vice versa).

If the WG allows flexibility for tag 1 vs tag 1001, text must be added which either (a) states that the representation (once encoded) never be changed or (b) defines an unambiguous canonicalization of the time value.

-Ed

Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Principal Staff, Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423<tel:(443)%20778-7423> / (F) 443-228-3839<tel:(443)%20228-3839>

From: dtn <dtn-bounces@ietf.org> On Behalf Of Jeremy.Mayer@dlr.de
Sent: Wednesday, July 29, 2020 3:11 AM
To: cabo@tzi.org; scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org
Cc: dtn@ietf.org
Subject: [EXT] Re: [dtn] BPbis - time units

APL external email warning: Verify sender dtn-bounces@ietf.org<mailto:dtn-bounces@ietf.org> before clicking links or attachments

Hi,

I think we need to allow some flexibility with regards to the expression of time units. For many applications, it should suffice to keep everything in milliseconds (keeping in mind that millisecond-based times also necessitate internal timekeeping capability with a similar accuracy. However, in long-delay/bandwidth-constrained applications, there may not be any real requirement to have millisecond-accuracy time fields/time-keeping.

Therefore, I propose (apologies in advance) that we use both: tag 1 can be a standard unix-based timestamp (in seconds), used for long-delay applications. Otherwise, times can be represented with tag 1001, key (-3,-18) as reference in Carstens CBOR timekeeping draft (https://www.ietf.org/id/draft-bormann-cbor-time-tag-03.txt) for additional flexibility in unit expression, with the slight overhead that may arise.

Thanks,

Jeremy

________________________________
From: dtn <dtn-bounces@ietf.org<mailto:dtn-bounces@ietf.org>> on behalf of Carsten Bormann <cabo@tzi.org<mailto:cabo@tzi.org>>
Sent: Wednesday, July 29, 2020 7:47:45 AM
To: Burleigh, Scott C (US 312B)
Cc: dtn@ietf.org<mailto:dtn@ietf.org>
Subject: Re: [dtn] BPbis - time units

On 2020-07-29, at 03:09, Burleigh, Scott C (US 312B) <scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org<mailto:scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>> wrote:
>
> Hi.  At IETF-108 there was discussion on whether BP time fields (e.g., bundle creation time, lifetime, bundle age) should be denominated in seconds, milliseconds, microseconds, or nanoseconds.  Version 26 of the BPbis I-D (now posted) revises all time field definitions to be denominated in milliseconds.

Note that CBOR has a choice of different time formats (tag 1, tag 1001), so if you want to provide a choice, you could allow the use of these in addition to assigning a default meaning to naked integers.  (These have a different epoch, but that is just a matter of subtracting a constant value; the representation needs one bit more which is making a difference between 2106 and 2030 next for whole seconds.)  Until 2106, tag 1 is shorter (6 bytes in total) than a naked integer in milliseconds (9 bytes).

(I don't have an opinion on the actual question, but here is some data for that.)

Grüße, Carsten

_______________________________________________
dtn mailing list
dtn@ietf.org<mailto:dtn@ietf.org>
https://www.ietf.org/mailman/listinfo/dtn