IETF Logo Mail Archive

Re: [dtn] [core] Fwd: New Version Notification for draft-gomez-core-coap-bp-00.txt

Christian Amsüss <christian@amsuess.com> Tue, 19 March 2024 11:32 UTC

Return-Path: <christian@amsuess.com>
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 392D9C14F6B1; Tue, 19 Mar 2024 04:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF4UwGxoV4BN; Tue, 19 Mar 2024 04:32:25 -0700 (PDT)
Received: from smtp.akis.at (smtp.akis.at [IPv6:2a02:b18:500:a515::f455]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089DAC14F601; Tue, 19 Mar 2024 04:32:21 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by smtp.akis.at (8.17.2/8.17.2) with ESMTPS id 42JBWHWo038380 (version=TLSv1.2 cipher=ECDHE-ECDSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 19 Mar 2024 12:32:17 +0100 (CET) (envelope-from christian@amsuess.com)
X-Authentication-Warning: smtp.akis.at: Host 095129206250.cust.akis.net [95.129.206.250] claimed to be poseidon-mailhub.amsuess.com
Received: from poseidon-mailbox.amsuess.com (hermes.lan [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 0C5A635DB2; Tue, 19 Mar 2024 12:32:17 +0100 (CET)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:bfbd:e9f4:2c0a:95da]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BA298324AC; Tue, 19 Mar 2024 12:32:16 +0100 (CET)
Received: (nullmailer pid 18882 invoked by uid 1000); Tue, 19 Mar 2024 11:32:16 -0000
Date: Tue, 19 Mar 2024 21:32:16 +1000
From: Christian Amsüss <christian@amsuess.com>
To: Rick Taylor <rick@tropicalstormsoftware.com>
Cc: "carles.gomez@upc.edu" <carles.gomez@upc.edu>, "core@ietf.org" <core@ietf.org>, "dtn@ietf.org" <dtn@ietf.org>, Anna Calveras Auge <anna.calveras@upc.edu>
Message-ID: <Zfl3wDDPW_H9Kj_q@hephaistos.amsuess.com>
References: <170928597415.22824.8051716330073401889@ietfa.amsl.com> <CAAUO2xxnC8t6LGr=OkR5tk7pHQOrScf5ZReLnaaOzEOYA7EFqQ@mail.gmail.com> <ZfkEWrZ0EcqlAJ3K@hephaistos.amsuess.com> <38A5475DE83986499AEACD2CFAFC3F9802736E1F11@tss-server1.home.tropicalstormsoftware.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="aqYEZC9pXCa5OjY2"
Content-Disposition: inline
In-Reply-To: <38A5475DE83986499AEACD2CFAFC3F9802736E1F11@tss-server1.home.tropicalstormsoftware.com>
X-Scanned-By: MIMEDefang 2.86
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/LlLG_DRO8e12gl405Y_pTCFyiJE>
Subject: Re: [dtn] [core] Fwd: New Version Notification for draft-gomez-core-coap-bp-00.txt
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 19 Mar 2024 11:32:28 -0000

On Tue, Mar 19, 2024 at 07:59:15AM +0000, Rick Taylor wrote:
> In BPv7 bundles are (mostly uniquely) identified by the tuple of
> (Source EID, Timestamp) both in the primary block:

Hm, even if we can assume that the Source EID is constant across
retransmissions (we likely can) and the transmission timestamp is made
available to the application after transmission (is it?), and even if we
could know the current bundle's timestamp in advance (likely not), even
a delta compressed version of that in CBOR soon exceeds the 24bit of the
extended MID -- and thus, it's not only more complex than sticking with
MIDs, it's also larger.

Using the presence of the send time stamp (independent of the MID
considerations) should make Observe easier to handle, though:
Notifications in NONs might be implicitly ordered by their send time
stamps; not sure whether we have anything in our toolkit already to help
with CON notifications.

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

v2.23.0 | Report a Bug | By Email