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

[Marc Blanchet <[e-mail]>]

> Le 29 mai 2024 à 05:09, Rick Taylor <[e-mail]> a écrit :
> 
> Hi All,
>  
> Just top-posting a few comments re bundle identity and de-duplication (and I am most definitely not up to speed on COAP so please excuse me repeating the obvious)
>  
> In BPv7, a bundle MUST be uniquely identified by the tuple of (Sender_EID, Creation timestamp) – ignoring BP fragmentation, which I think you should at the COAP level.
>  
> This means that BPAs (routers) along the path can and may be de-duplicating bundles, so you shouldn’t expect to be doing a lot of dedup at the COAP layer, but it should be checked for nonetheless.  

Yes. Similarly, IP packets are not often duplicated but a transport must be prepared to deal if it happens, which is what IP transports do.  In case of BP,  for managing BP region routing and node mobility, Scott Burleigh mentioned a few weeks ago that the bundles have to be duplicated so that the network can learn the new topology. Therefore, it seems that within BP design, bundles will be duplicated not just by « accident ».

Regards, Marc.

>  
> However, there is no requirement of ‘maintaining bundle order’ at the BPA layer, so you will need to perform reordering at the COAP layer, but the ‘Creation timestamp’ field in the BP primary block (which should be available to a higher layer) does give you an Bundle A ‘created before’ Bundle B relationship which is likely what you need.
>  
> The Sender_EID can be required to be fixed for the length of a COAP ‘session’, as an EID is a logical communication endpoint rather than an address, and hence avoids problems such as re-homing, multi-homing, mobility, etc.
>  
> And yes, although a Creation timestamp is only 2 CBOR unsigned integers, an EID can be a fairly large CBOR object when encoded.  But it is worth remembering that although ‘native’ COAP compresses heavily to fit in small frames, a bundle can happily be a several orders of magnitude larger than 1500 octets – but I’m not sure if that helps!
>  
> And…  bundle status reports are defined as very much a debugging feature – RFC9171 states ‘disabled by default’, as they are a potential source of DDoS by reflection attacks.  Requiring status reports for COAP-over-BP feels like a mistake to me.
>  
> Just my 2 cents worth, hope it helps.
>  
> Cheers,
>  
> Rick
>  
> From: Carles Gomez Montenegro [mailto:carles.gomez=[e-mail]]
> Sent: 29 May 2024 08:46
> To: Achim Kraus
> Cc: Christian Amsüss; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>; Anna Calveras Auge
> Subject: [dtn] Re: [core] Fwd: New Version Notification for draft-gomez-core-coap-bp-00.txt
>  
> Hello Achim,
>  
> Many thanks for your feedback!
>  
> Please find below our inline responses/comments:
>  
> On Tue, 19 Mar 2024 at 13:16, Achim Kraus <[e-mail] <mailto:[e-mail]>> 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
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/core
> 
> _______________________________________________
> dtn mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>