Subject: [dtn-interest] Fwd: Re: IETF Challenges - DTN and the Internet of Stuff

From: Stephen Farrell <[email-masked]>
Date: Sun, 03 Mar 2013 13:23:10 +0000

FYI for those not on the main ietf discussion list.
Full thread involves other stuff but starts at [1].

I think it'd be timely for us to start discussion about
that 5050bis topic in the next few weeks, probably after
next week's Orlando IETF meeting is done.

So if people with ideas could sharpen those over the
next two weeks ready to start the discussion, that'd be
great.

S.

[1] http://www.ietf.org/mail-archive/web/ietf/current/msg77405.html

-------- Original Message --------
Subject: Re: IETF Challenges - DTN and the Internet of Stuff
Date: Sat, 02 Mar 2013 11:42:37 +0000
From: Stephen Farrell <[email-masked]>
To: Fred Baker (fred) <[email-masked]>
CC: [email-masked] <[email-masked]>

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-masked] 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.
>

---

From: Vint Cerf <[email-masked]>
Date: Sun, 3 Mar 2013 09:11:55 -0500

see:

https://docs.google.com/file/d/0B0IeBYngPBqkOGJPMVNBM0VCNnM/edit?usp=sharing

or search for "desirable properties of a national PSN"

see footnote 23 on page 12 for reference to DTN.

vint

On Sun, Mar 3, 2013 at 8:23 AM, Stephen Farrell
<[email-masked]>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>
>
> > 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.
> >
>
>
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>

---

From: Eric Travis <[email-masked]>
Date: Fri, 8 Mar 2013 22:08:31 -0500

Stephen,

| I think it'd be timely for us to start discussion about
| that 5050bis topic in the next few weeks, probably after
| next week's Orlando IETF meeting is done.
|
| So if people with ideas could sharpen those over the
| next two weeks ready to start the discussion, that'd be
| great.

I have to admire a fellow who, when encountering a (potentially large)
powder keg, sends out for kerosene and checks his pocket for dry matches…

Prior to opening discussion, it might be helpful if the chairs provided a
bit of guidance (bounding of the scope and goals) to focus the revision
effort.  There is little benefit to opening (heated) discussion on topics
considered to be either too ambitious or disruptive to to the status quo of
the particular DTN variant supported by RFC 5050.

The raw-minutes from the July Google offsite (
http://down.dsg.cs.tcd.ie/dtnrg-at-google-12/raw-mins.txt) are a bit rough,
but seem to suggest some goals/guidance to build upon.

Eric

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 09 Mar 2013 13:07:34 +0000

Hi Eric,

> powder keg, sends out for kerosene and checks his pocket for dry matches…

:-)

> but seem to suggest some goals/guidance to build upon.

Yes, I do plan to summarise that when I've a chance. (Or if someone
else who was there would like to do that, that'd be just fine.)

The main constraints I recall were that a 5050bis would have to
easily allow for gatewaying with 5050 so that, in particular, the
space folks wouldn't be discommoded, and that the list of iccky
things we've noticed over the last few years ought be addressed
(time, simpler security, checksums,...).

Personally, other than those constraints I hope we start out being
very open-minded about it all.

Cheers,
S.