Local Mesh Networks Are Not the Internet
The most recent Scientific American has yet another article extolling the wonders of mesh networks and their ability to route around censorship (and damage.) As usual, the article ignores the uses people actually have for the Internet.
Ask a random passerby what sorts of things are "on the Internet", and you'll get a wide variety of answers: E-mail, porn, Twitter, Facebook, Wikipedia, games. Very few will say "all the computers in my neighborhood", because virtually nobody cares about that aspect. And the former list are almost entirely hosted in data centers. No application but Bittorrent and botnets cares about talking to others in your neighborhood. They want to talk to a rack of servers living in a carefully air-conditioned room, usually in some other city.
So what good does it do to build a mesh network that is independent of ISPs, when the other side of the applications that people use all live in data centers connected to ISPs?
Possibility 1: Build new applications. Good luck with that; market discipline will quickly teach you the benefits of centralized (but clustered) applications vs. trying to run your application in a peer-to-peer fashion.
Possibility 2: Connect all the data centers in the city to the mesh network. A good start. Too bad that you need DNS to find them, and you probably don't have any TLD nameservers in your city. So you implement a new distributed naming system. See point 1.
Possibility 3: Build mesh networks large enough to cross the Rockies, or develop cheap homebrew trans-Atlantic links. (Kickstarter a few communications satellites?) At least this doesn't require a whole new protocol stack!
Back in the real world of hierarchical network routing, though, we really could use a new protocol stack that handles multiple connections well. For all the talk about the Internet supporting redundancy, multihoming (having two or more IP addresses) is handled very badly. I have had friends with redundant links through two different ISPs (DSL + cable, for example) and you can make this work--- short-lived HTTP connections load-balance pretty well. But sustained sessions (remote desktops, VPN, etc.) can't be switched from one path to the other, because that TCP connection state is tied to an IP address, which indicates a particular ISP. There is virtually no way to change your route (as an end user) without changing your identity as well.
Large enterprises are able to negotiate service agreements and run VPN connections in such a way as to tie their internal networks together despite this. But the end-to-end argument tells us that reliability, security, and availability are properties that can only be achieved by endpoints working together. IP addresses as endpoint doesn't cut it--- but until that problem is solved, mesh networks will continue to be local-area toys, not censorship-robust Internet access.
Ask a random passerby what sorts of things are "on the Internet", and you'll get a wide variety of answers: E-mail, porn, Twitter, Facebook, Wikipedia, games. Very few will say "all the computers in my neighborhood", because virtually nobody cares about that aspect. And the former list are almost entirely hosted in data centers. No application but Bittorrent and botnets cares about talking to others in your neighborhood. They want to talk to a rack of servers living in a carefully air-conditioned room, usually in some other city.
So what good does it do to build a mesh network that is independent of ISPs, when the other side of the applications that people use all live in data centers connected to ISPs?
Possibility 1: Build new applications. Good luck with that; market discipline will quickly teach you the benefits of centralized (but clustered) applications vs. trying to run your application in a peer-to-peer fashion.
Possibility 2: Connect all the data centers in the city to the mesh network. A good start. Too bad that you need DNS to find them, and you probably don't have any TLD nameservers in your city. So you implement a new distributed naming system. See point 1.
Possibility 3: Build mesh networks large enough to cross the Rockies, or develop cheap homebrew trans-Atlantic links. (Kickstarter a few communications satellites?) At least this doesn't require a whole new protocol stack!
Back in the real world of hierarchical network routing, though, we really could use a new protocol stack that handles multiple connections well. For all the talk about the Internet supporting redundancy, multihoming (having two or more IP addresses) is handled very badly. I have had friends with redundant links through two different ISPs (DSL + cable, for example) and you can make this work--- short-lived HTTP connections load-balance pretty well. But sustained sessions (remote desktops, VPN, etc.) can't be switched from one path to the other, because that TCP connection state is tied to an IP address, which indicates a particular ISP. There is virtually no way to change your route (as an end user) without changing your identity as well.
Large enterprises are able to negotiate service agreements and run VPN connections in such a way as to tie their internal networks together despite this. But the end-to-end argument tells us that reliability, security, and availability are properties that can only be achieved by endpoints working together. IP addresses as endpoint doesn't cut it--- but until that problem is solved, mesh networks will continue to be local-area toys, not censorship-robust Internet access.