Arthur T Knackerbracket has found the following story:
NASA's Human Exploration and Operations and Science Mission Directorates are collaborating to make interplanetary Internet a reality.
They're about to demonstrate Delay/Disruption Tolerant Networking, or DTN -- a technology that sends information much the same way as the conventional Internet does. Information is put into DTN bundles, which are sent through space and ground networks to its destination.
The Science Mission Directorate looks forward to incorporating DTN into future missions and has identified the Plankton, Aerosol, Cloud, ocean Ecosystem, or PACE, mission as the first key opportunity to demonstrate this revolutionary capability.
-- submitted from IRC
This discussion has been archived.
No new comments can be posted.
Disruption Tolerant Networking to Demonstrate Internet in Space
|
Log In/Create an Account
| Top
| 11 comments
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
(1)
(Score: 3, Insightful) by FatPhil on Tuesday July 17 2018, @09:27AM (8 children)
How are they defining "the conventional Internet" which they're contrasting themselves against? That sounds like something you would be contrasting against the "modern internet". Because where I grew up, high latency and intermittent communication - using UUCP - was the thing, over dialup obviously, more than a decade before always-on modern internet connections were.
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
(Score: 0) by Anonymous Coward on Tuesday July 17 2018, @09:30AM (1 child)
Yes. But on a computer.
(Score: 2) by MostCynical on Tuesday July 17 2018, @12:41PM
In SPACE
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 3, Funny) by c0lo on Tuesday July 17 2018, @09:38AM (3 children)
Nope. It's some network layers down (UUCP standing in the application protocol layer)
It actually builds upon the RFC 1149 and RFC 6214, but they needed to tackle the inability of avian carriers to deal with space conditions.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by KritonK on Tuesday July 17 2018, @11:51AM (2 children)
Although TFA talks about plankton, I think that plankton is the object of study, not one of the network layers.
On the other hand, these RFCs describe protocols for sending datagrams, and I would think that for a "solar system internet", UDP has a better chance of producing something that works, than TCP. Having to wait ~2,5 seconds to receive acknowledgment for each packet sent to or from the moon, will slow a TCP connection to a crawl, and it only gets worse in the case of the planets. Of course, with UDP you will have to retransmit lost packets, which will add additional delays and will make receiving a complete file an undecidable problem.
(Score: 0) by Anonymous Coward on Tuesday July 17 2018, @04:16PM (1 child)
You don't need to re-transmit lost packets if you use FEC (forward error correction). Old tech is good tech!
(Score: 2) by KritonK on Wednesday July 18 2018, @07:53AM
FEC will correct corrupted packets, as long as the number of corrupted bits stays within a specified limit. Packets that are corrupted more than that, will need to be retransmitted.
(Score: 2) by Zinho on Tuesday July 17 2018, @12:42PM (1 child)
Sounds a lot like the satellite internet connection I had for a month before cancelling. I literally had ping times of up to 3500ms, and if I turned on my VPN I couldn't even do file transfers across the network in Windows. Somewhere along the line the OSI model broke down, and something in the Host layers balked at the connection provided in the media layers by my ISP.
If interplanetary internet is going to succeed it'll need more support than just a replacement of the network layer.
"Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
(Score: 2) by requerdanos on Tuesday July 17 2018, @01:09PM
To be fair, the network layer has some problems that make things that should work great, not work.
For example, "mostly reliable" or semi-reliable wireless connections should be able to retransmit lost packets through drop-outs just as dial-up modems were able to retransmit packets through line noise. But they often don't; the packets get dropped.
When we take this semi-reliable wireless connection and move the ends to different planets, now we have the problem of a pretty high inherent ping time due to the speed of light* on top of the problem of the wireless connection being intermittent.
Thing is, these are easily predictable problems that should be very easy to solve.
Takes a long time to transmit? Wait longer. Done. Maybe not 100% solution, but something workable until that 100% solution comes along.
Many packets get lost? Acknowledge them, retransmit lost ones. Done. Maybe not 100% solution, but something workable until that 100% solution comes along.
But wifi shooting a few tens of meters across the street becomes basically unusable if a few trucks go by and modulate the signal between the buildings. Something will definitely need to change.
-----
* unless they get that entanglement thing working and create an ansible, and hand-wave away criticisms that it would break causality, which frankly doesn't seem to be a thing at the quantum level (still does not solve dropped packets).
(Score: 0) by Anonymous Coward on Tuesday July 17 2018, @08:00PM
Retransmission depends on a reasonable probability of success on the first and certainly the second try.
Long delay paths make this even worse.
Multiple, less than stellar links in the retransmission path, even worse.
Hop by hop retransmission can improve the odds with multiple bad links.
(Think store and forward, like pre-internet networking.)
What do you do for the delays?
Probably a better retransmission control protocol than TCP, maybe also with some redundancy like FEC.
Did NASA publish anything on how this actually works?
(Score: 2) by Fishscene on Wednesday July 18 2018, @01:44AM
I've been researching DTN for a few months now. There seems to be 2 major categories for Delay/Disruption(both/either name can be used) Tolerant Networking.
1) The route through the network is unknown. If you need to get a message from one-side of the stadium to your friend on the other side, and you have 0 infrastructure other than random cell phones, how would the routing algorithm's route efficiently to and from your destination?
2) The route through the network is known. This is what NASA gets to work with because they know which satellites are being used. It also helps to know when the satellites will be available as they orbit celestial bodies.
Whereas TCP and UDP require a nearly real-time connection between the source and destination, DTN does not.
Basically, DTN comes somewhere after the ISO Application layer, and before the 3rd layer. DTN is ideally protocol-agnostic. So it should be able to use TCP/UDP/BlueTooth/Radio/anything and it should be able to be completely independent of the protocol. So if it gets something over bluetooth, it can route it over TCP or whatever other protocol you have for communicating between 2 devices.
I for one am very excited to see NASA moving ahead with this.
Here's some resources on the topic:
https://www.nasa.gov/content/dtn [nasa.gov] This has a video that does an excellent, if basic job at describing how DTN will help with efficient communication.
https://www.youtube.com/watch?v=cr5A2WQGzIQ [youtube.com]
https://en.wikipedia.org/wiki/Delay-tolerant_networking [wikipedia.org]
/Begin dream
I've had aspirations for creating an easy-to-use DTN app for Android/iPhone that could be used in emergency situations when infrastructure is not available. For example, some guy in a boat paddling down a flooded street and hapless victims enabling an emergency mode - transmitting their location and status info to the boat man who can being the info to an emergency center. Or even for use with villages that don't have infrastructure - they can send messages across town using a completely ad-hoc DTN network.
I'm also not a programmer either - that's probably my biggest hurdle right now. So I've been dinking around in Powershell learning more about DTN and how I might code it in the future.
Here's the project I've been following - and they have a working DTN app for Android: https://github.com/ibrdtn/ [github.com]
/end dream
I know I am not God, because every time I pray to Him, it's because I'm not perfect and thankful for what He's done.