Re: [dtn] BPbis - time units

["Taylor, Rick" <[e-mail]>]

Airbus Amber
Ed,

You make a valid point re canonicalization and recoding, but given the stamps are in the immutable primary block, after the source has built the block, no matter the timeval encoding, they can't be changed, so I see this a non-issue - which normally means I've missed something... can you elaborate?

Cheers,

Rick

Rick Taylor
Product Design Authority, Mobile IP Node/PlexOS
Principal Engineer (eXpert), Mobile Communications
Airbus Defence and Space
Celtic Springs
Coedkernew
Newport
NP10 8FZ

Phone: [phone]
[e-mail]<mailto:[e-mail]>
www.airbusdefenceandspace.com<http://www.airbusdefenceandspace.com/>

From: dtn [mailto:[e-mail]] On Behalf Of Birrane, Edward J.
Sent: Wednesday, July 29, 2020 3:21 PM
To: [e-mail]; [e-mail]; scott.c.burleigh=[e-mail]
Cc: [e-mail]
Subject: Re: [dtn] BPbis - time units

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 <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Wednesday, July 29, 2020 3:11 AM
To: [e-mail]<mailto:[e-mail]>; scott.c.burleigh=[e-mail]<mailto:scott.c.burleigh=[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: [EXT] Re: [dtn] BPbis - time units

APL external email warning: Verify sender [e-mail]<mailto:[e-mail]> 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 <[e-mail]<mailto:[e-mail]>> on behalf of Carsten Bormann <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, July 29, 2020 7:47:45 AM
To: Burleigh, Scott C (US 312B)
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [dtn] BPbis - time units

On 2020-07-29, at 03:09, Burleigh, Scott C (US 312B) <scott.c.burleigh=[e-mail]..org<mailto:scott.c.burleigh=[e-mail]>> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dtn



THIS DOCUMENT IS NOT SUBJECT TO EXPORT CONTROL.

This email and its attachments may contain confidential and/or privileged information.  If you have received them in error you must not use, copy or disclose their content to any person.  Please notify the sender immediately and then delete this email from your system.  This e-mail has been scanned for viruses, but it is the responsibility of the recipient to conduct their own security measures. Airbus Operations Limited is not liable for any loss or damage arising from the receipt or use of this e-mail.

Airbus Operations Limited, a company registered in England and Wales, registration number, 3468788.  Registered office:  Pegasus House, Aerospace Avenue, Filton, Bristol, BS34 7PA, UK.