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:

1	ICNRG Chairs’ Presentation: Status, Updates	Chairs
2	Secure Web Objects and Transactions	Dirk Kutscher
3	Transaction Manifests	Marc Mosko
4	Vanadium: Secure, Distributed Applications	Marc Mosko
5	Global vs. Scoped Namespaces	Marc Mosko

---

---

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.

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

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

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

Edmund Yeh: NDN for Data-Intensive Science Experiments

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

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

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

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

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

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

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

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

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

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

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

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

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

Dave Oran: Ping & Traceroute Update

Dave Oran presented the recent updates to two specifications:

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

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

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

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

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

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

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

Dave Oran: Path Steering Refresher

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

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

ICN Path Steering would enable

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

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

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

Dirk Kutscher: Reflexive Forwarding Re-Design

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

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

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

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

Example: RESTful communication over ICN

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

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

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

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

Reflexive Forwarding Design

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

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

Potential Applications

Potential applications include

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

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

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

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

Recent RFC Publications

ICNRG published two RFCs recently:

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

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

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

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

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

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

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

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

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

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

ICNRG Meeting on December 10th 2021

• Meeting Material
• Video Recording

Agenda

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

---

Zenoh

• Carlos Guimarães
• Presentation
• Video Recording

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

---

SPAN Network Architecture

• Rhett Sampson and Jaime Lorca
• Presentation
• Video Recording

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

---

NDNts API Design

• Junxiao Shi
• Presentation
• Video Recording

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

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

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

---

Big Data Processing

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

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

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

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

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

Further optimizations can be achieved through:

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

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

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

---

Broker-Based Publish/Subscribe

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

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

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

Technically, the system is based on

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

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

---

NDN-Based Ethereum Blockchain

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

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

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

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

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

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

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

---

Producer Anonymity based on Onion Routing in Named Data Networking

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

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

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

The authors have developed a system that is

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

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

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

---

A Data-Centric View on the Web of Things

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Discussion on the ICNRG mailing list.

ACM ICN-2019 took place in the week of September 23 in Macau, SAR China. The conference was co-located with Information-Centric-Networking-related side events: the TouchNDN Workshop on Creating Distributed Media Experiences with TouchDesigner and NDN before and an IRTF ICNRG meeting after the conference. In the following, I am providing a summary of some highlights of the whole week from my (naturally very subjective) perspective.

Applications

ICN with its accessing named data in the network paradigm is supposed provide a different, hopefully better, service to application compared to the traditional stack of TCP/IP, DNS and application-layer protocols. Research in this space is often addressing one of two interesting research questions: 1) What is the potential for building or re-factoring applications that use ICN and what is the impact on existing designs; and 2) what requirements can be learned for the evolution of ICN, what services are useful on top of an ICN network layer, and/or how should the ICN network layer be improved.

Network Management

The best paper at the conference on Lessons Learned Building a Secure Network Measurement Framework using Basic NDN by Kathleen Nichols took the approach of investigating how a network measurement system can be implemented without inventing new features for the NDN network layer. Instead, Kathleen's work explored the features and usability support mechanisms that would be needed for implementing her Distributed Network Measurement Protocol (DNMP) in terms of frameworks and libraries leveraging existing NDN. DNMP is secure, role-based framework for requesting, carrying out, and collecting measurements in NDN forwarders. As such it represents a class of applications where applications both send and receive data that is organized by hierarchical topics in a namespace which implies a conceptual approach where applications do not (want to) talk to specific producers but are really operating in an information-centric style.

Communication in such a system involves one-to-many, many-to-one, and any-to-any communications about information (not data objects hosted at named nodes). DNMP employs a publish/subscribe model inspired by protocols such as MQTT where publishers and subscribers communicate through hierarchically structured topics. Instead of existing frameworks for data set reconciliation, with DNMP work includes the development of a lightweight pub/sub sync protocol called syncps that uses Difference Digests, solving the multi-party set reconciliation problem with prior context.

In a role-based system such as DNMP that uses secure Named-Data-based communication, automating authentication and access control is typically a major challenge. DNMP leverages earlier work on Trust Schema but extends this by a Versatile Security Toolkit (VerSec) that integrates with the transport framework to simplify integration of trust rules. VerSec is about to be released under GPL.

I found this paper really interesting to read because it is a nice illustration of what kind of higher layer services and APIs non-trivial application require. Also, the approach of using the NDN network layer as is but implementing additional functionality as libraries and frameworks seems promising with respect to establishing a stable network layer platform where innovation can happen independently on top. Moreover, the paper embraces Information-Centric thinking nicely and demonstrates the concept with a relevant application. Finally, I am looking forward to see the VerSec software which could make it easier for developers to implement rigorous security and validation in the applications.

Distributed Media Experiences

Jeff Burke and Peter Gusev organized the very cool TouchNDN workshop on Creating Distributed Media Experiences with TouchDesigner and NDN at the School of Creative Media at the City University of Hong Kong (summary presentation). The background is that video distribution/access has evolved significantly from linear TV broadcast to todays applications. Yet, many systems still seem to be built in a way that optimizes for linear video streaming to consumer eye balls, with a frame sequence abstraction.

Creative media applications such as Live Show Control (example) exhibit a much richer interaction with digital video, often combing 3D modelling with flexible, non-sequential access to video based on (for example) semantics, specific time intervals, quality layers, or spatial coordinates.

Combine this with dynamic lightning, sound control and instrumentation of theater effects, and you get an idea of an environment where various pieces of digital media are mixed together creatively and spontaneously. Incidentally, a famous venue for such an installation is the Spectacle at MGM Cotai, close to the venue of ACM ICN-2019 in Macau.

Derivative's TouchDesigner is a development platform for such realtime user experiences. It is frequently used for projection mapping, interactive visualization and other applications. The Center for Research in Engineering, Media and Performance (REMAP) has developed an integration of NDN with TouchDesigner's realtime 3D engine via the NDN-Common-Name-Library stack as a platform for experimenting with data-centric media. The objective is to provide a more natural networked media platform that does not have to deal with addresses (L2 or L3) but enables applications to publish and request media assets in namespaces that reflect the structure of the data. Combing this with other general ICN properties such as implicit multicast distribution and in-network caching results in a much more adequate platform for creating realtime multimedia experiences.

The TouchNDN workshop was one of REMAP's activities on converging their NDN research with artistic and cultural projects, trying to get NDN out of the lab and into the hands of creators in arts, culture, and entertainment. It is also an eye-opener for the ICN community for learning about trends and opportunities in real-time rendering and visual programming which seems to bear lots of potential for innovation -- both from the artistic as well as from the networking perspective.

Personally, I think it's a great, inspiring project that teaches us a lot about more interesting properties and metrics (flexible access, natural APIs, usability, utility for enabling innovations) compared to the usual quantitative performance metrics from the last century.

Inter-Server Game State Synchronization

Massive Multiplayer Online Role-Playing Games (MMORPGs) allow up to thousands of players to play in the same shared virtual world. Those worlds are often distributed on multiple servers of a server cluster, because a single server would not be able to handle the computational load caused by the large number of players interacting in a huge virtual world. This distribution of the world on a server cluster requires to synchronize relevant game state information among the servers. The synchronization requires every server to send updated game state information to the other servers in the cluster, resulting in redundantly sent traffic when utilizing current IP infrastructure.

In their paper Inter-Server Game State Synchronization using Named Data Networking Philipp Moll, Sebastian Theuermann, Natascha Rauscher, Hermann Hellwagner, and Jeff Burke started from the assumption that ICN's implicit multicast support and the ability to to decouple the game state information from the producing server could reduce the amount of redundant traffic and also help with robustness and availability in the presence of server failures.

They built a ICNified version of Minecraft and developed protocols for synchronizing game state in a server cluster over NDN. Their evaluation results indicated the benefits on an ICN-based approach for inter-server game state synchronization despite larger packet overheads (compared to TCP/IP). The authors made all their artefacts required for reproducing the results available on github.

Panel on Industry Applications of ICN

I had the pleasure of moderating a panel on industry applications of ICN, featuring Richard Chow (Intel), Kathleen Nichols (Pollere Inc.), and Kent Wu (Hong Kong Applied Science and Technology Research Institute). Recent ICN research has produced various platforms for experimentation and application development. One welcome development consists of initial ICN deployment mechanisms that do not require a forklift replacement of large parts of the Internet. At the same time, new technologies and use cases, such as edge computing, massively scalable multiparty communication, and linear video distribution, impose challenges on the existing infrastructure. This panel with experts from different application domains discussed pain points with current systems, opportunities and promising results for building specific applications with ICN, and challenges, shortcomings, and ideas for future evolution of ICN.

What was interesting to learn was how different groups pick up the results and available software to build prototypes for research and industry applications and what they perceive as challenges in applying ICN.

Decentralization

Growing concerns about centralization, surveillance and loss of digital sovereignty are currently fuelling many activities around P2P-inspired communication and storage networks, decentralized web ("web3") efforts as well as group such as the IRTF Research Group on Decentralized Internet Infrastructure (DINRG). One particular concern is the almost universal dependency on central cloud platforms for anchoring trust in applications that are actually of a rather local nature such as smart home platforms. Since such platforms often entail rent-seeking or surveillance-based business models, it is becoming increasingly important to investigate alternatives.

NDN/CCN-based ICN with its built-in PKI system provides some elements for an alternative design. In NDN/CCN it is possible to set up secure communication relationships without necessarily depending on third-party platforms which could be leveraged for more decentralized designs of IoT systems, social media and many other applications.

Decentralized and Secure Multimedia Sharing

A particularly important application domain is multimedia sharing where surveillance and manipulation campaigns by the dominant platforms have led to the development of alternative federated social media applications such as Mastodon and Diaspora. In their paper Decentralized and Secure Multimedia Sharing Application over Named Data Networking Ashlesh Gawande, Jeremy Clark, Damian Coomes, and Lan Wang described their design and implementation of npChat (NDN Photo Chat), a multimedia sharing application that provides similar functionality as today’s media-sharing based social networking applications without requiring any centralized service providers.

The major contributions of this work include identifying the specific requirements for a fully decentralized application, and designing and implementing NDN-based mechanisms to enable users to discover other users in the local network and through mutual friends, build friendship via multi-modal trust establishment mirrored from the real world, subscribe to friends’ multimedia data updates via pub-sub, and control access to their own published media.

This paper is interesting in my view because it illustrates the challenges and some design options nicely. It also suggests further research in terms of namespace design, name privacy and trust models. The authors developed an NDN-based prototype for Android systems that is supposed to appear on the Android Play store soon.

Exploring the Relationship of ICN and IPFS

We were happy to have David Dias, Adin Schmahmann, Cole Brown, and Evan Miyazono from Protocol Labs at the conference who held a tutorial on IPFS that also touched upon the relationship of IPFS and some ICN approaches.

Protocol Lab's InterPlanetary File System (IPFS) is a peer-to-peer content-addressable distributed filesystem that seeks to connect all computing devices with the same system of files. It is an opensource community-driven project, with reference implementations in Go and Javascript, and a global community of millions of users. IPFS resembles past and present efforts to build and deploy Information-Centric Networking approaches to content storage, resolution, distribution and delivery. IPFS and libp2p, which is the modular network stack of IPFS, are based on name-resolution based routing. The resolution system is based on Kademlia DHT and content is addressed by flat hash-based names. IPFS sees significant real-world usage already and is projected to become one of the main decentralised storage platforms in the near future. The objective of this tutorial is to make the audience familiar with IPFS and able to use the tools provided by the project for research and development.

Interestingly IPFS bear quite some similarities with earlier ICN systems such as NetInf but is using traditional transport and application layer protocols for the actual data transfer. One of the interesting research questions in that space are how IPFS system could be improved with today's ICN technology (as an underlay) but also how the design of a future IPFS-like system could leverage additional ICN mechanisms such as Trust Schema, data set reconciliation protocols, and remote method invocation. The paper Towards Peer-to-Peer Content Retrieval Markets: Enhancing IPFS with ICN by Onur Ascigil, Sergi Reñé, Michał Król et al. explored some of these options.

IoT

IoT is one of the interesting application areas for ICN, especially IoT in constrained environments, where the more powerful forwarding model (stateful forwarding and in-network caching) and the associated possibility for more fine-grained control of storage and communication resources incurs significant optimization potential (which was also a topic at this year's conference).

QoS Management in Constrained NDN Networks

Quality of Service (QoS) in the IP world mainly manages forwarding resources, i.e., link capacities and buffer spaces. In addition, Information Centric Networking (ICN) offers resource dimensions such as in-network caches and forwarding state. In constrained wireless networks, these resources are scarce with a potentially high impact due to lossy radio transmission. In their paper Gain More for Less: The Surprising Benefits of QoS Management in Constrained NDN Networks Cenk Gündoğan, Jakob Pfender, Michael Frey, Thomas C. Schmidt, Felix Shzu-Juraschek, and Matthias Wählisch explored the two basic service qualities (i) prompt and (ii) reliable traffic forwarding for the case of NDN. The resources that were taken into account are forwarding and queuing priorities, as well as the utilization of caches and of forwarding state space. The authors treated QoS resources not only in isolation, but also correlated their use on local nodes and between network members. Network-wide coordination is based on simple, predefined QoS code points. The results indicate that coordinated QoS management in ICN is more than the sum of its parts and exceeds the impact QoS can have in the IP world.

What I found interesting about his paper is the validation in real-world experiments that demonstrated impressive improvements, based on the coordinated QoS management approach. This work comes timely considering the current ICN QoS discussion in ICNRG, for example in draft-oran-icnrg-qosarch. Also, the authors made their artefacts available on github for enabling reproducing their results.

How Much ICN Is Inside of Bluetooth Mesh?

Bluetooth mesh is a new mode of Bluetooth operation for low-energy devices that offers group-based publish-subscribe as a network service with additional caching capabilities. These features resemble concepts of information-centric networking (ICN), and the analogy to ICN has been repeatedly drawn in the Bluetooth community. In their paper Bluetooth Mesh under the Microscope: How much ICN is Inside? Hauke Petersen, Peter Kietzmann, Cenk Gündoğan, Thomas C. Schmidt, and Matthias Wählisch compared Bluetooth mesh with ICN both conceptually and in real-world experiments. They contrasted both architectures and their design decisions in detail. They conducted experiments on an IoT testbed using NDN/CCNx and Bluetooth Mesh on constrained RIOT nodes.

Interestingly the authors found that the implementation of ICN principles and mechanisms in Bluetooth Mesh is rather limited. In fact, Bluetooth Mesh performs flooding without content caching and merely using the equivalent of multicast addresses as a surrogate for names. Based on these findings, the authors discuss options of how ICN support for Bluetooth could or should look like, so the paper is interesting both for understanding the actual working of Bluetooth Mesh as well as for ideas for improving Bluetooth Mesh. The authors made their artefacts available on github for enabling reproducing their results.

ICN and LoRa

LoRa is an interesting technology for its usage of license-free sub-gigahertz spectrum and bi-directional communication capabilities. We were happy to have Kent Wu and Xiaoyu Zhao from ASTRI at the conference and the ICNRG meeting who talked about their LoRa prototype development for a smart metering system for water consumption in Hong Kong. In addition to that, the ICNRG also discussed different options for integrating ICN and LoRa and got an update by Peter Kietzmann on the state of LoRa support in the RIOT OS. This is an exciting area for innovation, and we expect more work and interesting results in the future.

New Frontiers

Appying ICN to big data storage and processing and to distributed computing are really promising research directions that were explored by papers at the conference.

NDN and Hadoop

The Hadoop Distributed File System (HDFS) is a network file system used to support multiple widely-used big data frameworks that can scale to run on large clusters. In their paper On the Power of In-Network Caching in the Hadoop Distributed File System Eric Newberry and Beichuan Zhang evaluate the effectiveness of using in-network caching on switches in HDFS- supported clusters in order to reduce per-link bandwidth usage in the network.

They discovered that some applications featured large amounts of data requested by multiple clients and that, by caching read data in the network, the average per-link bandwidth usage of read operations in these applications could be reduced by more than half. They also found that the choice of cache replacement policy could have a significant impact on caching effectiveness in this environment, with LIRS and ARC generally performing the best for larger and smaller cache sizes, respectively. The authors also developed a mechanism to reduce the total per-link bandwidth usage of HDFS write operations by replacing write pipelining with multicast.

Overall, the evaluation results are promising, and it will be interesting to see how the adoption of additional ICN concepts and mechanisms and caching could be useful for big data storage and processing.

Compute-First Networking

Although, as a co-author, I am clearly biased, I am quite convinced of the potential for distributed computing and ICN that we described in a paper co-authored by Michał Król, Spyridon Mastorakis, David Oran, and myself.

Edge- and, more generally, in-network computing is receiving a lot attention in research and industry fora. What are the interesting research questions from a networking perspective? In-network computing can be conceived in many different ways – from active networking, data plane programmability, running virtualized functions, service chaining, to distributed computing. Modern distributed computing frameworks and domain-specific languages provide a convenient and robust way to structure large distributed applications and deploy them on either data center or edge computing environments. The current systems suffer however from the need for a complex underlay of services to allow them to run effectively on existing Internet protocols. These services include centralized schedulers, DNS-based name translation, stateful load balancers, and heavy-weight transport protocols.

Over the past years, we have been working on alternative approaches, trying to find ways for integrating networking and computing in new ways, so that distributed computing can leverage networking capabilities directly and optimize usage of networking and computing resources in a holistic fashion. Here is a summary of our latest paper.

The Internet Research Task Force (IRTF) has published two Experimental RFCs specifying the node behavior, message semantics, and the message syntax of the CCNx protocol: RFC 8569 (Content-Centric Networking (CCNx) Semantics) and RFC 8609 (Content-Centric Networking (CCNx) Messages in TLV Format). CCNx is one particular variant of ICN protocols. These specifications document the implementation of an available Open-Source implementation and are intended to encourage additional experiments with Information-Centric Networking technologies.

Background

Information-Centric Networking (ICN) is a class of architectures and protocols that provide "access to named data" as a first-order network service. Instead of host-to-host communication as in IP networks, ICNs often use location-independent names to identify data objects, and the network provides the services of processing (answering) requests for named data with the objective to finally deliver the requested data objects to a requesting consumer.

Such an approach has profound effects on various aspects of a networking system, including security (by enabling object-based security on a message/packet level), forwarding behavior (name-based forwarding, caching), but also on more operational aspects such as bootstrapping, discovery etc.

The CCNx and NDN variants of ICN are based on a request/response abstraction where consumers (hosts, applications requesting named data) send INTEREST messages into the network that are forwarded by network elements to a destination that can provide the requested named data object. Corresponding responses are sent as so-called DATA messages that follow the reverse INTEREST path.

Sometimes ICN has been mis-characterized as a solution for in-network caching, possibly replacing CDN. While ICN's location-independent access and its object-security approach does indeed enable opportunistic in-network data caching (e.g., for local retransmissions, data sharing), it is actually not the main feature -- it is actually rather a consequence of the more fundamental properties of 1) accessing named data, 2) object-security and integrated trust model, and 3) stateful forwarding.

Accessing Named Data

Each unique data object is named unambiguously in a hierarchical naming scheme and can be validated in a means specified by the producer, i.e., the origin source. (Data objects can also optionally be encrypted in different ways). The naming concept and the object-based validation approach lay the foundation for location independent operation, because data validity can be ascertained by any node in the network, regardless of where the corresponding messages was received from.

The network can generally operate without any notion of location, and nodes (consumers, forwarders) can forward requests for named data objects directly, i.e., without any additional address resolution. Location independence also enables additional features, for example the possibility to replicate and cache named data objects. Opportunistic on-patch caching is thus a standard feature in many ICN systems -- typically for enhancing reliability and performance.

Naming data and application-specific naming conventions are naturally important aspects in ICN. It is common that applications define their own naming convention (i.e., semantics of elements in the name hierarchy). Such names can often directly derived from application requirements, for example a name like /my-home/living-room/light/switch/main could be relevant in a smart home setting, and corresponding devices and application could use a corresponding convention to facilitate controllers finding sensors and actors in such a system with minimal user configuration.

Object-Security and Integrated Trust Model

One of the objection validation approaches is based on Public-Key cryptography, where publishers sign objects (parts of messages) and can name the Public Key in the message, so that a validator can retrieve the corresponding object (containing the Public Key and a certificate that would bind the key to a naming hierarchy). The certificate would be an element of a typical trust hierarchy.

Public-Key cryptography and PKI systems are also used in the Internet/Web today. In CCNx/NDN-based ICN, the key/certificate retrieval is directly provided by the network itself, i.e., it uses the same INTEREST/DATA protocol, and the system is typically used in a way that every object/message can be linked to a trust anchor.

Where that trust anchor resides is defined by the application semantics and its naming conventions. Unlike the Internet/Web today, it is not required to link to centralized trust anchors (such as root Certificate Authorities) -- instead it is possible to set up local, decentralized trustworthy networked systems in a permissionless manner.

Stateful Forwarding

In CCNx and NDN, forwarders are stateful, i.e., they keep track of forwarded INTEREST to later match the received DATA messages. Stateful forwarding (in conjunction with the general named-based and location-independent operation) also empowers forwarders to execute individual forwarding strategies and perform optimizations such as in-network retransmissions, multicasting requests (in cases there are several opportunities for accessing a particular named data object) etc.

Stateful forwarding enables nodes in the network to perform similar function as endpoints (i.e., consumers), so that there is not a strong distinction between these roles. For example, consumers and forwarders can control INTEREST sending rates to respond to observed network conditions. Adapting in-network transport behavior can thus be achieved naturally, i.e., without brittle, in-transparent middleboxes, TCP proxies etc.

ICN Scenarios

ICN is a general-purpose networking technologies and can thus be applied to many scenarios. I am highlighting a few particularly interesting ones in the following sections.

Scalable Media Distribution

The "Accessing Named Data" paradigm also implies that CCNx/NDN-based ICN is fundamentally connectionless. While there can be collections of Named Data Objects that are requested (and transmitted) in a flow-like manner (as a consecutive series, sharing paths), a server (producer) does not have to maintain any client or connection state -- one factor for making servers more scalable.

ICN forwarders can aggregate INTEREST received from different (for example, downstream) links for the same Named Data Object. Instead of forwarding the second, third etc. INTEREST for the same object, a forwarder (as part of its forwarding strategy) could decide to just record those INTERESTS (and note the interfaces they have been received from) and then later distribute the received object via all of these interfaces.

For live or near-live media distribution, this can enable an additional factor for scalability: 1) less INTERESTs are hitting the producers and 2) less INTEREST and DATA messages are transmitted over the network. Effectively, this behavior implement an implicit multicast-like tree-based distribution -- without any explicit signaling and (inter-domain) multicast routing.

Finally in-network caching can further reduce upstream traffic, i.e., by answering requests for currently popular objects from a forwarder cache.

The corresponding gains have been demonstrated in Proof-of-Concept implementations, for example in Cisco's hICN DASH-like video distribution system.

Multi-Access & Multi-Path Networking

Multi-Access networking is getting increasingly important as most mobile devices already provide at least two radio interfaces that can be used simultaneously. For example Apple's Siri can use Multipath TCP for trying to obtain better performance by combining mobile network and WLAN interfaces and by jointly managing the available resources.

ICN communication is inherently multipath in a sense that ICN is not connection-based and that any forwarder can make independent forwarding decisions for multipath INTEREST forwarding. ICN's location independence also enables a multidestination communication style: Named Data Object can be replicated in the network, so that the network could not only provide different paths to one producer but to many producers, which can increase network utilization and performance further.

These properties in conjunction with ICN's stateful forwarding model enables several optimizations (both for window- as well as rate-based congestion controlled multipath communication) of MPTCP's end-to-end control loop. An example of such an approach has been described by Mahdian et al..

Internet of Things (IoT)

IoT is a broad field, but often refers to 1) networking constrained devices and 2) communicating in local networks (that are not or should not be connected to the Internet on a permanent basis).

In low-power wireless networks with challenged connectivity, frequent power-saving and potentially node mobility, ICN can typically outperform IP-based technology stacks with respect to implementation simplicity, data availability and performance. The implementation simplicity stems from the ICN model of accessing named data directly, i.e., with integrated security and without the need for any resolution infrastructure and application layer protocols (in some IoT scenarios).

The data availability and performance improvements are caused by the stateful forwarding and opportunistic caching feature that are useful for multi-hop mesh networks with frequent connectivity changes due to sleep cycles and mobility. The stateful forwarding enables ICN to react more flexibly to changes, and in-network caching can keep data available in the network so that it can be retrieved at some time offset, for example when a sleeping wakes up and resumes communication with a next-hop node. Gündoğan et al. have performed an extensive analysis comparing NDN with CoAP and MQTT on large-scale IoT testbeds that demonstrated these benefits.

Computing in the Network

Recent advances in platform virtualization, link layer technologies and data plane programmability have led to a growing set of use cases where computation near users or data consuming applications is needed -- for example for addressing minimal latency requirements for compute intensive interactive applications (networked Augmented Reality, AR), for addressing privacy sensitivity (avoiding raw data copies outside a perimeter by processing data locally), and for speeding up distributed computation by putting computation at convenient places in a network topology.

Most application layer frameworks suffer from being conceived as overlays, i.e., they can enable certain forms of optimization (such as function placement, scaling) -- but do typically require centralized orchestration. Running as an overlay means, connecting compute functions through protocols such as TCP, requiring some form of resolution system that maps application-layer names to IP addresses etc.

Approaches such as Named Function Networking (NFN) and Remote Method Invocation for ICN (RICE) have demonstrated how the ICN approach of accessing named data in the network can be extended to accessing dynamic computation results, maintaining all the ICN security and forwarding/caching properties.

In such systems, computing and networking can be integrated in new ways, for example by allowing compute node to include knowledge about the ICN networks routing information base, currently observed availability and performance data for making offloading and scaling decisions. Consequentially, this enables a promising joint optimization of computing and networking resource that is especially attractive for fine-granular distributed system development.

Also see draft-kutscher-coinrg-dir for a general discussion of Computing in the Network.

The CCNx Specifications

The work on CCN started about 11 years ago in project led by Van Jacobson at PARC -- in parallel with many other research projects on ICN such as NetInf, PURSUIT etc. The CCN work split up into branches later: NDN (maintained by the NDN NSN projects) and CCNx (maintained by PARC).

In 2016, Cisco acquired the CCNx technology and the software implementations from PARC and continued working on them in research and proof-of-concepts, and trials. The software has been made available as a sub-project in the fd.io project and is now called CICN, featuring support for the VPP framework in fd.io.

This implementation largely follows the specification in the now published CCNx RFCs which are products of the IRTF ICN Research Group.

RFC 8569 describes the core concepts of the Content-Centric Networking (CCNx) architecture and presents a network protocol based on two messages: Interests and Content Objects. It specifies the set of mandatory and optional fields within those messages and describes their behavior and interpretation. This architecture and protocol specification is independent of a specific wire encoding.

RFC 8609 specifies the encoding of CCNx messages in a TLV packet format, including the TLV types used by each message element and the encoding of each value. The semantics of CCNx messages follow the encoding-independent CCNx Semantics specification.

Both of these RFCs have been authored by Marc Mosko, Nacho Solis, and Chris Wood.

More Information

The IRTF ICN Research Group is an international research forum that covers research and experimentation work across the different ICN approaches and projects. Its goal is to promote experimentation and validation activities with ICN technology.

There is also a yearly academic conference under the ACM SIGCOMM
umbrella. The 2019 ICN conference takes place from September 24 to 26 in HongKong. Previous editions of the conference:

• ACM ICN 2014
• ACM ICN 2015
• ACM ICN 2016
• ACM ICN 2017
• ACM ICN 2018

We (ICNRG) published RFC 7927 on Information-Centric Networking (ICN) Research Challenges.

This memo describes research challenges for Information-Centric Networking (ICN), an approach to evolve the Internet infrastructure to directly support information distribution by introducing uniquely named data as a core Internet principle. Data becomes independent from location, application, storage, and means of transportation, enabling or enhancing a number of desirable features, such as security, user mobility, multicast, and in-network caching. Mechanisms for realizing these benefits is the subject of ongoing research in the IRTF and elsewhere. This document describes current research challenges in ICN, including naming, security, routing, system scalability, mobility management, wireless networking, transport services, in-network caching, and network management.

Information-Centric Networking (ICN) is an approach to evolve the Internet infrastructure to directly support accessing Named Data Objects (NDOs) as a first-order network service. Data objects become independent of location, application, storage, and means of transportation, allowing for inexpensive and ubiquitous in-network caching and replication. The expected benefits are improved efficiency and security, better scalability with respect to information/bandwidth demand, and better robustness in challenging communication scenarios.

ICN concepts can be deployed by retooling the protocol stack: name-based data access can be implemented on top of the existing IP infrastructure, e.g., by allowing for named data structures,
ubiquitous caching, and corresponding transport services, or it can be seen as a packet-level internetworking technology that would cause fundamental changes to Internet routing and forwarding. In summary, ICN can evolve the Internet architecture towards a network model based on named data with different properties and different services.

This document presents the ICN research challenges that need to be addressed in order to achieve these goals. These research challenges are seen from a technical perspective, although business relationships between Internet players will also influence developments in this area. We leave business challenges for a separate document, however. The objective of this memo is to document the technical challenges and corresponding current approaches and to expose requirements that should be addressed by future research work.

Continue reading...