Subject: [icnrg] Do we need an ICMP for ICN?

From: "Thomas C. Schmidt" <[email-masked]>
Date: Wed, 19 Jul 2017 16:44:02 +0200

Hi,

we want to continue the lively discussion of today's meeting on "how to 
do control messaging" in ICN.

We made the case for a new message kind in ICN that

  * is unidirectional + stateless
  * carries simple control state (e.g., names)
  * is strictly link-local
  * follows FIB (or broadcast)

So it's something like a restricted, tiny ICMP (or IGMP/MLD).

Key arguments for this are

  * most appropriate for transporting control information
  * does not twist/overload Interest semantics (or even syntax)
  * clearly (and cleanly) treatable in the stack
  * preserves the CCN/NDN request-response logic on the network
  * does not introduce push-based threats (except for link jamming, 
which Interests could also do)

Key counterarguments are now requested from the group ;)

Best,
  Thomas

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: "Dirk Kutscher" <[email-masked]>
Date: Thu, 20 Jul 2017 10:59:18 +0200

Hi Thomas,

Thanks for kicking off this discussion.

Considering that we are doing a lot with name and namespace designs, how 
bad would using Interests messages and a dedicated namespace for 
link-local management communication really be? Are there other issues 
besides style?

Dirk

On 19 Jul 2017, at 16:44, Thomas C. Schmidt wrote:

> Hi,
>
> we want to continue the lively discussion of today's meeting on "how 
> to do control messaging" in ICN.
>
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg

---

From: "David Oran" <[email-masked]>
Date: Thu, 20 Jul 2017 11:06:08 +0200

On 20 Jul 2017, at 10:59, Dirk Kutscher wrote:

> Considering that we are doing a lot with name and namespace designs, 
> how bad would using Interests messages and a dedicated namespace for 
The other thing I’m failing to grasp is that if every node is an ICN 
forwarder, then normal interests and data are actually forwarded “hop 
by hop”. So I’m somewhat failing to see how this special message 
actually achieves something that cannot be achieved with normal 
interests, possibly augmented by a special “forwarding strategy” for 
interests directed at names published by the content proxy under a local 
name prefix.

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 20 Jul 2017 15:19:06 +0200

Hi Dirk,

> link-local management communication really be? Are there other issues

An answer could start with the caveat: "the CCN/NDN packet semantic is 
much more pronounced than that of plain IP"

The Semantic of Interest packets I know reads:

  1) request for named data (don't carry data)
  2) initiate a response
  3) travel onward according to FIB, if not satisfied locally

which means that a stack does not expect data in an Interest packet and 
does open a response 'transaction' (incl. possible PIT state(s)) for it.

So I would say, selecting special names/namespaces for link-local 
management is easy going with 3), but somewhat difficult with 1) and 2).

An example of being difficult is the 'Interest-follows-Interest' approach:
Here, we need
   * three packets, and
   * one transaction timeout, and
   * one overload of the Interest semantic
to inform a local neighbor for example about a new FIB entry.

On the other hand, if we name a packet Interest, use it to transport 
data, and don't associate a content request with it, then this is badly 
overloading the CCN/NDN semantic and confusing. Part of the confusion 
also is that such a "Notification Interest" (if not constrained 
otherwise) re-introduces all the DDoS potentials of IP, which CCN/NDN 
originally wanted to overcome.

Cheers,
  Thomas

--

---

From: "David Oran" <[email-masked]>
Date: Thu, 20 Jul 2017 15:44:39 +0200

On 20 Jul 2017, at 15:19, Thomas C. Schmidt wrote:

>> how
Interest messages in CCNx can have a (small) payload field, useful in 
cases where you have some extra information not useful for routing that 
does not need to be “echoed back” in the response.

>  2) initiate a response
correct.

>  3) travel onward according to FIB, if not satisfied locally
correct.

> which means that a stack does not expect data in an Interest packet 
> and does open a response 'transaction' (incl. possible PIT state(s)) 
> for it.
>
yes, there is PIT state. Not sure why this is a problem.

> An example of being difficult is the 'Interest-follows-Interest' 
three instead of two? if you set short Interest timeouts then the PIT 
state will not persist very long and if you want you can just time out 
instead of responding.

>   * one transaction timeout, and
yes, one PIT timeout. What I’d like to understand, is what is the 
timeout behavior for the state installed by the proposed new message? If 
you don’t have any then I’m even more confused than I thought.

> to inform a local neighbor for example about a new FIB entry.
Here is where I got most confused. If you are going to install state (a 
new FIB entry), you need to authenticate the packet in some way, 
otherwise you are open to state creation / route hijacking attacks. How 
is this done with the NAM message? If you do interest/data (and don’t 
try to optimize out the data response from the content proxy, then the 
response can be signed in such a way that nodes know it is a 
“blessed” route advertisement. Since the content proxy is the root 
of this edge routing tree, it can tell if multiple nodes are attempting 
to announce the same prefix and either refuse based on some criteria 
like a signature on the Interest, or allow multiple sources to claim to 
be the publisher and install multiple routes.

> data, and don't associate a content request with it, then this is 
> badly overloading the CCN/NDN semantic and confusing.
For the general case of carrying arbitrary data I agree with this, 
however using Interest as a trigger or as a way to initiate a route 
installation is not such a semantic overloading in my view. For another 
example, if you like trace-based mobility protocols (which I don’t but 
that’s another subject), NDN KITE uses an Interest/Data exchange 
initiated from the mobile node to install a transitory mobility anchor 
pointing to the reverse path.

> Part of the confusion also is that such a "Notification Interest" (if 
> not constrained otherwise) re-introduces all the DDoS potentials of 
> IP, which CCN/NDN originally wanted to overcome.
>
I disagree with this. All Interests have to be rate controlled anyway 
for both congestion and DoS reasons. Having one more usage doesn’t 
change what you need to implement and execute.

Best,

DaveO.

---

From: [email-masked]
Date: Thu, 20 Jul 2017 20:43:02 +0200 (CEST)

I'm jumping in late, too bad I could not be present at the meeting.

My viewpoint is: we should introduce ICMP as one use-case of a new 
mechanics at link-level, RPC, and do this below ICN.

I think it was with Marc Mosko that I once discussed different "styles":
- one that starts from above - the ICN name-space
- one that starts from below - link-level RPC
(and net mtgt was a topic at one Dagstuhl seminar).

Passing control parameters are much more natural in an RPC world where 
one can also have link- and service-tailored semantics (SNMP and ICMP 
are limited to at-least-once, I guess). Much work on TLV encoding can be 
inherited, though.

Lifting ICMP to ICN level will always collide with the rules in place 
there (namespace, interest aggregation, working around caches etc) so I 
would prefer it to have it run in parallel to, not inside, an ICN, 
although it probably will share some of the datastructures.

The RPC view fits well with NFN in the sense that I suggest to name 
remote functions, but the namespace would be distinct:
- use remote function call to negotiate a secure link, secure association
- use remote function call to explore a neighbor's capabilities
- use remote function to do ICMP requests, conditional on provided credentials
- use remote function call to ask neighbor to handle this NDN interest
   (running over the encrypted link)
- use remote function call to ask neighbor to handle this CCNx content
   (using a specific fragmentation protocol)

In other words, this link-layer RPC becomes the multiplexer and 
hypervisor protocol - ICN is about virtualizing networks, after all. One 
could also look at NETCONF (RFC6241) ... once we strip out XML and go 
back to datagram instead of connection-oriented 8-)

Some traces of this RPC exploration are still in the CCN-lite code, I think.

best, c

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 21 Jul 2017 09:57:01 +0200

Hi Christian,

I'm a bit confused:

  * with link-level, you mean Layer2, i.e. the MAC layer? As of a 
protocol, something like ARP?

  * with RPC you refer to Remote Procedure Call?? At L2, this would be a 
procedural interaction between drivers/network stacks?

Our former discussion was about messages on the ICN network layer. 
Link-local in this context referred to 'Hopcound=1' (or a message that 
is not forwarded on the network layer).

The figurative protocol name 'ICMP' referred to a plain, unidirectional, 
strictly local messaging that remains bound to the control plane. So: no 
multihop, no (data) interface to the application.

Best,
  Thomas

--

---

From: [email-masked]
Date: Fri, 21 Jul 2017 18:42:46 +0200 (CEST)

Hi Thomas,

I try to argue that there is a larger solution space we should consider, 
with architecturally cleaner points. What you seem to be discussing is 
the "from above style", wanting to make underground stuff visible (and 
by that taint the location transparency).

Re link-level - this can be L2 but also includes the Internet fabric in 
case of an ICN overlay: anything that links two ICN routers.

Re RPC: yes, interaction between drivers/network stacks separated by a 
single hop.

I'm not in favor of unidirectional messaging, even not for ICMP error 
notifications, EXCEPT it is framed in an outer RPC call that was setup 
to stream multiple messages (this is how it's called in protobuf terms, 
see 
https://developers.google.com/protocol-buffers/docs/techniques#streaming). 
It's the consumer end of pubsub, really:

c->s: please stream notifications (RPC starts)

c<-s: ok, service starts now

c<-s: notif1
c<-s: notif2
c<-s: notif3

c->s: keep-alive

c<-s: notif4
c<-s: notif5
c<-s: ...

c->s: stop it

c<-s: notification service (and RPC call) ends

best, c

On Fri, 21 Jul 2017, Thomas C. Schmidt wrote:

> Hi Christian,
>
> I'm a bit confused:
>
> * with link-level, you mean Layer2, i.e. the MAC layer? As of a protocol, 
> something like ARP?
>
> Our former discussion was about messages on the ICN network layer. Link-local 
> in this context referred to 'Hopcound=1' (or a message that is not forwarded 
> on the network layer).
>

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 22 Jul 2017 13:47:11 +0200

Hi Christian,

thanks for the feedback ... please see inline.

> by that taint the location transparency).

No: location transparency is not touched by exchanging location 
information. Every routing protocol - and ICN (CCN/NDN) urgently do need 
routing protocols - is required to exchange topological information. 
This may be link availability (surveying, maintaining) or neighborship 
relations. For name-based routing, it must be names.
We rose the question whether this needs a lightweight, but reasonably 
confined messaging.

> case of an ICN overlay: anything that links two ICN routers.

I wouldn't like an "ICN Network layer" to only function with specific 
"subnetwork-functions" in place. I guess IPv6 people have learned their 
lesson from ARP.

> It's the consumer end of pubsub, really:

... mhmm: this is a matter of perspective, I guess. An ICMP message 
could be viewed as an RPC call with fixed remote function for that 
message (in the stack). Instead of RPC(redirect, nexthop) we have the 
message REDIRECT(nexthop).

Still, protobuf  is a high-level tightly-coupled distribution mechanism 
on the application layer. protobuf actually works only because TCP/IP is 
already bootstrapped and in place.

ICN request-response semantic also lives on a 'pretty high' level in the 
sense that bootstrapping, routing, management, maintenance etc. is 
difficult. Most mechanisms either rely on broadcast (e.g., chronosync), 
  some artificial overloading, or some miracle "beyond the scope of the 
paper".

We are trying to open the discussion on the lower level: loosely 
coupled, fairly independent (wireless) nodes try to establish an ICN 
network layer that actually can transport named content as desired.

We acknowledge there is broadcast (of Interests), we object any 
network-wide push, as this spoils the CCN/NDN core, but have the 
impression that we need the additional ability to say "hello" to our 
neighbors.

Best,
  Thomas

--

---

From: [email-masked]
Date: Sun, 23 Jul 2017 19:03:09 +0200 (CEST)

Hi Thomas,

is this one of these boundaries where two communities (networking and 
distributed systems) could be close but vocabulary and current practice 
is impeding it?

I'm trying to answer along this suspicion, see more inline ...

On Sat, 22 Jul 2017, Thomas C. Schmidt wrote:

> No: location transparency is not touched by exchanging location information.

But you would expose/lift this information into the ICN namespace, 
right? That is not, in my view, location transparent naming. It is not 
the single publisher anymore that makes content available, but billions 
of publishers all using the same name: I cannot, when abroad and using 
*that* name, query the content that my homegateway is producing, 
violating the expectation that I fetch content by name regardless of 
location: this becomes a different kind of name, with a smell...

> Every routing protocol - and ICN (CCN/NDN) urgently do need routing protocols 
> - is required to exchange topological information. This may be link 
> availability (surveying, maintaining) or neighborship relations. For 
> name-based routing, it must be names.

Agreed. But this is done either under the hood or in a correct ICN 
namespace where topology as well as router ids are correctly mapped, for 
example in the NDN testbed where content produced by routers is 
accessible ... from anywhere.

> We rose the question whether this needs a lightweight, but reasonably 

I reckon that by "messaging" we talk about the mechanics how the ICN 
semantics, including routing, is achieved, right? I'm fine with that, 
just that I think this should happen under the hood, not at ICN 
namespace level.

> "subnetwork-functions" in place. I guess IPv6 people have learned their 

RPC is not ARP. Can you expand on how ipv6 insights would work against 
RPC?

> ... mhmm: this is a matter of perspective, I guess. An ICMP message could be 
> viewed as an RPC call

My example suggested a different implementation: (unsolicited) ICMP 
messages are fine IF embedded in an outer RPC call (to some fixed remote 
subscription function) that asked for such notifications.

> with fixed remote function for that message (in the 
> stack). Instead of RPC(redirect, nexthop) we have the message 
> REDIRECT(nexthop).

Agreed on this, it is different: here your ICMP message requests a 
service (and I think that RPC is the way to handle it, I definitely 
prefer the RPC(fctname, param) encoding).

> Still, protobuf  is a high-level tightly-coupled distribution mechanism on 
> the application layer. protobuf actually works only because TCP/IP is already 
> bootstrapped and in place.

That is where practice and perception may be impeding. Sun RPC (RFC 
1831) runs also over UDP. Dave Oran pointed out to me a marvelous paper 
from Apollo Computers from 1988, 
http://jim.rees.org/apollo-archive/papers/ncs.pdf.gz

This is really good stuff. I use it now in my classes and claim that the 
five paragraphs on page 12 starting with "All that the NCA/RPC protocol 
assumes is an underlying unreliable network service." capture the core 
of RPC, demonstrate its versatility. This IS messaging-level talk (real 
networkers use messages), not the glossy leaflet on the Google site for 
OO- and Java programmers.

> sense that bootstrapping, routing, management, maintenance etc. is difficult.

I respectfully disagree: The request-response semantics would benefit 
(would have benefitted?) from being embedded in full RPC, it is too 
"messaging" level.

> Most mechanisms either rely on broadcast (e.g., chronosync),  some artificial 
> overloading, or some miracle "beyond the scope of the paper".

... which is another way of saying that the apps have to compensate for 
that shortcoming, right?

> We are trying to open the discussion on the lower level: loosely coupled, 
> fairly independent (wireless) nodes try to establish an ICN network layer 
> that actually can transport named content as desired.

Fine with me, I'm open to gossip style or whatever (even w/o RPC) it 
takes as an under-the-hood technique to provide the same ICN 
abstraction, permitting to couple that network segment to the rest of 
the ICN world. But this does not mean that the rest of the ICN world has 
to introduce these under-the-hood techniques, too, and you share that 
view if I correctly understand your following paragraph:

> We acknowledge there is broadcast (of Interests), we object any network-wide 
> push, as this spoils the CCN/NDN core, but have the impression that we need 
> the additional ability to say "hello" to our neighbors.

Trying to draw a perimeter here: Your interest is in a MANET-dependent 
discussion how to implement ICN. If this is true I would phrase your 
statement slightly differently:

"We acknowledge there is broadcast (of Interest-like messagelets), we 
object any ICN-level push messages, as this spoils the CCN/NDN core, but 
have the impression that we need the additional ability to say "hello" 
with messagelets to our neighbors in order to implement full Interest- 
and Data messages across the MANET."

How much agreement/disagreement does this trigger?

best, c

>>> Link-local