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

> Le 13 avr. 2023 à 10:21, Sipos, Brian J. <Brian.Sipos@jhuapl.edu> a écrit :
> 
> All,
> Now that we are getting into discussions of codifying BP application protocols (e.g. Marc’s proposals for SNMP/BP

Sorry I did not try to encapsulate SNMP over BP, but email.

> 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.

In IP world, there is a quadruple: source IP and port, destination IP and port. That creates a unique connection id on both ends. Right now, we don’t have that in BP.
Moreover, we need to support multiple application connections (that you call conversations) from the same source and destination: therefore the source should create a unique id to be used to recognize the “reply”, and keep a mapping of the ids.

> 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.

Nooo. BP is already super complex.

> 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).

If the same source is sending thousands/millions of application bundle payloads to the same destination and these are for loooong delays, as that is this wg actual use case!, and that some may never come back, we will end up using a large number space and I’m not sure any BP stack is able to cope with this large set.

Moreover, it is the application protocol that knows when a “connection” is finished, not the BP stack. Therefore, the BP node has no clue when to unallocate that source “connection id”. 

I think it is in fact much easier to deal with this at the application layer, with the appropriate semantics that are known by the application protocol. BP is there to deliver bundles to an application agent, and BP is really doing its only job good here.

I’m not sure we will have so many applications that require what you are describing. To me, with SMTP and HTTP done, we are in pretty good shape a large majority of apps nowadays are over http. And you see by the http-over-bp draft, your proposal won’t be enough anyway to support http.

Marc.

>  
> 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
> dtn@ietf.org <mailto:dtn@ietf.org>
> https://www.ietf.org/mailman/listinfo/dtn