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

From: "Dirk Kutscher" <[email-masked]>
Date: Wed, 13 Sep 2017 17:59:37 +0200

Hi all,

JFYI, we are going to hold a panel discussion on this topic at the 
upcoming ICNRG interim meeting on September 29 in Berlin.

The general idea is that, based on what has been discussed so far, we 
want to make some progress in a f2f discussion.

If you have interest in actively contributing, please let us know.

Thanks,
Dirk, Dave, Nörje

On 2 Aug 2017, at 14:45, Cenk Gündoğan wrote:

> 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/
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg