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

From: Cenk Gündoğan <[email-masked]>
Date: Wed, 2 Aug 2017 14:45:35 +0200

Hello Christian, all,

sorry for hopping in so late; I hope we can keep this discussion running.

@Christian: Your proposition of utilizing a link-local RPC technique for
streaming in CCNx/NDN and to drive ICMP like messaging sounds quite
intriguing. For reference, I copied your RPC example from one of your
previous mails below.

> 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

While I actually like this approach – it is self-contained and still
consumer-driven – I observe a few drawbacks. In general ICMP, we have
this fire-and-forget notion (state handling is ontop of ICMP, like in
PING or NDP). The above RPC scheme contradicts this by introducing a
setup and teardown phase as well as soft states that need keep-alives.
So based on the premise (and please correct me if I understood you
wrongly) that your viewpoint is to introduce ICMP ontop of RPC, I would
rather propose the other way around. RPC is the more feature-rich
technique and may be built using ICMP like link-local messaging in ICN.

The signaling and propagation of control information (e.g. for routing
protocols) is essential and as Dave pointed out in the ICNRG meeting
@Prague, control plane sits ontop of the data plane, like UDP or ICMP
are ontop of IP. However, with the current data plane of CCNx/NDN, we
are bound to Interest or Data, from which the Interest is the most
suited type for such signaling. We saw how Interests are (ab)?used for
this purpose: Interest notification (encode data in name or payload),
Interest polling, Interest-Data/Interest-Data handshakes,... yet, at the
end of the day, this signaling packet is still an Interest, i.e., it is
subject to the general CCNx/NDN state machine: a) check the CS, b) check
the PIT, c) check the FIB. Several drawbacks exist when reusing the
Interest:
    * requires a separate namespace
    * the CS is searched for something that does not represent data
    * the PIT needs some adjustments to *not* do any kind of Interest
      aggregation for signaling Interests as, by design, signaling must
      reach the application sitting ontop the network stack (above PIT).

So, a link-local signaling (let it be through an ICMP facsimile or
something else), would require IMO another packet type that is
orthogonal to what Interest and Data provide. A packet type that does
not transition the CCNx/NDN state machine (no need to query content in
the CS, use Interest for that) and would therefore "run in parallel"
(like Christian wrote in a previous mail) due to the orthogonality to
plain Interest-Data. It is crucial that such signaling is bound to the
link and is not forwarded beyond to reduce the attack surface.

And, to close the circle, this is actually the starting point of this
discussion. In our proposal of the Pub-Sub deployment option we build a
sink tree and for this, signaling (much like in the RPC diagram) is
necessary, but IMO there is no clean solution for this yet (or I am
blinded by my ignorance).

Cheers,
Cenk

On 17-07-23 19:03:09, [email-masked] wrote:
> 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:
> 
> > On 21.07.2017 18:42, [email-masked] wrote:
> > 
> > > 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).
> > 
> > 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
> > confined messaging.
> 
> 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.
> 
> > > 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.
> > 
> > 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.
> 
> RPC is not ARP. Can you expand on how ipv6 insights would work against RPC?
> 
> > > 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:
> > 
> > ... 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.
> 
> > ICN request-response semantic also lives on a 'pretty high' level in the
> > 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
> 
> > 
> > Best,
> > Thomas
> > 
> > > 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?
> > > > 
> > > > * 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
> > > > 
> > > > On 20.07.2017 20:43, [email-masked] wrote:
> > > > > 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
> > > > > 
> > > > > 
> > > > > On Thu, 20 Jul 2017, Dirk Kutscher wrote:
> > > > > 
> > > > > > 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.
> > > > > > > 
> > > > > > > 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 °
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > icnrg mailing list
> > > > > > > [email-masked]
> > > > > > > https://www.irtf.org/mailman/listinfo/icnrg
> > > > > > 
> > > > > > _______________________________________________
> > > > > > icnrg mailing list
> > > > > > [email-masked]
> > > > > > https://www.irtf.org/mailman/listinfo/icnrg
> > > > > > 
> > > > > 
> > > > 
> > > > -- 
> > > > 
> > > > 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 °
> > > > 
> > > 
> > 
> > -- 
> > 
> > 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 °
> > 

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

-- 
Cenk Gündoğan

Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: [email-masked]
Web: https://www.inet.haw-hamburg.de/