Dirk Kutscher

The ACM Information-Centric Networking 2022 Conference took place in Osaka from September 19 to 21 2022, hosted by Osaka University. It was a three-day conference with tutorials, one keynote, two panel session, and paper and poster/demo presentations. The highlights (with links to papers and presentations) from my perspective were the following:

Keynote by Dave Oran: Travels with ICN – The road traversed and the road ahead

Dave Oran presented an overview of his research experience over the last ten years that was informed by many seminal research contributions on ICN and his career in the network vendor sector as well as in standards and research bodies such as the IETF and IRTF.

The keynote's theme was about disentagling the application and network layer aspects of ICN, which led to interesting perspectives on some of the previous design decisions in CCNx and NDN.

As ilustrated in the figure below, the more networking-minded ICN topics are typically connected to features and challenges of building packet-forwarding networks based on the principle of accessing named data. The actual research questions are generally not different to those of IP networks (routing, mobility etc.), but ICN provides a significant potential to re-think and often improve over the specific approaches in IP networks due to its core properties such as object security and symmetric, stateful forwarding.

Information-centric applications development in contrast is often concerned with general naming concepts, namespace design, and security features that are enabled by namespace design and application layer object security such as trust schema and provenance.

The message in Dave's talk was not that these are completely disjunct areas that should best be investigated independent of each other, but rather that the ICN's fascination and disruptive potential is based on the potential for rethinking layer boundaries and contemplating a better function split between applications, network stacks on endpoints, and forwarding elements in the network. In his talk, Dave focused on

• the Interaction of consumers & networking producers of data;
• routing;
• forwarding; and
• congestion control.

He discussed many lessons learned as well as open research and new ideas for all of these topics – please refer to the presentation slides for details.

One particularly interesting current ICN research topic is distributed computing and ICN architectures & interaction models for that. ICN's name-based forwarding model and object security provide very interesting options for simplifying systems such as microservices, RESTful services and distributed application coordination. Alluding to our work on Reflexive Forwarding, Dave offered two main lessons learned from building corresponding communication abstractions:

1. Content fetch with two-way handshakes is a poor match for doing distributed computations.

2. Extensions to the base protocols can give a flexible underpinning for multiple interaction models

This raises the question of the slim waist of ICN, i.e., as research progresses, what should be the minimal feature set and what is the right extensibility model?

Dave concluded his talk with a few interesting questions:

• how can the networking insights we’ve gained from ICN protocols inform the construction of Information Centric systems and applications?

  • Whether and how to utilize name-based routing to achieve robustness and performance scaling for distributed applications?
  • Where does caching help or not help and how to best utilize caches?
  • Does pushing Names down to lower layers help latency? Resilience? Fairness?

• How can the insights we’ve gained from applying Information Centricity in applications inform what we bother to change the network to do, and what not?

  • Do things like multipath forwarding, in-network retransmission, or reflexive forwarding actually enable applications that are hard or infeasible to do without them?
  • Is there a big win for wireless networks in terms of optimizing a scarce resource or having more robust and responsive mobility characteristics?

More details in the presentation slides

Panel: ICN and the Metaverse – Challenges and Opportunities

I had the pleasure of being in a panel with Jeff Burke (UCLA) and Geoff Houston (APNIC), moderated by Alexander Afanasyev (Florida International University) discussing Metaverse challenges and opportunities for ICN.

Questions on Metaverse and ICN

Large-scale interactive and networked AR/VR/XR systems are now referred to as Metaverse, and the general assumption is that corresponding applications will be hosted on platforms, similar to those that are employed for web and social media applications today.

In the web, the platform approach has led to an accelerated development and growth of a few popular mainstream systems. On the other hand, several problems have been observed such as ubiquitous surveillance, lock-in effects, centralization, innovation stagnation, and cost overhead for achieving the required performance.

While these phenomena may have both technical and economic root causes, we would like to discuss:

• How should Metaverse systems be designed, and what would be important architectural pillars?
• What is the potential for re-imagining Metaverse with information-centric concepts and protocols?
• Would ICN enable or lead to profound architecturally unique approaches – or would protocols such as NDN be a drop-in replacement for QUIC, HTTP3 etc.?
• What are the challenges for building ICN-based Metaverse systems, and what it missing in today's ICN platforms?

As input to the discussion, Jeff Burke and myself (together with Dave Oran) submitted two papers:

• Jeff Burke: Statement: As TCP/IP is to the web, ICN is to the…?
• Dirk Kutscher and David Oran: RESTful information-centric networking: statement

Research Directions

Jeff offered a list of really interesting research directions based on the notion that in the Metaverse, host-based identifiers and end-to-end connections between hosts would be abstracted even further away than in today’s web. Client devices would fade into the background in favor of the data supplanting or augmenting the real world. Thus, a metaverse consisted of information not associated with the physical world unless it needed to describe or provide interaction with it. The experiential semantics were viscerally information-centric, which would help to motivate the ICN research opportunities such as:

• Persistence: The information forming a metaverse persists across sessions and users.

• “Content” and Interoperability: Designing the relationships among metaverse-layer objects and the named packets that an ICN network moves and stores.

• Naming and Spatial Organization: How to best integrate knowledge from research in databases and related fields where these challenges have been considered for decades.

• Trust, Provenance, and Transactions: Using ICN to disentangle metaverse objects from the security provided by a source or a given channel of communication, with the named data representation secured at the time of publication instead.

RESTful ICN

In our paper on RESTFul ICN, Dave Oran and I asked the question: given that most web applications are concerned with transferring named units of data (web resources, video chunks etc.), can the REST paradigm be married with the data-oriented, receiver-driven operation of Information-Centric Networking (ICN), leveraging attractive ICN benefits such as consumer anonymity, stateful and symmetric forwarding, flow-balance in-network caching, and implicit object security?

We argue that this is feasible given some of the recent advances in ICN protocol development and that the resulting suite is simpler and potentially having better performance and robustness properties. Our sketch of an ICN based protocol framework addresses secure and efficient establishment and continuation of REST communication sessions, without giving up key ICN properties, such as consumer anonymity and flow balance.

Panel Discussion

The panel discussed the current socio-economic realities in the Internet and the Web and explored opportunities (and non-opportunities) for redesigns, and how ICN could be a potential enabler for that.

My personal view is that most of the potential dystopian outcomes of future Metaverse applications are independent from the enabling networking technology and the technology stack at large (security, naming etc.). It is really important to understand the actual objectives of a specific systems, i.e., who operates to which ends, similar to so-called social networks today. If the main objective is to create a more powerful advertising and manipulation platform, then such as system will exhibit yet unimaginable surveillance and tracking mechanisms – independent of the underlying network stack.

With respect to the technical design, I agree to Jeff Burke's proposed research directions. One particularly interesting question will be how to design a Information-Centric communication stack and corresponding APIs. I argued that it is not necessary to replicate existing interaction styles and protocol stacks from the TCP/IP (or QUIC) world. Instead it should be more interesting and productive to discuss the fundamentally needed interaction classes such as

• High-performance multi-destination transfer
• Group communication and synchronization
• High-performance session-oriented communication with servers and peers (for which we proposed RESTful ICN).

The panel then also discussed how likely non-mainstream Metaverse systems would be adopted and whether the current socio-economic environment actually allows for that level of permissionless innovation – considering the network effects that Metaverse systems would be subjected to, much in the same way as so-called social networks.

Panel: Hard Lessons for ICN from IP Multicast?

Thomas Schmidt (HAW Hamburg) moderated a panel discussion with Jon Crowcroft (University of Cambridge), Dave Oran, and George Xylomenos (Athens University of Economics and Business) as panelists.

With the continued shift towards more and more live video streaming services over the Internet, scalable multi-destination delivery has become more relevant again. For example, the recently chartered IETF Working Group on Media over QUIC (MOQ), is addressing the need for scalable multi-destination delivery and the unavailability of IP multicast as a platform by developing a QUIC-based overlay system that essentially uses information-centric concepts, albeit in a QUIC overlay network. Such system would consist of a network of QUIC proxies, connected via individual QUIC connections to emulate request forwarding and chunk-based video data distribution. Considering the non-negligible overhead and complexity one might ask the question whether live video streaming over the Internet could be served by a better approach. Questions like this are being asked by the network service provider community (ISPs have to bear a lot of the overhead and overlay complexity) as well, for example in this APNIC blog posting by Jake Holland titled Why inter-domain multicast now makes sense.

This panel was inspired by a statement paper submitted by Jon Crowcroft titled [Hard lessons for ICN from IP multicast (https://dl.acm.org/doi/10.1145/3517212.3558086). In this brief statement, Jon traced the line of thought from Internet multicast through to Information Centric Networking, and used this to outline what he thinks should have been the priorities in ICN work from the start.

The statement paper discusses a few problems with IP multicast that have been largely acknowledged such as difficulties in creating viable business models, unsolved security problems such as IP multicast being used as a DDOS platform, and interdomain multicast that proven difficult to establish due multicast routing scaling problems and the lack of robust pricing models. The second part of the paper is then some ICN work that has been addressing some of the mentioned issued.

The paper gave rise to an interesting and controversial discussion at the panel. The most important point is IMO to characterize ICN communication model correctly: it is correct that the combination of stateful forwarding, Interest aggregation, and caching enables an implicit multi-destination delivery service. It is implicit, because consumers that ask for the same units of named data within a time frame at the order of the network RTT will send equivalent Interest messages so that forwarders can multicast the data delivery to the faces they received such Interests from. In conjunction with opportunistic (or managed) caching by forwarders this would enable a very elegant multi-destination delivery services that can even cater to a wider variation of Interest sending times, as "late" Interest would be answered from caches.

This is a different service model compared to the push-based IP multicast model. ICN does not provide such as service in the first place, but is just applying its regular receiver-driven mode of operation which elegantly works well in the case of multiple consumers asking for the same data. It is probably fair to say that the ICN model caters to media-delivery use cases (one stream delivered to multiple consumers) but does not try to provide the more general IP multicast service model (Any Source Multicast). However, by extension, the ICN approach could be applied to multi-source scenarios as well – the system would build implicit delivery trees from any source to current consumers, without requiring extra machinery.

With this, if you like, simpler service model, ICN does fundamentally not inherit many of the problems that prohibit IP multicast in the Internet: the system is receiver-driven which simply eliminates DDOS threats (on the packet level). It is also not clear, whether ICN would need anything special to provide this service in inter-domain settings (except for general ICN routing in the Internet, which is a general,
but different research question).

Acknowledging this conceptual and practical difference, there are obviously other interesting research questions that ICN multi-destination delivery entails, for example performance and jitter reduction in the presence of caching and other transport questions.

Overall, a good time to talk about multi-destination delivery and to keep thinking about missing pieces and potential future work in ICN.

Enabling Distributed Applications

One paper presentation session was focused on distributed applications – a very interesting and relevant ICN research area. It featured three great papers:

SoK: The evolution of distributed dataset synchronization solutions in NDN

This paper by Philipp Moll, Varun Patil, Lan Wang, and Lixia Zhang systemizes the knowledge about distributed dataset synchronisation in ICN, or Sync in short, which, according to the authors, plays the role of a transport service in the Named Data Networking (NDN) architecture. A number of NDN Sync protocols have been developed over the last decade. For this paper, they conducted a systematic examination of NDN Sync protocol designs, identified common design patterns, revealed insights behind different design approaches,
and collected lessons learned over the years.

Sync enables new ways of thinking about coordination and general communication in distributed ICN systems, and I encourage everyone to read this for a good overview of the different proposed systems and their properties.

There are also some open research questions around Sync, such as large-scale applicability, alternative to using Interest multicast for discovery and more – a good topic to work on!

DICer: distributed coordination for in-network computations

This paper by Uthra Ambalavanan, Dennis Grewe, Naresh Nayak, Liming Liu, Nitinder Mohan, and Jörg Ott is a nice product of the Piccolo project that had the pleasure to set up and co-lead.

Application domains such as automotive and the Internet of Things may benefit from in-network computing to reduce the distance data travels through the network and the response time. Information Centric Networking (ICN) based compute frameworks such as Named Function Networking (NFN) are promising options due to their location independence and loosely-coupled communication model.

However, unlike current operations, such solutions may benefit from orchestration across the compute nodes to use the available resources in the network better. In this paper, the authors adopted the State Vector Synchronization (SVS), an application dataset synchronization protocol in ICN, to enhance the neighborhood knowledge of in-network compute nodes in a distributed fashion. They designed distributed coordination for in-network computation (DICer) that assists the service deployments by improving the resolution of compute requests.

Kua: a distributed object store over named data networking

This paper by Varun Patil, Hemil Desai, and Lixia Zhang decribes a distributed object store in NDN.

Applications such as machine learning training systems or log collection generate and consume large amounts of data. Object storage systems provide a simple abstraction to store and access such large datasets. These datasets are typically larger than the capacities of individual storage servers, and require fault tolerance through replication. This paper presents Kua, a distributed object storage system built over Named Data Networking (NDN).

The data-centric nature of NDN helps Kua maintain a simple design while catering to requirements of storing large objects, providing fault tolerance, low latency and strong consistency guarantees, along with data-centric security.

ICN Applications and Wireless Networking

The session on ICN Applications and Wireless Networking features four papers:

N-DISE: NDN-based data distribution for large-scale data-intensive science

This paper by Yuanhao Wu, Faruk Volkan Mutlu, et al. describes an NDN for Data-Intensive Science Experiments (N-DISE).

To meet unprecedented challenges faced by the world’s largest data- and network-intensive science programs, the authors designed and implemented a new, highly efficient and field-tested data distribution, caching, access and analysis system for the Large Hadron Collider (LHC) high energy physics (HEP) network and other major science programs. They developed a hierarchical Named Data Networking (NDN) naming scheme for HEP data, implemented new consumer and producer applications to interface with the high-performance NDNDPDK forwarder, and buildt on recently developed high-throughput NDN caching and forwarding methods.

The experiemts in this paper include delivering LHC data over the wide area network (WAN) testbed at throughputs exceeding 31 Gbps between Caltech and StarLight, with dramatically reduced download time.

Building a secure mHealth data sharing infrastructure over NDN

In this paper Saurab Dulal, Nasir Ali, et al. describes an NDN-based mHealth system called mGuard.

Exploratory efforts in mobile health (mHealth) data collection and sharing have achieved promising results. However, fine-grained contextual access control and real-time data sharing are two of the remaining challenges in enabling temporally-precise mHealth intervention. The authors have developed an NDN based system called mGuard to address these challenges. mGuard provides a pub-sub API to let users subscribe to real-time mHealth data streams, and uses name-based access control policies and key-policy attribute-based encryption to grant fine-grained data access to authorized users based on contextual information.

Delay-tolerant ICN and its application to LoRa

I have co-authored this paper together with Peter Kietzmann, José Alamos, Thomas C. Schmidt, and Matthias Wählisch.

Connecting low-power long-range wireless networks, such as LoRa, to the Internet imposes significant challenges because of the vastly longer round-trip-times (RTTs) in these constrained networks. In our paper on "Delay-Tolerant ICN and Its Application to LoRa" we present an Information-Centric Networking (ICN) protocol framework that enables robust and efficient delay-tolerant communication to edge networks, including but not limited to LoRa. Our approach provides ICN-idiomatic communication between networks with vastly different RTTs for different use cases. We applied this framework to LoRa, enabling end-to-end consumer-to-LoRa-producer interaction over an ICN-Internet and asynchronous ("push") data production in the LoRa edge. Instead of using LoRaWAN, we implemented an IEEE 802.15.4e DSME MAC layer on top of the LoRa PHY layer and ICN protocol mechanisms in the RIOT operating system.

For our experiments, we connected constrained LoRa nodes and gateways on IoT hardware platforms to a regular, emulated ICN network and performed a series of measurements that demonstrate robustness and efficiency improvements compared to standard ICN.

iCast: dynamic information-centric cross-layer multicast for wireless edge network

This paper by Tianlong Li, Tian Song, Yating Yang, and Jike Yang presents iCast, short for dynamic information-centric multicast, to enable dynamic multicast in the link layer.

Native multicast support in Named Data Networking (NDN)
is an attractive feature, as multicast content delivery can reduce the redundant traffic and improve the network performance, especially in wireless edge networks. With their visibility into Interest and Data names, NDN routers automatically aggregate the same requests from different end hosts and establish network-layer multicast. However,
the current link-layer multicast based on host-centric MAC address management is inflexible. Consequently, supporting NDN dynamic multicast with the current link-layer architecture remains a challenge.

iCast enables dynamic multicast in the link layer based on three main contributions:

1. iCast integrates NDN native multicast with the host-centric link layer while maintaining the host-centric properties of the current link layer.
2. iCast achieves per-packet dynamic multicast in the link layer, and the authors further propose a hash-based iCast variant for dynamic connection.
3. iCast has been implemented in a real testbed, and the evaluation results show that iCast reduces up to 59.53% traffic compared with vanilla NDN. iCast bridges the gap between NDN multicast and the host-centric link-layer multicast.

Web applications today utilize the Representational State Transfer (REST) architecture pattern, depending on HTTP, TLS, and either TCP or QUIC as the protocol substrate to build upon. The resulting protocol stacks can be quite complex, and the RESTful communication is locked into channel-like connections of the respective transport protocol.

Given that most web applications are concerned with transferring named units of data (web resources, video chunks etc.), we asked ourselves: can the REST paradigm be married with the data-oriented, receiver-driven operation of Information-Centric Networking (ICN), leveraging attractive ICN benefits such as consumer anonymity, stateful and symmetric forwarding, flow-balance in-network caching, and implicit object security?

We argue that this is feasible given some of the recent advances in ICN protocol development and that the resulting suite is simpler and potentially having better performance and robustness properties. Our sketch of an ICN based protocol framework addresses secure and efficient establishment and continuation of REST communication sessions, without giving up key ICN properties, such as consumer anonymity and flow balance.

Representational State Transfer in the Web Today

The Web today is based on an extended version of the Representational State Transfer (REST) architecture pattern for client-server interaction. This simple model has been extended and applied to HTTP for web applications by supporting not only retrieval, but also creation, processing, and deletion of data. Real-world REST systems employ additional concepts and mechanisms such as security and privacy, support for application sessions, and have various optimizations to eliminate unnecessary round-trips.

REST and ICN

Since nearly all web applications today are based on the RESTful client-server communication model, the question then occurs how such interactions can be achieved in ICN, i.e., secure and confidential RESTful access to web resources, with support for efficient handling of a sequence of interactions in a session-like context.

The applicability of ICN's Interest/Data interaction to modern web applications that provide a significant amount of data in requests headers for cookies and other request parameters has been assessed by Moiseenko et al., concluding that it is not immediately clear how to use ICN effectively for web communication. We have also argued in our earlier RICE paper on Remote Method Invocation in ICN that the basic Interest/Data exchange model of CCNx/NDN-style ICN is not sufficient and that certain use cases (e.g., sending resource representations or request parameters from a client to a server) should not be implemented by overloading the Interest message.

In draft-oran-icnrg-reflexive-forwarding, we have discussed the specific problems extensively. In its default mode, ICN also lacks name privacy, which we consider essential for any real-world application of ICN to web services. However, various techniques have been developed to improve name privacy in ICN, such as the onion routing approach in ANDaNA (Anonymous Named Data Networking Application).

In our vision paper on RESTful Information-Centric Networking at [ACM ICN-2022 (https://conferences2.sigcomm.org/acm-icn/2022/), we argue that an ICN-based RESTful programming model that overcomes these limitations is feasible given some of the recent advances in ICN protocol development and provide the outline of the corresponding protocol framework.

HTTP has been extended and partially redesigned over time, and provides its own idiosyncratic conventions and mechanisms, e.g., which request-relevant information to represent in the URI vs. message headers vs. message bodies. The goal of this work is not to simply map current HTTP mechanisms to ICN, but rather to provide an ICN-idiomatic platform for RESTful applications including an Information-Centric web.

Any ICN web platform will only be useful and relevant if it provides equivalent (or better) security and privacy properties as the state-of-art, i.e., HTTP3 over QUIC and TLS 1.3, so our proposed framework provides a TLS-like security context for RESTful communication (sessions). Also, RESTful ICN should not compromise on existing ICN benefits such as consumer anonymity and consumer mobility.

Our technical design integrates CCNx Key Exchange (a TLS-1.3-like key exchang protocol for ICN) and our Reflexive Forwarding scheme for ICN, and uses that for providing symmetric key derivation and efficient RESTful communication and session resumption in an ICN-idiomatic way. Please check out our paper for details.

References

• Dirk Kutscher and David Oran. 2022; RESTful information-centric networking: statement; In Proceedings of the 9th ACM Conference on Information-Centric Networking (ICN '22); Association for Computing Machinery, New York, NY, USA, 150–152. https://doi.org/10.1145/3517212.3558089
• ACM ICN-2022
• David Oran and Dirk Kutscher; Reflexive Forwarding for CCNx and NDN Protocols; Internet Draft draft-oran-icnrg-reflexive-forwarding, Work in Progress
• Marc Mosko, Ersin Uzun, Christopher A. Wood; CCNx Key Exchange Protocol Version 1.0; Internet Draft draft-wood-icnrg-ccnxkeyexchange-02, Work in Progress; January 2018

Abstract

Connecting low-power long-range wireless networks, such as LoRa, to the Internet imposes significant challenges because of the vastly longer round-trip-times (RTTs) in these constrained networks. In our newly published paper on "Delay-Tolerant ICN and Its Application to LoRa" at ACM ICN-2022, we present an Information-Centric Networking (ICN) protocol framework that enables robust and efficient delay-tolerant communication to edge networks, including but not limited to LoRa. Our approach provides ICN-idiomatic communication between networks with vastly different RTTs for different use cases. We applied this framework to LoRa, enabling end-to-end consumer-to-LoRa-producer interaction over an ICN-Internet and asynchronous ("push") data production in the LoRa edge. Instead of using LoRaWAN, we implemented an IEEE 802.15.4e DSME MAC layer on top of the LoRa PHY layer and ICN protocol mechanisms in the RIOT operating system. For our experiments, we connected constrained LoRa nodes and gateways on IoT hardware platforms to a regular, emulated ICN network and performed a series of measurements that demonstrate robustness and efficiency improvements compared to standard ICN.

Challenging Bi-Directional LoRa Communication

LoRaWAN provides a vertically integrated network architecture for connecting LoRa networks and its constrained devices to the Internet that is designed to offload power-constrained gateways relay communication between the wireless link and network servers (often co-located with additional application server infrastructure) that manage the intricate energy-conservation regime of connected LoRa devices.

The energy conservation objectives lead to a MAC layer design that incurs dramatically higher latency and round trip times (RTTs) of several seconds, compared to what connection-oriented Internet transport protocols are typically designed to support. As a result, LoRaWAN supports message-oriented transport through gateways and dedicated network servers only, without a notion of end-to-end communication from the Internet to LoRa nodes. While it is theoretically possible to run bidirectional IP-based communication on top of LoRaWAN, the resulting systems inherit latency challenges of LoRaWAN for bi-directional communication that would impact transport layer performance and applicability.

Delay-Tolerant Information-Centric Networking

Information-Centric Networking (ICN) has demonstrated benefits for improving data availability and communication performance in constrained IoT networks.

In a newly published paper on "Delay-Tolerant ICN and Its Application to LoRa" at ACM ICN-2022, Peter Kietzmann, José Alamos, Thomas Schmidt, Matthias Wählisch and myself argue that ICN is also a suitable network layer for connecting such challenged edge networks to a more regular Internet, by leveraging hop-by-hop transport functions, ICN caching and minimal application-agnostic extensions.

In earlier work, we have described a design of an improved, IEEE 802.15.4e DSME-based MAC layer for LoRa that supports packet-based communication, specifically ICN-style Interest/Data communication. Yet, RTTs can still be on the order of seconds due to the underlying power saving regime. Leveraging their work, we take an ICN-enabled LoRa subnet as a basis which is attached via an ICN forwarder on a gateway device. We developed a delay-tolerant ICN communication framework that allows connecting these LoRa sub-networks to a "regular" ICN Internet, with the following design goals:

1. supporting IoT sensor data transmission;
2. supporting arbitrary orders of delays, without specific assumptions of typical RTTs on other nodes on the ICN Internet;
3. not requiring application awareness on gateway nodes;
4. utilizing ICN-idiomatic communication to benefit from ICN principles such as accessing named data, Interest/Data semantics, caches, flow balance, etc.

We have developed interactions for IoT communication use cases that leverage bespoke (but application-agnostic) capabilities on gateway-based forwarders and the Reflexive Forwarding extensions for ICN that Dave Oran and I developed for Remote Method Invocation, RESTful communication, and IoT push data scenarios.

Our LoRa systems features two interaction patterns. First, IoT sensor data retrieval from an Internet-based consumer using Interest/Data interactions; and second, asynchronously "pushing'' data from an IoT sensor to an Internet-based consumer with pub/sub semantics.

Results

The contributions of out work are the following:

1. The design of delay-tolerant ICN-interactions and node behavior for this constrained environment.
2. A complete implementation of the DSME MAC layer for LoRa and our ICN protocol extensions on RIOT, serving common LoRa sensors and RIOT-based gateways.
3. An experiment-based evaluation of the interactions on constrained IoT hardware, connected to an emulated ICN-Internet, and a comparison with vanilla ICN approaches.

In conjunction with the OS-level implementation of ICN (and extensions), DSME, and LoRa, our two protocol mechanisms for Internet consumer-initiated and LoRa producer-initiated communication exhibit high reliability and targeted completion time (compared to Vanilla ICN) when applied to the delay-prone regime.

Despite an additional round trip, our evaluations in the paper exhibit low overhead of these approaches by overcoming redundant polling. We leveraged recently proposed gateway behavior (such as RICE) and ICN protocol extensions (reflexive forwarding), the latter of which serves many other use cases beyond phoning home and could be considered a useful standard ICN feature.

References

• ACM ICN-2022 Conference
• Pre-print of our paper
• Presentation video
• Previous work on the DSME and ICN network design
• Reflexing Forwarding Framework
• RIOT Operating System

The Information-Centric Networking Research Group (ICNRG) of the Internet Research Task Force (IRTF) met during the 113th meeting of the Internet Engineering Task Force (IETF) that took place in Vienna from March 19th to March 25th 2022. IETF-113 was the IETF's first hybrid meeting with onsite and remote participants.

Presentation material and minutes are available online, and there is a full recording on youTube. I am summarizing the meeting below.

Edmund Yeh: NDN for Data-Intensive Science Experiments

Edmund Yeh (Northeastern University) presented the NSF-funded project NDN for Data-Intensive Science Experiments (N-DISE), a two-year inter-disciplinary project with participants from Northeastern, Caltech, UCLA, and Tennessee Tech that collaborates with the Large Hadron Collider (LHC), genomics researchers, and the NDN project team.

N-DISE is building data-centric ecosystem to provide agile, integrated, interoperable, scalable, robust and trustworthy solutions for heterogeneous data-intensive domains, in order to support very data-intensive science applications through an NDN-based communication and data sharing infrastructure. The LHC high energy physics program represents the leading target use case, but the project is also looking at BioGenome and other human genome projects as future use cases.

In many data-intensive science applications, data needs to distributed in real-time, archived, retrieved by multiple consumers etc. Within one data centers, but even more so in geographically distributed scenarios, this could lead to a signficant amount of duplicated transmissions with legacy system architectures. N-DISE would leverage general ICN features and concepts such as location-independent data naming, on-path caching and explicit replication through data repos to dramatically improve the efficiency but also to reduce the complexity of such data management systems and their applications.

The general approach of the N-DISE project is to leverage recent results in high-speed NDN networking such as ndn-dpdk to build a data science support infrastructure for petascale distribution, which involves research in high-througput forwarding/caching, the definition of container-based node architectures, FPGA acceleration subsystems and SDN control. The goal is to deliver LHC data over wide area networks at throughputs of approximately 100 Gpbs and to dramatically decrease download times by using optimized caching.

From an NDN perspective, the project provides several interesting lines of work:

• Deployment architectures (how to build efficient container-based N-DISE nodes);
• WAN Testbed creation and throughput testing;
• Optimized caching and forwarding;
• Congestion control and multi-path forwardind; and
• FPGA acceleration.

There are several interesting ideas and connections to ongoing ICN research in N-DISE. For example, as people start building applications for high-speed data sharing but also distributed computing, the question of container-based ICN node architectures arise, i.e., how to enable easy cloud-native deployment of such systems without compromising too much on performance.

Another interesting aspect is congestion control in multi-path forwarding scenarios. Existing technologies such as Multipath TCP and Multipath QUIC are somewhat limited with respect to their ability to use multipath resources in the network efficiently. In ICN, with its different forwarding model multipath forwarding decisions could be made hop-by-hop, and consumers (receiving endpoints) could be given greater control over path selection. For example:

• MIRCC: Multipath-aware ICN Rate-based Congestion Control is a rate-based, multipath-aware ICN congestion control approach inspired by but noticeably differing from RCP.
• Path switching in content centric and named data networks and current ICNRG work on Path steering enables consumers to learn about path diversity in the network on a soft-state basis and then request specific end-to-end Interest forwarding paths themselves.

Cenk Gündoğan: Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Arithmetic

Cenk Gündoğan of HAW Hamburg presented an update of draft-gundogan-icnrg-ccnx-timetlv, a proposal for an alternative logarithmic encoding of time values in ICN (CCNx) messages.

The motivation for this work lies in constrained networking where header compression as per RFC 9139 (ICNLoWPAN) would be applied and more compact time encoding would be desirable. The proposed approach would allow for a compact encoding with dynamic ranges (as in floating point arithmetics), but imposes challenges with respect to backwards compatibility.

ICNRG is considering adopting this work as a research group item to find the best way for updating the current CCNx specifications in the light of these questions.

Dave Oran: Ping & Traceroute Update

Dave Oran presented the recent updates to two specifications:

• ICN Ping (draft-irtf-icnrg-icnping)
• ICN Traceroute (draft-irtf-icnrg-icntraceroute)

In IP, fundamental and very useful tools such as ping and traceroute were created years after the architecture and protocol definitions. In ICN there is an opportunity to leverage tooling at an earlier phase – but also to reason about needed tools and useful features.

ICN Ping provides the ability to ascertain reachability of names, which includes

• to test the reachability and operational state of an ICN forwarder;
• to test the reachability of a producer or a data repository;
• to test whether a specific named object is cached in some on-path CS, and, if so, return the administrative name of the corresponding forwarder; and
  • to perform some simple network performance measurements.

ICN Traceroute provides ability to ascertain characteristics (transit forwarders
and delays) of at least one of the available routes to a name prefix, which includes

• to trace one or more paths towards an ICN forwarder (for troubleshooting purposes);
• to trace one or more paths along which a named data of an application can be reached;
• to test whether a specific named object is cached in some on-path CS, and, if so, trace the path towards it and return the identity of the corresponding forwarder; and
• to perform transit delay network measurements.

Both drafts completed Research Group Last Call in January 2022 and evoked some feedback that has now been addressed (see presentation for details). ICNRG will transfer these drafts to IRSG review and subsequent steps in the IRTF review and publication process soon.

Dave Oran: Path Steering Refresher

Dave Oran presented a refresher of a previously presented specification of Path Steering in ICN (draft-oran-icnrg-pathsteering). Path Steering is a mechanism to discover paths to the producers of ICN content objects and steer subsequent Interest messages along a previously discovered path. It has various uses, including the operation of state-of-the-art multipath congestion control algorithms and for network measurement and management.

In ICN, communication is inherently multi-path and potentially multidestination. But so far there is no mechanism for consumers to direct Interest traffic onto a
specific path, which could lead to
– Forwarding Strategies in ICN forwarders can spray Interests onto various paths;
– Consumers have a hard time interpreting failures and performance glitches;
– Troubleshooting and performance tools need path visibility and control to find problems and do simple measurements.

ICN Path Steering would enable

• Discovering, monitor and troubleshoot multipath network connectivity based on names and name prefixes:
  • Ping
  • Traceroute
• Accurately measure a performance of a specific network path.
• Multipath Congestion control needs to:
  • Estimate/Count number of available paths
  • Reliably identify a path
  • Allocate traffic to each path
• Traffic Engineering and SDN
  • Externally programmable end-to-end paths for Data Center and
    Service Provider networks.

Briefly, Path Steering works by using a Path Label (as an extension to existing protocol formats, see figure) for discovering and for specifying selected paths.

The technology would give consumers much more visibility and greater control of multipath usage and could be useful for many applications, especially those that want to leverage path diversity, for example high-volume file transfers, robust communication in dynamically changing networks, and distributed computing.

Dirk Kutscher: Reflexive Forwarding Re-Design

Dave Oran and I recently re-design a scheme that we called Reflexive Forwarding and that is specified in draft-oran-icnrg-reflexive-forwarding.

Current Information-Centric Networking protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an Interest-Data exchange in the case of the two protocols noted above).

A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint.

This specification proposes a Reflexive Forwarding extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609.

Example: RESTful communication over ICN

In today HTTP deployments, requests such as HTTP GET requests are conceptionally stateless, but in fact they carry a lot of information that would allow server to process these requests correctly. This includes regular header fields, cookies but also input parameters (form data etc.) so that requests can become very large (sometimes larger than the corresponding result messages).

It is generally not a good idea to build client-server systems that require servers to parse and process a lot a client-supplied input data, as this could easily be exploited by computational overload attacks.

In ICN, in addition, Interest message should not be used to carry a lot of "client" parameters as this could lead to issues with respect to flow balance (congestion control schemes in ICN should work based on DATA message volume and rate), but would also force forwarders to store large Interest messages and could potentially even lead to Interest fragmentation, a highly undesirable consequence.

Reflexive Forwarding aims at providing a robust ICN-idiomatic way to transfer "input parameters", by enabling the "server side" to fetch parameters using regular ICN communication (Interest/Data). When doing so, we do not want to give up important ICN properties such as not requiring consumers (i.e., the "clients") to reveal their source address – a useful feature for enable easy consumer mobility and some form of privacy.

Reflexive Forwarding Design

Our Reflexive Forwarding scheme addresses this by letting the consumer specify a tempory, non-globally-routable prefix to the network and the producer that would allow the producer to get back to the consumer through Reflexive Interests for fetching the required input parameters at the producer's discretion. The figure above depicts the high-level protocol operation.

Our new design leverage tempory PIT (Pending Interest Table) state in forwarders and PIT Tokens (hop-by-hop protocol fields in NDN and CCNx) that would allow forwaders, to map Reflexive Interests to PIT entries of the actual Interest and thus forward the Reflexive Interest correctly, on the reverse path.

Potential Applications

Potential applications include

• RESTful communication, e.g., Web over ICN;
• Remote Method Invocation;
• Phone-home scenarios; and
• Peer state synchronization.

For example, we have used a previous design of this scheme in our paper RICE: Remote Method Invocation in ICN that leveraged Reflexive Forwarding for the invocation and input parameter transmission as depicted in the figure above.

Reflexive Forwarding requires relativly benign to ICN forwarder and endpoint behavior but could enable many relevant use cases in an ICN idiomatic way, without requiring large layering overhead and without giving important ICN properties.

The Information-Centric Networking Research Group (ICNRG) of the Internet Research Task Force (IRTF) has recently published two RFC and held a research meeting on December 10th 2021.

Recent RFC Publications

ICNRG published two RFCs recently:

RFC 9139: ICN Adaptation to Low-Power Wireless Personal Area Networks (LoWPANs)

RFC 9139 defines a convergence layer for Content-Centric Networking (CCNx) and Named Data Networking (NDN) over IEEE 802.15.4 Low-Power Wireless Personal Area Networks (LoWPANs). A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described.

To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by IPv6 over LoWPAN (6LoWPAN) is extended to include new dispatch types for CCNx and NDN. Additionally, the fragmentation component of the 6LoWPAN dispatching framework is applied to Information-Centric Network (ICN) chunks.

In its second part, the document defines stateless and stateful compression schemes to improve efficiency on constrained links. Stateless compression reduces TLV expressions to static header fields for common use cases. Stateful compression schemes elide states local to the LoWPAN and replace names in Data packets by short local identifiers.

The ICN LoWPAN specification is a great platform for future experiments with ICN in constrained networking environments, including but not limited to LoWPAN networks.

RFC 9138: Design Considerations for Name Resolution Service in Information-Centric Networking (ICN)

RFC 9138 provides the functionalities and design considerations for a Name Resolution Service (NRS) in Information-Centric Networking (ICN). The purpose of an NRS in ICN is to translate an object name into some other information such as a locator, another name, etc. in order to forward the object request.

Since naming data independently from its current location (where it is stored) is a primary concept of ICN, how to find any NDO using a location-independent name is one of the most important design challenges in ICN. Such ICN routing may comprise three steps:

1. Name resolution: matches/translates a content name to the locator of the content producer or source that can provide the content.
2. Content request routing: routes the content request towards the content's location based either on its name or locator.
3. Content delivery: transfers the content to the requester.

Among the three steps of ICN routing, this document investigates only the name resolution step, which translates a content name to the content locator. In addition, this document covers various possible types of name resolution in ICN such as one name to another name, name to locator, name to manifest, name to metadata, etc.

ICNRG Meeting on December 10th 2021

• Meeting Material
• Video Recording

Agenda

1	Chairs’ Presentation: Status, Updates	Chairs	05 min
2	Zenoh - The Edge Data Fabric	Carlos Guimarães	30 min
3	The SPAN Network Architecture	Rhett Sampson	30 min
4	NDNts API Design	Junxiao Shi	30 min
6	Wrap-Up, Next Steps	Chairs	5 min

---

Zenoh

• Carlos Guimarães
• Presentation
• Video Recording

Carlos Guimarães presented zenoh – The Edge Data Fabric. zenoh is an ICN-inspired data distribution and processing system that zenoh aims at unifying data in motion, data at rest and computations. It blends traditional pub/sub with geo distributed storage, queries and computations, adopting a hierarchical naming scheme and other ICN properties. zenoh provides a high level API for high performance pub/sub and distributed queries, data representation transcoding, an implementation of geo-distributed storage and distributed computed values.

---

SPAN Network Architecture

• Rhett Sampson and Jaime Lorca
• Presentation
• Video Recording

Rhett Sampson and Jaime Llorca presented GT Systems' SPAN-AI content distribution system (CDN as a service) that uses ICN/CCN/NDN for the implementation of their distributed content delivery system, leveraging name-based routing.

---

NDNts API Design

• Junxiao Shi
• Presentation
• Video Recording

Junxiao Shi presented the NDNts API Design. NDNts is an NDN implementation in TypeScript, aiming to facilitate NDN application development in browsers and on the Node.js platform.

The development of NDNts led to some insights on NDN low-level API design (packet decoding, fragmentation, notion of "faces", retransmission logic etc.) that Junxiao shared in his presentation.

The Dataflow paradigm is a popular distributed computing abstraction that is leveraged by several popular data processing frameworks such as Apache Flink and Google Dataflow. Fundamentally, Dataflow is based on the concept of asynchronous messaging between computing nodes, where data controls program execution, i.e., computations are triggered by incoming data and associated conditions. This typically leads to very modular system architectures that enable re-use, re-composition, and parallel execution naturally. Most of the popular distributed processing frameworks today are implemented as overlays, i.e., they allow for instantiating computations and for inter-connecting them, for example by creating and maintaining communication channels between nodes such as system processes and microservices.

Connections and Overlays

The connection-based approach incurs several architectural problems and inefficiencies, for example: application logic is concerned with receiving and producing data as a result of computation processes but connections imply transport endpoint addresses that are typically not congruent. This typically implies a mapping or orchestration system. One key goal for Dataflow systems is to enable parallel execution, i.e., one computation is run in parallel, which also affects the communication relationships with upstream producers and downstream consumers. For example, when parallelizing a computation step, it typically implies that each instance is consuming a partition of the inputs instead of all the inputs. An indirection- and connection-based approach makes it harder to configure (and especially to dynamically re-configure) such dataflow graphs.

In some variants of Dataflow, for example stream processing, it can be attractive if one computation output can be consumed by multiple downstream functions. Connection-based overlays typically require duplicating the data for each such connection, incurring significant overheads. In large-scale scenarios, the computation functions may be distributed to multiple hosts that are inter-connected in a network. Orchestrators may have visibility into compute resource availability but typically have to treat the TCP/IP network as a blackbox. As a result, the actual data flow is locked into a set of overlay connections that do not necessarily follow optimal paths, i.e., the communication flows are incongruent with the logical data flows.

IceFlow: Information-Centric Dataflow

In our ACM ICN 2021 paper Vision: Information-Centric Dataflow – Re-Imagining Reactive Distributed Computing, we present IceFlow – an Information-Centric Dataflow system approach that supports traditional Dataflow with Information-Centric principles and that can be used as a drop-in replacement for existing Dataflow-based frameworks.

In addition to the paper, we also show a live of a joint optimization of computing and networking resources in IceFlow: Decentralized ICN-based dataflow system implementation.

IceFlow’s objectives are:

1. reducing complexity in Dataflow systems by removing connection-based overlays and corresponding orchestration requirements;
2. enabling efficient communication by reducing data duplication; and
3. enabling additional improvements through more direct communication and caching in the network.

IceFlow is employing access to authenticated data in the network as per CCNx/NDN-based ICN for the communication between computation functions and provides additional features such as flowcontrol, partitions for data streaming, and a window concept for synchronizing computations in streaming pipelines. The contributions of this paper are:

1. an ICN naming scheme for Dataflow;
2. a concept for receiver-driven flow control in IceFlow-based Dataflow systems and for dealing with parallel processing in IceFlowbased Dataflow systems; and
3. a prototype implementation.

Links

• ACM ICN 2021
• Vision: Information-Centric Dataflow – Re-Imagining Reactive Distributed Computing
• Decentralized ICN-based dataflow system implementation

The IRTF Information-Centric Networking Research Group (ICNRG) held a meeting on December 1st 2020. Here is a summary of the research highlights. You can find all the presentation and the meetings minutes on the IETF datatracker.

---

Big Data Processing

Edmund Yeh (Northeastern University) presented an overview of recent and current research on supporting Data-Centric Ecosystems for Large-Scale Data-Intensive Science through ICN in the NSF SANDIE Project (SDN-Assisted NDN for Data Intensive Experiments) and in the NSF N-DISE project (NDN for Data Intensive Science Experiments).

Data-intensive science applications such as processing of LHC and genomics data pose interesting challenges to system design and efficient resource usage: from an application perspective these system require accessing named data, independent of location, transport mechanisms etc.

The underlying infrastructures however typically focus on addresses, processes, servers, and connections, which also has repercussions on the security architectures (securing containers and delivery pipes).

The research work in the SANDIE and N-DISE project is applying a data-centric approach to system and network design through the whole data lifecycle, i.e., data is uniquely named and authenticated/encrypted directly at the production phase and then delivered, replicated, stored and made available under that name.

Using basic ICN mechanisms (accessing named data, opportunistic caching, receiver-driven operation, and implicit multicast), accessing, processing and re-using data for data-intensive applications can be much optimized.

Further optimizations can be achieved through:

• joint optimization of forwarding and caching resources as described in Jointly Optimal Routing and Caching for Arbitrary Network
  Topologies; and
• high-speek DPDK-based forwarding NDN-DPDK: NDN Forwarding at 100 Gbps on Commodity Hardware.

The team has applied this to accelerating XRootD for scalable
fault-tolerant data access and demonstrated throughput rates of over 6.7 Gbps and 10 times acceleration.

The newly started N-DISE project will continue this research, aiming at developing a production-ready NDN-based petascale data distribution, caching, access, and computation platform that could server major science programs, with LHC high energy physics as a primary target use case. Technically, the work will focus on created NDN-DPDK consumer and producer applications, packaging NDN-DPDK and applications into containers for diverse platforms, and advancing ICN data integrity and provenance mechanisms.

---

Broker-Based Publish/Subscribe

Nameseok Ko of ETRI presented a design for a Broker-based Pub/Sub System for NDN.

Pub/sub is a popular communication pattern for loosely coupled producers and consumers, supporting one-to-many asynchronous push-based communication. In principle, ICN is amenable to broker-less, distributed implementations of the Pub/sub pattern, for example through dataset synchronization techniques a la Psync.

The presented design is addressing constrained environments such as IoT with low-performance producers, potentially connected to larger systems with scalability and naming flexibility requirements that are difficult to meet with existing approaches. For these environments, the ETRI team has developed a multi-broker based approach, where brokers act as rendezvous points for publishers and subscribers and as gateways to other brokers.

Technically, the system is based on

• a logical separation of topic data management (brokers map the topic name to topic rendezvous nodes names through hashing);
• topic manifests that list rendezvous nodes holding named data streams; and
• data manifests describing data names for a data stream.

This system is supposed to be easily scalable and offloads constrained publishers and subscribers, thus supporting IoT environments that are connected to less constrained infrastructure.

---

NDN-Based Ethereum Blockchain

Quang Tung Thai of ETRI presented results from experiments with an NDN-based Ethereum Blockchain implementation.

Data communication in today's blockchain networks is known to be highly redundant due to the significant amount of duplication that occurs by implementing gossip protocols in connection-oriented overlays. In Ethereum blocks and transaction are broadcast over a such a P2P overlay that is based on a Kademlia-like DHT for finding peers and on TCP communication between peers.

Small objects are pushed directly to all managed peers, whereas large objects are pushed to a few managed peers and are then announced to the remaining peers for subsequent downloading with obvious redundancy and inefficiency.

While the blocks/transaction broadcasting seems to be a good fit for ICN dataset synchronization techniques such as Psync, it turns out that it cannot directly replace the complete Gossip system in Ethereum, as the P2P overlay is still needed for data validation according to the ETRI team.

In the presented work, this has been addressed this by designing an NDN-based P2P system for data announcements that is paired with a NDN-based data retrieval that could still provide most of the efficiency gains. The design is based on the following ideas:

• blockchain nodes have routable prefixes (node names);
• all data objects (blocks/transactions) have globally unique names (so that regular ICN forwarding/caching benefits can apply);
• object names are mapped to nodes names through forwarding hints;
• the existence of new objects is announced through the P2P overlay, and the object is then retrieved using regular ICN Interest/Data; and
• validation still takes place in overlay nodes.

The ETRI team has implemented a fully functional NDN-based Ethereum blockchain client based on geth, the official go-based client, where the TCP/IP P2P module has been replaced by an NDN module. First testbed-based experiments yielded promising efficiency gains, i.e., the traffic redundancy can be translated to higher throughput.

---

Producer Anonymity based on Onion Routing in Named Data Networking

Toru Hasegawa of Osaka University has presented a scheme for Producer Anonymity based on Onion Routing in NDN.

Baseline ICN provides a somewhat asymmetric flavor of anonymity: in general, consumers enjoy anonymity because CCNx/NDN-based ICN does not have the notion of source addresses, and because INTEREST can be aggregated in the network which could provide additional (opportunistic) anonymity.

In many applications though, endpoints will be both consumers and producers at the same time, especially when providing information to others that needs to be requests through Interest/Data exchanges. In addition, the baseline consumer anonymity does not provide very strong content-consumer unlinkability – so that additional measures are required.

The authors have developed a system that is

• achieving producer anonymity against adversaries who analyze content names, signatures and packet routes; and is
• leveraging mostly baseline NDN mechanisms.

The design is based on the Hidden Service in
Tor and is employing so-called self-certifying names as producer pseudonyms so that consumers can talk to producers through rendezvous point without exposing a routable name. In order to prevent en-route information leakage, producers communicate with other other nodes only through circuits. Additional anonymity for rendezvous communication is achieved through RICE.

The system has been implemented using the ndn-cxx library, with AES-128 for encryption and HMAC-SHA-256 for message digests. One advantage of the system is that it can provide the same level of anonymity as Tor's Hidden Service with less of anonymizing routers, which results in reduced latency and higher throughput.

---

A Data-Centric View on the Web of Things

Cenk Gündoğan provided a presentation on a Data-centric View on the Web of Things which followed up on his paper at ACM ICN-2020 on Toward a RESTful Information-Centric Web of Things: A Deeper Look at Data Orientation in CoAP.

This presentation was discussing the adoption of information-centric properties in the CoAP-based IoT technology stack, for example:

• request-response semantics (through regular CoAP GET method semantics);
• stateful forwarding and caching (could be achieved through CoAP proxy chaining); and
• content object security (OSCORE).

General ICN principles can be found in different protocols, at different layers. For example DASH-based video streaming is essentially ICN on top of HTTP from an application perspective. Similar comparisons could be made in other domains, namely IoT, specifically for the CoAP technology stack.

The general question here is whether a corresponding CoAP system with application-layer proxying and object security would be comparable to an ICN-based system with respect to feature completeness and efficiency (communication- and implementation-wise).

Other questions that the authors are currently investigating include how relevant ICN features such as the implicit multicast ability could be added/mapped to CoAP and how ICN's name-based routing and forwarding strategies (that could work without dedicated routing protocols in some scenarios) could be matched by CoAP systems (without completely re-implementing ICN on top of CoAP).

Low-power, long-range radio systems such as LoRaWAN represent one of the few remaining networked system domains that still feature a complete vertical stack with special link- and network layer designs independent of IP. Similar to local IoT systems for low-power networks (LoWPANs), the main service of these systems is to make data available at minimal energy consumption, but over longer distances. LoRaWAN (the system that comprises the LoRa PHY and MAC) supports bi-directional communication, if the IoT device has the energy budget. Application developers interface with the system using a centralized server that terminates the LoRaWAN protocol and makes data available on the Internet.

While LoRaWAN applications are typically providing access to named data, the existing LoRaWAN stack does not support this way of communicating. LoRaWAN is device-centric and is generally designed as a device-to-server messaging system – with centralized servers that serve as rendezvous point for accessing sensor data. The current design imposes rigid constraints and does not facilitate accessing named data natively, which results in many point solutions and dependencies on central server instances.

In our demo paper & presentation at ACM ICN-2020, we are therefore describing how Information-Centric Networking could provide a more natural communication style for LoRa applications and how ICN could help to conceive LoRa networks in a more distributed fashion compared to todays mainstream LoRaWAN deployments. For LoWPANs (e.g., 802.15.4 networks), ICN has already demonstrated to be an attractive and viable alternative to legacy integrated special purpose stacks – we believe that
LoRa communication provides similar opportunities.

Watch my Peter Kietzmann's talk about it here:

ACM ICN-2020 took place online from September 29th to October 1st 2020. This is a quick summary of the main technical highlights from my personal perspective. Overall, it was a high-quality event, and it was great to see the progress that is being made by different teams. Here, I am focusing specifically on Architecture, Content Distribution, Programmability, and Performance. If you are interested in the complete program, all papers, presentation material, and presentation videos are available on the conference website.

Architecture

The Information-Centric Networking concept can be implemented in different ways (and some people would argue that some overlay systems for content distribution and data processing are essentially information-centric). ICN systems have often been associated with clean-slate approaches, requiring difficult to imagine fork-lift replacement of larger parts of the infrastructure. While this has never the case (because you can always run ICN protocols over different underlays or directly map the semantics to IPv6), it is still interesting to learn about new approaches and to compare existing data-oriented frameworks to pure ICN systems.

Named-Data Transport

In their paper Named-Data Transport: An End-to-End Approach for an Information-Centric IP Internet (Presentation) Abdulazaz Albalawi and J. J. Garcia-Luna-Aceves have developed an alternative implementation of the accessing named data concept called Named-Data Transport (NDT) that can leverage existing Internet routing and DNS, while still providing the general properties (accessing named-data securely, in-network caching, receiver-driven operation).

The system is based on three components: 1) A connection-free reliable transport protocol, called Named Data Transport Protocol (NDTP), 2) a DNS extension (my-DNS) for manifest records that describe content items and their chunks, and 3) NDT Proxies that act as transparent caches and that track pending requests, similar to ICN forwarders, but at the transport layer.

In NDT, content names are based on DNS domain names, and each name is mapped to an individual manifest record (in the DNS). These records provide a mapping to a list of IP addresses hosting content replicas. When requesting such records, the idea is that the system would be able apply similar traffic steering as today's CDNs, i.e., provide the requestor with a list of topologically close locations. Producers would be responsible for producing and publishing such manifests.

The Named Data Transport Protocol (NDTP) is a receiver-driven transport protocol (on top of UDP) used by consumers and NDT Proxies which behave logically like ICN forwarders. There is more to the whole approach (such as security, name privacy etc.).

In my view, NDT is an example of a resolution-based ICN system with interesting ideas for deployability. In principle, resolution-based ICN has been pursued by other approaches before (such as NetInf). In general, these systems have a better initial deployment story at the cost of requiring additional infrastructure (and resolution steps during operation.)

RESTful Information-Centric Web of Things

In the Internet of Things, ICN has demonstrated many benefits in terms of reduced code complexity, better data availability, and reduced communication overhead compared to many vertically integrated IoT stacks and location/connection-based protocols.

In their paper Toward a RESTful Information-Centric Web of Things: A Deeper Look at Data Orientation in CoAP (presentation), Cenk Gündoğan, Christian Amsüss, Thomas C. Schmidt, and Matthias Wählisch compare a CoAP and OSCORE (Object Security for Constrained RESTFul Environments) based network of CoAP clients, servers, and proxies with a corresponding NDN setup.

The authors investigated the possibility of building a restful Web of Things that adheres to ICN first principles using the CoAP protocol suite (instead of a native ICN protocol framework). The results showed, since CoAP is quite modular and can be used in different ways, this is indeed possible, if one is willing to give up strict end-to-end semantics and to introduce proxies that mimic ICN forwarder behavior. (The paper reports on many other things, such as extensive performance measurements and comparisons.)

In my view, this is an interesting Gedankenexperiment, and there was a lively discussion at the conference. One of the discussion topics was the question how accurate the comparison really is. For example, while is is possible to construct a CoAP proxy chain that mimics ICN behavior, real-world scenarios would require additional functionality in the CoAP network (routing, dealing with disruptions etc.) that might lead to a different level of complexity (that would possibly be less pronounced in an native ICN environment).

Still, the important take-away of this paper is that some applications of CoAP & OSCORE exhibit information-centric properties, and it is an interesting question whether, for a green-field deployment, the user would not be better served by a native ICN approach.

Content Distribution

Content Distribution and ICN have a long history, sometimes challenged by some misunderstandings. Because one of the early ICN approaches was called Content-Centric Networking (CCN), it was often assumed that ICN would disrupt or replace Content Distribution Networks (CDNs) or that it was a CDN-like technology.

While ICN will certainly help with large-scale content distribution and potentially also change/simplify CDN operations, the core idea is actually about accessing named data securely as a principal network service -- for all applications (that's why Named Data Networking -- NDN -- is a better name).

Managed content distribution as such will continue to be important, even in an ICN world. Surely, it will enjoy better support from the network as today's CDN can expect, thus enabling new exciting applications and simplifying operations, but I prefer avoiding the notion of ICN replacing CDN.

When looking at actual networks and applications today, it is fair to say that almost nothing works without CDN. What we are seeing today is hyperscalers and essentially all the (so-called) OTT video providers extending their systems into ISP networks, by simply shipping standalone edge caches such as Netflix OCA servers as standalone systems to ISPs.

Each of these providers have their own special requirements of how to map customers to edge caches, how to implement traffic steering etc, which is painful enough for operators already. I expect this to become even more pressing as we shift more and more linear live TV to the Internet. Flash-crowd audiences such as viewers of UEFA Champions' League matches will require a massive extension of the already extensive edge caching infrastructure and require massive investments but also significant complexity with respect to traffic steering and guaranteeing a decent viewing experience.

In that context, it is no wonder that people try to resort to IP-Multicast for ensuring a more scaleable last-mile distribution such as this proposal by Akamai and others. Marrying IP-Multicast with a CDN-overlay is (IMO) not exactly complexity reduction, so I think we are now at a tipping point where the Internet in terms of concepts and deployable physical infrastructure can provide many cool services, but where the limited features of the network layers requires a prohibitive amount of complexity -- to an extend where people start looking for better solutions.

At ICN-2020, CDN was thus discussed quite extensively again -- with many interesting, complementary contributions.

Keynote by Bruce Maggs on The Economics of Content Distribution

We were extremely happy to have Bruce Maggs (Emerald Innovations, on leave from Duke University, ex NEC researcher, one of the founding employees of Akamai) delivering his keynote on the Economics of Content Delivery. In his talk Bruce explained different economic aspects (flow of payments, cost of goods sold) but also challenges for different CDN services such as live-streaming.

The take-aways for ICN were:

• Incentives and cost must be aligned
• Performance benefits from caching
  • Reducing latency is valuable to content providers
  • Reducing network is valuable to ISPs.
• If there was caching at the core (in addition to the edge)
  • What is the additional benefit?
  • Who pays for that?
• Protocol innovation is still possible
  • In the past, people thought that HTTP/TLS/TPC/IP is difficult to overcome
  • QUIC demonstrates that new protocols can be introduced

The socio-economic discussion resonated quite well with me, as some of earlier ICN projects in Europe tried to address these aspects relatively early in 2008. I believe this was due to the operator and vendor influence at the time. In retrospect, I would say that the approaches at that time were possibly too much top-down and premature (trying to revert value chains and find new business models). It is only now that we understand the economics of CDN, its complexity and real cost that (in my view) represent barriers to innovation -- and that we can start to imagine actually implementing different systems.

Far Cry: Will CDNs Hear NDN's Call?

In their paper Far Cry: Will CDNs Hear CDN's Call? (presentation), Chavoosh Ghasemi, Hamed Yousefi, and Beichuan Zhang tried to compare NDN with enterprise CDN (a particular variant of CDN) with respect to caching and retrieval of static contents.

In their work, the authors deployed an adaptive video streaming service over three different networks: Akamai, Fastly, and the NDN testbed. They had users in four different continents and conducted a two-week experiment, comparing Quality of Experience, Origin workload, failure resiliency, and content security.

I cannot summarize of all of the results here, but the conclusions by the authors were:

• CDNs outperform the current NDN testbed deployment in terms of QoE (achievable video resolution in a DASH-setting)
• Origin workload and failure resiliency are mainly the products of the network design -- and the NDN testbed outperforms current CDNs
• More as an interpretation: NDN can realize a resilient, secure, and scalable content network given appropriate software and protocol maturity and hardware resources.

The paper was discussed intensively at the conference , for example, it was debated how comparable the plain NDN testbed and its network service really are -- to a production-level CDN.

In my view, the value of this paper lies in the created experiment facilities and the attempt to establish some ground truth (based on current NDN maturity). I hope that this work can leverage by more experiments in the future.

iCDN: An NDN-based CDN

In their paper iCDN: An NDN-based CDN (presentation), Chavoosh Ghasemi, Hamed Yousefi, and Beichuan Zhang (i.e., the same authors), pursue a more forward-looking approach. In this paper, they develop a CDN service based on ICN mechanisms, i.e., trying to conceive a future CDN system that does not need to take the current network's limitations into account.

One of the interesting ICN properties is that the main service of accessing named data does not require any notion of location. Sometimes people assume that an Information-Centric system always needs to map names to locators such as IP addresses, but this is a really limited view. Instead, it is possible to build the network solely on forwarding INTERESTs for named data based on forwarding information of that same namespace. A forwarder may have more than forwarding info base entry for the same name -- from a consumer (application) perspective these are completely equivalent.

Because of intrinsic object security, it does not matter from which particular host a content object is served. There can be several copies -- all equivalent. When creating copies of original content, e.g., by cloning a data repository, the new copy needs to be announced (by injecting routing information) , and from that point on, it is reachable without any additional management, configuration or other out-of-band mechanisms.

When applying this notion to CDN scenarios, it is easy to understand the simplification opportunities. In ICN, content repositories can be added to the network, and in-network name-based forwarding will find the closest copy automatically.

For iCDN, the authors have leveraged this basic notion and built an ICN-based CDN that does not need any client-to-cache mapping and overlay routing mechanisms. Based on that, iCDN features logical partitions and cache hierarchies for content namespaces (for acknowledging that there may be different CDN providers, hosting different content services).

iCDNs employ cache hierarchies to exploit on-path and off-oath caches without relying on application-layer routing functions. The idea was to provide a scalable, adaptive solution that can cope with dynamic network changes as well as dynamic changes in content popularity.

There are more details to this approach, and of course the debate on what is the best ICN-based CDN design has just started. Still, this paper is an interesting contribution in my view, because it illustrates the opportunities for rethinking CDN nicely.

Programmability

Programmability and ICN has two facets: 1) Implementing distributed computing with ICN (for example as in CFN -- Compute-First Networking) and 2) implementing ICN with programmable infrastructure. ACM ICN-2020 has seen contributions in both directions.

Result Provenance in Named Function Networking

In their paper Result Provenance in Named Function Networking (presentation), Claudio Marxer and Christian Tschudin have leveraged their previous work on Named Function Networking (NFN) and developed a result provenance framework for distributed computing in NFN.

In this work, the authors augmented NFN with a data structure that creates transparency of the genesis of every evaluation results so that entities in the system can ascertain result provenance. The main idea is the introduction of so-called provenance records that capture meta data about the genesis of the computation result. The paper discusses integration of these records into NDN and procedures for provenance checks and trust computation.

In my view, the interesting contribution of this work is the illustration of how the general concept of provenance verification can be implemented in a data-oriented system such as the ICN-based Named Function Networking framework. The results may be (so some extend) to other ICN-based in-network computing systems, so I hope this paper will start a thread of activities on this subject.

ENDN: An Enhanced NDN Architecture with a P4-programmable Data Plane

In their paper ENDN: An Enhanced NDN Architecture with a P4-programmable Data Plane (presentation), Ouassim Karrakchou, Nancy Samaan, and Ahmed Karmouch present an NDN system that is implemented in a P4-programmable data plane, i.e., a system in which applications can interact with a control plane that configures the data plane according to the required services.

The work in this paper is based on the notion that applications specify their content delivery requirements to the network, i.e., the control plane of a network. The control plane provide a catalogue of content delivery services, which are then translated into data plane configurations that ultimately get installed on P4 switches.

Examples of such services include Content Delivery Pattern services (whether the system is based on INTEREST/DATA or some stateful data forwarding), Content Name Rewrite services (enabling the network to rewrite certain names in INTERESTs), Adaptive Forwarding services (next-hop selection) etc.

In my view, this paper is interesting because it provides a relatively advanced perspective of how applications specify required behavior to a programmable ICN network. Moreover, the authors implemented this successfully on P4 switches and described relevant lessons learned and achievements in the paper.

Performance

Performance has historically always been an interesting topic in ICN. On the one hand, ICN provides substantial performance increases in the network due to its forwarding and caching features. On the other hand, it has been shown that implementing an ICN forwarder that operates at modern network line-speeds is challenging.

NDN-DPDK: NDN Forwarding at 100 Gbps on Commodity Hardware

In their paper NDN-DPDK: NDN Forwarding at 100 Gbps on Commodity Hardware (presentation), Junxiao Shi, Davide Pesavento, and Lotfi Benmohamed present their design of a DPDK-based forwarder.

The authors have developed a complete NDN implementation that runs on real hardware and that supports the complete NDN protocol and name matching semantics.

This work is interesting because the authors describe the different optimization techniques including better algorithms and more efficient data structures, as well as making use of the parallelism offered by modern multi-core CPUS and multiple hardware queues with user-space drivers for kernel-bypass.

This work represents the first software forwarder implementation that is able to achieve 100 Gpbs without compromises in NDN protocols semantics. The authors have published the source at https://github.com/usnistgov/ndn-dpdk.

In most Internet (two-party) communication scenarios, we have to deal with connection setup protocols, for example for TCP (three-way handshake), TLS (three-way key agreement), HTTP (leveraging TLS/TCP before GET-RESPONSE). The most important concern is to make sure that both parties know that they have succesfully established a connection and to agree on its parameters.

In client-server communication, there are other, application-layer, requirements as well, for example authenticating and authorizing peer and checking input parameters. Web applications today, typically serve a mix of static and dynamic content, and the generation of such dynamic content requires considerable amount of client input (as request parameters), which in results in considerable amounts of data (Google: "Request headers today vary in size from ~200 bytes to over 2KB.", SPDY Whitepaper).

When designing connection establishment protocols and their interaction with higher layer protocols, there are a few, sometimes contradicting objectives:

• fast connection setup: calls for minimizing the number of round-trips;
• reliable connection and security context setup: reliable state synchronization requires a three-way handshake); and
• robustness against attacks from unauthorized or unwanted clients: could be done by filtering connection attempts, by authentication checks, or other parameter checks on the server.

The goal to minimize the number of round-trips can contradict with robustness: For example, in a dynamic web content scenario, spawning a server worker thread for processing a malicious client request that will have to be declined can be huge resource waste and thus make the services susceptible to DOS attacks.

These are general trade-offs in many distributed computing and web-based systems. In Information-Centric Networking (ICN), there can be additional objectives such as maintaining client (consumer) anonymity (to the network) to avoid finger-printing and tracking (ICN does not have source addresses).

Current ICN protocols such as CCNx and NDN have a wide range of useful applications in content retrieval and other scenarios that depend only on a robust two-way exchange in the form of a request and response (represented by an Interest-Data exchange in the case of the two protocols noted above).

A number of important applications however, require placing large amounts of data in the Interest message, and/or more than one two-way handshake. While these can be accomplished using independent Interest-Data exchanges by reversing the roles of consumer and producer, such approaches can be both clumsy for applications and problematic from a state management, congestion control, or security standpoint.

For RICE, Remote Method Invocation for ICN, we developed a corresponding scheme that addresses the different objectives mentioned above.

In draft-oran-icnrg-reflexive-forwarding we have now provided a formal specification of a corresponding Reflexive Forwarding extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications. It updates RFC8569 and RFC8609.

The approach that we have taken here is to extend the ICN forwarding node requirements, so in addition to the general state synchronization problems, this Internet Draft raises the question of evolvability of core ICN protocols.

Discussion on the ICNRG mailing list.