Dirk Kutscher

The Information-Centric Networking Research Group (ICNRG) of the Internet Research Task Force (IRTF) met at IETF-119 in Brisbane. Here is my quick summary of the meeting:

Agenda:

Meeting material:

• All presentation material
• Meeting minutes
• Meeting video

ICNRG Status

ICNRG recently published four news RFCs – great achievement by all involved authors and the whole group!

• RFC 9510: Alternative Delta Time Encoding for Content-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic
• RFC 9531: Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN)
• RFC 9508: Information-Centric Networking (ICN) Ping Protocol Specification
• RFC 9507: Information-Centric Networking (ICN) Traceroute Protocol Specification

See my blog posting for a more detailed description.

Secure Web Objects and Transactions

One focus of this meeting was transactions in ICN, i.e., interactions with the intention to achieve some durable state change at a remote peer – which imposes some challenges in a system that is designed around accessing named data.

In my presentation I talked about different ways to realize transactions in ICN:

1. ICN as a network layer
   • Client-server communication between two nodes
   • Implement transaction semantics on top of an ICN messaging service
2. Recording state changes in shared data structures
   • Shared namespace, potentially functioning as a transaction ledger
   • Still need to think about atomicity etc

For 1) transactions as messaging over ICN networks, the following considerations apply:

• Client-server communication between two nodes
• Implement transaction semantics on top of an ICN messaging service
• Different approaches
  • A: Traditional layering: Using NDN-like systems as a messaging layer
  • Assign prefixes to client & servers
  • Send messages back and forth, and implement reliability and transactions semantics on top
  • B: ICN-native communication: Use Interest-Data as request-response abstraction for transactions
  • Mapping transaction communication and state evolution more directly to ICN, e.g., Interest-Data in NDN
  • Collapsing traditional network, transport, application layer functions

I mainly talked about variant 1B, ICN-native communication: Use InterestData as request-response abstraction for transactions and introduced the idea of "Secure Web Objects" (SWOs) for a data-oriened web as a motivation.

In such a system, not everything would be about accessing named data object – there is also a need for "client/server" state evolution, e.g., for online banking and similar use cases.

I introduced some ideas on RESTful ICN that we published in an earlier paper. The Restful ICN proposal leverages Reflexive Forwarding, for robust client-server communication and integrates elements of CCNx key exchange for security context setup and session resumption.

Summarizing, I wanted to initiate a discussion about how to realize transactions in information-centric systems? This discussion is not about mapping ICN to existing protocols, such as HTTP, but about actual distributed computing semantics, i.e., robust session setup and state evolution. Transactions with ICN-native communication are hard to provide with with basic Interest/Data. Reflexive Forwarding + CCNx Key Exchange + transaction semantics are an attempt to provide such a service in a mostly ICN-idiomatic way, with the downside that reflexive forwarding needs extensions to forwarders. This raises question on the minimal feature set of core ICN protocols, and to deal with extensions.

In the discussion, it was pointed out that lots of experience on distributed systems has shown that transactions or secure multi-interactions will generally require more than a single two-way exchange.

Others suggested that ICN and NDN has authentication carried out when the signed interest arrives which directly proves authentication, so that the authentication would in fact be done beforehand.

However, authentication may not be enough. For example, client authorization in client-server communication is a critical function which needs to be carefully designed in real-world networks. For example, forcing a server to do signature verification on initial request arrival has been shown in prior systems (e.g. TCP+TLS) to represent a serious computational DOS attack risk. Reflexive Forwarding in RICE tries to avoid exactly that problem, by enabling the server to iteratively authenticate and authorize clients before committing computing resources.

It was also said that whenever a protocol does authentication. you need to analyze in the context of specific examples to discuss, and that cannot only look at the problem at an abstract level.

Transaction Manifests

Marc Mosko presented another approach to transactions in ICN, called [Transaction Manifests](https://datatracker.ietf.org/meeting/119/materials/slides-119-icnrg-transaction-manifests-00 "Transaction Manifests "Transaction Manifests"). He explained that ICN can be transactional.

Typically, ICN is considered as a publish/subscribe or pre-publishing of named-data approach. Outside ICN, distributed transactions do exist, especially in DLTs. For example, considering a permissioned DLT with size N and K << N bookkeepers. In a DLT, they base their decision on the block hash history. In this talk, Marc discussed what would be an equivalent function in ICN, and introduced the notion of transaction manifests.

In ICN, there is a technology called FLIC (File-like collections), i.e., manifests for static objects. FLIC describes a single object that is re-constructed by traversing the manifest in order. In Marc's proposal, a transaction manifest describes a set of names that must be considered together. The transaction manifest names likely point to FLIC root manifests.

In the example above, transaction manifest entries entries point directly to objects. For a complete systems, you would also need a set of bookkeepers, e.g., systems like Hyperledger offering global ordering vis bespoke orderer nodes. Such bookkeeper would have to ensure that a transaction has current pre-conditions, current post-conditions, and no conflicts in post-conditions. Transaction manifests are a form of write-ahead logs (WAL), as used in databases, such as PostgreSQL.

Marc went on discussing a few challenges, such as interactions with repositories and caches, as well as distributed transaction manifests.

There was some discussion on the required ordering properties for this approach, i.e., whether, in a multi-bookkeeper system, livelocks and deadlocks could occur – and whether these could resolved without requiring a total order.

Marc is continueing to work on this. One of the next steps would be to design client-to-bookkepper and bookkeeper-to-bookkeeper protocols.

Vanadium: Secure, Distributed Applications

Marc Mosko introduced the Vanadium system, a secure, distributed RPC system based on distributed naming and discovery. Vanadium uses symmetrical authentication and encryption and may use private name discovery with Identity-Based-Encryption (IBE).

Vanadium has two parts:

1. Principals and Blessings and Caveats (Security)
   • Use a hierarchical name, e.g. alice:home:tv.
   • Certificate based
   • Blessings are scoped delegations from one principal to another for a namespace (e.g. alice grants Bob “watch” permissions to the TV)
   • Caveats are restrictions on delegations (e.g. Bob can only watch 6pm – 9pm).
   • 3rd party caveats must be discharged before authorization
   • E.g. revocations or auditing
2. The RPC mount tables (Object Naming)
   • These describe how to locate RPC namespaces
   • They provide relative naming

Vanadium is interesting because parts of its design resemble some ICN concepts, especially the security part:

• It uses prefix matching and encryption
• Namespaces work like groups
• The colon : separates the blesser from the blessed
• Authorizations match extensions.
  • If Alice authorized “read” to alice:hometv to alice:houseguests, and if Bob has a blessing for alice:houseguests:bob, then Bob has “read” to alice:hometv.
• A special terminator :$ only matches the exact prefix.
  • A blessing to alice:houseguest:$ only matches that exact prefix.

Marc then explain the object naming structure and the entity resolution in Vanadium.

More details can be found in Marc's presentation and on Vanadium's web page.

In summary, Vanadium is a permissioned RPC service. A Vanadium name encodes the endpoint plus name suffix. The endpoint does not need to resolve to a single mount table server, it could be any server that possesses an appropriate blessing. Authentication is done via pair-wise key exchange and blessing validations. It can be private if using IBE, otherwise server name leaks. Authorizations and Blessings and Caveats use hierarchical, prefixmatching names.

From an ICN perspective, the security approach seems interesting. Blessings and Caveats and discharges and namespaces as groups. One question is how this differs from SDSI co-signings. The Vanadium identity service provides an interesting mapping of OAuth2 app:email tokens to PKI and blessings. The RPC approach exhibits some differences to ICN, e.g., embedding the endpoint identifier in the name. ICN technologies in this context are public-key scoped names in CCNx and schematized trust anchors in NDN.

In the discusion, it was noted that it would be interesting to do an apples-to-apples comparison to the NDN trust schema approach; Vanadium's approach with the ability to create blessings and caveats on demand seems to be much more granular and dynamic.

Global vs. Scoped Namespaces

Marc Mosko discussed global vs. scoped namespaces. For example, how do you know that the key you are looking at is the key that you should be looking at? IPFS punts that to out-of-band mechanisms. CCNX on the other hand uses public key scoped names; you can put a public key, publisher ID in an interest and say you only wanyt this name if signed with the associated key.

It was suggested to re-visit some of the concepts in the RPC system of OSF distributed computing, where all namespaces were scoped, and name discovery starts out as local. You could then "attach" a local namespace to more global namespace via an explicit "graft" operation. The key here was that the authoritative pointers representing the namespace graph were from child to parent, as opposed to parent to child as it is with systems like DNS. Your local trust root identifier could become a name in a higher layer space, yielding a trust root higher in the hierarchy tha could be used instead of or in addition to your local trust root. Doing this can create progressively more global name spaces out of local ones.

Please check out the meeting video for the complete discussion at the meeting.

We just published our IEEE Communications Magazine article on Rethinking LoRa for the IoT with an Open Access license.

LoraWAN and the Internet

Internet of Things (IoT) interconnects numerous sensors and actuators either locally or across the global Internet. From an application perspective, IoT systems are inherently data-oriented, their purpose is often to provide access to named sensor data and control interfaces. From a device and communication perspective, things in the IoT are resource-constrained devices that are commonly powered by a small battery and communicate wirelessly.

LoRaWAN systems today integrate the LoRa physical layer with the LoRaWAN MAC layer and corresponding infrastructure support. Among the IoT radio technologies, LoRa is a versatile and popular candidate since it provides a physical layer that allows for data transmission over multiple kilometers with minimal energy consumption. At the same time, the high LoRa receiver sensitivity enables packet reception in noisy environments, which makes it attractive for industrial deployments. On the downside, LoRa achieves only low data rates requiring long on-air times, and significantly higher latencies compared to radios that are typically used for Internet access.

LoraWAN MAC Layer

The LoRaWAN MAC layer and network architecture that is often used in LoRa deployments, thus provide a vertically integrated sensor data delivery service on top of the LoRa PHY that implements media access and end-to-end network connectivity. Unfortunately, LoRaWAN cannot utilize the LoRa PHY to its best potential with respect to throughput and robustness and is mostly used for upstream-only communication. It is not intended to directly interconnect with the Internet, but relies on a bespoke middlebox architecture consisting of gateways and network servers. Overall LoRaWAN has the following main problems, as depicted in the figure below.

1. Centralization around a network server prevents data sharing between users, across distributed applications, and requires permanent infrastructure backhaul of the wireless access network.
2. Uplink-oriented and uncoordinated communication leads to wireless interference. Downlink traffic is rarely available in practice and suffers from scalability issues.

Data-centric Delay-tolerant End-to-End Communication over the Internet

This paper presents an overview about recent advancements to enable data-centric, long-range IoT communication based on LoRa. The proposed network system aims for delay-tolerant, bi-directional communication in the presence of vastly longer latencies and lower bandwidth compared to regular Internet systems – without relying on vertically integrated middlebox-based architectures. The resulting system resolves current LoRaWAN performance issues using two main building blocks: a new network layer based on Information-centric Networking (ICN) and a new MAC layer.

Originally designed for non-constrained wired networks to abandon the end-to-end paradigm and access data only by names instead of IP endpoints, ICN migrated to the constrained wireless IoT over the past years. ICN still lacks a lower layer definition but provides mechanisms that are beneficial for the challenging LoRa domain: Decoupling of content from endpoints separates data access from physical infrastructure. Inherent content caching and replication potentially reduce link load, thus, wireless interference, and it preserves battery resources. The ICN-LoRa system presented in this paper bases its design on IEEE 802.15.4 DSME which was originally designed for low-power personal area networks. This MAC handles media access reliably using time- and frequency multiplexing, and enables reliable bi-directional communication.

Synergizing the advantages of LoRa, DSME, and ICN enables delay-tolerant, bi-directional LoRa communication, wich enhances many existing IoT applications. Wide area data retrieval and control as for solar power stations or smart street lighting systems are facilitated by the new MAC and its ICN integration. High voltage overhead line monitoring connecting voltage sensors and transformers relies on high data reliability, even under intermittent connectivity or loss. ICN achieves this, employing content caching and replication. Traveling container monitoring (RFC 7744) is challenging due to mobility and interference from metallic surfaces, where LoRa surpasses other radio systems. Decoupling content from its location for mobile containers and an adaptation to long producer delays are naturally contributed by LoRa-ICN.

Results

In our paper, we provide the essential technical background and challenges to design a LoRa-ICN system. We identify the key performance potentials of five protocol variants based on an implementation in RIOT OS and experiments on off-the-shelf IoT devices.

LoRa is an attractive radio technology for the IoT, providing a long wireless transmission range for battery-driven devices. Its versatility is hindered, though, by common deployments with LoRaWAN. We re-visited LoRa in the IoT to provide a serverless, data-oriented communication service. We presented the design of a new media access and network layer that leverages 802.15.4 DSME and Information-centric Networking to allow for reliable LoRa transmissions. To scale to a global Internet (of Things), LoRa-ICN facilitates ubiquitous connectivity of constrained nodes and robust bi-directional communication in the presence of power-saving regimes and high loss rates.

We showed that vastly higher latencies in low-power wireless domains can be addressed by extending the default ICN node behavior at the network edge. Two protocol extensions enable ICN-style data transport between resource-constrained LoRa nodes and a domain-agnostic application on the ICN Internet. The core idea is not limited to LoRa but caters to various delay-prone scenarios. Our experiments based on common IoT hardware and software showed significant performance improvements and further optimization potential compared to Vanilla ICN.

The new LoRa-ICN system paves the way for more versatile LoRa deployments in the IoT that serve additional use cases, mixed sensor-actor topologies, or firmware updates utilizing beacon overloading.

References

This article

• P. Kietzmann, J. Alamos, D. Kutscher, T. C. Schmidt and M. Wählisch, Rethinking LoRa for the IoT: An Information-centric Approach in IEEE Communications Magazine, doi: 10.1109/MCOM.001.2300379.

Reflexive forwarding

The ICN communication mechanisms this work is based on.

• Reflexive Forwarding in NDN
• Oran, D. R. and D. Kutscher; Reflexive Forwarding for CCNx and NDN Protocols; Work in Progress; Internet-Draft draft-oran-icnrg-reflexive-forwarding-05; 26 March 2023

In-depth publications this work is based on

• Peter Kietzmann, José Alamos, Dirk Kutscher, Thomas C. Schmidt, and Matthias Wählisch. 2022. Delay-tolerant ICN and its application to LoRa. In Proceedings of the 9th ACM Conference on Information-Centric Networking (ICN '22). Association for Computing Machinery, New York, NY, USA, 125–136. https://doi.org/10.1145/3517212.3558081
• P. Kietzmann, J. Alamos, D. Kutscher, T. C. Schmidt and M. Wählisch, Long-Range ICN for the IoT: Exploring a LoRa System Design, 2022 IFIP Networking Conference (IFIP Networking), Catania, Italy, 2022, pp. 1-9, doi: 10.23919/IFIPNetworking55013.2022.9829792. https://ieeexplore.ieee.org/document/9829792
• José Álamos, Peter Kietzmann, Thomas C. Schmidt, and Matthias Wählisch. 2022. DSME-LoRa: Seamless Long-range Communication between Arbitrary Nodes in the Constrained IoT. ACM Trans. Sen. Netw. 18, 4, Article 69 (November 2022), 43 pages. https://doi.org/10.1145/3552432

We have posted the agenda our ICNRG meeting at IETF-118:

Drafts

• https://datatracker.ietf.org/doc/draft-irtf-icnrg-flic/
• https://datatracker.ietf.org/doc/draft-yao-tsvwg-cco-problem-statement-and-usecases/00/
• https://datatracker.ietf.org/doc/draft-yao-tsvwg-cco-requirement-and-analysis/00/
• https://datatracker.ietf.org/doc/draft-li-icnrg-damc/

Logistics

ICNRG Meeting at IETF-118 – 2023-11-07, 08:30 to 10:30 UTC

• MeetEcho
• Notes
• IETF-118 Agenda

We have submitted two new Internet Drafts on Collective Communication:

1. Kehan Yao , Xu Shiping , Yizhou Li , Hongyi Huang , Dirk Kutscher; Collective Communication Optimization: Problem Statement and Use cases; Internet Draft draft-yao-tsvwg-cco-problem-statement-and-usecases-00; work in progress; October 2023

2. Kehan Yao , Xu Shiping , Yizhou Li , Hongyi Huang , Dirk Kutscher; Collective Communication Optimization: Requirement and Analysis; Internet Draft draft-yao-tsvwg-cco-requirement-and-analysis-00; work in progress; October 2023

Collective Communication refers to communication between a group of processes in distributed computing contexts, for example involving interaction types such as broadcast, reduce, all-reduce. This data-oriented communication model is employed by distributed machine learning and other data processing systems, such as stream processing. Current Internet network and transport protocols (and corresponding transport layer security) make it difficult to support these interactions in the network, e.g., for aggregating data on topologically optimal nodes for performance enhancements. These two drafts discuss use cases, problems, and initial ideas for requirements for future system and protocol design for Collective Communication. They will be discussed at IETF-118.

In a joint panel at ACM ICN-2023 and IEEE ICNP-2023 in Reykjavik, Ken Calvert, Jim Kurose, Lixia Zhang, and myself discussed future network abstractions. The panel was moderated by Dave Oran. This was one of the more interesting and interactive panel sessions I participated in, so I am providing a summary here.

Since the Internet's initial rollout ~40 years ago, not only its global connectivity has brought fundamental changes to society and daily life, but its protocol suite and implementations have also gone through many iterations of changes, with SDN, NFV, and programmability among other changes over the last decade. This panel looks into next decade of network research by asking a set of questions regarding where lies the future direction to enable continued innovations.

Opportunities and Challenges for Future Network Innovations

Lixia Zhang: Rethinking Internet Architecture Fundamentals

Lixia Zhang (UCLA), quoting Einstein, said that the formulation of the problem is often more essential than the solution and pointed at the complexities of today's protocols stacks that are apparently needed to achieve desired functionality. For example, Lixia mentioned RFC 9298 on proxying UDP in HTTP, specifically on tunneling UDP to a server acting as a UDP-specific proxy over HTTP. UDP over IP was once conceived as a minial message-oriented communication service that was intended for DNS and interactive real-time communication. Due to its push-based communication model, it can be used with minimal effort for useful but also harmful application, including large-scale DDOS attacks. Proxing UDP over HTTP addresses this and other concerns, by providing a secure channel to a server in a web context, so that the server can authorize tunnel endpoints, and so that the UDP communication is congestion controlled by the underlying transport protocol (TCP or QUIC). This specification can be seen as a work-around: sending unsolicted (and un-authenticated) messages over the Internet is a major problem in today's Internet. There is no general approach for authenticating such messages and no concept for trust in peer identities. Instead of analyzing the root cause of such problems, the Internet communities (and the dominant players in that space) prefer to come up with (highly inefficient) workarounds.

This problem was discussed more generally by Oliver Spatscheck of AT&T Labs in his 2013 article titled Layers of Success, where he discussed the (actually deployed) excessive layering in production networks, for example mobile communication networks, where regular Internet traffic is routinely tunneled over GTP/UDP/IP/MPLS:

The main issue with layering is that layers hide information from each other. We could see this as a benefit, because it reduces the complexities involved in adding more layers, thus reducing the cost of introducing more services. However, hiding information can lead to complex and dynamic layer interactions that hamper the end-to-end system’s reliability and are extremely difficult if not impossible to debug and operate. So, much of the savings achieved when introducing new services is being spent operating them reliably.

According to Lixia, the excessive layering stems from more fundamental problems with today's network architecture, notably the lack of identity and trust in the core Internet protocols and the lack of functionality in the forwarding system – leading to significant problems today as exemplied by recent DDoS attacks. Quoting Einstein again, she said that we cannot solve problems by using the same kind of thinking we used when we created them, calling for a more fundamental redesign based on information-centric networking principles.

Ken Calvert: Domain-specific Networking

Ken Calvert (University of Kentucky) provided a retrospective of networking research and looked at selected papers published at the first IEEE ICNP conference in 1993. According to Ken, the dominant theme at that time was How to design, build, and analyze protocols, for example as discussed in his 1993 ICNP paper titled Beyond layering: modularity considerations for protocol architectures.

Ken offered a set of challenges and opportunities for future networking research, such as:

• Domain-specific networking à la Ex uno pluria, a 2018 CCR editorial discussing:
  • infrastructure ossification;
  • lack of service innovation; and
  • a fragmentation into "ManyNets" that could re-create a service-infrastructure innovation cycle.
• Incentives and "money flow"
  • Can we escape from the advertising-driven Internet app ecosystem? Should we?
• Wide-area multicast (many-many) service
  • Building block for building distributed applications?
• Inter-AS trust relationships
  • Ossification of the Inter-AS interface – cannot be solved by a protocol!
• Impact ⇐ Applications ⇐ Business opportunities ($)
  • What user problem cannot be solved today?
• "The core challenge of CS ... is a conceptual one, viz., what (abstract) mechanisms we can conceive without getting lost in the complexities of our own making." - Dijkstra

For his vision for networking in 30 years, Ken suggested that:

• IP addresses will still be in use
  • but visible only at interfaces between different owners' infrastructures
• Network infrastructure might consist of access ASes + separate core networks operated by the "Big Five".
• Users might communicate via direct brain interfaces with AI systems.

Dirk Kutscher: Principled Approach to Network Programmability

I offered the perspective of introducing a principled approach to programmability that could provide better programmability (for humans and AI), based on more powerful network abstractions.

Previous work in SDN with protocols such as OpenFlow and dataplane programming languages such as P4 have only scratched the surface of what could be possible. OpenFlow was a great first idea, but it was fundamentally constrained by the IP and Ethernet-based abstractions that were built into it. It can be used for programming some applications in that domain, such as firewalls, virtual networking etc., but the idea of continuous innovation has not really materialized.

Similarly, P4 was advertized as an enabler for new levels of dataplane programmability, but even simple systems such as NetCache have to go to quite some extend to achieve minimal functionality for a proof-of-concept. Another P4 problem that is often reported is the hardware heterogeneity so that universal programmability is not really possible. In my opinion, this raises some questions with respect to applicability of current dataplane programming for in-network computing. A good example of a more productive application of P4 is the recent SIGCOMM paper on NetClone that describes as fast, scalable, and dynamic request cloning for microsecond-Scale RPCs. Here P4 is used as an accelerator for programming relatively simple functionality (protocol parsing, forwarding).

This may not be enough for future universal programmability though. During the panel discussion, I drew an analogy to computer programming language. We are not seeing the first programming language and IDEs that are designed from the ground up for better AI. What would that mean for network programmability? What abstractions and APIs would we need?

In my opinion, we would have to take a step back and think about the intended functionality and the required observability for future (automated) network programmability that is really protocol-independent. This would then entail more work on:

• the fundamental forwarding service (informed by hardware constraints);
• the telemetry approach;
• suitable protocol semantics;
• APIs for applications and management; and
• new network emulation & debugging approach (a long the lines of "network digital twin" concepts).

Overall, I am expecting new exiciting research in the direction of principled approaches to network programmability.

Jim Kurose: Open Research Infrastructures and Softwarization

Jim reminded us that the key reason Internet research flourished was the availability of open infrastructure with no incumbent providers initially. The infrastructure was owned by researchers, labs, and universities and allowed for a lot of experimentation.

This open infrastructure has recently been challenged by ossification with the rise of production ISP services at scale, and the emergence of closed ISPs, cellular carriers, hyperscalers operating large portion of the network.

As an example for emerging environments that offer interesting opportunities for experiments and new developments, Jim mentioned 4G/5G private networks, i.e., licensed spectrum created closed ecosystems – but open to researchers, creating opportunities for:

• innovation in private 5G networks such as Citizens Broadband Radio Service (CBRS) that could enables innovation in open, deployed systems and a democratization of 5G+ networks and edge applications;
• testbeds, such as Platforms for Advanced Wireless Research (PAWR); and
• the integration of WiFi, 5G as link-layer edge RANs.

Jim was also suggesting further opportunities in softwarization and programmability, such as (formal) methods for logical correctness and configuration management, as well as programmability to add services beyond the "minimal viable service", such as closed loop automatic control and management.

Finally Jim also mentioned opportunities in emerging new networks such as LEOs, IoT and home networks.

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