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

Thu Sep 7 23:28:02 UTC 2023

Good points! Actually I like the way in RFC 9174, listening a single TCP port for multiple connections.
Thanks for the tips.

Cheol

From: Sipos, Brian J. <Brian.Sipos at jhuapl.edu>
Sent: Thursday, September 7, 2023 11:30 PM
To: 구철회 <chkoo at kari.re.kr>; Felix Flentge <Felix.Flentge at esa.int>
Cc: Gao, Jay L (JPL-332C)[JPL Empl <jay.l.gao at jpl.nasa.gov>; 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>; sis-dtn at mailman.ccsds.org
Subject: RE: [EXT] RE: Is there a standardized way to implement/configure TCP convergence layer for Bundle transaction?

Cheol,
I agree with what Felix has mentioned and I will strongly encourage to use the IANA allocated port number where possible and let your network stack or OS deal with multiplexing TCP connections. Having all (or as many as possible) hosts listening on standard ports will avoid the need to customize each new node/host.

And this is not something DTN- or BP-specific, using standard port numbers generally will help with middleboxes and tools like Wireshark or scapy to need less configuration from the default.

From: chkoo at kari.re.kr<mailto:chkoo at kari.re.kr> <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Sent: Thursday, September 7, 2023 7:10 AM
To: Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>
Cc: Sipos, Brian J. <Brian.Sipos at jhuapl.edu<mailto:Brian.Sipos at jhuapl.edu>>; Gao, Jay L (JPL-332C)[JPL Empl <jay.l.gao at jpl.nasa.gov<mailto:jay.l.gao at jpl.nasa.gov>>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>; Keith Scott <keithlscott at gmail.com<mailto:keithlscott at gmail.com>>; Wilmot, Jonathan J. (GSFC-580. <jonathan.j.wilmot at nasa.gov<mailto:jonathan.j.wilmot at nasa.gov>>; Carlo Caini <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: [EXT] RE: Is there a standardized way to implement/configure TCP convergence layer for Bundle transaction?

APL external email warning: Verify sender chkoo at kari.re.kr<mailto:chkoo at kari.re.kr> before clicking links or attachments

RFC 9174! I just quick reviewed the document and found that 4556 is the allocated TCP port number and information that I need (Thanks to Sipos Brian J.)

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

It seems that we are mixing standardisation, conventions and implementations.

From the standardisation perspective, I don’t see any interoperability issue (I just did a quick review RfC 9174). If there are, these should be addressed in IETF.

The use of specific UDP ports for LTP according to engine id is nothing more then a convention for specific implementations. Running LTP over UDP can use any port you agree. (Anyway, I would typically suggest to use TCPCL for terrestrial communication).

I think the real underlying question is how to know to connect to a specific node (which CL to use, which parameters, …). Currently, we specify this in ICDs. In the future we may use discovery mechanisms (I think there is on-going work), network management, registries (some people proposed the SANA sites & apertures) or something else to get such information.

Regards,
Felix

From: chkoo at kari.re.kr<mailto:chkoo at kari.re.kr> <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>
Sent: Wednesday, September 6, 2023 11:32 PM
To: Sipos Brian J. <Brian.Sipos at jhuapl.edu<mailto:Brian.Sipos at jhuapl.edu>>
Cc: Gao, Jay L (JPL-332C)[JPL Empl <jay.l.gao at jpl.nasa.gov<mailto:jay.l.gao at jpl.nasa.gov>>; Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>; Keith Scott <keithlscott at gmail.com<mailto:keithlscott at gmail.com>>; Wilmot, Jonathan J. (GSFC-580. <jonathan.j.wilmot at nasa.gov<mailto:jonathan.j.wilmot at nasa.gov>>; Carlo Caini <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>; sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>
Subject: RE: RE: 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<mailto:Brian.Sipos at jhuapl.edu>>
받는사람 : "구철회" <chkoo at kari.re.kr<mailto:chkoo at kari.re.kr>>, "Gao, Jay L (JPL-332C)[JPL Empl" <jay.l.gao at jpl.nasa.gov<mailto:jay.l.gao at jpl.nasa.gov>>, Felix Flentge <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>, "sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>" <sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>>, "Torgerson, J. Leigh (US 332C)" <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>, Keith Scott <keithlscott at gmail.com<mailto:keithlscott at gmail.com>>, "Wilmot, Jonathan J. (GSFC-580." <jonathan.j.wilmot at nasa.gov<mailto:jonathan.j.wilmot at nasa.gov>>, Carlo Caini <carlo.caini at unibo.it<mailto: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<mailto: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<mailto:jay.l.gao at jpl.nasa.gov>>; 'Felix Flentge' <Felix.Flentge at esa.int<mailto:Felix.Flentge at esa.int>>; sburleig.sb at gmail.com<mailto:sburleig.sb at gmail.com>; Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov<mailto:jordan.l.torgerson at jpl.nasa.gov>>; 'Keith Scott' <keithlscott at gmail.com<mailto:keithlscott at gmail.com>>; 'Wilmot, Jonathan J. (GSFC-580.0)[VANTAGE SYSTEMS INC <jonathan.j.wilmot at nasa.gov<mailto:jonathan.j.wilmot at nasa.gov>>; 'Carlo Caini' <carlo.caini at unibo.it<mailto:carlo.caini at unibo.it>>
Cc: sis-dtn at mailman.ccsds.org<mailto: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<mailto: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

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).

[Image removed by sender.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230907/93b390ea/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 332 bytes
Desc: image001.jpg
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230907/93b390ea/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 823 bytes
Desc: image002.jpg
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230907/93b390ea/attachment-0003.jpg>