[Sis-dtn] FW: [dtn] [EXT] yet another modest proposal

[Dr. Keith L Scott]

FYI.  This was from the second half of the IETF DTN WG meeting.

                                --keith

From: dtn <dtn-bounces at ietf.org> on behalf of Dr. Keith L Scott <kscott at mitre.org>
Date: Thursday, July 28, 2022 at 10:33 AM
To: sburleig.sb at gmail.com <sburleig.sb at gmail.com>, dtn at ietf.org <dtn at ietf.org>
Subject: Re: [dtn] [EXT] yet another modest proposal
So I can sort of remember SOME IPv4 addresses (at least for a while…) but IPv6?  -- forget it.  So sure, why not just use (IPN Node) numbers?  Bonus if we build a DNS-like service (and some elements of CCSDS are interested in a whois-like service as well).

To your point about the IPN DNS-like service being delay-tolerant.  Well, in general, yes, such a service should operate over BP and could operate over disruptions/delays.  The issue is what happens when this database changes.  Fundamentally, the information has to be synchronized throughout the network.  That could be a long/painful process in a DTN, but I’m not sure there’s an alternative.

I’m not sure I agree on the need for something that’s highly processor-efficient; I’d lean more towards something that is highly compressible so that those synchronization efforts are more efficient.

As I said above, some elements of CCSDS are interested in a ‘whois-like’ service that would map a node number to a point of contact.  I think that gets at your notion of the meaninglessness of node numbers and the ‘hints’ about who ‘owns’ what based on IANA / SANA registry entries.  That service would have all the same issues of the DNS-like service, I think.


Again, in the near future, the DNS and whos databases will be reasonably small, and most resolutions are going to be done by people on Earth.  For the slightly-longer term we may have folks on the Moon, and later on Mars which starts to get to be an issue.  Good and efficient algorithms for doing the ‘zone transfers’ to support the DNS and whois services would be good, but probably supportable for the next, say, 50-100 years.


So, I think I agree, numbers are as good as anything and probably better than trying to do string-to-string mappings.

(My apologies if the above is duplicative; I couldn’t make the second hour of the meeting – it was recorded, right?  I’ll try to catch that).


                                --keith


From: dtn <dtn-bounces at ietf.org> on behalf of sburleig.sb at gmail.com <sburleig.sb at gmail.com>
Date: Wednesday, July 27, 2022 at 9:51 PM
To: dtn at ietf.org <dtn at ietf.org>
Subject: [EXT] [dtn] yet another modest proposal

Hi, all.  This is the email on node identifiers that Rick somewhat recklessly invited at the end of our meeting yesterday.  It is long.  You might want to read it sitting down.



The bottom line: I propose that all BP nodes be uniquely identified by node numbers -- natural numbers -- full stop.



The obvious objections to this are:

  *   Lengthy node numbers are impossible for people to remember, type correctly, or derive semantic sense from.  All absolutely true.  There should never be any reason for any human (other than maybe a troubleshooting network engineer or a BP developer) to see or use a node number.  Unique node numbers should only be written, processed, or read by computing devices, which will find them extremely convenient.  Humans should only refer to nodes by human-readable, semantically rich character strings.  Further notes on this below.
  *   Node numbers convey no information about the node.  Not entirely correct (as discussed below) but again absolutely true in general.  There is no need for node identifiers to convey information about nodes; that information belongs somewhere else, as discussed below.



Inconvenience of reference by humans:



Humans interact with DTN by means of applications, instantiated by computing devices.  Those applications can readily utilize a directory service to map between arbitrarily expressive human-readable names and numbers.  DNS is an existence proof.



The key difference between DNS and the sort of BP directory service I’m suggesting is that the former is not delay-tolerant, while the latter pretty much is.  DNS maps between character strings and IP addresses, which are the names (written in an alphabet of just 0 and 1) of the locations of IP nodes; a BP directory service would map between character strings and node numbers, which are the names (again in binary alphabet) of the nodes themselves.  That means that whenever the address of an IP node changes, the directory (the DNS system) needs to be updated in order for routing to that node to succeed; those updates happen quickly in the Internet but would be unsustainable in a Solar System Internet.  In contrast, changing the location of a BP node would have no effect on a BP directory at all; the same name still refers to the same node.



Naturally, changing the human-readable name of a BP node would affect the operation of BP applications, just as changing the domain name of an IP node affects the operation of Internet applications.  Nothing new there.  Actually, there’s no reason there couldn’t be multiple character strings that map to the same BP node number, either to cushion a node’s transition to a new human-readable name or to support abbreviations or nicknames or aliases.



Moreover, there might easily be multiple BP directories managed by different entities, all of which might or might not support the same naming syntax.  Nor would all (or, really, any) directories need to support node number mapping for all nodes in the network – if you’re running a selenium mine on Mars, maybe the directory you consult doesn’t have to include all BP nodes in Malaysia; sort of like phone books.  I would propose that we let the community sort out which syntax(es) they prefer and which directories they prefer; there’s no reason we need to nail this all down now, let’s leave the door open for some creativity in expression.  DNS and the World-Wide Web were not envisioned in detail by the original inventors of TCP/IP, they came along later.  Maybe we shouldn’t get ahead of ourselves.



The key thing is to have a dead-simple, highly processor-efficient and bandwidth-efficient foundation for everybody to build on.  That’s what we get by numbering nodes.



Meaninglessness of node numbers:



If there are BP directories that map between node numbers and human-readable names, then (a) those human-readable names can themselves be arbitrarily expressive and (b) those human-readable names (or the numbers themselves) can be used to retrieve as much information about nodes as one could ask for.



It’s true that all of this mapping and lookup activity is not even remotely delay-tolerant *if* the directories are centrally located and must be queried across 40-minute round-trip times.  But there is zero reason to adopt that model: because the association between a human-readable node name and a node number (and thus the node itself) never changes when the node’s location changes, it’s entirely delay-tolerant to replicate directory contents across any number of repositories that are IP-local to nodes throughout the network.  Again, changes in nodes’ human-readable names themselves – likely rare – would need to be synchronized across all directory replicants, but any alternate node identification system would have to do the same and would have a much greater impact, as the changes would have to be propagated to all nodes rather than only to all copies of the directory.



And in fact node numbers need not be entirely devoid of information.  We already have a node number assignment mechanism in place in IANA, and part of that mechanism is the delegation of a large range of node numbers to the CCSDS SANA; SANA, in turn, has already delegated sub-ranges of that range to several NASA centers.  Node numbers are a little like Ethernet addresses in this sense.  It would not be especially difficult to build lookup software that would use knowledge of these range delegations (maybe “allotments”, like the gardening space allotments in some European cities) to map immediately from a node number to the entity that assigned that number to that node – maybe termed the “operator” for the smallest range that includes that node number.  Given an operator ID maybe you could look up routing constraints, security rules, whatever.  If allotment boundaries are chosen with some care you could use bitmaps for lookup.



Speaking of “allotments”, I will further suggest that there might be a number of other different types of node aggregation that we might want to contemplate in the long term.  The notion of “region” that I’ve been working with in ION is the set of all nodes that are cited as senders and/or receivers of bundles in the contacts that make up a single contact plan; as such, a region bounds the operation of forwarding based on Contact Graph Routing.  It’s tempting to overload “regions” with additional administrative significance, like node (rather than contact plan) management authority or security profile or tariff zone, whatever.  We can do that, but I think it’s kind of Procrustean; in the long run I think we will have greater operational flexibility and efficiency by letting any given node be a member of allotment X, region Q, security domain G, etc., all of which may or may not partially overlap.  We don’t know all the requirements yet; let’s not try to design everything now.



Thanks for reading this far.  Let me know what you think.



Scott











-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220728/8d92cc4f/attachment-0001.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20220728/8d92cc4f/attachment-0001.txt>