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.

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

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

Documents

• The Cloud Strikes Back: Investigating the Decentralization of IPFS
• Local-First Software
• draft-mcfadden-consolidation-taxonomy-03

Logistics

DINRG Meeting at IETF-118 – 2023-11-06, 08:30 to 10:30 UTC

• MeetEcho
• Onsite tool
• Notes
• IETF-118 Agenda

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.

Decentralization of the Internet Research Group at IETF-117

The Decentralization of the Internet Research Group (DINRG) of the Internet Research Task Force (IRTF) had a meeting on 2023-07-27 at the 117th meeting of the Internet Engineering Task Force (IETF). DINRG aims to provide for the research and engineering community, both an open forum to discuss the Internet centralization phenomena and associated potential threats, and a platform to facilitate the coordination of efforts in identifying the causes of observed consolidations and the mitigation solutions.

For context, we recently published a workshop report that discusses some fundamental problems: ACM SIGCOMM CCR: Report of 2021 DINRG Workshop on Centralization in the Internet

The DINRG meeting at IETF-117 meeting featured three highly interesting talks by Cory Doctorow, Volker Stocker & William Lehr, and Christian Tschudin that created quite some attention and led to lively discussions during and after the meeting. There is a full meeting recording on youTube, and we have published meeting minutes. Special thanks to Ryo Yanagida, A.J. Stein, and Eve Schooler for taking notes at the meeting.

Cory Doctorow: Let The Platforms Burn: Bringing Back the Good Fire of the Old Internet

Cory Doctorow, a science fiction author, activist and journalist, talked about a trend in platform evolution that he calls enshittification, where platforms go through different phases after growing user bases quickly as per platform economics and market domination strategies and of locking in users through technical and economic barriers. In advertisement (and digital online market) platforms, the platform operator sits between the users and other companies (so-called "two-sided market" scenarios), where the user base, the obtained personal information and behavioral surveillance results become assets to attracts such companies.

For example, in order to make avertising more effective, social media platforms would increase control of users's timelines, i.e., content that is presented to them, and make it harder for users to leave the platform. Overall this results in negative user experience. For increasing advertisment revenue, platforms would then sell attention more directly, i.e., exploit their position in the advertisement market. See Cory's posting on enshittification for details.

This process and the difficulties in effectively controlling and regulating platform companies, has led to a permanent crisis that Cory compares to a fire hazard situation. Platforms were rocked by scandals private data theft, accidental leaks and intended data sharing with other insitutions etc.

While the computer and networking world has seen a constant emerging and vanishing of "platforms" (operating systems, PC companies, online services) before, the current concentrated tech market makes is impossible to let harmful (or not very user-friendly) dissolve. This is due to network effects (Metcalfe's law) and switching costs, for example when trying to leave a dominant social media platforms and thereby losing connections to friends. This monopoly situation is enabled by a legal environment with ineffective antitrust laws, which has allowed for dominating platform to constantly acquire competing companies and potentially disruptive businesses.

With new laws for content moderation and censorship, platform get even more control over their users (in the name of preventing harrassment), without making in any easier to leave platforms. In his article (and podcast epsidode) called "Let the Platforms Burn", Cory concluded

Platforms collapse "slowly, then all at once." The only way to prevent sudden platform collapse syndrome is to block interoperability so users can't escape the harms of your walled garden without giving up the benefits they give to each other.

We should stop trying to make the platforms good. We should make them gone. We should restore the "good fire" that ended with the growth of financialized Big Tech empires. We should aim for soft landings for users, and stop pretending that there's any safe way to life in the fire zone.

We should let the platforms burn.

WIth respect to the (de-)centralization discussion in DINRG and the Internet community, this raises some important question as to

• what is the role of open interfaces, standards etc today in reality? Are we still using them to build interoperable, possibly federated systems?
• how should technology development, standards setting and regulation evolve to effectively enable user choice (migration, platform selection)?

Discussion

There was a question whether the real issue was that platforms are making a remarkable griphold, buying each other, but they are buying the users, i.e., whether the primary concern is the size of these platforms with this method or the method itself only? Cory replied in saying that size certainly promotes distortions. Scale was problem for two reasons. The contract enforcement function dominates. When the referee is less powerful than the team, it allows teams to cheat.
Secondly, even if we stipulated that companies are well run by smart people, they all make errors, and at that scale the mistakes are much more consequential.

Another question was who is willing to implement the interoperability standards and how companies can be convinved to do that. Cory talked about companies' motivation, i.e., companies wanted walled gardens, or to have APIs with advantages (vs disadvantages) to them. What they really seeked (over competitive interoperability) was to have legal remedies for those who reverse engineer to competitively enter the market. When there was a mandate and permission for inter-operators, if restoring that power was possible, that would help to avoid unquantifiable risk.

Some of these strategies are discussed in Cory upcoming book "How to seize the means of computation”.

Volker Stocker and William Lehr: Ecosystem Evolution and Digital Infrastructure Policy Challenges: Insights & Reflections from an Economics Perspective"

Volker Stocker of the Weizenbaum Institute for the Networked Society and William Lehr of the Advanced Networking Architecture Group in CSAIL at MIT presented their research on ecosysem evolution and policy challenges from an economics perspective. Volker is an economist with broad experience in interdisciplinay research, and William is a telecommunications and Internet economist and consultant.

Volker talked about the convergence of digital and non-digital worlds and mentioned a few trends that needed attention:

• The shift to the edge and shift to the localization of traffic.
• Ownership and management has shifted in the Internet ecosystem: sometimes hyper giant content providers with proprietary networks, sometimes edge clouds or roving resources.
• Potential consequences: value chain constellations are more complex, diverse & dynamic, resulting in changing ownership and governance structures, industry structures as well as competititve and innovational dynamics.

Volker made three points in his reflections on ecosystem evolution:

1. Essential digital infrastructure is about more than connectiivty, not just connectivities like IPX and ISPs.
2. The majority of the requisite investmenet will be private! E.g., access ISPs, CAPs, CDNs, upstream ISPs, and end-users are all investing.
3. More and new forms of resource sharing will be needed. More network sharing agreements: active & passive sharing arrangements and optimal models are evolving.

William highlighted that the legacy Internet is not the Internet of today, and the economics of yesterday are not those of today. One of the questions is how to restore meaningful competition?

He mentioned the following challenges and paths forward:

1. Multidisciplinary Engagement & Feedback
2. Assymetric Info & Measurements: Metrics and data (and their provenance)
3. Capacity to Detect and Act

Discussion

There was a discussion about how the private sector is expected to profit from the infrastructure development needed by society (assuming investments from the private sector). William replied in saying that
government built/subsidized most infrastructure in most places, with small investments needed initially. Some say significant investment should come from the utilities, which we should not dismiss. But we likely will need a strong argument on how to get there. Either we say there is a lot of money coming from public sector (for example, through taxes) or we have to find a way to manage private actors. Thus policy issues are important. Some of these questions are discussed in Williams paper on "Getting to the Broadband Future Efficiently with BEAD funding”.

Another question alluded to policy lagging behing the technical development, i.e., the mismatch of speed of innovation and speed of regulation (which is really hard at the national and internationl levels). William said that the best hope is standards and architectures that provides options and mentioned the importance of open source software.

Christian Tschudin: Minimal Global Broadcast

Christian Tschudin of the University of Basel presented a research idea called "Minimal Global Broadcast" (abstract). Christian is a computer science professor with a track record of research in Information-Centric Networking, distributed computing, and decentralized systems.

Christian started out from the observation that contacting peers in a decentralized environment is challenging. The key question is how do you learn about a peer’s current coordinates and their preferences? The platforms themselves often offer directories, but these are logically centralized rendezvous servers with a partial view and require trust in these platforms. Instead of conceptualizing an uber directory service Christian proposed a global information dissemination system that focuses on the data, asserting an allowance of “200 bytes of novelty per month
and citizen”.

This global broadcast channel can (and should) be implemented in many ways, starting from sneakernets to shortwave communication and including Internet-based online-services. Christian explained how such a service could be used to facilitate user migration and user discovery on their current preferred platform(s).

Discussion

There were some question on trust in user identities. Christian said that trust roots would be external to MGB, and that there would be different levels of trust, e.g., for inter-personal relationship vs. business relationships.

References

• DINRG charter
• DINRG@IETF-117 Meeting Material
• DINRG@IETF-117 Meeting Minutes
• DINRG@IETF-117 Video Recording
• Volker Stocker and William Lehr; Ecosystem Evolution and Digital Infrastructure Policy Challenges: Insights & Reflections from an Economics Perspective; presentation at IRTF DINRG; 2023-07-25; San Francisco
• ACM SIGCOMM CCR: Report of 2021 DINRG Workshop on Centralization in the Internet
• Cory Doctorow; The 'Enshittification' of TikTok – Or how, exactly, platforms die; Wired; 2023-01-23
• Cory Doctorow; Let the Platforms Burn; 2023-07-10
• Lehr, W. (2023), “Getting to the Broadband Future Efficiently with BEAD funding,” white paper prepared with support from WISPA, January 2023, available at https://www.wispa.org/docs/Lehr_White_Paper_Final.pdf
• Lehr, W. (2022), “5G and AI Convergence, and the Challenge of Regulating Smart Contracts,” in Europe’s Future Connected: Policies and Challenges for 5G and 6G Networks, edited by E. Bohlin and F. Cappelletti, European Liberal Forum (ELF), pages 72-80, available at https://liberalforum.eu/publication/europes-future-connected-policies-and-challenges-for-5g-and-6g-networks/.
• Lehr, W. and V. Stocker (2023), "Next-generation Networks: Necessity of Edge Sharing," forthcoming Frontiers in Computer Science: Networks and Communications, Summer 2023
• Oughton, E., W. Lehr, K. Katsaros, I. Selinis, D. Bubley, and J. Kusuma (2021), "Revisiting Wireless Internet Connectivity: 5G vs. Wi-Fi 6," Telecommunications Policy, 45 (2021) 102127, available at https://authors.elsevier.com/sd/article/S0308-5961(21)00032-X.
• Stocker, V. and W. Lehr (2022), “Regulatory Policy for Broadband: A Response to the ‘ETNO Report’s’ Proposal for Intervention in Europe’s Internet Ecosystem,” white paper, available at https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4263096.
• Stocker, V., Smaragdakis, G., and Lehr, W. (2020). The state of network neutrality regulation. SIGCOMM Comput. Commun. Rev. 50, 1 (January 2020), 45–59. https://doi.org/10.1145/3390251.3390258
  Work in progress
• Frias, Z., Mendo, L., Lehr, W. and Stocker, V. (2023), "Measuring NextGen Mobile Broadband: Challenges and Research Agenda for Policymaking", 32nd European International Telecommunications Society Conference (EuroITS2023), June 19-20, Madrid, Spain.
• Lehr, W., D. Sicker, D. Raychaudhuri, V. Singh (2023), “Edge Computing: digital infrastructure beyond broadband connectivity,” TPRC51: Annual Research Conference on Communications, Information and Internet Policy, September 22-23, 2023, American University, Washington DC
• Stocker, V. Bauer, J., and Pourdamghani, A. (2023). "Innovation Dynamics in the Internet Ecosystem & Digital Economy Policy”,, 32nd European International Telecommunications Society Conference (EuroITS2023), June 19-20, Madrid, Spain.
• Christian Tschudin; Minimal Global Broadcast (MGB); presentation and abstract at IRTF DINRG meeting at IETF-117, 2023-07-25

We have updated our Internet Draft on Directions for Computing in the Network.

In-network computing can be conceived in many different ways -- from active networking, data plane programmability, running virtualized functions, service chaining, to distributed computing.

This memo proposes a particular direction for Computing in the Networking (COIN) research and lists suggested research challenges.

This is now an adopted COINRG work item.

Link to draft: draft-irtf-coin-dir.

ACM SIGCOMM CCR just published the report of our 2021 DINRG meeting on Centralization in the Internet.

Executive Summary

There is a consensus within the networking community that the Internet consolidation and centralization trend has progressed rapidly over recent years, as measured by the structural changes to the data delivery infrastructure, the control power over system platforms, application development and deployment, and even in the standard development efforts. This trend has brought impactful technical, societal, and economical consequences.

When the Internet was first conceived as a decentralized system 40+ years back, few people, if any, could have foreseen how it looks today. How has the Internet evolved from there to here? What have been the driving forces for the observed consolidation? From a retrospective view, was there anything that might have been done differently to influence the course the Internet has taken? And most importantly, what should and can be done now to mitigate the trend of centralization? Although there are significant interests in these topics, there has not been much structured discussion on how to answer these important questions.

The IRTF Research Group on Decentralizing the Internet (DINRG) organized a workshop on “Centralization in the Internet” on June 3, 2021, with the objective of starting an organized open discussion on the above questions. Although there seems to be an urgent need for effective countermeasures to the centralization problem, this workshop took a step back: before jumping into solution development to steer the Internet away from centralization, we wanted to discuss how the Internet has evolved and changed, and what have been the driving forces and enablers for those changes. The organizers and part of the community believe that a sound and evidence-based understanding is the key towards devising effective remedy and action plans. In particular, we would like to deepen our understanding of the relationship between the architectural properties and economic developments.

This workshop consisted of two panels, each panel started with an opening presentation, followed by panel discussions, then open-floor discussions. There was also an all-hand discussion at the end. Three hours of the workshop presentations and discussions showed that this Internet centralization problem space is highly complex and filled with intrinsic interplays between technical and economic factors.

This report aims to summarize the workshop outcome with a broad-brush picture of the problem space. We hope that this big picture view could help the research group, as well as the broader IETF community, to reach a clearer and shared high-level understanding of the problem, and from there to identify what actions are needed, which of them require technical solutions, and which of them are regulatory issues which require technical community to provide inputs to regulatory sectors to develop effective regulation policies.

You can find the report in the ACM Digital Library. We also have a pre-print version.

Recent years have witnessed the consolidations of the Internet applications, services, as well as the infrastructure. The Decentralization of the Internet Research Group (DINRG) aims to provide for the research and engineering community, both an open forum to discuss the Internet centralization phenomena and associated potential threats, and a platform to facilitate the coordination of efforts in identifying the causes of observed consolidations and the mitigation solutions.

Our upcoming DINRG meeting at IETF-117 will feature three talks – by Cory Doctorow, Volker Stocker & William Lehr, and Christian Tschudin.

Documents

• Cory Doctorow: Let the Platforms Burn
• Christian Tschudin: Minimal Global Broadcast (MGB)

Logistics

DINRG Meeting at IETF-117 – 2023-07-25, 20:00 to 21:30 UTC

IETF-117 Agenda