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(_at_)irtf(_dot_)org 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.