idnits 2.17.1 draft-irtf-nwcrg-nwc-ccn-reqs-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2, 2020) is 1325 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Coding Research Group K. Matsuzono 3 Internet-Draft H. Asaeda 4 Intended status: Informational NICT 5 Expires: March 6, 2021 C. Westphal 6 Huawei 7 September 2, 2020 9 Network Coding for Content-Centric Networking / Named Data Networking: 10 Considerations and Challenges 11 draft-irtf-nwcrg-nwc-ccn-reqs-04 13 Abstract 15 This document describes the current research outcomes in Network 16 Coding (NWC) for Content-Centric Networking (CCNx) / Named Data 17 Networking (NDN), and clarifies the technical considerations and 18 potential challenges for applying NWC in CCNx/NDN. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 6, 2021. 37 Copyright Notice 39 Copyright (c) 2020 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Definitions related NWC . . . . . . . . . . . . . . . . . 4 57 2.2. Definitions related to CCNx/NDN . . . . . . . . . . . . . 6 58 3. CCNx/NDN Basics . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. NWC Basics . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 5. Advantages of NWC and CCNx/NDN . . . . . . . . . . . . . . . 9 61 6. Technical Considerations . . . . . . . . . . . . . . . . . . 9 62 6.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 9 63 6.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 64 6.2.1. Scope of NWC . . . . . . . . . . . . . . . . . . . . 11 65 6.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 11 66 6.2.3. Router Operation . . . . . . . . . . . . . . . . . . 12 67 6.2.4. Publisher Operation . . . . . . . . . . . . . . . . . 13 68 6.2.5. Backward Compatibility . . . . . . . . . . . . . . . 13 69 6.3. In-network Caching . . . . . . . . . . . . . . . . . . . 13 70 6.4. Seamless Consumer Mobility . . . . . . . . . . . . . . . 14 71 7. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 7.1. Adoption of Convolutional Coding . . . . . . . . . . . . 15 73 7.2. Rate and Congestion Control . . . . . . . . . . . . . . . 15 74 7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16 75 7.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 17 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 77 9. Informative References . . . . . . . . . . . . . . . . . . . 18 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 80 1. Introduction 82 Information-Centric Networking (ICN) in general, and Content-Centric 83 Networking (CCNx) [16] or Named Data Networking (NDN) [18] in 84 particular, have emerged as a novel communication paradigm advocating 85 the retrieval of data based on their names. This paradigm pushes 86 content awareness into the network layer. It is expected to enable 87 consumers to obtain the content they desire in a straightforward and 88 efficient manner from the heterogenous networks they may be connected 89 to. The CCNx/NDN architecture has introduced innovative ideas and 90 has stimulated research in a variety of areas, such as in-network 91 caching, name-based routing, multipath transport, content security. 92 One key benefit of requesting content by name is that it eliminates 93 the requirement of establishing a session between the client and a 94 specific server, and the content can thereby be retrieved from 95 multiple sources. 97 In parallel, there has been a growing interest in both academia and 98 industry for better understanding the fundamental aspects of Network 99 Coding (NWC) toward enhancing key system-performance metrics such as 100 data throughput, robustness and reduction in the required number of 101 transmissions through connected networks, and point-to-multipoint 102 connections. NWC is a technique that is typically used for encoding 103 packets for recovering lost source packets at the receiver, and for 104 effectively obtaining the desired information in a fully distributed 105 manner. In addition, NWC can be used for security enhancements [2] 106 [3] [4] [5]. 108 From the perspective of the NWC transport mechanism, NWC can be 109 categorized into two major categories: coherent NWC, and non-coherent 110 NWC [35]. In coherent NWC, the source and destination nodes know the 111 exact network topology and the coding operations at intermediate 112 nodes. When multiple consumers are attempting to receive the same 113 content such as live video streaming, coherent NWC could enable 114 optimal throughput sending the content flow over the constructed 115 optimal multicast trees [29]. However, it requires a fully 116 adjustable and specific routing mechanism, and a large computational 117 capacity for central coordination. In the case of non-coherent NWC, 118 that often comprises the use of Random Linear Coding (RLC), it is not 119 necessary to know the network topology nor the intermediate coding 120 operations [30]. As non-coherent NWC works in a completely 121 independent and decentralized manner, this approach is more feasible 122 especially in the large-scale use cases. 124 NWC combines multiple packets together with parts of the same 125 content, and may do this at the source or at other nodes in the 126 network. Network coded packets are not connected to a specific 127 server, as they may have been combined within the network. As NWC is 128 focused on what information should be encoded in a network packet 129 instead of the specific host at which it has been generated, it is in 130 line with the CCNx/NDN core networking layer. NWC has already been 131 implemented for information/content dissemination [6] [7] [8]. 132 Montpetit, et al., first suggested that NWC techniques be exploited 133 to enhance key system performances in ICN [9]. NWC provides CCNx/NDN 134 with the highly beneficial potential of effectively disseminating 135 information in a completely independent and decentralized manner. 137 In this document, we consider how NWC can be applied to the CCNx/NDN 138 architecture and describe the technical considerations and potential 139 challenges for making CCNx/NDN-based communications better using the 140 NWC technology. It should be noted that the presentation of specific 141 solutions (e.g., NWC optimization methods) for enhancing CCNx/NDN 142 performance metrics by exploiting NWC is outside the scope of this 143 document. 145 2. Terminology 147 This section provides the terminology definitions related to NWC and 148 CCNx/NDN used in this document. 150 2.1. Definitions related NWC 152 The terminologies regarding NWC used in this document are defined as 153 follows. These are aligned with RFCs produced by the FEC Framework 154 (FECFRAME) IETF Working Groups as well as IRTF Coding for Efficient 155 Network Communications Research Group (NWCRG)[21]. 157 The definitions of the general terminologies used are as follows: 159 o Source Packet: A packet originating from the source that 160 contributes to one or more source symbols. The source symbol is a 161 unit of data originating from the source that is used as input to 162 encoding operations. For instance, an real-time transport 163 protocol (RTP) packet as a whole can constitute a source symbol. 164 In other situations (e.g., to address variable size packets), a 165 single RTP packet may contribute to various source symbols. 167 o Coded Packet, or Repair Packet: A packet containing one or more 168 coded symbols (also called repair symbol). The coded symbol is a 169 unit of data that is the result of a coding operation, applied 170 either to source symbols or (in case of recoding) source and/or 171 coded symbols. When there is a single coded symbol per coded 172 packet, a coded symbol corresponds to a coded packet. 174 o Innovative Packet: A source or coded packet that increases the 175 rank of the linear system (also called degrees of freedom) at a 176 receiver. 178 o Encoding versus Recoding versus Decoding: Encoding is an operation 179 that takes source symbols as input and produces encoding symbols 180 (source or coded symbols) as output. Recoding is an operation 181 that takes encoding symbols as input and produces encoding symbols 182 as output. Decoding is an operation takes encoding symbols as 183 input and produces source symbols as output. 185 The terminology definitions regarding coding types are as follows: 187 o Random Linear Coding (RLC): Particular case of linear coding using 188 a set of random coding coefficients. Linear coding linearly 189 combines a set of input source and/or coded symbols using a given 190 set of coefficients and resulting in a coded symbol. Many linear 191 codes exist that differ from the way coding coefficients are drawn 192 from a finite field of a given size. 194 o Block Coding: Coding technique wherein the input flow(s) must be 195 first segmented into a sequence of blocks; encoding and decoding 196 are performed independently on a per-block basis. 198 o Sliding Window Coding or Convolutional Coding: General class of 199 coding techniques that rely on a sliding encoding window. 200 Encoding window is a set of source (and coded in the case of 201 recoding) symbols used as input to the coding operations. The set 202 of symbols change over time, as the encoding window slides over 203 the input flow(s). This is an alternative solution to block 204 coding. 206 o Fixed or Elastic Sliding Window Coding: Coding technique that 207 generates coded symbol(s) on the fly, from the set of source 208 symbols present in the sliding encoding window at that time, 209 usually by using linear coding. The sliding window may be either 210 of fixed size or of variable size over the time (also known as 211 "Elastic Sliding Window"). For instance, the size may depend on 212 acknowledgments sent by the receiver(s) for a particular source 213 symbol or source packet (received, decoded, or decodable). 215 The terminology definitions regarding low-level coding aspects are as 216 follows: 218 o Rank of the Linear System or Degrees of Freedom: At a receiver, 219 the number of linearly independent equations of the linear system. 220 It is also known as "Degrees of Freedom". The system may be of 221 "full rank," wherein decoding is possible, or "partial rank", 222 wherein only partial decoding is possible. 224 o Generation, or Block: With block codes, the set of source symbols 225 of the input flow(s) that are logically grouped into a block, 226 before doing encoding. 228 o Generation Size, or Block Size: With block codes, the number of 229 source symbols belonging to a block. It is equivalent to the 230 number of source packets when there is a single source symbol per 231 source packet. 233 o Generation ID, or Block ID: With block codes, the identifier of a 234 block to which source and coded symbols belong. It is also known 235 as "Source Block Number (SBN)". 237 o Coding Coefficient: With linear coding, this is a coefficient in a 238 certain finite field. This coefficient may be chosen in different 239 ways: for instance, randomly, in a predefined table, or using a 240 predefined algorithm plus a seed. 242 o Coding Vector: A set of coding coefficients used to generate a 243 certain coded symbol through linear coding. 245 o Finite Field: Finite fields, used in linear codes, have the 246 desired property of having all elements (except zero) invertible 247 for + and * and all operations over any elements do not result in 248 an overflow or underflow. Examples of finite fields are prime 249 fields {0..p^m-1}, where p is prime. Most used fields use p=2 and 250 are called binary extension fields {0..2^m-1}, where m often 251 equals 1, 4 or 8 for practical reasons. 253 o Finite Field size: The number of elements in a finite field. For 254 example the binary extension field {0..2^m-1} has size q=2^m. 256 2.2. Definitions related to CCNx/NDN 258 The terminologies regarding CCNx/NDN used in this document are 259 defined below. They are consistent with the RFCs produced by the 260 Information-Centric Networking (ICNRG) IRTF Working Group[1] [17]. 262 o Interest: A message requesting a content object with a matching 263 name and other optional selectors for selecting from multiple 264 objects having the same name prefix. 266 o Content Object: A unit of content data delivered through the CCNx/ 267 NDN network. 269 o Consumer: A node requesting a name (i.e., content). It initiates 270 the name-based communication by sending an interest packet. 272 o Publisher: A node that provides content. It originally creates or 273 owns a content. 275 o Router: An intermediate node between the consumer and producer 276 that facilitates the name-based communication by forwarding 277 interest and data packets. 279 o Forwarding Information Base (FIB): A lookup table in a content 280 router containing the name prefix and corresponding destination 281 interface for forwarding the interest packets. 283 o Pending Interest Table (PIT): A lookup table populated by the 284 interest packets containing the name prefix of the requested data, 285 and the outgoing interface used to forward the received data 286 packets. 288 o Content Store (CS): A storage space for a router to cache content 289 objects. 291 3. CCNx/NDN Basics 293 We briefly explain the key concepts of CCNx/NDN. Both protocols are 294 similar in principle, and also different in terms of some 295 implementation choices. 297 In a CCNx network, there are two types of packets at the network 298 level: interest and data. The consumer requests a content object by 299 sending an interest that carries the name of the data. One 300 difference to note here between CCNx and NDN is that in CCNx [17], 301 the interest is required to a full name, while in NDN [19], it may 302 carry a name prefix (and receive in return any data with a name 303 matching this prefix). 305 Once a router receives an interest, it performs a series of lookups: 306 first it checks if it has a copy of the requested content object 307 available in the Content Store (CS). If it does, it returns the 308 data, and the transaction is considered to have been successfully 309 completed. 311 If it does not have a copy of the requested content object in the CS, 312 it performs a lookup of the PIT to check if there is already an 313 outgoing interest for the same content object. If there is no such 314 interest, then it creates an entry in the PIT that lists the name 315 included in the interest, and the interfaces from which it received 316 the interest. This is later used to send the content object back, as 317 interest packets do not carry a source field that identifies the 318 consumer. If there is already a PIT entry for this name, it is 319 updated with the incoming interface of this new interest, and the 320 interest is discarded. 322 After the PIT lookup, the interest undergoes a FIB lookup for 323 selecting an outgoing interface. The FIB lists name prefixes and 324 their corresponding forwarding interfaces in order to send the 325 interface towards a router that possesses a copy of the requested 326 data. 328 Once a copy of the data is retrieved, it is sent back to the 329 consumer(s) using the trail of PIT entries; routers remove the PIT 330 state every time that an interest is satisfied, and may store the 331 data in their CS. 333 Data packets carry some information for validating the data, and in 334 particular, that the data is indeed that which corresponds to the 335 name. This is necessary because authentication of the object is 336 crucial in CCNx/NDN. However, this step is optional at routers in 337 order to speed up the processing. 339 The key aspect of CCNx/NDN is that the consumer of the content does 340 not establish a session with a specific server. Indeed, the router 341 or publisher that returns the content object is not aware of the 342 network location of the consumer and the consumer is not aware of the 343 network location of the node that provides the content. This, in 344 theory, allows the interests to follow different paths within a 345 network or even to be sent over completely different networks. 347 4. NWC Basics 349 While the forwarding node simply relays received data packets in 350 conventional IP communication networks, NWC allows the node to 351 combine some data packets that are already received into one or 352 several output packets to be sent. In this section, we simply 353 describe the basic operations of NWC. Herein, we focus on RLC in a 354 block coding manner that is well known as a major coding technique. 356 For simplicity, let us consider an example case of end-to-end coding 357 wherein a publisher and consumer perform encoding and decoding for a 358 content. This end-to-end coding is regarded as a special case of 359 NWC. The publisher splits the content into several blocks called 360 generations. Encoding and decoding are performed independently on a 361 per-block (per-generation) basis. Let us assume that each generation 362 consists of K original source packets of the same size. When the 363 packets do not have the same size, zero padding is added. In order 364 to generate one coded packet within a certain generation, the 365 publisher linearly combines K of the original source packets, where 366 additions and multiplications are performed using a coding vector 367 consisting of K coding coefficients that are randomly selected in a 368 certain finite field. The publisher may send some or all of the 369 source packets as well as coded packets in the content flow (called 370 systematic coding), where the coded packets (also called repair 371 packets) are typically used for repairing lost source packets. 373 Coded packets can also be used for performing encoding. If the 374 forwarding nodes know each coding vector and generation identifier of 375 the received coded packets, they may perform an encoding operation 376 (called recoding), which is the most prominent operation in NWC. 378 At the consumer, decoding is performed by solving a set of linear 379 equations that are represented by the coding vectors of the received 380 coded packets within a certain generation. In order to obtain all 381 the source packets, the consumer requires K linearly independent 382 equations. In other words, the consumer must receive at least K 383 linearly independent data packets (called innovative packets). As 384 receiving a linearly dependent data packet is not useful for 385 decoding, recoding should generate and provide innovative packets. 386 One of major benefits of RLC is that even for a small-sized finite 387 field (e.g., q=2^8), the probability of generating linearly dependent 388 packets is negligible [29]. 390 5. Advantages of NWC and CCNx/NDN 392 NWC and CCNx/NDN can contribute to effective large-scale content/ 393 information dissemination. They both provide similar benefits such 394 as throughput/capacity gain and robustness enhancement. The 395 difference between their approaches is that, the former considers 396 content flow as algebraic information that is to be combined [20], 397 while the latter focuses on the content/information itself at the 398 networking layer. Because these approaches are complementary and 399 their combination would be advantageous, it is natural to combine 400 them. 402 The name-based communication in CCNx/NDN enables consumers to obtain 403 requested content objects without establishing and maintaining 404 continuous end-to-end communication channels between nodes. This 405 feature facilitates the exploitation of the in-network cache and 406 multipath/multisource retrieval and also supports consumer mobility 407 without the need for updating the location information/identifier 408 during handover [16]. Furthermore, the name-based communication 409 intrinsically supports multicast communication because identical 410 interests are aggregated at the routers. 412 CCNx/NDN does not provide reliable and robust content dissemination 413 by default. However, NWC can enable the CCNx/NDN transport system to 414 effectively distribute and cache the data associated with multipath 415 data retrieval [9]. Furthermore, NWC can contribute to improving 416 both the caching performance and cache privacy that CCNx/NDN newly 417 introduces at the networking layer [27]. Others also have introduced 418 some use cases of the application of NWC in CCNx/NDN, such as the 419 cases of content dissemination with in-network caching [10] [13] 420 [14], seamless consumer mobility [11] [33], and low-latency low-loss 421 video streaming [15]. In this context, it is well worth considering 422 NWC integration in CCNx/NDN. 424 6. Technical Considerations 426 This section presents the considerations for CCNx/NDN with NWC in 427 terms of network architecture and protocol. This document focuses on 428 NWC in a block coding manner. 430 6.1. Content Naming 432 Naming content objects is as important for CCNx/NDN as naming hosts 433 is in the current-day Internet [22]. In this section, two possible 434 naming schemes are presented. 436 Each coded packet may have a unique name as content objects (original 437 source packets) has in CCNx/NDN, as PIT/CS operations typically 438 require a unique name for identifying the coded packet. As a method 439 of naming a coded packet, the coding vector and the identifier of the 440 generation (also called block) can be used as a part of the content 441 object name. For instance, when the generation ID is g-id, 442 generation size is 4, and coding vector is (1,0,0,0), the name could 443 be /CCNx.com/video-A/g-id/1000. This naming scheme is simple and can 444 support the delivery of coded packets with exactly the same 445 operations in the PIT/CS as those for the content objects. 447 If a content-naming schema such as the on presented above is used, an 448 interest requesting a coded packet may have the full name including a 449 generation id and coding vector (/CCNx.com/video-A/g-id/1000) or only 450 the name prefix including only a generation id (/CCNx.com/video-A/ 451 g-id). In the former case, exact name matching to the PIT is simply 452 performed at data forwarders (as in CCNx). The consumer is enabled 453 to specify and retrieval an innovative packet necessary for the 454 consumer. This could shift the generation of the coding vector from 455 the data forwarder onto the consumer. 457 In the latter case, partial name matching is required at the data 458 forwarders (as in the case of NDN). As the interest with only the 459 prefix name matches any coded packet with the generation ID, the 460 consumer could immediately obtain an coded packet from a nearby CS 461 (in-network cache) without knowing the coding vectors of the cached 462 coded packets in advance. In the case wherein coded packets in 463 transit are modified by in-network recoding performed at routers, the 464 consumer could also receive the modified coded packets. However, in 465 contrast to the former case, the consumer may fail to obtain 466 sufficient degrees of freedom (see Section 6.2.3). To address this 467 issue, a new TLV type of interest message may be required for 468 specifying further coding information in order to limit the coded 469 packets to be received. For instance, this is enabled by specifying 470 the coding vectors of innovative packets for the consumer (also 471 called decoding matrix) as in [9]. This extension may incur an 472 interest packet of significantly increased size, and it may thus be 473 useful to use compression techniques for coding vectors [24] [25]. 474 Without such coding information provided by the interest, the 475 forwarder would be required to maintain some records regarding the 476 interest packets that were satisfied previously (See Section 6.2.3). 478 A coded packet may have a name that indicates that it is a coded 479 packet, and move the coding information into a metadata field in the 480 payload (i.e., the name includes the data type, source or coded 481 packet). This would not be beneficial for applications or services 482 that may not need to understand the packet payload. Owing to the 483 possibility that multiple coded packets may have the same name, some 484 mechanism is required for the consumer to obtain innovative packets. 485 As described in Section 6.3, a mechanism for managing the multiple 486 innovative packets in the CS would also be required. In addition, 487 extra computational overhead would be incurred when the payload is 488 being encrypted. 490 6.2. Transport 492 The pull-based request--response feature of CCNx/NDN is a fundamental 493 principle of its transport layer; one interest retrieves at most one 494 data packet. It is believed that it is important that this rule not 495 be violated, as it would open denial-of -service (Dos) attacks, and 496 thus, the following basic operation should be considered for applying 497 NWC to CCNx/NDN. Nevertheless, such security considerations should 498 be addressed if this rule were to be violated. 500 6.2.1. Scope of NWC 502 It should be discussed whether data forwarder can perform in-network 503 recoding with data packets that are being received in transit, or if 504 only the data that matches an interest can be subject to NWC 505 operations. In the latter case, encoding or recoding is performed to 506 generate the coded packet on an end-to-end coding basis (where one 507 end is the consumer and the other end is any forwarder that is able 508 to respond to the interest). This could occur when each coded packet 509 has a unique name and interest has the full name. On the other hand, 510 if interest has a partial name without any coding vector information 511 or coded packets have a same name, the former case may occur; 512 recoding occurs anywhere in the network where it is possible to 513 modify the received coded packet and forward it. As CCNx/NDN 514 comprises mechanisms for ensuring the integrity of the data during 515 transfer, in-network recoding introduces complexities in the network 516 that would require the consideration of the integrity mechanisms to 517 still work. Similarly, in-network caching of coded packets at 518 routers may be valuable; however, the routers would require some 519 mechanisms to validate the coded packets (see Section 8). 521 6.2.2. Consumer Operation 523 To obtain NWC benefits (possibly associated with in-network caching), 524 the consumer is required to issue interests that direct the router 525 (or publisher) to forward innovative packets if available. When 526 issuing an interest specifying a unique name with g-id and the coding 527 vector for a coded packet, the consumer could appropriately receive 528 an innovative packet if it is available at some forwarders. However, 529 the consumer is required to know the naming structure (through a 530 specific name resolution scheme for instance) in order to specify the 531 exact name of the coded packet to be retrieved. In this end-to-end 532 coding case, if the consumer wants to adjust some coding parameters 533 at the publisher, some specific scheme would be required to be used. 535 Conversely, the consumer without decoding capability (e.g., specific 536 sensor node) may want to receive only the source packets. As 537 described in Section 6.1, because the coded packet can have a name 538 that is explicitly different from source packets, issuing interests 539 for retrieving source packets is possible. In NDN, if the interest 540 has only the name prefix, as in the case of /NDN.com/file-A, without 541 any selectors, a forwarder may return a matching codec packet. 543 6.2.3. Router Operation 545 If the router constantly responds to the incoming interests by 546 returning non-innovative packets, the consumer(s) cannot decode and 547 obtain the source packets for all time. This issue could happen when 548 1) incoming interests for coded packets do not specify some coding 549 parameters such as the coding vectors to be used, and 2) the router 550 does not have a sufficient number of linearly independent source or 551 coded packets (possibly in the CS) to use for recoding. In this 552 case, the router is required to determine whether or not it can 553 generate innovative packets to be forwarded to the interface(s) at 554 which the interests arrived. An approach to deal with this issue is 555 that the router maintains a tally of the interests for a specific 556 name, generation ID and the incoming interface(s), in order to record 557 how many degrees of freedom have already been provided [10]. As such 558 a scheme requires state management (and potentially timers) in 559 routers, scalability and practicality should be considered. In 560 addition, some transport mechanism of in-network loss detection and 561 recovery [15] [33] at router as well as a consumer-driven mechanism 562 could be indispensable for enabling fast loss recovery and enhancing 563 NWC gains. After determining that an innovative packet cannot be 564 provided, according to the FIB, the router relays the received 565 interests to the upstream router(s) or publisher to obtain innovative 566 packets. In this context, to retrieve innovative packet effectively 567 and quickly, an appropriate setting of the FIB and efficient interest 568 forwarding strategies should also be considered. 570 In another possible case, when receiving interests only for source 571 packets, the router may attempt to decode and obtain all the source 572 packets and store them (if the full cache capacity are available), 573 thus enabling a faster response to the interests. As recoding or 574 decoding results in an extra computational overhead, the router is 575 required to determine how to respond to receiving interests according 576 to the use case (e.g., a delay-sensitive or delay-tolerant 577 application) and the router situation, such as available cache space 578 and computational capability. 580 6.2.4. Publisher Operation 582 Before performing NWC for specified content in CCNx/NDN, the 583 publisher is responsible for splitting the overall content into small 584 content objects to avoid packet fragmentation that could cause 585 unnecessary packet processing and degraded throughput. The size of 586 the content objects should be within the allowable packet size in 587 order to avoid packet fragmentation in CCNx/NDN network. The 588 publisher performs the encoding operation for a set of the small 589 content objects, and the naming process for the coded packets. 591 If the producer takes the lead in determining the used coding vectors 592 and generating the coding packets, there exists two possible end-to- 593 end coding cases; 1) consumers obtain the names of the coded packets 594 through a certain mechanism, and send the corresponding interests 595 toward the publisher to obtain the coded packets that have already 596 been generated at the publisher; and 2) the publisher determines the 597 coding vectors after receiving the interests specifying them. In the 598 former case, although the consumers cannot flexibly specify a coding 599 vector for generating the coded packet to obtain, the latency for 600 obtaining the coded packet can be reduced as compared that in the 601 latter case wherein additional NWC operations are required to be 602 performed after receiving the interests. The common benefit in such 603 end-to-end coding cases is that if the publisher adds a signature on 604 the coded packets, data validation becomes possible throughout as in 605 the case of normal CCNx/NDN operations. According to the application 606 requirement for latency, such an NWC operation strategy should be 607 considered. 609 6.2.5. Backward Compatibility 611 NWC operations should be applied in addition to the regular network 612 behavior. Hence, nodes should be able to not support network coding 613 (not only in forwarding the packets, but also in the caching 614 mechanism). NWC operations should function alongside regular network 615 operations. An NWC framework should be compatible with a regular 616 framework in order to facilitate backward compatibility and smooth 617 migration from one framework to the other. 619 6.3. In-network Caching 621 Caching is a useful technique used for improving throughput and 622 latency in various applications. In-network caching in CCNx/NDN 623 essentially provides support at network level and is highly 624 beneficial owing to the involved exploitation of NWC for enabling 625 effective multicast transmission [34], multipath data retrieval [10] 626 [11], fast loss recovery [15]. However, there remain several issues 627 to be considered. 629 There generally exist limitations in the CS capacity, and the caching 630 policy affects the consumer's performances [26] [31] [32]. It is 631 thus crucial for routers to determine which content objects should be 632 cached and discarded. As delay-sensitive applications often do not 633 require an in-network cache for a long period owing to their real- 634 time constraints, routers have to know the necessity for caching 635 received content objects to save the caching volume. In CCNx, this 636 could be made possible by setting a Recommended Cache Time (RCT) in 637 the optional header of the data packet at the publisher side. The 638 RCT serves as a guideline for the CS cache in determining how long to 639 retain the content object. When the RCT is set as zero, the router 640 recognizes that caching the content object is meaningless. 641 Conversely, the router may cache it when the RCT has a greater value. 642 In NDN, the TLV type of FreshnessPeriod could be used. 644 One key aspect of in-network caching is whether or not routers can 645 cache coded packets in their CS. They may be caching the coded 646 packets without having the ability to perform a validation of the 647 content objects. Therefore, the caching of the coded packets would 648 require some mechanism to validate the coded packets (see Section 8). 649 In the case wherein the coded packets have the same name, it would 650 also require some mechanism to identify them. 652 6.4. Seamless Consumer Mobility 654 A key feature of CCNx/NDN is that it is sessionless, which enables 655 the consumer and router to send multiple interests to different 656 copies of the content in parallel, by using multiple interfaces at 657 the same time in an asynchronous manner. Through the multipath data 658 retrieval, the consumer could obtain the content from multiple copies 659 that are distributed while using the aggregate capacity of multiple 660 interfaces used. For the link between the consumer and the multiple 661 copies, the consumer can perform a certain rate adaptation mechanism 662 for video streaming [11] or congestion control for content 663 acquisition [12]. 665 NWC adds a reliability layer network to CCNx in a distributed and 666 asynchronous manner, because NWC provides a mechanism for ensuring 667 that the interests sent to multiple copies of the content in parallel 668 retrieve innovative packets, even in the case of packet losses on 669 some of the paths/networks to these copies. This obviously applies 670 to consumer mobility events [11], wherein the consumer may connect 671 between multiple access points (APs) before a consumer mobility event 672 (make-before-break handoff). In the case of such a consumer mobility 673 event, the consumer is first connected to the previous AP, then to 674 both the previous and next APs, and then finally only to the next 675 APs. With CCNx, the consumer only sends interests on the available 676 interfaces. By combining NWC with CCNx/NDN, the requesting of coded 677 packets ensures that during the phase wherein it is connected to the 678 previous and the next APs at the same time, it would not receive 679 duplicate data, but does not miss out any content either. The 680 consumer would receive additional degrees of freedom with any 681 innovative packet it receives on either interface. From this 682 perspective, an interest forwarding strategy at the consumer (and 683 possibly router) for efficiently obtaining innovative packets should 684 be considered for the consumer to achieve seamless consumer mobility. 686 7. Challenges 688 This section presents several primary challenges and research items 689 to be considered when applying NWC in CCNx/NDN. 691 7.1. Adoption of Convolutional Coding 693 Several block coding approaches have been proposed thus far; however, 694 there is still no sufficient discussion and application of the 695 convolutional coding approach (e.g., sliding or elastic window 696 coding) in CCNx/NDN. Convolutional coding is often appropriate for 697 situations wherein a fully or partially reliable delivery of 698 continuous data flows is required, and especially when these data 699 flows feature realtime constraints. As in [36], on an end-to-end 700 coding basis, it would be advantageous for continuous content flow to 701 adopt sliding window coding in CCNx/NDN. In this case, the publisher 702 is required to appropriately set coding parameters and let the 703 consumer know the information, and the consumer is required to send 704 interest (i.e., feedback information) regarding the data reception 705 and/or decoding status. As CCNx/NDN advocates hop-by-hop 706 communication, it would be worth discussing and investigating how 707 convolutional coding can be applied in a hop-by-hop manner and its 708 benefits. In particular, in the case wherein in-network recoding 709 could occur at routers, both the encoding window and CS management 710 would be required, and the corresponding feasibility and practicality 711 should be considered. 713 7.2. Rate and Congestion Control 715 The Addition of redundancy using repair packets may result in further 716 network congestion and could adversely affect the overall throughput 717 performance. In particular, in a situation wherein fair bandwidth 718 sharing is more desirable, each streaming flow must adapt to the 719 network conditions to fairly consume the available link bandwidth. 720 It is thus necessary that each content flow cooperatively implements 721 congestion control to adjust the consumed bandwidth to stabilize the 722 network condition (i.e., to achieve a low packet loss rate, delay, 723 and jitter). From this perspective, although a router-supported 724 approach would be effective, an effective deployment scenario is 725 required. 727 As described in Section 6.4, NWC can contribute to seamless consumer 728 mobility by obtaining innovative packets without receiving duplicated 729 packets through multipath data retrieval. It can be challenging to 730 develop an effective rate and congestion control mechanism in order 731 to achieve seamless consumer mobility while improving the overall 732 throughput or latency by fully exploiting NWC operations. 734 7.3. Security 736 While CCNx/NDN introduces new security issues at the networking layer 737 that are different from the IP network, such as a cache poisoning and 738 pollution attack, a DoS attack using interest packets, some security 739 approaches are already provided [22] [23]. The application of NWC in 740 CCNx/NDN impacts the security mechanisms of CCNx/NDN. 742 CCNx/NDN is designed to prevent modification of the data packets; the 743 data packet for a specific name can be self-authenticated, can be 744 validated on the delivery path, and may also be cached at untrusted 745 routers. NWC may bring up a security issue related to data integrity 746 when performing in-network recoding, as attackers could inject 747 invalid data packets, and fill the CSs at the routers with the 748 invalid content objects (cache poisoning attack). On the assumption 749 that each coded packet has the valid signature, the straightforward 750 approach would comprises the routers verifying the signature within 751 the coded packets in transit and only transmitting and storing the 752 validated coded packets. However, as performing a signature 753 verification by the routers may be infeasible at line speed, some 754 mechanisms should be considered for distributing and reducing the 755 load of signature verification, in order to maintain in-network cache 756 benefits such as latency and network-load reduction. 758 In addition, to maintain the in-network cache efficiency, routers 759 with CS should take caution when caching validated coded packets. As 760 coded packets are unpopular in general use, they could be targeted by 761 a cache pollution attack that requests less popular content objects 762 more frequently to undermine popularity-based caching by skewing the 763 content popularity. Denial of Service (DoS) attacks may also target 764 the routers and/or the publisher performing NWC in order to impose a 765 higher computation load owing to the NWC operations. NWC also offers 766 a new surface of attack; if the coding vector is exposed at the 767 network layer, it would have to be protected (and validated) in order 768 to prevent modifications by an attacker (and allow for verification) 769 on the path of the packet. 771 On the other hand, NWC could be used to mitigate privacy issues CCNx/ 772 NDN introduces. For instance, assuming that consumers can use 773 multipath data retrieval and caching in CCNx/NDN with NWC, cache 774 privacy and anonymity set for consumers can be improved in addition 775 to caching performance owing to the diversity of the caching content 776 objects along different paths. 778 In this context, it can be a challenge that coping with the security 779 issues as low computation overhead as possible while facilitating the 780 NWC operations in CCNx/NDN. From the perspective of both feasibility 781 and practicability, more effective approaches with consideration of 782 security would be required in order to accelerate the deployment of 783 CCNx/NDN with NWC. 785 7.4. Routing Scalability 787 In CCNx/NDN, a name-based routing protocol without a resolution 788 process streamlines the routing process and reduces the overall 789 latency. In IP routing, the growth in the routing table size has 790 become a concern. It is thus necessary to use a hierarchical naming 791 scheme in order to improve the routing scalability by enabling the 792 aggregation of the routing information. 794 It is required to enable consumers to efficiently obtain innovative 795 packets using multipath retrieval in a fully distributed manner, and 796 thus fully leverage NWC in CCNx/NDN to improve throughput or reduce 797 latency. This would require some efficient routing mechanism to 798 appropriately set the FIB and also an efficient interest forwarding 799 strategy. Such routing coordination may create routing scalability 800 issues. It would be challenging to achieve effective and scalable 801 routing for interests requesting coded packets as well as to simplify 802 the routing process. 804 8. Security Considerations 806 In-network recoding is a prominent operation of NWC; however, it may 807 lead to cache poisoning attacks that inject invalid coded packets to 808 the network. To address this issue, there exist some possible 809 approaches. First, as a signature verification approach, the 810 exploitation of multi-signature capability could be applied. This 811 allows not only the original content publisher but also some routers 812 responsible for in-network recoding to have their own unique signing 813 key. Each router of the group signs newly generated coded packet in 814 order for other nodes to be able to validate the data with the 815 signature. The CS may verify the signature within the coded packet 816 before storing it to avoid invalid data caching. Second, as a 817 consumer-dependent approach, the consumer puts a restriction on the 818 matching rule using only the name of the requested data. The 819 interest ambiguity can be clarified by specifying both the name and 820 the key identifier (the publisher's public key digest) used for 821 matching to the requested data. This KeyId restriction is built in 822 the CCNx design [1]. Only the requested data packet satisfying the 823 interest with the KeyId restriction would be forwarded and stored in 824 the CS, thus resulting in a reduction in the chances of cache 825 poisoning. Moreover, in the CCNx design, there exists the rule that 826 the CS obeys in order to avoid amplifying invalid data; if an 827 interest has a KeyID restriction, the CS must not reply unless it 828 knows that the signature on the matching content object is correct. 829 If the CS cannot verify the signature, the interest may be treated as 830 a cache miss and forwarded to the upstream router(s). Third, as a 831 certificate chain management approach (possibly without certificate 832 authority), HopAuth could be used to establish a trustworthy data 833 delivery path [28]. This approach adopts the hop-by-hop 834 authentication mechanism, wherein forwarding-integrated hop-by-hop 835 certificate collection is performed to provide suspension certificate 836 chains such that the data retrieval is trustworthy. 838 Routers should also take caution when storing and retaining the coded 839 packets (unpopular content objects) in the CS, as they could be 840 targeted by cache pollution attacks. In order to mitigate the cache 841 pollution attacks' impact on the in-network cache efficiency, the 842 routers could check the request frequencies and store the coded 843 packets with certain popularity to prevent the attacks. In addition, 844 they could periodically evaluate the popularity or other properties 845 of the cached content that are applied to the cache replacement 846 mechanism. 848 The routers or publishers require careful attention to the DoS 849 attacks aiming at provoking the high load of NWC operations by using 850 the interests for coded packets. In order to mitigate such attacks, 851 the routers could adopt a rate-limiting approach. For instance, they 852 could monitor the PIT size growth for coded data per content to 853 detect the attacks, and limit the interest arrival rate when 854 necessary. If the NWC application wishes to secure an interest 855 (considered as the NWC actuator) in order to prevent such attacks, 856 the application should consider using an encrypted wrapper and an 857 explicit protocol. 859 9. Informative References 861 [1] Mosko, M. and et al., "Content-Centric Networking (CCNx) 862 Semantics", RFC 8569, July 2019, 863 . 865 [2] Cai, N. and R. Yeung, "Secure network coding", Proc. 866 International Symposium on Information Theory 867 (ISIT), IEEE, June 2002. 869 [3] Lima, L., Gheorghiu, S., Barros, J., Mdard, M., and A. 870 Toledo, "Secure Network Coding for Multi-Resolution 871 Wireless Video Streaming", IEEE Journal of Selected Area 872 (JSAC), vol. 28, no. 3, April 2002. 874 [4] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for 875 Network Coding File Distribution", Proc. Infocom, IEEE, 876 April 2006. 878 [5] Vilea, J., Lima, L., and J. Barros, "Lightweight security 879 for network coding", Proc. ICC, IEEE, May 2008. 881 [6] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. 882 Ramchandran, "Network Coding for Distributed Storage 883 Systems", IEEE Trans. Information Theory, vol. 56, no.9, 884 September 2010. 886 [7] Gkantsidis, C. and P. Rodriguez, "Network coding for large 887 scale content distribution", Proc. Infocom, IEEE, March 888 2005. 890 [8] Seferoglu, H. and A. Markopoulou, "Opportunistic Network 891 Coding for Video Streaming over Wireless", Proc. Packet 892 Video Workshop (PV), IEEE, November 2007. 894 [9] Montpetit, M., Westphal, C., and D. Trossen, "Network 895 Coding Meets Information-Centric Networking: An 896 Architectural Case for Information Dispersion Through 897 Native Network Coding", Proc. Workshop on Emerging Name- 898 Oriented Mobile Networking Design (NoM), ACM, June 2012. 900 [10] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, 901 "NetCodCCN: a network coding approach for content-centric 902 networks", Proc. Infocom, IEEE, April 2016. 904 [11] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive 905 Video Streaming over CCN with Network Coding for Seamless 906 Mobility", Proc. International Symposium on Multimedia 907 (ISM), IEEE, December 2016. 909 [12] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, 910 "MIRCC: Multipath-aware ICN Rate-based Congestion 911 Control", Proc. Conference on Information-Centric 912 Networking (ICN), ACM, September 2016. 914 [13] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 915 Westphal, "An Optimal Cache Management Framework for 916 Information-Centric Networks with Network Coding", Proc. 917 Networking Conference, IFIP/IEEE, June 2014. 919 [14] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 920 Westphal, "A Minimum Cost Cache Management Framework for 921 Information-Centric Networks with Network Coding", 922 Computer Networks, Elsevier, August 2016. 924 [15] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency 925 Low Loss Streaming using In-Network Coding and Caching", 926 Proc. Infocom, IEEE, May 2017. 928 [16] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 929 Briggs, N., and R. Braynard, "Networking Named Content", 930 Proc. CoNEXT, ACM, December 2009. 932 [17] Mosko, M. and et al., "Content-Centric Networking (CCNx) 933 Messages in TLV Format", RFC 8609, July 2019, 934 . 936 [18] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 937 K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 938 "Named data networking", ACM Comput. Commun. Rev., vol. 939 44, no. 3, July 2014. 941 [19] NDN Packet Format, "NDN Packet Format Specification 0.3 942 documentation", Sept. 2019, 943 . 945 [20] Koetter, R. and M. Medard, "An Algebraic Approach to 946 Network Coding", IEEE/ACM Trans. on Networking, vol. 11, 947 no 5, Oct. 2003. 949 [21] Adamson, B. and et al., "Taxonomy of Coding Techniques for 950 Efficient Network Communications", RFC 8406, June 2018, 951 . 953 [22] Kutscher, D. and et al., "Information-Centric Networking 954 (ICN) Research Challenges", RFC 7927, July 2016. 956 [23] Pentikousis, K. and et al., "Information-Centric 957 Networking: Evaluation and Security Considerations", 958 RFC 7945, July 2019. 960 [24] Thomos, N. and P. Frossard, "Toward one Symbol Network 961 Coding Vectors", IEEE Communications letters, vol. 16, no. 962 11, November 2012. 964 [25] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek, 965 "Fulcrum Network Codes: A Code for Fluid Allocation of 966 Complexity", available at http://arxiv.org/abs/1404.6620, 967 April 2014. 969 [26] Perino, D. and M. Varvello, "A reality check for content 970 centric networking", Proc. SIGCOMM Workshop on 971 Information-centric networking (ICN'11), ACM, August 2011. 973 [27] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. 974 Xie, "Privacy-Aware Multipath Video Caching for Content- 975 Centric Networks", IEEE Journal of Selected Area 976 (JSAC) vol. 38, no. 8, June 2016. 978 [28] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric 979 Authentication for Secure In-Network Big-Data Retrieval", 980 IEEE Trans. on Network Science and Engineering (Early 981 Access), September 2018. 983 [29] Wu, Y., Chou, P., and K. Jain, "A comparison of network 984 coding and tree packing", Proc. ISIT, IEEE, June 2004. 986 [30] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D., 987 Shi, M., and B. Leong, "A Random Linear Network Coding 988 Approach to Multicast", IEEE Trans. Information 989 Theory, vol. 52, no.10, October 2006. 991 [31] Podlipnig, S. and L. Osz, "A Survey of Web Cache 992 Replacement Strategies", Proc. ACM Computing Surveys vol. 993 35, no. 4, December 2003. 995 [32] Rossini, G. and D. Rossi, "Evaluating CCN multi-path 996 interest forwarding strategies", Elsevier Computer 997 Communication, vol.36, no. 7, April 2013. 999 [33] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 1000 N., and X. Zeng, "Leveraging ICN In-network Control for 1001 Loss Detection and Recovery in Wireless Mobile networks", 1002 Proc. ICN ACM, September 2016. 1004 [34] Ali, M. and U. Niesen, "Coding for Caching: Fundamental 1005 Limits and Practical Challenges", IEEE Communications 1006 Magazine vol. 54, no. 8, August 2016. 1008 [35] Koetter, R. and F. Kschischang, "An algebraic approach to 1009 network coding", IEEE Trans. Netw. vol.11, no.5, October 1010 2008. 1012 [36] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 1013 V. Roca, "On-the-Fly Erasure Coding for Real-Time Video 1014 Applications", IEEE Trans. Multimeda vol.13, no.4, August 1015 2011. 1017 Authors' Addresses 1019 Kazuhisa Matsuzono 1020 National Institute of Information and Communications Technology 1021 4-2-1 Nukui-Kitamachi 1022 Koganei, Tokyo 184-8795 1023 Japan 1025 Email: matsuzono@nict.go.jp 1027 Hitoshi Asaeda 1028 National Institute of Information and Communications Technology 1029 4-2-1 Nukui-Kitamachi 1030 Koganei, Tokyo 184-8795 1031 Japan 1033 Email: asaeda@nict.go.jp 1035 Cedric Westphal 1036 Huawei 1037 2330 Central Expressway 1038 Santa Clara, California 95050 1039 USA 1041 Email: cedric.westphal@huawei.com