[dtn] "Block data length" field in BPbis

Felix Walter <felix.walter@tu-dresden.de> Fri, 23 March 2018 16:22 UTC

Return-Path: <felix.walter@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 74BA412DA09 for <dtn@ietfa.amsl.com>; Fri, 23 Mar 2018 09:22:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 5OyvEM957CTG for <dtn@ietfa.amsl.com>; Fri, 23 Mar 2018 09:22:26 -0700 (PDT)
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 B4D7112D96B for <dtn@ietf.org>; Fri, 23 Mar 2018 09:22:26 -0700 (PDT)
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 <felix.walter@tu-dresden.de>) id 1ezPSR-0004qC-GB for dtn@ietf.org; Fri, 23 Mar 2018 17:22:24 +0100
Received: from [141.30.247.101] by server-40.mailclusterdns.zih.tu-dresden.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (envelope-from <felix.walter@tu-dresden.de>) id 1ezPSR-0006c4-53 for dtn@ietf.org; Fri, 23 Mar 2018 17:22:23 +0100
From: Felix Walter <felix.walter@tu-dresden.de>
Organization: Technische Universität Dresden
To: dtn@ietf.org
Message-ID: <ce643b57-1765-c189-0c2d-5fbe5f573548@tu-dresden.de>
Date: Fri, 23 Mar 2018 17:22:22 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-TUD-Original-From: felix.walter@tu-dresden.de
X-TUD-Virus-Scanned: mailout6.zih.tu-dresden.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/QseT8KqA7AVUotfq8v_ME0FtUZI>
Subject: [dtn] "Block data length" field in BPbis
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 23 Mar 2018 16:22:29 -0000

Hi,

We just had a short talk with Scott, Ed, and Rick about the "Block data
length" [1] field of the canonical block in BPbis that I would like to
forward to the list. As far as I understand it, this value is the count
of (serialized) bytes still belonging to the block, but following the
length field.

Because CBOR is used for the block-type-specific data, the length field
by itself is redundant. For example, in the payload block, it will
always be followed by a "CBOR byte string" representing the payload
data. (This contains a length as well.)
It needs to be considered in implementations that all these length
fields are variable-length themselves - however, this turned out to be
no big issue. I also see the point of having the "Block data length"
available to the parser, to be able to skip over the whole block data of
complex extension blocks without even parsing them.

Are there any further reasons for having the "Block data length"
available which I have missed? Or does anyone have a strong opinion on
whether this should be removed or kept?

By the way, the language concerning the "Block data length" should
probably be modified slightly as it refers to "[...] the aggregate
length of all remaining fields of the block, i.e., the
block-type-specific data fields.", though, this may (now) be followed by
the CRC checksum.

Felix

[1] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-10#section-4.2.3