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

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

Marc, I think I understand and agree with your points.

 

I still think that there is a need for some conventions to allow scalability and deconfliction. I agree that a BPA should not be keeping track of any kind of conversation state, and that an application must do its own in-band correlation between any notion of “associated response” payloads. As a practical matter though, when an application bound to some EID on a BPA receives a bundle and needs to send a response, to which destination does it send? To me the most simple (and stateless!) method is to send a response to the same EID which sourced the responded-to bundle. Any other method will require some pre-configuration or negotiation of lookup tables I think, which really limits scalability.

 

My use case in the near term is related to practicalities with the AMP, using SNMP as a basis for a well-established and well-adopted system that, for the most part, has a good workflow (not speaking here of the SMI object model or any message contents, just messaging workflow). But I think the same kind of logic applies to things like the HTTP-exchange-over-BP proposal. I’m going to use the term “client” below in the most generic sense as the “user of some abstract service.”

If response bundles are sent to some destination other than the source of the responded-to, maybe based on a well-known lookup table, then this will also cause a larger logical burden on the “client” side: when a response bundle is received, the single endpoint application must correlate the response with a request and then do whatever dispatch is necessary with the payload. This works fine when there is only one “client” per node but does not intrinsically allow for multiple clients on a single node.

 

If each “client” were allowed to register as an endpoint (from a pool of available “dynamic EIDs”) and the response-destination-from-source logic Is followed, then it’s the BPA which is performing the multiplexing. And it’s being done in a way which requires no state on the BPA (or even any notion of there being a conversation at all). It’s actually the application here that decides when a conversation is done by simply de-registering its endpoint (and associated EID). In this way what I’m proposing requires no change to the fundamental processing or interface of a BPA. As a convenience the only addition is a method for an endpoint to ask of a BPA “register me with an EID from that pool of dynamic EIDs, I don’t care which one just pick an unused one”. The fact that this is equivalent to some existing uses of UDP/IP is, to me, more an indication that it’s a reasonable pattern to follow.

 

This does not preclude an application/endpoint from choosing a well-known service number/demux, which is definitely something that has a purpose. But the concept of an ephemeral endpoint, which will register only for some short interval (relative the BPA lifetime) and then de-register once its work is finished, also has usability and scalability value. Imagine if every IP host was only allowed a single DNS client on a well-known port, even if technically possible it would be a huge unnecessary burden of coordination.

 

From: Marc Blanchet <[e-mail]> 
Sent: Thursday, April 13, 2023 7:47 PM
To: Sipos, Brian J. <[e-mail]>
Cc: [e-mail]
Subject: [EXT] Re: [dtn] Concept of BP conversations and ephemeral services

 


APL external email warning: Verify sender [e-mail] <mailto:[e-mail]>  before clicking links or attachments

 

 





Le 13 avr. 2023 à 10:21, Sipos, Brian J. <[e-mail] <mailto:[e-mail]> > 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> https://www.rfc-editor.org/rfc/rfc6335.html

[2]  <https://www.rfc-editor.org/rfc/rfc9171#section-4.2.3> 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> https://www.ietf.org/id/draft-ietf-dtn-ipn-update-01.html#section-8.3

 

_______________________________________________
dtn mailing list
 <mailto:[e-mail]> [e-mail]
 <https://www.ietf.org/mailman/listinfo/dtn> https://www.ietf.org/mailman/listinfo/dtn