This is an introduction to our paper:

• Wei Geng, Yulong Zhang, Dirk Kutscher, Abhishek Kumar, Sasu Tarkoma, Pan Hui; Sok: Distributed Computing in ICN; 10th ACM Conference on Information-Centric Networking (ACM ICN '23); October 9 — 10, 2023, Reykjavik, Iceland; https://doi.org/10.1145/3623565.3623712; pre-print available at https://arxiv.org/abs/2309.08973.

Distributed computing is the basis for all relevant applications on the Internet. Based on well-established principles, different mechanisms, implementations, and applications have been developed that form the foundation of the modern Web.

The Internet with its stateless forwarding service and end-to-endcommunication model promotes certain types of communication for distributed computing. For example, IP addresses and/or DNS names provide different means for identifying computing components. Reliable transport protocols (e.g., TCP, QUIC) promote interconnecting modules. Communication patterns such as REST and protocol implementations such as HTTP enable certain types of distributed computing interactions, and security frameworks such as TLS and the web PKI constrain the use of public-key cryptography for different security functions.

From Distributed Computing...

Distributed computing has different facets, for example, client-server computing, web services, stream processing, distributed consensus systems, and Turing-complete distributed computing platforms. There are also different perspectives on how distributed computing should be implemented on servers and network platforms, a research area that we refer to as Computing in the Network. Active Networking, one of the earliest works on computing in the network, intended to inject programmability and customization of data packets in the network itself; however, security and complexity considerations proved to be major limiting factors, preventing its wider deployment.

Dataplane programmability refers to the ability to program behavior, including application logic, on network elements and SmartNICs, thus enabling some form in-network computing. Alternatively, different types of server platforms and light-weight execution environments are enabling other forms of distributing computation in networked systems, such as architectural patterns, such as edge computing.

... To Computing in the Network

With currently available Internet technologies, we can observe a relatively succinct layering of networking and distributed computing, i.e., distributed computing is typically implemented in overlays with Content Distribution Networks (CDNs) being prominent and ubiquitous example. Recently, there has been growing interest in revisiting this relationship, for example by the IRTF Computing in the NetworkResearch Group (COINRG) – motivated by advances in network and server platforms, e.g., through the development of programmable data plane platforms and the development of different types of distributed computing frameworks, e.g., stream processing and microservice frameworks.

This is also motivated by the recent development of new distributed computing applications such as distributed machine learning (ML), and emerging new applications such as Metaverse suggest new levels of scale in terms of data volume for distributed computing and the pervasiveness of distributed computing tasks in such systems. There are two research questions that stem from these developments:

1. How can we build distributed computing systems in the network that can leverage the on-path location of compute functions, e.g., optimally aligning stream processing topologies with networked computing platform topologies?

2. How can the network support distributed computing in general, so that the design and operation of such systems can be simplified, but also so that different optimizations can be achieved to improve performance and robustness?

Issues in Legacy Distributed Computing

Although there are many distributed computing applications, it is also worth noting that there are many limitations and performance issues. Factors such as network latency, data skew, checkpoint overhead, back pressure, garbage collection overhead, and issues related to performance, memory management, and serialization and deserialization overhead can all influence the efficiency. Various optimization techniques can be implemented to alleviate these issues, including memory adjustment, refining the checkpointing process, and adopting efficient data structures and algorithms.

Some performance problems and complexity issues stem from the overlay nature of current systems and their way of achieving the above-mentioned mechanisms with temporary solutions based on TCP/IP and associated protocols such as DNS. For example, Network Service Mesh has been characterized as architecturally complex because of the so-called sidecar approaches and their implementation problems.

In systems that are layered on top of HTTP or TCP (or QUIC), compute nodes typically cannot assess the network performance directly – only indirectly through observed throughput and buffer under-runs. Information-centric data-flow systems, such as IceFlow, intend to provide better visibility and thus better joint optimization potential by more direct access to data-oriented communication resources. Then, some coordination tasks that are based on exchanging updates of shared application state can be elegantly mapped to named data publication in a hierarchical namespace, as the different dataset synchronization (Sync) protocols in NDN demonstrated.

Information-Centric Distributed Computing

In our paper on Distributed Computing in ICN at ACM ICN-2023, we focus on distributed computing and on how information-centricity in the network and application layer can support the development and operation of such systems. The rich set of distributed computing systems in ICN suggests that ICN provides some benefits for distributed computing that could offer advantages such as better performance, security, and productivity when building corresponding applications.

ICN with its data-oriented operation and generally more powerful forwarding layer provides an attractive platform for distributed computing. Several different distributed computing protocols and systems have been proposed for ICN, with different feature sets and different technical approaches, including Remote Method Invocation (RMI) as an interaction model as well as more comprehensive distributed computing platforms. RMI systems such as RICE leverage the fundamental named-based forwarding service in ICN systems and map requests to Interest messages and method names to content names (although the actual implementation is more intricate). Method parameters and results are also represented as content objects, which provides an elegant platform for such interactions.

ICN generally attempts to provide a more useful service to data-oriented applications but can also be leveraged to support distributed computing specifically.

Names

Accessing named data in the network as a native service can remove the need for mapping application logic identifiers such as function names to network and process identifiers (IP addresses, port numbers), thus simplifying implementation and run-time operation, as demonstrated by systems such as Named Function Networking (NFN), RICE, and IceFlow. It is worth noting that, although ICN does not generally require an explicit mapping of names to other domain identifiers, such networks require suitable forwarding state, e.g., obtained from configuration, dynamic learning, or routing.

Data-orientedness

ICN's notion of immutable data with strong name-content binding through cryptographic signatures and hashes seems to be conducive to many distributed computing scenarios, as both static data objects and dynamic computation results in those systems such as input parameters and result values can be directly sent as ICN data objects. NFN has first demonstrated this.

Securing distributed computing could be supported better in so far as ICN does not require additional dependencies on public-key or pipe securing infrastructure, as keys and certificates are simply named data objects and centralized trust anchors are not necessarily needed. Larger data collections can be aggregated and re-purposed by manifests (FLIC), enabling "small" and "big data" computing in one single framework that is congruent to the packet-level communication in a network. IceFlow uses such an aggregation approach to share identical stream processing results objects in multiple consumer contexts.

Data-orientedness eliminates the need for connections; even reliable communication in ICN is completely data-oriented. If higher-layer (distributed computing) transactions can be mapped to the network layer data retrieval, then server complexity can be reduced (no need to maintain several connections), and consumers get direct visibility into network performance. This can enable performance optimizations, such as linking network and computing flow control loops (one realization of joint optimization), as showed by IceFlow.

Location independence and data sharing

Embracing the principle of accessing named and authenticated data also enables location independence, i.e., corresponding data can be obtained from any place in the network, such as replication points (repos) and caches. This fundamentally enables better multi-source/path capabilities as well as data sharing, i.e., multiple data retrieval operations for one named data object by different consumers can potentially be completed by a cache, repo, or peer in the network.

Stateful Forwarding

ICN provides stateful, symmetric forwarding, which enables general performance optimizations such as in-network retransmissions, more control over multipath forwarding, and load balancing. This concept could be extended to support distributed computing specifically, for example, if load balancing is performed based on RTT observations for idempotent remote-method invocations.

More Networking, less Management

The combination of data-oriented, connection-less operation, and stateful (more powerful) forwarding in ICN shifts functionality from management and orchestration layers (back) to the network layer, which can enable complexity reduction, which can be especially pronounced in distributed computing. For example, legacy stream processing and service mesh platforms typically must manage connectivity between deployment units (pods in Kubernetes). In Apache Flink, a central orchestrator manages the connections between task managers (node agents). Systems such as IceFlow have demonstrated a more self-organized and decentralized stream-processing approach, and the presented principles are applicable to other forms of distributed computing.

In summary, we can observe that ICN's general approach of having the network providing a more natural (data retrieval) platform for applications benefits distributed computing in similar ways as it benefits other applications. One particularly promising approach is the elimination of layer barriers, which enables certain optimizations.

In addition to NFN, there are other approaches that jointly optimize the utilization of network and computing resources to provide network service mesh-like platforms, such as edge intelligence using federated learning, advanced CDNs where nodes can dynamically adapt to user demands according to content popularity, such as iCDN and OpenCDN, and general computing systems, such as Compute-First Networking, IceFlow, and ICedge.

Our paper on Distributed Computing in ICN at ACM ICN-2023 provides a comprehensive analysis and understanding of distributed computing systems in ICN, based on a survey of more than 50 papers. Naturally, these different efforts cannot be directly compared due to their difference in nature. We categorized different ICN distributed computing systems, and individual approaches and highlighted their specific properties.

The scope of this study is technologies for ICN-enabled distributed computing. Specifically, we divide the different approaches into four categories, as shown in the figure above: enablers, protocols, orchestration, and applications. The contributions of this study are as follows:

1. A discussion of the benefits and challenges of distributed computing in ICN.
2. A categorization of different proposed distributed computing systems in ICN.
3. A discussion of lessons learned from these systems.
4. A discussion of existing challenges and promising directions for future work.

Recent Research on Distributed Computing in ICN

I am providing some pointers to my previous research on distributed computing in ICN below.

The paper that has led to this article:

• Wei Geng, Yulong Zhang, Dirk Kutscher, Abhishek Kumar, Sasu Tarkoma, Pan Hui; Sok: Distributed Computing in ICN; 10th ACM Conference on Information-Centric Networking (ACM ICN '23); October 9 — 10, 2023, Reykjavik, Iceland; https://doi.org/10.1145/3623565.3623712; pre-print available at https://arxiv.org/abs/2309.08973.

Current work in the Computing in the Network Research Group of the IRTF:

• Dirk Kutscher, Teemu Kärkkäinen, Jörg Ott; Directions for Computing in the Network; Internet Draft draft-irtf-coinrg-dir-00, Work in Progress; August 2023

Reflexive Forwarding and Remote Method Invocation

Providing a unified remote computation capability in ICN presents some unique challenges, among which are timer management, client authorization, and binding to state held by servers, while maintaining the advantages of ICN protocol designs like CCN and NDN. In the RICE work,we developed a unified approach to remote function invocation in ICN that exploits the attractive ICN properties of name-based routing, receiver-driven flow and congestion control, flow balance, and object-oriented security while presenting a natural programming model to the application developer. The RICE protocol is leveraging an ICN extension called Reflexive Forwarding that provides ICN-idiomatic method parameter transmission.

• RICE: Remote Method Invocation in ICN (best paper award at ACM ICN-2018)
• Reflexive Forwarding in ICN

Distributed Computing Frameworks

Leveraging RICE as a mechanism, we have developed Compute-First Networking (CFN) in ICN, a Turing-complete distributed computing platform. IceFlow is a proposal for Dataflow in ICN in a decentralized manner.

• Compute-First Networking (CFN): Distributed Computing Meets ICN
• IceFlow: Information-Centric Dataflow: Re-Imagining Reactive Distributed Computing

Applications

Based on Reflexive Forwarding, we have developed a concept for RESTful ICN that leverages CCNx key exchange for setting up security contexts and keys that could then be used for secure, data-oriented REST-like communication.

Delay-Tolerant LoRa leveraged Reflexive Forwarding to enable constrained LoRa nodes to "phone home" when they want to transmit data, thus enabling new ways (without central network and application servers) for connecting LoRa networks to the Internet.

• RESTful ICN
• Delay-Tolerant LoRa ICN Networking

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. Reflexive Forwarding is a proposed extension to the CCNx and NDN protocol architectures that eliminates the problems inherent in using independent Interest-Data exchanges for such applications.

The protocol is specified in draft-oran-icnrg-reflexive-forwarding and has been used in a few of our research projects such as:

• RICE: Remote Method Invocation in ICN (best paper award at ACM ICN-2018)
• Compute-First Networking (CFN): Distributed Computing Meets ICN
• RESTful ICN
• Delay-Tolerant LoRa ICN Networking

My student intern Xinchen Jin from ShanghaiTech has implemented the Reflexing Forwarding specification in NDN (with modifications to ndn-cxx and NFD) and set up a testbed in mini-NDN for experiments over multiple forwarders.

Resources

• draft-oran-icnrg-reflexive-forwarding
• Reflexive forwarding implementation in NDN

Our project proposal on Named Data Microverse was selected as a winner of the Future of Data Challenge

The Named Data Microverse project explores how Information-Centric Networking (ICN) can enable a free, open and decentralized approach to “the metaverse”. The project aims to balances scalability and market-based innovation with democratization, trustworthiness, and equitable empowerment of individuals. ICN provides an architectural foundation for secure, distributed applications to be created more easily and provides resilience in natural disasters, better mobility support, cloud-optional local communication, improved privacy, and other benefits that are not addressed solely by “Web3” technologies.

This is a joint project with Jeff Burke and Lixia Zhang at UCLA.

I had the pleasure of chairing a really interesting panel discussion at the NDN Community meeting (NDNComm 2023) on March 3rd 2023.

The panel discussed opportunities and challenges for building Metaverse systems with a Named Data Networking approach. Specific discussion questions include:

• What are architectural, security-related, and performance-related issues in Metaverse systems today?
• What communication patterns could be supported by NDN platforms?
• How can the data-oriented model and decentralized trust establishment help in developing better Metaverse systems and at what layer would NDN technologies help?
• What are gaps, challenges and research opportunities for NDN evolution to address Metaverse system requirements?

The panelists were:

• Paulo Mendes (Airbus Research)
• Michelle Munson (Eluvio)
• Todd Hodes (Eluvio)
• Jeff Burke (UCLA REMAP)

The panel discussed scenarios for Named Data in the Metaverse such as AR in live performance, real-time ML for transformed reality, architectures for emerging arts, media, and entertainment, commercial content distribution and experience delivery, as well as Metaverse VR experiences in challenged networks.

Jeff Burke introduced exciting ideas for re-imaging VR-enhanced live performances and shared some ideas and insights from building such applications. In his class of applications, there is a lot of local interaction (for example in a theater), creating interesting challenges and opportunities for local, decentralized Metaverses. On the application layer, Metaverse VR applications would like use scene and model descriptions such as USD and gITF, so the question arises, what opportunities exist for mapping the corresponding names to "network layer" names.

Michelle Munson and Todd Hodes introduced Eluvio's Content Fabric Protocol (CFP), a platform aimed at commercial-grade decentralized content distribition, providing content-native adressability programmability mechanisms for storage, distribution, and in-built streaming and content processing. CFP uses Blockchain governance for versioning, access control, and on-chain/cross-chain monetization. An example use case is the Warner Movieverse.

The panel discussed the different approaches of dealing with named-data as a fundamental building block and some specific use cases for networked Metaverse systems such as (secure) in-network content transformation. Overall, the panel was a great initial discussion on these ideas that should definitely be continued. Check out the list of related events below for possible venues.

Related Events

• Metaverse-focused ICN Research Group meeting at the upcoming IETF-116 meeting: (ICNRG meets on March 28, 09:30 to 11:00 JST, online participation possible).
• Metaverse side meeting at IETF-116 on March 30th at 11:30. See IETF Metaverse mailing list for agenda and details.
• IEEE MetaCom Workshop on Decentralized, Data-Oriented Networking for the Metaverse (DORM)

IEEE MetaCom Workshop on Decentralized, Data-Oriented Networking for the Metaverse (DORM)

Workshop page at IEEE MetaCom

Organizers

• Jeff Burke, UCLA
• Dirk Kutscher, HKUST(GZ)
• Dave Oran, Network Systems Research & Design
• Lixia Zhang, UCLA

Workshop Description

The DORM workshop is a forum to explore new directions and early research results on Metaverse system architecture, protocols, and security, along a data-oriented design direction that can encourage and facilitate decentralized realizations. Here we broadly interpret the phrase “Metaverse” as a new phase of networking with multi-dimensional shared views in open realms.

Most prototype implementations of such systems today replicate the social media platform model: they run on cloud servers offered by a small number of providers, and have identities and trust management anchored at these servers. Consequently, all communications are mediated through such servers, together with extensive CDN overlay infrastructures or the equivalent.

Although the cloud services may be extended to edges to address performance and delay issues, the centralization of control power that stems from this cloud-centric approach can be problematic from a societal perspective. It also reflects a significant semantic mismatch between the existing address-based network support and many aspirations for open realm applications and interoperability: the applications, by and large, operate on named data principles at the application layer, but need to deploy multiple layers of middleware services, which are provider-specific, to bridge the gap. These added complexities prohibit new ways of interacting (leveraging new data formats such as USD and gITF) and are not conducive to flexible distributed computing in the edge-to-cloud continuum.

This workshop solicits efforts that explore new directions in metaverse realization and work that takes a principled approach to key topics in the areas of 1) Networking as the Platform, 2) Objects and Experiences, and 3) Trust and Transactions without being constrained by inherited platforms.

Networking as the Platform

Metaverse systems will rely on a variety of communication patterns such as client-server RPC, massively scalable multi-destination communication, publish-subscribe etc. In systems that are designed with a cloud-based, centralized architecture in mind, such interactions are typically mediated by central servers and supported by overlay CDN infrastructure, with operational inflexibility and lacking optimization mechanisms, for example in order to leverage specific network link layer capabilities such as broadcast/multicast features. Underlying reliance on existing stacks also introduces familiar complications in providing disruption-tolerant, mobile-friendly extended reality applications, limiting their viability for eventual use in critical infrastructure and require significant engineering support to use in demanding entertainment applications, such as large-scale live events.

This workshop seeks research on new strategies for Metaverse system design that can promote innovation by lowering barriers to entry for new applications that perform robustly under a variety of conditions. We solicit research on Metaverse system design that addresses architectural and protocol-level issues without the reliance on a centralized cloud-based architecture. Instead, we expect the DORM workshop submissions to start with a distributed system assumption, focusing on individual protocol and security elements that enable decentralized Metaverse realizations.

Many Metaverse-relevant interactions such as video streaming and distribution of event data today inherently rely on abstractions for accessing named data objects such as video chunks, for example in DASH-based video streaming. The DORM workshop will therefore particularly invite contributions that explore new systems and protocol designs that leverage that principle, thus exploring new opportunities to re-imagine the relationship between application/network and link/physical layer protocols in order to better support Metaverse system implementations. This could include work on new hypermedia concepts based on the named data principle and cross-layer designs for simplifying and optimizing the implementation and operation of such protocols.

We expect such systems to as well be better suited to elegant, efficient integration of computing into the network, thus providing more flexible and adaptive platforms for offloading computation and supporting more elaborate data dissemination strategies.

From Objects to Experiences

In our perceived Metaverse/open realm systems, there are different existing and emerging media representations and encodings such as current video encodings as well as scene and 3D object description and transmission formats such as USD and glTF. Similar to previous developments in the networked audio/video area, it is interesting to investigate opportunities for new scene and 3D object representation formats that are suitable not only for efficient creation and file-like unidirectional transmission but also for streaming, granular composition and access, de-structuring, efficient multi-destination transmission, possibly using network coding techniques.

The workshop is therefore soliciting contributions that explore a holistic approach to media/object representation within network/distributed computing, enabling better performance, composability and robustness of future distributed Metaverse systems. Submissions that explore cross-layer approaches to supporting emerging media types such as volumetric video and neural network codecs are encouraged, as are considerations of how code implementing object behaviors and interactions can be supported - providing a path to the interoperable experiences expressed in various Metaverse visions.

Trust and Transactions

Finally, distributed open realm systems need innovative solutions in identity management and security support that enable interoperation among multiple systems including a diverse population of users. We note that mechanisms to support trust are inherently coupled with various identities, from "real world" identities to application-specific identities that users may adopt in different contexts. Proposed solutions need to consider not just media asset exchange but also the interactions among objects, and the data flows needed to support it.

The workshop solicits contributions that identify specific technical challenges, for example system bootstrapping, trust establishment, authenticated information discovery, and that propose new approaches to the identified challenges. Researchers are encouraged to consider cross-layer designs that address disconnects between layers of trust in many current systems - e.g., the reliance on third-party certificate authorities for authentications, the inherent trust in connections rather than the objects themselves, that tends to generate brittleness for even local communications if connectivity to the global network is compromised.

Call for Papers

The Decentralized Data-Oriented Networking for the Metaverse (DORM) workshop is intended as a forum to explore new directions and early research results on the system architecture, protocols, and security to support Metaverse applications, focusing on data-oriented, decentralized system designs. We view Metaverse as a new phase of networking with multi-dimensional shared views in open realms.

Most Metaverse systems today replicate the social media platform model, i.e., they assume a cloud platform provider-based system architecture where identities and the trust among them is anchored via a centralized administrative structure and where communication is mediated through servers and an extensive CDN overlay infrastructure operated by that administration. The centralization that stems from this approach can be problematic both from a control and from a performance & efficiency perspective. Despite operating on named data principles conceptually, such systems typically exhibit traditional layering approaches that prohibit new ways of interacting (leveraging new data formats such as USD and gITF) and that are not conducive for flexible distributed computing in the edge-to-cloud continuum.

This workshop solicits work that takes a principled approach at key research topics in the areas of 1) Networking as the Platform, 2) Objects and Experiences, and 3) Trust and Transactions without being constrained by inherited platform designs, including but no limited to:

• Distributed Metaverse architectures
• Computing in the network as an integral component for better communication and interaction support
• Application-layer protocols for a rich set of interaction styles in open realms
• Supporting Metaverse via data-oriented techniques
• Security, Privacy and Identity Management in Metaverse systems
• New concepts for improved network support for Metaverse systems, e.g., through facilitating ubiquitous multipath forwarding and multi-destination delivery
• Cross-layer designs
• Emerging scene description and media formats
• Quality of Experience for Metaverse applications
• Distributed consensus and state synchronization
• Security, Privacy and Identity Management in Metaverse systems

Given the breadth and emerging nature of the field, all papers should include the articulation of a specific vision of Metaverse that provides clarifying assumptions for the technical content.

Submissions and Formatting

The workshop invites submission of manuscripts with early and original research results that have not been previously published or posted on public websites or that are not currently under review by another conference or journal. Submitted manuscripts must be prepared according to IEEE Computer Society Proceedings Format (double column, 10pt font, letter paper) and submitted in the PDF format. The manuscript submitted for review should be no longer than 6 pages without references. Reviewing will be double-blind. Submissions must not reveal the authors’ names and their affiliations and avoid obvious self-references. Accepted and presented papers will be published in the IEEE MetaCom 2023 Conference Proceedings and included in IEEE Xplore.

Manuscript templates can be found here. All submissions to IEEE MetaCom 2023 must be uploaded to EasyChair at https://easychair.org/conferences/?conf=metacom2023.

Organization Committee

• Jeff Burke, UCLA
• Dirk Kutscher, HKUST(GZ)
• Dave Oran, Network Systems Research & Design
• Lixia Zhang, UCLA

Technical Program Committee

• Alex Afanasyev, Florida International University
• Hitoshi Asaeda, NICT
• Ali Begen, Ozyegin University
• Taejoong Chung, Virginia Tech
• Serge Fdida, Sorbonne University Paris
• Carlos Guimarães, ZettaScale Technology SARL
• Peter Gusav, UCLA
• Toru Hasagawa, Osaka University
• Jungha Hong, ETRI
• Kenji Kanai, Waseda University
• Ruidong Li, Kanazawa University
• Spyridon Mastorakis, University of Nebraska Omaha
• Kazuhisa Matsuzono, NICT
• Marie-Jose Montpetit, Concordia University Montreal
• Jörg Ott, Technical University Munich
• Yiannis Psarras, Protocol Labs
• Eve Schooler, Intel
• Tian Song, Beijing Institute of Technology
• Kazuaki Ueda, KDDI Research
• Cedric Westphal, Futurewei
• Edmund Yeh, Northeastern University
• Jiadong Yu, HKUST(GZ)
• Yu Zhang, Harbin Institute of Technology

Important Dates

• March 20, 2023, Paper submission deadline
• April 20, 2023 Notification of paper acceptance
• May 10, 2023, Camera-ready paper submissions

Submission Link

https://easychair.org/conferences/?conf=metacom2023

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

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.