RFC 9273

Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges

📅 published August 2022, from ietf

RFC 9273 💜 Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges

Authors: K. Matsuzono, H. Asaeda (both at NICT), and C. Westphal (at Huawei) 🎀

Category: Informational 🌸 (this is an IRTF document, ISSN 2070-1721)

Date: August 2022 📅

It doesn't list anything it obsoletes or updates, so nothing is being replaced or patched here ✨

Abstract

okay so this doc is all about the current research on Network Coding (NC) for Content-Centric Networking (CCNx) / Named Data Networking (NDN) 🦋 It breaks down the technical considerations and the potential challenges of using NC with CCNx/NDN, and it's a product of the Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG) 💅

Status of This Memo

Real talk first: this is not an Internet Standards Track specification. It's published just for info 📚

This doc comes from the Internet Research Task Force (IRTF), which shares the results of Internet-related research and development. Those results might not be ready for deployment, so keep that in mind 🫶 It represents the consensus of the Coding for Efficient Network Communications Research Group of the IRTF. Documents approved for publication by the IRSG are not candidates for any level of Internet Standard, see Section 2 of RFC 7841 💀

If you want the current status, any errata, or a way to send feedback, check https://www.rfc-editor.org/info/rfc9273 ✨

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the date of publication. Please read them carefully, because they spell out your rights and restrictions for this doc 🙈

Table of Contents

   1.  Introduction
   2.  Terminology
     2.1.  Definitions Related to NC
     2.2.  Definitions Related to CCNx/NDN
   3.  CCNx/NDN Basics
   4.  NC Basics
   5.  Advantages of NC and CCNx/NDN
   6.  Technical Considerations
     6.1.  Content Naming
       6.1.1.  Unique Naming for NC Packets
       6.1.2.  Nonunique Naming for NC Packets
     6.2.  Transport
       6.2.1.  Scope of NC
       6.2.2.  Consumer Operation
       6.2.3.  Forwarder Operation
       6.2.4.  Producer Operation
       6.2.5.  Backward Compatibility
     6.3.  In-Network Caching
     6.4.  Seamless Consumer Mobility
   7.  Challenges
     7.1.  Adoption of Convolutional Coding
     7.2.  Rate and Congestion Control
     7.3.  Security
     7.4.  Routing Scalability
   8.  IANA Considerations
   9.  Security Considerations
   10. Informative References
   Acknowledgments
   Authors' Addresses

1. Introduction ✨

okay so Information-Centric Networking (ICN) is the big picture, and Content-Centric Networking (CCNx) [1] and Named Data Networking (NDN) [2] are its main vibes 🌸 The whole idea is that you retrieve data by its name instead of by where it lives. This pushes content awareness down into the network layer, which is giving efficient access to the stuff you want, no matter which heterogeneous networks you're connected through 🦋 The CCNx/NDN architecture brought in some seriously innovative ideas and has inspired research into a bunch of areas, like in-network caching, name-based routing, multipath transport, and content security 👑 One huge perk of asking for content by name is that you don't need to set up a session with one specific server, so the content can be pulled from multiple sources at once 💖

Meanwhile, academia and industry have been super into understanding the basics of Network Coding (NC) 🔥 The goal is to boost things like data throughput and robustness, cut down on the number of transmissions needed across connected networks, and reduce redundant transmissions on broadcast or point-to-multipoint connections 📈 NC is a technique that's usually used to encode packets so the receiver can recover lost source packets, and it gets the info across in a fully distributed way 🧚 NC can also be handled with a practical security scheme that deals with pollution attacks [3]. It can stop eavesdroppers from getting anything meaningful [4], and it can protect a wireless video stream while keeping the NC benefits [5] [6] 🔒

From the transport side, NC splits into two big categories: coherent NC and noncoherent NC [7] [8] 🎀 With coherent NC, the source and destination both know the exact network topology and the coding operations available at intermediate nodes 🗺️ When lots of consumers want the same content, like live video streaming, coherent NC can hit optimal throughput by sending the flow over constructed optimal multicast trees [9] ✨ The catch is that it needs a fully adjustable and specific routing mechanism plus a large computational capacity for central coordination, which is a lot 💀 Noncoherent NC often uses Random Linear Coding (RLC), and here nobody needs to know the network topology or the intermediate coding operations [10] 🫶 It works in a completely independent, decentralized way, so it's way more feasible when you want to skip that central coordination 🌈

NC mixes multiple packets together with pieces of the same content, and it can do that at the source, at other nodes in the network, or both 🍓 Network coded packets aren't tied to one specific server, since they might have been combined inside the network 🦋 NC cares about what info gets encoded into a packet rather than which host made it, so it fits the CCNx/NDN core networking layer perfectly 💅 NC lets you recover missing packets by encoding the info across several packets 🙌 ICN and NC are literally synergistic, because ICN lets data packets get cached all over the network 🌸 In a typical NC network, the sender has to transmit enough packets to get the original data back, but ICN lets you grab network-coded packets straight from caches in the network, and that's why the combo is so effective 🔥 NC has already been implemented for information and content dissemination [11] [12] [13] 💜 Montpetit et al. were the first to suggest using NC techniques to boost key aspects of system performance in ICN [14] 👑 CCNx/NDN can totally slay at exploiting the benefits of NC (see Section 5), but some technical considerations are needed to combine NC and CCNx/NDN because of CCNx/NDN's unique features (see Section 6) 🎀

In this doc, we look at how NC can be applied to the CCNx/NDN architecture, and we lay out the technical considerations and potential challenges for making CCNx/NDN-based communications better with NC technology ✨ Quick heads up: presenting specific solutions (for example, NC optimization methods) for boosting CCNx/NDN performance metrics with NC is outside the scope of this document 🙈

This doc is the collaborative work and consensus of the Coding for Efficient Network Communications Research Group (NWCRG) and the Information-Centric Networking Research Group (ICNRG) 🫶 It was read and reviewed by all the active research group members. Just so you know, it's not an IETF product and it's not a standard 💖

2. Terminology

okay so this section is where we get the NC vocab straight 🎀 these terms are defined in RFC 8406 [15] and were produced by the NWCRG, so go there if you want the full tea 🍵

Source Packet: a packet coming from the source that contributes to one or more source symbols. A source symbol is a unit of data from the source that gets used as input to encoding operations. For instance, a Real-time Transport Protocol (RTP) packet as a whole can be a source symbol 🦋 but in other situations (e.g., to handle variable size packets), a single RTP packet might contribute to various source symbols. it's giving flexibility 💅

Repair Packet: a packet containing one or more coded symbols (also called repair symbols). A coded symbol, or repair symbol, is a unit of data that comes out of a coding operation, applied either to source symbols or (in the case of recoding) to source and/or coded symbols. When there's a single repair symbol per repair packet, a repair symbol corresponds to a repair packet ✨

Encoding versus Recoding versus Decoding: okay this one is a whole trio 🧚 encoding takes source symbols as input and produces encoding symbols (source or coded symbols) as output. Recoding takes encoding symbols as input and produces encoding symbols as output. Decoding takes encoding symbols as input and produces source symbols as output. three ops, three vibes 💜

The terms regarding coding types are defined as follows:

Random Linear Coding (RLC): a particular form of linear coding that uses a set of random coding coefficients. Linear coding does a linear combination of a set of input symbols (i.e., source and/or coded symbols) using a given set of coefficients, and the result is a repair symbol 🌈

Block Coding: a coding technique where the input flow(s) must first be segmented into a sequence of blocks. Encoding and decoding are performed independently on a per-block basis 🧩

Sliding Window Coding or Convolutional Coding: a general class of coding techniques that rely on a sliding encoding window. An encoding window is a set of source (and, in the case of recoding, coded) symbols used as input to the coding operations. The set of symbols changes over time as the encoding window slides over the input flow(s). This is an alternative solution to block coding 🌸

Fixed or Elastic Sliding Window Coding: a coding technique that generates coded symbol(s) on the fly, from the set of source symbols present in the sliding encoding window at that time, usually by using linear coding. The sliding window may be either of fixed size or of variable size over time (also known as "Elastic Sliding Window"). For instance, the size may depend on acknowledgments sent by the receiver(s) for a particular source symbol or source packet (received, decoded, or decodable). the size literally adapts, iconic 👑

The terms regarding low-level coding aspects are defined as follows:

Rank of the Linear System or Degrees of Freedom: at a receiver, the number of linearly independent equations of the linear system. It is also known as "Degrees of Freedom". The system may be of "full rank", where decoding is possible, or "partial rank", where only partial decoding is possible 🎯

Generation or Block: with block codes, the set of source symbols of the input flow(s) that are logically grouped into a block before encoding is done 🫶

Generation Size or Block Size: with block codes, the number of source symbols belonging to a block. It is equivalent to the number of source packets when there is a single source symbol per source packet 🍓

Coding Coefficient: with linear coding, this is a coefficient in a certain finite field. This coefficient may be chosen in different ways: for instance, randomly, from a predefined table, or using a predefined algorithm plus a seed 🎲

Coding Vector: a set of coding coefficients used to generate a certain coded symbol through linear coding ✨

Finite Field: finite fields, used in linear codes, have the desired property of having all elements (except zero) invertible for + and *, and no operation over any elements can result in an overflow or underflow. Examples of finite fields are prime fields {0..p^(m-1)}, where p is prime. Most used fields use p=2 and are called binary extension fields {0..2^(m-1)}, where m often equals 1, 4, or 8 for practical reasons. math bestie, you're doing amazing 🧮💅

the terminology for CCNx/NDN used in this document is defined in RFC 8793 [16], which was produced by the ICNRG. They are consistent with the relevant documents ([17] [18]). so it's all aligned, no drama 🤝

3. CCNx/NDN Basics 🌈

okay let's quickly run through the key CCNx/NDN concepts 💖 in a CCNx/NDN network there are two types of packets at the network level: interest and data packets (defined in Section 3.4 of [16]). The term "content object", meaning a unit of content data, is an alias for data packet [16]. The ICN consumer (defined in Section 3.2 of [16]) requests a content object by sending an interest that carries the name of the data.

once an ICN forwarder (defined in Section 3.2 of [16]) receives an interest, it runs a series of lookups 👀 First, it checks whether it has a copy of the requested content object in the cache storage, called Content Store (CS) (defined in Section 3.3 of [16]). If it does, it returns the data, and the transaction is considered successfully completed 🎉

If it does not have a copy of the requested content object in the CS, it does a lookup of the Pending Interest Table (PIT) (defined in Section 3.3 of [16]) to check whether there is already an outgoing interest for the same content object. If there is no such interest, it creates an entry in the PIT that lists the name included in the interest and the interfaces it was received from. This is later used to send the content object back, since interest packets do not carry a source field that identifies the consumer. If there is already a PIT entry for this name, it gets updated with the incoming interface of this new interest, and the interest is discarded 🙈

After the PIT lookup, the interest goes through a Forwarding Information Base (FIB) (defined in Section 3.3 of [16]) lookup to select an outgoing interface. The FIB lists name prefixes and their corresponding forwarding interfaces, so the interest can be sent toward a forwarder that has a copy of the requested data 🧭

Once a copy of the data is retrieved, it is sent back to the consumer(s) using the trail of PIT entries. Forwarders remove the PIT state every time an interest is satisfied, and they may store the data in their CS 🗂️

Data packets carry some information for verifying data integrity and origin authentication, and in particular, that the data really is the data that corresponds to the name [19]. This is necessary because authentication of the object is crucial in CCNx/NDN. However, this step is optional at forwarders in order to speed up processing ⚡

the key aspect of CCNx/NDN is that the consumer of the content does not establish a session with a specific server. The forwarder or producer (defined in Section 3.2 of [16]) that returns the content object is not aware of the network location of the consumer, and the consumer is not aware of the network location of the node that provides the content. In theory, this allows the interests to follow different paths within a network, or even to be sent over completely different networks 🌍✨

4. NC Basics 💜

okay so while a forwarding node in conventional IP networks simply relays received data packets, NC lets the node combine some data packets it has already received into one or several output packets to be sent 🔥 In this section we just describe the basic operations of NC. Here we focus on RLC in a block coding manner, which is well known as a major coding technique.

for simplicity, let's look at an example of end-to-end coding, where a producer and a consumer respectively perform encoding and decoding for a content object. This end-to-end coding is regarded as a special case of NC. The producer splits the content into several blocks called generations. Encoding and decoding are performed independently on a per-block (per-generation) basis. Let's assume each generation consists of K original source packets of the same size. When the packets don't have the same size, zero padding is added. To generate one repair packet within a certain generation, the producer linearly combines K of the original source packets, where additions and multiplications are performed using a coding vector consisting of K coding coefficients that are randomly selected in a certain finite field. The producer may respond to interests by sending the corresponding source packets and repair packets in the content flow (called systematic coding), where the repair packets are typically used for recovering lost source packets 🩹

Repair packets can also be used for performing encoding. If the forwarding nodes know each coding vector and generation identifier (hereinafter referred to as generation ID) of the received repair packets, they may perform an encoding operation (called recoding), which is the most distinctive feature of NC compared to other coding techniques. main character energy 👑

At the consumer, decoding is performed by solving a set of linear equations represented by the coding vectors of the received source and repair packets (possibly only repair packets) within a certain generation. To obtain all the source packets, the consumer requires K linearly independent equations. In other words, the consumer must receive at least K linearly independent data packets (called innovative packets). Since receiving a linearly dependent data packet isn't useful for decoding, recoding should generate and provide innovative packets 💅 One of the major benefits of RLC is that, even for a small-sized finite field (e.g., q=2^8), the probability of generating linearly dependent packets is negligible [9] 🌸

5. Advantages of NC and CCNx/NDN ✨

okay so combining NC and CCNx/NDN is giving large-scale content dissemination 💖. They each bring similar perks, like throughput/capacity gain and robustness enhancement 💅. The difference is how they think about stuff: NC treats the content flow as algebraic information that gets combined [7], while CCNx/NDN zooms in on the content/information itself at the networking layer 🧚. These two are complementary and would be advantageous together, so teaming up is honestly so natural 🫶.

Name-based communication in CCNx/NDN lets consumers grab the content objects they asked for without setting up and maintaining end-to-end communication channels between nodes 🦋. This is iconic because it makes the in-network cache and multipath/multisource retrieval easier to use, and it supports consumer mobility without updating the location information/identifier during handover [1] 😭. Name-based communication also basically has multicast built in, since identical interests get aggregated at the forwarders 🌈.

NC can help the CCNx/NDN transport system distribute and cache the data tied to multipath data retrieval [14] 🌸. Pairing multipath retrieval and in-network caching with NC doesn't just boost the cache hit rate, it also expands the anonymity set of each consumer (the set of potential routers that can serve a given consumer) [20] 👑. That expansion makes it harder for adversaries to infer what content others are consuming, which helps improve cache privacy 🙈. Others have explored NC in CCNx/NDN too, like content dissemination with in-network caching [21] [22] [23], seamless consumer mobility [24] [25], and low-latency low-loss video streaming [26] 🎀. So yeah, it's well worth considering NC integration in CCNx/NDN 💜.

6. Technical Considerations

This section looks at CCNx/NDN with NC from the network architecture and protocol side 🧠. Quick note: this document focuses on NC when it's used in a block coding manner 🍓.

6.1. Content Naming

Naming content objects matters just as much for CCNx/NDN as naming hosts does on today's Internet [19] 💅. This section presents two possible naming schemes ✨.

6.1.1. Unique Naming for NC Packets

Each source and repair packet (called an NC packet from here on) may have a unique name, just like each original content object does in CCNx/NDN. PIT and CS operations typically need a unique name to identify the NC packet 🔥. For a naming method that takes block coding into account, the coding vector and the generation ID can be used as part of the content object name. As in [21], when the generation ID is "g-id", the generation size is 4, and the coding vector is (1,0,0,0), the name could be /CCNx.com/video-A/g-id/1000 🦋. Other identifiers and/or encoding-related parameters can also be name components. For example, the encoding ID specifying the coding scheme may be used with "enc-id", such as /CCNx.com/video-A/enc-id/g-id/1000, as defined in the FEC Framework (FECFRAME) [27] 🧚. This naming scheme is simple and can support NC packet delivery with exactly the same PIT/CS operations used for content objects 💖.

If you use a naming scheme like the one above, an interest requesting an NC packet may have the full name, including a generation ID and coding vector (/CCNx.com/video-A/g-id/1000), or only the name prefix with just a generation ID (/CCNx.com/video-A/g-id) 🌈. With the full name, exact name matching to the PIT is simply done at data forwarders (as in CCNx/NDN) 💅. The consumer can specify and retrieve an innovative packet it needs to decode successfully 👑. This could shift the generation of the coding vector from the data forwarder onto the consumer 🫶.

With only the prefix, partial name matching is required at the data forwarders 🙈. Since an interest with only the prefix matches any NC packet with that prefix, the consumer could immediately grab an NC packet from a nearby CS (in-network cache) without knowing the coding vectors of the cached NC packets in advance 😭. If NC packets in transit are modified by in-network recoding at forwarders, the consumer could also receive those modified NC packets 🦋. However, unlike the full-name case, the consumer may fail to obtain sufficient degrees of freedom (see Section 6.2.3) 💀. To address this, a new TLV type in an interest message may be required for specifying further coding information, so the NC packets to be received are limited ✨. For instance, this is enabled by specifying the coding vectors of innovative packets for the consumer (also called decoding matrix), as in [14] 🍓. This extension may make an interest packet significantly bigger, so it may be useful to use compression techniques for coding vectors [28] [29] 🌸. Without that coding information in the interest, the forwarder would be required to keep some records about the interest packets it satisfied previously (see Section 6.2.3) 🧠.

6.1.2. Nonunique Naming for NC Packets

An NC packet may have a name that says it's an NC packet (the name includes the data type, source, or repair packet), while the coding information moves into a metadata field in the payload 🎀. Honestly, this isn't super helpful for apps or services that don't need to peek inside the payload 🙈. Since multiple NC packets might share the same name, some mechanism is required for the consumer to obtain innovative packets 💅. As described in Section 6.3, a mechanism for managing the multiple innovative packets in the CS would also be required 🔥. Plus, extra computational overhead gets added when the payload is encrypted 😭.

6.2. Transport

CCNx/NDN's pull-based request-response feature is a fundamental principle of its transport layer 👑. One interest retrieves, at most, one data packet 🧚. So a forwarder or producer cannot inject unrequested data packets on its own initiative. This rule is important, and it really should not be violated, because 1) it would open denial-of-service (DoS) attacks, 2) it invalidates existing congestion control approaches that follow this rule, and 3) it would reduce the efficiency of existing consumer mobility approaches 😭. So the following basic operation should be considered for applying NC to CCNx/NDN. Still, such security considerations must be addressed if this rule were to be violated.

⚠️ Security alert, bestie: if anyone breaks the "no unrequested data" rule, the security considerations have to be handled, and they are a whole big deal 💀.

6.2.1. Scope of NC

Here's the open question: can a data forwarder do in-network recoding on data packets that arrive in transit, or can only the data that matches an interest be subject to NC operations? In the latter case, encoding or recoding is performed to generate the NC packet at any forwarder that is able to respond to the interest 🧩. This could happen when each NC packet has a unique name and the interest has the full name. On the other hand, if the interest has a partial name without any coding vector information, or multiple NC packets have the same name, the former case may occur. That means recoding can happen anywhere in the network where the received NC packet can be modified and forwarded 🌊. CCNx/NDN has mechanisms for ensuring data integrity during transfer, so in-network recoding adds complexities that need consideration for those integrity mechanisms to still work 🔐. Similarly, in-network caching of NC packets at forwarders may be valuable, but the forwarders would require some mechanisms to validate the NC packets (see Section 9) ✨.

6.2.2. Consumer Operation

To get NC benefits (possibly along with in-network caching), the consumer is required to issue interests that direct the forwarder (or producer) to respond with innovative packets if they're available 🌟. When each NC packet may have a unique name (as described in Section 6.1), the consumer can issue an interest that specifies a unique name with g-id and the coding vector for an NC packet. That way, the consumer could appropriately receive an innovative packet if one is available at some forwarders 💖.

To specify the exact name of the NC packet to retrieve, the consumer is required to know the valid naming scheme 🧠. From a practical viewpoint, it's desirable for the consumer application to automatically construct the right name components without depending on any application specifics 🫶. To do this, the consumer application may retrieve and refer to a manifest [17] that enumerates the content objects, including NC packets. Or it may use a coding scheme specifier as a name component to construct the name components of interests requesting innovative packets 💅.

Conversely, a consumer without decoding capability (e.g., a specific sensor node) may want to receive only the source packets 🌸. As described in Section 6.1, the NC packet can have a name that is explicitly different from source packets, so issuing interests for retrieving source packets is possible ✨.

6.2.3. Forwarder Operation 🦋

okay so picture this, bestie 🫶. If the forwarder keeps answering incoming interests with non-innovative packets, the consumers literally can't decode and get the source packets 😭. This can happen when 1) the incoming interests for NC packets don't say which coding parameters to use, like the coding vectors, and 2) the forwarder doesn't have enough linearly independent NC packets (maybe sitting in the CS) to recode with. In that situation, the forwarder is required to figure out whether it can generate innovative packets to send out the interfaces where the interests came in. 💅

One way to handle this is for the forwarder to keep a tally of interests for a specific name, generation ID, and the incoming interface(s), so it knows how many degrees of freedom it has already handed out [21]. Ngl, this scheme needs state management in forwarders (and maybe timers too), so scalability and practicality have to be considered 🥺. Also, some transport mechanism for in-network loss detection and recovery at a forwarder [25][26], plus a consumer-driven mechanism, could be indispensable for fast loss recovery and for actually getting those NC gains 🔥.

If a forwarder can't either return a matching innovative packet from its local content store or produce a recoded packet that's innovative on the fly, it's important that it does not just send back a non-innovative packet. Instead, it should do a forwarding lookup in its FIB and forward the interest toward the producer or an upstream forwarder that can provide an innovative packet 🧚. To get an innovative packet quickly and effectively, a good FIB setting and efficient interest-forwarding strategies should be considered too ✨.

Another possible case is when the forwarder only receives interests for source packets. Then it may try to decode and collect all the source packets and store them (if the full cache capacity is available), which means it can respond faster to later interests 🌈. Recoding and decoding add extra computational overhead, though, so the forwarder is required to decide how to respond to received interests based on the use case (for example, a delay-sensitive or delay-tolerant application) and its own situation, like available cache space and computational capability 💜.

6.2.4. Producer Operation 🎀

Before doing NC for some content in CCNx/NDN, the producer is responsible for splitting the whole thing into small content objects. That's so packets don't get fragmented, which would cause unnecessary packet processing and a drop in throughput 😤. The size of those content objects should fit within the allowable packet size, so the CCNx/NDN network doesn't have to fragment anything 🌸. Then the producer does the encoding for that set of small content objects and handles the naming for the NC packets 💖.

If the producer is the one deciding which coding vectors to use when it generates the NC packets, there are three general strategies for naming and producing them 👑:

  1. Consumers understand the naming conventions for NC packets in detail, so they can send interests toward the producer to get NC packets whose coding parameters were already picked by the producer.
  2. The producer picks the coding vectors and generates the NC packets only after it gets interests specifying which packets the consumer wants.
  3. The naming scheme for choosing coding vectors and their matching NC packets is spelled out in a "Manifest" (for example, FLIC [30]). The consumer can grab that manifest, use it to choose among the available coding vectors and packets, and then send the right interests 🦋.

Okay, so with the first case, consumers can't flexibly pick a coding vector, but the latency to get the NC packet is lower than in the other two cases ⭐. The second case has a latency penalty because of the extra NC operations that happen after the interests arrive 🙈. With the third case, the NC packets that go into the manifest have to be pre-computed by the producer (since the manifest refers to NC packets by their hashes, not their names). But the producer can pick which ones to include and make multiple manifests, either ahead of time or on demand, with different coding tradeoffs if that's what it wants 💅.

A shared benefit of the first two approaches to end-to-end coding is that if the producer adds a signature on the NC packets, data validation is possible throughout the network, same as CCNx/NDN without NC 🔥. The third approach trades off the extra latency of fetching the manifest against the efficiency of only needing a signature on the manifest and not on every single NC packet 🫶.

6.2.5. Backward Compatibility 🌈

NC operations should be applied in addition to the regular ICN behavior, and they should work alongside regular ICN operations ✨. So nodes that don't support NC should still be able to handle packets properly. That means they can forward the NC packets and also cache them 💜. An NC framework should be compatible with a regular framework, so backward compatibility and a smooth migration from one to the other are possible 🧚.

6.3. In-Network Caching 🍓

Caching is a super useful technique for improving throughput and latency in all kinds of applications 💖. In-network caching in CCNx/NDN gives support at the network level, and it's highly beneficial because it lets NC be used for effective multicast transmission [31], multipath data retrieval [21][24], and fast loss recovery [26]. Still, there are a few issues to think about 😭.

The CS capacity is limited, and the caching policy affects the consumer's performance [32][33][34]. So it's crucial for forwarders to decide which content objects get cached and which get discarded 🎀. Delay-sensitive applications often don't need an in-network cache for very long because of their real-time constraints, so forwarders have to know whether caching a received content object is actually necessary, to save caching volume 🥺. In CCNx, the producer can set a Recommended Cache Time (RCT) in the optional header of the data packet, and that's how this works 🌸. The RCT is a guideline for the CS on how long to keep the content object 💅. When the RCT is zero, the forwarder knows caching that content object isn't useful. If the RCT is a greater value, the forwarder may cache it ✨. In NDN, the TLV type of FreshnessPeriod could be used for this 🦋.

One key aspect of in-network caching is whether forwarders can cache NC packets in their CS. They might be caching NC packets without being able to validate the content objects, and that's a problem 🙈. So caching NC packets would need some mechanism to validate them (see Section 9) 🔥. If NC packets have the same name, caching them would also need some mechanism to tell them apart 👑.

6.4. Seamless Consumer Mobility 🧚

A key feature of CCNx/NDN is that it's sessionless. That lets the consumer and forwarder send multiple interests toward different copies of the content in parallel, using multiple interfaces at the same time, in an asynchronous way 💫. Through multipath data retrieval, the consumer can get content from multiple distributed copies and use the aggregate capacity of multiple interfaces 🌈. For the link between the consumer and those copies, the consumer can run a rate adaptation mechanism for video streaming [24] or congestion control for content acquisition [35] 💜.

NC adds a reliability layer to CCNx in a distributed and asynchronous manner 🫶. That's because NC makes sure the interests sent to multiple copies in parallel retrieve innovative packets, even when some of the paths or networks to those copies lose packets 🔥. This applies to consumer mobility events [24]. During a mobility event, the consumer can receive additional degrees of freedom with any innovative packet, as long as at least one interface is available 🦋. To achieve seamless consumer mobility, an interest-forwarding strategy at the consumer (and possibly at the forwarder) is required for efficiently obtaining innovative packets 💅.

7. Challenges 🌸

This section covers several primary challenges and research items to think about when applying NC in CCNx/NDN 👑.

7.1. Adoption of Convolutional Coding ✨

Several block coding approaches have been proposed so far, but there still isn't enough discussion and application of convolutional coding (for example, sliding or elastic window coding) in CCNx/NDN 🥺. Convolutional coding is often a good fit when fully or partially reliable delivery of continuous data flows is required, especially when those flows have real-time constraints 💖. As in [36], on an end-to-end coding basis, it would be advantageous for continuous content flows to adopt sliding window coding in CCNx/NDN 🌈. In this case, the producer is required to set the coding parameters appropriately and let the consumer know them, and the consumer is required to send interests augmented with feedback about data reception and/or decoding status 🧚. CCNx/NDN uses hop-by-hop forwarding state, so it's worth discussing and investigating how convolutional coding can be applied in a hop-by-hop manner and what benefits might come from that 🍓. In particular, when in-network recoding could happen at forwarders, both the encoding window and CS management would be required, and their feasibility and practicality should be considered 🔥.

7.2. Rate and Congestion Control 💜

Adding redundancy with repair packets may result in further network congestion and could hurt overall throughput 😭. Where fair bandwidth sharing is more desirable, each streaming flow must adapt to network conditions so it fairly consumes the available link bandwidth 🫶. So it's necessary for each content flow to cooperatively implement congestion control to adjust its consumed bandwidth [37] ✨. From this angle, an effective deployment approach is required, such as a forwarder-supported approach that can still provide benefits under partial deployment 💅.

As described in Section 6.4, NC can contribute to seamless consumer mobility by obtaining innovative packets without receiving duplicated packets through multipath data retrieval 🦋. Avoiding duplicated packets has congestion control benefits too 🌸. It can be challenging to develop an effective rate and congestion control mechanism that achieves seamless consumer mobility while improving overall throughput or latency by fully exploiting NC operations 🙈.

7.3. Security 🔐

Okay so CCNx/NDN brings its own brand-new security drama at the networking layer, totally different from IP 💀 Think cache poisoning, pollution attacks, and DoS attacks using interest packets. Some security approaches already exist for this stuff though [19] [38]. Adding NC into CCNx/NDN creates two potential security aspects we have to handle, periodt 💅

The first one is in-network recoding at forwarders 🦋 Some mechanism for checking the integrity of the NC packets that get freshly produced by in-network recoding is required, so that consumers or other forwarders can receive valid NC packets. There are some possible approaches in Section 9, but there may be a more effective method with lower complexity and computation overhead ✨

The second one is that attackers maliciously request and inject NC packets, which could amplify some attacks 😭 NC packets aren't popular in general use, so they could be targeted by a cache pollution attack. That attack requests less popular content objects more often, which skews the content popularity and undermines popularity-based caching 🙈 This needs to be dealt with so the in-network cache efficiency stays strong 🍓 If an attacker injects invalid NC packets to fill the CSs at the forwarders, the cache poisoning attack could be effectual, depending on the exact integrity coverage on NC packets.

On the assumption that each NC packet has a valid signature, the straightforward approach would be for forwarders to verify the signature within the NC packets in transit, and then only transmit and store the validated ones. Here's the catch: signature verification by forwarders may be infeasible at line speed. So some mechanisms should be considered for distributing and reducing the load of signature verification, which keeps the in-network cache benefits like latency and network-load reduction alive 🌈

7.4. Routing Scalability 🧚

In CCNx/NDN, a name-based routing protocol without a resolution process streamlines the routing process and reduces overall latency ✨ In IP routing, the growth in routing table size has become a concern. That's why it's necessary to use a hierarchical naming scheme, which improves routing scalability by letting routing information be aggregated 👑

To realize the benefits of NC, consumers need to efficiently obtain innovative packets using the multipath retrieval mechanisms of CCNx/NDN. This would require an efficient routing mechanism to appropriately set the FIB, plus an efficient interest-forwarding strategy. Honestly, that routing coordination may create routing scalability issues 💀 It would be challenging to achieve effective and scalable routing for interests requesting NC packets, and also to simplify the routing process.

8. IANA Considerations 🎀

No IANA actions in this document, bestie. Nothing to register here 🫶

9. Security Considerations 🔥

Okay, this is the big one. In-network recoding is a distinguishing feature of NC, so only valid NC packets produced by in-network recoding must be requested and utilized (and possibly stored) 🚨 There are some possible approaches for this, and they're all kind of iconic.

First, there's signature verification. The exploitation of multi-signature capability could be applied here. This lets not only the original content producer but also some forwarders responsible for in-network recoding have their own unique signing key 🔑 Each forwarder in the group signs a newly generated NC packet, so other nodes can validate the data with the signature. The CS may verify the signature within the NC packet before storing it, which helps avoid invalid data caching ✨

Second, there's the consumer-dependent approach. The consumer puts a restriction on the matching rule using only the name of the requested data. The interest ambiguity can be clarified by specifying both the name and the key identifier (the producer's public key digest) used for matching to the requested data 🦋 This KeyId restriction is built into the CCNx design [17]. Only the requested data packet satisfying the interest with the KeyId restriction would be forwarded and stored in the CS, so the chances of cache poisoning go down 📉 Also, the CCNx design has a rule the CS obeys so it doesn't amplify invalid data: if an interest has a KeyId restriction, the CS must not reply unless it knows that the signature on the matching content object is correct. If the CS can't verify the signature, the interest may be treated as a cache miss and forwarded to the upstream forwarder(s) 🙌

Third, there's certificate chain management, possibly without a certificate authority. Some mechanism, such as [39], could be used to establish a trustworthy data delivery path 🛤️ This approach adopts the hop-by-hop authentication mechanism, where forwarding-integrated hop-by-hop certificate collection is performed to provide suspension certificate chains, so the data retrieval is trustworthy.

Depending on the adopted caching strategy, such as cache replacement policies, forwarders should also take caution when storing and retaining the NC packets in the CS, because they could be targeted by cache pollution attacks 😬 To reduce the impact of cache pollution attacks, forwarders should check the content request frequencies to detect the attack, and they may limit requests by ignoring some of the consecutive requests. Then the forwarders can decide to apply or change to another cache replacement mechanism 🔄

The forwarders or producers need to watch out for DoS attacks aimed at provoking a high load of NC operations by using interests for NC packets 🚨 To mitigate these attacks, the forwarders could adopt a rate-limiting approach. For instance, they could monitor the PIT size growth for NC packets per content to detect attacks, and limit the interest arrival rate when necessary. And if the NC application wants to secure an interest (considered as the NC actuator) to prevent such attacks, the application should consider using an encrypted wrapper and an explicit protocol 🔐

10. Informative References 📚

Here's the full reading list, every single one of them:

[1]        Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
           Briggs, N., and R. Braynard, "Networking Named Content",
           Proc. CoNEXT, ACM, DOI 10.1145/1658939.1658941, December
           2009, <https://doi.org/10.1145/1658939.1658941>.

[2]        Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy,
           K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang,
           "Named data networking", ACM SIGCOMM Computer
           Communication Review, vol. 44, no. 3,
           DOI 10.1145/2656877.2656887, July 2014,
           <https://doi.org/10.1145/2656877.2656887>.

[3]        Gkantsidis, C. and P. Rodriguez, "Cooperative Security for
           Network Coding File Distribution", Proc. Infocom, IEEE,
           DOI 10.1109/INFOCOM.2006.233, April 2006,
           <https://doi.org/10.1109/INFOCOM.2006.233>.

[4]        Cai, N. and R. Yeung, "Secure network coding", Proc.
           International Symposium on Information Theory (ISIT),
           IEEE, DOI 10.1109/ISIT.2002.1023595, June 2002,
           <https://doi.org/10.1109/ISIT.2002.1023595>.

[5]        Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A.
           Toledo, "Secure Network Coding for Multi-Resolution
           Wireless Video Streaming", IEEE Journal of Selected Area
           (JSAC), vol. 28, no. 3, DOI 10.1109/JSAC.2010.100409,
           April 2010, <https://doi.org/10.1109/JSAC.2010.100409>.

[6]        Vilea, J., Lima, L., and J. Barros, "Lightweight security
           for network coding", Proc. ICC, IEEE,
           DOI 10.48550/arXiv.0807.0610, May 2008,
           <https://doi.org/10.48550/arXiv.0807.0610>.

[7]        Koetter, R. and M. Medard, "An Algebraic Approach to
           Network Coding", IEEE/ACM Transactions on Networking, vol.
           11, no. 5, DOI 10.1109/TNET.2003.818197, October 2003,
           <https://doi.org/10.1109/TNET.2003.818197>.

[8]        Vyetrenko, S., Ho, T., Effros, M., Kliewer, J., and E.
           Erez, "Rate regions for coherent and noncoherent
           multisource network error correction", Proc. International
           Symposium on Information Theory (ISIT), IEEE,
           DOI 10.1109/ISIT.2009.5206077, June 2009,
           <https://doi.org/10.1109/ISIT.2009.5206077>.

[9]        Wu, Y., Chou, P., and K. Jain, "A comparison of network
           coding and tree packing", Proc. International Symposium on
           Information Theory (ISIT), IEEE,
           DOI 10.1109/ISIT.2004.1365182, June 2004,
           <https://doi.org/10.1109/ISIT.2004.1365182>.

[10]       Ho, T., Medard, M., Koetter, R., Karger, D., Effros, M.,
           Shi, J., and B. Leong, "A Random Linear Network Coding
           Approach to Multicast", IEEE Trans. on Information Theory,
           vol. 52, no. 10, DOI 10.1109/TIT.2006.881746, October
           2006, <https://doi.org/10.1109/TIT.2006.881746>.

[11]       Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K.
           Ramchandran, "Network Coding for Distributed Storage
           Systems", IEEE Trans. Information Theory, vol. 56, no.9,
           DOI 10.1109/TIT.2010.2054295, September 2010,
           <https://doi.org/10.1109/TIT.2010.2054295>.

[12]       Gkantsidis, C. and P. Rodriguez, "Network coding for large
           scale content distribution", Proc. Infocom, IEEE,
           DOI 10.1109/INFCOM.2005.1498511, March 2005,
           <https://doi.org/10.1109/INFCOM.2005.1498511>.

[13]       Seferoglu, H. and A. Markopoulou, "Opportunistic Network
           Coding for Video Streaming over Wireless", Proc. Packet
           Video Workshop (PV), IEEE,
           DOI 10.1109/PACKET.2007.4397041, November 2007,
           <https://doi.org/10.1109/PACKET.2007.4397041>.

[14]       Montpetit, M., Westphal, C., and D. Trossen, "Network
           Coding Meets Information-Centric Networking: An
           Architectural Case for Information Dispersion Through
           Native Network Coding", Proc. Workshop on Emerging Name-
           Oriented Mobile Networking Design (NoM), ACM,
           DOI 10.1145/2248361.2248370, June 2012,
           <https://doi.org/10.1145/2248361.2248370>.

[15]       Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
           F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
           Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
           S. Sivakumar, "Taxonomy of Coding Techniques for Efficient
           Network Communications", RFC 8406, DOI 10.17487/RFC8406,
           June 2018, <https://www.rfc-editor.org/info/rfc8406>.

[16]       Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
           D., and C. Tschudin, "Information-Centric Networking (ICN):
           Content-Centric Networking (CCNx) and Named Data Networking
           (NDN) Terminology", RFC 8793, DOI 10.17487/RFC8793, June
           2020, <https://www.rfc-editor.org/info/rfc8793>.

[17]       Mosko, M., Solis, I., and C. Wood, "Content-Centric
           Networking (CCNx) Semantics", RFC 8569,
           DOI 10.17487/RFC8569, July 2019,
           <https://www.rfc-editor.org/info/rfc8569>.
  • [18] Mosko, M., Solis, I., and C. Wood, "Content-Centric Networking (CCNx) Messages in TLV Format", RFC 8609, DOI 10.17487/RFC8609, July 2019, <https://www.rfc-editor.org/info/rfc8609>.
  • [19] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I., Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch, "Information-Centric Networking (ICN) Research Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016, <https://www.rfc-editor.org/info/rfc7927>.
  • [20] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. Xie, "Privacy-Aware Multipath Video Caching for Content-Centric Networks", IEEE Journal on Selected Areas in Communications (JSAC), vol. 38, no. 8, DOI 10.1109/JSAC.2016.2577321, June 2016, <https://doi.org/10.1109/JSAC.2016.2577321>.
  • [21] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, "NetCodCCN: a network coding approach for content-centric networks", Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2016.7524382, April 2016, <https://doi.org/10.1109/INFOCOM.2016.7524382>.
  • [22] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. Westphal, "An Optimal Cache Management Framework for Information-Centric Networks with Network Coding", Proc. Networking Conference, IFIP/IEEE, DOI 10.1109/IFIPNetworking.2014.6857127, June 2014, <https://doi.org/10.1109/IFIPNetworking.2014.6857127>.
  • [23] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. Westphal, "A Minimum Cost Cache Management Framework for Information-Centric Networks with Network Coding", Computer Networks, Elsevier, DOI 10.1016/j.comnet.2016.08.004, August 2016, <https://doi.org/10.1016/j.comnet.2016.08.004>.
  • [24] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive Video Streaming over CCN with Network Coding for Seamless Mobility", Proc. International Symposium on Multimedia (ISM), IEEE, DOI 10.1109/ISM.2016.0054, December 2016, <https://doi.org/10.1109/ISM.2016.0054>.
  • [25] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, N., and X. Zeng, "Leveraging ICN In-network Control for Loss Detection and Recovery in Wireless Mobile networks", Proc. of the 3rd ACM Conference on Information-Centric Networking, DOI 10.1145/2984356.2984361, September 2016, <https://doi.org/10.1145/2984356.2984361>.
  • [26] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency Low Loss Streaming using In-Network Coding and Caching", Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2017.8057026, May 2017, <https://doi.org/10.1109/INFOCOM.2017.8057026>.
  • [27] Watson, M., Begen, A., and V. Roca, "Forward Error Correction (FEC) Framework", RFC 6363, DOI 10.17487/RFC6363, October 2011, <https://www.rfc-editor.org/info/rfc6363>.
  • [28] Thomos, N. and P. Frossard, "Toward One Symbol Network Coding Vectors", IEEE Communications Letters, vol. 16, no. 11, DOI 10.1109/LCOMM.2012.092812.121661, November 2012, <https://doi.org/10.1109/LCOMM.2012.092812.121661>.
  • [29] Lucani, D., Pedersen, M., Ruano, D., Sørensen, C., Heide, J., Fitzek, F., and O. Geil, "Fulcrum Network Codes: A Code for Fluid Allocation of Complexity", DOI 10.48550/arXiv.1404.6620, April 2014, <https://doi.org/10.48550/arXiv.1404.6620>.
  • [30] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, "File-Like ICN Collections (FLIC)", Work in Progress, Internet-Draft, draft-irtf-icnrg-flic-03, 7 November 2021, <https://datatracker.ietf.org/doc/html/draft-irtf-icnrg-flic-03>.
  • [31] Maddah-Ali, M. and U. Niesen, "Coding for Caching: Fundamental Limits and Practical Challenges", IEEE Communications Magazine, vol. 54, no. 8, DOI 10.1109/MCOM.2016.7537173, August 2016, <https://doi.org/10.1109/MCOM.2016.7537173>.
  • [32] Perino, D. and M. Varvello, "A reality check for content centric networking", Proc. SIGCOMM Workshop on Information-centric networking (ICN '11), ACM, DOI 10.1145/2018584.2018596, August 2011, <https://doi.org/10.1145/2018584.2018596>.
  • [33] Podlipnig, S. and L. Böszörmenyi, "A Survey of Web Cache Replacement Strategies", Proc. ACM Computing Surveys, vol. 35, no. 4, DOI 10.1145/954339.954341, December 2003, <https://doi.org/10.1145/954339.954341>.
  • [34] Rossini, G. and D. Rossi, "Evaluating CCN multi-path interest forwarding strategies", Elsevier Computer Communications, vol. 36, no. 7, DOI 10.1016/j.comcom.2013.01.008, April 2013, <https://doi.org/10.1016/j.comcom.2013.01.008>.
  • [35] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, "MIRCC: Multipath-aware ICN Rate-based Congestion Control", Proc. Conference on Information-Centric Networking (ICN), ACM, DOI 10.1145/2984356.2984365, September 2016, <https://doi.org/10.1145/2984356.2984365>.
  • [36] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and V. Roca, "On-the-Fly Erasure Coding for Real-Time Video Applications", IEEE Transactions on Multimedia, vol. 13, no. 4, DOI 10.1109/TMM.2011.2126564, August 2011, <https://doi.org/10.1109/TMM.2011.2126564>.
  • [37] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Forward Erasure Correction (FEC) Coding and Congestion Control in Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022, <https://www.rfc-editor.org/info/rfc9265>.
  • [38] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S., and G. Boggia, "Information-Centric Networking: Evaluation and Security Considerations", RFC 7945, DOI 10.17487/RFC7945, September 2016, <https://www.rfc-editor.org/info/rfc7945>.
  • [39] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric Authentication for Secure In-Network Big-Data Retrieval", IEEE Trans. on Network Science and Engineering, vol. 7, no. 1, DOI 10.1109/TNSE.2018.2872049, September 2018, <https://doi.org/10.1109/TNSE.2018.2872049>.

Acknowledgments 🫶

Huge thanks to the ICNRG and NWCRG crew, especially Marie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti, for their super valuable comments and suggestions on this doc. The authors are so grateful 💖✨

Authors' Addresses 💌

Kazuhisa Matsuzono National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Tokyo 184-8795 Japan Email: matsuzono@nict.go.jp

Hitoshi Asaeda National Institute of Information and Communications Technology 4-2-1 Nukui-Kitamachi, Tokyo 184-8795 Japan Email: asaeda@nict.go.jp

Cedric Westphal Huawei 2330 Central Expressway Santa Clara, California 95050 United States of America Email: cedric.westphal@futurewei.com,

📦 where this page comes from