idnits 2.17.1 draft-irtf-nwcrg-nwc-ccn-reqs-02.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 20, 2019) is 1673 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: '0' is mentioned on line 336, but not defined == Unused Reference: '30' is defined on line 829, but no explicit reference was found in the text 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: March 23, 2020 C. Westphal 6 Huawei 7 September 20, 2019 9 Network Coding for Content-Centric Networking / Named Data Networking: 10 Requirements and Challenges 11 draft-irtf-nwcrg-nwc-ccn-reqs-02 13 Abstract 15 This document describes the current research outcomes regarding 16 Network Coding (NC) for Content-Centric Networking (CCN) / Named Data 17 Networking (NDN), and clarifies the requirements and challenges for 18 applying NC into CCN/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 23, 2020. 37 Copyright Notice 39 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. NDN/CCN Background . . . . . . . . . . . . . . . . . . . 5 58 3. Advantages provided by NC and CCN/NDN . . . . . . . . . . . . 7 59 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. Content Naming . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Transport . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.2.1. Scope of Network Coding . . . . . . . . . . . . . . . 9 63 4.2.2. Consumer Operation . . . . . . . . . . . . . . . . . 9 64 4.2.3. Router Operation . . . . . . . . . . . . . . . . . . 9 65 4.2.4. Publisher Operation . . . . . . . . . . . . . . . . . 10 66 4.2.5. Backward Compatibility . . . . . . . . . . . . . . . 11 67 4.3. In-network Caching . . . . . . . . . . . . . . . . . . . 11 68 4.4. Seamless Mobility . . . . . . . . . . . . . . . . . . . . 12 69 4.5. Security and Privacy . . . . . . . . . . . . . . . . . . 12 70 5. Challenges . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 5.1. Adopting Convolutional Coding . . . . . . . . . . . . . . 13 72 5.2. Rate and Congestion Control . . . . . . . . . . . . . . . 13 73 5.3. Security and Privacy . . . . . . . . . . . . . . . . . . 14 74 5.4. Routing Scalability . . . . . . . . . . . . . . . . . . . 15 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 7.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 81 1. Introduction 83 Information-Centric Networks (ICN) in general, and Content-Centric 84 Networking (CCN) [15] or Named Data Networking (NDN) [17] in 85 particular, have emerged as a novel communication paradigm advocating 86 to retrieve data through their names. This paradigm pushes content 87 awareness into the network layer. It is expected to enable consumers 88 to obtain the content they desire in a straightforward and efficient 89 manner from the heterogenous networks they may be connected to. The 90 CCN/NDN architecture has introduced innovative ideas and has 91 stimulated research in a variety of areas, such as in-network 92 caching, name-based routing, multi-path transport, content security, 93 and so on. One key benefit of requesting content by name is that it 94 removes the need to establish a session between the client and a 95 specific server, and that content can thereby be retrieved from 96 multiple sources. 98 In parallel, there has been a growing interest from both academia and 99 industry to better understand fundamental aspects of Network Coding 100 (NC) toward enhancing key system performance metrics such as data 101 throughput, robustness and reduction in the required number of 102 transmissions through connected networks, point-to-multipoint 103 connections, etc. Typically, NC is a technique mainly used to encode 104 packets to recover lost source packets at the receiver, and to 105 effectively get the desired information in a fully distributed 106 manner. In addition, NC can be used for security enhancements [2] 107 [3] [4] [5]. 109 From the perspective of NC transport mechanism, NC is divided into 110 two major categories: one is coherent NC, and the other is non- 111 coherent NC [33]. In coherent NC, source and destination nodes 112 exactly know network topology and coding operations at intermediate 113 nodes. When multiple consumers are trying to receive the same 114 content such as live video streaming, coherent NC could enable the 115 optimal throughput by making the content flow sent over the 116 constructed optimal multicast trees [26]. However, it requires a 117 fully adjustable and specific routing mechanism, and an intense 118 computational task for central coordination. In the case of non- 119 coherent NC that often utilizes RLC, it is not required to know 120 either network topology nor intermediate coding operations [27]. 121 Since non-coherent NC works in a completely independent and 122 decentralized manner, this approach is more feasible especially in 123 the large scale use cases. 125 NC mixes multiple packets together with parts of the same content, 126 and may do this at the source or at other nodes in the network. As 127 such, network coded packets are not connected to a specific server, 128 as they may have been mixed within the network. Since NC focuses on 129 what information should be encoded in a network packet, rather than 130 the specific host where it has been generated, it is in line with the 131 CCN/NDN core networking layer. NC has already been implemented for 132 information/content dissemination (e.g. [6] [7] [8]). Montpetit, et 133 al., first suggested to exploit NC techniques to enhance key system 134 performances in ICN [9]. NC provides CCN/NDN with the highly 135 beneficial potential to effectively disseminate information in a 136 completely independent and decentralized manner. 138 In this document, we consider how NC can be applied to the CCN/NDN 139 architecture and describe the requirements and potential challenges 140 for making CCN/NDN-based communications better using the NC 141 technology. Please note that providing specific solutions (e.g., NC 142 optimization methods) to enhance CCN/NDN performance metrics by 143 exploiting NC is out of scope of this document. 145 2. Terminology 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [1]. 151 2.1. Definitions 153 The terminology regarding NC used in this document is described 154 below. It is aligned with RFCs produced by the FEC Framework 155 (FECFRAME) IETF Working Groups as well as IRTF Coding for Efficient 156 Network Communications Research Group (NWCRG)[20]. 158 o Random Linear Coding (RLC): Particular case of Linear Coding using 159 a set of random coding coefficients. 161 o Generation, or (IETF) Block: With Block Codes, the set of Source 162 Symbols of the input Flow(s) that are logically grouped into a 163 Block, before doing encoding. 165 o Generation Size, Code Dimension, or (IETF) Block Size: With Block 166 Codes, the number of Source Symbols, k, belonging to a Block. 168 o Coding Vector: A set of Coding Coefficients used to generate a 169 certain Repair Symbol through Linear Coding. The number of 170 nonzero coefficients in the Coding Vector defines its density 172 o Finite Field: Finite fields, used in Linear Codes, have the 173 desired property of having all elements (except zero) invertible 174 for + and * and all operations over any elements do not result in 175 an overflow or underflow. Examples of Finite Fields are prime 176 fields {0..p^m-1}, where p is prime. Most used fields use p=2 and 177 are called binary extension fields {0..2^m-1}, where m often 178 equals 1, 4 or 8 for practical reasons. 180 o Finite Field size: The number of elements in a finite field. For 181 example the binary extension field {0..2^m-1} has size q=2^m. 183 o Block Coding: Coding technique where the input Flow(s) must be 184 first segmented into a sequence of blocks, FEC encoding and 185 decoding being performed independently on a per-block basis. 187 o Sliding Window Coding or Convolutional Coding: General class of 188 coding techniques that rely on a sliding encoding window. This is 189 an alternative solution to Block Coding. 191 o Fixed or Elastic Sliding Window Coding: Coding technique that 192 generates repair data on-the-fly, from the set of source data 193 present in the sliding encoding window at that time, usually by 194 using Linear Coding. The sliding window may be either of fixed 195 size or of variable size over the time (also known as "elastic 196 sliding window"). 198 o Feedback: Feedback information sent by a decoding node to a node 199 (or from a consumer to a publisher in case of End-to-End Coding). 200 The nature of information contained in a feedback packet varies, 201 depending on the use-case. It can provide reception and/or 202 decoding statistics, or the list of available source packets 203 received or decoded, or the list of lost source packets that 204 should be retransmitted, or a number of additional repair packet 205 needed to have a full rank linear system. 207 Concerning CCN/NDN, the following terminology and definitions are 208 used. 210 o Consumer: A node requesting content. It initiates communication 211 by sending an interest packets. 213 o Publisher: A node providing content. It originally creates or 214 owns the content. 216 o Forwarding Information Base (FIB): A lookup table in a content 217 router containing the name prefix and corresponding destination 218 interface to forward the interest packets. 220 o Pending Interest Table (PIT): A lookup table populated by the 221 interest packets containing the name prefix of the requested data, 222 and the outgoing interface used to forward the received data 223 packets. 225 o Content Store (CS): A storage space for a router to cache content 226 objects. It is also known as in-network cache. 228 o Content Object: A unit of content data delivered through the CCN/ 229 NDN network. 231 o Content Flow: A sequence of content objects associated with the 232 unique content name prefix. 234 2.2. NDN/CCN Background 236 Armed with the terminology above, we briefly explain the key concepts 237 of CCN/NDN. Both protocols are similar in principle, and different 238 on some implementation choices. 240 In a CCN network, there are two types of packets at the network 241 level: interest and data. The consumer request a content by sending 242 an "interest" message, that carries the name of the data. On 243 difference to note here in CCN and NDN is that in CCN [16], the 244 interest must carry a full name, while in NDN [18] it may carry a 245 name prefix (and receive in return any data with a name matching this 246 prefix). 248 Once a router receives an "interest" message, it performs a series of 249 look-up: first it checks in the Content Store if it has a copy of the 250 requested content available. If it does, it returns the data and the 251 transaction has successfully completed. 253 If it does not, it performs a look-up of the PIT to see if there is 254 already an outgoing request for the same data. If there is not, then 255 it creates an entry in the PIT that lists the name included in the 256 interest, and the interfaces from which it received the interest. 257 This is used later to send the data back, since interest packets do 258 not carry a source field that identifies the requester. If there is 259 already a PIT entry for this name, then it is updated with the 260 incoming interface of this new request and the interest is discarded. 262 After the PIT look-up, the interest undergoes a FIB lookup to select 263 an outgoing interface. The FIB lists name prefixes and their 264 corresponding forwarding interfaces, to send the interface towards a 265 router that possesses a copy of the requested data. 267 Once a copy of the data is retrieved, it is sent back to the 268 requester(s) using the trail of PIT entries; intermediate nodes 269 remove the PIT state every time that an interest is satisfied, and 270 may store the data in their content store. 272 Data packets carry some information to validate the data, in 273 particular that the data is indeed the one that corresponds to the 274 name. This is required since authentication of the object is crucial 275 in CCN/NDN. However, this step is optional at intermediate routers, 276 so as to speed up the processing. 278 The key aspect of CCN/NDN is that the consumer of the content does 279 not establish a session with a specific server. Indeed, the node 280 that returns the content is not aware of the network location of the 281 requester and the requester is not aware of the network location of 282 the node that provides the content. This in theory allows the 283 interests to follow different paths within a network, or even to be 284 sent over totally different networks. 286 3. Advantages provided by NC and CCN/NDN 288 Both NC for large scale content dissemination [7] and CCN/NDN can 289 contribute to effective content/information delivery while working 290 jointly. They both bring similar benefits such as throughput/ 291 capacity gain and robustness enhancement. The difference between 292 their approaches is that, the former considers content flow as 293 algebraic information to combine [19], while the latter focuses on 294 content/information itself at the networking layer. Because these 295 approaches are complementary, it is natural to combine them. 297 The CCN/NDN core abstraction at networking layer through name makes 298 network stack simple as it enables applications to take maximum 299 advantage of multiple simultaneous connectivities due to its simpler 300 relationship with the layer 2 [15]. CCN/NDN itself, however, does 301 not provide reliable and robust content dissemination by default. 302 This requires some specific CCN/NDN transport (i.e., strategy layer) 303 [15]. NC can enable the CCN/NDN transport system to effectively 304 distribute and cache data associated with multi-path data retrieval 305 [9]. Furthermore, NC can contribute to improving both caching 306 performance and cache privacy that CCN/NDN newly poses at the 307 networking layer [25]. Others also have considered NC in CCN/NDN use 308 cases such as content dissemination with in-network caching [10] [12] 309 [13], seamless mobility [11] [31], low-latency video streaming [14], 310 etc. In this context, it should be natural that there is much room 311 for considering NC integration into CCN/NDN. 313 4. Requirements 315 This section presents the NC requirements for ICN/CCN in terms of 316 network architecture and protocol. The current document focuses on 317 NC in a block coding manner. 319 4.1. Content Naming 321 Naming content objects is as important for CCN/NDN as naming hosts is 322 for today's Internet [21]. Before performing network coding for 323 specified content in CCN/NDN, the overall content should be split 324 into small content objects to avoid packet fragmentation that could 325 cause unnecessary packet processing and degrade throughput. The size 326 of content objects should be within the allowable packet size so as 327 to avoid packet fragmentation in CCN/NDN network, and then network 328 coding should be applied into a set of the content objects. 330 Each coded packet MAY have a unique name as the original content 331 object has in CCN/NDN, since PIT/CS operations typically need a 332 unique name to identify the coded data. As a way of naming coded 333 packet, the coding vector and the identifier of generation can be 334 used as a part of the content object name [10]. For instance, when 335 the block size (also called generation size) is k and the coding 336 vector is [1,0,0,0], the name would be like /CCN.com/video-A/k/1000. 337 This naming scheme is simple and can support the delivery of coded 338 packets with exactly the same operations in the PIT/CS as for 339 original source packets. Since such a naming way enables consumer to 340 specify coded packets to receive, it could shift the generation of 341 the coding vector from the content producer onto the content 342 requester (described in Section 4.2.2). 344 If a naming schema such as above is used, it would be valuable to 345 reconsider whether Interests should carry full names (as in CCN) or 346 prefixes (as in NDN) as multiple network coded packets could match a 347 response to a specific prefix for a given generation, such as 348 /CCN.com/video-A/k. In the latter case allowing partial name 349 matching, the content requestor may not be able to obtain degrees of 350 freedom. Thus, extensions in the TLV header of the Interest would be 351 used to specify further network coding information so as to limit 352 coded packets to be received (for instance, by specifying the encoded 353 vectors the content requestor receives (also called decoding matrix) 354 as in [9]). However, it may incur a largely increased size of TLV 355 header, and thus it may be useful to use compression techniques for 356 coding vectors [22] [23]. Without such coding information, the 357 forwarding node would need to maintain some records regarding 358 interest packets sent before (described in Section 4.2.3). 360 Coded packet MAY have a name that indicates that it is a coded 361 packet, and move the coding information into a metadata field in the 362 payload (i.e., the name includes only data type, original or coded 363 packet, etc). It would not be beneficial for applications or 364 services that may not need to understand the packet payload. Due to 365 the possibility that multiple coded packets may have a same name, 366 some mechanism is needed for the content requestor to obtain 367 innovative coded packets. As described in Section 4.3, a mechanism 368 to manage the multiple innovative packets in the CS would be required 369 as well. In addition, extra computational overhead would occur when 370 the payload is being encrypted (described in Section 4.5). 372 4.2. Transport 374 The pull-based request-response feature of CCN/NDN is a fundamental 375 principle of its transport layer; one Interest retrieves at most one 376 Data packet. It is believed that it is important to not violate this 377 rule, as it would open denial of service attacks issues, and thus the 378 following basic operation should be considered to apply NC to CCN/ 379 NDN. In any case, such security considerations must be addressed if 380 this rule were to be violated. 382 4.2.1. Scope of Network Coding 384 It should be discussed whether the network can recode data packets 385 that are being received in transit, or if only the data that matches 386 an interest can be subject to network coding operations. In the 387 latter case, the network coding is performed on an end-to-end basis 388 (where one end is the consumer, and the other end is any node that is 389 able to respond to the Interest). In the former case, NC happens 390 anywhere in the network that is able to update the data. As CCN/NDN 391 has mechanisms in place to ensure the integrity of the data during 392 transfer, NC in the network introduce complexities that would require 393 special consideration for the integrity mechanisms to still work. 395 Similarly, caching of network coded packets at intermediate node may 396 be valuable, but may prevent the node caching the coded content to 397 validate the content. 399 4.2.2. Consumer Operation 401 To obtain NC benefits associated with in-network caching, consumer 402 needs to issue interests directing the router (or publisher) to 403 forward innovative coded packets if available. The reason why this 404 directive is needed is that delay-sensitive applications such as 405 live-video streaming may want to sequentially get original packets 406 rather than coded packets cached in routers due to real-time 407 constraint. As described in Section 4.1, because coded packet can 408 have a name explicitly different from original source packets, 409 issuing such an interest is possible. 411 When issuing interests specifying unique names with k and coding 412 vectors for each coded packets, consumer appropriately receives 413 innovative coded packets if they are available at some nodes and can 414 be forwarded to the consumer. However, consumer needs to know the 415 naming structure (through a specific name resolution scheme for 416 instance) in order for nodes to specify the exact name of generated 417 coded data packet to retrieve it. In the case of NC end-to-end 418 approach, if consumer want to adjust some coding parameters at 419 publisher, some specific scheme would be required. 421 4.2.3. Router Operation 423 Routers need to forward linearly independent coded packets toward 424 downstream nodes if incoming interests for coded packets does not 425 specify some coding parameters such as the coding vector to be used. 426 Routers thus need to determine whether or not they can generate 427 useful coded packets for consumers. Assuming that the size of the 428 Finite Field in use is not relatively small, re-encoding using enough 429 cached independent packets has a strong probability of making 430 independent coded packets [26]. However, without enough cached 431 packets, router needs to determine whether or not to an independent 432 coded packet can be forwarded to the interface at which the interest 433 arrived. To deal with this issue, some proposed schemes [10] require 434 that the router maintains a tally of the interests for a specific 435 name, generation and the corresponding interface, so as to know how 436 many degrees of freedom have been provided already for the NC 437 packets. Scalability and practicality of maintaining such scheme at 438 intermediate routers should be considered. In addition, some 439 transport mechanism of in-network loss detection and recovery [31] 440 [14] at router as well as consumer-driven mechanism could be 441 indispensable in order to enable fast loss recovery and enhance NC 442 gains. After determining that independent coded packet cannot be 443 provided, according to the FIB, the router relays received interests 444 to upstream nodes to receive a new original or independent coded 445 packet. In this context, to effectively and quickly retrieve 446 independent coded data, appropriately setting the FIB and efficient 447 interest forwarding strategies should be also considered. 449 In another possible case, when receiving interests for only original 450 packets, routers may try to decode and get all the original packets 451 and store them (if there are fully available cache capacity), 452 enabling faster response to the interests. Since re-encoding or 453 decoding leads to extra computational overhead, routers need to 454 determine how to response to receiving interests according to the use 455 case (e.g., delay-sensitive or delay-tolerant application) and the 456 router situation such as available cache space and computational 457 capability. 459 4.2.4. Publisher Operation 461 The procedure for splitting an overall content into small content 462 objects (described in Section 4.1) is the responsibility of the 463 original publisher. When applying NC for the content, the publisher 464 performs NC over the content objects, and naming processing for the 465 coded packets. If the producer takes the lead in determining the 466 used coding vectors and generating the coded packets, there are the 467 two possible end-to-end cases; 1) content requestors obtain the names 468 of coded packets through a certain mechanism, and send the correspond 469 interests toward the publisher to get the coded packets already 470 generated at the publisher, and 2) the publisher determines the 471 coding vectors after receiving interests specifying them. In the 472 former case, although content requestors cannot flexibly specify an 473 coding vector for generating the coded packet to retain, but the 474 latency for getting the coded data can be reduced compared to the 475 latter case where additional NC operations need after receiving 476 interests. The common benefit in such end-to-end cases is that if 477 the publisher adds signature on the coded packets, data verification 478 can be possible throughout. According to application requirement for 479 latency, such NC operation strategy should be considered. 481 4.2.5. Backward Compatibility 483 Network Coding operations should be applied in addition to the 484 regular network behavior. As such, nodes should be able to not 485 support network coding (either in forwarding the packets, but also in 486 the caching mechanism). Network Coding operations should function 487 alongside regular network operations. A network coding framework 488 should be compatible with a regular framework, so as to allow 489 backward compatibility and smooth migration from one framework to the 490 other. 492 4.3. In-network Caching 494 Caching is an essential technique to improve throughput and latency 495 in various applications. In-network caching CCN/NDN essentially 496 supports at network level is highly beneficial by exploiting NC to 497 enable effective multicast transmission [32], multipath data 498 retrieval [10] [11], fast loss recovery [14], and so on. However, 499 there are several issues to be considered. 501 As a general issue, there are limitations of cache capacity, and 502 caching policy affects on consumer's performances [24] [28] [29]. It 503 is thus highly significant for routers to determine which packets 504 should be cached and discarded. Since delay-sensitive applications 505 often do not require in-network cache for a long period due to their 506 real-time constraints, routers have to know the necessity for caching 507 received packets to save the caching volume. This could be possible 508 by putting a flag into optional header of data packets at publisher 509 side. When receiving data packets with the flag meaning no necessity 510 for cache, routers just have to forward them to downstream nodes. On 511 the other hand, when receiving original packets or coded packets 512 without the flag, router may cache them based on a specified 513 replacement policy. 515 One key aspect of in-network caching is whether or not intermediate 516 nodes can cache NC packets without first decoding them. They may be 517 caching the coded packets without having the ability to perform 518 validation of the content (described in Section 4.5). Therefore, 519 caching of coded packets would require some mechanism to validate 520 coded packets. In addition, when coded packets have a same name, it 521 would also require some mechanism to identify them. 523 4.4. Seamless Mobility 525 This subsection presents how NC can achieve seamless mobility [11] 526 [31] and clarify the requirements. A key feature of CCN/NDN is that 527 it is sessionless and that multiple interests can be sent to 528 different copies of the content in parallel. CCN/NDN enables a 529 consumer to retrieve the content from multiple copies that are 530 distributed and asynchronous. The key benefit is that the link 531 between the consumer and the multiple copies acts as a virtual 532 logical link, upon which rate adaptation mechanism (say, for video 533 streaming) can be performed. 535 In this context, NC adds a reliability layer network to CCN in a 536 distributed and asynchronous manner, because NC provides a mechanism 537 to ensure that the Interests sent to multiple copies of the content 538 in parallel retrieve innovative packets, even in the case of packet 539 losses on some of the paths/networks to these copies. This naturally 540 applies to mobility events, where the consumer may connect between 541 multiple access points before a mobility event (make-before-break 542 handoff). In such mobility event, the consumer is connected first to 543 the previous access point, then to both the previous and next access 544 points, then finally only to the next access points. With CCN, the 545 consumer only sends interests on the available interfaces. By 546 combining NC with CCN, requesting coded packets ensures that during 547 the phase where it is connected to the previous and the next APs at 548 the same time, it does not receive duplicate data, but does not miss 549 on any content either. The consumer receives additional degrees of 550 freedom with any innovative packet it receives on either interface. 551 From this point of view, an effective interest forwarding strategy 552 for obtaining innovative packets should be considered for consumer to 553 achieve seamless mobility. 555 4.5. Security and Privacy 557 This subsection describes the requirement for security and privacy 558 provided by NC in CCN/NDN, such as data integrity especially when 559 intermediate nodes perform re-encoding, as in the case of hash 560 restrictions for original data packets, and so on. 562 Network coding impacts the security mechanisms of CCN/NDN. In 563 particular, CCN/NDN is designed to prevent modification of the Data 564 packets. Because Data packets for a specific name can be self- 565 authenticated, they can be validated on the delivery path, and can 566 also be cached at untrusted intermediate nodes. Network coding may 567 bring up issues if intermediate nodes are allowed to modify packets 568 by performing additional network coding operations. In addition, if 569 in-network caches store coded packets, they need to be able to 570 validate that the packets are not compromised, so as to avoid cache 571 pollution attacks. Without having all the packets in a generation, 572 the cache cannot decode the packets to check if it is authenticated. 574 In CCN/NDN, content objects can be encrypted to support access 575 control or privacy. If the coding information of coded packet are 576 encrypted together with the payload (for instance, at source coding), 577 the content requestor or forwarding nodes would incur extra 578 computational overhead for decryption of the packet to interpret the 579 coding information. With consideration for low computation overhead, 580 some mechanism supporting both NC and access control/privacy should 581 be considered. 583 5. Challenges 585 This section presents several primary challenges and research items 586 to be considered when applying NC into CCN/NDN. 588 5.1. Adopting Convolutional Coding 590 Several block coding approaches have been proposed so far, but there 591 is still no sufficient discussion and application of convolutional 592 coding approach (e.g., sliding or elastic window coding) in CCN/NDN. 593 Convolutional coding is often appropriate to situations where a fully 594 or partially reliable delivery of continuous data flows is needed, 595 especially when these data flows feature realtime constraints. As in 596 [34] on an end-to-end basis, it would be advantageous for continuous 597 content flow to adopt sliding window coding in CCN/NDN. In this 598 case, the publisher needs to appropriately set coding parameters and 599 let content requestor know the information, and content requestor 600 needs to send interest (i.e., feedback information) about the data 601 reception status. Since CCN/NDN advocates hop-by-hop communication, 602 it would be worth discussing and investigating how convolutional 603 coding can be applied in a hop-by-hop fashion and the benefits. In 604 particular, assuming that NC could occur at intermediate nodes with 605 some useful data packets stored in the CS as described in the 606 previous section, both the encoding window and CS management would be 607 required, and the feasibility and practicality should be considered. 609 5.2. Rate and Congestion Control 611 Adding redundancy using coded packets may cause further network 612 congestion and adversely affect overall throughput performance. In 613 particular, in a situation where fair bandwidth sharing is more 614 desirable, each streaming flow must adapt to the network conditions 615 to fairly consume the available link bandwidth. It is thus 616 indispensable that each content flow cooperatively implements 617 congestion control to adjust the consumed bandwidth to stabilize the 618 network condition (i.e., to achieve low packet loss rate, delay, and 619 jitter). From this point of view, a router supported approach would 620 be effective, but an effective deployment scenario is needed. 622 As described in Section 4.4, NC can contribute to seamless mobility 623 by obtaining innovative packets without receiving duplicated packets 624 through a virtual logical link to multiple copies of the content. To 625 achieve seamless mobility while improving overall throughput or 626 latency, an effective rate adaptation mechanism upon the virtual 627 logical link is also challenging. 629 5.3. Security and Privacy 631 CCN/NDN introduces new security and privacy issues at the networking 632 layer different from IP network, such as cache poisoning and 633 pollution attack, DoS attack using interest packets, and so on. 635 NC could be utilized to mitigate some security or privacy issues CCN/ 636 NDN introduces. For instance, assuming that consumers can utilize 637 multipath data retrieval and caching in CCN/NDN with NC, cache 638 privacy and anonymity set for consumers can be improved as well as 639 caching performance due to the diversity of caching content along 640 different paths. 642 On the other hand, considering NC operations over CCN/NDN, the issues 643 related to in-network caching add additional complexity. In order to 644 avoid cache poisoning attack which tries to fill routers cache with 645 polluted content, router needs to check whether or not the content is 646 validated. However, in the case of performing NC and generating a 647 new coded data at routers, a validation mechanism to accurately 648 verify coded data as quickly as possible should be considered while 649 maintaining in-network cache benefits (lower latency and network 650 resource saving). If router can cache some valid coded data, it 651 needs to put a great deal of thought into the effectiveness with 652 respect to cache pollution attack, since coded data newly generated 653 may be unpopular. Moreover, Denial of Service (DoS) attacks may 654 target either the routers or the publishers performing NC to pose 655 unnecessary coded data, impose higher NC computation load, and 656 increase the number of PIT entries, which requires some careful 657 considerations to avoid them. 659 NC also offers a new surface of attack; for instance, if the coding 660 vector is exposed at the network layer, it would have to be protected 661 (and validated) so as to avoid modifications by an attacker (and 662 allow for verification) on the path of the packet. 664 In this context, from the perspective of both feasibility and 665 practicability, a more effective approach with consideration for 666 security and privacy would be needed in order to accelerate the 667 deployment of CCN/NDN with NC. 669 5.4. Routing Scalability 671 In CCN/NDN, a name-based routing protocol without a resolution 672 process streamlines the routing process and reduces the overall 673 latency. As in IP routing, the growth in the routing table size has 674 become a concern. This may require a hierarchical naming scheme so 675 as to improve the routing scalability by enabling aggregation of 676 routing information. Moreover, it is a challenge that content 677 requestors efficiently obtain linearly independent coded packets 678 using multipath retrieval in a fully distributed manner, in order to 679 fully leverage NC over CCN/NDN to improve throughput or reduce 680 latency. This would require some efficient routing mechanism to 681 appropriately set the FIB and also requires some efficient interest 682 forwarding strategy. Such routing coordination may create routing 683 scalability issues. From another NC perspective, as described 684 Section 4.2.2, when issuing interests specifying unique names for 685 each coded packet, consumers need in advance to know how to specify 686 the names of the coded data through some specific name resolution 687 scheme, and routers may need to appropriately set the FIBs. In this 688 context, it would be challenging to achieve effective and scalable 689 routing for interests requesting coded data as well as to simplify 690 the routing process. 692 6. Security Considerations 694 This document does not impact the security of the Internet. Security 695 considerations related to NC for CCN/NDN are described in the 696 previous Section. 698 7. References 700 7.1. Normative References 702 [1] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, 704 DOI 10.17487/RFC2119, March 1997, 705 . 707 7.2. Informative References 709 [2] Cai, N. and R. Yeung, "Secure network coding", Proc. 710 International Symposium on Information Theory 711 (ISIT), IEEE, June 2002. 713 [3] Lima, L., Gheorghiu, S., Barros, J., Mdard, M., and A. 714 Toledo, "Secure Network Coding for Multi-Resolution 715 Wireless Video Streaming", IEEE Journal of Selected Area 716 (JSAC), vol. 28, no. 3, April 2002. 718 [4] Gkantsidis, C. and P. Rodriguez, "Cooperative Security for 719 Network Coding File Distribution", Proc. Infocom, IEEE, 720 April 2006. 722 [5] Vilea, J., Lima, L., and J. Barros, "Lightweight security 723 for network coding", Proc. ICC, IEEE, May 2008. 725 [6] Dimarkis, A., Godfrey, P., Wu, Y., Wainwright, M., and K. 726 Ramchandran, "Network Coding for Distributed Storage 727 Systems", IEEE Trans. Information Theory, vol. 56, no.9, 728 September 2010. 730 [7] Gkantsidis, C. and P. Rodriguez, "Network coding for large 731 scale content distribution", Proc. Infocom, IEEE, March 732 2005. 734 [8] Seferoglu, H. and A. Markopoulou, "Opportunistic Network 735 Coding for Video Streaming over Wireless", Proc. Packet 736 Video Workshop (PV), IEEE, November 2007. 738 [9] Montpetit, M., Westphal, C., and D. Trossen, "Network 739 Coding Meets Information-Centric Networking: An 740 Architectural Case for Information Dispersion Through 741 Native Network Coding", Proc. Workshop on Emerging Name- 742 Oriented Mobile Networking Design (NoM), ACM, June 2012. 744 [10] Saltarin, J., Bourtsoulatze, E., Thomos, N., and T. Braun, 745 "NetCodCCN: a network coding approach for content-centric 746 networks", Proc. Infocom, IEEE, April 2016. 748 [11] Ramakrishnan, A., Westphal, C., and J. Saltarin, "Adaptive 749 Video Streaming over CCN with Network Coding for Seamless 750 Mobility", Proc. International Symposium on Multimedia 751 (ISM), IEEE, December 2016. 753 [12] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 754 Westphal, "An Optimal Cache Management Framework for 755 Information-Centric Networks with Network Coding", Proc. 756 Networking Conference, IFIP/IEEE, June 2014. 758 [13] Wang, J., Ren, J., Lu, K., Wang, J., Liu, S., and C. 759 Westphal, "A Minimum Cost Cache Management Framework for 760 Information-Centric Networks with Network Coding", 761 Computer Networks, Elsevier, August 2016. 763 [14] Matsuzono, K., Asaeda, H., and T. Turletti, "Low Latency 764 Low Loss Streaming using In-Network Coding and Caching", 765 Proc. Infocom, IEEE, May 2017. 767 [15] Jacobson, V., Smetters, D., Thornton, J., Plass, M., 768 Briggs, N., and R. Braynard, "Networking Named Content", 769 Proc. CoNEXT, ACM, December 2009. 771 [16] Mosko, M. and et al., "Content-Centric Networking (CCNx) 772 Messages in TLV Format", RFC 8609, July 2019, 773 . 775 [17] Zhang, L., Afanasyev, A., Burke, J., Jacobson, V., Claffy, 776 K., Crowley, P., Papadopoulos, C., Wang, L., and B. Zhang, 777 "Named data networking", ACM Comput. Commun. Rev., vol. 778 44, no. 3, July 2014. 780 [18] NDN Packet Format, "NDN Packet Format Specification 0.3 781 documentation", Sept. 2019, 782 . 784 [19] Koetter, R. and M. Medard, "An Algebraic Approach to 785 Network Coding", IEEE/ACM Trans. on Networking, vol. 11, 786 no 5, Oct. 2003. 788 [20] Adamson, B. and et al., "Taxonomy of Coding Techniques for 789 Efficient Network Communications", RFC 8406, June 2018, 790 . 792 [21] Kutscher, D. and et al., "Information-Centric Networking 793 (ICN) Research Challenges", RFC 7927, July 2016. 795 [22] Thomos, N. and P. Frossard, "Toward one Symbol Network 796 Coding Vectors", IEEE Communications letters, vol. 16, no. 797 11, November 2012. 799 [23] Lucani, D., Pedersen, M., Heide, J., and F. Fitzek, 800 "Fulcrum Network Codes: A Code for Fluid Allocation of 801 Complexity", available at http://arxiv.org/abs/1404.6620, 802 April 2014. 804 [24] Perino, D. and M. Varvello, "A reality check for content 805 centric networking", Proc. SIGCOMM Workshop on 806 Information-centric networking (ICN'11), ACM, August 2011. 808 [25] Wu, Q., Li, Z., Tyson, G., Uhlig, S., Kaafar, M., and G. 809 Xie, "Privacy-Aware Multipath Video Caching for Content- 810 Centric Networks", IEEE Journal of Selected Area 811 (JSAC) vol. 38, no. 8, June 2016. 813 [26] Wu, Y., Chou, P., and K. Jain, "A comparison of network 814 coding and tree packing", Proc. ISIT, IEEE, June 2004. 816 [27] Ho, T., Medard, M., Koetter, R., Karger, R., Effros, D., 817 Shi, M., and B. Leong, "A Random Linear Network Coding 818 Approach to Multicast", IEEE Trans. Information 819 Theory, vol. 52, no.10, October 2006. 821 [28] Podlipnig, S. and L. Osz, "A Survey of Web Cache 822 Replacement Strategies", Proc. ACM Computing Surveys vol. 823 35, no. 4, December 2003. 825 [29] Rossini, G. and D. Rossi, "Evaluating CCN multi-path 826 interest forwarding strategies", Elsevier Computer 827 Communication, vol.36, no. 7, April 2013. 829 [30] Chai, W., He, D., Psaras, I., and G. Pavlou, "Cache Less 830 for More in Information-centric Networks", Journal 831 Computer Communications, vol. 37. no. 7, April 2013. 833 [31] Carofiglio, G., Muscariello, L., Papalini, M., Rozhnova, 834 N., and X. Zeng, "Leveraging ICN In-network Control for 835 Loss Detection and Recovery in Wireless Mobile networks", 836 Proc. ICN ACM, September 2016. 838 [32] Ali, M. and U. Niesen, "Coding for Caching: Fundamental 839 Limits and Practical Challenges", IEEE Communications 840 Magazine vol. 54, no. 8, August 2016. 842 [33] Koetter, R. and F. Kschischang, "An algebraic approach to 843 network coding", IEEE Trans. Netw. vol.11, no.5, October 844 2008. 846 [34] Tournoux, P., Lochin, E., Lacan, J., Bouabdallah, A., and 847 V. Roca, "On-the-Fly Erasure Coding for Real-Time Video 848 Applications", IEEE Trans. Multimeda vol.13, no.4, August 849 2011. 851 Authors' Addresses 853 Kazuhisa Matsuzono 854 National Institute of Information and Communications Technology 855 4-2-1 Nukui-Kitamachi 856 Koganei, Tokyo 184-8795 857 Japan 859 Email: matsuzono@nict.go.jp 861 Hitoshi Asaeda 862 National Institute of Information and Communications Technology 863 4-2-1 Nukui-Kitamachi 864 Koganei, Tokyo 184-8795 865 Japan 867 Email: asaeda@nict.go.jp 869 Cedric Westphal 870 Huawei 871 2330 Central Expressway 872 Santa Clara, California 95050 873 USA 875 Email: cedric.westphal@huawei.com