The Delay-Tolerant Networking (DTN) protocol emerged from work first started in 1998 in partnership with Nasa's Jet Propulsion Laboratory. The initial goal was to modify the ubiquitous Transmission Control Protocol (TCP) to facilitate robust communications between celestial bodies and satellites.
Cerf and his team were eventually forced to acknowledge (ACK?) that TCP simply couldn't cut the mustard, with massive delay and data loss caused by celestial motion rendering TCP useless.
"There was a little problem called the speed of light," joked a typically playful Cerf, as he outlined the idea to the OpenMobileSummit conference in San Francisco. "When Earth and Mars are closest, we're 35 million miles apart, and it's a three and a half minute trip one way, seven minutes for a round trip. Then when we're farthest apart, we're 235 million miles – 20 minutes one way, 40 minutes round trip."
Those pesky planets. But surely Google, having dominated Earth, could do something about that? "The planets rotate, and we haven't figured out how to stop that," Cerf admitted.
The core issue is that TCP assumes a continuous (and fairly reliable) connection. DTN makes no such assumptions, requiring each node to buffer all of its packets until a stable connection can be established. Whereas TCP will repeatedly attempt to send packets until they are successfully acknowledged, DTN will automatically find a destination node with a reliable connection, and then send its payload just once. Given the latency of space communications and the minimal power restrictions placed upon satellites, DTNs approach seems prudent.
However most people don't have a need for regular satellite communication (well, our columnist Warren Ellis has that death ray of his), but Cerf sees his robust protocol having more down-to-Earth applications. Mobile networks, for example, must regularly cope with long periods of delay or loss – a train tunnel rudely interrupting a YouTube stream, for example. Perhaps looking to gain an edge on its competitors, Google has already integrated DTN into Android's networking stack.
Using Android from an asteroid? It's only a matter of time.
[Source: www.wired.co.uk]Cerf and his team were eventually forced to acknowledge (ACK?) that TCP simply couldn't cut the mustard, with massive delay and data loss caused by celestial motion rendering TCP useless.
"There was a little problem called the speed of light," joked a typically playful Cerf, as he outlined the idea to the OpenMobileSummit conference in San Francisco. "When Earth and Mars are closest, we're 35 million miles apart, and it's a three and a half minute trip one way, seven minutes for a round trip. Then when we're farthest apart, we're 235 million miles – 20 minutes one way, 40 minutes round trip."
Those pesky planets. But surely Google, having dominated Earth, could do something about that? "The planets rotate, and we haven't figured out how to stop that," Cerf admitted.
The core issue is that TCP assumes a continuous (and fairly reliable) connection. DTN makes no such assumptions, requiring each node to buffer all of its packets until a stable connection can be established. Whereas TCP will repeatedly attempt to send packets until they are successfully acknowledged, DTN will automatically find a destination node with a reliable connection, and then send its payload just once. Given the latency of space communications and the minimal power restrictions placed upon satellites, DTNs approach seems prudent.
However most people don't have a need for regular satellite communication (well, our columnist Warren Ellis has that death ray of his), but Cerf sees his robust protocol having more down-to-Earth applications. Mobile networks, for example, must regularly cope with long periods of delay or loss – a train tunnel rudely interrupting a YouTube stream, for example. Perhaps looking to gain an edge on its competitors, Google has already integrated DTN into Android's networking stack.
Using Android from an asteroid? It's only a matter of time.
.png)
No comments:
Post a Comment