Re: [dtn] [EXT] Re: I-D Action: draft-ietf-dtn-ipn-update-04.txt

["Birrane, Edward J." <[e-mail]>]

Erik,

  (With chair hat off…)

  I agree that we should avoid an *over-reliance* on reserved, well-known service identifiers. Polluting a space with niche services doesn’t seem to help anyone.

 However, I think we should allow for the *existence* of reserved, well-known service identifiers, for three reasons:

First -- service identifiers are logical identifiers (not ports or PIDs). For example, I could have a BPA which supports the “ABC” service and every time a new remote node uses that service the local BPA would spawn a new local process to handle that particular service for that particular remote node. Even if I wind up spawning 5..10…20 local processes to communicate with 5..10…20 remote nodes, I would expect the service identifier for all of them to remain the service identifier for service “ABC” because services are logical identifiers. The “demux” on the local node IMO is handled by the local node itself.  Certainly private-use service identifiers don’t need to behave that way, but well-known services identifiers could (and probably should).

Second – Waypoint nodes may want to understand well-known service traffic. I could imagine local policy on a waypoint BPA enforcing QoS or QoP as a function of well-known services. Such as “all network management traffic needs to be signed” or “all file transfer traffic needs to be encrypted”.  If service identifiers are *all* private use and, thus, likely only known to source and destinations, we remove any practical analysis by waypoint nodes.

Third – If we presume that we must do service discovery for all services, then every participating BPA would need a mapping of every other BPA’s custom identifier for service “ABC” or otherwise presume that service discovery can be done “on demand” round-trip (which does not sound DTN-like). I think we should avoid (relatively) large, per-node mappings of custom identifiers (and worrying about them changing?) for well-known services.

I propose something of a middle ground – we have a 64 bit space here, after all:


1.       All one-byte encoded service identifiers be private use.

2.       Most two-byte encoded service identifiers be private use, but keep a small carve out (32?) for well-known services.

3.       Most three-byte encoded service identifiers be private use, but keep a small range (1024? 2048?) for well-known services. Maybe another range for unassigned?

4.       Most 4 byte and above now could just be unassigned.

Then focus discussion on what should/should not be a well-known service. My hope is that well-known doesn’t mean 100% adoption but, rather, likely adoption for some threshold use, yet to be defined.

Thoughts?

-Ed

---
Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Constellation Networking
Supervisor, Embedded Applications Group
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839


From: Erik Kline <[e-mail]>
Sent: Thursday, May 18, 2023 2:01 AM
To: Oscar Garcia <[e-mail]>
Cc: Birrane, Edward J. <[e-mail]>; Zaheduzzaman Sarker <[e-mail]>; Rick Taylor <[e-mail]>; [e-mail]
Subject: [EXT] Re: [dtn] I-D Action: draft-ietf-dtn-ipn-update-04.txt

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



I'd like to consider an argument for not having any reserved, well-known service numbers at all (other than zero for administrative endpoint purposes).

Making assumptions about port numbers and their application meaning was useful when the resolution mechanisms available did not support returning the extra port number information (e.g. gethostname).  For various reasons things like SRV records did not exactly take off as a replacement that could give true port number flexibility.  Regardless, it's clear that today port 443 alone doesn't tell you anything about the application anymore.  (Indeed, "ALPN is the new port number.")

I personally think that well-known, reserved ports are a bit of a relic from the past that perhaps we don't need to carry forward.  I would suggest that the service number (and for that matter: the demux portion) should be something returned via a resolution mechanism (including "statically assigned" resolution) and there's likely very little value to having anything be reserved/well-known in the same way that port numbers were.

2 cents,
-ek


On Wed, May 17, 2023 at 12:22 PM Oscar Garcia <[e-mail]<mailto:[e-mail]>> wrote:
Ed,
Great point about specific service numbers for common application services.
I have been dealing with that for Medical Records for Space for some time.
In a conference that I gave today on DTN, this was one of the points that was brought up in the Q&A.
Making a parallel with TCP/IP ports, port 104 is reserved for exchanging radiology images in DICOM PACS on TCP/IP.
Best,
Oscar

On 17/5/2023 15:44, Birrane, Edward J. wrote:
Rick,

  (Chair hat off)

  Coming back from the CCSDS meeting last week, the one comment on the updated document was about the treatment of service numbers.

  It is expected that service numbers in the IPN scheme identify some application service. For example, RFC9171 Section 4.2.5.1.2 states “… the EID's service number (a number that identifies some application service)…”.   Given that definition, missions will likely have their own application services for common operations like commanding and telemetry. Keeping the smaller numbered elements (0-23) as RFC required (or generally specification required) would be a burden because:


1.       Mission-specific services will not likely be traced to RFCs or public standards

2.       Mission-specific services would be frequently used in a constrained environment so small encodings would be appreciated.

  Suggestion was to have an allocation of smaller numbers (and possibly larger numbers) be made “private use”  (https://www.rfc-editor.org/rfc/rfc8126.html#section-4.1) with, perhaps, a smaller section carved out for specification required.

-Ed


Edward J. Birrane, III, Ph.D. (he/him/his)
Chief Engineer, Space Constellation Networking
Supervisor, Embedded Applications Group
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (C) 443-690-8272

From: dtn <[e-mail]><mailto:[e-mail]> On Behalf Of Zaheduzzaman Sarker
Sent: Monday, May 15, 2023 3:44 AM
To: Rick Taylor <[e-mail]><mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: [EXT] Re: [dtn] I-D Action: draft-ietf-dtn-ipn-update-04.txt

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



Hi all,

Lets continue the WGLC one more week (ending 19th May 15, 2023). Consensus call will be made after this week. If anyone has any question about this extension, please let me know.

//Zahed

On 2023-05-12, 10:53, "dtn" <[e-mail]<mailto:[e-mail]>> wrote:

Hi All,

I have pushed out a new version -04 of the ipn update draft to fix a
missing xref and address some of ScottJ's comments.

Again, please have a quick read.

Cheers,

Rick

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


_______________________________________________

dtn mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/dtn

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