rfc9273.original   rfc9273.txt 
NWCRG and ICNRG K. Matsuzono Internet Research Task Force (IRTF) K. Matsuzono
Internet-Draft H. Asaeda Request for Comments: 9273 H. Asaeda
Intended status: Informational NICT Category: Informational NICT
Expires: August 31, 2022 C. Westphal ISSN: 2070-1721 C. Westphal
Huawei Huawei
February 27, 2022 August 2022
Network Coding for Content-Centric Networking / Named Data Networking: Network Coding for Content-Centric Networking / Named Data Networking:
Considerations and Challenges Considerations and Challenges
draft-irtf-nwcrg-nwc-ccn-reqs-09
Abstract Abstract
This document describes the current research outcomes in Network This document describes the current research outcomes in Network
Coding (NC) for Content-Centric Networking (CCNx) / Named Data Coding (NC) for Content-Centric Networking (CCNx) / Named Data
Networking (NDN), and clarifies the technical considerations and Networking (NDN) and clarifies the technical considerations and
potential challenges for applying NC in CCNx/NDN. This document is potential challenges for applying NC in CCNx/NDN. This document is
the product of the Coding for Efficient Network Communications the product of the Coding for Efficient Network Communications
Research Group (NWCRG) and the Information-Centric Networking Research Group (NWCRG) and the Information-Centric Networking
Research Group (ICNRG). Research Group (ICNRG).
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Research Task Force
and may be updated, replaced, or obsoleted by other documents at any (IRTF). The IRTF publishes the results of Internet-related research
time. It is inappropriate to use Internet-Drafts as reference and development activities. These results might not be suitable for
material or to cite them other than as "work in progress." deployment. This RFC represents the consensus of the Coding for
Efficient Network Communications Research Group of the Internet
Research Task Force (IRTF). Documents approved for publication by
the IRSG are not candidates for any level of Internet Standard; see
Section 2 of RFC 7841.
This Internet-Draft will expire on August 31, 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9273.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document.
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
2.1. Definitions related to NC . . . . . . . . . . . . . . . . 4 2.1. Definitions Related to NC
2.2. Definitions related to CCNx/NDN . . . . . . . . . . . . . 6 2.2. Definitions Related to CCNx/NDN
3. CCNx/NDN Basics . . . . . . . . . . . . . . . . . . . . . . . 6 3. CCNx/NDN Basics
4. NC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. NC Basics
5. Advantages of NC and CCNx/NDN . . . . . . . . . . . . . . . . 8 5. Advantages of NC and CCNx/NDN
6. Technical Considerations . . . . . . . . . . . . . . . . . . 9 6. Technical Considerations
6.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 9 6.1. Content Naming
6.1.1. Unique Naming for NC Packets . . . . . . . . . . . . 9 6.1.1. Unique Naming for NC Packets
6.1.2. Non-Unique Naming for NC Packets . . . . . . . . . . 10 6.1.2. Nonunique Naming for NC Packets
6.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Transport
6.2.1. Scope of NC . . . . . . . . . . . . . . . . . . . . . 11 6.2.1. Scope of NC
6.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 11 6.2.2. Consumer Operation
6.2.3. Forwarder Operation . . . . . . . . . . . . . . . . . 12 6.2.3. Forwarder Operation
6.2.4. Producer Operation . . . . . . . . . . . . . . . . . 13 6.2.4. Producer Operation
6.2.5. Backward Compatibility . . . . . . . . . . . . . . . 14 6.2.5. Backward Compatibility
6.3. In-network Caching . . . . . . . . . . . . . . . . . . . 14 6.3. In-Network Caching
6.4. Seamless Consumer Mobility . . . . . . . . . . . . . . . 15 6.4. Seamless Consumer Mobility
7. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Challenges
7.1. Adoption of Convolutional Coding . . . . . . . . . . . . 15 7.1. Adoption of Convolutional Coding
7.2. Rate and Congestion Control . . . . . . . . . . . . . . . 16 7.2. Rate and Congestion Control
7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16 7.3. Security
7.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 17 7.4. Routing Scalability
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations
10. Informative References . . . . . . . . . . . . . . . . . . . 19 10. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments
Authors' Addresses
1. Introduction 1. Introduction
Information-Centric Networking (ICN) in general, and Content-Centric Information-Centric Networking (ICN), in general, and Content-Centric
Networking (CCNx) [16] or Named Data Networking (NDN) [19] in Networking (CCNx) [1] or Named Data Networking (NDN) [2], in
particular, have emerged as a novel communication paradigm advocating particular, have emerged as a novel communication paradigm that
the retrieval of data based on their names. This paradigm pushes advocates for the retrieval of data based on their names. This
content awareness into the network layer. It is expected to enable paradigm pushes content awareness into the network layer. It is
consumers to obtain the content they desire in a straightforward and expected to enable consumers to obtain the content they desire in a
efficient manner from the heterogenous networks they may be connected straightforward and efficient manner from the heterogenous networks
to. The CCNx/NDN architecture has introduced innovative ideas and they may be connected to. The CCNx/NDN architecture has introduced
has stimulated research in a variety of areas, such as in-network innovative ideas and has stimulated research in a variety of areas,
caching, name-based routing, multipath transport, and content such as in-network caching, name-based routing, multipath transport,
security. One key benefit of requesting content by name is that it and content security. One key benefit of requesting content by name
eliminates the requirement to establish a session between the client is that it eliminates the requirement to establish a session between
and a specific server, and the content can thereby be retrieved from the client and a specific server, and the content can thereby be
multiple sources. retrieved from multiple sources.
In parallel, there has been a growing interest in both academia and In parallel, there has been a growing interest in both academia and
industry for better understanding the fundamental aspects of Network industry for better understanding the fundamental aspects of Network
Coding (NC) toward enhancing key system performance metrics such as Coding (NC) toward enhancing key system performance metrics, such as
data throughput, robustness and reduction in the required number of data throughput, robustness and reduction in the required number of
transmissions through connected networks, and redundant transmission transmissions through connected networks, and redundant transmission
on broadcast or point-to-multipoint connections. NC is a technique on broadcast or point-to-multipoint connections. NC is a technique
that is typically used for encoding packets to recover from lost that is typically used for encoding packets to recover from lost
source packets at the receiver, and for effectively obtaining the source packets at the receiver and for effectively obtaining the
desired information in a fully distributed manner. In addition, in desired information in a fully distributed manner. In addition, in
terms of security aspects, NC can be managed using a practical terms of security aspects, NC can be managed using a practical
security scheme that deals with pollution attacks [2], and can be security scheme that deals with pollution attacks [3] and can be
utilized for preventing eavesdroppers from obtaining meaningful utilized for preventing eavesdroppers from obtaining meaningful
information [3] or protecting a wireless video stream while retaining information [4] or protecting a wireless video stream while retaining
the NC benefits [4] [5]. the NC benefits [5] [6].
From the perspective of the NC transport mechanism, NC can be divided From the perspective of the NC transport mechanism, NC can be divided
into two major categories: coherent NC, and non-coherent NC [38] into two major categories: coherent NC and noncoherent NC [7] [8].
[39]. In coherent NC, the source and destination nodes know the In coherent NC, the source and destination nodes know the exact
exact network topology and the coding operations available at network topology and the coding operations available at intermediate
intermediate nodes. When multiple consumers are attempting to nodes. When multiple consumers are attempting to receive the same
receive the same content such as live video streaming, coherent NC content, such as live video streaming, coherent NC could enable
could enable optimal throughput by sending the content flow over the optimal throughput by sending the content flow over the constructed
constructed optimal multicast trees [32]. However, it requires a optimal multicast trees [9]. However, it requires a fully adjustable
fully adjustable and specific routing mechanism, and a large and specific routing mechanism and a large computational capacity for
computational capacity for central coordination. In the case of non- central coordination. In the case of noncoherent NC, which often
coherent NC, which often uses Random Linear Coding (RLC), it is not uses Random Linear Coding (RLC), it is not necessary to know the
necessary to know the network topology nor the intermediate coding network topology nor the intermediate coding operations [10]. As
operations [33]. As non-coherent NC works in a completely noncoherent NC works in a completely independent and decentralized
independent and decentralized manner, this approach is more feasible manner, this approach is more feasible in terms of eliminating such a
in terms of eliminating such a central coordination. central coordination.
NC combines multiple packets together with parts of the same content, NC combines multiple packets together with parts of the same content
and may do this at the source and/or at other nodes in the network. and may do this at the source and/or at other nodes in the network.
Network coded packets are not associated with a specific server, as Network coded packets are not associated with a specific server, as
they may have been combined within the network. As NC is focused on they may have been combined within the network. As NC is focused on
what information should be encoded in a network packet instead of the what information should be encoded in a network packet instead of the
specific host at which it has been generated, it is in line with the specific host at which it has been generated, it is in line with the
architecture of the CCNx/NDN core networking layer. NC allows for architecture of the CCNx/NDN core networking layer. NC allows for
recovery of missing packets by encoding the information across recovery of missing packets by encoding the information across
several packets. ICN is synergistic with NC, as it allows for several packets. ICN is synergistic with NC, as it allows for
caching of data packets throughout the network. In a typical network caching of data packets throughout the network. In a typical network
that uses NC, the sender must transmit enough packets to retrieve the that uses NC, the sender must transmit enough packets to retrieve the
original data. ICN offers an opportunity to retrieve network coded original data. ICN offers an opportunity to retrieve network-coded
packets directly from caches in the network and this makes the packets directly from caches in the network, making the combination
combination of ICN and NC particularly effective. In fact, NC has of ICN and NC particularly effective. In fact, NC has already been
already been implemented for information/content dissemination [6] implemented for information/content dissemination [11] [12] [13].
[7] [8]. Montpetit, et al., first suggested that NC techniques be Montpetit et al. first suggested that NC techniques be exploited to
exploited to enhance key aspects of system performance in ICN [9]. enhance key aspects of system performance in ICN [14]. Although
Although CCNx/NDN excels to exploit the benefits of NC (as described CCNx/NDN excels to exploit the benefits of NC (as described in
in Section 5), some technical considerations are needed to combine NC Section 5), some technical considerations are needed to combine NC
and CCNx/NDN owing to the unique features of CCNx/NDN (as described and CCNx/NDN owing to the unique features of CCNx/NDN (as described
in Section 6). in Section 6).
In this document, we consider how NC can be applied to the CCNx/NDN In this document, we consider how NC can be applied to the CCNx/NDN
architecture and describe the technical considerations and potential architecture and describe the technical considerations and potential
challenges for making CCNx/NDN-based communications better using the challenges for making CCNx/NDN-based communications better using the
NC technology. It should be noted that the presentation of specific NC technology. It should be noted that the presentation of specific
solutions (e.g., NC optimization methods) for enhancing CCNx/NDN solutions (e.g., NC optimization methods) for enhancing CCNx/NDN
performance metrics by exploiting NC is outside the scope of this performance metrics by exploiting NC is outside the scope of this
document. document.
This document represents the collaborative work and consensus of the This document represents the collaborative work and consensus of the
Coding for Efficient Network Communications Research Group (NWCRG) Coding for Efficient Network Communications Research Group (NWCRG)
and the Information-Centric Networking Research Group (ICNRG). It is and the Information-Centric Networking Research Group (ICNRG). This
not an IETF product and is not a standard. document was read and reviewed by all the active research group
members. It is not an IETF product and is not a standard.
2. Terminology 2. Terminology
2.1. Definitions related to NC 2.1. Definitions Related to NC
This section provides the terms related to NC used in this document, This section provides the terms related to NC used in this document,
which are defined in RFC8406 [21] produced by NWCRG. which are defined in RFC 8406 [15] and produced by the NWCRG.
o Source Packet: A packet originating from the source that Source Packet:
contributes to one or more source symbols. The source symbol is a A packet originating from the source that contributes to one or
unit of data originating from the source that is used as input to more source symbols. The source symbol is a unit of data
encoding operations. For instance, a real-time transport protocol originating from the source that is used as input to encoding
(RTP) packet as a whole can constitute a source symbol. In other operations. For instance, a Real-time Transport Protocol (RTP)
packet as a whole can constitute a source symbol. In other
situations (e.g., to address variable size packets), a single RTP situations (e.g., to address variable size packets), a single RTP
packet may contribute to various source symbols. packet may contribute to various source symbols.
o Repair Packet: A packet containing one or more coded symbols (also Repair Packet:
called repair symbol). Coded symbol or repair symbol is a unit of A packet containing one or more coded symbols (also called repair
data that is the result of a coding operation, applied either to symbol). The coded symbol or repair symbol is a unit of data that
source symbols or (in case of re-coding) source and/or coded is the result of a coding operation, applied either to source
symbols. When there is a single repair symbol per repair packet, symbols or (in case of recoding) source and/or coded symbols.
a repair symbol corresponds to a repair packet. When there is a single repair symbol per repair packet, a repair
symbol corresponds to a repair packet.
o Encoding versus Re-coding versus Decoding: Encoding is an Encoding versus Recoding versus Decoding:
operation that takes source symbols as input and produces encoding Encoding is an operation that takes source symbols as input and
symbols (source or coded symbols) as output. Re-coding is an produces encoding symbols (source or coded symbols) as output.
operation that takes encoding symbols as input and produces Recoding is an operation that takes encoding symbols as input and
encoding symbols as output. Decoding is an operation takes produces encoding symbols as output. Decoding is an operation
encoding symbols as input and produces source symbols as output. that takes encoding symbols as input and produces source symbols
as output.
The terms regarding coding types are defined as follows: The terms regarding coding types are defined as follows:
o Random Linear Coding (RLC): A particular form of linear coding Random Linear Coding (RLC):
using a set of random coding coefficients. Linear coding performs A particular form of linear coding using a set of random coding
linear combination of a set of input symbols (i.e., source and/or coefficients. Linear coding performs a linear combination of a
coded symbols) using a given set of coefficients and results in a set of input symbols (i.e., source and/or coded symbols) using a
repair symbol. given set of coefficients and results in a repair symbol.
o Block Coding: A coding technique wherein the input flow(s) must be Block Coding:
first segmented into a sequence of blocks; encoding and decoding A coding technique wherein the input flow(s) must be first
are performed independently on a per-block basis. segmented into a sequence of blocks. Encoding and decoding are
performed independently on a per-block basis.
o Sliding Window Coding or Convolutional Coding: A general class of Sliding Window Coding or Convolutional Coding:
coding techniques that rely on a sliding encoding window. A general class of coding techniques that rely on a sliding
Encoding window is a set of source (and coded in the case of re- encoding window. An encoding window is a set of source (and coded
coding) symbols used as input to the coding operations. The set in the case of recoding) symbols used as input to the coding
of symbols change over time, as the encoding window slides over operations. The set of symbols change over time, as the encoding
the input flow(s). This is an alternative solution to block window slides over the input flow(s). This is an alternative
coding. solution to block coding.
o Fixed or Elastic Sliding Window Coding: A coding technique that Fixed or Elastic Sliding Window Coding:
generates coded symbol(s) on the fly, from the set of source A coding technique that generates coded symbol(s) on the fly, from
symbols present in the sliding encoding window at that time, the set of source symbols present in the sliding encoding window
usually by using linear coding. The sliding window may be either at that time, usually by using linear coding. The sliding window
of fixed size or of variable size over the time (also known as may be either of fixed size or of variable size over time (also
"Elastic Sliding Window"). For instance, the size may depend on known as "Elastic Sliding Window"). For instance, the size may
acknowledgments sent by the receiver(s) for a particular source depend on acknowledgments sent by the receiver(s) for a particular
symbol or source packet (received, decoded, or decodable). source symbol or source packet (received, decoded, or decodable).
The terms regarding low-level coding aspects are defined as follows: The terms regarding low-level coding aspects are defined as follows:
o Rank of the Linear System or Degrees of Freedom: At a receiver, Rank of the Linear System or Degrees of Freedom:
the number of linearly independent equations of the linear system. At a receiver, the number of linearly independent equations of the
It is also known as "Degrees of Freedom". The system may be of linear system. It is also known as "Degrees of Freedom". The
"full rank," wherein decoding is possible, or "partial rank", system may be of "full rank", wherein decoding is possible, or
wherein only partial decoding is possible. "partial rank", wherein only partial decoding is possible.
o Generation, or Block: With block codes, the set of source symbols Generation or Block:
of the input flow(s) that are logically grouped into a block, With block codes, the set of source symbols of the input flow(s)
before doing encoding. that are logically grouped into a block before doing encoding.
o Generation Size, or Block Size: With block codes, the number of Generation Size or Block Size:
source symbols belonging to a block. It is equivalent to the With block codes, the number of source symbols belonging to a
number of source packets when there is a single source symbol per block. It is equivalent to the number of source packets when
source packet. there is a single source symbol per source packet.
o Coding Coefficient: With linear coding, this is a coefficient in a Coding Coefficient:
certain finite field. This coefficient may be chosen in different With linear coding, this is a coefficient in a certain finite
ways: for instance, randomly, in a predefined table, or using a field. This coefficient may be chosen in different ways: for
predefined algorithm plus a seed. instance, randomly, in a predefined table or using a predefined
algorithm plus a seed.
o Coding Vector: A set of coding coefficients used to generate a Coding Vector:
certain coded symbol through linear coding. A set of coding coefficients used to generate a certain coded
symbol through linear coding.
o Finite Field: Finite fields, used in linear codes, have the Finite Field:
desired property of having all elements (except zero) invertible Finite fields, used in linear codes, have the desired property of
for + and * and no operation over any elements can result in an having all elements (except zero) invertible for + and *, and no
overflow or underflow. Examples of finite fields are prime fields operation over any elements can result in an overflow or
{0..p^m-1}, where p is prime. Most used fields use p=2 and are underflow. Examples of finite fields are prime fields
called binary extension fields {0..2^m-1}, where m often equals 1, {0..p^(m-1)}, where p is prime. Most used fields use p=2 and are
4 or 8 for practical reasons. called binary extension fields {0..2^(m-1)}, where m often equals
1, 4, or 8 for practical reasons.
2.2. Definitions related to CCNx/NDN 2.2. Definitions Related to CCNx/NDN
The terminology regarding CCNx/NDN used in this document is defined The terminology regarding CCNx/NDN used in this document is defined
in RFC8793 [17] produced by ICNRG. They are consistent with the in RFC 8793 [16], which was produced by the ICNRG. They are
relevant documents ([1] [18]). consistent with the relevant documents ([17] [18]).
3. CCNx/NDN Basics 3. CCNx/NDN Basics
We briefly explain the key concepts of CCNx/NDN. In a CCNx/NDN We briefly explain the key concepts of CCNx/NDN. In a CCNx/NDN
network, there are two types of packets at the network level: network, there are two types of packets at the network level:
interest and data packet (defined in Section 3.4 of [17]). The term interest and data packet (defined in Section 3.4 of [16]). The term
of content object, which means a unit of content data, is an alias to "content object", which means a unit of content data, is an alias to
data packet [17]. The ICN consumer (defined in Section 3.2 of [17]) data packet [16]. The ICN consumer (defined in Section 3.2 of [16])
requests a content object by sending an interest that carries the requests a content object by sending an interest that carries the
name of the data. name of the data.
Once an ICN forwarder (defined in Section 3.2 of [17]) receives an Once an ICN forwarder (defined in Section 3.2 of [16]) receives an
interest, it performs a series of lookups: first it checks if it has interest, it performs a series of lookups. First, it checks if it
a copy of the requested content object available in the cache storage has a copy of the requested content object available in the cache
called Content Store (CS) (defined in Section 3.3 of [17]). If it storage, called Content Store (CS) (defined in Section 3.3 of [16]).
does, it returns the data, and the transaction is considered to have If it does, it returns the data, and the transaction is considered to
been successfully completed. have been successfully completed.
If it does not have a copy of the requested content object in the CS, If it does not have a copy of the requested content object in the CS,
it performs a lookup of the Pending Interest Table (PIT) (defined in it performs a lookup of the Pending Interest Table (PIT) (defined in
Section 3.3 of [17]) to check if there is already an outgoing Section 3.3 of [16]) to check if there is already an outgoing
interest for the same content object. If there is no such interest, interest for the same content object. If there is no such interest,
then it creates an entry in the PIT that lists the name included in then it creates an entry in the PIT that lists the name included in
the interest, and the interfaces from which it received the interest. the interest and the interfaces from which it received the interest.
This is later used to send the content object back, as interest This is later used to send the content object back, as interest
packets do not carry a source field that identifies the consumer. If packets do not carry a source field that identifies the consumer. If
there is already a PIT entry for this name, it is updated with the there is already a PIT entry for this name, it is updated with the
incoming interface of this new interest, and the interest is incoming interface of this new interest, and the interest is
discarded. discarded.
After the PIT lookup, the interest undergoes a Forwarding Information After the PIT lookup, the interest undergoes a Forwarding Information
Base (FIB) (defined in Section 3.3 of [17]) lookup for selecting an Base (FIB) (defined in Section 3.3 of [16]) lookup for selecting an
outgoing interface. The FIB lists name prefixes and their outgoing interface. The FIB lists name prefixes and their
corresponding forwarding interfaces in order to send the interest corresponding forwarding interfaces in order to send the interest
towards a forwarder that possesses a copy of the requested data. toward a forwarder that possesses a copy of the requested data.
Once a copy of the data is retrieved, it is sent back to the 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 consumer(s) using the trail of PIT entries; forwarders remove the PIT
state every time that an interest is satisfied, and may store the state every time that an interest is satisfied and may store the data
data in their CS. in their CS.
Data packets carry some information for verifying data integrity and Data packets carry some information for verifying data integrity and
origin authentication, and in particular, that the data is indeed origin authentication and, in particular, that the data is indeed
that which corresponds to the name [24]. This is necessary because that which corresponds to the name [19]. This is necessary because
authentication of the object is crucial in CCNx/NDN. However, this authentication of the object is crucial in CCNx/NDN. However, this
step is optional at forwarders in order to speed up the processing. step is optional at forwarders in order to speed up the processing.
The key aspect of CCNx/NDN is that the consumer of the content does The key aspect of CCNx/NDN is that the consumer of the content does
not establish a session with a specific server. Indeed, the not establish a session with a specific server. Indeed, the
forwarder or producer (defined in Section 3.2 of [17]) that returns forwarder or producer (defined in Section 3.2 of [16]) that returns
the content object is not aware of the network location of the 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 consumer, and the consumer is not aware of the network location of
node that provides the content. This, in theory, allows the the node that provides the content. This, in theory, allows the
interests to follow different paths within a network or even to be interests to follow different paths within a network or even to be
sent over completely different networks. sent over completely different networks.
4. NC Basics 4. NC Basics
While the forwarding node simply relays received data packets in While the forwarding node simply relays received data packets in
conventional IP communication networks, NC allows the node to combine conventional IP communication networks, NC allows the node to combine
some data packets that are already received into one or several some data packets that are already received into one or several
output packets to be sent. In this section, we simply describe the output packets to be sent. In this section, we simply describe the
basic operations of NC. Herein, we focus on RLC in a block coding basic operations of NC. Herein, we focus on RLC in a block coding
skipping to change at page 8, line 17 skipping to change at line 356
packets, where additions and multiplications are performed using a packets, where additions and multiplications are performed using a
coding vector consisting of K coding coefficients that are randomly coding vector consisting of K coding coefficients that are randomly
selected in a certain finite field. The producer may respond to selected in a certain finite field. The producer may respond to
interests to send the corresponding source packets and repair packets interests to send the corresponding source packets and repair packets
in the content flow (called systematic coding), where the repair in the content flow (called systematic coding), where the repair
packets are typically used for recovering lost source packets. packets are typically used for recovering lost source packets.
Repair packets can also be used for performing encoding. If the Repair packets can also be used for performing encoding. If the
forwarding nodes know each coding vector and generation identifier forwarding nodes know each coding vector and generation identifier
(hereinafter referred to as generation ID) of the received repair (hereinafter referred to as generation ID) of the received repair
packets, they may perform an encoding operation (called re-coding), packets, they may perform an encoding operation (called recoding),
which is the most distinctie feature of NC compared to other coding which is the most distinctive feature of NC compared to other coding
techniques. techniques.
At the consumer, decoding is performed by solving a set of linear At the consumer, decoding is performed by solving a set of linear
equations that are represented by the coding vectors of the received equations that are represented by the coding vectors of the received
source and repair packets (possibly only repair packets) within a source and repair packets (possibly only repair packets) within a
certain generation. In order to obtain all the source packets, the certain generation. In order to obtain all the source packets, the
consumer requires K linearly independent equations. In other words, consumer requires K linearly independent equations. In other words,
the consumer must receive at least K linearly independent data the consumer must receive at least K linearly independent data
packets (called innovative packets). As receiving a linearly packets (called innovative packets). As receiving a linearly
dependent data packet is not useful for decoding, re-coding should dependent data packet is not useful for decoding, recoding should
generate and provide innovative packets. One of major benefits of generate and provide innovative packets. One of the major benefits
RLC is that even for a small-sized finite field (e.g., q=2^8), the of RLC is that, even for a small-sized finite field (e.g., q=2^8),
probability of generating linearly dependent packets is negligible the probability of generating linearly dependent packets is
[32]. negligible [9].
5. Advantages of NC and CCNx/NDN 5. Advantages of NC and CCNx/NDN
Combining NC and CCNx/NDN can contribute to effective large-scale Combining NC and CCNx/NDN can contribute to effective large-scale
content/information dissemination. They individually provide similar content/information dissemination. They individually provide similar
benefits such as throughput/capacity gain and robustness enhancement. benefits, such as throughput/capacity gain and robustness
The difference between their approaches is that, the former considers enhancement. The difference between their approaches is that the
content flow as algebraic information that is to be combined [20], former considers content flow as algebraic information that is to be
while the latter focuses on the content/information itself at the combined [7], while the latter focuses on the content/information
networking layer. Because these approaches are complementary and itself at the networking layer. Because these approaches are
their combination would be advantageous, it is natural to combine complementary and their combination would be advantageous, it is
them. natural to combine them.
The name-based communication in CCNx/NDN enables consumers to obtain The name-based communication in CCNx/NDN enables consumers to obtain
requested content objects without establishing and maintaining end- requested content objects without establishing and maintaining end-
to-end communication channels between nodes. This feature to-end communication channels between nodes. This feature
facilitates the exploitation of the in-network cache and multipath/ facilitates the exploitation of the in-network cache and multipath/
multisource retrieval and also supports consumer mobility without the multisource retrieval and also supports consumer mobility without the
need for updating the location information/identifier during handover need for updating the location information/identifier during handover
[1]. Furthermore, the name-based communication intrinsically
[16]. Furthermore, the name-based communication intrinsically
supports multicast communication because identical interests are supports multicast communication because identical interests are
aggregated at the forwarders. aggregated at the forwarders.
NC can enable the CCNx/NDN transport system to effectively distribute NC can enable the CCNx/NDN transport system to effectively distribute
and cache the data associated with multipath data retrieval [9]. and cache the data associated with multipath data retrieval [14].
Exploiting multipath data retrieval and in-network caching with NC Exploiting multipath data retrieval and in-network caching with NC
contributes to not only improving the cache hit rate but also contributes to not only improving the cache hit rate but also
expanding the anonymity set of each consumer (the set of potential expanding the anonymity set of each consumer (the set of potential
routers that can serve a given consumer) [30]. The expansion makes routers that can serve a given consumer) [20]. The expansion makes
it difficult for adversaries to infer the content consumed by others, it difficult for adversaries to infer the content consumed by others
and thus contributes to improving cache privacy. Others also have and thus contributes to improving cache privacy. Others also have
introduced some use cases of the application of NC in CCNx/NDN, such introduced some use cases of the application of NC in CCNx/NDN, such
as the cases of content dissemination with in-network caching [10] as the cases of content dissemination with in-network caching [21]
[13] [14], seamless consumer mobility [11] [36], and low-latency low- [22] [23], seamless consumer mobility [24] [25], and low-latency low-
loss video streaming [15]. In this context, it is well worth loss video streaming [26]. In this context, it is well worth
considering NC integration in CCNx/NDN. considering NC integration in CCNx/NDN.
6. Technical Considerations 6. Technical Considerations
This section presents the considerations for CCNx/NDN with NC in This section presents the considerations for CCNx/NDN with NC in
terms of network architecture and protocol. This document focuses on terms of network architecture and protocol. This document focuses on
NC when employed in a block coding manner. NC when employed in a block coding manner.
6.1. Content Naming 6.1. Content Naming
Naming content objects is as important for CCNx/NDN as naming hosts Naming content objects is as important for CCNx/NDN as naming hosts
is in the current-day Internet [24]. In this section, two possible is in the current-day Internet [19]. In this section, two possible
naming schemes are presented. naming schemes are presented.
6.1.1. Unique Naming for NC Packets 6.1.1. Unique Naming for NC Packets
Each source and repair packet (hereinafter referred to as NC packet) Each source and repair packet (hereinafter referred to as NC packet)
may have a unique name as each original content object has in CCNx/ may have a unique name, as each original content object has in CCNx/
NDN, as PIT and CS operations typically require a unique name for NDN and as PIT and CS operations typically require a unique name for
identifying the NC packet. As a method of naming an NC packet that identifying the NC packet. As a method of naming an NC packet that
takes into account the feature of block coding, the coding vector and takes into account the feature of block coding, the coding vector and
the generation ID can be used as a part of the content object name. the generation ID can be used as a part of the content object name.
As in [10], when the generation ID is "g-id", generation size is 4, As in [21], when the generation ID is "g-id", generation size is 4,
and coding vector is (1,0,0,0), the name could be /CCNx.com/video-A/ and coding vector is (1,0,0,0), the name could be /CCNx.com/video-A/
g-id/1000. Some other identifiers and/or parameters related to the g-id/1000. Some other identifiers and/or parameters related to the
encoding scheme can also be used as name components. For instance, encoding scheme can also be used as name components. For instance,
the encoding ID specifying the coding scheme may be used with "enc- the encoding ID specifying the coding scheme may be used with
id" such as /CCNx.com/video-A/enc-id/g-id/1000, as defined in the FEC "enc-id", such as /CCNx.com/video-A/enc-id/g-id/1000, as defined in
Framework (FECFRAME) [26]. This naming scheme is simple and can the FEC Framework (FECFRAME) [27]. This naming scheme is simple and
support the delivery of NC packets with exactly the same operations can support the delivery of NC packets with exactly the same
in the PIT/CS as those for the content objects. operations in the PIT/CS as those for the content objects.
If a content-naming schema such as the one presented above is used, If a content-naming schema, such as the one presented above, is used,
an interest requesting an NC packet may have the full name including 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 a generation ID and coding vector (/CCNx.com/video-A/g-id/1000) or
only the name prefix including only a generation ID (/CCNx.com/video- only the name prefix including only a generation ID (/CCNx.com/video-
A/g-id). In the former case, exact name matching to the PIT is A/g-id). In the former case, exact name matching to the PIT is
simply performed at data forwarders (as in CCNx/NDN). The consumer simply performed at data forwarders (as in CCNx/NDN). The consumer
is able to specify and retrieve an innovative packet necessary for is able to specify and retrieve an innovative packet necessary for
the consumer to decode successfully. This could shift the generation the consumer to decode successfully. This could shift the generation
of the coding vector from the data forwarder onto the consumer. of the coding vector from the data forwarder onto the consumer.
In the latter case, partial name matching is required at the data In the latter case, partial name matching is required at the data
forwarders. As the interest with only the prefix name matches any NC forwarders. As the interest with only the prefix name matches any NC
packet with the same prefix, the consumer could immediately obtain an packet with the same prefix, the consumer could immediately obtain an
NC packet from a nearby CS (in-network cache) without knowing the NC packet from a nearby CS (in-network cache) without knowing the
coding vectors of the cached NC packets in advance. In the case coding vectors of the cached NC packets in advance. In the case
wherein NC packets in transit are modified by in-network re-coding wherein NC packets in transit are modified by in-network recoding
performed at forwarders, the consumer could also receive the modified performed at forwarders, the consumer could also receive the modified
NC packets. However, in contrast to the former case, the consumer NC packets. However, in contrast to the former case, the consumer
may fail to obtain sufficient degrees of freedom (see Section 6.2.3). may fail to obtain sufficient degrees of freedom (see Section 6.2.3).
To address this issue, a new TLV type in an interest message may be To address this issue, a new TLV type in an interest message may be
required for specifying further coding information in order to limit required for specifying further coding information in order to limit
the NC packets to be received. For instance, this is enabled by the NC packets to be received. For instance, this is enabled by
specifying the coding vectors of innovative packets for the consumer specifying the coding vectors of innovative packets for the consumer
(also called decoding matrix) as in [9]. This extension may incur an (also called decoding matrix) as in [14]. This extension may incur
interest packet of significantly increased size, and it may thus be an interest packet of significantly increased size, and it may thus
useful to use compression techniques for coding vectors [27] [28]. be useful to use compression techniques for coding vectors [28] [29].
Without such coding information provided by the interest, the Without such coding information provided by the interest, the
forwarder would be required to maintain some records regarding the forwarder would be required to maintain some records regarding the
interest packets that were satisfied previously (See Section 6.2.3). interest packets that were satisfied previously (see Section 6.2.3).
6.1.2. Non-Unique Naming for NC Packets 6.1.2. Nonunique Naming for NC Packets
An NC packet may have a name that indicates that it is an NC packet, An NC packet may have a name that indicates that it is an NC packet
and move the coding information into a metadata field in the payload and move the coding information into a metadata field in the payload
(i.e., the name includes the data type, source or repair packet). (i.e., the name includes the data type, source, or repair packet).
This would not be beneficial for applications or services that may This would not be beneficial for applications or services that may
not need to understand the packet payload. Owing to the possibility not need to understand the packet payload. Owing to the possibility
that multiple NC packets may have the same name, some mechanism is that multiple NC packets may have the same name, some mechanism is
required for the consumer to obtain innovative packets. As described required for the consumer to obtain innovative packets. As described
in Section 6.3, a mechanism for managing the multiple innovative in Section 6.3, a mechanism for managing the multiple innovative
packets in the CS would also be required. In addition, extra packets in the CS would also be required. In addition, extra
computational overhead would be incurred when the payload is being computational overhead would be incurred when the payload is being
encrypted. encrypted.
6.2. Transport 6.2. Transport
The pull-based request-response feature of CCNx/NDN is a fundamental The pull-based request-response feature of CCNx/NDN is a fundamental
principle of its transport layer; one interest retrieves at most one principle of its transport layer; one interest retrieves, at most,
data packet. This means that a forwarder or producer cannot inject one data packet. This means that a forwarder or producer cannot
unrequested data packets on its own initiative. It is believed that inject unrequested data packets on its own initiative. It is
it is important that this rule not be violated, as 1) it would open believed that it is important that this rule not be violated, as 1)
denial-of-service (DoS) attacks, 2) it invalidates existing it would open denial-of-service (DoS) attacks, 2) it invalidates
congestion control approaches following this rule, and 3) it would existing congestion control approaches following this rule, and 3) it
reduce the efficiency of existing consumer mobility approaches. would reduce the efficiency of existing consumer mobility approaches.
Thus, the following basic operation should be considered for applying Thus, the following basic operation should be considered for applying
NC to CCNx/NDN. Nevertheless, such security considerations must be NC to CCNx/NDN. Nevertheless, such security considerations must be
addressed if this rule were to be violated. addressed if this rule were to be violated.
6.2.1. Scope of NC 6.2.1. Scope of NC
An open question is whether data forwarder can perform in-network re- An open question is whether a data forwarder can perform in-network
coding with data packets that are being received in transit, or if recoding with data packets that are being received in transit or if
only the data that matches an interest can be subject to NC only the data that matches an interest can be subject to NC
operations. In the latter case, encoding or re-coding is performed operations. In the latter case, encoding or recoding is performed to
to generate the NC packet at any forwarder that is able to respond to generate the NC packet at any forwarder that is able to respond to
the interest. This could occur when each NC packet has a unique name the interest. This could occur when each NC packet has a unique name
and interest has the full name. On the other hand, if interest has a and interest has the full name. On the other hand, if interest has a
partial name without any coding vector information or multiple NC partial name without any coding vector information or multiple NC
packets have the same name, the former case may occur; re-coding packets have the same name, the former case may occur; recoding
occurs anywhere in the network where it is possible to modify the occurs anywhere in the network where it is possible to modify the
received NC packet and forward it. As CCNx/NDN comprises mechanisms received NC packet and forward it. As CCNx/NDN comprises mechanisms
for ensuring the integrity of the data during transfer, in-network for ensuring the integrity of the data during transfer, in-network
re-coding introduces complexities in the network that needs recoding introduces complexities in the network that needs
consideration for the integrity mechanisms to still work. Similarly, consideration for the integrity mechanisms to still work. Similarly,
in-network caching of NC packets at forwarders may be valuable; in-network caching of NC packets at forwarders may be valuable;
however, the forwarders would require some mechanisms to validate the however, the forwarders would require some mechanisms to validate the
NC packets (see Section 8). NC packets (see Section 9).
6.2.2. Consumer Operation 6.2.2. Consumer Operation
To obtain NC benefits (possibly associated with in-network caching), To obtain NC benefits (possibly associated with in-network caching),
the consumer is required to issue interests that direct the forwarder the consumer is required to issue interests that direct the forwarder
(or producer) to respond with innovative packets if available. In (or producer) to respond with innovative packets if available. In
the case where each NC packet may have a unique name (as described in the case where each NC packet may have a unique name (as described in
Section 6.1), by issuing an interest specifying a unique name with Section 6.1), by issuing an interest specifying a unique name with
g-id and the coding vector for an NC packet, the consumer could g-id and the coding vector for an NC packet, the consumer could
appropriately receive an innovative packet if it is available at some appropriately receive an innovative packet if it is available at some
forwarders. forwarders.
In order to specify the exact name of the NC packet to be retrieved, In order to specify the exact name of the NC packet to be retrieved,
the consumer is required to know the valid naming scheme. From a the consumer is required to know the valid naming scheme. From a
practical viewpoint, it is desirable for the consumer application to practical viewpoint, it is desirable for the consumer application to
automatically construct the right name components without depending automatically construct the right name components without depending
on any application specifications. To this end, the consumer on any application specifications. To this end, the consumer
application may retrieve and refer to a manifest [1] that enumerates application may retrieve and refer to a manifest [17] that enumerates
the content objects including NC packets, or may use some coding the content objects, including NC packets, or may use some coding
scheme specifier as a name component to construct the name components scheme specifier as a name component to construct the name components
of interests to request innovative packets. of interests to request innovative packets.
Conversely, the consumer without decoding capability (e.g., specific Conversely, the consumer without decoding capability (e.g., specific
sensor node) may want to receive only the source packets. As sensor node) may want to receive only the source packets. As
described in Section 6.1, because the NC packet can have a name that described in Section 6.1, because the NC packet can have a name that
is explicitly different from source packets, issuing interests for is explicitly different from source packets, issuing interests for
retrieving source packets is possible. retrieving source packets is possible.
6.2.3. Forwarder Operation 6.2.3. Forwarder Operation
If the forwarder constantly responds to the incoming interests by If the forwarder constantly responds to the incoming interests by
returning non-innovative packets, the consumer(s) cannot decode and returning non-innovative packets, the consumer(s) cannot decode and
obtain the source packets. This issue could happen when 1) incoming obtain the source packets. This issue could happen when 1) incoming
interests for NC packets do not specify some coding parameters such interests for NC packets do not specify some coding parameters, such
as the coding vectors to be used, and 2) the forwarder does not have as the coding vectors to be used, and 2) the forwarder does not have
a sufficient number of linearly independent NC packets (possibly in a sufficient number of linearly independent NC packets (possibly in
the CS) to use for re-coding. In this case, the forwarder is the CS) to use for recoding. In this case, the forwarder is required
required to determine whether or not it can generate innovative to determine whether or not it can generate innovative packets to be
packets to be forwarded to the interface(s) at which the interests forwarded to the interface(s) at which the interests arrived. An
arrived. An approach to deal with this issue is that the forwarder approach to deal with this issue is that the forwarder maintains a
maintains a tally of the interests for a specific name, generation ID tally of the interests for a specific name, generation ID, and the
and the incoming interface(s), in order to record how many degrees of incoming interface(s) in order to record how many degrees of freedom
freedom have already been provided [10]. As such a scheme requires have already been provided [21]. As such a scheme requires state
state management (and potentially timers) in forwarders, scalability management (and potentially timers) in forwarders, scalability and
and practicality must be considered. In addition, some transport practicality must be considered. In addition, some transport
mechanism for in-network loss detection and recovery [15] [36] at mechanism for in-network loss detection and recovery [25][26] at a
forwarder as well as a consumer-driven mechanism could be forwarder, as well as a consumer-driven mechanism, could be
indispensable for enabling fast loss recovery and realising NC gains. indispensable for enabling fast loss recovery and realizing NC gains.
If a forwarder cannot either return a matching innovative packet from If a forwarder cannot either return a matching innovative packet from
its local content store, nor produce on-the-fly a recoded packet that its local content store, nor produce on the fly a recoded packet that
is innovative, it is important that the forwarder not simply return a is innovative, it is important that the forwarder not simply return a
non-innovative packet but instead do a forwarding lookup in its FIB non-innovative packet but instead do a forwarding lookup in its FIB
and forward the interest toward the producer or upstream forwarder and forward the interest toward the producer or upstream forwarder
that can provide an innovative packet. In this context, to retrieve that can provide an innovative packet. In this context, to retrieve
innovative packet effectively and quickly, an appropriate setting of an innovative packet effectively and quickly, an appropriate setting
the FIB and efficient interest forwarding strategies should also be of the FIB and efficient interest-forwarding strategies should also
considered. be considered.
In another possible case, when receiving interests only for source In another possible case, when receiving interests only for source
packets, the forwarder may attempt to decode and obtain all the packets, the forwarder may attempt to decode and obtain all the
source packets and store them (if the full cache capacity are source packets and store them (if the full cache capacity are
available), thus enabling a faster response to subsequent interests. available), thus enabling a faster response to subsequent interests.
As re-coding or decoding results in an extra computational overhead, As recoding or decoding results in an extra computational overhead,
the forwarder is required to determine how to respond to received the forwarder is required to determine how to respond to received
interests according to the use case (e.g., a delay-sensitive or interests according to the use case (e.g., a delay-sensitive or
delay-tolerant application) and the forwarder situation, such as delay-tolerant application) and the forwarder situation, such as
available cache space and computational capability. available cache space and computational capability.
6.2.4. Producer Operation 6.2.4. Producer Operation
Before performing NC for specified content in CCNx/NDN, the producer Before performing NC for specified content in CCNx/NDN, the producer
is responsible for splitting the overall content into small content is responsible for splitting the overall content into small content
objects to avoid packet fragmentation that could cause unnecessary objects to avoid packet fragmentation that could cause unnecessary
packet processing and degraded throughput. The size of the content packet processing and degraded throughput. The size of the content
objects should be within the allowable packet size in order to avoid objects should be within the allowable packet size in order to avoid
packet fragmentation in CCNx/NDN network. The producer performs the packet fragmentation in a CCNx/NDN network. The producer performs
encoding operation for a set of the small content objects, and the the encoding operation for a set of the small content objects and the
naming process for the NC packets. naming process for the NC packets.
If the producer takes the lead in determining what coding vectors to If the producer takes the lead in determining what coding vectors to
use in generating the NC packets, there are three general strategies use in generating the NC packets, there are three general strategies
for naming and producing the NC packets: for naming and producing the NC packets:
1. consumers themselves understand in detail the naming conventions 1. Consumers themselves understand in detail the naming conventions
used for NC packets and thereby can send the corresponding used for NC packets and thereby can send the corresponding
interests toward the producer to obtain NC packets whose coding interests toward the producer to obtain NC packets whose coding
parameters have already been determined by the producer. parameters have already been determined by the producer.
2. the producer determines the coding vectors and generates the NC 2. The producer determines the coding vectors and generates the NC
packets after receiving interests specifying the packets the packets after receiving interests specifying the packets the
consumer wished to receive. consumer wished to receive.
3. The naming scheme for specifying the coding vectors and 3. The naming scheme for specifying the coding vectors and
corresponding NC packets is explicitly represented via a corresponding NC packets is explicitly represented via a
"Manifest" (e.g., FLIC [23]) that can be obtained by the consumer "Manifest" (e.g., FLIC [30]) that can be obtained by the consumer
and used to select among the available coding vectors and their and used to select among the available coding vectors and their
corresponding packets, and thereby send the corresponding corresponding packets and thereby send the corresponding
interests. interests.
In the first case, although the consumers cannot flexibly specify a In the first case, although the consumers cannot flexibly specify a
coding vector for generating the NC packet to obtain, the latency for coding vector for generating the NC packet to obtain, the latency for
obtaining the NC packet is less than in the latter two cases. For obtaining the NC packet is less than in the latter two cases. For
the second case, there is a latency penalty for the additional NC the second case, there is a latency penalty for the additional NC
operations performed after receiving the interests. For the third operations performed after receiving the interests. For the third
case, the NC packets to be included in the manifest must be pre- case, the NC packets to be included in the manifest must be pre-
computed by the producer (since the manifest references NC packets by computed by the producer (since the manifest references NC packets by
their hashes, not their names), but the producer can select which to their hashes, not their names), but the producer can select which to
include the manifest, and produce multiple manifests either in include in the manifest and produce multiple manifests either in
advance or on demand with different coding tradeoffs if so desired. advance or on demand with different coding tradeoffs, if so desired.
A common benefit the first two approaches to end-to-end coding is A common benefit of the first two approaches to end-to-end coding is
that if the producer adds a signature on the NC packets, data that, if the producer adds a signature on the NC packets, data
validation becomes possible throughout (as is the case with CCNx/NDN validation becomes possible throughout (as is the case with the CCNx/
operation in the absence of NC). The third approach of using a NDN operation in the absence of NC). The third approach of using a
manifest trades off the additional latency incurred by the need to manifest trades off the additional latency incurred by the need to
fetch the manifest against the efficiency of needing a signature only fetch the manifest against the efficiency of needing a signature only
on the manifest and not on each individual NC packet. on the manifest and not on each individual NC packet.
6.2.5. Backward Compatibility 6.2.5. Backward Compatibility
NC operations should be applied in addition to the regular ICN NC operations should be applied in addition to the regular ICN
behavior, and should function alongside regular ICN operations. behavior and should function alongside regular ICN operations.
Hence, nodes which do not support NC should still be able to properly Hence, nodes that do not support NC should still be able to properly
handle packets, not only in being able to forward the NC packets, but handle packets, not only in being able to forward the NC packets but
also to cache these packets. An NC framework should be compatible also to cache these packets. An NC framework should be compatible
with a regular framework in order to facilitate backward with a regular framework in order to facilitate backward
compatibility and smooth migration from one framework to the other. compatibility and smooth migration from one framework to the other.
6.3. In-network Caching 6.3. In-Network Caching
Caching is a useful technique used for improving throughput and Caching is a useful technique used for improving throughput and
latency in various applications. In-network caching in CCNx/NDN latency in various applications. In-network caching in CCNx/NDN
essentially provides support at network level and is highly essentially provides support at the network level and is highly
beneficial owing to the involved exploitation of NC for enabling beneficial, owing to the involved exploitation of NC for enabling
effective multicast transmission [37], multipath data retrieval [10] effective multicast transmission [31], multipath data retrieval [21]
[11], fast loss recovery [15]. However, there remain several issues [24], and fast loss recovery [26]. However, there remain several
to be considered. issues to be considered.
There generally exist limitations in the CS capacity, and the caching There generally exist limitations in the CS capacity, and the caching
policy affects the consumer's performance [29] [34] [35]. It is thus policy affects the consumer's performance [32] [33] [34]. It is thus
crucial for forwarders to determine which content objects should be crucial for forwarders to determine which content objects should be
cached and which discarded. As delay-sensitive applications often do cached and which discarded. As delay-sensitive applications often do
not require an in-network cache for a long period owing to their not require an in-network cache for a long period, owing to their
real-time constraints, forwarders have to know the necessity for real-time constraints, forwarders have to know the necessity for
caching received content objects to save the caching volume. In caching received content objects to save the caching volume. In
CCNx, this could be made possible by setting a Recommended Cache Time CCNx, this could be made possible by setting a Recommended Cache Time
(RCT) in the optional header of the data packet at the producer side. (RCT) in the optional header of the data packet at the producer side.
The RCT serves as a guideline for the CS cache in determining how The RCT serves as a guideline for the CS cache in determining how
long to retain the content object. When the RCT is set as zero, the long to retain the content object. When the RCT is set as zero, the
forwarder recognizes that caching the content object is not useful. forwarder recognizes that caching the content object is not useful.
Conversely, the forwarder may cache it when the RCT has a greater Conversely, the forwarder may cache it when the RCT has a greater
value. In NDN, the TLV type of FreshnessPeriod could be used. value. In NDN, the TLV type of FreshnessPeriod could be used.
One key aspect of in-network caching is whether or not forwarders can One key aspect of in-network caching is whether or not forwarders can
cache NC packets in their CS. They may be caching the NC packets cache NC packets in their CS. They may be caching the NC packets
without having the ability to perform a validation of the content without having the ability to perform a validation of the content
objects. Therefore, the caching of the NC packets would require some objects. Therefore, the caching of the NC packets would require some
mechanism to validate the NC packets (see Section 8). In the case mechanism to validate the NC packets (see Section 9). In the case
wherein the NC packets have the same name, it would also require some wherein the NC packets have the same name, it would also require some
mechanism to identify them. mechanism to identify them.
6.4. Seamless Consumer Mobility 6.4. Seamless Consumer Mobility
A key feature of CCNx/NDN is that it is sessionless, which enables A key feature of CCNx/NDN is that it is sessionless, which enables
the consumer and forwarder to send multiple interests toward the consumer and forwarder to send multiple interests toward
different copies of the content in parallel, by using multiple different copies of the content in parallel, by using multiple
interfaces at the same time in an asynchronous manner. Through the interfaces at the same time in an asynchronous manner. Through the
multipath data retrieval, the consumer could obtain the content from multipath data retrieval, the consumer could obtain the content from
multiple copies that are distributed while using the aggregate multiple copies that are distributed while using the aggregate
capacity of multiple interfaces. For the link between the consumer capacity of multiple interfaces. For the link between the consumer
and the multiple copies, the consumer can perform a certain rate and the multiple copies, the consumer can perform a certain rate
adaptation mechanism for video streaming [11] or congestion control adaptation mechanism for video streaming [24] or congestion control
for content acquisition [12]. for content acquisition [35].
NC adds a reliability layer to CCNx in a distributed and asynchronous NC adds a reliability layer to CCNx in a distributed and asynchronous
manner, because NC provides a mechanism for ensuring that the manner, because NC provides a mechanism for ensuring that the
interests sent to multiple copies of the content in parallel retrieve interests sent to multiple copies of the content in parallel retrieve
innovative packets, even in the case of packet losses on some of the innovative packets, even in the case of packet losses on some of the
paths/networks to these copies. This applies to consumer mobility paths/networks to these copies. This applies to consumer mobility
events [11], wherein the consumer could receive additional degrees of events [24], wherein the consumer could receive additional degrees of
freedom with any innovative packet if at least one available freedom with any innovative packet if at least one available
interface exists during the mobility event. An interest forwarding interface exists during the mobility event. An interest-forwarding
strategy at the consumer (and possibly forwarder) for efficiently strategy at the consumer (and possibly forwarder) for efficiently
obtaining innovative packets would be required for the consumer to obtaining innovative packets would be required for the consumer to
achieve seamless consumer mobility. achieve seamless consumer mobility.
7. Challenges 7. Challenges
This section presents several primary challenges and research items This section presents several primary challenges and research items
to be considered when applying NC in CCNx/NDN. to be considered when applying NC in CCNx/NDN.
7.1. Adoption of Convolutional Coding 7.1. Adoption of Convolutional Coding
Several block coding approaches have been proposed thus far; however, Several block coding approaches have been proposed thus far; however,
there is still not sufficient discussion and application of the there is still not sufficient discussion and application of the
convolutional coding approach (e.g., sliding or elastic window convolutional coding approach (e.g., sliding or elastic window
coding) in CCNx/NDN. Convolutional coding is often appropriate for coding) in CCNx/NDN. Convolutional coding is often appropriate for
situations wherein a fully or partially reliable delivery of situations wherein a fully or partially reliable delivery of
continuous data flows is required, and especially when these data continuous data flows is required and especially when these data
flows feature realtime constraints. As in [40], on an end-to-end flows feature real-time constraints. As in [36], on an end-to-end
coding basis, it would be advantageous for continuous content flow to coding basis, it would be advantageous for continuous content flow to
adopt sliding window coding in CCNx/NDN. In this case, the producer adopt sliding window coding in CCNx/NDN. In this case, the producer
is required to appropriately set coding parameters and let the is required to appropriately set coding parameters and let the
consumer know the information, and the consumer is required to send consumer know the information, and the consumer is required to send
interests augmented with feedback information regarding the data interests augmented with feedback information regarding the data
reception and/or decoding status. As CCNx/NDN utilises hop-by-hop reception and/or decoding status. As CCNx/NDN utilizes the hop-by-
forwarding state, it would be worth discussing and investigating how hop forwarding state, it would be worth discussing and investigating
convolutional coding can be applied in a hop-by-hop manner and what how convolutional coding can be applied in a hop-by-hop manner and
benefits might accrue. In particular, in the case wherein in-network what benefits might accrue. In particular, in the case wherein in-
re-coding could occur at forwarders, both the encoding window and CS network recoding could occur at forwarders, both the encoding window
management would be required, and the corresponding feasibility and and CS management would be required, and the corresponding
practicality should be considered. feasibility and practicality should be considered.
7.2. Rate and Congestion Control 7.2. Rate and Congestion Control
The addition of redundancy using repair packets may result in further The addition of redundancy using repair packets may result in further
network congestion and could adversely affect the overall throughput. network congestion and could adversely affect the overall throughput.
In particular, in a situation wherein fair bandwidth sharing is more In particular, in a situation wherein fair bandwidth sharing is more
desirable, each streaming flow must adapt to the network conditions desirable, each streaming flow must adapt to the network conditions
to fairly consume the available link bandwidth. It is thus necessary to fairly consume the available link bandwidth. It is thus necessary
that each content flow cooperatively implement congestion control to that each content flow cooperatively implement congestion control to
adjust the consumed bandwidth [22]. From this perspective, an adjust the consumed bandwidth [37]. From this perspective, an
effective deployment approach (e.g., a forwarder-supported approach effective deployment approach (e.g., a forwarder-supported approach
that can provide benefits under partial deployment) is required. that can provide benefits under partial deployment) is required.
As described in Section 6.4, NC can contribute to seamless consumer As described in Section 6.4, NC can contribute to seamless consumer
mobility by obtaining innovative packets without receiving duplicated mobility by obtaining innovative packets without receiving duplicated
packets through multipath data retrieval, and avoiding duplicated packets through multipath data retrieval, and avoiding duplicated
packets has congestion control benefits as well. It can be packets has congestion control benefits as well. It can be
challenging to develop an effective rate and congestion control challenging to develop an effective rate and congestion control
mechanism in order to achieve seamless consumer mobility while mechanism in order to achieve seamless consumer mobility while
improving the overall throughput or latency by fully exploiting NC improving the overall throughput or latency by fully exploiting NC
operations. operations.
7.3. Security 7.3. Security
While CCNx/NDN introduces new security issues at the networking layer While CCNx/NDN introduces new security issues at the networking layer
that are different from the IP network, such as a cache poisoning and that are different from the IP network, such as a cache poisoning,
pollution attacks, a DoS attack using interest packets, some security pollution attacks, and a DoS attack using interest packets, some
approaches are already provided [24] [25]. The application of NC in security approaches are already provided [19] [38]. The application
CCNx/NDN brings two potential security aspects that need to be dealt of NC in CCNx/NDN brings two potential security aspects that need to
with. be dealt with.
The first is in-network re-coding at forwarders. Some mechanism for The first is in-network recoding at forwarders. Some mechanism for
ensuring the integrity of the NC packets newly produced by in-network ensuring the integrity of the NC packets newly produced by in-network
re-coding is required in order for consumers or other forwarders to recoding is required in order for consumers or other forwarders to
receive valid NC packets. To this end, there are some possible receive valid NC packets. To this end, there are some possible
approaches described in Section 8, but there may be more effective approaches described in Section 9, but there may be a more effective
method with lower complexity and computation overhead. method with lower complexity and computation overhead.
The second is that attackers maliciously request and inject NC The second is that attackers maliciously request and inject NC
packets, which could amplify some attacks. As NC packets are packets, which could amplify some attacks. As NC packets are
unpopular in general use, they could be targeted by a cache pollution unpopular in general use, they could be targeted by a cache pollution
attack that requests less popular content objects more frequently to attack that requests less popular content objects more frequently to
undermine popularity-based caching by skewing the content popularity. undermine popularity-based caching by skewing the content popularity.
Such an attack needs to be dealt with in order to maintain the in- Such an attack needs to be dealt with in order to maintain the in-
network cache efficiency. By injecting invalid NC packets with the network cache efficiency. By injecting invalid NC packets with the
goal of filling the CSs at the forwarders with them, the cache goal of filling the CSs at the forwarders with them, the cache
poisoning attack could be effectual depending on the exact integrity poisoning attack could be effectual depending on the exact integrity
coverage on NC packets. On the assumption that each NC packet has coverage on NC packets. On the assumption that each NC packet has
the valid signature, the straightforward approach would comprise the the valid signature, the straightforward approach would comprise the
forwarders verifying the signature within the NC packets in transit forwarders verifying the signature within the NC packets in transit
and only transmitting and storing the validated NC packets. However, and only transmitting and storing the validated NC packets. However,
as performing a signature verification by the forwarders may be as performing a signature verification by the forwarders may be
infeasible at line speed, some mechanisms should be considered for infeasible at line speed, some mechanisms should be considered for
distributing and reducing the load of signature verification, in distributing and reducing the load of signature verification in order
order to maintain in-network cache benefits such as latency and to maintain in-network cache benefits, such as latency and network-
network-load reduction. load reduction.
7.4. Routing Scalability 7.4. Routing Scalability
In CCNx/NDN, a name-based routing protocol without a resolution In CCNx/NDN, a name-based routing protocol without a resolution
process streamlines the routing process and reduces the overall process streamlines the routing process and reduces the overall
latency. In IP routing, the growth in the routing table size has latency. In IP routing, the growth in the routing table size has
become a concern. It is thus necessary to use a hierarchical naming become a concern. It is thus necessary to use a hierarchical naming
scheme in order to improve the routing scalability by enabling the scheme in order to improve the routing scalability by enabling the
aggregation of the routing information. aggregation of the routing information.
To realize the benefits of NC, consumers need to efficiently obtain To realize the benefits of NC, consumers need to efficiently obtain
innovative packets using multipath retrieval mechanisms of CCNx/NDN. innovative packets using multipath retrieval mechanisms of CCNx/NDN.
This would require some efficient routing mechanism to appropriately This would require some efficient routing mechanism to appropriately
set the FIB and also an efficient interest forwarding strategy. Such set the FIB and also an efficient interest-forwarding strategy. Such
routing coordination may create routing scalability issues. It would routing coordination may create routing scalability issues. It would
be challenging to achieve effective and scalable routing for be challenging to achieve effective and scalable routing for
interests requesting NC packets as well as to simplify the routing interests requesting NC packets, as well as to simplify the routing
process. process.
8. Security Considerations 8. IANA Considerations
In-network re-coding is a distinguishing feature of NC. Only valid This document has no IANA actions.
NC packets produced by in-network re-coding must be requested and
9. Security Considerations
In-network recoding is a distinguishing feature of NC. Only valid NC
packets produced by in-network recoding must be requested and
utilized (and possibly stored). To this end, there exist some utilized (and possibly stored). To this end, there exist some
possible approaches. First, as a signature verification approach, possible approaches. First, as a signature verification approach,
the exploitation of multi-signature capability could be applied. the exploitation of multi-signature capability could be applied.
This allows not only the original content producer but also some This allows not only the original content producer but also some
forwarders responsible for in-network re-coding to have their own forwarders responsible for in-network recoding to have their own
unique signing key. Each forwarder of the group signs newly unique signing key. Each forwarder of the group signs a newly
generated NC packet in order for other nodes to be able to validate generated NC packet in order for other nodes to be able to validate
the data with the signature. The CS may verify the signature within the data with the signature. The CS may verify the signature within
the NC packet before storing it to avoid invalid data caching. the NC packet before storing it to avoid invalid data caching.
Second, as a consumer-dependent approach, the consumer puts a Second, as a consumer-dependent approach, the consumer puts a
restriction on the matching rule using only the name of the requested restriction on the matching rule using only the name of the requested
data. The interest ambiguity can be clarified by specifying both the data. The interest ambiguity can be clarified by specifying both the
name and the key identifier (the producer's public key digest) used name and the key identifier (the producer's public key digest) used
for matching to the requested data. This KeyId restriction is built for matching to the requested data. This KeyId restriction is built
in the CCNx design [1]. Only the requested data packet satisfying in the CCNx design [17]. Only the requested data packet satisfying
the interest with the KeyId restriction would be forwarded and stored the interest with the KeyId restriction would be forwarded and stored
in the CS, thus resulting in a reduction in the chances of cache in the CS, thus resulting in a reduction in the chances of cache
poisoning. Moreover, in the CCNx design, there exists the rule that poisoning. Moreover, in the CCNx design, there exists the rule that
the CS obeys in order to avoid amplifying invalid data; if an the CS obeys in order to avoid amplifying invalid data; if an
interest has a KeyID restriction, the CS must not reply unless it interest has a KeyId restriction, the CS must not reply unless it
knows that the signature on the matching content object is correct. knows that the signature on the matching content object is correct.
If the CS cannot verify the signature, the interest may be treated as If the CS cannot verify the signature, the interest may be treated as
a cache miss and forwarded to the upstream forwarder(s). Third, as a a cache miss and forwarded to the upstream forwarder(s). Third, as a
certificate chain management approach (possibly without certificate certificate chain management approach (possibly without certificate
authority), some mechanism such as [31] could be used to establish a authority), some mechanism, such as [39], could be used to establish
trustworthy data delivery path. This approach adopts the hop-by-hop a trustworthy data delivery path. This approach adopts the hop-by-
authentication mechanism, wherein forwarding-integrated hop-by-hop hop authentication mechanism, wherein the forwarding-integrated hop-
certificate collection is performed to provide suspension certificate by-hop certificate collection is performed to provide suspension
chains such that the data retrieval is trustworthy. certificate chains such that the data retrieval is trustworthy.
Depending on the adopted caching strategy such as cache replacement Depending on the adopted caching strategy, such as cache replacement
policies, forwarders should also take caution when storing and policies, forwarders should also take caution when storing and
retaining the NC packets in the CS as they could be targeted by cache retaining the NC packets in the CS, as they could be targeted by
pollution attacks. In order to mitigate the cache pollution attacks' cache pollution attacks. In order to mitigate the cache pollution
impact, forwarders should check the content request frequencies to attacks' impact, forwarders should check the content request
detect the attack and may limit requests by ignoring some of the frequencies to detect the attack and may limit requests by ignoring
consecutive requests. The forwarders can then decide to apply or some of the consecutive requests. The forwarders can then decide to
change to the other cache replacement mechanism. apply or change to the other cache replacement mechanism.
The forwarders or producers require careful attention to the DoS The forwarders or producers require careful attention to the DoS
attacks aiming at provoking the high load of NC operations by using attacks aimed at provoking the high load of NC operations by using
the interests for NC packets. In order to mitigate such attacks, the the interests for NC packets. In order to mitigate such attacks, the
forwarders could adopt a rate-limiting approach. For instance, they forwarders could adopt a rate-limiting approach. For instance, they
could monitor the PIT size growth for NC packets per content to could monitor the PIT size growth for NC packets per content to
detect the attacks, and limit the interest arrival rate when detect the attacks and limit the interest arrival rate when
necessary. If the NC application wishes to secure an interest necessary. If the NC application wishes to secure an interest
(considered as the NC actuator) in order to prevent such attacks, the (considered as the NC actuator) in order to prevent such attacks, the
application should consider using an encrypted wrapper and an application should consider using an encrypted wrapper and an
explicit protocol. explicit protocol.
9. Acknowledgements
The authors would like to thank ICNRG and NWCRG members, especially
Marie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti,
for their valuable comments and suggestions on this document.
10. Informative References 10. Informative References
[1] Mosko, M. and et al., "Content-Centric Networking (CCNx) [1] Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
Semantics", RFC 8569, July 2019, Briggs, N., and R. Braynard, "Networking Named Content",
<https://tools.ietf.org/html/rfc8569>. Proc. CoNEXT, ACM, DOI 10.1145/1658939.1658941, December
2009, <https://doi.org/10.1145/1658939.1658941>.
[2] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for [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, Network Coding File Distribution", Proc. Infocom, IEEE,
April 2006. DOI 10.1109/INFOCOM.2006.233, April 2006,
<https://doi.org/10.1109/INFOCOM.2006.233>.
[3] Cai, N. and R. Yeung, "Secure network coding", Proc. [4] Cai, N. and R. Yeung, "Secure network coding", Proc.
International Symposium on Information Theory International Symposium on Information Theory (ISIT),
(ISIT), IEEE, June 2002. IEEE, DOI 10.1109/ISIT.2002.1023595, June 2002,
<https://doi.org/10.1109/ISIT.2002.1023595>.
[4] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A. [5] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A.
Toledo, "Secure Network Coding for Multi-Resolution Toledo, "Secure Network Coding for Multi-Resolution
Wireless Video Streaming", IEEE Journal of Selected Area Wireless Video Streaming", IEEE Journal of Selected Area
(JSAC), vol. 28, no. 3, April 2010. (JSAC), vol. 28, no. 3, DOI 10.1109/JSAC.2010.100409,
April 2010, <https://doi.org/10.1109/JSAC.2010.100409>.
[5] Vilea, J., Lima, L., and J. Barros, "Lightweight security [6] Vilea, J., Lima, L., and J. Barros, "Lightweight security
for network coding", Proc. ICC, IEEE, May 2008. for network coding", Proc. ICC, IEEE,
DOI 10.48550/arXiv.0807.0610, May 2008,
<https://doi.org/10.48550/arXiv.0807.0610>.
[6] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. [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 Ramchandran, "Network Coding for Distributed Storage
Systems", IEEE Trans. Information Theory, vol. 56, no.9, Systems", IEEE Trans. Information Theory, vol. 56, no.9,
September 2010. DOI 10.1109/TIT.2010.2054295, September 2010,
<https://doi.org/10.1109/TIT.2010.2054295>.
[7] Gkantsidis, C. and P. Rodriguez, "Network coding for large [12] Gkantsidis, C. and P. Rodriguez, "Network coding for large
scale content distribution", Proc. Infocom, IEEE, March scale content distribution", Proc. Infocom, IEEE,
2005. DOI 10.1109/INFCOM.2005.1498511, March 2005,
<https://doi.org/10.1109/INFCOM.2005.1498511>.
[8] Seferoglu, H. and A. Markopoulou, "Opportunistic Network [13] Seferoglu, H. and A. Markopoulou, "Opportunistic Network
Coding for Video Streaming over Wireless", Proc. Packet Coding for Video Streaming over Wireless", Proc. Packet
Video Workshop (PV), IEEE, November 2007. Video Workshop (PV), IEEE,
DOI 10.1109/PACKET.2007.4397041, November 2007,
<https://doi.org/10.1109/PACKET.2007.4397041>.
[9] Montpetit, M., Westphal, C., and D. Trossen, "Network [14] Montpetit, M., Westphal, C., and D. Trossen, "Network
Coding Meets Information-Centric Networking: An Coding Meets Information-Centric Networking: An
Architectural Case for Information Dispersion Through Architectural Case for Information Dispersion Through
Native Network Coding", Proc. Workshop on Emerging Name- Native Network Coding", Proc. Workshop on Emerging Name-
Oriented Mobile Networking Design (NoM), ACM, June 2012. Oriented Mobile Networking Design (NoM), ACM,
DOI 10.1145/2248361.2248370, June 2012,
[10] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, <https://doi.org/10.1145/2248361.2248370>.
"NetCodCCN: a network coding approach for content-centric
networks", Proc. Infocom, IEEE, April 2016.
[11] 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, December 2016.
[12] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, [15] Adamson, B., Adjih, C., Bilbao, J., Firoiu, V., Fitzek,
"MIRCC: Multipath-aware ICN Rate-based Congestion F., Ghanem, S., Lochin, E., Masucci, A., Montpetit, M-J.,
Control", Proc. Conference on Information-Centric Pedersen, M., Peralta, G., Roca, V., Ed., Saxena, P., and
Networking (ICN), ACM, September 2016. 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>.
[13] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. [16] Wissingh, B., Wood, C., Afanasyev, A., Zhang, L., Oran,
Westphal, "An Optimal Cache Management Framework for D., and C. Tschudin, "Information-Centric Networking
Information-Centric Networks with Network Coding", Proc. (ICN): Content-Centric Networking (CCNx) and Named Data
Networking Conference, IFIP/IEEE, June 2014. Networking (NDN) Terminology", RFC 8793,
DOI 10.17487/RFC8793, June 2020,
<https://www.rfc-editor.org/info/rfc8793>.
[14] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. [17] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Westphal, "A Minimum Cost Cache Management Framework for Networking (CCNx) Semantics", RFC 8569,
Information-Centric Networks with Network Coding", DOI 10.17487/RFC8569, July 2019,
Computer Networks, Elsevier, August 2016. <https://www.rfc-editor.org/info/rfc8569>.
[15] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency [18] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Low Loss Streaming using In-Network Coding and Caching", Networking (CCNx) Messages in TLV Format", RFC 8609,
Proc. Infocom, IEEE, May 2017. DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>.
[16] Jacobson, V., Smetters, D., Thornton, J., Plass, M., [19] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Briggs, N., and R. Braynard, "Networking Named Content", Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
Proc. CoNEXT, ACM, December 2009. "Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
[17] Wissingh, B. and et al., "Information-Centric Networking [20] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G.
(ICN): Content-Centric Networking (CCNx) and Named Data Xie, "Privacy-Aware Multipath Video Caching for Content-
Networking (NDN) Terminology", RFC 8793, June 2020, Centric Networks", IEEE Journal on Selected Areas in
<https://tools.ietf.org/html/rfc8793>. Communications (JSAC), vol. 38, no. 8,
DOI 10.1109/JSAC.2016.2577321, June 2016,
<https://doi.org/10.1109/JSAC.2016.2577321>.
[18] Mosko, M. and et al., "Content-Centric Networking (CCNx) [21] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun,
Messages in TLV Format", RFC 8609, July 2019, "NetCodCCN: a network coding approach for content-centric
<https://tools.ietf.org/html/rfc8609>. networks", Proc. Infocom, IEEE,
DOI 10.1109/INFOCOM.2016.7524382, April 2016,
<https://doi.org/10.1109/INFOCOM.2016.7524382>.
[19] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, [22] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C.
K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, Westphal, "An Optimal Cache Management Framework for
"Named data networking", ACM Comput. Commun. Rev., vol. Information-Centric Networks with Network Coding", Proc.
44, no. 3, July 2014. Networking Conference, IFIP/IEEE,
DOI 10.1109/IFIPNetworking.2014.6857127, June 2014,
<https://doi.org/10.1109/IFIPNetworking.2014.6857127>.
[20] Koetter, R. and M. Medard, "An Algebraic Approach to [23] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C.
Network Coding", IEEE/ACM Trans. on Networking, vol. 11, Westphal, "A Minimum Cost Cache Management Framework for
no 5, Oct. 2003. 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>.
[21] Adamson, B. and et al., "Taxonomy of Coding Techniques for [24] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive
Efficient Network Communications", RFC 8406, June 2018, Video Streaming over CCN with Network Coding for Seamless
<https://tools.ietf.org/html/rfc8406>. Mobility", Proc. International Symposium on Multimedia
(ISM), IEEE, DOI 10.1109/ISM.2016.0054, December 2016,
<https://doi.org/10.1109/ISM.2016.0054>.
[22] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding [25] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova,
and Congestion Control in Transport", Work in Progress, N., and X. Zeng, "Leveraging ICN In-network Control for
draft-irtf-nwcrg-coding-and-congestion-09, June 2021. 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>.
[23] Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like [26] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency
ICN Collections (FLIC)", Work in Progress, draft-irtf- Low Loss Streaming using In-Network Coding and Caching",
icnrg-flic-03, Nov. 2021. Proc. Infocom, IEEE, DOI 10.1109/INFOCOM.2017.8057026, May
2017, <https://doi.org/10.1109/INFOCOM.2017.8057026>.
[24] Kutscher, D. and et al., "Information-Centric Networking [27] Watson, M., Begen, A., and V. Roca, "Forward Error
(ICN) Research Challenges", RFC 7927, July 2016. Correction (FEC) Framework", RFC 6363,
DOI 10.17487/RFC6363, October 2011,
<https://www.rfc-editor.org/info/rfc6363>.
[25] Pentikousis, K. and et al., "Information-Centric [28] Thomos, N. and P. Frossard, "Toward One Symbol Network
Networking: Evaluation and Security Considerations", Coding Vectors", IEEE Communications Letters, vol. 16, no.
RFC 7945, July 2019. 11, DOI 10.1109/LCOMM.2012.092812.121661, November 2012,
<https://doi.org/10.1109/LCOMM.2012.092812.121661>.
[26] Watson, M. and et al., "Forward Error Correction (FEC) [29] Lucani, D., Pedersen, M., Ruano, D., Sørensen, C., Heide,
Framework", RFC 6363, Oct. 2011. 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>.
[27] Thomos, N. and P. Frossard, "Toward one Symbol Network [30] Tschudin, C., Wood, C. A., Mosko, M., and D. Oran, "File-
Coding Vectors", IEEE Communications letters, vol. 16, no. Like ICN Collections (FLIC)", Work in Progress, Internet-
11, November 2012. Draft, draft-irtf-icnrg-flic-03, November 2021,
<https://www.ietf.org/archive/id/draft-irtf-icnrg-flic-
03.txt>.
[28] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek, [31] Maddah-Ali, M. and U. Niesen, "Coding for Caching:
"Fulcrum Network Codes: A Code for Fluid Allocation of Fundamental Limits and Practical Challenges", IEEE
Complexity", available at http://arxiv.org/abs/1404.6620, Communications Magazine, vol. 54, no. 8,
April 2014. DOI 10.1109/MCOM.2016.7537173, August 2016,
<https://doi.org/10.1109/MCOM.2016.7537173>.
[29] Perino, D. and M. Varvello, "A reality check for content [32] Perino, D. and M. Varvello, "A reality check for content
centric networking", Proc. SIGCOMM Workshop on centric networking", Proc. SIGCOMM Workshop on
Information-centric networking (ICN'11), ACM, August 2011. Information-centric networking (ICN '11), ACM,
DOI 10.1145/2018584.2018596, August 2011,
[30] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. <https://doi.org/10.1145/2018584.2018596>.
Xie, "Privacy-Aware Multipath Video Caching for Content-
Centric Networks", IEEE Journal of Selected Area
(JSAC) vol. 38, no. 8, June 2016.
[31] 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, September 2018.
[32] Wu, Y., Chou, P., and K. Jain, "A comparison of network [33] Podlipnig, S. and L. Böszörmenyi, "A Survey of Web Cache
coding and tree packing", Proc. ISIT, IEEE, June 2004. Replacement Strategies", Proc. ACM Computing Surveys, vol.
35, no. 4, DOI 10.1145/954339.954341, December 2003,
<https://doi.org/10.1145/954339.954341>.
[33] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D., [34] Rossini, G. and D. Rossi, "Evaluating CCN multi-path
Shi, M., and B. Leong, "A Random Linear Network Coding interest forwarding strategies", Elsevier Computer
Approach to Multicast", IEEE Trans. Information Communications, vol. 36, no. 7,
Theory, vol. 52, no.10, October 2006. DOI 10.1016/j.comcom.2013.01.008, April 2013,
<https://doi.org/10.1016/j.comcom.2013.01.008>.
[34] Podlipnig, S. and L. Osz, "A Survey of Web Cache [35] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran,
Replacement Strategies", Proc. ACM Computing Surveys vol. "MIRCC: Multipath-aware ICN Rate-based Congestion
35, no. 4, December 2003. Control", Proc. Conference on Information-Centric
Networking (ICN), ACM, DOI 10.1145/2984356.2984365,
September 2016, <https://doi.org/10.1145/2984356.2984365>.
[35] Rossini, G. and D. Rossi, "Evaluating CCN multi-path [36] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and
interest forwarding strategies", Elsevier Computer V. Roca, "On-the-Fly Erasure Coding for Real-Time Video
Communication, vol.36, no. 7, April 2013. 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>.
[36] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, [37] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Forward
N., and X. Zeng, "Leveraging ICN In-network Control for Erasure Correction (FEC) Coding and Congestion Control in
Loss Detection and Recovery in Wireless Mobile networks", Transport", RFC 9265, DOI 10.17487/RFC9265, July 2022,
Proc. ICN ACM, September 2016. <https://www.rfc-editor.org/info/rfc9265>.
[37] Ali, M. and U. Niesen, "Coding for Caching: Fundamental [38] Pentikousis, K., Ed., Ohlman, B., Davies, E., Spirou, S.,
Limits and Practical Challenges", IEEE Communications and G. Boggia, "Information-Centric Networking: Evaluation
Magazine vol. 54, no. 8, August 2016. and Security Considerations", RFC 7945,
DOI 10.17487/RFC7945, September 2016,
<https://www.rfc-editor.org/info/rfc7945>.
[38] Koetter, R. and F. Kschischang, "An algebraic approach to [39] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric
network coding", IEEE Trans. Netw. vol.11, no.5, October Authentication for Secure In-Network Big-Data Retrieval",
2003. 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>.
[39] Vyetrenko, S., Ho, T., Effros, M., Kliewer, J., and E. Acknowledgments
Erez, "Rate regions for coherent and noncoherent
multisource network error correction", Proc. International
Symposium on Information Theory (ISIT), IEEE, July 2009.
[40] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and The authors would like to thank ICNRG and NWCRG members, especially
V. Roca, "On-the-Fly Erasure Coding for Real-Time Video Marie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti,
Applications", IEEE Trans. Multimeda vol.13, no.4, August for their valuable comments and suggestions on this document.
2011.
Authors' Addresses Authors' Addresses
Kazuhisa Matsuzono Kazuhisa Matsuzono
National Institute of Information and Communications Technology National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi, Tokyo
Koganei, Tokyo 184-8795 184-8795
Japan Japan
Email: matsuzono@nict.go.jp Email: matsuzono@nict.go.jp
Hitoshi Asaeda Hitoshi Asaeda
National Institute of Information and Communications Technology National Institute of Information and Communications Technology
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi, Tokyo
Koganei, Tokyo 184-8795 184-8795
Japan Japan
Email: asaeda@nict.go.jp Email: asaeda@nict.go.jp
Cedric Westphal Cedric Westphal
Huawei Huawei
2330 Central Expressway 2330 Central Expressway
Santa Clara, California 95050 Santa Clara, California 95050
USA United States of America
Email: cedric.westphal@futurewei.com, Email: cedric.westphal@futurewei.com,
 End of changes. 160 change blocks. 
474 lines changed or deleted 538 lines changed or added

This html diff was produced by rfcdiff 1.48.