[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:46 UTC

Return-Path: <carles.gomez@upc.edu>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4E19DC14CE39 for <core@ietfa.amsl.com>; Wed, 29 May 2024 00:46:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.896
X-Spam-Status: No, score=-6.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id E5KKArh1ktAX for <core@ietfa.amsl.com>; Wed, 29 May 2024 00:45:57 -0700 (PDT)
Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 097BDC14CE51 for <core@ietf.org>; Wed, 29 May 2024 00:45:57 -0700 (PDT)
Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-a6268034cf8so78040766b.3 for <core@ietf.org>; Wed, 29 May 2024 00:45:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=upc-edu.20230601.gappssmtp.com; s=20230601; t=1716968755; x=1717573555; 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=0L7OeC+YnmPh20XjiKfJOUwYR6OKG6tx+afJPZlWC1Q=; b=1x5zIpxBd8kDmmvtmFeyz2DkpCrjZV9NF3sV4bPnacL0FbILTJGeL2tiO6W2tYFIlk wrYK9oTxBKg0D/5MAnx75sStZxGPObxY5+qoYJAS3+AcxCQpMzDKyZIVkvXojoupHhdA VLynVS5tKHv+u1ajhdAb8KCKpbDbBkuZ6+fe7srS3ykyn/H8Scjx+VmJ92qtLkL273Wb 4XClve4GhleUKUbb7aX6uBAdWqx69S8Pvi+yJ/HBAdBE5TkFnZhBTgg37fPx973kAVX3 CNx3tLrBLMmZsjQvm9kVoAjgQLcbMnB4FWk5qxi6eBcGkil25x5T3WnmbOD5Xa/NIEP7 W3Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1716968755; x=1717573555; 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=0L7OeC+YnmPh20XjiKfJOUwYR6OKG6tx+afJPZlWC1Q=; b=d1Y+qDne/v9spKC0giyJ5A0NpE19LqxCBoMwaEsH3hhnwoPxwNeKcvRLmWF0aRRVjz pJWNVEZiHYqfFMHnSu6nGZMHqQ36uYNf7OFV09uobKKYG9MhTfbI7+R/pFz2XxQ+aNzf WhepynJSD37WJmj8s1V9hCp1A4UNDqB86O6wUaUX5ingfOn5myz0gqFV0RexvsFhKVMA bw+wuAaIJrb/85fajrPPAM73petW+w4mGZVqV2Yt39NH4lOkoOHWZM0Jl4cCz/+LBsA2 uDuFKgMWP/j5yrVO6TXajK+qkBdD9rEuJnLk8AEdCCCzTG0dgi5FRpoZ5QM4bCj94ted sPZw==
X-Forwarded-Encrypted: i=1; AJvYcCVfZAda+TM/xePnacEHzVlj+iWskaCC4xsXr4xmbd+WRbA+7v0X32x1Z/RcCFfnq7Wy/5owxjBB3q41GGU2
X-Gm-Message-State: AOJu0Yzsgw8UvFdVEJCuStSrSyFlyJr60ZUqLM7VVxbx5IdNOYkyNZ98 6R1/b0LBl9su5coghdSYNtOo7l/AJdFo9Iikw378lkFla+x7My1LqXeEpWVORVJimVkek3r1fiE iPf9yhgT/SQFe5BEywzxXUB+o2xop4AvHaCuU4w==
X-Google-Smtp-Source: AGHT+IEOGGOChPRO81I1Ht0uC7IjgCz7wFjBd/VVSl91OAleyHVaUyWsb63Ro86WGIT2ITu9WH7OW9QxpQ6aEEAiiB8=
X-Received: by 2002:a50:c907:0:b0:572:689f:6380 with SMTP id 4fb4d7f45d1cf-578519144e9mr11731813a12.3.1716968755312; Wed, 29 May 2024 00:45:55 -0700 (PDT)
MIME-Version: 1.0
References: <170928597415.22824.8051716330073401889@ietfa.amsl.com> <CAAUO2xxnC8t6LGr=OkR5tk7pHQOrScf5ZReLnaaOzEOYA7EFqQ@mail.gmail.com> <ZfkEWrZ0EcqlAJ3K@hephaistos.amsuess.com> <517a3ccc-8f64-49ca-b8a8-ca9f83c7333a@gmx.net>
In-Reply-To: <517a3ccc-8f64-49ca-b8a8-ca9f83c7333a@gmx.net>
From: Carles Gomez Montenegro <carles.gomez@upc.edu>
Date: Wed, 29 May 2024 09:45:43 +0200
Message-ID: <CAAUO2xw+940p6BmLC6KBKEJvJNxE4KKAX4kzR7ZbD2+a1i5Bxg@mail.gmail.com>
To: Achim Kraus <achimkraus@gmx.net>
Content-Type: multipart/alternative; boundary="000000000000c04ea6061992f0ed"
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: Christian Amsüss <christian@amsuess.com>, 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/lw3V2WKW6g0ahbq0qbetBjhfHhE>
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 Achim,

Many thanks for your feedback!

Please find below our inline responses/comments:

On Tue, 19 Mar 2024 at 13:16, Achim Kraus <achimkraus@gmx.net> wrote:

> Hello Carles, Anna, Christian,
> from draft-gomez-core-coap-bp-00:
>  > TO-DO: MAX_PAYLOADS for deep space?
> I was able to make some experience with a global geostationary satellite
> NB-IoT network (NTN) early February this year (2024). I was using
> Eclipse/Californium with CoAP/DTLS 1.2 CID on both sides, server and
> device. The main issue was relaxing the transmission timeouts to about
> 30s. That's twice the RTT of my own experience.
> I have access to "Skylo Device Conformance Document." from
> (https://www.skylo.tech/) It's AFAIK it's not public, but got the
> permission to cite this section:
> "Data Usage Policy and Best Practices
> The Skylo network is designed with IoT data rates in mind. This is
> reflected in our network policies and associated data plans. Please
> ensure you have the correct data plan associated with your SIM.
> Satellite transmission packet size and frequency should adhere to the
> following best practices:
> - The maximum packet size for each transmission is 256 bytes.
> - The minimum time between successive packets should greater than 30
> seconds
> ...
> Depending on the data plan associated with a device and solution,
> real-time messaging and/or alerting may be supported. As a best
> practice when designing and implementing a solution that includes real
> time messaging and/or alerting, be sure application logic can
> accommodate standard message 1-way latency of up to 30 seconds."
> The 256 bytes includes all headers, in my case starting with the
> IP-header. It's not that deep as inter-planet communication, but I would
> not expect to have better numbers when communicating with Mars.

Thanks, the details of the above mentioned data plan are very interesting.

>  From Christian's comment:
>  > * Increasing the message ID size and timeouts also means that servers
>  >    that do request deduplication may need to store quite many requests.
>  From draft-gomez-core-coap-bp-00:
>  > avoiding a severe limitation on the number of messages
> FMPOV, the "ultra-long-range-communication" does not only come
> with high latency, it also limits the amount of data. Therefore
> I hardly see, that a 16 bit MID will expire.
While some typical bit rates used in (deep) space are relatively low (in
the order of Mbit/s), greater bit rates (up to Gbit/s) have been reported,
and might also be more typical in the future.

One option might be not modifying the MID size (i.e., 16 bits). However,
RFC 7252 would imply that, in some cases (e.g., Jupiter to Earth, for
MAX_RETRANSMIT=1) the maximum average message rate would decrease from the
current ~265 message/s down to ~3 message/s. Perhaps the latter could be
enough. Or perhaps a more future-proof approach could aim to avoid a
limitation on the maximum message rate. But of course, the downsides of
increasing the MID size (such as those mentioned by Christian) need to be
taken into account as well.

Once again, many thanks for your feedback!

Best regards,

Carles and Anna

> best regards
> Achim
> Am 19.03.24 um 04:19 schrieb Christian Amsüss:
> > 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)?
> >
> > * 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)?
> >
> > * 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).
> >
> > * 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.
> >
> >    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).
> >
> > * 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.
> >
> > * 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.
> >
> > Best regards
> > Christian
> >
> >
> > _______________________________________________
> > core mailing list
> > core@ietf.org
> > https://www.ietf.org/mailman/listinfo/core