Dirk Kutscher

We are organizing the 2025 HKUST Internet Research Workshop (HKIRW) in the week before the IETF-122 meeting in Bangkok. This workshop aims to bring together researchers in computer networking and systems around the globe to a live forum discussing innovative ideas at their early stages. The mission of the workshop is that promising but not-yet-mature ideas can receive timely feedback from the community and experienced researchers, leading them into future IRTF work, Internet Drafts, or IETF working groups.

The workshop will operate like a “one day Dagstuhl seminar” and will focus on discussion and ideas exchange and less on conference-style presentations. The objective is to identify topics and connect like-minded people for potential future collaboration.

Please see https://hkirw.github.io/2025/ for details.

References

• Workshop homepage
• Report from HKIRW-2024

On Monday, December 9th, 2024, we held our Decentralization of the Internet (DIN) workshop at ACM CoNEXT-2024. It brought together network researchers, law and policy experts, and digital right activists to discuss the observed consolidation and centralization of the existing Internet applications, services, and the infrastructure in recent years. This trend has economic as well as technical implications for attributes commonly associated with the Internet, such as user-centricity and permissionless innovations.

The Decentralization of the Internet Research Group (DINRG) of the Internet Research Task Force (IRTF) has been working on identifying the root causes and consequences of Internet centralization at IETF meetings and focused workshops in the past, which has led to significant insights, especially with regard to the centralization of infrastructure and control power. This recent DIN workshop at ACM CoNEXT-2024, organized by my DINRG co-chairs Lixia Zhang and myself, provided a forum for academic researchers to present and discuss on-going efforts on this topic, and to create a greater awareness of this important issue in the broader network research community. The workshop attracted a diverse set of researchers who are working on Internet decentralization in fields such as Internet technologies, economics and law-making. The workshop featured two keynotes, two technical paper presentation sessions, and an interactive panel discussion.

Keynotes

The keynotes were presented by two renowned experts:

Keynote: Cory Doctorow: DISENSHITTIFY OR DIE!

Cory Doctorow, member of the Electronic Frontier Foundation (EFF), gave a talk titled DISENSHITTIFY OR DIE! How computer scientists can halt enshittification to make a new, good internet and condemn today's enshitternet to the scrapheap of history. Cory’s talk vividly explained the historic development of a process that he called enshittification, a process in which the providers of online products and services changed their policies subtly and gradually over time, grabbing the control of user data for profitability. Doctorow also discussed potential remedies and countermeasures, including removing the barriers for users to exit platforms and reinstalling the end-to-end principle in future application developments.

Keynote: Michael Karanicolas: The Fediverse Papers: Constitutional, Governance, and Policy Questions for a New Paradigm of Networking

Michael Karanicolas, the executive director of the UCLA Institute for Technology, Law and Policy, talked about the Fediverse Papers: Constitutional, Governance, and Policy Questions for a New Paradigm of Networking. Michael provided an overview of the history of digital speech and content governance. He highlighted the challenges in supporting effective content moderation in today’s Internet contexts, including issues around monetization, legislation, privacy, and the need for governance mechanisms to meet users, content owners, and governments’ expectations. He emphasized the importance of intentionality and a structured process to identify the essential policy questions and to evaluate various design choices for the future of decentralized platforms.

Decentralized Systems

Bluesky and the AT Protocol: Usable Decentralized Social Media

Authors: Martin Kleppmann, Paul Frazee, Jake Gold, Jay Graber, Daniel Holmgren, Devin Ivy, Jeromy Johnson, Bryan Newbold, Jaz Volpert

Abstract: Bluesky is a new social network built upon the AT Protocol, a decentralized foundation for public social media. It was launched in private beta in February 2023, and has grown to over 10 million registered users by October 2024. In this paper we introduce the architecture of Bluesky and the AT Protocol, and explain how the technical design of Bluesky is informed by our goals: to enable decentralization by having multiple interoperable providers for every part of the system; to make it easy for users to switch providers; to give users agency over the content they see; and to provide a simple user experience that does not burden users with complexity arising from the system’s decentralized nature. The system’s openness allows anybody to contribute to content moderation and community management, and we invite the research community to use Bluesky as a dataset and testing ground for new approaches in social media moderation.

ReP2P Matrix: Decentralized Relays to Improve Reliability and Performance of Peer-to-Peer Matrix

Authors: Benjamin Schichtholz, Roland Bless, Florian Jacob, Hannes Hartenstein, Martina Zitterbart

Abstract: Matrix is a decentralized middleware for low-latency group communication, most renowned for its use in the Element instant messenger. Proposals for peer-to-peer (P2P) Matrix architectures aim to decentralize the current architecture further, which is based on federated servers. These proposals require that the receiver and the originator, or another peer that already successfully received the message, are simultaneously online. We introduce relay-enhanced P2P Matrix (ReP2P Matrix) in order to improve message delivery between peers that are online at different times. The design maintains the advantages of P2P Matrix and integrates well into it, e.g., it reuses existing mechanisms for authentication and authorization. Using an extended real-world group messaging traffic dataset, we evaluate P2P Matrix by comparing it to P2P Matrix without relays. The results show that relays do not only improve reliability in message delivery, but also increase the share of low delivery latencies by 50% points in groups with up to 30 members.

On Empowering End Users in Future Networking

Authors: Tianyuan Yu, Xinyu Ma, Lixia Zhang

Abstract: In today's Internet, end users communicate largely via cloud-based apps, and user data are stored in cloud servers and controlled by cloud providers. Recent years have witnessed multiple efforts in developing decentralized social apps with various design approaches, although the community at large is yet to fully understand the effectiveness, viability, and limitations of these different designs. In this paper, we make a proposition that a necessary condition of moving towards Internet decentralization is enabling direct user-to-user (U2U) communications, and discuss the design choices in several decentralization efforts and identify their limitations. We then articulate why a DNS-derived namespace is the best choice in U2U app developments in general, and use a recently developed decentralized app, NDN Workspace (NWS), as an example to show how NWS' use of DNS-derived namespace enables secure U2U communications.

Technologies for Decentralization

Atomicity and Abstraction for Multi-Blockchain Interactions

Authors: Huaixi Lu, Akshay Jajoo, Kedar S. Namjoshi

Abstract: A blockchain enables secure, atomic transactions among untrusted parties. Atomicity is not guaranteed, however, for transactions whose operations span several blockchains; multi-chain atomicity must be enforced by a protocol. Such protocols are known only for special cases, such as cryptocurrency swaps, which are limited only to two chains. We propose a novel two-phase protocol that facilitates atomic executions of general multi-chain (>= 2) transactions. We formally analyze the protocol correctness and show that the proposed abstraction considerably simplifies the development of multi-chain applications. Our experiments with a prototype implementation show that the performance of the general atomicity protocol is comparable to that of custom-built implementations.

Communication Cost for Permissionless Distributed Consensus at Internet Scale

Authors: David Guzman, Dirk Trossen, Jörg Ott

Abstract: The diffusion of information that evolves a distributed computing state is a fundamental operation of a permissionless distributed consensus system (DCS). This permissionless participation decentralized the consensus over the distributed computing state, e.g., in cryptocurrencies and voting systems. For this, a permissionless DCS implements protocols to establish relationships among peers, which is then used to diffuse information. The relation establishment constitutes the control plane of the DCS, while the state diffusion is the data plane. The prevalent mechanism to realize both is a randomized peer-centric iterative diffusion. In this paper, we contrast this approach against a multicast-based design, focusing our comparison on the costs (bytes transmitted) for maintaining the relations, the control plane. We develop suitable models to account for those costs, parameterized through Internet-scale experimental insights we derived from existing DCS deployments. Our results show that the communication costs can be reduced by 30 times.

Towards a Decentralized Internet Namespace

Authors: Yekta Kocaogullar, Eric Osterweil, Lixia Zhang

Abstract: The Domain Name System (DNS) has been providing a decentralized global namespace to support all Internet applications and usages over the last few decades. In the recent years, a number of blockchain-based name systems have emerged with the claim of providing better namespace decentralization than DNS. The community at large seems uncertain with regard to which of these systems is the best in providing decentralized Internet namespace control. In this paper, we first deconstruct the design of DNS, identify its three essential components and explain who controls each of them. We then examine the Ethereum Name Service (ENS) as a representative example of blockchain-based naming systems, gauge the degree of its decentralization. Finally, we conduct a comparative analysis between DNS and ENS to assess the validity and affordability of each design and the (de)centralization in their namespace control and name system operations.

Panel Discussion: Decentralization of the Internet – Quo Vadis?

An interactive panel discussion with (from left to right) Michael Karanicolas (UCLA), Paul Mockapetris (ThreatSTOP), Dan Massey (USC ISI, NSF), and Cory Doctorow (EFF), articulated various next steps for countering Internet centralization. Among many things discussed, the panel and audience identified the notion of enabling direct user-to-user communication without reliance on third parties, and the required functionality to support that, such as how to provide user owned identities, tools for user mutual authentications and secure communications.

These and additional related topics will be further discussed at the IRTF DIN research group, which is a forum with open participation to serve the purpose of continuous international collaborative research on Internet decentralization.

References

• Workshop homepage at ACM CoNEXT-2024
• Workshop papers
• Workshop videos
• IETF blog post on the workshop
• IRTF DINRG

I am delighted that I have been appointed as the next Chair of the Internet Research Task Force (IRTF) by the Internet Architecture Board (IAB).

I have been involved in the IRTF for many years. It is a unique organization that conducts research of importance to the evolution of the Internet protocols, applications, architecture and technology. It has initiated and supported many important technology developments for the Internet in the past, in fields such as network architecture, security and privacy, congestion control, and many more.

The IRTF focuses on longer term research issues, and its various research groups are enabling international collaboration for continuous research on critical topics for the Internet by working with academic and industry research communities.

My term starts in March 2025. I am sincerely grateful for all the support I have received, I am looking forward to working with this community to help making the Internet work better through good research work.

References

• https://www.iab.org/announcements/dirk-kutscher-to-be-next-internet-research-task-force-chair/

The IRTF DINRG Meeting at IETF-121 takes place on 2024-11-06 at 13:00 to 14:30 UTC.

• Presentations in the IETF datatracker
• MeetEcho
• Onsite tool
• Notes
• DINRG Wiki
• IETF-121 Agenda

Documents and Links to Resources

1. United We Stand: Collaborative Detection and Mitigation of
   Amplification DDoS Attacks at
   Scale
2. https://datatracker.ietf.org/doc/draft-mcfadden-consolidation-taxonomy/
3. https://datatracker.ietf.org/doc/draft-mcfadden-cnsldtn-effects/

Notes

Please remember that all sessions are being recorded.

The ICNRG Meeting at IETF-121 takes place on 2024-11-05, 13:00 to 14:30 UTC.

• Agenda and Presentations
• MeetEcho
• Notes
• IETF-121 Agenda

ICNRG Agenda

Please remember that all sessions are being recorded.

Material

1. https://datatracker.ietf.org/doc/draft-irtf-icnrg-flic/
2. https://datatracker.ietf.org/doc/draft-mosko-icnrg-ccnxchunking/
3. https://github.com/mmosko/ccnpy
4. https://datatracker.ietf.org/doc/draft-irtf-icnrg-reflexive-forwarding/
5. https://datatracker.ietf.org/doc/draft-hong-icn-metaverse-interoperability/
6. https://datatracker.ietf.org/doc/draft-li-icnrg-damc/

We have an exciting agenda for our upcoming IRTF DINRG meeting (Wednesday, July 24th, 2024 at 09:30 in Vancouver) at IETF-120. If you do not attend the IETF-120 meeting locally, please consider attending online.

Documents and Links to Resources

• Policy Network on Internet
  Fragmentation
• https://datatracker.ietf.org/doc/draft-ietf-dance-architecture/06/
• https://datatracker.ietf.org/doc/rfc9518/
• SOLID Project

Panel Description

Internet Decentralization – Next Steps

The previous DINRG meetings all had lively open mic discussions. However we noticed that those spontaneous conversations, while being interesting and insightful, tend to head to different issues in diverse directions. At this meeting we will continue/extend the previous discussions by gathering a small group of panelists and start the discussion with a list of questions collected from the previous meetings. We will have an open mic for all audience and share the list of discussion questions on DINRG list before the meeting; by gathering a panel and preparing a list of questions, we hope to make the discussions more effective and fruitful, moving towards our overarching goal of identifying an ordered list of issues that DINRG aims to address in coming years.

Links

• DINRG Presentations in the IETF
  datatracker
• MeetEcho
• Onsite
  tool
• Notes
• DINRG Wiki
• IETF-120 Agenda

Many Internet of Things (IoT) applications have requirements that cannot be satisfied by centralized cloud-based systems (i.e., cloud computing). These include time sensitivity, data volume, connectivity cost, operation in the face of intermittent services, privacy, and security. As a result, IoT is driving the Internet toward edge computing.

We have published RFC 9556, outlining the requirements of the emerging IoT edge and its challenges. It presents a general model and major components of the IoT edge to provide a common basis for future discussions in the Thing-to-Thing Research Group (T2TRG) and other IRTF and IETF groups.

Today, many IoT services leverage cloud computing platforms because they provide virtually unlimited storage and processing power. The reliance of IoT on back-end cloud computing provides additional advantages, such as scalability and efficiency. At the time of writing, IoT systems are fairly static with respect to integrating and supporting computation. It is not that there is no computation, but that systems are often limited to static configurations (edge gateways and cloud services).

However, IoT devices generate large amounts of data at the edges of the network. To meet IoT use case requirements, data is increasingly being stored, processed, analyzed, and acted upon close to the data sources. These requirements include time sensitivity, data volume, connectivity cost, and resiliency in the presence of intermittent connectivity, privacy, and security, which cannot be addressed by centralized cloud computing. A more flexible approach is necessary to address these needs effectively. This involves distributing computing (and storage) and seamlessly integrating it into the edge-cloud continuum. We refer to this integration of edge computing and IoT as "IoT edge computing". RFC 9556 describes the related background, use cases, challenges, system models, and functional components.

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.

In the Information-Centric Networking Research Group (ICNRG) of the Internet Research Task Force (IRTF) we have recently published a set of new RFCs:

RFC 9510: Alternative Delta Time Encoding for Content-Centric Networking (CCNx) Using Compact Floating-Point Arithmetic

Content-Centric Networking (CCNx) utilizes delta time for a number of functions. When using CCNx in environments with constrained nodes or bandwidth-constrained networks, it is valuable to have a compressed representation of delta time. In order to do so, either accuracy or dynamic range has to be sacrificed. Since the current uses of delta time do not require both simultaneously, one can consider a logarithmic encoding. This document updates RFC 8609 ( to specify this alternative encoding.

RFC 9531: Path Steering in Content-Centric Networking (CCNx) and Named Data Networking (NDN)

Path steering is a mechanism to discover paths to the producers of Information-Centric Networking (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 multi-path congestion control algorithms and for network measurement and management. This specification derives directly from the design published in https://dl.acm.org/doi/10.1145/3125719.3125721 (4th ACM Conference on Information-Centric Networking) and, therefore, does not recapitulate the design motivations, implementation details, or evaluation of the scheme. However, some technical details are different, and where there are differences, the design documented here is to be considered definitive.

RFC 9508: Information-Centric Networking (ICN) Ping Protocol Specification

This document presents the design of an Information-Centric Networking (ICN) Ping protocol. It includes the operations of both the client and the forwarder.

Ascertaining data plane reachability to a destination and taking coarse performance measurements of Round-Trip Time (RTT) are fundamental facilities for network administration and troubleshooting. In IP, where routing and forwarding are based on IP addresses, ICMP Echo Request and ICMP Echo Reply packets are the protocol mechanisms used for this purpose, generally exercised through the familiar ping utility. In Information-Centric Networking (ICN), where routing and forwarding are based on name prefixes, the ability to ascertain the reachability of names is required.

In order to carry out meaningful experimentation and deployment of ICN protocols, new tools analogous to ping and traceroute used for TCP/IP are needed to manage and debug the operation of ICN architectures and protocols. This document describes the design of a management and debugging protocol analogous to the ping protocol of TCP/IP; this new management and debugging protocol will aid the experimental deployment of ICN protocols. As the community continues its experimentation with ICN architectures and protocols, the design of ICN Ping might change accordingly. ICN Ping is designed as a "first line of defense" tool to troubleshoot ICN architectures and protocols. As such, this document is classified as an Experimental RFC. Note that a measurement application is needed to make proper use of ICN Ping in order to compute various statistics, such as average, maximum, and minimum Round-Trip Time (RTT) values, variance in RTTs, and loss rates.

RFC 9507: Information-Centric Networking (ICN) Traceroute Protocol Specification

This document presents the design of an Information-Centric Networking (ICN) Traceroute protocol. This includes the operation of both the client and the forwarder.

In TCP/IP, routing and forwarding are based on IP addresses. To ascertain the route to an IP address and to measure the transit delays, the traceroute utility is commonly used. In Information-Centric Networking (ICN), routing and forwarding are based on name prefixes. To this end, the ability to ascertain the characteristics of at least one of the available routes to a name prefix is a fundamental requirement for instrumentation and network management. These characteristics include, among others, route properties such as which forwarders were transited and the delay incurred through forwarding.

In order to carry out meaningful experimentation and deployment of ICN protocols, new tools analogous to ping and traceroute used for TCP/IP are needed to manage and debug the operation of ICN architectures and protocols. This document describes the design of a management and debugging protocol analogous to the traceroute protocol of TCP/IP; this new management and debugging protocol will aid the experimental deployment of ICN protocols. As the community continues its experimentation with ICN architectures and protocols, the design of ICN Traceroute might change accordingly. ICN Traceroute is designed as a tool to troubleshoot ICN architectures and protocols.

The emerging term In-Network Computin (INC) [inc] in particular refers applying on-path programmable networking devices (e.g., switches and routers between clients and servers) as an accelerator or function offloader to boost throughput, reduce server load, or improve latency, typically in a well-controlled data center network environment.

Some INC implementations evolved from programmable data plane systems and align with the trend of network programmability at large. In recent year, it has been shown to support many promising applications (e.g., caching, aggregation, and agreement). For example, in distributed machine learning (DML), training nodes produce data (gradients) that needs to be aggregated or reduced -- and the result could be distributed to one or multiple consumers. As another example, the NetClone system [netclone] uses in-network forwarder to replicate RPC invocation messages and to perform more informed forwarding based on observed latencies for accelerating RPC communication.

While it is possible to achieve this kind of operation purely with end-to-end communication between worker nodes, performance can be dramatically improved by offloading both the operation processing and the data dissemination to nodes in the network. These in-network processors are often conceived as semi-transparent performance enhancing on-path elements, i.e., they are not the actual endpoints in transport protocol sessions and would intercept packets with application data and potentially generate new data that they would have to transmit.

In our Internet Draft draft-song-inc-transport-protocol-req-01.txt, we are discussing this problem and are formulating some requirements for the design of future transport protocols in this space.

References

• Collective Communication: Better Network Abstractions for AI
• Computing in the Network – Lessons Learned and New Opportunities
• [I-D.yao-tsvwg-cco-problem-statement-and-usecases] Yao, K., Shiping, X., Li, Y., Huang, H., and D. KUTSCHER, "Collective Communication Optimization: Problem Statement and Use cases", Work in Progress, Internet-Draft, draft-yao-tsvwg-cco-problem-statement-and-usecases-00, 23 October 2023, https://datatracker.ietf.org/doc/html/draft-yao-tsvwg-cco-problem-statement-and-usecases-00.
• [inc] Klenk et al., B., "An In-Network Architecture for Accelerating Shared-Memory Multiprocessor Collectives", ACM/IEEE 47th Annual International Symposium on Computer Architecture (ISCA), 2020, <https:dx.doi.org/10.1109/ISCA45697.2020.00085>
• [netclone] Kim, G., "NetClone: Fast, Scalable, and Dynamic Request Cloning for Microsecond-Scale RPCs", In Proceedings of the ACM SIGCOMM 2023 Conference (ACM SIGCOMM '23). Association for Computing Machinery, New York, NY, USA, 195-207, 2023 https://dl.acm.org/doi/10.1145/3603269.3604820