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

[Rick Taylor <[e-mail]>]

Hi Christian,

In BPv7 bundles are (mostly uniquely) identified by the tuple of (Source EID, Timestamp) both in the primary block:

>From Section 4.3.1 of RFC9171:

"The creation timestamp comprises two unsigned integers that, together with the source node ID and (if the bundle is a fragment) the fragment offset and payload length, serve to identify the bundle. See Section 4.2.7 for the definition of this field."

Cheers,

Rick

> -----Original Message-----
> From: dtn [mailto:[e-mail]] On Behalf Of Christian Amsüss
> Sent: 19 March 2024 03:20
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; Anna Calveras Auge
> Subject: Re: [dtn] [core] Fwd: New Version Notification for draft-gomez-core-
> coap-bp-00.txt
> 
> 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
> 
> --
> We are dreamers, shapers, singers, and makers.
>   -- Elric