IETF Challenges - DTN and the Internet of Stuff

"Fred Baker (fred)" <fred@cisco.com> Sat, 02 March 2013 10:54 UTC

Return-Path: <fred@cisco.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B5821F90FB for <ietf@ietfa.amsl.com>; Sat, 2 Mar 2013 02:54:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.495
X-Spam-Level:
X-Spam-Status: No, score=-110.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7AIjQpcFV9y for <ietf@ietfa.amsl.com>; Sat, 2 Mar 2013 02:54:37 -0800 (PST)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E1E1F21F90F6 for <ietf@ietf.org>; Sat, 2 Mar 2013 02:54:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2620; q=dns/txt; s=iport; t=1362221677; x=1363431277; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=XeEzrp54kx8tktUTEilrCbNw+VhNID2tm0istaD7pic=; b=k7x57+62tRB3B9y9A8Gu3yh4UXXoPQMKe8EzBSrEqr28nCwChEVbh7bz xiK+RhA+DSXg6IyDvvoFKdSdFtunJI/tSdELrKeeXb9yP8IGpL+AgFw5h EGmBwnYg1CoAcbTO5KZ8Dk67aEaSyim6nJpoS70l+CujLDnJpGSh7kto7 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAFPZMVGtJV2b/2dsb2JhbABEwkV8FnOCIQEEOj8SASoUQicEDg2IC68dkUqNTIEgMYJmYQOnLoMIgXI1
X-IronPort-AV: E=Sophos; i="4.84,767,1355097600"; d="scan'208,223"; a="182923900"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 02 Mar 2013 10:54:36 +0000
Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r22Asa7J002604 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Mar 2013 10:54:36 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sat, 2 Mar 2013 04:54:36 -0600
From: "Fred Baker (fred)" <fred@cisco.com>
To: Jari Arkko <jari.arkko@piuha.net>
Subject: IETF Challenges - DTN and the Internet of Stuff
Thread-Topic: IETF Challenges - DTN and the Internet of Stuff
Thread-Index: AQHOFzRTeun6/47J4kSX5dDZ7ErAiw==
Date: Sat, 02 Mar 2013 10:54:34 +0000
Message-ID: <8C48B86A895913448548E6D15DA7553B7BB253@xmb-rcd-x09.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.19.64.117]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CDA9FB55DF089842962EC5F2EA0E8909@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Mar 2013 10:54:38 -0000

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

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.