Subject: [dtn] new BPbis spec

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Thu, 22 Jun 2017 22:34:05 +0000

Hi.  I just posted an updated BPbis specification that I think addresses nearly all of the comments on which we reached consensus, either over email or at IETF 98.  The one exception I can think of is the request to add references to formal definitions for CRC-16-ANSI and CRC-32, which I omitted because on a quick search I wasn't able to find any; if anyone knows where those definitions live, please speak up.

I think we may have two quite different approaches on the table for defining custody transfer outside of the BP specification.  I will be posting one of them in a few minutes and hope to post the other sometime tomorrow.

Scott

---

From: Lucas Kahlert <[email-masked]>
Date: Fri, 30 Jun 2017 14:10:32 +0200

Hello Mr. Burleigh,

I am the student who implemented BP-bis-07 in [µPCN]. There were some 
requests to move the CRC field of Canonical Bundle Blocks to the end of 
the block -- after the block-specific data fields. This change would 
make incremental processing (parsing and serializing) of the CBOR 
structure easier.

Is there any specific reason that the CRC field is still positioned 
after the CRC type field?

Here is a short recap of the matter:

If a bundle is incrementally serialized each Bundle field is encoded 
into its CBOR item and written immediately to the output to have a 
minimal memory footprint during serialization.

The problem with the current position of the CRC field is that the 
CBOR-encoded version of the block's data field must be known when the 
CRC field for the canonical block is calculated. This can be achieved by:

a) Encode the payload into CBOR and keep it in memory (possibly huge 
memory footprint!)

b) Encode the payload into CBOR twice: first to update the CRC checksum, 
secondly for writing to output

I think both approaches are not optimal.

If the CRC field is at the end of a block the CRC checksum can be 
calculated "on-the-fly" meaning that the checksum is updated for each 
byte written to the output. There is no need to iterate over the whole 
binary CBOR structure again.

Regrads,
Lucas

[µPCN]: http://upcn.eu/

On 23.06.2017 00:34, Burleigh, Scott C (312B) wrote:
> Hi.  I just posted an updated BPbis specification that I think addresses 
> nearly all of the comments on which we reached consensus, either over 
> email or at IETF 98.  The one exception I can think of is the request to 
> add references to formal definitions for CRC-16-ANSI and CRC-32, which I 
> omitted because on a quick search I wasn’t able to find any; if anyone 
> knows where those definitions live, please speak up.
> 
> I think we may have two quite different approaches on the table for 
> defining custody transfer outside of the BP specification.  I will be 
> posting one of them in a few minutes and hope to post the other sometime 
> tomorrow.
> 
> Scott
> 
> 
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
>

---

From: Brian Sipos <[email-masked]>
Date: Fri, 30 Jun 2017 13:03:02 +0000

Scott,

I had recommended to cite specifics for the CRC behaviors. There seems to be a good informative list at <http://reveng.sourceforge.net/crc-catalogue/all.htm> which indicates that:

For the CRC-32 behavior, a good citation is ITU-T V.42-2002 "Error-correcting procedures for DCEs using asynchronous-to-synchronous conversion".

For the CRC-16-ANSI behavior, a good citation may be the original ANSI X3.28 though I'm having a difficult time trying to track the thing down. Is there any particular reason why this variant of CRC-16 was chosen over a more... easily-cited variation such as CRC-16-CCITT (X.25) as used by, for example, RFC 1331.

________________________________
From: dtn <[email-masked]> on behalf of Burleigh, Scott C (312B) <[email-masked]>
Sent: Thursday, June 22, 2017 6:34:05 PM
To: [email-masked]
Subject: [dtn] new BPbis spec

Hi.  I just posted an updated BPbis specification that I think addresses nearly all of the comments on which we reached consensus, either over email or at IETF 98.  The one exception I can think of is the request to add references to formal definitions for CRC-16-ANSI and CRC-32, which I omitted because on a quick search I wasn’t able to find any; if anyone knows where those definitions live, please speak up.

Scott

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 30 Jun 2017 20:31:05 +0000

Thanks for the CRC-32 reference, Brian, and I am fine with switching to a more easily cited CRC-16 if the WG agrees.

Scott
________________________________
From: Brian Sipos [[email-masked]]
Sent: Friday, June 30, 2017 6:03 AM
To: Burleigh, Scott C (312B); [email-masked]
Subject: Re: new BPbis spec

Scott,

Scott

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 30 Jun 2017 20:38:03 +0000

Sorry, Lucas, that was just an oversight.  I saw that the CRC was at the end of the Primary Block, and I simply neglected to make the same change to the Canonical Block.

Scott
________________________________________
From: dtn [[email-masked]] on behalf of Lucas Kahlert [[email-masked]]
Sent: Friday, June 30, 2017 5:10 AM
To: [email-masked]
Subject: Re: [dtn] new BPbis spec

Hello Mr. Burleigh,

Regrads,
Lucas

[µPCN]: http://upcn.eu/