Re: [dtn] working group last call on draft-ietf-dtn-bpbis

Lucas Kahlert <lucas.kahlert@tu-dresden.de> Mon, 06 February 2017 18:01 UTC

Return-Path: <lucas.kahlert@tu-dresden.de>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD33412946E for <dtn@ietfa.amsl.com>; Mon, 6 Feb 2017 10:01:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcoQOhTr2ZFg for <dtn@ietfa.amsl.com>; Mon, 6 Feb 2017 10:01:12 -0800 (PST)
Received: from mailout6.zih.tu-dresden.de (mailout6.zih.tu-dresden.de [141.30.67.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFE612946D for <dtn@ietf.org>; Mon, 6 Feb 2017 10:01:12 -0800 (PST)
Received: from mail.zih.tu-dresden.de ([141.76.14.4]) by mailout6.zih.tu-dresden.de with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84_2) (envelope-from <lucas.kahlert@tu-dresden.de>) id 1canbB-0000Wk-Tq for dtn@ietf.org; Mon, 06 Feb 2017 19:01:10 +0100
Received: from 77-64-188-193.dynamic.primacom.net ([77.64.188.193] helo=[192.168.1.12]) by server-40.mailclusterdns.zih.tu-dresden.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from <lucas.kahlert@tu-dresden.de>) id 1canbB-0000G9-N4 for dtn@ietf.org; Mon, 06 Feb 2017 19:01:09 +0100
To: dtn@ietf.org
References: <44B4919D-4283-4FDD-91E5-1EE5288D50AC@viagenie.ca> <CY1PR0501MB2057443811EEB5AAD0ED16A19F720@CY1PR0501MB2057.namprd05.prod.outlook.com>
From: Lucas Kahlert <lucas.kahlert@tu-dresden.de>
Message-ID: <ade49b01-4ea4-aa2f-e0db-efdac5a2c29c@tu-dresden.de>
Date: Mon, 06 Feb 2017 19:01:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CY1PR0501MB2057443811EEB5AAD0ED16A19F720@CY1PR0501MB2057.namprd05.prod.outlook.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TUD-Original-From: lucas.kahlert@tu-dresden.de
X-TUD-Virus-Scanned: mailout6.zih.tu-dresden.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/2yfYagOrhPrEVvh-10r_ZzXu6ag>
Subject: Re: [dtn] working group last call on draft-ietf-dtn-bpbis
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Feb 2017 18:01:14 -0000

Hello,

I am a student currently implementing the BPbis draft in 
[upcn](http://upcn.eu/) using the stateless callback-based streaming API 
of libcbor.


# Relocating the CRC field

As already mentioned by Brian Sipos and Marius Feldmann the position of 
the checksum should be relocated to the end of each extension block.

In the current draft it is quite tricky to calculate the CRC of an 
extension block "on-the-fly" (calculating the CRC checksum while you are 
decoding or serializing CBOR chunks). If the CRC is located at the end 
of a block (like in the primary block) you can use the CBOR encoding 
result for each field to calculate the CRC checksum and at the end of 
the block augment the CRC with appropriate zero-bytes and encode the 
checksum as CBOR.

For extension blocks the CBOR encoded data length and data must be known 
*before* it is written to the output. You have to skip the CRC-CBOR 
bytes first, store a pointer to the output buffer, proceed with the data 
length and data encoding and after that finish the CRC calculation and 
write the checksum into the stored buffer location. This makes the 
implementation rather complicated.


# Fixed-size byte-string encoding

I also would recommend a fixed-size byte-string encoding for the 
CRC-field to avoid confusion about a "compressed" checksum representation.


Regards,
Lucas

On 23.01.2017 17:11, Brian Sipos wrote:
> Scott,
>
> I have no new comments for the BPbis draft, but just want to re-state some earlier discussion:
>
> - On the checksum field position/contents, I believe that we had settled on relocating the checksum to the end of each block and to use a fixed-size byte-string encoding (to avoid ambiguities).
>
> - I had recommended to include some language in the spec about a BP agent accepting alternate, non-canonical encodings (e.g. indefinite-length vs. definite-length arrays) and then possibly canonicalize the bundle. An agent performing canonicalization would have implications for BPSEC down the road, just to keep in mind.
>
>
> ________________________________
> From: dtn <dtn-bounces@ietf.org> on behalf of Marc Blanchet <marc.blanchet@viagenie.ca>
> Sent: Friday, January 6, 2017 8:34:42 AM
> To: dtn
> Subject: [dtn] working group last call on draft-ietf-dtn-bpbis
>
> Hello,
>   following last IETF meeting in Seoul, this message is a 4 week working
> group last call on draft-ietf-dtn-bpbis, terminating on friday February
> 3rd 2017, 23h59 UTC. This wg last call is simultaneous for 2 documents,
> since the intent is to forward them together to the IESG.
>   Please send your comments to the mailing list with the subject as this
> message.
>
> Regards, Marc&Rick, dtn wg co-chairs
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
> dtn Info Page - Internet Engineering Task Force<https://www.ietf.org/mailman/listinfo/dtn>
> www.ietf.org
> "This list is for discussions related to the formation of a Delay Tolerant Networking (DTN) working group. The IRTF DTNRG research group has worked on the particular ...
>
>
>
>
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
>