Literally and figuratively, CANDOS took only a baby step, the dissenters at JPL say. It proved little. The 600 kilometers between Earth and a near-Earth orbiting space shuttle doesn't even measure up to the distance between Paris and Prague; countless packets travel much farther than that every minute of every day. The question remains: just how far into space can the Internet Protocol reasonably go?

At NASA's JPL, in the foothills of the San Gabriel Mountains, near Pasadena, Calif., doubts about IP's suitability in space began in the early 1990s. Run by the California Institute of Technology, JPL plans, designs, and controls deep-space missions for NASA. The Mars rovers are JPL's handiwork, as is the Cassini space probe now orbiting Saturn.

Like the engineers at Goddard, JPL researchers were interested in using IP to standardize telecommunications throughout the solar system. But the more they tried to shoehorn IP into the task, the more they came to doubt its practicality for deep space.

Why? The JPL researchers looked at the same basic obstacles—the handoff problem and the distance-delay problem. But where the Goddard group saw surmountable obstacles, the JPL engineers—including "Mr. IP" Cerf—saw showstoppers. Take the delay problem: the JPL crew found that no matter how they tried to readjust TCP for deep-space travel, it would not work. "Remote control is very hard when you have a 40-minute round-trip time," says Cerf.

JPL senior staffer Adrian Hooke, along with engineers Robert Durst and Keith Scott from the nonprofit organization Mitre Corp., started work in 1997 on a set of IP-based standards to address these problems. In 1998, Cerf started helping Hooke's team. By then, the group had been through four iterations of a modified set of Internet protocols. They all involved modifying TCP so that it would not rely on the sender and final receiver's being in constant contact.

In 2002, a member of the JPL team, Kevin Fall, a researcher for Intel Corp.'s Berkeley Research Lab, came up with the term Delay Tolerant Networking (DTN) to describe the architecture that would be needed to address this sort of problem. The Interplanetary Internet Working Group rebranded itself the Delay Tolerant Networking Research Group and began working on drafts, submitted to the Internet Research Task Force, to describe how such a network should operate. Fall now leads the group.

A delay-tolerant network is designed to move data across rough networks—networks that have long delays and noisy connections. Central to Fall's concept of DTN is "bundling," a mechanism for a space network's nodes—probes, relay satellites, and the like—to hold data if the next hop in the network is unavailable. Communications specialists call this a store-and-forward network.

This approach contrasts greatly with how nodes handle data on the TCP/IP-driven Internet. An Internet router doesn't keep track of the packets it conveys, nor where they are going beyond the next hop. Only the computer at the endpoint of all this hopping knows that a packet has arrived (and sends the acknowledgment back through the entire chain).

A DTN router, in contrast, keeps a copy of every packet of data sent, at least until the next node has sent a message that it has received it. That scheme ensures that no data gets lost en route, even if a node is offline. Should a relay satellite along an interplanetary Internet slip behind the other side of a moon, a router on a DTN network would simply hold onto the data that needed to be transmitted until that satellite reappeared, or until another one came into position to provide the necessary hop [see diagram, "Bank Shot"].

While the new protocol is hugely inefficient by earthly standards, using up a lot of memory to hold duplicate copies of data and needing orders of magnitude more time to send complete messages, it is a surefire way to get data to its destination. And it has some other benefits for a device in outer space, which, after all, has other things to worry about besides communicating with Earth.

Suppose a robotic surveyor on Mars has to navigate harsh terrain, looking for rocks that might contain fossils, and then send new photos of them back to Earth—a 10- to 12-minute trip at best. If it were a node on a TCP/IP network, the robot would have to keep a copy of that data in its limited memory banks until it got a confirmation that the data had been received on Earth. Such a notice would take at least 20 minutes to arrive—more if a direct connection weren't available. DTN, on the other hand, would require the surveyor to keep the data only until they were received by the first node—probably a nearby relay satellite. The surveyor could empty its memory banks and go back to snapping more photos within seconds.

In December, the JPL team submitted a draft for a DTN-supporting protocol called the Licklider Transmission Protocol, named in honor of Internet pioneer J.C.R. Licklider. (In 1962, Licklider jokingly nicknamed a group of researchers he was working with the "Intergalactic Computer Network.") The Licklider Transmission Protocol would replace both IP and TCP. Once again, picturing protocols as layers in a stack, if the bottom layer is the physical wire line or radio wave connecting two devices, the Licklider Transmission Protocol sits just above that. It makes the link between two routers more reliable than IP and TCP, says JPL researcher Scott Burleigh, who coauthored the draft. [see photo, "Beyond The Internet Protocol"].

The fact that DTN Eschews IP bothers some at Goddard and elsewhere in the NASA realm. You can hear the rumblings of discontent, if only in small groups huddled at space communications conferences or in cryptically snippy e-mails posted to technical mailing lists.

"There's been resistance to the idea of not using IP everywhere really from the beginning," JPL's Burleigh acknowledges. No one at NASA disputes the science behind DTN, not even its critics at Goddard. Not when Cerf, who could be expected to defend IP tenaciously, is on the JPL team. As CANDOS's Israel concedes, "You can't really say those guys don't know what they are talking about."

The Goddard concern basically boils down to this: if NASA were to choose DTN as the single architecture for its space missions, it could very well miss out on the opportunity to reuse commercially developed Internet software and hardware. It would in effect be prolonging its decades-old reliance on specialized products that cost far more or have fewer features (or both). With so much money and operability at stake, working with some version of IP is long overdue, these researchers say.

Consider President Bush's plans for a moon base and an eventual mission to Mars. It calls for coordinating the activities of multiple systems and habitats—robots that explore planets, way stations on the moon, relay satellites that orbit planets. It cries out for an IP-based networked approach to managing communications, Goddard specialists say, adding that commercial IP could help cut costs dramatically. It would also allow scientists to run many Internet applications that DTN would render unusable. While DTN can work with IP for some things, such as file transfers, using DTN to connect two IP networks—one in space and another on Earth, for instance—breaks the end-to-end connectivity essential for running many other Internet applications.

One such set of applications involves the interfaces that control scientific instruments. Today, scientists usually have to write by hand the programs that control the instruments that carry out their experiments aboard space probes. Researchers at the NASA Glenn Research Center, in Cleveland, have developed software tools that allow scientists to place a small Web server on each instrument. Then, with a space-based IP network, the scientists would need only a Web browser on a computer to tap into that instrument—in principle, from any network connection: a university laboratory, home, or a Starbucks coffee shop. With a DTN network, on the other hand, there would be no end-to-end Internet connection all the way to the instrument, rendering it useless.

Then there's the cost issue. Consider, for example, security software, needed so that hackers can't invade NASA's systems and take multimillion-dollar space probes on remote-controlled interplanetary joy rides. Such software is expensive to create but, for standard IP applications, easily purchased nowadays.

Over the years, researchers have carefully designed stripped-down security software for spacecraft communications that wraps a packet with a very thin envelope, reducing to a minimum the total number of bytes of data needed to send a photo or other information. The data savings, though, have to be weighed against the fact that a specialized solution is expensive to implement, maintain, and update, given the tiny number of vendors, compared with the commercial Internet equivalent, IPSec.

But what about the long transmission times and other challenges of space communications? At least two techniques exist for dealing with dodgy connectivity, the IP-in-space advocates say. One is the User Datagram Protocol, or UDP, which is similar to TCP but sends packets out without requiring receipts. It's been used for years in applications such as streaming media, where losing a packet here and there is much less important than keeping up with a high-speed data exchange. In fact, the CANDOS experiment aboard the shuttle used a version of UDP, called Multicast Dissemination Protocol.

Another model is provided by a store-and-forward network millions of us use every day—the Simple Mail Transfer Protocol, in which a server holds e-mail until we retrieve it. Phil Paulsen, who manages the earth science technology office at the Glenn Research Center, was part of a NASA team that developed, with General Dynamics Corp., store-and-forward software specifically for space communications.

"We assumed that there would be these kinds of satellites where you do not have continuous connectivity," Paulsen says. The best thing about the software? It runs over IP. But like Goddard's Mobile IP, it has been tested only in near-Earth orbits. No one has even done the basic math to calculate if such an approach can be extended for millions of kilometers.

For his part, Cerf isn't swayed. "They mystify me," he says of DTN's detractors, and generally of those who insist ordinary Internet protocols can be used in space. "My opinion is that you can't tweak the protocols enough to make them useful and still be compatible."

Sure, these specialists understand terrestrial Internet technologies fiendishly well. What they don't get, Cerf says, is the "space" aspect of space communications. Space will befuddle earthbound protocols in ways most network experts rarely conceive of.

Timing, for instance. Internet routers around the globe synchronize their clocks by the millisecond in order to coordinate the flow of packets. That synchronization is far more difficult when a significant fraction of a light-year separates a spacecraft's onboard clock from its reference clock. "The problem with the interplanetary environment is that there ain't no such thing as 'now,' " Cerf says.

Power, a limited resource on all NASA equipment, is another issue. Can TCP or some other protocol be tweaked so that it gets less chatty, and therefore less power-hungry, when a craft's fuel cells run down? The JPL team doesn't think so.

IP everywhere or not? For outsiders, such emotional differences in philosophy may seem like a NASA divided. For the space agency, however, it's just good science: have researchers beat on a problem from different angles and let the best solution win out.

Sitting quietly on the sidelines, waiting to evaluate all this work, are the NASA architects who must design the ambitious space fleet President Bush envisions. Over the next year, NASA's Space Communications Architecture Working Group will start planning the basic communications design for the Crew Exploration Vehicle. "Our job with technology is to figure out where it fits in with the evolving architecture," says its chairman, John Rush.

Rush has heard from both sides of the IP debate. He admits to liking the IP folks' idea of "the scientist sitting in his laboratory and communicating with his instruments on a spacecraft." But he's also well aware of the challenges. Over the next 10 months, JPL, Goddard, and Glenn will make their cases to the working group, through presentations and white papers.

One thing is certain: NASA is moving toward a networked model of interplanetary communications. Long gone are the days of dedicating a communications link to any one craft. The question now is how to build a network for a sky full of orbiters, shuttles, surveyors, and other spacecraft—the equipment that will be our eyes and ears to the universe. We want to make sure we get the best view possible.