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

[Erik Kline <[e-mail]>]

On Mon, May 29, 2023 at 9:08 AM Birrane, Edward J. <
[e-mail]> wrote:

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

Agreed, 100%.

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

I definitely agree that a strict private-use-only approach would greatly
increase the amount of state information that would need to be synchronized.

In my earlier attempted explanation, the waypoints would have to have been
part of the "domain" in which node+service number mappings were shared (and
therefore "well-known" to those within the domain).

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

Agreed that dynamic resolution is antithetical to general DTN usage.
(Someone could, of course, devise such a system, but its usefulness would
clearly be restricted.)

I know I was somehow extraordinarily unclear before: I never expected a
dynamic resolution mechanism in ordinary usage.  Rather I had imagined
_something_ in the control plane distributing the necessary configuration
information to applications within a cooperating domain.

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

I have no intention of adhering to any excessively dogmatic position; I
just wanted to understand better how a set of "node.service"
destination EIDs was distributed/provisioned to applications.

All, or some combination, of these schemes seems very reasonable to me.

Many thanks!
-Erik

-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] 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]> 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]> <[e-mail]> * On Behalf Of *Zaheduzzaman
> Sarker
> *Sent:* Monday, May 15, 2023 3:44 AM
> *To:* Rick Taylor <[e-mail]>
> <[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] 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]> 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]
> https://www.ietf.org/mailman/listinfo/dtn
>
>
>
> _______________________________________________
>
> dtn mailing list
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/dtn
>
>
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn
>
>