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

From: Anders Lindgren <[email-masked]>
Date: Thu, 8 Jan 2015 12:59:20 +0100

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: [email-masked]
> Ämne: New Version Notification for draft-lindgren-icnrg-efficientiot-02.txt
> Datum: 8 januari 2015 12:57:00 CET
> Till: Bengt Ahlgren <[email-masked]>, "Anders F. Lindgren" <[email-masked]>, Fehmi Ben Abdesslem <[email-masked]>, "Fehmi Ben Abdesslem" <[email-masked]>, Adeel Mohammad Malik <[email-masked]>, Olov Schelen <[email-masked]>, "Anders Lindgren" <[email-masked]>, "Olov Schelen" <[email-masked]>, "Adeel Mohammad Malik" <[email-masked]>, "Bengt Ahlgren" <[email-masked]>
> 
> 
> 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
>

---

From: [email-masked]
Date: Thu, 8 Jan 2015 16:42:36 +0100 (CET)

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:

> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: Mark Stapp <[email-masked]>
Date: Thu, 08 Jan 2015 12:13:03 -0500

hmm: I think this is a bit strong:

On 1/8/15 10:42 AM, [email-masked] wrote:
> Should we call this the tiranny of the extremists?

[...]
> map-name-to-bytes semantics enriched with segment numbers.

I don't think this is "tyranny" or even "extreme". CCN/NDN has a couple 
of core properties, and we're trying to discover whether those 
properties compose a system that actually ... works. getting some 
focussed discussion on what is actually in a name, for example, seems 
... far from "extreme" to me. it is not glamorous to be sure, to ask 
folks to say "we have to have such-and-such available" or "we must NOT 
have such-and-such", and to ask them to write that down, and support 
those assertions. but I think that's a good way to highlight the 
underlying assumptions and semantic issues about what NDN can express, 
and how.

I appreciate your advocacy for "named functions", but that capability 
seems to me to be one of the various interesting services that an 
ICN-ish network might support. I'm not convinced that the concept needs 
to be included in every discussion or accomodated as a core property.

-- Mark

---

From: [email-masked]
Date: Thu, 8 Jan 2015 22:03:51 +0100 (CET)

> hmm: I think this is a bit strong:
...
> I appreciate your advocacy for "named functions", but that capability seems 
> to me to be one of the various interesting services that an ICN-ish network 
> might support. I'm not convinced that the concept needs to be included in 
> every discussion or accomodated as a core property.

point taken, no problem. Suggesting that I ask for "accomodation as a 
core property" might be strong, too? ;-)

However, I consent with the extremist label for myself when it comes to 
multi-protocol support. For example, I would be very much in favor of 
self-declaration in form of an additional type field in the fixed header 
saying "I'm carrying ccnb stuff", "I'm cisco2015", "I'm NDN". This would 
clarify what the version field is about: it's the version of the fixed 
header and nothing more, not the version of the carried protocol data 
units.

Views?

best, christian

> I don't think this is "tyranny" or even "extreme". CCN/NDN has a couple of 
> core properties, and we're trying to discover whether those properties 
> compose a system that actually ... works. getting some focussed discussion on 
> what is actually in a name, for example, seems ... far from "extreme" to me. 
> it is not glamorous to be sure, to ask folks to say "we have to have 
> such-and-such available" or "we must NOT have such-and-such", and to ask them 
> to write that down, and support those assertions. but I think that's a good 
> way to highlight the underlying assumptions and semantic issues about what 
> NDN can express, and how.
>
> -- Mark

---

From: David Oran <[email-masked]>
Date: Thu, 8 Jan 2015 15:52:15 -0800

> On Jan 8, 2015, at 1:03 PM, [email-masked] wrote:
> 
>> I appreciate your advocacy for "named functions", but that capability seems to me to be one of the various interesting services that an ICN-ish network might support. I'm not convinced that the concept needs to be included in every discussion or accomodated as a core property.
> 
> point taken, no problem. Suggesting that I ask for "accomodation as a core property" might be strong, too? ;-)
> 
> However, I consent with the extremist label for myself when it comes to multi-protocol support. For example, I would be very much in favor of self-declaration in form of an additional type field in the fixed header saying "I'm carrying ccnb stuff", "I'm cisco2015", "I'm NDN". This would clarify what the version field is about: it's the version of the fixed header and nothing more, not the version of the carried protocol data units.
> 
> Views?
> 
Interesting idea, definitely worth considering given that we may want to independently evolve the parts of the protocol that have application significance from the parts that are confined to “internal layer” operation.

> best, christian
> 
> 
>> I don't think this is "tyranny" or even "extreme". CCN/NDN has a couple of core properties, and we're trying to discover whether those properties compose a system that actually ... works. getting some focussed discussion on what is actually in a name, for example, seems ... far from "extreme" to me. it is not glamorous to be sure, to ask folks to say "we have to have such-and-such available" or "we must NOT have such-and-such", and to ask them to write that down, and support those assertions. but I think that's a good way to highlight the underlying assumptions and semantic issues about what NDN can express, and how.
>> 
>> -- Mark
>

---

From: Anders Lindgren <[email-masked]>
Date: Tue, 13 Jan 2015 07:54:34 +0100

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 [email-masked]:

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