Disconnected life in a connected world

While on sabbatical, moving from country to country, we've periodically lost reasonable connectivity options: an iPhone is more than happy to roam, but once you notice that the $10/day charges are accumulating you quickly take the phone off the network.  The days of open WiFi are long past, and so you find yourself moving from one pool of WiFi connectivity to another with big disconnected gaps in between.

This, of course, is a common pattern: all of us experience such events when driving or in trains, or in situations with poor cellular signals, and for people in the military, police, fire, or other first-responder roles, there is also the issue of being in a setting that may have experienced a major disruption, so that things like cellular phones are down.

Life in that disconnected edge has become precarious and in some ways, dangerous.  A soldier who loses connectivity is at risk from "friendly fire": the good guys won't know who her or she is, but might see movement and fire.  An emergency responder entering an area devastated by a tornado won't know where the other team members are, what's been searched and what hasn't, and might have trouble calling for reinforcements.   The automated self-driving car might find itself in fully autonomous mode, and as I've mentioned several times, I happen to think that self-driving cars that don't slave themselves to smart highway systems will be a menace.

The core problem is that as the world migrates more and more strongly to a cloud-centric model, we are on the one hand increasingly dependent on cloud-hosted applications and infrastructure, and yet on the other hand, are also forced to operate without that infrastructure support whenever disconnected.

What can be done?  I used to work on gossip and peer to peer protocols, and some believe that mesh networks offer a possible response: at a minimum, an emergency response team or a squad of ground troops would have connectivity between themselves, which is already an improvement, and if one of the team members has visibility to a satellite or an orbiting drone that can relay network messages, we could even cobble together a form of Internet connectivity.

But mesh connectivity is, I think, of limited value.  The protocols for establishing a peering relationship between mobile nodes are surprisingly slow, especially if it needs to be authenticated, and TCP performs poorly on such connections because of their relatively high loss rates.  UDP datagram protocols would be a better option, but we lack a form of UDP that could avoid the initial peering dialog: you would want a kind of UDP "anycast" (accepted by any node within range), but you only get something more like UDP tunneled over a hardware level secure channel that needs a whole three-way handshake to establish.

Similarly, while I love gossip protocols, I honestly don't see much of a fit.  We want a very limited kind of communication between nearby peers, and reach-back to the cloud when feasible.  Gossip imagines a whole different model based on one to all broadcast (like for Bitcoin) and to me, that just isn't a match to this use case.

Today's approach is useful, even if not universal.  For example, a kind of long-term "quasi-static" mesh connectivity (based on connections that are costly to create but that endure for a long time) can work in situations like a military patrol, where connectivity is continuous even though the squad loses reach-back to the base.  But for other cases, like groups of self-driving cars, I don't see it as a good option.  In this I'm at odds with the self-driving car community; they are great fans of convoy-style protocols in which groups of cars get near one-another, connect, and cooperate for short periods of time; my belief is that forming the communication group will take so long that the cars could easily already have banged into one-another before the first message can be sent. 

I think we need new hardware and new software, and a new push to create a mode in which cloud computing applications could routinely disconnect for periods of time but continue to operate with lightweight mobile peering relationships.  Thus first, you need a model of cloud computing that understands disconnection; we have parts of the solution, but not all.  Next, we need hardware that can support an unpeered wireless connectivity model in which nearby nodes could sense one-another very rapidly and exchange unreliable datagrams without any prior setup (if the military or police would like a special secure mode with stronger connections, no problem, but it should run over this weaker packet mode, not the other way around).  And finally, we would want to use this functionality to show that we could create peered groups of cars in milliseconds, rather than seconds to minutes as seems to be the case today. 

None of these strikes me as technically doubtful.  The big win is that we could move towards an increasingly nimble style of sometimes-connected functionality.  When connected to the cloud, applications would have all the benefits of cloud computing that we enjoy (and are becoming very dependent upon) today.  But when connectivity is poor, at least nearby cars could coordinate to avoid crashing into one-another, or nearby emergency responders could cooperate to efficiently search a damaged building for survivors.  For IoT scenarios, we could leverage this same functionality to support rapid interrogation of nearby devices, or quick sharing of data with them.

Up to now, the cloud hasn't really needed disconnected mobility, so perhaps it isn't surprisingly that the cloud and the edge devices try quite so hard to operate in a mode that mimics TCP, or even TCP with SSL security.  But times are changing, and we need a new edge model that can better match the real use cases.