Network Coding for Content-Centric Networking / Named Data Networking: Considerations and Challenges
draft-irtf-nwcrg-nwc-ccn-reqs-04

Document Type Active Internet-Draft (nwcrg RG)
Last updated 2020-09-07 (latest revision 2020-09-02)
Replaces draft-matsuzono-nwcrg-nwc-ccn-reqs
Stream IRTF
Intended RFC status Informational
Formats plain text pdf htmlized (tools) htmlized bibtex
Stream IRTF state In RG Last Call
Consensus Boilerplate Unknown
Document shepherd Marie-Jose Montpetit
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to Marie-Jose Montpetit <marie@mjmontpetit.com>
Network Coding Research Group                               K. Matsuzono
Internet-Draft                                                 H. Asaeda
Intended status: Informational                                      NICT
Expires: March 6, 2021                                       C. Westphal
                                                                  Huawei
                                                       September 2, 2020

 Network Coding for Content-Centric Networking / Named Data Networking:
                     Considerations and Challenges
                    draft-irtf-nwcrg-nwc-ccn-reqs-04

Abstract

   This document describes the current research outcomes in Network
   Coding (NWC) for Content-Centric Networking (CCNx) / Named Data
   Networking (NDN), and clarifies the technical considerations and
   potential challenges for applying NWC in CCNx/NDN.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on March 6, 2021.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Matsuzono, et al.         Expires March 6, 2021                 [Page 1]
Internet-Draft               NWC for CCN/NDN              September 2020

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Definitions related NWC . . . . . . . . . . . . . . . . .   4
     2.2.  Definitions related to CCNx/NDN . . . . . . . . . . . . .   6
   3.  CCNx/NDN Basics . . . . . . . . . . . . . . . . . . . . . . .   7
   4.  NWC Basics  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   5.  Advantages of NWC and CCNx/NDN  . . . . . . . . . . . . . . .   9
   6.  Technical Considerations  . . . . . . . . . . . . . . . . . .   9
     6.1.  Content Naming  . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Transport . . . . . . . . . . . . . . . . . . . . . . . .  11
       6.2.1.  Scope of NWC  . . . . . . . . . . . . . . . . . . . .  11
       6.2.2.  Consumer Operation  . . . . . . . . . . . . . . . . .  11
       6.2.3.  Router Operation  . . . . . . . . . . . . . . . . . .  12
       6.2.4.  Publisher Operation . . . . . . . . . . . . . . . . .  13
       6.2.5.  Backward Compatibility  . . . . . . . . . . . . . . .  13
     6.3.  In-network Caching  . . . . . . . . . . . . . . . . . . .  13
     6.4.  Seamless Consumer Mobility  . . . . . . . . . . . . . . .  14
   7.  Challenges  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     7.1.  Adoption of Convolutional Coding  . . . . . . . . . . . .  15
     7.2.  Rate and Congestion Control . . . . . . . . . . . . . . .  15
     7.3.  Security  . . . . . . . . . . . . . . . . . . . . . . . .  16
     7.4.  Routing Scalability . . . . . . . . . . . . . . . . . . .  17
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  17
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  18
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Introduction

   Information-Centric Networking (ICN) in general, and Content-Centric
   Networking (CCNx) [16] or Named Data Networking (NDN) [18] in
   particular, have emerged as a novel communication paradigm advocating
   the retrieval of data based on their names.  This paradigm pushes
   content awareness into the network layer.  It is expected to enable
   consumers to obtain the content they desire in a straightforward and
   efficient manner from the heterogenous networks they may be connected
   to.  The CCNx/NDN architecture has introduced innovative ideas and
   has stimulated research in a variety of areas, such as in-network
   caching, name-based routing, multipath transport, content security.
   One key benefit of requesting content by name is that it eliminates
   the requirement of establishing a session between the client and a
   specific server, and the content can thereby be retrieved from
   multiple sources.

Matsuzono, et al.         Expires March 6, 2021                 [Page 2]
Internet-Draft               NWC for CCN/NDN              September 2020

   In parallel, there has been a growing interest in both academia and
   industry for better understanding the fundamental aspects of Network
   Coding (NWC) toward enhancing key system-performance metrics such as
   data throughput, robustness and reduction in the required number of
   transmissions through connected networks, and point-to-multipoint
   connections.  NWC is a technique that is typically used for encoding
   packets for recovering lost source packets at the receiver, and for
   effectively obtaining the desired information in a fully distributed
   manner.  In addition, NWC can be used for security enhancements [2]
   [3] [4] [5].

   From the perspective of the NWC transport mechanism, NWC can be
   categorized into two major categories: coherent NWC, and non-coherent
   NWC [35].  In coherent NWC, the source and destination nodes know the
   exact network topology and the coding operations at intermediate
   nodes.  When multiple consumers are attempting to receive the same
   content such as live video streaming, coherent NWC could enable
   optimal throughput sending the content flow over the constructed
   optimal multicast trees [29].  However, it requires a fully
   adjustable and specific routing mechanism, and a large computational
   capacity for central coordination.  In the case of non-coherent NWC,
   that often comprises the use of Random Linear Coding (RLC), it is not
   necessary to know the network topology nor the intermediate coding
   operations [30].  As non-coherent NWC works in a completely
   independent and decentralized manner, this approach is more feasible
   especially in the large-scale use cases.

   NWC combines multiple packets together with parts of the same
   content, and may do this at the source or at other nodes in the
   network.  Network coded packets are not connected to a specific
   server, as they may have been combined within the network.  As NWC is
   focused on 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 CCNx/NDN core networking layer.  NWC has already been
   implemented for information/content dissemination [6] [7] [8].
   Montpetit, et al., first suggested that NWC techniques be exploited
   to enhance key system performances in ICN [9].  NWC provides CCNx/NDN
   with the highly beneficial potential of effectively disseminating
   information in a completely independent and decentralized manner.

   In this document, we consider how NWC can be applied to the CCNx/NDN
   architecture and describe the technical considerations and potential
   challenges for making CCNx/NDN-based communications better using the
   NWC technology.  It should be noted that the presentation of specific
   solutions (e.g., NWC optimization methods) for enhancing CCNx/NDN
   performance metrics by exploiting NWC is outside the scope of this
   document.

Matsuzono, et al.         Expires March 6, 2021                 [Page 3]
Internet-Draft               NWC for CCN/NDN              September 2020

2.  Terminology

   This section provides the terminology definitions related to NWC and
   CCNx/NDN used in this document.

2.1.  Definitions related NWC

   The terminologies regarding NWC used in this document are defined as
   follows.  These are aligned with RFCs produced by the FEC Framework
   (FECFRAME) IETF Working Groups as well as IRTF Coding for Efficient
   Network Communications Research Group (NWCRG)[21].

   The definitions of the general terminologies used are as follows:

   o  Source Packet: A packet originating from the source that
      contributes to one or more source symbols.  The source symbol is a
      unit of data originating from the source that is used as input to
      encoding operations.  For instance, an 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 packet may contribute to various source symbols.

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

   o  Innovative Packet: A source or coded packet that increases the
      rank of the linear system (also called degrees of freedom) at a
      receiver.

   o  Encoding versus Recoding versus Decoding: Encoding is an operation
      that takes source symbols as input and produces encoding symbols
      (source or coded symbols) as output.  Recoding is an operation
      that takes encoding symbols as input and produces encoding symbols
      as output.  Decoding is an operation takes encoding symbols as
      input and produces source symbols as output.

   The terminology definitions regarding coding types are as follows:

   o  Random Linear Coding (RLC): Particular case of linear coding using
      a set of random coding coefficients.  Linear coding linearly
      combines a set of input source and/or coded symbols using a given
      set of coefficients and resulting in a coded symbol.  Many linear
      codes exist that differ from the way coding coefficients are drawn
      from a finite field of a given size.

Matsuzono, et al.         Expires March 6, 2021                 [Page 4]
Internet-Draft               NWC for CCN/NDN              September 2020

   o  Block Coding: Coding technique wherein the input flow(s) must be
      first segmented into a sequence of blocks; encoding and decoding
      are performed independently on a per-block basis.

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

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

   The terminology definitions regarding low-level coding aspects are as
   follows:

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

   o  Generation, or Block: With block codes, the set of source symbols
      of the input flow(s) that are logically grouped into a block,
      before doing encoding.

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

   o  Generation ID, or Block ID: With block codes, the identifier of a
      block to which source and coded symbols belong.  It is also known
      as "Source Block Number (SBN)".

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

Matsuzono, et al.         Expires March 6, 2021                 [Page 5]
Internet-Draft               NWC for CCN/NDN              September 2020

   o  Coding Vector: 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
      desired property of having all elements (except zero) invertible
      for + and * and all operations over any elements do not result in
      an overflow or underflow.  Examples of finite fields are prime
      fields {0..p^m-1}, where p is prime.  Most used fields use p=2 and
      are called binary extension fields {0..2^m-1}, where m often
      equals 1, 4 or 8 for practical reasons.

   o  Finite Field size: The number of elements in a finite field.  For
      example the binary extension field {0..2^m-1} has size q=2^m.

2.2.  Definitions related to CCNx/NDN

   The terminologies regarding CCNx/NDN used in this document are
   defined below.  They are consistent with the RFCs produced by the
   Information-Centric Networking (ICNRG) IRTF Working Group[1] [17].

   o  Interest: A message requesting a content object with a matching
      name and other optional selectors for selecting from multiple
      objects having the same name prefix.

   o  Content Object: A unit of content data delivered through the CCNx/
      NDN network.

   o  Consumer: A node requesting a name (i.e., content).  It initiates
      the name-based communication by sending an interest packet.

   o  Publisher: A node that provides content.  It originally creates or
      owns a content.

   o  Router: An intermediate node between the consumer and producer
      that facilitates the name-based communication by forwarding
      interest and data packets.

   o  Forwarding Information Base (FIB): A lookup table in a content
      router containing the name prefix and corresponding destination
      interface for forwarding the interest packets.

   o  Pending Interest Table (PIT): A lookup table populated by the
      interest packets containing the name prefix of the requested data,
      and the outgoing interface used to forward the received data
      packets.

   o  Content Store (CS): A storage space for a router to cache content
      objects.

Matsuzono, et al.         Expires March 6, 2021                 [Page 6]
Internet-Draft               NWC for CCN/NDN              September 2020

3.  CCNx/NDN Basics

   We briefly explain the key concepts of CCNx/NDN.  Both protocols are
   similar in principle, and also different in terms of some
   implementation choices.

   In a CCNx network, there are two types of packets at the network
   level: interest and data.  The consumer requests a content object by
   sending an interest that carries the name of the data.  One
   difference to note here between CCNx and NDN is that in CCNx [17],
   the interest is required to a full name, while in NDN [19], it may
   carry a name prefix (and receive in return any data with a name
   matching this prefix).

   Once a router receives an interest, it performs a series of lookups:
   first it checks if it has a copy of the requested content object
   available in the Content Store (CS).  If it does, it returns the
   data, and the transaction is considered to have been successfully
   completed.

   If it does not have a copy of the requested content object in the CS,
   it performs a lookup of the PIT to check if there is already an
   outgoing 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 the interest, and the interfaces from which it received
   the 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 there is already a PIT entry for this name, it is
   updated with the incoming interface of this new interest, and the
   interest is discarded.

   After the PIT lookup, the interest undergoes a FIB lookup for
   selecting an outgoing interface.  The FIB lists name prefixes and
   their corresponding forwarding interfaces in order to send the
   interface towards a router that possesses a copy of the requested
   data.

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

   Data packets carry some information for validating the data, and in
   particular, that the data is indeed that which corresponds to the
   name.  This is necessary because authentication of the object is
   crucial in CCNx/NDN.  However, this step is optional at routers in
   order to speed up the processing.

Matsuzono, et al.         Expires March 6, 2021                 [Page 7]
Internet-Draft               NWC for CCN/NDN              September 2020

   The key aspect of CCNx/NDN is that the consumer of the content does
   not establish a session with a specific server.  Indeed, the router
   or publisher that returns the content object is not aware of the
   network location of the consumer and the consumer is not aware of the
   network location of the node that provides the content.  This, in
   theory, allows the interests to follow different paths within a
   network or even to be sent over completely different networks.

4.  NWC Basics

   While the forwarding node simply relays received data packets in
   conventional IP communication networks, NWC allows the node to
   combine some data packets that are already received into one or
   several output packets to be sent.  In this section, we simply
   describe the basic operations of NWC.  Herein, we focus on RLC in a
   block coding manner that is well known as a major coding technique.

   For simplicity, let us consider an example case of end-to-end coding
   wherein a publisher and consumer perform encoding and decoding for a
   content.  This end-to-end coding is regarded as a special case of
   NWC.  The publisher splits the content into several blocks called
   generations.  Encoding and decoding are performed independently on a
   per-block (per-generation) basis.  Let us assume that each generation
   consists of K original source packets of the same size.  When the
   packets do not have the same size, zero padding is added.  In order
   to generate one coded packet within a certain generation, the
   publisher linearly combines K of the original source packets, where
   additions and multiplications are performed using a coding vector
   consisting of K coding coefficients that are randomly selected in a
   certain finite field.  The publisher may send some or all of the
   source packets as well as coded packets in the content flow (called
   systematic coding), where the coded packets (also called repair
   packets) are typically used for repairing lost source packets.

   Coded packets can also be used for performing encoding.  If the
   forwarding nodes know each coding vector and generation identifier of
   the received coded packets, they may perform an encoding operation
   (called recoding), which is the most prominent operation in NWC.

   At the consumer, decoding is performed by solving a set of linear
   equations that are represented by the coding vectors of the received
   coded packets within a certain generation.  In order to obtain all
   the source packets, the consumer requires K linearly independent
   equations.  In other words, the consumer must receive at least K
   linearly independent data packets (called innovative packets).  As
   receiving a linearly dependent data packet is not useful for
   decoding, recoding should generate and provide innovative packets.
   One of major benefits of RLC is that even for a small-sized finite

Matsuzono, et al.         Expires March 6, 2021                 [Page 8]
Internet-Draft               NWC for CCN/NDN              September 2020

   field (e.g., q=2^8), the probability of generating linearly dependent
   packets is negligible [29].

5.  Advantages of NWC and CCNx/NDN

   NWC and CCNx/NDN can contribute to effective large-scale content/
   information dissemination.  They both provide similar benefits such
   as throughput/capacity gain and robustness enhancement.  The
   difference between their approaches is that, the former considers
   content flow as algebraic information that is to be combined [20],
   while the latter focuses on the content/information itself at the
   networking layer.  Because these approaches are complementary and
   their combination would be advantageous, it is natural to combine
   them.

   The name-based communication in CCNx/NDN enables consumers to obtain
   requested content objects without establishing and maintaining
   continuous end-to-end communication channels between nodes.  This
   feature facilitates the exploitation of the in-network cache and
   multipath/multisource retrieval and also supports consumer mobility
   without the need for updating the location information/identifier
   during handover [16].  Furthermore, the name-based communication
   intrinsically supports multicast communication because identical
   interests are aggregated at the routers.

   CCNx/NDN does not provide reliable and robust content dissemination
   by default.  However, NWC can enable the CCNx/NDN transport system to
   effectively distribute and cache the data associated with multipath
   data retrieval [9].  Furthermore, NWC can contribute to improving
   both the caching performance and cache privacy that CCNx/NDN newly
   introduces at the networking layer [27].  Others also have introduced
   some use cases of the application of NWC in CCNx/NDN, such as the
   cases of content dissemination with in-network caching [10] [13]
   [14], seamless consumer mobility [11] [33], and low-latency low-loss
   video streaming [15].  In this context, it is well worth considering
   NWC integration in CCNx/NDN.

6.  Technical Considerations

   This section presents the considerations for CCNx/NDN with NWC in
   terms of network architecture and protocol.  This document focuses on
   NWC in a block coding manner.

6.1.  Content Naming

   Naming content objects is as important for CCNx/NDN as naming hosts
   is in the current-day Internet [22].  In this section, two possible
   naming schemes are presented.

Matsuzono, et al.         Expires March 6, 2021                 [Page 9]
Internet-Draft               NWC for CCN/NDN              September 2020

   Each coded packet may have a unique name as content objects (original
   source packets) has in CCNx/NDN, as PIT/CS operations typically
   require a unique name for identifying the coded packet.  As a method
   of naming a coded packet, the coding vector and the identifier of the
   generation (also called block) can be used as a part of the content
   object name.  For instance, 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/g-id/1000.  This naming scheme is simple and can
   support the delivery of coded packets with exactly the same
   operations in the PIT/CS as those for the content objects.

   If a content-naming schema such as the on presented above is used, an
   interest requesting a coded packet may have the full name including a
   generation id and coding vector (/CCNx.com/video-A/g-id/1000) or only
   the name prefix including only a generation id (/CCNx.com/video-A/
   g-id).  In the former case, exact name matching to the PIT is simply
   performed at data forwarders (as in CCNx).  The consumer is enabled
   to specify and retrieval an innovative packet necessary for the
   consumer.  This could shift the generation of the coding vector from
   the data forwarder onto the consumer.

   In the latter case, partial name matching is required at the data
   forwarders (as in the case of NDN).  As the interest with only the
   prefix name matches any coded packet with the generation ID, the
   consumer could immediately obtain an coded packet from a nearby CS
   (in-network cache) without knowing the coding vectors of the cached
   coded packets in advance.  In the case wherein coded packets in
   transit are modified by in-network recoding performed at routers, the
   consumer could also receive the modified coded packets.  However, in
   contrast to the former case, the consumer may fail to obtain
   sufficient degrees of freedom (see Section 6.2.3).  To address this
   issue, a new TLV type of interest message may be required for
   specifying further coding information in order to limit the coded
   packets to be received.  For instance, this is enabled by specifying
   the coding vectors of innovative packets for the consumer (also
   called decoding matrix) as in [9].  This extension may incur an
   interest packet of significantly increased size, and it may thus be
   useful to use compression techniques for coding vectors [24] [25].
   Without such coding information provided by the interest, the
   forwarder would be required to maintain some records regarding the
   interest packets that were satisfied previously (See Section 6.2.3).

   A coded packet may have a name that indicates that it is a coded
   packet, and move the coding information into a metadata field in the
   payload (i.e., the name includes the data type, source or coded
   packet).  This would not be beneficial for applications or services
   that may not need to understand the packet payload.  Owing to the
   possibility that multiple coded packets may have the same name, some

Matsuzono, et al.         Expires March 6, 2021                [Page 10]
Internet-Draft               NWC for CCN/NDN              September 2020

   mechanism is required for the consumer to obtain innovative packets.
   As described in Section 6.3, a mechanism for managing the multiple
   innovative packets in the CS would also be required.  In addition,
   extra computational overhead would be incurred when the payload is
   being encrypted.

6.2.  Transport

   The pull-based request--response feature of CCNx/NDN is a fundamental
   principle of its transport layer; one interest retrieves at most one
   data packet.  It is believed that it is important that this rule not
   be violated, as it would open denial-of -service (Dos) attacks, and
   thus, the following basic operation should be considered for applying
   NWC to CCNx/NDN.  Nevertheless, such security considerations should
   be addressed if this rule were to be violated.

6.2.1.  Scope of NWC

   It should be discussed whether data forwarder can perform in-network
   recoding with data packets that are being received in transit, or if
   only the data that matches an interest can be subject to NWC
   operations.  In the latter case, encoding or recoding is performed to
   generate the coded packet on an end-to-end coding basis (where one
   end is the consumer and the other end is any forwarder that is able
   to respond to the interest).  This could occur when each coded packet
   has a unique name and interest has the full name.  On the other hand,
   if interest has a partial name without any coding vector information
   or coded packets have a same name, the former case may occur;
   recoding occurs anywhere in the network where it is possible to
   modify the received coded packet and forward it.  As CCNx/NDN
   comprises mechanisms for ensuring the integrity of the data during
   transfer, in-network recoding introduces complexities in the network
   that would require the consideration of the integrity mechanisms to
   still work.  Similarly, in-network caching of coded packets at
   routers may be valuable; however, the routers would require some
   mechanisms to validate the coded packets (see Section 8).

6.2.2.  Consumer Operation

   To obtain NWC benefits (possibly associated with in-network caching),
   the consumer is required to issue interests that direct the router
   (or publisher) to forward innovative packets if available.  When
   issuing an interest specifying a unique name with g-id and the coding
   vector for a coded packet, the consumer could appropriately receive
   an innovative packet if it is available at some forwarders.  However,
   the consumer is required to know the naming structure (through a
   specific name resolution scheme for instance) in order to specify the
   exact name of the coded packet to be retrieved.  In this end-to-end

Matsuzono, et al.         Expires March 6, 2021                [Page 11]
Internet-Draft               NWC for CCN/NDN              September 2020

   coding case, if the consumer wants to adjust some coding parameters
   at the publisher, some specific scheme would be required to be used.

   Conversely, the consumer without decoding capability (e.g., specific
   sensor node) may want to receive only the source packets.  As
   described in Section 6.1, because the coded packet can have a name
   that is explicitly different from source packets, issuing interests
   for retrieving source packets is possible.  In NDN, if the interest
   has only the name prefix, as in the case of /NDN.com/file-A, without
   any selectors, a forwarder may return a matching codec packet.

6.2.3.  Router Operation

   If the router constantly responds to the incoming interests by
   returning non-innovative packets, the consumer(s) cannot decode and
   obtain the source packets for all time.  This issue could happen when
   1) incoming interests for coded packets do not specify some coding
   parameters such as the coding vectors to be used, and 2) the router
   does not have a sufficient number of linearly independent source or
   coded packets (possibly in the CS) to use for recoding.  In this
   case, the router is required to determine whether or not it can
   generate innovative packets to be forwarded to the interface(s) at
   which the interests arrived.  An approach to deal with this issue is
   that the router maintains a tally of the interests for a specific
   name, generation ID and the incoming interface(s), in order to record
   how many degrees of freedom have already been provided [10].  As such
   a scheme requires state management (and potentially timers) in
   routers, scalability and practicality should be considered.  In
   addition, some transport mechanism of in-network loss detection and
   recovery [15] [33] at router as well as a consumer-driven mechanism
   could be indispensable for enabling fast loss recovery and enhancing
   NWC gains.  After determining that an innovative packet cannot be
   provided, according to the FIB, the router relays the received
   interests to the upstream router(s) or publisher to obtain innovative
   packets.  In this context, to retrieve innovative packet effectively
   and quickly, an appropriate setting of the FIB and efficient interest
   forwarding strategies should also be considered.

   In another possible case, when receiving interests only for source
   packets, the router may attempt to decode and obtain all the source
   packets and store them (if the full cache capacity are available),
   thus enabling a faster response to the interests.  As recoding or
   decoding results in an extra computational overhead, the router is
   required to determine how to respond to receiving interests according
   to the use case (e.g., a delay-sensitive or delay-tolerant
   application) and the router situation, such as available cache space
   and computational capability.

Matsuzono, et al.         Expires March 6, 2021                [Page 12]
Internet-Draft               NWC for CCN/NDN              September 2020

6.2.4.  Publisher Operation

   Before performing NWC for specified content in CCNx/NDN, the
   publisher is responsible for splitting the overall content into small
   content objects to avoid packet fragmentation that could cause
   unnecessary packet processing and degraded throughput.  The size of
   the content objects should be within the allowable packet size in
   order to avoid packet fragmentation in CCNx/NDN network.  The
   publisher performs the encoding operation for a set of the small
   content objects, and the naming process for the coded packets.

   If the producer takes the lead in determining the used coding vectors
   and generating the coding packets, there exists two possible end-to-
   end coding cases; 1) consumers obtain the names of the coded packets
   through a certain mechanism, and send the corresponding interests
   toward the publisher to obtain the coded packets that have already
   been generated at the publisher; and 2) the publisher determines the
   coding vectors after receiving the interests specifying them.  In the
   former case, although the consumers cannot flexibly specify a coding
   vector for generating the coded packet to obtain, the latency for
   obtaining the coded packet can be reduced as compared that in the
   latter case wherein additional NWC operations are required to be
   performed after receiving the interests.  The common benefit in such
   end-to-end coding cases is that if the publisher adds a signature on
   the coded packets, data validation becomes possible throughout as in
   the case of normal CCNx/NDN operations.  According to the application
   requirement for latency, such an NWC operation strategy should be
   considered.

6.2.5.  Backward Compatibility

   NWC operations should be applied in addition to the regular network
   behavior.  Hence, nodes should be able to not support network coding
   (not only in forwarding the packets, but also in the caching
   mechanism).  NWC operations should function alongside regular network
   operations.  An NWC framework should be compatible with a regular
   framework in order to facilitate backward compatibility and smooth
   migration from one framework to the other.

6.3.  In-network Caching

   Caching is a useful technique used for improving throughput and
   latency in various applications.  In-network caching in CCNx/NDN
   essentially provides support at network level and is highly
   beneficial owing to the involved exploitation of NWC for enabling
   effective multicast transmission [34], multipath data retrieval [10]
   [11], fast loss recovery [15].  However, there remain several issues
   to be considered.

Matsuzono, et al.         Expires March 6, 2021                [Page 13]
Internet-Draft               NWC for CCN/NDN              September 2020

   There generally exist limitations in the CS capacity, and the caching
   policy affects the consumer's performances [26] [31] [32].  It is
   thus crucial for routers to determine which content objects should be
   cached and discarded.  As delay-sensitive applications often do not
   require an in-network cache for a long period owing to their real-
   time constraints, routers have to know the necessity for caching
   received content objects to save the caching volume.  In CCNx, this
   could be made possible by setting a Recommended Cache Time (RCT) in
   the optional header of the data packet at the publisher side.  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 router
   recognizes that caching the content object is meaningless.
   Conversely, the router may cache it when the RCT has a greater value.
   In NDN, the TLV type of FreshnessPeriod could be used.

   One key aspect of in-network caching is whether or not routers can
   cache coded packets in their CS.  They may be caching the coded
   packets without having the ability to perform a validation of the
   content objects.  Therefore, the caching of the coded packets would
   require some mechanism to validate the coded packets (see Section 8).
   In the case wherein the coded packets have the same name, it would
   also require some mechanism to identify them.

6.4.  Seamless Consumer Mobility

   A key feature of CCNx/NDN is that it is sessionless, which enables
   the consumer and router to send multiple interests to different
   copies of the content in parallel, by using multiple interfaces at
   the same time in an asynchronous manner.  Through the multipath data
   retrieval, the consumer could obtain the content from multiple copies
   that are distributed while using the aggregate capacity of multiple
   interfaces used.  For the link between the consumer and the multiple
   copies, the consumer can perform a certain rate adaptation mechanism
   for video streaming [11] or congestion control for content
   acquisition [12].

   NWC adds a reliability layer network to CCNx in a distributed and
   asynchronous manner, because NWC provides a mechanism for ensuring
   that the interests sent to multiple copies of the content in parallel
   retrieve innovative packets, even in the case of packet losses on
   some of the paths/networks to these copies.  This obviously applies
   to consumer mobility events [11], wherein the consumer may connect
   between multiple access points (APs) before a consumer mobility event
   (make-before-break handoff).  In the case of such a consumer mobility
   event, the consumer is first connected to the previous AP, then to
   both the previous and next APs, and then finally only to the next
   APs.  With CCNx, the consumer only sends interests on the available
   interfaces.  By combining NWC with CCNx/NDN, the requesting of coded

Matsuzono, et al.         Expires March 6, 2021                [Page 14]
Internet-Draft               NWC for CCN/NDN              September 2020

   packets ensures that during the phase wherein it is connected to the
   previous and the next APs at the same time, it would not receive
   duplicate data, but does not miss out any content either.  The
   consumer would receive additional degrees of freedom with any
   innovative packet it receives on either interface.  From this
   perspective, an interest forwarding strategy at the consumer (and
   possibly router) for efficiently obtaining innovative packets should
   be considered for the consumer to achieve seamless consumer mobility.

7.  Challenges

   This section presents several primary challenges and research items
   to be considered when applying NWC in CCNx/NDN.

7.1.  Adoption of Convolutional Coding

   Several block coding approaches have been proposed thus far; however,
   there is still no sufficient discussion and application of the
   convolutional coding approach (e.g., sliding or elastic window
   coding) in CCNx/NDN.  Convolutional coding is often appropriate for
   situations wherein a fully or partially reliable delivery of
   continuous data flows is required, and especially when these data
   flows feature realtime constraints.  As in [36], on an end-to-end
   coding basis, it would be advantageous for continuous content flow to
   adopt sliding window coding in CCNx/NDN.  In this case, the publisher
   is required to appropriately set coding parameters and let the
   consumer know the information, and the consumer is required to send
   interest (i.e., feedback information) regarding the data reception
   and/or decoding status.  As CCNx/NDN advocates hop-by-hop
   communication, it would be worth discussing and investigating how
   convolutional coding can be applied in a hop-by-hop manner and its
   benefits.  In particular, in the case wherein in-network recoding
   could occur at routers, both the encoding window and CS management
   would be required, and the corresponding feasibility and practicality
   should be considered.

7.2.  Rate and Congestion Control

   The Addition of redundancy using repair packets may result in further
   network congestion and could adversely affect the overall throughput
   performance.  In particular, in a situation wherein fair bandwidth
   sharing is more desirable, each streaming flow must adapt to the
   network conditions to fairly consume the available link bandwidth.
   It is thus necessary that each content flow cooperatively implements
   congestion control to adjust the consumed bandwidth to stabilize the
   network condition (i.e., to achieve a low packet loss rate, delay,
   and jitter).  From this perspective, although a router-supported

Matsuzono, et al.         Expires March 6, 2021                [Page 15]
Internet-Draft               NWC for CCN/NDN              September 2020

   approach would be effective, an effective deployment scenario is
   required.

   As described in Section 6.4, NWC can contribute to seamless consumer
   mobility by obtaining innovative packets without receiving duplicated
   packets through multipath data retrieval.  It can be challenging to
   develop an effective rate and congestion control mechanism in order
   to achieve seamless consumer mobility while improving the overall
   throughput or latency by fully exploiting NWC operations.

7.3.  Security

   While CCNx/NDN introduces new security issues at the networking layer
   that are different from the IP network, such as a cache poisoning and
   pollution attack, a DoS attack using interest packets, some security
   approaches are already provided [22] [23].  The application of NWC in
   CCNx/NDN impacts the security mechanisms of CCNx/NDN.

   CCNx/NDN is designed to prevent modification of the data packets; the
   data packet for a specific name can be self-authenticated, can be
   validated on the delivery path, and may also be cached at untrusted
   routers.  NWC may bring up a security issue related to data integrity
   when performing in-network recoding, as attackers could inject
   invalid data packets, and fill the CSs at the routers with the
   invalid content objects (cache poisoning attack).  On the assumption
   that each coded packet has the valid signature, the straightforward
   approach would comprises the routers verifying the signature within
   the coded packets in transit and only transmitting and storing the
   validated coded packets.  However, as performing a signature
   verification by the routers may be infeasible at line speed, some
   mechanisms should be considered for distributing and reducing the
   load of signature verification, in order to maintain in-network cache
   benefits such as latency and network-load reduction.

   In addition, to maintain the in-network cache efficiency, routers
   with CS should take caution when caching validated coded packets.  As
   coded packets are unpopular in general use, they could be targeted by
   a cache pollution attack that requests less popular content objects
   more frequently to undermine popularity-based caching by skewing the
   content popularity.  Denial of Service (DoS) attacks may also target
   the routers and/or the publisher performing NWC in order to impose a
   higher computation load owing to the NWC operations.  NWC also offers
   a new surface of attack; if the coding vector is exposed at the
   network layer, it would have to be protected (and validated) in order
   to prevent modifications by an attacker (and allow for verification)
   on the path of the packet.

Matsuzono, et al.         Expires March 6, 2021                [Page 16]
Internet-Draft               NWC for CCN/NDN              September 2020

   On the other hand, NWC could be used to mitigate privacy issues CCNx/
   NDN introduces.  For instance, assuming that consumers can use
   multipath data retrieval and caching in CCNx/NDN with NWC, cache
   privacy and anonymity set for consumers can be improved in addition
   to caching performance owing to the diversity of the caching content
   objects along different paths.

   In this context, it can be a challenge that coping with the security
   issues as low computation overhead as possible while facilitating the
   NWC operations in CCNx/NDN.  From the perspective of both feasibility
   and practicability, more effective approaches with consideration of
   security would be required in order to accelerate the deployment of
   CCNx/NDN with NWC.

7.4.  Routing Scalability

   In CCNx/NDN, a name-based routing protocol without a resolution
   process streamlines the routing process and reduces the overall
   latency.  In IP routing, the growth in the routing table size has
   become a concern.  It is thus necessary to use a hierarchical naming
   scheme in order to improve the routing scalability by enabling the
   aggregation of the routing information.

   It is required to enable consumers to efficiently obtain innovative
   packets using multipath retrieval in a fully distributed manner, and
   thus fully leverage NWC in CCNx/NDN to improve throughput or reduce
   latency.  This would require some efficient routing mechanism to
   appropriately set the FIB and also an efficient interest forwarding
   strategy.  Such routing coordination may create routing scalability
   issues.  It would be challenging to achieve effective and scalable
   routing for interests requesting coded packets as well as to simplify
   the routing process.

8.  Security Considerations

   In-network recoding is a prominent operation of NWC; however, it may
   lead to cache poisoning attacks that inject invalid coded packets to
   the network.  To address this issue, there exist some possible
   approaches.  First, as a signature verification approach, the
   exploitation of multi-signature capability could be applied.  This
   allows not only the original content publisher but also some routers
   responsible for in-network recoding to have their own unique signing
   key.  Each router of the group signs newly generated coded packet in
   order for other nodes to be able to validate the data with the
   signature.  The CS may verify the signature within the coded packet
   before storing it to avoid invalid data caching.  Second, as a
   consumer-dependent approach, the consumer puts a restriction on the
   matching rule using only the name of the requested data.  The

Matsuzono, et al.         Expires March 6, 2021                [Page 17]
Internet-Draft               NWC for CCN/NDN              September 2020

   interest ambiguity can be clarified by specifying both the name and
   the key identifier (the publisher's public key digest) used for
   matching to the requested data.  This KeyId restriction is built in
   the CCNx design [1].  Only the requested data packet satisfying the
   interest with the KeyId restriction would be forwarded and stored in
   the CS, thus resulting in a reduction in the chances of cache
   poisoning.  Moreover, in the CCNx design, there exists the rule that
   the CS obeys in order to avoid amplifying invalid data; if an
   interest has a KeyID restriction, the CS must not reply unless it
   knows that the signature on the matching content object is correct.
   If the CS cannot verify the signature, the interest may be treated as
   a cache miss and forwarded to the upstream router(s).  Third, as a
   certificate chain management approach (possibly without certificate
   authority), HopAuth could be used to establish a trustworthy data
   delivery path [28].  This approach adopts the hop-by-hop
   authentication mechanism, wherein forwarding-integrated hop-by-hop
   certificate collection is performed to provide suspension certificate
   chains such that the data retrieval is trustworthy.

   Routers should also take caution when storing and retaining the coded
   packets (unpopular content objects) in the CS, as they could be
   targeted by cache pollution attacks.  In order to mitigate the cache
   pollution attacks' impact on the in-network cache efficiency, the
   routers could check the request frequencies and store the coded
   packets with certain popularity to prevent the attacks.  In addition,
   they could periodically evaluate the popularity or other properties
   of the cached content that are applied to the cache replacement
   mechanism.

   The routers or publishers require careful attention to the DoS
   attacks aiming at provoking the high load of NWC operations by using
   the interests for coded packets.  In order to mitigate such attacks,
   the routers could adopt a rate-limiting approach.  For instance, they
   could monitor the PIT size growth for coded data per content to
   detect the attacks, and limit the interest arrival rate when
   necessary.  If the NWC application wishes to secure an interest
   (considered as the NWC actuator) in order to prevent such attacks,
   the application should consider using an encrypted wrapper and an
   explicit protocol.

9.  Informative References

   [1]        Mosko, M. and et al., "Content-Centric Networking (CCNx)
              Semantics", RFC 8569, July 2019,
              <https://tools.ietf.org/html/rfc8569>.

Matsuzono, et al.         Expires March 6, 2021                [Page 18]
Internet-Draft               NWC for CCN/NDN              September 2020

   [2]        Cai, N. and R. Yeung, "Secure network coding", Proc.
              International Symposium on Information Theory
              (ISIT), IEEE, June 2002.

   [3]        Lima, L., Gheorghiu, S., Barros, J., Mdard, M., and A.
              Toledo, "Secure Network Coding for Multi-Resolution
              Wireless Video Streaming", IEEE Journal of Selected Area
              (JSAC), vol. 28, no. 3, April 2002.

   [4]        Gkantsidis, C. and P. Rodriguez, "Cooperative Security for
              Network Coding File Distribution", Proc. Infocom, IEEE,
              April 2006.

   [5]        Vilea, J., Lima, L., and J. Barros, "Lightweight security
              for network coding", Proc. ICC, IEEE, May 2008.

   [6]        Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K.
              Ramchandran, "Network Coding for Distributed Storage
              Systems", IEEE Trans. Information Theory, vol. 56, no.9,
              September 2010.

   [7]        Gkantsidis, C. and P. Rodriguez, "Network coding for large
              scale content distribution", Proc. Infocom, IEEE, March
              2005.

   [8]        Seferoglu, H. and A. Markopoulou, "Opportunistic Network
              Coding for Video Streaming over Wireless", Proc. Packet
              Video Workshop (PV), IEEE, November 2007.

   [9]        Montpetit, M., Westphal, C., and D. Trossen, "Network
              Coding Meets Information-Centric Networking: An
              Architectural Case for Information Dispersion Through
              Native Network Coding", Proc. Workshop on Emerging Name-
              Oriented Mobile Networking Design (NoM), ACM, June 2012.

   [10]       Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun,
              "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,
              "MIRCC: Multipath-aware ICN Rate-based Congestion
              Control", Proc. Conference on Information-Centric
              Networking (ICN), ACM, September 2016.

Matsuzono, et al.         Expires March 6, 2021                [Page 19]
Internet-Draft               NWC for CCN/NDN              September 2020

   [13]       Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C.
              Westphal, "An Optimal Cache Management Framework for
              Information-Centric Networks with Network Coding", Proc.
              Networking Conference, IFIP/IEEE, June 2014.

   [14]       Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C.
              Westphal, "A Minimum Cost Cache Management Framework for
              Information-Centric Networks with Network Coding",
              Computer Networks, Elsevier, August 2016.

   [15]       Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency
              Low Loss Streaming using In-Network Coding and Caching",
              Proc. Infocom, IEEE, May 2017.

   [16]       Jacobson, V., Smetters, D., Thornton, J., Plass, M.,
              Briggs, N., and R. Braynard, "Networking Named Content",
              Proc. CoNEXT, ACM, December 2009.

   [17]       Mosko, M. and et al., "Content-Centric Networking (CCNx)
              Messages in TLV Format", RFC 8609, July 2019,
              <https://tools.ietf.org/html/rfc8609>.

   [18]       Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy,
              K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang,
              "Named data networking", ACM Comput. Commun. Rev., vol.
              44, no. 3, July 2014.

   [19]       NDN Packet Format, "NDN Packet Format Specification 0.3
              documentation", Sept. 2019,
              <https://named-data.net/doc/NDN-packet-spec/current/>.

   [20]       Koetter, R. and M. Medard, "An Algebraic Approach to
              Network Coding", IEEE/ACM Trans. on Networking, vol. 11,
              no 5, Oct. 2003.

   [21]       Adamson, B. and et al., "Taxonomy of Coding Techniques for
              Efficient Network Communications", RFC 8406, June 2018,
              <https://tools.ietf.org/html/rfc8406>.

   [22]       Kutscher, D. and et al., "Information-Centric Networking
              (ICN) Research Challenges", RFC 7927, July 2016.

   [23]       Pentikousis, K. and et al., "Information-Centric
              Networking: Evaluation and Security Considerations",
              RFC 7945, July 2019.

Matsuzono, et al.         Expires March 6, 2021                [Page 20]
Internet-Draft               NWC for CCN/NDN              September 2020

   [24]       Thomos, N. and P. Frossard, "Toward one Symbol Network
              Coding Vectors", IEEE Communications letters, vol. 16, no.
              11, November 2012.

   [25]       Lucani, D., Pedersen, M., Heide, J., and F. Fitzek,
              "Fulcrum Network Codes: A Code for Fluid Allocation of
              Complexity",  available at http://arxiv.org/abs/1404.6620,
              April 2014.

   [26]       Perino, D. and M. Varvello, "A reality check for content
              centric networking", Proc. SIGCOMM Workshop on
              Information-centric networking (ICN'11), ACM, August 2011.

   [27]       Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G.
              Xie, "Privacy-Aware Multipath Video Caching for Content-
              Centric Networks", IEEE Journal of Selected Area
              (JSAC) vol. 38, no. 8, June 2016.

   [28]       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 (Early
              Access), September 2018.

   [29]       Wu, Y., Chou, P., and K. Jain, "A comparison of network
              coding and tree packing", Proc. ISIT, IEEE, June 2004.

   [30]       Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D.,
              Shi, M., and B. Leong, "A Random Linear Network Coding
              Approach to Multicast", IEEE Trans. Information
              Theory, vol. 52, no.10, October 2006.

   [31]       Podlipnig, S. and L. Osz, "A Survey of Web Cache
              Replacement Strategies", Proc. ACM Computing Surveys vol.
              35, no. 4, December 2003.

   [32]       Rossini, G. and D. Rossi, "Evaluating CCN multi-path
              interest forwarding strategies", Elsevier Computer
              Communication, vol.36, no. 7, April 2013.

   [33]       Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova,
              N., and X. Zeng, "Leveraging ICN In-network Control for
              Loss Detection and Recovery in Wireless Mobile networks",
              Proc. ICN ACM, September 2016.

   [34]       Ali, M. and U. Niesen, "Coding for Caching: Fundamental
              Limits and Practical Challenges", IEEE Communications
              Magazine vol. 54, no. 8, August 2016.

Matsuzono, et al.         Expires March 6, 2021                [Page 21]
Internet-Draft               NWC for CCN/NDN              September 2020

   [35]       Koetter, R. and F. Kschischang, "An algebraic approach to
              network coding", IEEE Trans. Netw. vol.11, no.5, October
              2008.

   [36]       Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and
              V. Roca, "On-the-Fly Erasure Coding for Real-Time Video
              Applications", IEEE Trans. Multimeda vol.13, no.4, August
              2011.

Authors' Addresses

   Kazuhisa Matsuzono
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan

   Email: matsuzono@nict.go.jp

   Hitoshi Asaeda
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan

   Email: asaeda@nict.go.jp

   Cedric Westphal
   Huawei
   2330 Central Expressway
   Santa Clara, California  95050
   USA

   Email: cedric.westphal@huawei.com

Matsuzono, et al.         Expires March 6, 2021                [Page 22]