[Sis-dtn] [EXT] Re: [EXTERNAL] IPN URI Scheme Service Numbers

Wed May 24 04:15:53 UTC 2023

is there some reason a DTN node cannot serve multiple users with the same
service concurrently?

v

On Wed, May 24, 2023 at 7:10 AM Birrane, Edward J. <
Edward.Birrane at jhuapl.edu> wrote:

> Yeah,
>
>
>
>   I have no issue with standard numbers for services, either.
>
>
>
>   I **think** the reasoning against standardized service numbers is
> fourfold:
>
>
>
> 1.      We don’t seem to be using them. The SANA registry only
> standardizes 64/65 for CFDP sender/receiver. Even then, there was some
> concern about nodes that have multiple instances of CFDP engines running
> (IIRC).
>
>
>
> 2.      Service numbers might be domain dependent. If we reserve a number
> (or two) for CFDP, that’s probably a good thing for the space domain but
> not for other domains that would never use CFDP. Should we be reserving
> “universal” service number space for services that are not universal?
>
>
>
> 3.      Every BPA would need to protect service number ranges that are
> for things they would never use.
>
>
>
> 4.      On the internet most well-known ports aren’t used anymore and we
> use single ports (like 443) for different kinds of traffic and rely on
> service discovery. Especially in microservice architectures? (not my area
> so unsure on this one)
>
>
>
>   But the alternative is service discovery over a DTN (sounds like a bad
> idea) or adding an extension block with service info (which is kinda back
> to service numbers).
>
>
>
>   Since the service number space is large (64bit) it seems like a small
> ask to carve out a few 2-byte and 3-byte ranges for standard services.
>
>
>
> -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 <(443)%20778-7423> / (C) 443-690-8272 <(443)%20690-8272>
>
>
>
> *From:* Vint Cerf <vint at google.com>
> *Sent:* Tuesday, May 23, 2023 10:18 PM
> *To:* Torgerson, J. Leigh (US 332C) <jordan.l.torgerson at jpl.nasa.gov>
> *Cc:* Birrane, Edward J. <Edward.Birrane at jhuapl.edu>;
> sis-dtn at mailman.ccsds.org
> *Subject:* [EXT] Re: [Sis-dtn] [EXTERNAL] IPN URI Scheme Service Numbers
>
>
>
> I agree with Torgerson's reasoning.
>
> v
>
>
>
>
>
> On Tue, May 23, 2023 at 11:40 PM Torgerson, J. Leigh (US 332C) via SIS-DTN
> <sis-dtn at mailman.ccsds.org> wrote:
>
> I generally agree with the proposal Ed outlines (though I would like to
> reserve all 1 or 2 byte SN’s as standards, and leave the private use
> service numbers for the 3 or 4-byte encodings, much like the convention of
> the first 1024 IP well-known ports, since everyone should want to be using
> standard application services like bping, other snmp-like applications, and
> for deep space use, CDFP at least.. Standard 1 or 2 byte service numbers
> for the most common applications would be more efficient.
>
>
>
> Why not all private? If a program (say, the Mars program) wants all nodes
> to be able to host a CFDP client that identifies itself as service number
> 65, then if a mission is launched later, and it wants to relay CFDP data
> through one of the other Mars nodes, then it will have to use service
> number 65, or arrange with other nodes to use some other service number,
> which will take intervention by the operators of the other nodes.
>
>
>
> This is the primary operational need to agree on some standard conventions
> for service numbers. I don’t think you want every DTN node in an IPN
> network to be able to pick its own service number for each application.
> (Some underlying convergence layer choices in a relay situation may depend
> on knowledge of the application so the correct convergence layer may be
> chosen for the next hop, and if the service numbers aren’t standardized, it
> will be a crap shoot at any relay node.)
>
>
>
> We’re trying to create an easily-interoperable DTN-enabled network, and I
> don’t see why standardized service numbers are controversial.  Is it a
> matter of food-fights between “registry organizations”? Is it a matter of
> how many bytes you use because of the CBOR encoding? IDK, but I do think
> making service numbers all “private” is a really bad idea – it just kicks
> the can down the road and leaves room for a lot of chaos as the SSI and DTN
> scale up.
>
>
>
> Leigh
>
>
>
>
>
>
>
> On 5/22/23, 5:49 AM, "SIS-DTN on behalf of Birrane, Edward J. via
> SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org <mailto:
> sis-dtn-bounces at mailman.ccsds.org> on behalf of sis-dtn at mailman.ccsds.org
> <mailto:sis-dtn at mailman.ccsds.org>> wrote:
>
>
>
>
>
> WG,
>
>
>
>
>
> Last week at the SIS-DTN weekly meeting we had a good discussion on
> allocation strategies for IPN service numbers.
>
>
>
>
>
> IIRC, there were three major areas of discussion related to these numbers:
> encoding size, allocation policy, and registry ownership.
>
>
>
>
>
> The encoding size discussion noted that the CBOR encoding of service
> numbers creates a very small allocation of 1-byte encodings (0-23), a small
> allocation of 2-byte encodings (24-155), a moderate size allocation of
> 3-byte encodings (256-65,535), and then 4+ byte encodings that give us the
> remainder of the 64bit service number space.
>
>
>
>
>
> The allocation policy discussion noted that there was a good case for
> "private use" service numbers for mission-specific use cases (commanding,
> telemetry) that do not otherwise map to a standardized protocol. These
> mission specific service numbers should not be standardized (they are
> mission specific) and there should be some allowance for them in the small
> encoding space since they will be used by missions often (perhaps most
> often).
>
>
>
>
>
> The registry ownership discussion noted that IANA is creating (updating
> really..) a registry for service numbers and should there be a SANA
> allocation in that registry.
>
>
>
>
>
> At the end of the discussion the following proposal was put forward:
>
>
>
>
>
> 1 byte service numbers (1-23) will be private use .
>
> 2 byte service numbers (24-255) will be expert review with a 64-id chunk
> allocated to SANA.
>
> 3 byte service numbers (256-65k) will be cut 1/3 private use, 1/3 IANA
> managed and 1/3 IANA managed but given to SANA.
>
> 4 byte will have a chunk of experimental.
>
> 4+bytes is unassigned.
>
>
>
>
>
> This continues to be an area of active discussion in the IETF mailing
> list. Some IETF participants are proposing that all service numbers be
> private-use and there be no standard service numbers since service
> discovery is better done today independent of port numbers. I disagree with
> this position - service numbers are not port numbers - but that case needs
> to be made, for those interested in following the discussion on the IETF
> mailing list.
>
>
>
>
>
> -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 <(443)%20778-7423> / (F) 443-228-3839 <(443)%20228-3839>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> SIS-DTN mailing list
>
> SIS-DTN at mailman.ccsds.org <mailto:SIS-DTN at mailman.ccsds.org>
>
>
> https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$
> <https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$>
> <
> https://urldefense.us/v3/__https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$
> <https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn__;!!PvBDto6Hs4WbVuu7!PmRT1qgVRZ2xQ2ZmSkNsmI_vgd4lA9qIIyGjTyX4JUYTo8kPleu5uCOTg66suXkIMwIJ575LUtjMFERB5874XXuzevk$>>
>
>
>
>
>
>
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>
>
>
>
> --
>
> Please send any postal/overnight deliveries to:
>
> Vint Cerf
>
> Google, LLC
>
> 1900 Reston Metro Plaza, 16th Floor
>
> Reston, VA 20190
>
> +1 (571) 213 1346 <(571)%20213-1346>
>
>
>
>
>
> until further notice
>
>
>
>
>
>
>

-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346

until further notice
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230524/83838cc6/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3995 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20230524/83838cc6/attachment-0001.bin>