Re: [icnrg] New Version Notification for draft-lindgren-icnrg-efficientiot-02.txt

Anders Lindgren <andersl@sics.se> Tue, 13 January 2015 06:54 UTC

Return-Path: <andersl@sics.se>
X-Original-To: icnrg@ietfa.amsl.com
Delivered-To: icnrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BADF91A8A15 for <icnrg@ietfa.amsl.com>; Mon, 12 Jan 2015 22:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.26
X-Spam-Level:
X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8F3687FLAyH for <icnrg@ietfa.amsl.com>; Mon, 12 Jan 2015 22:54:42 -0800 (PST)
Received: from outbox.sics.se (outbox.sics.se [193.10.64.137]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8421A8A16 for <icnrg@irtf.org>; Mon, 12 Jan 2015 22:54:42 -0800 (PST)
Received: from e-mailfilter01.sunet.se (e-mailfilter01.sunet.se [192.36.171.201]) by outbox.sics.se (Postfix) with ESMTPS id 972AAED6D; Tue, 13 Jan 2015 07:54:39 +0100 (CET)
Received: from norm.sics.se (norm.sics.se [193.10.64.192]) by e-mailfilter01.sunet.se (8.14.4/8.14.4/Debian-4) with ESMTP id t0D6sc2I028020 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 13 Jan 2015 07:54:38 +0100
Received: from [10.3.1.79] (unknown [199.36.244.25]) by norm.sics.se (Postfix) with ESMTPSA id 0E5181A4; Tue, 13 Jan 2015 07:54:36 +0100 (CET)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Anders Lindgren <andersl@sics.se>
In-Reply-To: <alpine.DEB.2.02.1501081559240.29267@cs-meet.cs.unibas.ch>
Date: Tue, 13 Jan 2015 07:54:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E9D44B63-D635-43CD-9EAC-344BF158A941@sics.se>
References: <20150108115700.6538.91253.idtracker@ietfa.amsl.com> <794B8A00-BB9E-487D-8CD1-1F3591EC5C26@sics.se> <alpine.DEB.2.02.1501081559240.29267@cs-meet.cs.unibas.ch>
To: christian.tschudin@unibas.ch
X-Mailer: Apple Mail (2.1878.6)
X-Bayes-Prob: 0.005 (Score 0, tokens from: outbound, outbound-sics-se:default, sics-se:default, base:default, @@RPTN)
X-p0f-Info: os=Linux 2.2.x-3.x, link=Ethernet or modem
X-CanIt-Geo: ip=199.36.244.25; country=US; region=Nevada; city=Las Vegas; latitude=36.1100; longitude=-115.2118; http://maps.google.com/maps?q=36.1100,-115.2118&z=6
X-CanItPRO-Stream: outbound-sics-se:outbound (inherits from outbound-sics-se:default, sics-se:default, base:default)
X-Canit-Stats-ID: 09NDiSCMr - d6842a557c69 - 20150113
X-Antispam-Training-Forget: https://canit.sunet.se/canit/b.php?i=09NDiSCMr&m=d6842a557c69&t=20150113&c=f
X-Antispam-Training-Nonspam: https://canit.sunet.se/canit/b.php?i=09NDiSCMr&m=d6842a557c69&t=20150113&c=n
X-Antispam-Training-Spam: https://canit.sunet.se/canit/b.php?i=09NDiSCMr&m=d6842a557c69&t=20150113&c=s
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.201
Archived-At: <http://mailarchive.ietf.org/arch/msg/icnrg/kdfAQYTA3-4Ee26Uc_zjRecbgmw>
Cc: icnrg@irtf.org
Subject: Re: [icnrg] New Version Notification for draft-lindgren-icnrg-efficientiot-02.txt
X-BeenThere: icnrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Information-Centric Networking research group discussion list <icnrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/icnrg>, <mailto:icnrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/icnrg/>
List-Post: <mailto:icnrg@irtf.org>
List-Help: <mailto:icnrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/icnrg>, <mailto:icnrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jan 2015 06:54:45 -0000

Hi Christian,

One of the things that we tried to explain better in this version of the draft (but maybe we need to do an even better job of it) based on comments received on the previous version is that 
we do not necessarily see every node as either an ”IoT node” or ”ICN node”, but rather that ”IoT functionality” and ”ICN functionality” (and I suppose that we could add ”named function functionality” here as well) are logically distinct roles, and a node may choose to only implement one of these roles. There might however also be many nodes that want to implement all those roles.

See you tomorrow in Boston!

/A

8 jan 2015 kl. 16:42 skrev christian.tschudin@unibas.ch:

> Hi Anders,
> 
> thanks for sharing this with us - an interesting read, clear language and positions, I like that.
> 
> Let me react with a high level observation: you mainly declare an IoT world that is "named function"-free. All processing is at the edge and in applications, never in intermediate nodes.
> 
> And I have the feeling that by doing a strict term replacement of s/IoT/High Speed ICN/g, it would be same, clear and valid document.
> 
> The resulting argumentation pattern is that because of the technical constraints at these two ends of the spectrum, we better define ICN as something where names are never worked on inside the network.
> 
> Should we call this the tiranny of the extremists? Because clearly, if ICN is mass-adopted, all smart phones, multi-core tablets, residential gateways, cloud portals, big data repos and server farms will NOT have these constraints.
> 
> [But even at the extreme ends, be it IoT or high speed forwarding, I dare to predict that name rewriting and in-network processing is inevitable and needs a way to be expressed.]
> 
> While this is a debate where we need time and more thoughts, the current question (i.e. next week) is on the table how packet formats should look like. I hope that this debate is not dominated by extremist views and that there will be hooks for richer expressiveness than the single map-name-to-bytes semantics enriched with segment numbers.
> 
> One architectural answer in my opinion is that we have to envisage, from the start, a multi-domain world where gateways will bridge the "challenged domains" like high speed and IoT with the rest of the world. I'm biased here, of course: these gateways will be multi-protocol-aware and are the natural habitat for named function processing.
> 
> Best,
> christian
> 
> 
> On Thu, 8 Jan 2015, Anders Lindgren wrote:
> 
>> Hi all,
>> 
>> We have posted a new version of our draft on Applicability and Tradeoffs of Information-Centric Networking for Efficient IoT and I plan to present it at the interim meeting in Boston next week.
>> 
>> /Anders
>> 
>> Vidarebefordrat brev:
>> 
>>> Från: internet-drafts@ietf.org
>>> Ämne: New Version Notification for draft-lindgren-icnrg-efficientiot-02.txt
>>> Datum: 8 januari 2015 12:57:00 CET
>>> Till: Bengt Ahlgren <bengta@sics.se>, "Anders F. Lindgren" <andersl@sics.se>, Fehmi Ben Abdesslem <fehmi@sics.se>, "Fehmi Ben Abdesslem" <fehmi@sics.se>, Adeel Mohammad Malik <adeel.mohammad.malik@ericsson.com>, Olov Schelen <olov.schelen@ltu.se>, "Anders Lindgren" <andersl@sics.se>, "Olov Schelen" <olov.schelen@ltu.se>, "Adeel Mohammad Malik" <adeel.mohammad.malik@ericsson.com>, "Bengt Ahlgren" <bengta@sics.se>
>>> 
>>> 
>>> A new version of I-D, draft-lindgren-icnrg-efficientiot-02.txt
>>> has been successfully submitted by Anders F. Lindgren and posted to the
>>> IETF repository.
>>> 
>>> Name:		draft-lindgren-icnrg-efficientiot
>>> Revision:	02
>>> Title:		Applicability and Tradeoffs of Information-Centric Networking for Efficient IoT
>>> Document date:	2015-01-08
>>> Group:		Individual Submission
>>> Pages:		20
>>> URL:            http://www.ietf.org/internet-drafts/draft-lindgren-icnrg-efficientiot-02.txt
>>> Status:         https://datatracker.ietf.org/doc/draft-lindgren-icnrg-efficientiot/
>>> Htmlized:       http://tools.ietf.org/html/draft-lindgren-icnrg-efficientiot-02
>>> Diff:           http://www.ietf.org/rfcdiff?url2=draft-lindgren-icnrg-efficientiot-02
>>> 
>>> Abstract:
>>>  This document outlines the tradeoffs involved in utilizing
>>>  Information Centric Networking (ICN) for the Internet of Things (IoT)
>>>  scenarios.  It describes the contexts and applications where the IoT
>>>  would benefit from ICN, and where a host-centric approach would be
>>>  better.  The requirements imposed by the heterogeneous nature of IoT
>>>  networks are discussed (e.g., in terms of connectivity, power
>>>  availability, computational and storage capacity).  Design choices
>>>  are then proposed for an IoT architecture to handle these
>>>  requirements, while providing efficiency and scalability.  An
>>>  objective is to not require any IoT specific changes of the ICN
>>>  architecture per se, but we do indicate some potential modifications
>>>  of ICN that would improve efficiency and scalability for IoT and
>>>  other applications.
>>> 
>>>  This document mainly serves as a problem statement and will not
>>>  present a conclusive architecture design.  It can be used as a basis
>>>  for further discussion and to design architectures for the IoT.
>>> 
>>> 
>>> 
>>> 
>>> Please note that it may take a couple of minutes from the time of submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> _______________________________________________
>> icnrg mailing list
>> icnrg@irtf.org
>> https://www.irtf.org/mailman/listinfo/icnrg