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

[Achim Kraus <[e-mail]>]

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.

 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.


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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core