idnits 2.17.1 draft-irtf-nwcrg-nwc-ccn-reqs-07.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 (October 24, 2021) is 915 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-irtf-nwcrg-coding-and-congestion-09 == Outdated reference: A later version (-05) exists of draft-irtf-icnrg-flic-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 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: April 27, 2022 C. Westphal 6 Huawei 7 October 24, 2021 9 Network Coding for Content-Centric Networking / Named Data Networking: 10 Considerations and Challenges 11 draft-irtf-nwcrg-nwc-ccn-reqs-07 13 Abstract 15 This document describes the current research outcomes in Network 16 Coding (NC) for Content-Centric Networking (CCNx) / Named Data 17 Networking (NDN), and clarifies the technical considerations and 18 potential challenges for applying NC in CCNx/NDN. This document is 19 the product of the Coding for Efficient Network Communications 20 Research Group (NWCRG) and the Information-Centric Networking 21 Research Group (ICNRG). 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 27, 2022. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Definitions related to NC . . . . . . . . . . . . . . . . 4 60 2.2. Definitions related to CCNx/NDN . . . . . . . . . . . . . 6 61 3. CCNx/NDN Basics . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. NC Basics . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 5. Advantages of NC and CCNx/NDN . . . . . . . . . . . . . . . . 8 64 6. Technical Considerations . . . . . . . . . . . . . . . . . . 9 65 6.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 11 67 6.2.1. Scope of NC . . . . . . . . . . . . . . . . . . . . . 11 68 6.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 11 69 6.2.3. Forwarder Operation . . . . . . . . . . . . . . . . . 12 70 6.2.4. Producer Operation . . . . . . . . . . . . . . . . . 13 71 6.2.5. Backward Compatibility . . . . . . . . . . . . . . . 14 72 6.3. In-network Caching . . . . . . . . . . . . . . . . . . . 14 73 6.4. Seamless Consumer Mobility . . . . . . . . . . . . . . . 15 74 7. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 7.1. Adoption of Convolutional Coding . . . . . . . . . . . . 15 76 7.2. Rate and Congestion Control . . . . . . . . . . . . . . . 16 77 7.3. Security . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 17 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 81 10. Informative References . . . . . . . . . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 84 1. Introduction 86 Information-Centric Networking (ICN) in general, and Content-Centric 87 Networking (CCNx) [16] or Named Data Networking (NDN) [19] in 88 particular, have emerged as a novel communication paradigm advocating 89 the retrieval of data based on their names. This paradigm pushes 90 content awareness into the network layer. It is expected to enable 91 consumers to obtain the content they desire in a straightforward and 92 efficient manner from the heterogenous networks they may be connected 93 to. The CCNx/NDN architecture has introduced innovative ideas and 94 has stimulated research in a variety of areas, such as in-network 95 caching, name-based routing, multipath transport, content security. 96 One key benefit of requesting content by name is that it eliminates 97 the requirement of establishing a session between the client and a 98 specific server, and the content can thereby be retrieved from 99 multiple sources. 101 In parallel, there has been a growing interest in both academia and 102 industry for better understanding the fundamental aspects of Network 103 Coding (NC) toward enhancing key system performance metrics such as 104 data throughput, robustness and reduction in the required number of 105 transmissions through connected networks, and redundant transmission 106 on broadcast or point-to-multipoint connections. NC is a technique 107 that is typically used for encoding packets to recover from lost 108 source packets at the receiver, and for effectively obtaining the 109 desired information in a fully distributed manner. In addition, NC 110 can be used for security enhancements [2] [3] [4] [5]. 112 From the perspective of the NC transport mechanism, NC can be divided 113 into two major categories: coherent NC, and non-coherent NC [39]. In 114 coherent NC, the source and destination nodes know the exact network 115 topology and the coding operations at intermediate nodes. When 116 multiple consumers are attempting to receive the same content such as 117 live video streaming, coherent NC could enable optimal throughput by 118 sending the content flow over the constructed optimal multicast trees 119 [33]. However, it requires a fully adjustable and specific routing 120 mechanism, and a large computational capacity for central 121 coordination. In the case of non-coherent NC, that often comprises 122 the use of Random Linear Coding (RLC), it is not necessary to know 123 the network topology nor the intermediate coding operations [34]. As 124 non-coherent NC works in a completely independent and decentralized 125 manner, this approach is more feasible especially in the large-scale 126 use cases. 128 NC combines multiple packets together with parts of the same content, 129 and may do this at the source or at other nodes in the network. 130 Network coded packets are not associated with a specific server, as 131 they may have been combined within the network. As NC is focused on 132 what information should be encoded in a network packet instead of the 133 specific host at which it has been generated, it is in line with the 134 architecture of the CCNx/NDN core networking layer. NC has already 135 been implemented for information/content dissemination [6] [7] [8]. 136 Montpetit, et al., first suggested that NC techniques be exploited to 137 enhance key aspects of system performance in ICN [9]. NC provides 138 CCNx/NDN with the highly beneficial potential of effectively 139 disseminating information in a completely topology independent and 140 decentralized manner. 142 In this document, we consider how NC can be applied to the CCNx/NDN 143 architecture and describe the technical considerations and potential 144 challenges for making CCNx/NDN-based communications better using the 145 NC technology. It should be noted that the presentation of specific 146 solutions (e.g., NC optimization methods) for enhancing CCNx/NDN 147 performance metrics by exploiting NC is outside the scope of this 148 document. 150 This document represents the collaborative work and consensus of the 151 Coding for Efficient Network Communications Research Group (NWCRG) 152 and the Information-Centric Networking Research Group (ICNRG). It is 153 not an IETF product and is not a standard. 155 2. Terminology 157 This section provides the terms related to NC and CCNx/NDN used in 158 this document. 160 2.1. Definitions related to NC 162 The terms regarding NC used in this document are defined as follows. 163 These are aligned with RFCs produced by the FEC Framework (FECFRAME) 164 IETF Working Groups as well as IRTF Coding for Efficient Network 165 Communications Research Group (NWCRG)[22]. 167 o Source Packet: A packet originating from the source that 168 contributes to one or more source symbols. The source symbol is a 169 unit of data originating from the source that is used as input to 170 encoding operations. For instance, a real-time transport protocol 171 (RTP) packet as a whole can constitute a source symbol. In other 172 situations (e.g., to address variable size packets), a single RTP 173 packet may contribute to various source symbols. 175 o Coded Packet, or Repair Packet: A packet containing one or more 176 coded symbols (also called repair symbol). The coded symbol is a 177 unit of data that is the result of a coding operation, applied 178 either to source symbols or (in case of re-coding) source and/or 179 coded symbols. When there is a single coded symbol per coded 180 packet, a coded symbol corresponds to a coded packet. 182 o Innovative Packet: A source or coded packet that increases the 183 rank of the linear system (also called degrees of freedom) at a 184 receiver. 186 o Encoding versus Re-coding versus Decoding: Encoding is an 187 operation that takes source symbols as input and produces encoding 188 symbols (source or coded symbols) as output. Re-coding is an 189 operation that takes encoding symbols as input and produces 190 encoding symbols as output. Decoding is an operation takes 191 encoding symbols as input and produces source symbols as output. 193 The terms regarding coding types are defined as follows: 195 o Random Linear Coding (RLC): A particular form of linear coding 196 using a set of random coding coefficients. Linear coding linearly 197 combines a set of input source and/or coded symbols using a given 198 set of coefficients and resulting in a coded symbol. Many linear 199 codes exist that differ from the way coding coefficients are drawn 200 from a finite field of a given size. 202 o Block Coding: A coding technique wherein the input flow(s) must be 203 first segmented into a sequence of blocks; encoding and decoding 204 are performed independently on a per-block basis. 206 o Sliding Window Coding or Convolutional Coding: A general class of 207 coding techniques that rely on a sliding encoding window. 208 Encoding window is a set of source (and coded in the case of re- 209 coding) symbols used as input to the coding operations. The set 210 of symbols change over time, as the encoding window slides over 211 the input flow(s). This is an alternative solution to block 212 coding. 214 o Fixed or Elastic Sliding Window Coding: A coding technique that 215 generates coded symbol(s) on the fly, from the set of source 216 symbols present in the sliding encoding window at that time, 217 usually by using linear coding. The sliding window may be either 218 of fixed size or of variable size over the time (also known as 219 "Elastic Sliding Window"). For instance, the size may depend on 220 acknowledgments sent by the receiver(s) for a particular source 221 symbol or source packet (received, decoded, or decodable). 223 The terms regarding low-level coding aspects are defined as follows: 225 o Rank of the Linear System or Degrees of Freedom: At a receiver, 226 the number of linearly independent equations of the linear system. 227 It is also known as "Degrees of Freedom". The system may be of 228 "full rank," wherein decoding is possible, or "partial rank", 229 wherein only partial decoding is possible. 231 o Generation, or Block: With block codes, the set of source symbols 232 of the input flow(s) that are logically grouped into a block, 233 before doing encoding. 235 o Generation Size, or Block Size: With block codes, the number of 236 source symbols belonging to a block. It is equivalent to the 237 number of source packets when there is a single source symbol per 238 source packet. 240 o Generation ID, or Block ID: With block codes, the identifier of a 241 block to which source and coded symbols belong. It is also known 242 as "Source Block Number (SBN)". 244 o Coding Coefficient: With linear coding, this is a coefficient in a 245 certain finite field. This coefficient may be chosen in different 246 ways: for instance, randomly, in a predefined table, or using a 247 predefined algorithm plus a seed. 249 o Coding Vector: A set of coding coefficients used to generate a 250 certain coded symbol through linear coding. 252 o Finite Field: Finite fields, used in linear codes, have the 253 desired property of having all elements (except zero) invertible 254 for + and * and no operation over any elements can result in an 255 overflow or underflow. Examples of finite fields are prime fields 256 {0..p^m-1}, where p is prime. Most used fields use p=2 and are 257 called binary extension fields {0..2^m-1}, where m often equals 1, 258 4 or 8 for practical reasons. 260 o Finite Field size: The number of elements in a finite field. For 261 example the binary extension field {0..2^m-1} has size q=2^m. 263 2.2. Definitions related to CCNx/NDN 265 The terminologies regarding CCNx/NDN used in this document are 266 defined in RFC8793 [17] produced by ICNRG. They are consistent with 267 the relevant documents ([1][18]). 269 3. CCNx/NDN Basics 271 We briefly explain the key concepts of CCNx/NDN. Both protocols are 272 similar in principle, but differ in some architecture and protocol 273 choices. 275 In a CCNx network, there are two types of packets at the network 276 level: interest and data packet (defined in Section 3.4 of [17]). 277 The term of content object, which means a unit of content data, is an 278 alias to data packet [17]. The ICN consumer (defined in Section 3.2 279 of [17]) requests a content object by sending an interest that 280 carries the name of the data. One difference to note here between 281 CCNx and NDN is that in CCNx [18], the interest is required to carry 282 a full name, while in NDN [20], it may carry a name prefix (and 283 receive in return any data with a name matching this prefix). 285 Once an ICN forwarder (defined in Section 3.2 of [17]) receives an 286 interest, it performs a series of lookups: first it checks if it has 287 a copy of the requested content object available in the Content Store 288 (CS) (defined in Section 3.3 of [17]). If it does, it returns the 289 data, and the transaction is considered to have been successfully 290 completed. 292 If it does not have a copy of the requested content object in the CS, 293 it performs a lookup of the Pending Interest Table (PIT) (defined in 294 Section 3.3 of [17]) to check if there is already an outgoing 295 interest for the same content object. If there is no such interest, 296 then it creates an entry in the PIT that lists the name included in 297 the interest, and the interfaces from which it received the interest. 298 This is later used to send the content object back, as interest 299 packets do not carry a source field that identifies the consumer. If 300 there is already a PIT entry for this name, it is updated with the 301 incoming interface of this new interest, and the interest is 302 discarded. 304 After the PIT lookup, the interest undergoes a Forwarding Information 305 Base (FIB) (defined in Section 3.3 of [17]) lookup for selecting an 306 outgoing interface. The FIB lists name prefixes and their 307 corresponding forwarding interfaces in order to send the interest 308 towards a forwarder that possesses a copy of the requested data. 310 Once a copy of the data is retrieved, it is sent back to the 311 consumer(s) using the trail of PIT entries; forwarders remove the PIT 312 state every time that an interest is satisfied, and may store the 313 data in their CS. 315 Data packets carry some information for validating the data, and in 316 particular, that the data is indeed that which corresponds to the 317 name. This is necessary because authentication of the object is 318 crucial in CCNx/NDN. However, this step is optional at forwarders in 319 order to speed up the processing. 321 The key aspect of CCNx/NDN is that the consumer of the content does 322 not establish a session with a specific server. Indeed, the 323 forwarder or producer (defined in Section 3.2 of [17]) that returns 324 the content object is not aware of the network location of the 325 consumer and the consumer is not aware of the network location of the 326 node that provides the content. This, in theory, allows the 327 interests to follow different paths within a network or even to be 328 sent over completely different networks. 330 4. NC Basics 332 While the forwarding node simply relays received data packets in 333 conventional IP communication networks, NC allows the node to combine 334 some data packets that are already received into one or several 335 output packets to be sent. In this section, we simply describe the 336 basic operations of NC. Herein, we focus on RLC in a block coding 337 manner that is well known as a major coding technique. 339 For simplicity, let us consider an example case of end-to-end coding 340 wherein a producer and consumer respectively perform encoding and 341 decoding for a content object. This end-to-end coding is regarded as 342 a special case of NC. The producer splits the content into several 343 blocks called generations. Encoding and decoding are performed 344 independently on a per-block (per-generation) basis. Let us assume 345 that each generation consists of K original source packets of the 346 same size. When the packets do not have the same size, zero padding 347 is added. In order to generate one coded packet within a certain 348 generation, the producer linearly combines K of the original source 349 packets, where additions and multiplications are performed using a 350 coding vector consisting of K coding coefficients that are randomly 351 selected in a certain finite field. The producer may respond to 352 interests to send the corresponding source packets and coded packets 353 in the content flow (called systematic coding), where the coded 354 packets (also called repair packets) are typically used for repairing 355 lost source packets. 357 Coded packets can also be used for performing encoding. If the 358 forwarding nodes know each coding vector and generation identifier of 359 the received coded packets, they may perform an encoding operation 360 (called re-coding), which is the most distinctie feature of NC 361 compared to other coding techniques. 363 At the consumer, decoding is performed by solving a set of linear 364 equations that are represented by the coding vectors of the received 365 coded packets within a certain generation. In order to obtain all 366 the source packets, the consumer requires K linearly independent 367 equations. In other words, the consumer must receive at least K 368 linearly independent data packets (called innovative packets). As 369 receiving a linearly dependent data packet is not useful for 370 decoding, re-coding should generate and provide innovative packets. 371 One of major benefits of RLC is that even for a small-sized finite 372 field (e.g., q=2^8), the probability of generating linearly dependent 373 packets is negligible [33]. 375 5. Advantages of NC and CCNx/NDN 377 Combining NC and CCNx/NDN can contribute to effective large-scale 378 content/information dissemination. They individually provide similar 379 benefits such as throughput/capacity gain and robustness enhancement. 380 The difference between their approaches is that, the former considers 381 content flow as algebraic information that is to be combined [21], 382 while the latter focuses on the content/information itself at the 383 networking layer. Because these approaches are complementary and 384 their combination would be advantageous, it is natural to combine 385 them. 387 The name-based communication in CCNx/NDN enables consumers to obtain 388 requested content objects without establishing and maintaining end- 389 to-end communication channels between nodes. This feature 390 facilitates the exploitation of the in-network cache and multipath/ 391 multisource retrieval and also supports consumer mobility without the 392 need for updating the location information/identifier during handover 393 [16]. Furthermore, the name-based communication intrinsically 394 supports multicast communication because identical interests are 395 aggregated at the forwarders. 397 NC can enable the CCNx/NDN transport system to effectively distribute 398 and cache the data associated with multipath data retrieval [9]. 399 Exploiting multipath data retrieval and in-network caching with NC 400 contributes to not only improving the cache hit rate but also 401 expanding the anonymity set of each consumer (the set of potential 402 routers that can serve a given consumer) [31]. The expansion makes 403 it difficult for adversaries to infer the content consumed by others, 404 and thus contributes to improving cache privacy. Others also have 405 introduced some use cases of the application of NC in CCNx/NDN, such 406 as the cases of content dissemination with in-network caching [10] 407 [13] [14], seamless consumer mobility [11] [37], and low-latency low- 408 loss video streaming [15]. In this context, it is well worth 409 considering NC integration in CCNx/NDN. 411 6. Technical Considerations 413 This section presents the considerations for CCNx/NDN with NC in 414 terms of network architecture and protocol. This document focuses on 415 NC when employed in a block coding manner. 417 6.1. Content Naming 419 Naming content objects is as important for CCNx/NDN as naming hosts 420 is in the current-day Internet [25]. In this section, two possible 421 naming schemes are presented. 423 Each coded packet may have a unique name as content objects (original 424 source packets) has in CCNx/NDN, as PIT/CS operations typically 425 require a unique name for identifying the coded packet. As a method 426 of naming a coded packet, the coding vector and the identifier of the 427 generation (also called block) can be used as a part of the content 428 object name. As in [10], when the generation ID is "g-id", 429 generation size is 4, and coding vector is (1,0,0,0), the name could 430 be /CCNx.com/video-A/g-id/1000. Some other identifiers and/or 431 parameters related to the encoding scheme can also be used as name 432 components. For instance, the encoding ID specifying the coding 433 scheme may be used with "enc-id" such as /CCNx.com/video-A/enc-id/ 434 g-id/1000, as defined in the FEC Framework (FECFRAME) [27]. This 435 naming scheme is simple and can support the delivery of coded packets 436 with exactly the same operations in the PIT/CS as those for the 437 content objects. 439 If a content-naming schema such as the one presented above is used, 440 an interest requesting a coded packet may have the full name 441 including a generation id and coding vector (/CCNx.com/video-A/ 442 g-id/1000) or only the name prefix including only a generation id 443 (/CCNx.com/video-A/g-id). In the former case, exact name matching to 444 the PIT is simply performed at data forwarders (as in CCNx). The 445 consumer is enabled to specify and retrieve an innovative packet 446 necessary for the consumer to decode successfully. This could shift 447 the generation of the coding vector from the data forwarder onto the 448 consumer. 450 In the latter case, partial name matching is required at the data 451 forwarders (as in the case of NDN). As the interest with only the 452 prefix name matches any coded packet with the generation ID, the 453 consumer could immediately obtain an coded packet from a nearby CS 454 (in-network cache) without knowing the coding vectors of the cached 455 coded packets in advance. In the case wherein coded packets in 456 transit are modified by in-network re-coding performed at forwarders, 457 the consumer could also receive the modified coded packets. However, 458 in contrast to the former case, the consumer may fail to obtain 459 sufficient degrees of freedom (see Section 6.2.3). To address this 460 issue, a new TLV type in an interest message may be required for 461 specifying further coding information in order to limit the coded 462 packets to be received. For instance, this is enabled by specifying 463 the coding vectors of innovative packets for the consumer (also 464 called decoding matrix) as in [9]. This extension may incur an 465 interest packet of significantly increased size, and it may thus be 466 useful to use compression techniques for coding vectors [28] [29]. 467 Without such coding information provided by the interest, the 468 forwarder would be required to maintain some records regarding the 469 interest packets that were satisfied previously (See Section 6.2.3). 471 A coded packet may have a name that indicates that it is a coded 472 packet, and move the coding information into a metadata field in the 473 payload (i.e., the name includes the data type, source or coded 474 packet). This would not be beneficial for applications or services 475 that may not need to understand the packet payload. Owing to the 476 possibility that multiple coded packets may have the same name, some 477 mechanism is required for the consumer to obtain innovative packets. 478 As described in Section 6.3, a mechanism for managing the multiple 479 innovative packets in the CS would also be required. In addition, 480 extra computational overhead would be incurred when the payload is 481 being encrypted. 483 6.2. Transport 485 The pull-based request-response feature of CCNx/NDN is a fundamental 486 principle of its transport layer; one interest retrieves at most one 487 data packet. This property prevents consumer or forwarder to inject 488 large amounts of unrequested data into the network. It is believed 489 that it is important that this rule not be violated, as 1) it would 490 open denial-of-service (DoS) attacks, 2) it invalidates existing 491 congestion control approaches following this rule, and 3) it would 492 reduce the efficiency of existing consumer mobility approaches. 493 Thus, the following basic operation should be considered for applying 494 NC to CCNx/NDN. Nevertheless, such security considerations must be 495 addressed if this rule were to be violated. 497 6.2.1. Scope of NC 499 An open question is whether data forwarder can perform in-network re- 500 coding with data packets that are being received in transit, or if 501 only the data that matches an interest can be subject to NC 502 operations. In the latter case, encoding or re-coding is performed 503 to generate the coded packet at any forwarder that is able to respond 504 to the interest. This could occur when each coded packet has a 505 unique name and interest has the full name. On the other hand, if 506 interest has a partial name without any coding vector information or 507 coded packets have a same name, the former case may occur; re-coding 508 occurs anywhere in the network where it is possible to modify the 509 received coded packet and forward it. As CCNx/NDN comprises 510 mechanisms for ensuring the integrity of the data during transfer, 511 in-network re-coding introduces complexities in the network that 512 needs consideration for the integrity mechanisms to still work. 513 Similarly, in-network caching of coded packets at forwarders may be 514 valuable; however, the forwarders would require some mechanisms to 515 validate the coded packets (see Section 8). 517 6.2.2. Consumer Operation 519 To obtain NC benefits (possibly associated with in-network caching), 520 the consumer is required to issue interests that direct the forwarder 521 (or producer) to respond with innovative packets if available. In 522 the case where each coded packet may have a unique name (as described 523 in Section 6.1), by issuing an interest specifying a unique name with 524 g-id and the coding vector for a coded packet, the consumer could 525 appropriately receive an innovative packet if it is available at some 526 forwarders. 528 In order to specify the exact name of the coded packet to be 529 retrieved, the consumer is required to know the valid naming scheme. 530 From a practical viewpoint, it is desirable for the consumer 531 application to automatically construct the right name components 532 without depending on any application specifications. To this end, 533 the consumer application may retrieve and refer to a manifest [1] 534 that enumerates the content objects including coded packets, or may 535 use some coding scheme specifier as a name component to construct the 536 name components of interests to request innovative packets. 538 Conversely, the consumer without decoding capability (e.g., specific 539 sensor node) may want to receive only the source packets. As 540 described in Section 6.1, because the coded packet can have a name 541 that is explicitly different from source packets, issuing interests 542 for retrieving source packets is possible. 544 6.2.3. Forwarder Operation 546 If the forwarder constantly responds to the incoming interests by 547 returning non-innovative packets, the consumer(s) cannot decode and 548 obtain the source packets for all time. This issue could happen when 549 1) incoming interests for coded packets do not specify some coding 550 parameters such as the coding vectors to be used, and 2) the 551 forwarder does not have a sufficient number of linearly independent 552 source or coded packets (possibly in the CS) to use for re-coding. 553 In this case, the forwarder is required to determine whether or not 554 it can generate innovative packets to be forwarded to the 555 interface(s) at which the interests arrived. An approach to deal 556 with this issue is that the forwarder maintains a tally of the 557 interests for a specific name, generation ID and the incoming 558 interface(s), in order to record how many degrees of freedom have 559 already been provided [10]. As such a scheme requires state 560 management (and potentially timers) in forwarders, scalability and 561 practicality must be considered. In addition, some transport 562 mechanism for in-network loss detection and recovery [15] [37] at 563 forwarder as well as a consumer-driven mechanism could be 564 indispensable for enabling fast loss recovery and realising NC gains. 565 If a forwarder cannot either return a matching innovative packet from 566 its local content store, nor produce on-the-fly a recoded packet that 567 is innovative, it is important that the forwarder not simply return a 568 non-innovative packet but instead do a forwarding lookup in its FIB 569 and forward the Interest toward the producer or upstream forwarder 570 that can provide an innovative packet. In this context, to retrieve 571 innovative packet effectively and quickly, an appropriate setting of 572 the FIB and efficient interest forwarding strategies should also be 573 considered. 575 In another possible case, when receiving interests only for source 576 packets, the forwarder may attempt to decode and obtain all the 577 source packets and store them (if the full cache capacity are 578 available), thus enabling a faster response to the interests. As re- 579 coding or decoding results in an extra computational overhead, the 580 forwarder is required to determine how to respond to received 581 interests according to the use case (e.g., a delay-sensitive or 582 delay-tolerant application) and the forwarder situation, such as 583 available cache space and computational capability. 585 6.2.4. Producer Operation 587 Before performing NC for specified content in CCNx/NDN, the producer 588 is responsible for splitting the overall content into small content 589 objects to avoid packet fragmentation that could cause unnecessary 590 packet processing and degraded throughput. The size of the content 591 objects should be within the allowable packet size in order to avoid 592 packet fragmentation in CCNx/NDN network. The producer performs the 593 encoding operation for a set of the small content objects, and the 594 naming process for the coded packets. 596 If the producer takes the lead in determining what coding vectors to 597 use in generating the coding packets, there are three general 598 strategies for naming and producing the coded packets: 600 1. consumers themselves understand in detail the naming conventions 601 used for coded packets and thereby can send the corresponding 602 interests toward the producer to obtain coded packets whose 603 coding parameters have already been determined by the producer. 605 2. the producer determines the coding vectors and generates the 606 coded packets after receiving interests specifying the packets 607 the consumer wished to receive. 609 3. The naming scheme for specifying the coding vectors and 610 corresponding coded packets is explicitly represented via a 611 "Manifest" (e.g., FLIC [24]) that can be obtained by the consumer 612 and used to select among the available coding vectors and their 613 corresponding packets, and thereby send the corresponding 614 interests. 616 In the first case, although the consumers cannot flexibly specify a 617 coding vector for generating the coded packet to obtain, the latency 618 for obtaining the coded packet is less than in the latter two cases. 619 For the second case, there is a latency penalty for the additional NC 620 operations performed after receiving the interests. For the third 621 case, the coded packets to be included in the manifest must be pre- 622 computed by the producer (since the manifest references coded packets 623 by their hashes, not their names), but the producer can select which 624 to include the manifest, and produce multiple manifests either in 625 advance or on demand with different coding tradeoffs if so desired. 627 A common benefit the first two approaches to end-to-end coding is 628 that if the producer adds a signature on the coded packets, data 629 validation becomes possible throughout (as is the case with CCNx/NDN 630 operation in the absence of NC). The third approach of using a 631 manifest trades off the additional latency incurred by the need to 632 fetch the manifest against the efficiency of needing a signature only 633 on the manifest and not on each individual coded packet. 635 6.2.5. Backward Compatibility 637 NC operations should be applied in addition to the regular network 638 behavior. Hence, nodes should be able to not support network coding 639 (not only in forwarding the packets, but also in the caching 640 mechanism). NC operations should function alongside regular network 641 operations. An NC framework should be compatible with a regular 642 framework in order to facilitate backward compatibility and smooth 643 migration from one framework to the other. 645 6.3. In-network Caching 647 Caching is a useful technique used for improving throughput and 648 latency in various applications. In-network caching in CCNx/NDN 649 essentially provides support at network level and is highly 650 beneficial owing to the involved exploitation of NC for enabling 651 effective multicast transmission [38], multipath data retrieval [10] 652 [11], fast loss recovery [15]. However, there remain several issues 653 to be considered. 655 There generally exist limitations in the CS capacity, and the caching 656 policy affects the consumer's performance [30] [35] [36]. It is thus 657 crucial for forwarders to determine which content objects should be 658 cached and which discarded. As delay-sensitive applications often do 659 not require an in-network cache for a long period owing to their 660 real-time constraints, forwarders have to know the necessity for 661 caching received content objects to save the caching volume. In 662 CCNx, this could be made possible by setting a Recommended Cache Time 663 (RCT) in the optional header of the data packet at the producer side. 664 The RCT serves as a guideline for the CS cache in determining how 665 long to retain the content object. When the RCT is set as zero, the 666 forwarder recognizes that caching the content object is not useful. 667 Conversely, the forwarder may cache it when the RCT has a greater 668 value. In NDN, the TLV type of FreshnessPeriod could be used. 670 One key aspect of in-network caching is whether or not forwarders can 671 cache coded packets in their CS. They may be caching the coded 672 packets without having the ability to perform a validation of the 673 content objects. Therefore, the caching of the coded packets would 674 require some mechanism to validate the coded packets (see Section 8). 675 In the case wherein the coded packets have the same name, it would 676 also require some mechanism to identify them. 678 6.4. Seamless Consumer Mobility 680 A key feature of CCNx/NDN is that it is sessionless, which enables 681 the consumer and forwarder to send multiple interests toward 682 different copies of the content in parallel, by using multiple 683 interfaces at the same time in an asynchronous manner. Through the 684 multipath data retrieval, the consumer could obtain the content from 685 multiple copies that are distributed while using the aggregate 686 capacity of multiple interfaces. For the link between the consumer 687 and the multiple copies, the consumer can perform a certain rate 688 adaptation mechanism for video streaming [11] or congestion control 689 for content acquisition [12]. 691 NC adds a reliability layer to CCNx in a distributed and asynchronous 692 manner, because NC provides a mechanism for ensuring that the 693 interests sent to multiple copies of the content in parallel retrieve 694 innovative packets, even in the case of packet losses on some of the 695 paths/networks to these copies. This applies to consumer mobility 696 events [11], wherein the consumer could receive additional degrees of 697 freedom with any innovative packet if at least one available 698 interface exists during the mobility event. An interest forwarding 699 strategy at the consumer (and possibly forwarder) for efficiently 700 obtaining innovative packets would be required for the consumer to 701 achieve seamless consumer mobility. 703 7. Challenges 705 This section presents several primary challenges and research items 706 to be considered when applying NC in CCNx/NDN. 708 7.1. Adoption of Convolutional Coding 710 Several block coding approaches have been proposed thus far; however, 711 there is still not sufficient discussion and application of the 712 convolutional coding approach (e.g., sliding or elastic window 713 coding) in CCNx/NDN. Convolutional coding is often appropriate for 714 situations wherein a fully or partially reliable delivery of 715 continuous data flows is required, and especially when these data 716 flows feature realtime constraints. As in [40], on an end-to-end 717 coding basis, it would be advantageous for continuous content flow to 718 adopt sliding window coding in CCNx/NDN. In this case, the producer 719 is required to appropriately set coding parameters and let the 720 consumer know the information, and the consumer is required to send 721 interests augmented with feedback information regarding the data 722 reception and/or decoding status. As CCNx/NDN utilises hop-by-hop 723 forwarding state, it would be worth discussing and investigating how 724 convolutional coding can be applied in a hop-by-hop manner and what 725 benefits might accrue. In particular, in the case wherein in-network 726 re-coding could occur at forwarders, both the encoding window and CS 727 management would be required, and the corresponding feasibility and 728 practicality should be considered. 730 7.2. Rate and Congestion Control 732 The addition of redundancy using repair packets may result in further 733 network congestion and could adversely affect the overall throughput. 734 In particular, in a situation wherein fair bandwidth sharing is more 735 desirable, each streaming flow must adapt to the network conditions 736 to fairly consume the available link bandwidth. It is thus necessary 737 that each content flow cooperatively implement congestion control to 738 adjust the consumed bandwidth [23]. From this perspective, although 739 a forwarder-supported approach would be effective, an effective 740 deployment approach that provides benefits under partial deployment 741 is required. 743 As described in Section 6.4, NC can contribute to seamless consumer 744 mobility by obtaining innovative packets without receiving duplicated 745 packets through multipath data retrieval. It can be challenging to 746 develop an effective rate and congestion control mechanism in order 747 to achieve seamless consumer mobility while improving the overall 748 throughput or latency by fully exploiting NC operations. 750 7.3. Security 752 While CCNx/NDN introduces new security issues at the networking layer 753 that are different from the IP network, such as a cache poisoning and 754 pollution attacks, a DoS attack using interest packets, some security 755 approaches are already provided [25] [26]. The application of NC in 756 CCNx/NDN brings two potential security aspects that need to be dealt 757 with. 759 The first is in-network re-coding at forwarders. Some mechanism for 760 ensuring the integrity of the coded packets newly produced by in- 761 network re-coding is required in order for consumers or other 762 forwarders to deal with valid coded packets. To this end, there are 763 some possible approaches described in Section 8, but there may be 764 more effective method with lower complexity and computation overhead. 766 The second is that attackers maliciously request and inject coded 767 packets, which could amplify some attacks. As coded packets are 768 unpopular in general use, they could be targeted by a cache pollution 769 attack that requests less popular content objects more frequently to 770 undermine popularity-based caching by skewing the content popularity. 771 Such an attack needs to be dealt with in order to maintain the in- 772 network cache efficiency. By injecting invalid coded packets with 773 the goal of filling the CSs at the forwarders with them, the cache 774 poisoning attack could be effectual depending on the exact integrity 775 coverage on coded packets. On the assumption that each coded packet 776 has the valid signature, the straightforward approach would comprise 777 the forwarders verifying the signature within the coded packets in 778 transit and only transmitting and storing the validated coded 779 packets. However, as performing a signature verification by the 780 forwarders may be infeasible at line speed, some mechanisms should be 781 considered for distributing and reducing the load of signature 782 verification, in order to maintain in-network cache benefits such as 783 latency and network-load reduction. 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 To realize the benefits of NC, consumers need to efficiently obtain 795 innovative packets using multipath retrieval mechanisms of CCNx/NDN. 796 This would require some efficient routing mechanism to appropriately 797 set the FIB and also an efficient interest forwarding strategy. Such 798 routing coordination may create routing scalability issues. It would 799 be challenging to achieve effective and scalable routing for 800 interests requesting coded packets as well as to simplify the routing 801 process. 803 8. Security Considerations 805 In-network re-coding is a distinguishing feature of NC. Only valid 806 coded packets produced by in-network re-coding must be requested and 807 utilized (and possibly stored). To this end, there exist some 808 possible approaches. First, as a signature verification approach, 809 the exploitation of multi-signature capability could be applied. 810 This allows not only the original content producer but also some 811 forwarders responsible for in-network re-coding to have their own 812 unique signing key. Each forwarder of the group signs newly 813 generated coded packet in order for other nodes to be able to 814 validate the data with the signature. The CS may verify the 815 signature within the coded packet before storing it to avoid invalid 816 data caching. Second, as a consumer-dependent approach, the consumer 817 puts a restriction on the matching rule using only the name of the 818 requested data. The interest ambiguity can be clarified by 819 specifying both the name and the key identifier (the producer's 820 public key digest) used for matching to the requested data. This 821 KeyId restriction is built in the CCNx design [1]. Only the 822 requested data packet satisfying the interest with the KeyId 823 restriction would be forwarded and stored in the CS, thus resulting 824 in a reduction in the chances of cache poisoning. Moreover, in the 825 CCNx design, there exists the rule that the CS obeys in order to 826 avoid amplifying invalid data; if an interest has a KeyID 827 restriction, the CS must not reply unless it knows that the signature 828 on the matching content object is correct. If the CS cannot verify 829 the signature, the interest may be treated as a cache miss and 830 forwarded to the upstream forwarder(s). Third, as a certificate 831 chain management approach (possibly without certificate authority), 832 some mechanism such as [32] could be used to establish a trustworthy 833 data delivery path. 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 Depending on the adopted caching strategy such as cache replacement 839 policies, forwarders should also take caution when storing and 840 retaining the coded packets in the CS as they could be targeted by 841 cache pollution attacks. In order to mitigate the cache pollution 842 attacks' impact, forwarders should check the content request 843 frequencies to detect the attack and may limit requests by ignoring 844 some of the consecutive requests. The forwarders can then decide to 845 apply or change to the other cache replacement mechanism. 847 The forwarders or producers require careful attention to the DoS 848 attacks aiming at provoking the high load of NC operations by using 849 the interests for coded packets. In order to mitigate such attacks, 850 the forwarders could adopt a rate-limiting approach. For instance, 851 they could monitor the PIT size growth for coded data per content to 852 detect the attacks, and limit the interest arrival rate when 853 necessary. If the NC application wishes to secure an interest 854 (considered as the NC actuator) in order to prevent such attacks, the 855 application should consider using an encrypted wrapper and an 856 explicit protocol. 858 9. Acknowledgements 860 The authors would like to thank ICNRG and NWCRG members, especially 861 Marie-Jose Montpetit, David Oran, Vincent Roca, and Thierry Turletti, 862 for their valuable comments and suggestions on this document. 864 10. Informative References 866 [1] Mosko, M. and et al., "Content-Centric Networking (CCNx) 867 Semantics", RFC 8569, July 2019, 868 . 870 [2] Cai, N. and R. Yeung, "Secure network coding", Proc. 871 International Symposium on Information Theory 872 (ISIT), IEEE, June 2002. 874 [3] Lima, L., Gheorghiu, S., Barros, J., Medard, M., and A. 875 Toledo, "Secure Network Coding for Multi-Resolution 876 Wireless Video Streaming", IEEE Journal of Selected Area 877 (JSAC), vol. 28, no. 3, April 2002. 879 [4] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for 880 Network Coding File Distribution", Proc. Infocom, IEEE, 881 April 2006. 883 [5] Vilea, J., Lima, L., and J. Barros, "Lightweight security 884 for network coding", Proc. ICC, IEEE, May 2008. 886 [6] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. 887 Ramchandran, "Network Coding for Distributed Storage 888 Systems", IEEE Trans. Information Theory, vol. 56, no.9, 889 September 2010. 891 [7] Gkantsidis, C. and P. Rodriguez, "Network coding for large 892 scale content distribution", Proc. Infocom, IEEE, March 893 2005. 895 [8] Seferoglu, H. and A. Markopoulou, "Opportunistic Network 896 Coding for Video Streaming over Wireless", Proc. Packet 897 Video Workshop (PV), IEEE, November 2007. 899 [9] Montpetit, M., Westphal, C., and D. Trossen, "Network 900 Coding Meets Information-Centric Networking: An 901 Architectural Case for Information Dispersion Through 902 Native Network Coding", Proc. Workshop on Emerging Name- 903 Oriented Mobile Networking Design (NoM), ACM, June 2012. 905 [10] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, 906 "NetCodCCN: a network coding approach for content-centric 907 networks", Proc. Infocom, IEEE, April 2016. 909 [11] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive 910 Video Streaming over CCN with Network Coding for Seamless 911 Mobility", Proc. International Symposium on Multimedia 912 (ISM), IEEE, December 2016. 914 [12] Mahdian, M., Arianfar, S., Gibson, J., and D. Oran, 915 "MIRCC: Multipath-aware ICN Rate-based Congestion 916 Control", Proc. Conference on Information-Centric 917 Networking (ICN), ACM, September 2016. 919 [13] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 920 Westphal, "An Optimal Cache Management Framework for 921 Information-Centric Networks with Network Coding", Proc. 922 Networking Conference, IFIP/IEEE, June 2014. 924 [14] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 925 Westphal, "A Minimum Cost Cache Management Framework for 926 Information-Centric Networks with Network Coding", 927 Computer Networks, Elsevier, August 2016. 929 [15] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency 930 Low Loss Streaming using In-Network Coding and Caching", 931 Proc. Infocom, IEEE, May 2017. 933 [16] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 934 Briggs, N., and R. Braynard, "Networking Named Content", 935 Proc. CoNEXT, ACM, December 2009. 937 [17] Wissingh, B. and et al., "Information-Centric Networking 938 (ICN): Content-Centric Networking (CCNx) and Named Data 939 Networking (NDN) Terminology", RFC 8793, June 2020, 940 . 942 [18] Mosko, M. and et al., "Content-Centric Networking (CCNx) 943 Messages in TLV Format", RFC 8609, July 2019, 944 . 946 [19] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 947 K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 948 "Named data networking", ACM Comput. Commun. Rev., vol. 949 44, no. 3, July 2014. 951 [20] NDN Packet Format, "NDN Packet Format Specification 0.3 952 documentation", Sept. 2019, 953 . 955 [21] Koetter, R. and M. Medard, "An Algebraic Approach to 956 Network Coding", IEEE/ACM Trans. on Networking, vol. 11, 957 no 5, Oct. 2003. 959 [22] Adamson, B. and et al., "Taxonomy of Coding Techniques for 960 Efficient Network Communications", RFC 8406, June 2018, 961 . 963 [23] Kuhn, N., Lochin, E., Michel, F., and M. Welzl, "Coding 964 and Congestion Control in Transport", Work in Progress, 965 draft-irtf-nwcrg-coding-and-congestion-09, June 2021. 967 [24] Tschudin, C., Wood, C., Mosko, M., and D. Oran, "File-Like 968 ICN Collections (FLIC)", Work in Progress, draft-irtf- 969 icnrg-flic-02, Nov. 2019. 971 [25] Kutscher, D. and et al., "Information-Centric Networking 972 (ICN) Research Challenges", RFC 7927, July 2016. 974 [26] Pentikousis, K. and et al., "Information-Centric 975 Networking: Evaluation and Security Considerations", 976 RFC 7945, July 2019. 978 [27] Watson, M. and et al., "Forward Error Correction (FEC) 979 Framework", RFC 6363, Oct. 2011. 981 [28] Thomos, N. and P. Frossard, "Toward one Symbol Network 982 Coding Vectors", IEEE Communications letters, vol. 16, no. 983 11, November 2012. 985 [29] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek, 986 "Fulcrum Network Codes: A Code for Fluid Allocation of 987 Complexity", available at http://arxiv.org/abs/1404.6620, 988 April 2014. 990 [30] Perino, D. and M. Varvello, "A reality check for content 991 centric networking", Proc. SIGCOMM Workshop on 992 Information-centric networking (ICN'11), ACM, August 2011. 994 [31] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. 995 Xie, "Privacy-Aware Multipath Video Caching for Content- 996 Centric Networks", IEEE Journal of Selected Area 997 (JSAC) vol. 38, no. 8, June 2016. 999 [32] Li, R., Asaeda, H., and J. Wu, "DCAuth: Data-Centric 1000 Authentication for Secure In-Network Big-Data Retrieval", 1001 IEEE Trans. on Network Science and Engineering vol. 7, no. 1002 1, September 2018. 1004 [33] Wu, Y., Chou, P., and K. Jain, "A comparison of network 1005 coding and tree packing", Proc. ISIT, IEEE, June 2004. 1007 [34] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D., 1008 Shi, M., and B. Leong, "A Random Linear Network Coding 1009 Approach to Multicast", IEEE Trans. Information 1010 Theory, vol. 52, no.10, October 2006. 1012 [35] Podlipnig, S. and L. Osz, "A Survey of Web Cache 1013 Replacement Strategies", Proc. ACM Computing Surveys vol. 1014 35, no. 4, December 2003. 1016 [36] Rossini, G. and D. Rossi, "Evaluating CCN multi-path 1017 interest forwarding strategies", Elsevier Computer 1018 Communication, vol.36, no. 7, April 2013. 1020 [37] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 1021 N., and X. Zeng, "Leveraging ICN In-network Control for 1022 Loss Detection and Recovery in Wireless Mobile networks", 1023 Proc. ICN ACM, September 2016. 1025 [38] Ali, M. and U. Niesen, "Coding for Caching: Fundamental 1026 Limits and Practical Challenges", IEEE Communications 1027 Magazine vol. 54, no. 8, August 2016. 1029 [39] Koetter, R. and F. Kschischang, "An algebraic approach to 1030 network coding", IEEE Trans. Netw. vol.11, no.5, October 1031 2008. 1033 [40] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 1034 V. Roca, "On-the-Fly Erasure Coding for Real-Time Video 1035 Applications", IEEE Trans. Multimeda vol.13, no.4, August 1036 2011. 1038 Authors' Addresses 1040 Kazuhisa Matsuzono 1041 National Institute of Information and Communications Technology 1042 4-2-1 Nukui-Kitamachi 1043 Koganei, Tokyo 184-8795 1044 Japan 1046 Email: matsuzono@nict.go.jp 1047 Hitoshi Asaeda 1048 National Institute of Information and Communications Technology 1049 4-2-1 Nukui-Kitamachi 1050 Koganei, Tokyo 184-8795 1051 Japan 1053 Email: asaeda@nict.go.jp 1055 Cedric Westphal 1056 Huawei 1057 2330 Central Expressway 1058 Santa Clara, California 95050 1059 USA 1061 Email: cedric.westphal@futurewei.com,