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

[Christian Amsüss <[e-mail]>]

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