Building the Interplanetary Internet

sighted writes "Internet pioneer Vint Cerf, now a Google VP, is leading a NASA effort to create a permanent network link to Mars within the next two years. As Cerf outlined in a recent talk, the 'InterPlaNet' protocol is designed to handle the delay caused by interplanetary distances. A signal traveling between the Earth and Mars can take up to 20 minutes."

Re:How exactly is this news?

[Washizu]

"leading a NASA effort to create a permanent network link to Mars within the next two years"

Re:Open protocol

[Leif_Bloomquist]

Actually, the majority (at least recently) use CCSDS [ccsds.org]

Re:What is the maximum latency for communication?

[jandrese]

The maximum TTL on a TCP/IP packet is 256 (I'm pretty sure it's unsigned). Of course that means absolutely nothing in this context because the TTL is only decremented (by one) when your packet goes through a router (it's designed to reduce the damage caused by routing loops). That said, there are timeouts in the TCP 3 way handshake that make setting up a regular plain vanilla TCP connection with Mars impossible unless you can figure out a way to exceed the speed of light. That's why you have to switch to IPN on the long hop to Mars and run applications that don't care about 20 minutes worth of delay. The applications are really the hardest part, you either have to set up fancy proxies or specifically build your application to handle long delays.

Current limits of technology

[Valdez]

Now, IANACG, so check my math. ;)

Mars is, roughly, between 50 and 250 million miles away from earth, depending where we are in our solar orbits. Recently, the closest it's been in a long while is nearly 35 million miles (back in 2003 according to the Intertron)... but the distance swings rapidly as we race around our orbits... it can go from 40 million to 200 million in the space of a few months. I'm using 50 million as a rough average for the sake of illustration.

Given the speed of light, as fast as we think we can go, is *only* 670 million mph... that means the fastest one way trip we think anything can do is still going to take 4.5 minutes... it'll be better when it's closer (just over 3 minutes) and worse when it's on the opposite side of the sun (22 minutes)... and remember thats just one way!

Even if we plant a colony on mars, you won't be seeing ms ping times between earth.sol and mars.sol until there a breakthrough in our understanding of physics and we figure out how to go faster than the speed of light.

For those who didn't want to bother to read this post, if you want to play Halo XXV on a Mars server, you'll need to figure out a way to communicate with that installation at superluminal speeds.

Re:Priorities

[Paulrothrock]

I live within a half mile of one of the most expensive schools in my state (Franklin & Marshall). Almost all of the kids drive brand new cars, many of them luxury cars. They're able to pay for high speed broadband and would spring for 10Mbps symmetrical connections even if they cost $100/month, just because Mommy and Daddy would pay for it. Because of the population density, a few last-mile (more like last-fifteen-feet) runs would make whoever did it tons of money.

But they don't. Why? Because the only two carriers in the city (Comcast and Verizon) are already making tons of money giving sub-par service, and there's no other competition to force them to innovate thanks to our wonderful state government. I can't even get Embarq because Verizon has the CO locked down, and Embarq isn't my "local carrier."

If the state government got rid of the monopolies on cable and phone lines, we'd see some movement.

uucp, USENET, 747 - all good analogs. UDP

[davidwr]

UUCP and USENET were good analogs, with "latency" usually being "less than an hour" or "less than a day" but sometimes "less than a week. Heck, there was one outfit that got USENET feeds by TAPE every week.

A 747 full of HD-DVDs or Blue-Rays has high bandwidth but terrible latency.

Any reason UDP's "send and forget" with an appropriate application- and link-level protocol can't be used? Of course, this would only be useful for non-latency-sensitive applications, such as a scheduled "push" of data, where the schedule was set up ahead of time. Given the chances of error, it should also have lots of error-correcting bits at the link level and a delay-tolerant error recovery at the application layer.

Re:talking without delays using quantum entangleme

[l4m3z0r]

Not possible according to wikipedia:

As a result, measurements performed on one system seem to be instantaneously influencing other systems entangled with it. But quantum entanglement does not enable the transmission of classical information faster than the speed of light (see discussion in next section below).

and here:

Although no information can be transmitted through entanglement alone, it is possible to transmit information using a set of entangled states used in conjunction with a classical information channel. This process is known as quantum teleportation. Despite its name, quantum teleportation cannot be used to transmit information faster than light, because a classical information channel is required.

Re:talking without delays using quantum entangleme

[mhall119]

You can transmit information this way, but not faster than light.

The problem is that whenever you observe one atom, the super-position collapses instantaneously for both. That means the receiver needs to know that the sender has already measured the atom on the sending end before observing their atom on the receiving end, this would have to be done by a standard, non-FTL signal. You also have the problem of not being able to collapse the super-position into a specific value (say 0 or 1), so while the receiver would know what state the sender's atom is in, that state is a random value (0 or 1), so no data is actually conveyed.

The first problem may be overcome with some time-based scheme, where the sender and receiver have syncronized clocks, and have agreed at what time the sender will measure his atom. The problem with random waveform collapse, however, would be harder to overcome, though I think the quantum computers in recent articles have managed to make it slightly less-random.

Re:Screw that

[rudeboy1]

I know you're kidding, but it underscores the point Cerf is trying to make. In standard TCP/IP, any download is a 2 way conversation, with the receiving party verifying all packets. A mutation of the current UDP model would do just as you say, where you would get long streams of unverified data from one source to another, with a simple acknowledgment packet at the end. The problem lies in possible transmission errors, of which there are many. If they go optical, (which I can't even fathom, but I suppose I don't know everything about optical open space comms) the slightest piece of debris in the signal path will cause packet corruption (making fault tolerance a central concern). If they go RF, well, there's a metric butt load of natural RF interference in space. That satellite is gonna need some big rabbit ears to pick up a whole stream without problems.

Ok, I know I get an A for effort and an F for sense of humor, but I wanted to cover the issue. sue me.