Re: [icnrg] [EXT] ICN (NDN) auto-configuration and self-learning: best practices?

[Dirk Kutscher <[e-mail]>]

Hi Teng,

thanks a lot!

Best regards,
Dirk

On 21 Jul 2022, at 5:59, Teng Liang wrote:

> Hi Dirk,
>
> Self-learning is implemented in NFD as a forwarding strategy. The current
> official version (v1) supports interest broadcast and on-demand route setup
> (i.e., add a route on data reception with prefix announcement attached).
> Self-learning v2 plans to add unicast face setup, and better interest/NACK
> handling. It is still under development, and an unofficial version can be
> found here (https://github.com/philoL/NFD-out-of-the-box).
>
> To use self-learning strategy, one can either use "nfdc strategy" command,
> or configure it in the nfd.config file, e.g., add an entry "/,
> /localhost/nfd/strategy/self-learning" in the strategy_choice (
> https://github.com/named-data/NFD/blob/master/nfd.conf.sample.in#L71).
>
> This tutorial in ICN'20 may be helpful:
> https://conferences.sigcomm.org/acm-icn/2020/tutorial-ndn.html.
>
> Best regards,
> Teng
>
> On Wed, Jul 20, 2022 at 10:19 PM Dirk Kutscher <[e-mail]> wrote:
>
>> Hello,
>>
>> I wanted to check in on the current state of auto-configuration
>> (self-learning) in local networks (single broadcast domains) such as
>> Ethernet networks.
>> Background
>>
>> Auto-configuration in the data plane (self-learning through forwarding)
>> without requiring additional control plane interactions (e.g., routing,
>> configuration) has always been one of the advertized ICN features.
>>
>> For example, in an Ethernet (switched or not), ideally one would be using
>> NDN with Ethernet (L2) faces. When you run NDN applications, what would be
>> the best (reliable, efficient) way to learn about faces and routes to
>> available data in the network? Ethernet broadcast/multicast (every node
>> could have exactly one face) is an option that would surely work, but could
>> incur overheads.
>> Reactive Optimistic Name-based Routing
>>
>> Early work such as Reactive Optimistic Name-based Routing (RONR) for the
>> IoT demonstrated the effectiveness of learning about forwarding options
>> through flooding for discovery and then creating FIB entries based on the
>> observed Data messages.
>> On Broadcast-based Self-Learning
>>
>> The 2017 IFIP Networking paper On Broadcast-based Self-Learning in Named
>> Data Networking [2] discusses several aspects such as prefix granularity,
>> trust of announcements and data, self-learning on switched Ethernet and
>> presented an approach that leverages flood-and-learn" and prefix
>> announcements but includes some additional mechanisms for reducing overhead
>> etc.
>> What is a "Face" in Named Data Networking?
>>
>> Junxiao is discussing the related topics of "what is a face?" (interface
>> vs. node adjacency) and multicast/broadcast in his blog posting [3],
>> motivated by his thoughts on NDNts API Design that he also presented at a
>> past ICNRG meeting [4].
>>
>> He is also discussing ways to deal with L2 remote addresses and alludes to
>> filtering NICs and name-based switching.
>> Forwarder Implementations
>>
>> In the "Wireless Multicast" section in [3], Junxiao describes a model that
>> could be used by consumer forwarders, without requiring name-based
>> switching in the network nor special producer support.
>>
>> In 2020, another implementation attempt was made using two faces: the
>> physical Ethernet adapter for broadcast, and an adjacency face between C
>> and P for unicast. Forwarding logic should extract the unicast address of P
>> in the first Data packet, dynamically create an adjacency face and setup a
>> route, and then send subsequent Interests on that adjacency face. This
>> would not fully insulate the forwarding plane from understanding
>> EndpointId, but it would be limited to the logic that perform this face
>> creation, and hopefully does not need to change everything else.
>>
>> This direction met challenges since the design stage. Generally, face
>> creation and route updates are assumed to infrequent, but dynamic adjacency
>> creation violates this assumption. NFD's architecture could allow the
>> forwarding plane to create adjacency faces. However, the only way to
>> perform a route update is sending a packet to the control plane running on
>> a separate thread, and it isn't possible to send a new packet while
>> processing another packet. Thus, this attempt never got past the design
>> stage.
>>
>> Incidentally, I had used a similar design many years ago for implementing
>> RFC 3259 (on L3 with UDP/IP multicast and unicast).
>>
>> I wondered whether this has been explored further or whether new designs
>> have been tried. The approach outlined above is IMO relatively
>> straight-forward, would rely on Ethernet Spanning Tree and on unicast
>> addressing at the cost of having to creating many faces potentially.
>>
>> I understand that NFD constraints made this difficult to implement. Is
>> this still the current situation?
>>
>> Are there other forwarders that implement this or other approaches?
>> NDN Switch design
>>
>> The paper [2] and Junxiao's blog posting [3] also mention ideas and early
>> work on switch designs that are based on name-based forwarding. In fact,
>> Junxiao has an earlier implementation on OpenWrt [5]. I could imagine that
>> a "production-grade" NDN switch could be quite useful in many scenarios,
>> including the current effort on Big Data processing and distributed
>> computing in NDN.
>>
>> Have there been new attempts, potentially leveraging NDN-DPDK or other
>> modern forwarders?
>>
>> Any pointers, new ideas, feedback on any of these topics would be very
>> welcome!
>>
>> Thanks,
>> Dirk
>> References
>>
>>    1. RONR <https://inet.haw-hamburg.de/papers/bmhsw-icnie-14.pdf>
>>    2. On Broadcast-based Self-Learning in Named Data Networking
>>    <https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=8264832&tag=1>
>>    3. What is a "Face" in Named Data Networking?
>>    <https://yoursunny.com/t/2021/NDN-face/>
>>    4. NDNts API Design
>>    <https://datatracker.ietf.org/meeting/interim-2021-icnrg-01/materials/slides-interim-2021-icnrg-01-sessa-ndnts-api-junxiao-shi-00>
>>    5. (NFD on OpenWrt Home Router)[
>> https://www.slideshare.net/yoursunny/nfd-luci]
>>    6. (RFC 3259: A Message Bus for Local Coordination)[
>> https://www.rfc-editor.org/rfc/rfc3259.html]
>>
>> External Email
>>
>> _______________________________________________
>> icnrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/icnrg
>>