IETF Logo Mail Archive

Re: [dtn] (no subject)

"Burleigh, Scott C (312B)" <Scott.C.Burleigh@jpl.nasa.gov> Mon, 14 January 2019 20:21 UTC

Return-Path: <Scott.C.Burleigh@jpl.nasa.gov>
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 950CA131023 for <dtn@ietfa.amsl.com>; Mon, 14 Jan 2019 12:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.553
X-Spam-Level:
X-Spam-Status: No, score=-6.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=jpl.nasa.gov
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 F0zdnhQY1wDf for <dtn@ietfa.amsl.com>; Mon, 14 Jan 2019 12:21:13 -0800 (PST)
Received: from ppa02.jpl.nasa.gov (ppa02.jpl.nasa.gov [128.149.137.113]) (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 9D05C127B4C for <dtn@ietf.org>; Mon, 14 Jan 2019 12:21:13 -0800 (PST)
Received: from pps.filterd (ppa02.jpl.nasa.gov [127.0.0.1]) by ppa02.jpl.nasa.gov (8.16.0.21/8.16.0.21) with SMTP id x0EKEaBE155630; Mon, 14 Jan 2019 12:21:12 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=jpl.nasa.gov; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=JPL1810; bh=QRLSGwl8KkLxVmg+CV9Wl4oE+TGWurOV4KWzXwIBOTY=; b=jCy2RGd3AiO1KdGg1AP6f4PBMfpWFkkDpegcsTsbBM6Bdc4y0AuFHbrxHoA+QYfbFP4T riQERgZKN9KTkyDmiXElQjb7AYxDgm/7oynv4CLXOVliVePr/FjMdcytE0cQN7hSiKox 3q0TbVTVQzW+FMIjcRYZmDgPzX3qr0YuxQR+2NteTvhOxm9EcElc9w4uMSv5obTGqTN6 aOtEsJRkGZEooxlQnd91nzqgr1jh6bttGrVHSkeAW4SLuGv6AYqvTrjbWnRX4gzK7jJ8 wAslN3VwC/3Rb2d+N+pLb9fC5ZCBnkt8nfxXjPQCOIVGlxRJsC+doN2JK4cwNhfnsxp7 6Q==
Received: from mail.jpl.nasa.gov (altphysenclup03.jpl.nasa.gov [128.149.137.120]) by ppa02.jpl.nasa.gov with ESMTP id 2pyga35ea4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 Jan 2019 12:21:12 -0800
Received: from mail.jpl.nasa.gov (ap-embx16-sp20.jpl.nasa.gov [128.149.137.84]) by smtp.jpl.nasa.gov (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id x0EKLB4d024464 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128 bits) verified OK); Mon, 14 Jan 2019 12:21:11 -0800
Received: from ap-embx16-sp10.RES.AD.JPL (2002:8095:8953::8095:8953) by ap-embx16-sp20.RES.AD.JPL (2002:8095:8954::8095:8954) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1531.3; Mon, 14 Jan 2019 12:21:11 -0800
Received: from ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b]) by ap-embx16-sp10.RES.AD.JPL ([fe80::4:f430:47b5:767b%17]) with mapi id 15.01.1531.008; Mon, 14 Jan 2019 12:21:11 -0800
From: "Burleigh, Scott C (312B)" <Scott.C.Burleigh@jpl.nasa.gov>
To: Felix Walter <felix.walter@tu-dresden.de>, "dtn@ietf.org" <dtn@ietf.org>
Thread-Topic: [dtn] (no subject)
Thread-Index: AQHUqqMOzmtVNB7RO0adAKWEio6CrKWvBn8AgAAucRA=
Date: Mon, 14 Jan 2019 20:21:11 +0000
Message-ID: <27ec081ddc454104b7a56d59f05661cd@jpl.nasa.gov>
References: <CANoKrvZZhzcPXupNTtup8rjJyWA0LevVRwqmn8qijJ3qn4dLEg@mail.gmail.com> <a37dca09-a4ca-052c-8234-3dc0abf649e8@tu-dresden.de>
In-Reply-To: <a37dca09-a4ca-052c-8234-3dc0abf649e8@tu-dresden.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [207.151.104.72]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Source-IP: ap-embx16-sp20.jpl.nasa.gov [128.149.137.84]
X-Source-Sender: Scott.C.Burleigh@jpl.nasa.gov
X-AUTH: Authorized
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-14_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901140156
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/tpjkZu0AkbV5GfnIdAJyVmoMyME>
Subject: Re: [dtn] (no subject)
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.29
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, 14 Jan 2019 20:21:16 -0000

Sure, we can change the 5th bullet of 4.2.3 to say "Block-type-specific data represented as a single definite-length CBOR byte string, i.e., a CBOR byte string that is not of indefinite length."

Scott

-----Original Message-----
From: dtn <dtn-bounces@ietf.org> On Behalf Of Felix Walter
Sent: Monday, January 14, 2019 1:24 AM
To: dtn@ietf.org
Subject: Re: [dtn] (no subject)

Hi Lucien,

Good point! I actually suggested this change at some point, not only because a second length value is redundant, but also because it leads to problems if you want to serialize a bundle as a stream using a CBOR library - the first length value depends on the encoding of the length inside the byte string header. Thus, you have to serialize the byte string separately and then concatenate it with the length plus the rest of the serialized bundle, either resulting in a lot of code handling this special case or significant memory overhead.

I don't see good use cases for the CBOR indefinite-length byte strings in a serialized bundle. It would rather lead to a lot of problems with parsing bundles as you mentioned.

@Scott: Couldn't we simply forbid the use of that representation for the block payload?

Felix


Am 12.01.19 um 19:16 schrieb Loiseau lucien:
> Hi,
>
> I noticed that since bpbis-10, the block data length was removed from 
> the Canonical Block Header, I imagine to reuse the length given as a 
> header of the CBOR byte string that constitutes the payload of the 
> block.
>
> However CBOR encoding authorizes a byte string to be "indefinite" so 
> that the cbor header would be -1 and then follows a series of byte 
> chunk with definite size. In that case, it may be impossible to 
> allocate memory for the whole payload, instead we would have to 
> readjust buffer as chunks are coming in. Another limitation with a 
> payload encoded as an indefinite cbor byte string is that it would be 
> impossible to refuse a large bundle until we fully decoded it or hit 
> the limit.
>
> Best Regards,
> Lucien
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn


_______________________________________________
dtn mailing list
dtn@ietf.org
https://www.ietf.org/mailman/listinfo/dtn

v2.23.0 | Report a Bug | By Email