Subject: [dtn] version 5 of bpbis spec

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Wed, 7 Sep 2016 15:59:30 +0000

Hi.  I just now posted a new version of the bpbis spec that I think addresses the sense of what we agreed to in the Berlin meeting.

1.  Specific encoding of the BP blocks is now included.  This is CBOR encoding, mostly lifted from the CBOR BP representation drafts I posted earlier.

2.  The custody refusal mechanism has been separated from the custodial retransmission mechanism.  When I looked carefully at the way custody transfer was defined, it seemed to me that the custody refusal mechanism was exactly identical to what was currently defined for custody transfer; what was a little different, actually, was custodial retransmission (because it lacked custody refusal).  Also, custody acceptance and release was going to be exactly the same for both.  So rather than breaking these things apart completely, I defined two different, individually optional custody transfer services: "retransmission service" (which now includes an additional custody signal that Keith Scott suggested) and "rerouting service".  I think the result accomplishes what we wanted to do, is relatively simple, and is a relatively small divergence from what people have already implemented and gotten some experience with.  Your comments are welcome.

Scott

---

From: Carlo Caini <[email-masked]>
Date: Wed, 7 Sep 2016 16:59:39 +0000

Dear Scott,
     I have just read the part concerning custody and I fully agree with the new definitions. In particular, the distinction of the two services makes definitively clearer the different aims that custody try to achieve.
Thanks to you and Keith for the excellent job.
   Yours,
       Carlo

________________________________________
Da: dtn [[email-masked]] per conto di Burleigh, Scott C (312B) [[email-masked]]
Inviato: mercoledì 7 settembre 2016 17:59
A: DTN WG
Oggetto: [dtn] version 5 of bpbis spec

Scott

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: Brian Sipos <[email-masked]>
Date: Tue, 13 Sep 2016 12:54:31 +0000

Scott,

Thank you for this consolidated specification.

My one concern with the current BPbis spec is to do with the CBOR encoding requirement specificity. Based on the current requirements for both a CBOR "type" and an "additional info" for encoded values, this disallows the use of all of the existing off-the-shelf CBOR encoders that I have examined. This is not necessarily a show-stopper for BPbis, but if a goal of this BPbis effort is to avoid custom protocol encoders/decoders then this is a problem.

My recommendation would be to simply do not specify specific required "additional info" but rather specify the qualities of the decoded values (e.g. maxim unsigned bit-length allowed for a value, allowed sizes of arrays). If there is a need for some kind of "canonical encoding" for these things then okay; but I don't think that a bundle which satisfies the spirit of the BPbis encoding but doesn't use the exact required octets should be treated as an invalid PDU. If using a COTS CBOR library to decode I don't see how you would detect that level of encoded detail anyway.

Two other very similar areas for encoding requirements:

1: Requirements about type and additional-info for CBOR arrays. Again, this runs into issues with COTS CBOR libraries (where I can specify an array be encoded, but not necessarily as indefinite-length form). My recommendation would be to simply specify that the encoding with be as a "CBOR array" and, if possible, any restrictions on the actual number of items in the array (regardless of how it gets encoded to octet-string). This is fundamentally the same idea as above, but does not require specific array type (definite vs indefinite).

2. Encoding of bit fields could be done either as an "unsigned integer" as currently specified (but without specific "additional info") or as byte-string. The one benefit of byte-string is that you guarantee a specific encoded bit-length and octet-size. I don't feel strongly either way on this, if integer is logically easier to handle then keep it as integer type.

My goal for all of this is to avoid unnecessary burden on implementation. Allow use of COTS software as much as reasonable.
Thanks,
Brian S.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Sep 2016 16:59:25 +0200

Brian Sipos wrote:
> My recommendation would be to simply do not specify specific required
> "additional info" but rather specify the qualities of the decoded values
> (e.g. maxim unsigned bit-length allowed for a value, allowed sizes of
> arrays). If there is a need for some kind of "canonical encoding" for
> these things then okay; but I don't think that a bundle which satisfies
> the spirit of the BPbis encoding but doesn't use the exact required
> octets should be treated as an invalid PDU. If using a COTS CBOR library
> to decode I don't see how you would detect that level of encoded detail
> anyway.

Indeed, the protocol definition should best be at the data model level,
not at the serialization level.

An easy way to do that is to write a CDDL specification, as I did for a
previous version of BPbis in

https://mailarchive.ietf.org/arch/msg/dtn/LVVQ9gQyXl-hrosyYYeEX6d2BQk

(At the time, I did not try to change anything in the data model -- I'd
probably use real CBOR booleans instead of FORTRAN booleans etc., but
this was just a 1:1 translation.)

Grüße, Carsten

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 13 Sep 2016 15:54:23 +0000

Hi, Brian.  I see your point, and I agree that enabling BP developers to use COTS software as much as possible is desirable.

My concern is that in some cases we are talking about using Bundle Protocol on highly resource-constrained platforms, where development cost is a less important consideration than code size and processing speed.  I am uneasy about requiring that every BP implementation include a complete implementation of all options of the CBOR specification.  From this perspective, specifying the encoding of data items in detail seems to have the advantage of minimizing the runtime cost of coding and decoding, possibly even enabling implementation in hardware.

But I will be happy to hear that my concern is unfounded.  Do we know of COTS CBOR implementations that are suitable for resource-constrained platforms, e.g., for IoT?

Scott

From: Brian Sipos [mailto:[email-masked]]
Sent: Tuesday, September 13, 2016 5:55 AM
To: Burleigh, Scott C (312B) <[email-masked]>; DTN WG <[email-masked]>
Subject: Re: version 5 of bpbis spec

Scott,

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 13 Sep 2016 19:43:41 +0200

On 13 September 2016 at 18:18:41, Burleigh, Scott C (312B) ([email-masked]) wrote:
> Do we know of COTS CBOR implementations that are suitable for resource-constrained platforms, e.g., for IoT?

As an example, CN-CBOR has a decoder that takes 822 bytes of code on an ARM platform.
This can be reduced by another 100 bytes or so by leaving out floating point.

I think it is a good idea to make some general encoding decisions (e.g., not using floating point if you don’t need that) and to communicate those in the specification.  Providing detailed instructions for the encoder makes that code more complex (and, as Brian said, can make it hard to reuse an existing implementation — which may already be on the platform to encode the application data).

Grüße, Carsten

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Tue, 13 Sep 2016 18:07:29 +0000

Okay, I’m sold.  I’ll revise the spec as proposed for the next version of the draft.

Scott

From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, September 13, 2016 10:44 AM
To: DTN WG <[email-masked]>; Brian Sipos <[email-masked]>; Burleigh, Scott C (312B) <[email-masked]>
Subject: Re: [dtn] version 5 of bpbis spec

Grüße, Carsten