Subject: [icnrg] ICN Packet Exchange "Patterns"

From: <[email-masked]>
Date: Mon, 30 Mar 2015 00:06:46 +0000

I trust everyone got home safely from our IETF extravaganza!

I don't want to get into an Us vs Them regarding Network People and Application People, or vice-versa, but I think ICN is going to require more from Application designers than what they are prepared for — or at least accustomed to.   It’s going to fall to us to spend some time making this stuff understandable and useable by the “Application People.”

We (the ICN community) have been devoted to getting the ICN concepts worked out and how, in many cases, to use these concepts to do what we’re already able to do.   However, as I keep saying, the capabilities of ICN are going to have a significant impact on how future applications are designed.

At one point in Sunday’s discussion, Mark Stapp pointed out that application writers just want to put their bits in and get them out on the other side. Granted, we will undoubtedly have some middle-layer thingamajigs that will give the application writers this point-to-point capability they are accustomed to.   These will be necessary to assure/reassure them that they can do what they’ve always been able to do.

But obviously what ICN brings to the table are these named packets.  If it isn’t clear already, this is not how application designers think about the network. :-)  For ICN to be used to a fuller extent, we should devise, record, and collect a set of exchange patterns and behaviors that enable an application to use ICN for new things.  These patterns are likely to exist in some middle layer above the networking but architecturally below the application itself (I think).

If we don’t, the point-to-point thingamajigs mentioned above will be used everywhere to do everything and ICN will be nothing more.

I will admit that at any given moment, I have both no idea where to start and yet a million ideas of where to start.  Furthermore, at what point does this kind of work move from “networking” into “applications.”  This does blurs the line (cf. Christian Tschudin’s talks on NFN).  Is this going to matter in terms of the venus or bodies that expose and sediment this work?

Anyway… I’m sure this isn’t of interest to everyone, but I’d like to collect at least a set of likeminded 'hand-wringers' to start thinking about various ways to make this happen.

Glenn

---

From: Marie-Jose Montpetit <[email-masked]>
Date: Mon, 30 Mar 2015 00:25:46 +0000

I think my intervention was in the direction of what you are talking about. And of course in the TAPS session I also addressed "applications". But we need to be careful that we talk of applications developers with the "s" being important. There is a huge gap between infrastructure applications where maybe ICN is a hard sell (is it?) and content or service or gaming applications where the idea of "naming things" can be way more acceptable and where finding patterns could even be great. Because of course for all these complex multimedia applications ICNs may prove to be way easier.  So it's not hand wringing.

/mjm
Marie-Jose Montpetit, Ph.D.
[email-masked]
@SocialTVMIT

> On Mar 29, 2015, at 8:06 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 30 Mar 2015 01:35:35 +0100

Hiya,

Apologies if I'm behind the times (I don't keep as up to speed
on this as previously though I wish I could), but...

On 30/03/15 01:06, [email-masked] wrote:
> However, as I keep saying, the capabilities of ICN are going to have
> a significant impact on how future applications are designed.

Do we have a working ICN answer when those application folks say that
they need to do access control?

If (as I think was the case last I looked) the answer is to fall back
to host based networking, then I think that's going to be perceived as
being severely problematic by application developers.

S.

---

From: Börje Ohlman <[email-masked]>
Date: Mon, 30 Mar 2015 08:12:37 +0000

> they need to do access control?

In the Green ICN project they seems to be using ABE. Maybe Jan or Dirk can elaborate?

	Börje

---

From: Mark Stapp <[email-masked]>
Date: Mon, 30 Mar 2015 15:27:03 -0400

Thanks for bringing this up, Glenn.

I didn't mean _quite_ what you suggest in this email. I meant 
"application writers are using fairly high-level abstractions, and they 
don't much care what the networking looks like (in many cases)." I have 
the impression that lots of apps now are written to quite high-level 
frameworks that are specifically designed to hide details of IP 
networking. I think that in those environments, applications express a 
few properties they care about (possibly embedded in a url), and then 
they ask the networking framework to do something.

(full disclosure - I am not any kind of expert in these frameworks, I've 
just read a bit of reference/help material about them.)

I was thinking of things like the networking abstractions in Swift, for 
example, or in the OSX networking 'core framework'. Those sorts of 
things don't look at all like bsd sockets apis: the client application 
code provides input that is something like a url, with some params, and 
viola, instant RESTful networking. and if something like DPRIVE 
converges, the app may get some confidentiality even if it doesn't 
change the url to 'https'.

That sort of abstraction has helped ipv6, for example, because things 
like A vs AAAA name-resolution, AF_INET or AF_INET6, and happy-eyeballs 
are happening ... somewhere else in the framework, not in the 
application-specific code. I was suggesting that support for a future 
'icn' or 'ndn' uri could sort of just arrive with a new version of xcode 
or msdev, at some time in the future.

lots of applications just want to 'get' something, or 'post' something, 
and if ICN can do those things, then lots of applications might be able 
to use ICN. it doesn't really matter to every application whether the 
'object' it retrieves is a 'stream' or a 'content', imo, any more than 
most applications don't care whether they end up using ipv4 or ipv6 
packets. now, as the IP world works harder to make the use of IP support 
some confidentiality, and some authentication, then applications will 
benefit, and those qualities will become the new baseline. if ICN 
*can't* do something that matches the baseline, then ... some 
applications just won't work without some kind of overhaul, and their 
authors may not be interested in doing that work.

so that was one point - that the application-facing baseline is not raw 
ipv4 packets (or raw ethernet frames), or even SOCK_STREAM sockets. 
another point is that the IP baseline is not fixed - it's moving in some 
meaningful ways. I definitely agree that making networking capabilities 
available to applications is interesting and worth thinking about - but 
I'm concerned that ICN is still missing some capabilities (again, imo.)

Thanks,
Mark

On 3/29/15 8:06 PM, [email-masked] wrote:
> I don't want to get into an Us vs Them regarding Network People and
Application People, or vice-versa, but I think ICN is going to require
more from Application designers than what they are prepared for — or at
least accustomed to. It’s going to fall to us to spend some time making
this stuff understandable and useable by the “Application People.”
>
> We (the ICN community) have been devoted to getting the ICN concepts
worked out and how, in many cases, to use these concepts to do what
we’re already able to do. However, as I keep saying, the capabilities of
ICN are going to have a significant impact on how future applications
are designed.
>
> At one point in Sunday’s discussion, Mark Stapp pointed out that
application writers just want to put their bits in and get them out on
the other side. Granted, we will undoubtedly have some middle-layer
thingamajigs that will give the application writers this point-to-point
capability they are accustomed to. These will be necessary to
assure/reassure them that they can do what they’ve always been able to do.
>
> But obviously what ICN brings to the table are these named packets.
> If
it isn’t clear already, this is not how application designers think
about the network. :-) For ICN to be used to a fuller extent, we should
devise, record, and collect a set of exchange patterns and behaviors
that enable an application to use ICN for new things. These patterns are
likely to exist in some middle layer above the networking but
architecturally below the application itself (I think).
>
> If we don’t, the point-to-point thingamajigs mentioned above will be
used everywhere to do everything and ICN will be nothing more.
>
> I will admit that at any given moment, I have both no idea where to
start and yet a million ideas of where to start. Furthermore, at what
point does this kind of work move from “networking” into “applications.”
This does blurs the line (cf. Christian Tschudin’s talks on NFN). Is
this going to matter in terms of the venus or bodies that expose and
sediment this work?
>
> Anyway… I’m sure this isn’t of interest to everyone, but I’d like to
collect at least a set of likeminded 'hand-wringers' to start thinking
about various ways to make this happen.

---

From: Ersin Uzun <[email-masked]>
Date: Mon, 30 Mar 2015 16:10:03 -0700

Encryption based access control methods are well suited for ICNs. Although
host-based point-to-point encryption might still be relevant in some cases
(e.g., real-time authorization, getting the decryption key, etc), I believe
the use cases that "really" need session-based point-to-point encryption
and access control are quite limited. Attached is a paper that will appear
in Networking 2015 in couple of months that shows an initial design of how
to develop such a flexible access control framework in the context of CCNx.

-Ersin

---

From: Ersin Uzun <[email-masked]>
Date: Mon, 30 Mar 2015 16:06:46 -0700

-Ersin