Fake Banner
    Lessons NASA Can Learn From The Internet
    By Michael Martinez | November 21st 2011 09:12 PM | 2 comments | Print | E-mail | Track Comments
    About Michael

    Michael Martinez has a Bachelor of Science degree in Computer Science, an Associate of Science degree in Data Processing Technology, and a few certifications...

    View Michael's Profile

    I am sure it is old news to most if not all of Science 2.0's readers that NASA recruited Vint Cerf to help adapt Internet technology to space mission communications in 2000; and that they successfully tested a new protocol in 2008. I have no doubt that the engineers can put together a pretty reliable interplanetary network.

    Still, systems have a way of growing beyond their designers' expectations. For example, earlier this year we made a big fuss about how the pool of available IPv4 addresses has finally been exhausted. Vint Cerf announced recently that he would like to see the entire world switch to IPv6 addressing by January 2013. Hopefully we won't have to expand beyond IPv6 but the Interplanetary Internet (IPN) might actually find a way to push that limit. I know, IPv6 allows for some very big numbers, but let me speculate madly.

    Suppose we extend our nascent swarm technology into space. We might create self-replicating hordes of little asteroid-and-comet monitoring probes or drones that spread out across the Solar System to give us a semi-real-time picture of the movement of objects out there.

    In fact, these self-guided replicating machines might even possess the capability to pass around new software and extend their native processing functions. Each node could blossom into a micronetwork of sub-nodes.

    We have already done this with the existing Internet -- you're just not accustomed to thinking of that process. But whereas 10-15 years ago most companies might have had only a small number of computers (or at most one) attached to the Internet, now it is common for even small to mid-size companies to deploy networks across multiple locations, multiple floors, and within small developer pods. We spawn networks like red tides. Technically, we might have exceeded the capacity of IPv4 addressing long ago but for the fact that many corporate networks reuse certain ranges of IP addresses within local addressing tables.

    I have a network at home. I use a wireless router to connect to the Internet and then every computer in my home connects to the router. I AM the network, and I could program each of my computers to use multiple IP addresses that would look like only one IP address to the rest of the world. So what's to prevent a tech-savvy family from giving each child their own network for all their IP-enabled devices so that Daddy doesn't have to worry about clutter on HIS personal network?

    We don't yet have the self-replicating technology but we're working on it, and when we have it we'll deploy it into as many environments as we can to expand both our knowledge and our grasp of the elements across the Solar System. That technology will have to be controlled and the controls will be remotely managed. Just imagine billions of slowly decaying automata floating around the Solar System 100 years from now -- we may have to assign special trackers just to track the obsolete trackers.

    All that IPN traffic will face similar systemic challenges to those confronting today's Earth-bound Internet, such as Bufferbloat, a system-wide decay in performance first identified by Jim Gettys only last year. Every time I look at the Internet Traffic Report I wonder who is winning the race against time: Mr. Gettys and his engineer allies or the gremlins in the system. I can't tell.

    Gettys defines Bufferbloat as "existence of excessively large (bloated) buffers into systems, particularly network communication systems.". I am not a network engineer but as I understand the problem, every time a network engineer solves a local problem by increasing a buffer he adds to the delays that spread across the Internet. These excessive buffers try not to fail, and it is that determination not to fail that causes everything to sag.

    As best I can understand it the IPN attempts to resolve the "dropped packet" issue by relying on localized buffering. Whereas the Earthbound Internet depends on packet drops to free up buffer space (and thus suffers congestion as buffers are increased to temporarily store more buffers) the IPN will try to hold on to everything for as long as necessary in order to ensure accurate delivery of messages. That way we can be reasonably sure that a remote-controlled robot won't focus its laser beam on our light-sensitive housing by mistake.

    The IPN is probably going to work fine with a small network. It's when the network expands that it will face a real test. And it may have to fall back on some primitive administrative techniques to handle the load. In fact, we may have to assign buffering priorities to all the communications because some things will have to be transmitted in such a way as to allow packet loss -- the very thing the IPN is designed to avoid.

    Command systems need to preserve their communications -- user systems don't. It's when we send a lot of users out into space that we'll need to stress the IPN in ways that, I fear, Mr. Cerf and JPL may not have thought about (and he freely admits he never foresaw the Internet we have today -- so I give him credit for being as realistic as a network designer can be). We may have to pass data around the Solar System like news group servers.

    Back in the 1990s, when bandwdith was precious and news group spam was prolific, many a news group server was configured to clear out high-activity groups' messages in a matter of hours. They received a message, stored it locally for their own users' access, and passed it on to peered servers as quickly as possible. Of course, that still happens today but I don't know what the level of urgency is.

    I don't expect our billions of self-replicating space-probes to be passing pornography and schmucky promotional messages around, but space spam may become a reality. Think of software engineers who design their little explorer bots to phone home with status reports. Think of explorer teams who request thousands of pictures from larger bodies in the Solar System. When we have these networks in place, we will use their resources.

    So millions of images and billions of status messages will be beamed across the Interplanetary Network by unyielding self-administered autonomous systems that only know they have to receive-and-pass-it-on. Their poor little buffers, even if built on quantum crystal technology, may not be able to handle all the communicating. The network will be a swarm of systems trying to balance the load by looking at what their nearest neighbors (their "local peers" if you would) are doing.

    Such a system may introduce latencies and ghost messages that have to be compensated for at the systemic level rather than through the node technology. We'll need protocols to ensure that old messages aren't allowed to reactivate processes that have been completed. We'll need police filters that clean up the clutter from images that have been transmitted to Earth (or wherever).

    But we'll also need super-buffers or data nets that float in space and keep archives of communications available for whatever needs them. These data storehouses will have to roll their data to each other the way massive networks share data between data centers now -- only they'll be sending data across the Solar System.

    I don't see why we wouldn't set up relay nodes and storage nets in orbits between interplanetary orbits. These nodes could reduce the amount of energy required to transfer data across long distances. We already use mirrors, proxy servers, and geotargeted cache servers across the Earthbound Internet. The Interplanetary Internet should be able to adapt such technology to its own needs.

    But the greatest challenge for the Interplanetary Network will be creating the infrastructure rapidly enough to accommodate future demand. Capacity will probably exceed demand for a long enough period of time to lull everyone into forgetting about the problem. Meanwhile, here on Earth we'll be developing our remote engineering technologies to create portable factories that can be sent into orbit, then to the moon, then to Mars. These portable factories will only need raw materials. They'll build probes, nodes, relay hubs, etc.

    It will all be very mundane, very non-automated, very slow and lethargic in the beginning. Then gradually innovations will creep into the system. Economies of scale will pick up the pace of growth. We'll throw more and more electronic clutter into space as we pursue our quest for knowledge, experiment with interplanetary colonization, and create both NEED and DEMAND for IPN resources.

    The system will evolve and as it evolves it will produce unforeseen behaviors and patterns. We will need to respond to those behaviors and we'll probably re-invent the wheel a few times. Eventually, maybe we'll get to the point where a family living on Mars will be able to request pictures of a few random asteroids passing near Jupiter, and the network will figure out which nodes can do that, and the pictures will be received and reshared to thousands of other familes without a flicker on the network. And that will happen a few dozen times every second.

    Comments

    Dear Michael,
    Actually, the Bundle Protocol works over IPv4, IPv6 and subsequent transport mechanisms because the destination identifiers are not IP addresses but interplanetary destination identifiers (written with variable length strings). There is a two-level structure so that binding of the destination identifier to a lower level address does not occur until the bundle arrives at the proper spacecraft, moon, asteroid or planet. This is called "late-binding". With regard to overloaded buffers, bundles can be assigned priority and also "life times" so that the expiration of the life time causes the bundle to be discarded. To avoid congestion and loss of data, there does have to be some kind of flow control. Note also that for many of the elements in an interplanetary system, "contacts" (ie, opportunities to transmit/receive) can be computed based on orbital dynamics, so nodes can know when it is time to transmit and/or listen for a communication. One can also use ad hoc methods for organizing mobile communication (e.g. on the surface of a planet, supporting mobile sensor networks, rovers, etc.) just as we would do here on Earth. The team that has worked on theese interplanetary protocols began with the assumption that we might ultimately see a need for a lot of traffic between planets or platforms in space, so a good deal of self-organization has been incorporated into the design.

    Michael Martinez
    Thank you for the clarification, Vint.  I knew I was being a little cheeky in writing the article but I have noticed that systems which continually expand develop complexities that create new layers of data superstructures within themselves, the characteristics of which cannot be accurately predicted on the basis of knowledge of previous existing layers of data superstructures.
    I am sure that your system, if it expands enough, will develop new, unpredicted characteristics that should make life interesting for future admins and engineers.  The super-system will find its own limits and capabilities in spite of all our best efforts -- or because of them.