On 03/02/2013 10:54 AM, Fred Baker (fred) wrote: > From my perspective, an important technical challenge in coming years might > be a variation on delay-tolerant networking. We have done a fair bit of work > in this area, for some definition of "we" - SOAP, Saratoga, and the NASA/JPL > DTNrg work. As Dave Crocker likes to point out, we actually have a canonical > DTN application and specification we all use - SMTP. > > In your blog, you mentioned emergency communications. Emergency > communications are all about ensuring the ability to deliver a message end to > end at a time when the intervening network is strenuously overloaded, > chaotic, or randomly connected. The canonical examples include events like > the fall of the twin towers, where half of the US undersea cable connectivity > to Europe was cut by a falling building, hurricanes like Katrina or Sandy, or > massive cyber-attacks; more run-of-the-mill models might come in the Smart > Objects domain of telemetry.
<dtnrg-co-chair-hat> Cool. As it happens, DTNRG folks agreed last summer to start work on a bis version of the bundle protocol (RFC5050), and now that we've gotten a few other things out of the way, we should be starting in on that real soon now. So if that does happen, then I'd say now's a great time to get involved in DTN stuff. Discussion will be on [email protected] and the RG may well meet at the July IETF to talk in detail about that. If anyone's interested in having a chat in Orlando, just ping me and if there's enough of us, I'll see if we can find a spot/slot to chat. DTN details can be found at [1]. </dtnrg-co-chair-hat> Cheers, S. [1] http://www.dtnrg.org/wiki > One example of a delay-tolerant network was Tsinghua's experiment in > measuring Beijing pollution. They put sensors and GPS units on taxis; every > time a taxi stopped, it asked its GPS where it was and what time it was, > asked its sensors for their data, and packaged the lot together into a > reading. I think they also asked for time in queue - when did the taxi stop, > and when did it subsequently change its position significantly. Every time > the taxi passed a bus, it synchronized with a wifi SSID on the bus, and > uploaded all of its data from the past hour or two. Every time the bus went > through a central station, it synchronized with a central reader and uploaded > its cached readings to Tsinghua. Net result - Tsinghua got a whole lot of > data on taxi routes, congested intersections, and pollution data. Individual > readings were delivered tens to hundreds of times and sorted out by the > analytic process. They developed what they described to us as a fairly > sophisticated model. > > I'm obviously not thinking, in this, about VoIP or Video/IP, although I could > imagine the Internet of Stuff implementing those in some way such as carrying > attachments (think HeyTell). I'm thinking more in the direction of IM or > email. The key thing is a service for containerized freight, if you will. I > can think of military applications, and a variety of telemetry applications > in the Internet of Stuff, which could include anything from meter reading to > variations on middleware-controlled communications. > > In any event, I could imagine future requirements that could build on such a > model, perhaps built in JSON or XML. >
