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

Carles Gomez Montenegro <carles.gomez@upc.edu> Mon, 08 January 2024 12:12 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 5FE4AC14F6B9 for <core@ietfa.amsl.com>; Mon, 8 Jan 2024 04:12:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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
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 FV20lbNUho32 for <core@ietfa.amsl.com>; Mon, 8 Jan 2024 04:12:53 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 4BD11C14F5F2 for <core@ietf.org>; Mon, 8 Jan 2024 04:12:52 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-40e4582ed74so10554535e9.1 for <core@ietf.org>; Mon, 08 Jan 2024 04:12:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=upc-edu.20230601.gappssmtp.com; s=20230601; t=1704715971; x=1705320771; darn=ietf.org; h=content-transfer-encoding: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=opSHbuFUBHQT1VyptZAre6GC264AqzgqmJsi+vPDWfI=; b=qy2kWaP+M9nt+RqyHHk6Nw36fDfi5FqbyvDVmdSw6acwH5VY2J/YnYxnqoKTsy1uCq DWqc5d4CbAAcmwHZkQSDPMX9tH+Rm7Bbn3sBY6zExicAPaq6KXhFhPNWvOnR9YuUYlfw iLwWv3XBMLpa6dBZDn9x4o4GE6EICRq9+YJT/ob3IN7U+aFf54Qvkk7t6TgsR5WMuTTB gppSwC4oeFpDbzGDYhY3mwcH15dw+mtQjzOBeCtqv8g+JRw7t6ijnl74xmPZGX4Kb6FB LK+G5C7sNrba1dSRVIvYekwVcz3yMRJ9IOIkxwHwuwfcjMA7ZRuakjnenFfqEKDgE1O7 NtGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704715971; x=1705320771; h=content-transfer-encoding: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=opSHbuFUBHQT1VyptZAre6GC264AqzgqmJsi+vPDWfI=; b=ApBWl/ppWVxBy/7mmMmzx/+LgqGlL/PtSmE4JuvY1BUdDygMyQBYCXAgMIhUgbCe7Y 0+W/cjxZfc1BC7fCSTEEOAbIAjQvNJ5wjCuUYZSa3xBrLRk0Op9Fr0PghrjAzOsglzdj LeqpbnWfutN9bx402NAQXNNMvBgJccibSedwK+JUJlgnUNsRM7asAFsD2CSBLmJ7a74Y 3sckt4WcrGlk91gxCjtpV6eJepm4w9EEoJr5vF8yIScjUKihUQZId4lvix1ikzO+iArk UlrNfVmwF2DkuF5RXEqdAXCDkW5jneyBnWSGzSKIIovPGQnY2NycwxEp1GTXjOh/lxSU yHAA==
X-Gm-Message-State: AOJu0YzLDv/GN65AIlctK0l5X3PvSE9hNegNgn3f2gjWktHrArKiBzqk zfi4nqsnWMQL06qgEYZjG0kp7t7Z3g0xxR6Nx3dCSqU9goUTSk3QvDbd9GQBjwc=
X-Google-Smtp-Source: AGHT+IGtx4LBrpj2rqI0GUjwNhnjtT2iHnZQPnRLcRan8Ql4tFaU01RIA+pqLdL+snrh+1F8z61CWR826zHxRLG/VwE=
X-Received: by 2002:a1c:7202:0:b0:40e:35dc:675f with SMTP id n2-20020a1c7202000000b0040e35dc675fmr980683wmc.219.1704715970850; Mon, 08 Jan 2024 04:12:50 -0800 (PST)
MIME-Version: 1.0
References: <170305483701.55313.10459564268148308635@ietfa.amsl.com> <CAAUO2xyqRj_hcD=SvC+5J_Tp=Cr7vD-cw-eiS2246qw_GJGuNg@mail.gmail.com> <ZYQHihJ7yGgXum_D@hephaistos.amsuess.com>
In-Reply-To: <ZYQHihJ7yGgXum_D@hephaistos.amsuess.com>
Reply-To: carles.gomez@upc.edu
From: Carles Gomez Montenegro <carles.gomez@upc.edu>
Date: Mon, 08 Jan 2024 13:12:40 +0100
Message-ID: <CAAUO2xz17253X22LEAUKxuk_CkdRzdTXg6vRn5zzpYCY2xac_w@mail.gmail.com>
To: Christian Amsüss <christian@amsuess.com>
Cc: core@ietf.org, deepspace@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/hIhTW77yZQ1eAkVnrZnPFfUhnJ4>
Subject: Re: [core] Fwd: New Version Notification for draft-gomez-core-coap-space-00.txt
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Jan 2024 12:12:54 -0000

Hello Christian,

(Apologies for the late response... And taking the liberty of CC'ing
the deepspace ML, even if just as "FYI".)

Thanks a lot for such detailed and interesting feedback!

It is encouraging to know that there has been already discussion on
FEC for CoAP.
Indeed, in addition to existing (terrestrial) use cases, deep space
may further contribute an additional incentive to materialize related
ideas into actual proposals (I-Ds).

Cheers,

Carles


On Thu, 21 Dec 2023 at 10:38, Christian Amsüss <christian@amsuess.com> wrote:
>
> Hello Carles,
> hello CoRE,
> (deepspace@ removed b/c this is more CoAP technical)
>
> On Wed, Dec 20, 2023 at 07:54:59AM +0100, Carles Gomez Montenegro wrote:
> > no proposal has been made to add support of Forward Error Correction
> > (FEC) to CoAP.
>
> There has been some discussion in hallway meetings and in the RIOT
> community chats on FEC for block-wise transfer (which have indeed not
> resulted in any written down proposals). This would not only be
> applicable to deep space, but also to terrestrial multicast channels
> when used for firmware updates.
>
> Discussion there was mainly focused on regular and not Q-Blocks, because
> the latter have a very tight set of constraints for their applicability,
> and because mechanisms introduced there (eg. the
> application/missing-blocks+cbor-seq type) can just as well be applied to
> regular block-wise transfer.
>
> One aspect that was discussed there was the choice of transmission
> sequence and sharding, where memory and code complexity requirements are
> traded against robustness of the protocol. Another trade-off to be
> considered is fast forwarding: For the applications that have been
> discussed previously, relaying through a proxy was highly relevant, and
> that proxy can not only terminate retransmissions, but also participate
> in FEC. If the proxy can not spool the whole resource, a wider spread of
> FEC (which is desirable for robustness) leads to the proxy being unable
> to participate in FEC. (As a complete space layperson, I imagine that
> such a proxy would be highly capable though, and could easily do all FEC
> recovery -- images of space stations receiving transmissions and
> forwarding them to ground stations once they pass over them comes to
> mind).
>
> BR
> Christian
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater powers.
>   -- Bene Gesserit axiom