Re: [dtn] BPbis

Rick,

  BPbis states that the primary block shall be immutable, and then provides a definition of immutability (from section 4.2.2):

The primary block of each bundle SHALL be immutable.  The values of
   all fields in the primary block must remain unchanged from the time
   the block is created to the time it is delivered.

If we allow flexible time representation, an implementation could say "I, and all downstream from me, prefer milliseconds" and then recode time values in primary blocks from seconds to milliseconds in a well-intentioned attempt to speedup some processing thinking they met the standard of immutability presented in section 4.2.2 because the semantic time value was unchanged.

The text should probably say "the encoded values of all fields in the primary block must remain unchanged...". Hopefully that is a small and not controversial clarification.

To your point - that may be obvious. But we have seen a similar issue with BPAs recoding fixed-width representations to compact representations in the past...

-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: Taylor, Rick <rick.taylor@airbus.com>
Sent: Wednesday, July 29, 2020 11:38 AM
To: Birrane, Edward J. <Edward.Birrane@jhuapl.edu>; Jeremy.Mayer@dlr.de; 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 rick.taylor@airbus.com<mailto:rick.taylor@airbus.com> before clicking links or attachments

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: +44 (0) 1633 71 5637
rick.taylor@airbus.com<mailto:rick.taylor@airbus.com>
www.airbusdefenceandspace.com<http://www.airbusdefenceandspace.com/>

From: dtn [mailto:dtn-bounces@ietf.org] On Behalf Of Birrane, Edward J.
Sent: Wednesday, July 29, 2020 3:21 PM
To: Jeremy.Mayer@dlr.de<mailto:Jeremy.Mayer@dlr.de>; cabo@tzi.org<mailto:cabo@tzi.org>; scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org<mailto:scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>
Cc: dtn@ietf.org<mailto:dtn@ietf.org>
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 <dtn-bounces@ietf.org<mailto:dtn-bounces@ietf.org>> On Behalf Of Jeremy.Mayer@dlr.de<mailto:Jeremy.Mayer@dlr.de>
Sent: Wednesday, July 29, 2020 3:11 AM
To: cabo@tzi.org<mailto:cabo@tzi.org>; scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org<mailto:scott.c.burleigh=40jpl.nasa.gov@dmarc.ietf.org>
Cc: dtn@ietf.org<mailto: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

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.