Slashdot Mirror
Communicating Even When the Network Is Down
coondoggie writes to mention a NetworkWorld article covering efforts to maintain network connectivity even when the network has holes. Building off of the needs of the military, the end goal is to create a service which will route around network trouble spots and maintain connectivity for users. From the article: "Researchers at BBN Technologies, of Cambridge, Mass., have begun the second phase of a DTN project, funded by $8.7 million from the Department of Defense's Defense Advanced Research Projects Agency (DARPA). Earlier this year, the researchers simulated a 20-node DTN. With each link available just 20% of the time, the network was able to deliver 100% of the packets transmitted." The article is on five small pages, with no option to see a linkable, printable version.
Wasn't that the point of the original ARPANET? To route around broken parts of the network? BBN was involved in that, too. What, have they been double-billing the DoD this whole time?
gigantino.tv - Heavy but weighs nothing.
Baby, darling. I appreciate the warning, but you do realize, as a janitor at Slashdot you have a decent amount of power, clout in the nerd world. Even though you're condemning their actions with your comment, you're promoting their site, giving them extra ad revenue with their annoying practices.
If you want to make a difference, make a stand, stop linking to sites like these. Send them a quick letter saying you'd be happy to send X thousand happy clickers their way if they'd give a single page, printable version. With their "Slashdot it" link at the bottom of the page, they obviously care.
The article is on five small pages, with no option to see a linkable, printable version.
Yea, except for maybe the link at the bottom of the article that says "Print".
Anyone else feel like they're time travelling when they're reading this?
you had me at #!
I'm glad DARPA funds stuff like this. They should perhaps call it DARPA-net or something like that. Also, perhaps this research will result in really cool new inter-networking technology that the public can make use of. Perhaps universities might be the first big users.
n et)
Of course, if that happens, I hope this new inter-networking thing doesn't get privatized... 'cause then all kinds of crazy things might happen.
(For the uninitiated or those who like things spelled out, see: http://en.wikipedia.org/wiki/History_of_the_Inter
A real criticism of what BBN is doing is that, heck, my cell phone is low enough on memory already--and I would be very put out having to share that meager space in order to persist that scoutmaster request for google earth maps. Also, think about how that mechanism would have to be configured--does every scout have to "allow" the scoutmaster to query/query-through their PDA's? How complicated would that be? If BBN decides to simplify it by allowing a certain level of adhoc-ness, then what would be the security ramifications?
I suppose that that's why this is a DARPA project (which connotes research)--because I think there is no way this can be more than an experiment.
The spec provides for "intermediate" servers receiving the message and passing it on.
Years ago this was duplicated with the old BBS's and phone lines. I'm talking about the single user at a time boards. One phone line. Lots of waiting.
The boards had the numbers of different boards that they would call as the lines were free (their's and the recipient's). Messages would be passed along whatever route was available until they were received at the destination.
This model is heavily dependent upon storage, though. If one of the nodes loses its hard drive, the messages stored there were lost. You can have unreliable connections, but you cannot have unreliable storage.
Also, think "routing loops". The tail of the messages gets really long in some of these schemes. You don't want the message routing back over connections it has already traversed, do you?
Which leaves the possibility of the "route to nowhere". Where messages go to die.
You must be just as blink as Zonk. The link to the print version is right next to the "Slashdot it" link!
This is an old wive's tale that deserves to die. The ARPANet was NOT built as an experiment in resiliant networking; it was built by DARPA to connect scientists so they could share all the large computers that DARPA was funding.
e rnet/dp/0684832674
See: Where Wizards Stay Up Late
http://www.amazon.com/Where-Wizards-Stay-Late-Int
and
http://www.businessweek.com/1996/38/b349359.htm
Yes, SMTP is an amazingly strong example of redundancy. However, we installed redundant fiber at a school I work for within a few days, and just for fun we'd pull plugs randomly and monitor the response time while a alternate link was used. I think 10ms was about average... Then it stopped being fun after a while. We even tested load balancing.
/.
So my question is.. why are we treating this like its a new thing? This seems like another one of the frequent quasi-ads which seem to be more common lately here on
Remember, this is Slashdot. We would gladly pay $8.5M in research to allow the computers to do the talking for us.
--------------
From: John Smith
To: Jane Doe
Subject: Thnx
thnx 4 ppt. wnt g00d lol.
JS
University in NZ
--------------
Come to think of it, forget the network. I think our communication is down.
Proof by very large bribes. QED.
Although this research is nice, it does not address the worst vulnerabilities of the current internet. Botnets, ARP poisoning, DNS poisoning, pwned routers seem to be a more dangerous risk than mere unreliable components. Cyberterrorism and criminal exploitation of the internet means subverting the system rather than just breaking pieces of it.
The original internet design carried the naive assumption that all the devices on the net could be trusted -- all the devices assumed the validity of all control data, responses to protocols, etc. In the original model, devices had two primary states -- "unavailable" and "available" where "unavailable" might cover both damaged or overloaded components (a slightly more sophisticated version assesses capacity or latency as gradations between the binary unavailable/available dichotomy). In this one dimensional two-state model, disruption tolerance means routing around "Unavailable" or overloaded components.
Yet the rising threat is from malicious entities that want to subvert the network's functioning, not just disable it. Spam, phishing, click fraud, and extortion depend on twisting a functioning network, not just poking holes in the network -- all the parts remain "available" but their data and responses become deceptive. Thus future fault-tolerant networks will need to distinguish between trustworthy and untrustworthy components. This suggests employing techniques such as cryptographic signatures, polling systems, blacklisting, FOAF, firmware integrity checks, and device-to-device secret questions.
Designing a more robust internet is a laudable task but we need to spend more effort on securing against the true threat of untrustworthy components rather than unavailable components.
Two wrongs don't make a right, but three lefts do.
It is clear from the article that they are aiming for something more than OSPF or other link state routing protocols. If a link is cut inside a network, OSPF adjusts so that traffic is routed through alternative paths. But, until there is convergence (which is quite fast in most cases), packets may be lost. Packet drops do tend to occur if a router cannot find a suitable route to a destination, if it is able to find a route but the link to that route is down, or even if the queue on that link is congested (full). That's the very nature of our present best effort internet.
It appears to me that these guys try to address some of these "shortcomings" by making certain privisions that can guarantee packet delivery, even in a overly late fashion. A routing instability, lost routes or links should not be able to cause packet drops if they have it right.
However, I used the quotes in "shortcomings" because I am not entirely certain that this has not been tried before. If, instead of a best effort packet routing service, you try to invent a "smart" network layer that can guarantee stuff like ordered delivery (packets are delivered in the order they departed), assured delivery (even with great delays) etc, you are basically trying to invent a (gasp!) connection oriented service. Not that connection oriented technologies are inherently bad, but, well, they are certainly an order of magnitude harder to implement. Anyone remembers OSI? It might as well be easier to leave IP simple as it is and try to move some smartness to the upper layers.
Additionally, it would be better to try to build on top of unreliable services like IP and construct stuff like SMTP (as a previous poster very cleverly pointed out), that can function even if parts of the network are mulfunctioning.
Well, anyway, you might want also to take a look at the efforts on the interplanetary internet, this article reminded me of it.
In the new "non" net-neutral(ity) world, routing around trouble spots was not a service you paid for. If you need that service it will be an extra $10.00 a month. We love all our customers and hope your experience with our product is to your satisfaction. Now, if you would please take just a few moments and fill out our survey...
No, this has not been done before in this manner. The internet does not communicate when disconnected. Try to send a file to a machine that is turned off or not connected to the net and see what you get?
This type of network, DTN (Disruption tolerant network - which btw, is similar to DTN - delay tolerant network - (see IETF working group)) is oriented towards disconnected operation, mobile nodes and ad-hoc environments.
BBN is not the only participant (though it is a big one). The project includes various universities and research institutes.
The problem is, discarding extraneous packets is actually a VERY GOOD THING when it comes to the internet. Several store and forward systems pre-dated the current TCP/IP stack, but guess what. They weren't as efficient in terms of required hardware resources or latency. This is because in a store and forward network, certain problems (like network cards going nuts and spewing tons of garbage) can cause lots and lots of data to accumulate in the network, and then you have to wait for every single packet to move on before you get to the new and relevant data.
The OSI model and network researchers in general recognize that reliable transport facilities can easily be built on top of unreliable "best-effort" communication networks, whereas it's nigh impossible to create light-weight best-effort services on top of a store and forward network. Since both kinds of applications exist, those that need reliable transport, and those that need speed. It only makes sense to provide an underlying fast and light weight network which doesn't provide, and isn't expected to provide, 100% reliability.
Finally, in practice, it actually turns out to be rediculous to expect 100% reliability from anything, particularly a low-level networking scheme since in the real world, no network is 100% reliable. Life can get very interesting indeed when you're supposed to rely on 100% packet delivery and one of your packets never arrives.
The real problem IMO when dealing with wireless networks is that so many developers try to shoehorn existing land-line applications and methodologies into the wireless world. There's a big difference between a network with an avg latency of 80ms, standard deviation of 2ms and 0.3% packet loss compared to a network with an avg latency of 500ms, a non-standard deviation pattern ranging between 200ms and 6 seconds and 20% packet loss. And that's completely ignoring issues related to moving between coverage zones and maintaining proper routing.
Basically, TCP, FTP, and many of their friends can wind up being very bad deals in such an environment. And things get even *more* interesting when someone tries to "fix" the network to work well with them... (by, for instance, blocking up groups of packets and waiting for a certain data-size to accumulate before sending.)
Look for DTN to be used in upcoming NASA missions (see interplanetary internet) as well as next-generation military networks. DARPA and NASA are serious about this, and have Vint Cerf's backing as well. I expect that there will be quite a few commercial-off-the-shelf solutions that spin off once the dust settles around the standard.
It won't replace the current internet protocol suite - just augment it.
Actually, a planned convergence layer for the DTN project is sneakernet.
DTNs work by storing packets (well, "bundles," really) at the router, until an opportunistic connection is available. Bundles move from hop to hop, until they arrive at their destination.
This is accomplished over a variety of "convergence layers," such as TCP and UDP, with UDP being the most commonly used for transmitting bundles currently in research. However, other convergence layers for other uses are being planned. One of these is sneakernet, where data is copied to physical media, the media is physically taken over to another node, and the other node reads the data and forwards the bundles to the next hop as available.
The main research page is at http://dtnrg.org/.
No. Normal routing works through space. Packets move from node to node, avoiding nodes and links that are down. DTNs can route through space and time, delaying packets until they can be routed further along.
If you have two networks that are only intermittently connected, normal routing will drop packets when the connection is down. DTNs will allow the packets to be held until the connection is up.
They carry endpoint IDs, which achieve a similar functionality to IP addresses and TCP/UDP ports, but are also human-readable. DTN protocols are fairly high-level, so they can do that.