Re: [dtn] [External] Concept of BP conversations and ephemeral services

["Ostermann, Shawn" <[e-mail]>]

I think that suggestion makes good sense. It would probably be many years before there were “a lot” of DTN applications, but it makes sense to me to borrow the ideas from TCP/IP that worked well in practice (like well-known vs. random (in an isolated range) ports).

Shawn


> On Apr 13, 2023, at 10:21 AM, Sipos, Brian J. <[e-mail]> wrote:
> 
> Use caution with links and attachments.
> All,
> Now that we are getting into discussions of codifying BP application protocols (e.g. Marc’s proposals for SNMP/BP and HTTP/BP, the DTN management protocol, etc.) there is a need to codify what is required, allowed, and not allowed regarding what some protocols and tools would call a “conversation” which means a multi-datagram sequence between two endpoints. My suggestion for how BP can handle this is to simply swap the Source and Destination EID as a way to participate in a conversation. This is terribly simple but does impose constraints on the application-side API for a BPA, which is that an application has some visibility into a received bundle’s source and destination EID (in the same way that POSIX socket API allows `bind`, `recvfrom`, and `sendto` to identify port number).
> 
> This is equivalent to how TCP, SCTP, and DCCP operate but because the BP EIDs are names and are separated from the CL transport there is no need for BP to ever introduce an explicit (and complex) logic for multi-homing, multi-pathing, etc. The EID is a stable name for one end of a conversation regardless of how the bundles are transported in either direction or how that may change over time. The point of codifying the notion of a conversation is so that both applications and diagnostic tools (like Wireshark) can have a shared understanding of “how things are supposed to work” that is independent of how the application protocol is actually using the conversation. There is even a bundle signaling flag in the form of “Acknowledgement by application is requested” [2] which seems to be otherwise undefined and could be used as an indication that a bundle is the start of a (possibly brief, one response) conversation.
> 
> Taking analogy from protocols that use UDP, but not required by UDP itself, there are two general types of UDP port used: assigned and dynamic [1]. For many uses of UDP one side of a conversation will use an assigned port for a well-known service but the other side is free to use a dynamic port number. This has a few benefits, but the one most applicable to scaling of services is that while the “provider” of a service can use an assigned number, the “user” of a service can use a dynamic number without the need for any pre-configuration or negotiation. The disambiguation between users/conversations is by allowing each user to register its own ephemeral endpoint in the local BPA without the need to coordinate with any other endpoint. This also doesn’t exclude the case where both endpoints use assigned numbers (which is how some protocols like SNMP or DNS can operate) but makes that more of a special case. The concrete effect of this would be to reserve a large chunk of 32-bit IPN service number space [3] and maybe reserve a prefix or pattern in the DTN service demux space for ephemeral endpoints (the tilde prefix is already reserved for non-singleton endpoints).
> 
> The reason for all of this is that I think applications are going to naturally fall into this pattern, both because existing protocols (over UDP and the other connection-oriented transport) already use this pattern and because it is a genuinely useful thing to not need to reinvent every time there is a two-way exchange of bundles between applications. Finally, this isn’t a proposal for “this is what you must do” but more like “if you need a conversation this is the standard pattern of behavior,” which is equivalent to BPSec as “if you need bundle security this is what you use.”
> 
> Any thoughts or interest in a short draft to nail down some of these concepts?
> Brian S.
> 
> [1] https://www.rfc-editor.org/rfc/rfc6335.html
> [2] https://www.rfc-editor.org/rfc/rfc9171#section-4.2.3
> [3] https://www.ietf.org/id/draft-ietf-dtn-ipn-update-01.html#section-8.3
> 
> _______________________________________________
> dtn mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/dtn

-----------------------------------------------------------------------------------------------------------------
Dr. Shawn Ostermann  - Ohio University
Computer Science Faculty
341 Stocker Center, Ohio University, Athens, Ohio  45701-2979
[e-mail] -- [phone]