Subject: Re: [icnrg] ICN Packet Exchange "Patterns"

From: <[email-masked]>
Date: Wed, 1 Apr 2015 22:45:00 +0000

This came up in an out-of-band discussion (paraphrasing accurately I hope):

"I remember a video in which Van described the current network layer abstraction asking for ‘Who' and its distance to the application layer, that is actually asking for "What", and the need for middleware to fill this _huge gap_.  Now I see you saying: '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.'  Isn't this _patterns and behaviors exchange_ something like the current middleware?"

Yes, but more.  Clearly we are still talking about the application asking for What and now the network layer can also be asked for What.  It’s likely that what the application requests for will be turned into smaller requests that actually fit into packets.   So there is some middleware doing that.  But, yes, we’re getting rid of the “who” part.

But after using this network for a while, I think there is even more.  That’s my notion about “fuller extent” and “new things."

If we leave it to the application writers to devise their own ways of using CCN, I expect that they will simply devise a point-to-point connection mechanism that behaves like the point-to-point connections we have today.  Which is fine.  Even in that scenario, the CCN behaviors of PIT aggregation and content caching may offer some benefit. I understand that for some, that will be enough.  But, again, I think there is more.

For me the open question is, can we devise a set of packet exchanges that let us create a locking protocol, or a synchronization protocol across the network?  How about a set of packet protocols to do queues or variety of distributed processing primitives?  How about network primitives that implement a Krivine machine?  These are clearly more than what the application writers expect of the network today — bits-in, bits-out.

Glenn