[dtn] Concept of BP conversations and ephemeral services

["Sipos, Brian J." <[e-mail]>]

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