[Sis-dtn] Is there a standardized way to implement/configure TCP convergence layer for Bundle transaction?

["구철회"]

Hi, Brian S.


Yes, either way has benefits, and there are no technical issues. Absolutely, there is no need to argue about which one is more correct.


Interfacing to another neighbor node through LTPCL over UDP is quite straightforward since it only needs to transmit all the LTP segmentation data to *113 UDP port (1113, 2113, 3113, and so on, according to the LTP node number).


Of course, LTPCL over UDP can be used with multiplexing. It is technically fine. However, it does affect the configuration parameters' effort, so every node must know the contact information for how the opposite side allocates the reception port in the range of 1 to 65535.


I think TCPCL has the same issue. Do we want to allocate a port number for this, e.g., xxx019 for dedicated use? Or do we want to reserve preferred port numbers from agencies, such as 1 to 1000 for NASA, 1000 to 2000 for ESA, 2000 to 3000 for KARI, and so on?


Cheol

--------- 원본 메일 ---------

보낸사람 : "Sipos, Brian J." <Brian.Sipos at jhuapl.edu>
받는사람 : "구철회" <chkoo at kari.re.kr>, "Gao, Jay L (JPL-332C)[JPL Empl" <jay.l.gao at jpl.nasa.gov>, Felix Flentge <Felix.Flentge at esa.int>, "sburleig.sb at gmail.com" <sburleig.sb at gmail.com>, "Torgerson, J. Leigh (US 332C)" <jordan.l.torgerson at jpl.nasa.gov>, Keith Scott <keithlscott at gmail.com>, "Wilmot, Jonathan J. (GSFC-580." <jonathan.j.wilmot at nasa.gov>, Carlo Caini <carlo.caini at unibo.it>
받은날짜 : 2023-09-07 (목) 02:51:05
제목 : RE: Is there a standardized way to implement/configure TCP convergence layer for Bundle transaction?



Cheol,
While the TCPCL allows many possible strategies, as you point out, I’m not sure that these represent barriers to interoperability. If a passive TCPCL entity chooses to listen on one port or may separate ports, it doesn’t (or shouldn’t) affect the ability of a peer to attempt to establish a TCPCL session. There may be specific policy on a node that refuses connections or terminates sessions based on the peer parameters, but this seems like a policy or configuration alignment issue and not necessarily lack of interoperability (the node can be capable of interoperating but chooses by policy not to do so).
 
I would be interested to see specific examples or hurdles with TCPCL practice, because if there are special cases that lead to trouble these should at least be captured as errata for RFC 9174 or as updated recommended practice.
 
LTP on the other hand, because it lacks a strong binding to its segment transport, can cause headaches with middleboxes (for example when using UDP transport can confuse NAT and firewalls because it isn’t guaranteed to use a single 5-tuple “conversation” the way other UDP applications typically do). This also has beneficial side effects related to multi-homing though, so there isn’t really a right or wrong way.
 
Thanks for any feedback,
Brian S.
 



From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of ??? via SIS-DTN
Sent: Wednesday, September 6, 2023 12:29 AM
To: 'Gao, Jay L (JPL-332C)[JPL Employee]' <jay.l.gao at jpl.nasa.gov>; 'Felix Flentge' <Felix.Flentge at esa.int>; sburleig.sb at gmail.com; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov>; 'Keith Scott' <keithlscott at gmail.com>; 'Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC <jonathan.j.wilmot at nasa.gov>; 'Carlo Caini' <carlo.caini at unibo.it>
Cc: sis-dtn at mailman.ccsds.org
Subject: [EXT] [Sis-dtn] Is there a standardized way to implement/configure TCP convergence layer for Bundle transaction?
 






APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org before clicking links or attachments
 
Hi Fellows
 
Recently, I began to consider that the implementation of the TCP convergence layer, which conveys Bundles reliably, can be source of interoperability issues among various DTN implementations.
There is freedom in designing the TCP interface, with options like allocating a single TCP port to a node and multiplexing neighbor input, or allocating multiple TCP ports for each neighbor's transaction input.
 
Some implementations perform an interrogation step to obtain multiplexing information from neighboring nodes, such as IPN/DTN address.
Some implementations prefer multiple TCP daemons for connecting with neighbors.
In either case, DTN software may need to implement a specialized UTA or CLA interface for interfacing with various other DTN software via TCP convergence layer.
 
Is there a standardized way to do it? Or do we want to discuss about a standardized way here?
 
On the contrary, LTP, as a Convergence Layer, is a straightforward mechanism and a point-to-point protocol that simplifies Bundle input multiplexing, resulting in fewer interoperability issues, in my opinion. LTPCL is useful at the ground-space link, however TCPCL can be more suitable choice for terrestrial link. So, I think, TCPCL needs more attention for future DTN usage.
 
Best,
Cheol
 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230907/28eced2d/attachment.htm>