NNSquad - Network Neutrality Squad
NNSquad Home Page
[ NNSquad ] Re: If this had been an actual emergency ...
I agree that we don't want to be simplistic. It's just that today we have the extreme of cloud dependency. Maps are good example -- you don't need to have all the rich information locally but I would like say as to what is available. This is why I try to avoid the term cache which implicitly implies implicit but prefer to manage availability. Emergency workers will need much more information for example though, perhaps, we all need to be ready just in case. It's not just the map data -- it's connectivity. If there is a disaster I want peer protocols that allow us to communicate without depending on servers far away or even a local cell tower. Our phones are loaded with radios -- even FM receivers but they can't easily talk to each other without special hacks. You can't just tell the voice and SMS traffic to relay. Voice might be problematic but certainly messaging should be able to continue to work as long as there is any path available even if 100 hops. GPS too is a problem in that it is now totally dependent upon satellites. Skyhook Wireless, Google and others are developing backup databases of alternate sources such as MAC addresses and cellular towers. There are all these hacks but we lack the coherent architecture vision beyond today's Internet. [ Having spent a lot of time working with radios both professionally and as a Ham, I continue to be dubious re multihop communications scenarios such as you outline, for a variety of reliability and other reasons. That said, the ability to switch cell phones into a "point to point walkie-talkie mode" between multiple cooperating units could have significant utility in emergency situations. As for Google and others building up databases of MAC addresses, etc. for backup comm purposes -- you're well familiar with the thanks Google got for that -- a pile of misguided lawsuits/complaints claiming they were purposely spying on Wi-Fi users. Good deeds getting punished, as usual. -- Lauren Weinstein NNSquad Moderator ] - - - -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Lauren Weinstein Sent: Monday, November 29, 2010 14:55 To: email@example.com Subject: [ NNSquad ] Re: If this had been an actual emergency ... On 11/29 09:06, Bob Frankston wrote: > We can think of Comcast's outage as a test of the emergency cloud > broadcasting system and it failed miserably. > One of the more important (and fascinating from a research standpoint) aspects of "cloud computing" is how to sufficently "harden" and "stage" data to avoid or minimize these sorts of problems. The nightmare scenario is total communications breakdown of course -- but odds are if that happens we'll be dealing with even more severe problems (e.g., during an earthquake -- and having been through two major ones here in L.A., that's not a theoretical for me). The navigation question is a toughie. Obviously a standalone GPS (hardware, or software-based on a phone with local map data) avoids this problem entirely, at the cost of less up to date data at least part of the time. But perhaps a middle ground is to keep the most commonly used data locally on the phone even for normally cloud-based navigation services. For example, if there's an earthquake, as long as I have basic L.A. area navigation data available on the phone without a data connection being needed, that's probably all I'm going to need until I get out of the local area. The flip-side to all this is that there are situations where *not* having the data locally can be a big win. If a hospital's files and IT are damaged in a disaster of some sort, being able to retrieve patient data from "the cloud" elsewhere could be very important. So as usual, these aren't simplistic situations either way. --Lauren-- NNSquad Moderator - - - On 11/29 09:06, Bob Frankston wrote: > We can think of Comcast's outage as a test of the emergency cloud > broadcasting system and it failed miserably. > > > > Imagine needing help during an emergency and being told, "Sorry, the can't > reach the cloud so all your medical information is unavailable and we can't > open our offices". We need to be very cautious about unnecessary > dependencies and unnecessary tethering. > > > > The "cloud" (whatever people now mean by the term) can be an immensely > useful resource but we have to be wary of dependency. Imagine having to > navigate during an earthquake only to find the Google Maps doesn't work > because it doesn't work if the cell towers are out - a distinct possibility > during an Earthquake. At a simply annoying level it's often unavailable when > traveling, especially for a US traveler abroad. Maybe more than annoying if > you are lost. >