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 dtn-interest@xxxxxxxx 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. >