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

Carles Gomez Montenegro <carles.gomez@upc.edu> Wed, 29 May 2024 07:40 UTC

Return-Path: <carles.gomez@upc.edu>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4CBDC151078 for <core@ietfa.amsl.com>; Wed, 29 May 2024 00:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=upc-edu.20230601.gappssmtp.com
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 23XwCbevFSCj for <core@ietfa.amsl.com>; Wed, 29 May 2024 00:40:58 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 2C848C15109D for <core@ietf.org>; Wed, 29 May 2024 00:40:57 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-a6341cf2c99so176406166b.0 for <core@ietf.org>; Wed, 29 May 2024 00:40:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=upc-edu.20230601.gappssmtp.com; s=20230601; t=1716968456; x=1717573256; darn=ietf.org; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IytfoDLad6bHP6ZvPO+9OlVcrX7W+oDXF79dzVqZ9X8=; b=Pt6eEeLNMDCg4hRKP/yWYvXhDpQ7omKUePIqcuJWUIusTHpubZOIIIZ8y02/PmX4MU 6+jk6iF1nWYQY7Qe7N5QOhLYxBUV27+Jy7kdLcCbNmwGJADZ9IuiOmRKJSt1A/Ye1PwN VbR7xuw7xrVWMdIldwyHpFeFymAvvrlbAVhdXb7M+KLiA4JzrRj0T9SAhhQlC04x2H/T f65xuTvtUWuoJbP6WWMhSYWpgmVOiajW+D7qWngAA7bpVK6OhXp5DThlPxQ4HH5NUVZI oKHpWM8uIdPOHaMSHIo25iOnxzZ9bjqH9vpiwI/DigB5G9jhE1BunPlg8dOVFVSMcIaS kp3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716968456; x=1717573256; h=cc:to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IytfoDLad6bHP6ZvPO+9OlVcrX7W+oDXF79dzVqZ9X8=; b=J0NOPBCTCYgcmJlMbDAfdLwb6d5xMb+HUCaMihUwELHPQ66DjrAfpX9FzBpVEqzQNy 4Q+8YwlZX0NoAqJHtds4zh7H4oKBMc1zoPBWeoSsWvuxN+jZbezY+jSeDgZO5R9ephF6 mFtX4hpSBpFfB0TmKMviNYL76Xxi6FnP8Iw4E9d0e0G4dP1uXG89MoSdJ26QHlUnaAoZ FVM743EC0y2OO65rzcNQZlHgutdnMIwIyKwC2I2qnReSA5u2l26zClP+mdNIi68T6ATS 58hZIjQlI5umF/c0veLly6fSp2ASVhY7JqPYazSbC4xaszm8OXnE/USiSw7oPhXw05WV ksdg==
X-Gm-Message-State: AOJu0YzTYxr1yeD/oNA12/5XT1Uo4hwIQKjaPlOjaTI8CxB89h6n0f4b UyuFHXAN0AzEKuk2aBVv1pujvANzuQVogG2vVeoShKZ3kTQ9zv4G1GBgT6XhamPnEEAqx2QAQ+2 OVD24FTpijLgnaqtOpncSswFaoT0iTI7ccp8j3axY9uZCmB5b4Co=
X-Google-Smtp-Source: AGHT+IGXcqn54W/4Cz/AHyv3ySdxghtqesqP8jnUCYilc95Q5rXqu75RPnTqJnOroC592aCCdWscoZ1/BTWOVzcwc5k=
X-Received: by 2002:a17:906:4903:b0:a5a:2e0:93ac with SMTP id a640c23a62f3a-a62641b19f9mr958890266b.5.1716968455718; Wed, 29 May 2024 00:40:55 -0700 (PDT)
MIME-Version: 1.0
References: <170928597415.22824.8051716330073401889@ietfa.amsl.com> <CAAUO2xxnC8t6LGr=OkR5tk7pHQOrScf5ZReLnaaOzEOYA7EFqQ@mail.gmail.com> <ZfkEWrZ0EcqlAJ3K@hephaistos.amsuess.com>
In-Reply-To: <ZfkEWrZ0EcqlAJ3K@hephaistos.amsuess.com>
From: Carles Gomez Montenegro <carles.gomez@upc.edu>
Date: Wed, 29 May 2024 09:40:44 +0200
Message-ID: <CAAUO2xz_tEbyw_JAc=TRENuEGsuSPveocirZpL_EOH8W22FsCg@mail.gmail.com>
To: Christian Amsüss <christian@amsuess.com>
Content-Type: multipart/alternative; boundary="000000000000e4e052061992de5c"
Message-ID-Hash: UTBPFCYYY4QB5SUF56HKHUYN6MBXTJOK
X-Message-ID-Hash: UTBPFCYYY4QB5SUF56HKHUYN6MBXTJOK
X-MailFrom: carles.gomez@upc.edu
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-core.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: core@ietf.org, dtn@ietf.org, Anna Calveras Auge <anna.calveras@upc.edu>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Reply-To: carles.gomez@upc.edu
Subject: [core] Re: Fwd: New Version Notification for draft-gomez-core-coap-bp-00.txt
List-Id: "Constrained RESTful Environments (CoRE) Working Group list" <core.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/tzmOo6cH6bjKJVTPbRU7FLfr7O4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Owner: <mailto:core-owner@ietf.org>
List-Post: <mailto:core@ietf.org>
List-Subscribe: <mailto:core-join@ietf.org>
List-Unsubscribe: <mailto:core-leave@ietf.org>

Hello Christian,

Apologies for the delay in this response, and many thanks for your
thoughtful and detailed feedback!

Please find below our inline comments/resposes.

On Tue, 19 Mar 2024 at 04:20, Christian Amsüss <christian@amsuess.com>
wrote:

> Hello Carles, Anna,
>
> thanks for submitting this. I know it's work for you, but for me it's
> also fun catching up with time values I otherwise only know from
> recreational reading :-)
>
> A few comments from a first read:
>
> * CoAP's retransmission mechanism is based on exponential back-off to
>   avoid congestion. Does BP provide any mechanisms suitable for
>   differentiating between congestion and loss of message (which would
>   allow doing linear rather than exponential retransmits), NACKs (which
>   would allow immediate retransmission) or RTT estimates (which could
>   decrease time to completion similar to how FASOR speeds up
>   retransmission)?
>

BP offers status reports. One possible status is "Reporting node deleted
the bundle", and one possible reason is "Depleted storage", which perhaps,
in some cases, might be understood as a congestion indication.

However, RFC 9171 states that "the generation of status reports MUST be
disabled by default and enabled only when the risk of excessive network
traffic is deemed acceptable". Also, "even when the generation of status
reports is enabled, the decision on whether or not to generate a requested
status report is left to the discretion of the BPA".

Therefore, considering current specifications, we cannot rely much on
congestion indications or RTT estimates other than those taken by CoAP
itself via CON messages (or our attempt to replace a CoAP ACK -with no
payload- by a BP status report).


>
> * Unlike the round trip time related parameters (which clearly need
>   higher values in interplanetary scenarios) 128 seconds from Observe
>   are related to the time by which a messager might be delayed relative
>   to another message.
>
>   As (to my little knowledge stemmming from reading this document) BP
>   will not retransmit on its own, can such reorderings happen? Or can
>   there be multipath routing (where path RTT differences would exceed
>   128 seconds)?
>

BP itself does not enforce a particular bundle routing solution. The
dynamic nature of the contacts between bundle nodes may produce reordering
(potentially exceeding the aforementioned 128 seconds).


>
> * Message IDs are mainly used for request deduplication, and to match
>   empty ACKs to requests. Are there identifiers inside BP that are
>   available to higher layers that they can use and refer to? (If so, an
>   original message could do without a message ID, a retransmission could
>   refer to the original bundle, and an ACK might just use the status
>   report).
>
>
There were some responses about this point, and you wrote a subsequent
message on it. I will later answer to that one.


> * Increasing the message ID size and timeouts also means that servers
>   that do request deduplication may need to store quite many requests.

  It may make sense to emphasize that the use of idempotent servers can
>   become necessary here.
>

Agreed!


>
>   Relatedly, OSCORE's default replay window is 32 messages, and unlike
>   for DTLS one can't unilaterally pick a larger one. I don't know if and
>   whether you plan on setting up OSCORE contexts, but that setup process
>   should include an explicit field to advertise a larger replay window.
>   (To my knowledge, everyone so far was happy with the default, and
>   never specified a way to increase the window).
>
> In order to provide security for CoAP over BP, there are probably two main
approaches: i) using BP-level security (BPSec), and ii) using CoAP-level
security (with OSCORE).

We don't have security content in the draft yet (currently, still -00), but
assuming that OSCORE is used, then the security context establishment may
need to support announcing a different replay window size, as you suggest.


> * RFC 7959 allows parallel transmissions of blocks, and the emphasis on
>   CON is merely a recommendation (which users document have good reason
>   to not follow) -- no need to go stop-and-wait there. RFC9177 has a
>   very limited applicability scope for its Q-Block. The content format
>   it describes for describing multiple missing blocks is just as
>   applicable to regular block-wise.
>

Well, we understand that if CON messages are used, even if in parallel, the
receiver would still transmit one ACK for each received block.

And, without RFC 9177, if NON messages are used, there is no way to recover
a missing block.

RFC 9177 naturally addresses these issues efficiently. While its original
applicability use case might be narrow, we understand that it has
significant potential in any general scenario where the packet loss
probability is significant and/or round trip time is large.


>
> * What is the shape of the endpoint_ID? Might be a tad hard to pack
>   URI-shaped identifiers into the authority component, but the upside is
>   that we may not need another scheme. Let's talk more after tomorrow's
>   presentations, where this will be a topic of mine anyway.
>
>
We are already working on updating Section 8 (among others, removing the
"+bp" from the URI scheme), based on the guidance in Section 6 of
draft-ietf-core-transport-indication-05 (which is very useful, thanks!). We
plan to include the updated content in this regard in the upcoming -01.

Once again, many thanks for your comments!

Best regards,

Carles and Anna


> Best regards
> Christian
>
> --
> We are dreamers, shapers, singers, and makers.
>   -- Elric
>