idnits 2.17.1 draft-pentikousis-icn-scenarios-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ICNRG K. Pentikousis, Ed. 3 Internet-Draft Huawei Technologies 4 Intended Status: Informational B. Ohlman 5 Expires: January 16, 2014 Ericsson 6 D. Corujo 7 Universidade de Aveiro 8 G. Boggia 9 Politecnico di Bari 10 G. Tyson 11 Queen Mary, University of London 12 E. Davies 13 Trinity College Dublin 14 P. Mahadevan 15 PARC 16 S. Spirou 17 Intracom Telecom 18 A. Molinaro 19 UNIRC 20 D. Gellert 21 InterDigital 22 S. Eum 23 NICT 24 July 15, 2013 26 ICN Baseline Scenarios and Evaluation Methodology 27 draft-pentikousis-icn-scenarios-04 29 Abstract 31 This document aims at establishing a common understanding about the 32 evaluation of different information-centric networking (ICN) 33 approaches so that they can be tested and compared against each other 34 while showcasing their own advantages. Towards this end, we review 35 the ICN literature and document scenarios which have been considered 36 in previous performance evaluation studies. We discuss a variety of 37 aspects that an ICN solution can address. This includes general 38 aspects, such as, network efficiency, reduced complexity, increased 39 scalability and reliability, mobility support, multicast and caching 40 performance, real-time communication efficacy, energy consumption 41 frugality, and disruption and delay tolerance. We detail ICN- 42 specific aspects as well, such as information security and trust, 43 persistence, availability, provenance, and location independence. We 44 then survey the evaluation tools currently available to researchers 45 in this area and provide suggestions regarding methodology and 46 metrics. Finally, this document sheds some light on the impact of 47 ICN on network security. 49 Status of this Memo 51 This Internet-Draft is submitted to IETF in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF), its areas, and its working groups. Note that 56 other groups may also distribute working documents as 57 Internet-Drafts. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 The list of current Internet-Drafts can be accessed at 65 http://www.ietf.org/1id-abstracts.html 67 The list of Internet-Draft Shadow Directories can be accessed at 68 http://www.ietf.org/shadow.html 70 Copyright and License Notice 72 Copyright (c) 2013 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Toward ICN Baseline Scenarios . . . . . . . . . . . . . . . . 5 86 2.1. Social Networking . . . . . . . . . . . . . . . . . . . . 5 87 2.2. Real-time Communication . . . . . . . . . . . . . . . . . 7 88 2.3. Mobile Networking . . . . . . . . . . . . . . . . . . . . 8 89 2.4. Infrastructure Sharing . . . . . . . . . . . . . . . . . . 10 90 2.5. Content Dissemination . . . . . . . . . . . . . . . . . . 11 91 2.6. Vehicular Networking . . . . . . . . . . . . . . . . . . . 13 92 2.7. Multiply Connected Nodes and Economics . . . . . . . . . . 15 93 2.8. Energy Efficiency . . . . . . . . . . . . . . . . . . . . 20 94 2.9. Delay- and Disruption-Tolerance . . . . . . . . . . . . . 22 95 2.10. Internet of Things . . . . . . . . . . . . . . . . . . . 27 96 2.11. Smart City . . . . . . . . . . . . . . . . . . . . . . . 30 97 2.12. Operation across Multiple Network Paradigms . . . . . . . 31 98 2.13. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 32 99 3. Evaluation Methodology . . . . . . . . . . . . . . . . . . . . 33 100 3.1. ICN Simulators and Testbeds . . . . . . . . . . . . . . . 34 101 3.1.1. CCN and NDN . . . . . . . . . . . . . . . . . . . . . 34 102 3.1.2. PSI . . . . . . . . . . . . . . . . . . . . . . . . . 36 103 3.1.3. NetInf . . . . . . . . . . . . . . . . . . . . . . . . 36 104 3.1.4. COMET . . . . . . . . . . . . . . . . . . . . . . . . 37 105 3.1.5. Large-scale Testing . . . . . . . . . . . . . . . . . 37 106 3.2. Topology Selection . . . . . . . . . . . . . . . . . . . . 38 107 3.3. Traffic Load . . . . . . . . . . . . . . . . . . . . . . . 39 108 3.4. Choosing Relevant Metrics . . . . . . . . . . . . . . . . 40 109 3.4.1. Traffic Metrics . . . . . . . . . . . . . . . . . . . 43 110 3.4.2. System Metrics . . . . . . . . . . . . . . . . . . . . 44 111 3.5. Resource Equivalence and Tradeoffs . . . . . . . . . . . . 46 112 3.6. Technology Evolution Assumptions . . . . . . . . . . . . . 46 113 4. Security Considerations . . . . . . . . . . . . . . . . . . . 46 114 4.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 47 115 4.2. Authorization, Access Control and Statistics . . . . . . . 48 116 4.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 49 117 4.4. Changes to the Network Security Threat Model . . . . . . . 49 118 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 119 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 120 7. Informative References . . . . . . . . . . . . . . . . . . . . 51 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62 123 1. Introduction 125 Information-centric networking (ICN) marks a fundamental shift in 126 communications and networking. In contrast with the omnipresent and 127 very successful host-centric paradigm, which is based on perpetual 128 connectivity and the end-to-end principle, ICN changes the focal 129 point of the network architecture from the end host to "named 130 information" (or content, or data). In this paradigm, connectivity 131 may well be intermittent. End-host and in-network storage can be 132 capitalized upon transparently, as bits in the network and on storage 133 devices have exactly the same value. Mobility and multiaccess are 134 the norm. Anycast, multicast, and broadcast are natively supported, 135 and energy efficiency is a design consideration from the very 136 beginning. 138 Although interest in ICN is growing rapidly, ongoing work on 139 different architectures, such as, for example, NetInf [NetInf], CCN 140 and NDN [CCN], the publish-subscribe Internet (PSI) architecture 141 [PSI], and the data-oriented architecture [DONA] is far from being 142 completed. The development phase that ICN is going through and the 143 plethora of approaches to tackle the hardest problems make this a 144 very active and growing research area but, on the downside, it also 145 makes it more difficult to compare different proposals on an equal 146 footing. This document aims to address this by establishing a common 147 understanding about potential experimental setups where different ICN 148 approaches can be tested and compared against each other while 149 showcasing their advantages. 151 Ahlgren et al. [SoA] note that describing ICN architectures is akin 152 to shooting a moving target. We find that comparing these different 153 approaches is often even more tricky. in particular, we observe that 154 a variety of performance evaluation scenarios has been devised, 155 typically with good reason, in order to highlight the advantages of 156 each ICN architecture. That is, there is no single scenario, use 157 case, or reference topology which is employed as a benchmark 158 consistently across the ICN literature. This should be expected to 159 some degree at this early stage of ICN development. Nevertheless, 160 this document shows that certain baseline scenarios seem to emerge in 161 which ICN architectures could showcase their superiority over current 162 systems, in general, and against each other, in particular. 164 The remainder of this document is organized as follows. In Section 2 165 we review the peer-reviewed ICN literature and select prominent 166 evaluation study cases as a foundation for the baseline scenarios to 167 be considered by the IRTF Information-Centric Networking Research 168 Group (ICNRG) in its future work. The list of scenarios has evolved 169 since the first draft version of this document based on the input 170 from the research group and the corresponding text contributions. 172 Section 3 presents currently available simulation tools and 173 experimental testbeds that can be used in evaluating ICN, and 174 outlines the key elements that should be considered in an ICN 175 evaluation. Finally, Section 4 discusses the impact of ICN on 176 network security. 178 2. Toward ICN Baseline Scenarios 180 This section presents a number of scenarios grouped into several 181 categories. Note that certain evaluation scenarios span across these 182 categories, so the boundaries between them should not be considered 183 rigid and inflexible. There are two goals for this section. First, 184 to provide a set of use cases and applications that highlight 185 opportunities for testing different ICN proposals. Second, to 186 identify key attributes of a common set of techniques that can be 187 instrumental in evaluating ICN. 189 The overall aim is that each scenario is described at a sufficient 190 level of detail so that it can serve as the base for comparative 191 evaluations of different approaches. This will need to include 192 reference configurations, topologies, specifications of traffic mixes 193 and traffic loads. These specifications (or configurations) should 194 preferably come as sets that describe extremes as well as "typical" 195 usage scenarios. 197 2.1. Social Networking 199 Social networking applications have proliferated over the past decade 200 based on overlay content dissemination systems that require large 201 infrastructure investments to rollout and maintain. Content 202 dissemination is at the heart of the ICN paradigm and, therefore, we 203 would expect that they are a "natural fit" for showcasing the 204 superiority of ICN over traditional client-server TCP/IP-based 205 systems. 207 Mathieu et al. [ICN-SN], for instance, illustrate how an Internet 208 Service Provider (ISP) can capitalize on CCN to deploy a short- 209 message service akin to Twitter at a fraction of the complexity of 210 today's systems. Their key observation is that such a service can be 211 seen as a combination of multicast delivery and caching. That is, a 212 single user addresses a large number of recipients, some of which 213 receive the new message immediately as they are online at that 214 instant, while others receive the message whenever they connect to 215 the network. 217 Along similar lines, Kim et al. [VPC] present an ICN-based social 218 networking platform in which a user shares content with her/his 219 family and friends without the need for a centralized content server; 220 see also subsection 2.4, below, and [JBDMM+12]. Based on the CCN 221 naming scheme, [VPC] takes a user name to represent a set of devices 222 that belong to the person. Other users in this in-network, 223 serverless social sharing scenario can access the user's content not 224 via a device name/address but with the user's name. In [VPC], 225 signature verification does not require any centralized 226 authentication server. Kim and Lee [VPC2] present a proof-of-concept 227 evaluation in which users with ordinary smartphones can browse a list 228 of members or content using a name, and download the content selected 229 from the list. 231 In short, in both ICN-based social networking application scenarios 232 there is no need for a classic client-server architecture (let alone 233 a cloud-based infrastructure) to intermediate between content 234 providers and consumers in a hub-and-spoke fashion. 236 Earlier work by Arianfar et al. [ANO10] considers a similar pull- 237 based content retrieval scenario using a different architecture, 238 pointing to significant performance advantages. Although the authors 239 consider a network topology (redrawn in Fig. 1 for convenience) that 240 has certain interesting characteristics, they do not explicitly 241 address social networking in their evaluation scenario. Nonetheless, 242 similarities are easy to spot: "followers" (such as C0, C1, ..., and 243 Cz in Fig. 1) obtain content put "on the network" (I1, ..., Im, and 244 B1, B2) by a single user (e.g. Px) relying solely on network 245 primitives. 247 \--/ 248 |C0| 249 /--\ +--+ +--+ +--+ +--+ 250 *=== |I0| === |I1| ... |In| |P0| 251 \--/ +--+ +--+ +--+ +--+ 252 |C1| \ / o 253 /--\ +--+ +--+ o 254 o |B1| === |B2| o 255 o o o o o +--+ +--+ o 256 o / \ o 257 o +--+ +--+ +--+ +--+ 258 o *=== |Ik| === |Il| ... |Im| |Px| 259 \--/ +--+ +--+ +--+ +--+ 260 |Cz| 261 /--\ 263 Figure 1. Dumbbell with linear daisy chains. 265 In summary, the social networking scenario aims to exercise each ICN 266 architecture in terms of network efficiency, multicast support, 267 caching performance and its reliance on centralized mechanisms (or 268 lack thereof). 270 2.2. Real-time Communication 272 Real-time audio and video (A/V) communications include an array of 273 services ranging from one-to-one voice calls to multi-party multi- 274 media conferences with support ranging from whiteboards to augmented 275 reality. Real-time communications have been studied and deployed in 276 the context of packet- and circuit-switched networks for decades. 277 The stringent quality of service requirements that this type of 278 communication imposes on network infrastructure are well known. 279 Since one could argue that network primitives which are excellent for 280 information dissemination are not well-suited for conversational 281 services, ICN evaluation studies should consider real-time 282 communication scenarios in detail. 284 Notably, Jacobson et al. [VoCCN] presented an early evaluation where 285 the performance of a VoIP (voice over IP) call using an information- 286 centric approach was compared with that of an off-the-shelf VoIP 287 implementation using RTP/UTP. The results indicated that despite the 288 extra cost of adding security support in the ICN approach, 289 performance was virtually identical in the two cases evaluated in 290 their testbed. However, the experimental setup presented is quite 291 rudimentary, while the evaluation considered a single voice call 292 only. Xuan and Yan [NDNpb] revisit the same scenario but are 293 primarily interested in reducing the overhead that may arise in one- 294 to-one communication employing an ICN architecture. Both studies 295 illustrate that quality telephony services are feasible with at least 296 one ICN approach. That said, future ICN evaluations should employ 297 standardized call arrival patterns, for example, following well- 298 established methodologies from the quality of service/experience 299 (QoS/QoE) evaluation toolbox and would need to consider more 300 comprehensive metrics. 302 Given the wide-spread deployment of real-time A/V communications, an 303 evaluation of an ICN system should demonstrate capabilities beyond 304 feasibility. For example, with respect to multimedia conferencing, 305 Zhu et al. [ACT] describe the design of a distributed audio 306 conference tool based on NDN. Their system includes ICN-based 307 conference discovery, discovery of speakers and voice data 308 distribution. The reported evaluation results point to gains in 309 scalability and security. Moreover, Chen et al. [G-COPSS] explore 310 the feasibility of implementing a Massively Multiplayer Online Role 311 Playing Game (MMORPG) based on CCNx and show that stringent temporal 312 requirements can be met, while scalability is significantly improved 313 when compared to a host-centric (IP-based) client-server system. 314 This type of work points to benefits for both the data and control 315 path of a modern network infrastructure. 317 Real-time communication also brings up the issue of named data 318 granularity for dynamically generated content. For instance, today 319 in many cases A/V data is generated in real-time and is distributed 320 immediately. One possibility is to apply a single name to the entire 321 content, but this could result in significant distribution delays. 322 Alternatively, distributing the content in smaller "chunks" which are 323 named individually may be a better option with respect to real-time 324 distribution but raises naming scalability concerns. 326 We observe that, all in all, the ICN research community has hitherto 327 only scratched the surface of this area with respect to illustrating 328 the benefits of adopting an information-centric approach as opposed 329 to a host-centric one, and more work is recommended in this 330 direction. 332 In short, scenarios in this category should illustrate not only 333 feasibility but reduced complexity, increased scalability, 334 reliability, and capacity to meet stringent QoS/QoE requirements when 335 compared to established host-centric solutions. Accordingly, the 336 primary aim of this scenario is to exercise each ICN architecture in 337 terms of its ability to satisfy real-time QoS requirements and 338 improved user experience. 340 2.3. Mobile Networking 342 IP mobility management relies on anchors to provide ubiquitous 343 connectivity to end-hosts as well as moving networks. This is a 344 natural choice for a host-centric paradigm that requires end-to-end 345 connectivity and a continuous network presence for hosts [SCES]. An 346 implicit assumption in host-centric mobility management is therefore 347 that the mobile node aims to connect to a particular peer, as well as 348 to maintain global reachability and service continuity [EEMN]. 349 However, with ICN new ideas about mobility management should come to 350 the fore capitalizing on the different nature of the paradigm. For 351 example, one could exploit the ability of nodes to better express 352 their intended use of the network, i.e., the retrieval of a small 353 subset of the global data corpus as discussed in [MOBSURV]. 355 Dannewitz et al. [N-Scen], illustrate a scenario where a multiaccess 356 end-host can retrieve email securely using a combination of cellular 357 and wireless local area network (WLAN) connectivity. This scenario 358 borrows elements from previous work, e.g., [DTI], and develops them 359 further with respect to multiaccess. Unfortunately, Dannewitz et al. 361 [N-Scen] do not present any results demonstrating that an ICN 362 approach is, indeed, better. That said, the scenario is interesting 363 as it considers content specific to a single user (i.e., her mailbox) 364 and does point to reduced complexity. It is also compatible with 365 recent work in the Distributed Mobility Management (DMM) Working 366 Group within the IETF. Finally, Xylomenos et al. [PSIMob] as well as 367 [EEMN] argue that an information-centric architecture can avoid the 368 complexity of having to manage tunnels to maintain end-to-end 369 connectivity as is the case with mobile anchor-based protocols such 370 as Mobile IP (and its variants). Similar considerations hold for a 371 vehicular (networking) environment, as we discuss in subsection 2.6 372 below. 374 Overall, mobile networking scenarios have not been developed in 375 detail, let alone evaluated at a large scale. Further, the majority 376 of scenarios discussed so far have related to information consumer, 377 rather than source, mobility. We expect that in the coming period 378 more papers will address this topic. Earlier work [mNetInf] argues 379 that for mobile and multiaccess networking scenarios we need to go 380 beyond the current mobility management mechanisms in order to 381 capitalize on the core ICN features. They present a testbed setup 382 (redrawn in Fig. 2) which can serve as the basis for other ICN 383 evaluations. In this scenario, node "C0" has multiple network 384 interfaces that can access local domains N0 and N1 simultaneously 385 allowing C0 to retrieve objects from which ever server (I2 or I3) can 386 supply them without necessarily needing to access the servers in the 387 core network "C" (P1 and P2). Lindgren [Lin11] explores this 388 scenario further for an urban setting. He uses simulation and 389 reports sizable gains in terms of reduction of object retrieval times 390 and core network capacity use. 392 +------------+ +-----------+ 393 | Network N0 | | Network C | 394 | | | | 395 | +--+ | ==== | +--+ | 396 | |I2| | | |P1| | 397 | +--+ | | +--+ | 398 | \--/ | | | 399 +-----|C0|---+ | | 400 | /--\ | | | 401 | +--+ | | | 402 | |I3| | | +--+ | 403 | +--+ | ==== | |P2| | 404 | | | +--+ | 405 | Network N1 | | | 406 +------------+ +-----------+ 408 Figure 2. Overlapping wireless multiaccess. 410 The benefits from capitalizing on the broadcast nature of wireless 411 access technologies has yet to be explored to its full potential in 412 the ICN literature, including quantifying possible gains in terms of 413 energy efficiency [AMR13]. Obviously, ICN architectures must avoid 414 broadcast storms. Early work in this area considers distributed 415 packet suppression techniques which exploit delayed transmissions and 416 overhearing; examples can be found in [MPZ10] and [OLG10] for ICN- 417 based mobile ad-hoc networks (MANETs), and in [WAKVWZ12] and [ACM12] 418 for vehicular scenarios. 420 One would expect that mobile networking scenarios will be naturally 421 coupled with those discussed in the previous sections, as more users 422 access social networking and multimedia applications through mobile 423 devices. Further, the constraints of real-time A/V applications 424 create interesting challenges in handling mobility, particularly in 425 terms of maintaining service continuity. This scenario therefore 426 spans across most of the others considered in this document with the 427 likely need for some level of integration, particularly considering 428 the well-documented increases in mobile traffic. Mobility is further 429 considered in subsection 2.9 and the economic consequences of nodes 430 having multiple network interfaces is explored in subsection 2.7. 432 To summarize, mobile networking scenarios should aim to provide 433 service continuity for those applications that require it, decrease 434 complexity and control signaling for the network infrastructure, as 435 well as increase wireless capacity utilization by taking advantage of 436 the broadcast nature of the medium. Beyond this, mobile networking 437 scenarios should form a cross-scenario platform that can highlight 438 how other scenarios can still maintain their respective performance 439 metrics during periods of high mobility. 441 2.4. Infrastructure Sharing 443 A key idea in ICN is that the network should secure information 444 objects per se, not the communications channel that they are 445 delivered over. This means that hosts attached to an information- 446 centric network can share resources on an unprecedented scale, 447 especially when compared to what is possible in an IP network. All 448 devices with network access and storage capacity can contribute their 449 resources increasing the value of an information-centric network 450 (perhaps) much faster than Metcalfe's law. 452 For example, Jacobson et al. [JBDMM+12] argue that in ICN the "where 453 and how" of obtaining information are new degrees of freedom. They 454 illustrate this with a scenario involving a photo sharing application 455 which takes advantage of whichever access network connectivity is 456 available at the moment (WLAN, Bluetooth, and even SMS) without 457 requiring a centralized infrastructure to synchronize between 458 numerous devices. It is important to highlight that since the focus 459 of communication changes, keep-alives in this scenario are simply 460 unnecessary, as devices participating in the testbed network 461 contribute resources in order to maintain user content consistency, 462 not link state information as is the case in the host-centric 463 paradigm. This means that the notion of "infrastructure" may be 464 completely different in the future. 466 Muscariello et al. [MCG11], for instance, presented early work on an 467 analytical framework that attempts to capture the storage/bandwidth 468 tradeoffs that ICN enables and can be used as foundation for a 469 network planning tool. In addition, Chai et al. [CHPP12] explore the 470 benefits of ubiquitous caching throughout an information-centric 471 network and argue that "caching less can actually achieve more." 472 These papers also sit alongside a variety of other studies that look 473 at various scenarios such as caching HTTP-like traffic [L9] and 474 BitTorrent-like traffic [TKMEMT12]. We observe that much more work 475 is needed in order to understand how to make optimal use of all 476 resources available in an information-centric network. In real-world 477 deployments, policy and commercial considerations are also likely to 478 affect the use of particular resources and more work is expected in 479 this direction as well (see also subsection 2.7). 481 In conclusion, scenarios in this category, would cover the 482 communication-computation-storage tradeoffs that an ICN deployment 483 must consider. This would exercise features relating to network 484 planning, perhaps capitalizing on user-provided resources, as well as 485 operational and economical aspects to illustrate the superiority of 486 ICN over other approaches. An obvious baseline to compare against in 487 this regard is existing federations of IP-based Content Distribution 488 Networks (CDNs). 490 2.5. Content Dissemination 492 Content dissemination has attracted more attention than other aspects 493 of ICN, perhaps due to a misunderstanding of what the first "C" in 494 CCN stands for. Scenarios in this category abound in the literature, 495 including stored and streaming A/V distribution, file distribution, 496 mirroring and bulk transfers, versioned content services (c.f., 497 Subversion-type revision control), as well as traffic aggregation. 499 Decentralized content dissemination with on-the-fly aggregation of 500 information sources was envisaged in [N-Scen], where information 501 objects can be dynamically assembled based on hierarchically 502 structured subcomponents. For example, a video stream could be 503 associated with different audio streams and subtitle sets, which can 504 all be obtained from different sources. Using the topology depicted 505 in Fig. 1 as an example, an application at C1 may end up obtaining, 506 say, the video content from I1, but the user-selected subtitles from 507 Px. Semantics and content negotiation, on behalf of the user, were 508 also considered, e.g., for the case of popular tunes which may be 509 available in different encoding formats. Effectively this scenario 510 has the information consumer issuing independent requests for content 511 based on information identifiers, and stitching the pieces together 512 irrespective of "where" or "how" they were obtained. 514 A case in point for content dissemination are vehicular ad-hoc 515 networks (VANETs), as an ICN approach may address their needs for 516 information dissemination between vehicles better than today's 517 solutions, as discussed in the following subsection. The critical 518 part of information dissemination in a VANET scenario revolves around 519 "where" and "when". For instance, one may be interested in traffic 520 conditions 2 km ahead while having no interest in similar information 521 about the area around the path origin. VANET scenarios may provide 522 fertile ground for showcasing the ICN advantage with respect to 523 content dissemination especially when compared with current host- 524 centric approaches. That said, information integrity and filtering 525 are challenges that must be addressed. As mentioned earlier, content 526 dissemination scenarios in VANETs have a particular affinity to the 527 mobility scenarios discussed earlier. 529 Content dissemination scenarios, in general, have a large overlap 530 with those described in the previous sections and are explored in 531 several papers, such as [DONA] [PSI] [PSIMob] [NetInf] [CCN] 532 [JBDMM+12] [ANO10], just to name a few. In addition, Chai et al. 533 [CURLING] present a hop-by-hop hierarchical content resolution 534 approach, which employs receiver-driven multicast over multiple 535 domains, advocating another content dissemination approach. Yet, 536 largely, work in this area did not address the issue of access 537 authorization in detail. Often, the distributed content is mostly 538 assumed to be freely accessible by any consumer. Distribution of 539 paid-for or otherwise restricted content on a public ICN network 540 requires more attention in the future. Fotiou et al. [FMP12] 541 consider a scheme to this effect but it still requires access to an 542 authorization server to verify the user's status after the 543 (encrypted) content has been obtained. This may effectively negate 544 the advantage of obtaining the content from any node, especially in a 545 disruption-prone or mobile network. 547 In summary, scenarios in this category aim to exercise primarily 548 scalability, cost and performance attributes of content 549 dissemination. Particularly, they should highlight the ability of an 550 ICN to scale to billions of objects, while not exceeding the cost of 551 existing content dissemination solutions (i.e., CDNs) and, ideally, 552 increasing performance. These should be shown in a holistic manner, 553 improving content dissemination for both information consumers and 554 publishers of all sizes. We expect that in particular for content 555 dissemination, both extreme as well as typical scenarios can be 556 specified drawing data from current CDN deployments. 558 2.6. Vehicular Networking 560 Users "on wheels" are interested in road safety, traffic efficiency, 561 and infotainment applications that can be supported through vehicle- 562 to-vehicle (V2V) and vehicle-to-infrastructure (V2I) wireless 563 communications. These applications exhibit unique features in terms 564 of traffic generation patterns, delivery requirements, spatial and 565 temporal scope, which pose great challenges to traditional networking 566 solutions. VANETs, by their nature, are characterized by challenges 567 such as fast-changing topology, intermittent connectivity, high node 568 mobility, but also by the opportunity to combine information from 569 different sources as each vehicle does not care about "who" delivers 570 the named data objects. 572 ICN is an attractive candidate solution for vehicular networking, as 573 it has several advantages. First, ICN fits well to the nature of 574 typical vehicular applications that are geography- and time-dependent 575 (e.g., road traveler information, accident warning, point-of-interest 576 advertisements) and usually target vehicles in a given area, 577 regardless of their identity or IP address. These applications are 578 likely to benefit from in-network and decentralized data caching and 579 replication mechanisms. Second, content caching is particularly 580 beneficial for intermittent on-the-road connectivity and can speed up 581 data retrieval through content replication in several nodes. Caching 582 can usually be implemented at relatively low cost in vehicles as the 583 energy demands of the ICN device are likely to be a negligible 584 fraction of the total vehicle energy consumption, thus allowing for 585 sophisticated processing, continuous communication and adequate 586 storage in the vehicle. Finally, ICN natively supports asynchronous 587 data exchange between end-nodes. By using (and redistributing) 588 cached named information objects, a mobile node can serve as a link 589 between disconnected areas. In short, ICN can enable communication 590 even under intermittent network connectivity, which is typical of 591 vehicular environments with sparse roadside infrastructure and fast 592 moving nodes. 594 The advantages of ICN in vehicular networks were preliminarily 595 discussed in [BK10] and [DMND], and additionally investigated in 596 [WWKVZ12] [WAKVWZ12] [AKH11] [TL12] [ACM12] [CRoWN]. For example, 597 Bai and Krishnamachari [BK10] take advantage of the localized and 598 dynamic nature of a VANET to explore how a road congestion 599 notification application can be implemented. Wang et al. [DMND] 600 consider data collection where Road-Side Units (RSUs) collect 601 information from vehicles by broadcasting NDN-like INTEREST packets. 602 The proposed architecture is evaluated using simulation in a grid 603 topology and is compared against a host-centric alternative based on 604 Mobile IP. See Fig. 3 for an indicative example of an urban VANET 605 topology. Their results indicate high efficiency for ICN even at 606 high speeds. That said, the authors point out that as this work is a 607 preliminary exploration of ICN in vehicular environments, many issues 608 remain to be evaluated, such as system scalability to large numbers 609 of vehicles and the impact of vehicles forwarding Interests and 610 relaying data for other vehicles. 612 + - - _- - -_- - - -_- - _- - - + 613 | /_\ /_\ /_\ /_\ | 614 | o o o o o o o o | 615 | +-------+ +-------+ _ | 616 | | | | |/_\ | 617 | _ | | | |o o | 618 | /_\| | | | | 619 | o o+--_----+\===/+--_----+ | 620 | /_\ |RSU| /_\ | 621 | o o /===\ o o | 622 | +-------+ +-------+ _ | 623 | | | | |/_\ | 624 | _ | | | |o o | 625 |/_\ | | | | | 626 |o o +_-----_+ +_-----_+ | 627 | /_\ /_\ /_\ /_\ | 628 +_ _ o_o_ _o_o_ _ _o_o_ _o_o_ _ + 630 Figure 3. Urban grid VANET topology. 632 As mentioned in the previous section, due to the short communication 633 duration between a vehicle and the RSU, and the typically short time 634 of sustained connectivity between vehicles, VANETs may be a good 635 showcase for the ICN advantages with respect to content 636 dissemination. Wang et al. [WWKVZ12], for instance, analyze the 637 advantages of hierarchical naming for vehicular traffic information 638 dissemination. Arnould et al. [AKH11] apply ICN principles to safety 639 information dissemination between vehicles with multiple radio 640 interfaces. In [TL12], TalebiFard and Leung use network coding 641 techniques to improve content dissemination over multiple ICN paths. 642 Amadeo et al. [ACM12][[CRoWN] propose an application-independent ICN 643 framework for content retrieval and distribution where the role of 644 provider can be played equivalently by both vehicles and RSUs. ICN 645 forwarding is extended through path-state information carried in 646 Interest and Data packets, stored in a new data structure kept by 647 vehicular nodes, and exploited also to cope with node mobility. 649 Typical scenarios for testing content distribution in VANETs may be 650 highways with vehicles moving in straight lines, with or without RSUs 651 along the road, as shown in Fig. 4. With a NDN approach in mind, for 652 example, RSUs may send Interests to collect data from vehicles 653 [DMND], or vehicles may send Interests to collect data from other 654 peers [WAKVWZ12] or from RSUs [ACM12]. Fig. 2 applies to content 655 dissemination in VANET scenarios as well, where C0 represents a 656 vehicle which can obtain named information objects via multiple 657 wireless peers and/or RSUs (I2 and I3 in the figure). Grid 658 topologies such as the one illustrated in Fig. 3 should be considered 659 in urban scenarios with RSUs at the crossroads, or co-located with 660 traffic lights as in [CRoWN]. 662 \__/ \__/ 663 |RU| |RU| 664 ================================ 665 _ _ _ _ 666 /_\ /_\ /_\ /_\ 667 _ _ o_o_ _o_o_ _o_o_ _o_o_ _ _ _ 668 _ _ _ _ 669 /_\ /_\ /_\ /_\ 670 o o o o o o o o 671 ================================ 673 Figure 4. Highway VANET topology. 675 To summarize, VANET scenarios aim to exercise ICN deployment from 676 various perspectives, including scalability, caching, transport, and 677 mobility issues. There is a need for further investigation in (i) 678 challenging scenarios (e.g., disconnected segments); (ii) scenarios 679 involving both consumer and provider mobility; (iii) smart caching 680 techniques which take into consideration node mobility patterns, 681 spatial and temporal relevance, content popularity, and social 682 relationships between users/vehicles; (iv) identification of new 683 applications (beyond data dissemination and traffic monitoring) that 684 could benefit from the adoption of an ICN paradigm in vehicular 685 networks (e.g., mobile cloud, social networking). 687 2.7. Multiply Connected Nodes and Economics 689 The evolution of, in particular, wireless networking technologies has 690 resulted in a convergence of the bandwidth and capabilities of 691 various different types of networks. Today a leading edge mobile 692 telephone or tablet computer will typically be able to access a Wi-Fi 693 access point, a 4G cellular network and the latest generation of 694 Bluetooth local networking. Until recently a node would usually have 695 a clear favorite network technology appropriate to any given 696 environment. The choice would, for example, be primarily determined 697 by the available bandwidth with cost as a secondary determinant. 698 Furthermore, it is normally the case that a device only uses one of 699 the technologies at a time for any particular application. 701 It seems likely that this situation will change so that nodes are 702 able to use all of the available technologies in parallel. This will 703 be further encouraged by the development of new capabilities in 704 cellular networks including Small Cell Networks (SCN) and 705 Heterogeneous Networks (HetNet). Consequently, mobile devices will 706 have similar choices to wired nodes attached to multiple service 707 providers allowing "multi-homing" via the various different 708 infrastructure networks as well as potential direct access to other 709 mobile nodes via Bluetooth or a more capable form of ad hoc Wi-Fi. 711 Infrastructure networks are generally under the control of separate 712 economic entities that may have different policies about the 713 information of an ICN deployed within their network caches. As ICN 714 shifts the focus from nodes to information objects, the interaction 715 between networks will likely evolve to capitalize on data location 716 independence, efficient and scalable in-network named object 717 availability and access via multiple paths. These interactions 718 become critical in evaluating the technical and economic impact of 719 ICN architectural choices, as noted in [ArgICN]. Beyond simply 720 adding diversity in deployment options, these networks have the 721 potential to alter the incentives among existing, and future, we may 722 add, network players, as noted in [EconICN]. 724 Moreover, such networks enable more numerous inter-network 725 relationships where exchange of information may be conditioned on a 726 set of multilateral policies. For example, shared SCNs are emerging 727 as a cost-effective way to address coverage of complex environments 728 such as sports stadiums, large office buildings, malls, etc. [OptSC] 729 [FEMTO]. Such networks are likely to be a complex mix of different 730 cellular and WLAN access technologies (such as HSPA, LTE, and Wi-Fi) 731 as well as ownership models. It is reasonable to assume that access 732 to content generated in such networks may depend on contextual 733 information such as the subscription type, timing, and location of 734 both the owner and requester of the content. The availability of 735 such contextual information across diverse networks can lead to 736 network inefficiencies unless data management can benefit from an 737 information-centric approach. The "Event with Large Crowds" 738 demonstrator created by the SAIL project investigated this kind of 739 scenario; more details are available in [SAIL-B3]. 741 Jacobson et al. [CCN] include interactions between networks in their 742 overall system design, and mention both "an edge-driven, bottom-up 743 incentive structure" and techniques based on evolutions of existing 744 mechanisms both for ICN router discovery by the end-user and for 745 interconnecting between autonomous systems (AS). For example, a BGP 746 extension for domain-level content prefix advertisement can be used 747 to enable efficient interconnection between AS's. Liu et al. [MLDHT] 748 proposed to address the "suffix-hole" issue found in prefix-based 749 name aggregation through the use of a combination of Bloom-filter 750 based aggregation and multi-level DHT. 752 Name aggregation has been discussed for a flat naming design as well 753 in [NCOA], which also notes that based on estimations in [DONA] flat 754 naming may not require aggregation. This is a point that calls for 755 further study. Scenarios evaluating name aggregation, or lack 756 thereof, should take into account the amount of state (e.g. size of 757 routing tables) maintained in edge routers as well as network 758 efficiency (e.g. amount of traffic generated). 760 +---------------+ 761 +---------->| Popular Video | 762 | +---------------+ 763 | ^ ^ 764 | | | 765 | +-+-+ $0/MB +-+-+ 766 | | A +-------+ B | 767 | ++--+ +-+-+ 768 | | ^ ^ | 769 | $8/MB | | | | $10/MB 770 | v | | v 771 +-+-+ $0/MB +--+---------+--+ 772 | D +---------+ C | 773 +---+ +---------------+ 775 Figure 5. Relationships and transit costs between networks A to D. 777 DiBenedetto et al. [RP-NDN] study policy knobs made available by NDN 778 to network operators. New policies, which are not feasible in the 779 current Internet are described, including a "cache sharing peers" 780 policy, where two peers have an incentive to share content cached in, 781 but not originating from, their respective network. The simple 782 example used in the investigation considers several networks and 783 associated transit costs, as shown in Fig. 5. (based on Fig. 1 of 784 [RP-NDN]). Agyapong and Sirbu [EconICN] further establish that ICN 785 approaches should incorporate features that foster (new) business 786 relationships. For example, publishers should be able to indicate 787 their willingness to partake in the caching market, proper reporting 788 should be enabled to avoid fraud, and content should be made 789 cacheable as much as possible to increase cache hit ratios. 791 Ahlgren et al. [SAIL-B3] enable network interactions in the NetInf 792 architecture using a name resolution service at domain edge routers, 793 and a BGP-like routing system in the NetInf Default Free Zone. 794 Business models and incentives are studied in [SAIL-A7] and [SAIL- 795 A8], including scenarios where the access network provider (or a 796 virtual CDN) guarantees QoS to end users using ICN. Fig. 6 797 illustrates a typical scenario topology from this work which involves 798 an interconnectivity provider. 800 +----------+ +-----------------+ +------+ 801 | Content | | Access Network/ | | End | 802 | Provider +---->| ICN Provider +---->| User | 803 +----------+ +-+-------------+-+ +------+ 804 | | 805 | | 806 v v 807 +-------------------+ +----------------+ +------+ 808 | Interconnectivity | | Access Network | | End | 809 | Provider +---->| Provider +------>| User | 810 +-------------------+ +----------------+ +------+ 812 Figure 6. Setup and operating costs of network entities 814 Jokela et al. [LIPSIN] propose a two-layer approach where additional 815 rendezvous systems and topology formation functions are placed 816 logically above multiple networks and enable advertising and routing 817 content between them. Visala et al. [LANES] further describe an ICN 818 architecture based on similar principles, which, notably, relies on a 819 hierarchical DHT-based rendezvous interconnect. Rajahalme et al. 820 [PSIRP1] describe a rendezvous system using both a BGP-like routing 821 protocol at the edge and a DHT-based overlay at the core. Their 822 evaluation model is centered around policy-compliant path stretch, 823 latency introduced by overlay routing, caching efficacy, and overlay 824 routing node load distribution. 826 Rajahalme et al. [ICCP] point out that ICN architectural changes may 827 conflict with the current tier-based peering model. For example, 828 changes leading to shorter paths between ISPs are likely to meet 829 resistance from Tier-1 ISPs. Rajahalme [IDMcast] shows how 830 incentives can help shape the design of specific ICN aspects, and in 831 [IDArch] he presents a modeling approach to exploit these incentives. 832 This includes a network model which describes the relationship 833 between Autonomous Systems based on data inferred from the current 834 Internet, a traffic model taking into account business factors for 835 each AS, and a routing model integrating the valley-free model and 836 policy-compliance. A typical scenario topology is illustrated in 837 Fig. 7, which is redrawn here based on Fig. 1 of [ICCP]. Note that 838 it relates well with the topology illustrated in Fig. 1 of this 839 document. 841 o-----o 842 +-----+ J +-----+ 843 | o--*--o | 844 | * | 845 o--+--o * o--+--o 846 | H +-----------+ I | 847 o-*-*-o * o-*-*-o 848 * * * * * 849 ****** ******* * ******* ******* 850 * * * * * 851 o--*--o o*-*-*o o--*--o 852 | E +--------+ F +---------+ G + 853 o-*-*-o o-----o o-*-*-o 854 * * * * 855 ****** ******* ****** ****** 856 * * * * 857 o--*--o o--*--o o--*--o o--*--o 858 | A | | B +-----------+ C | | D | 859 o-----o o--+--o o--+--o o----+o 860 | | ^^ | route 861 data | data | data || | to 862 | | || | data 863 o---v--o o---v--o o++--v-o 864 | User | | User | | Data | 865 o------o o------o o------o 867 Legend: 868 ***** Transit link 869 +---+ Peering link 870 +---> Data delivery or route to data 872 Figure 7. Tier-based set of interconnections between AS A to J. 874 To sum up, the evaluation of ICN architectures across multiple 875 network types should include a combination of technical and economic 876 aspects, capturing their various interactions. These scenarios aim 877 to illustrate scalability, efficiency and manageability, as well as 878 traditional and novel network policies. Moreover, scenarios in this 879 category should specifically address how different actors have proper 880 incentives, not only in a pure ICN realm, but also during the 881 migration phase towards this final state. 883 2.8. Energy Efficiency 885 Advantage can be taken of some prominent ICN features to 886 significantly reduce the energy footprint of future communication 887 networks. A simple example of a potential energy-saving operation is 888 caching. If a data object can be retrieved from within a network, 889 rather than from a distant origin server, clearly, significant 890 amounts of energy expenditure can be saved by avoiding several 891 further hops. Alternatively, approaches that aim to simplify 892 routers, such as [PURSUIT], could also reduce energy consumption by 893 pushing routing decisions into more energy-efficient data centers. 895 We elaborate on the energy efficiency potential of ICN based on three 896 categories of ICN characteristics. Namely, we point out that a) ICN 897 does not rely solely on end-to-end communication, b) ICN enables 898 ubiquitous caching, and c) ICN brings awareness of user requests (as 899 well as their corresponding responses) at the network layer thus 900 permitting network elements to better schedule their transmission 901 patterns. 903 First, ICN does not mandate perpetual end-to-end communication, which 904 introduces a whole range of energy consumption inefficiencies due to 905 the extensive signaling, especially in the case of mobile and 906 wirelessly connected devices. This opens up new opportunities for 907 accommodating sporadically connected nodes and could be one of the 908 keys to an order of magnitude decrease in energy consumption. For 909 example, web applications often need to maintain state at both ends 910 of a connection in order to verify that the authenticated peer is up 911 and running. This introduces keep-alive timers and polling behavior 912 with a high toll on energy consumption. Pentikousis [EEMN] discusses 913 several related scenarios and explains why the current host-centric 914 paradigm, which employs end-to-end always-on connections, introduces 915 built-in energy inefficiencies argueing that patches to make 916 currently deployed protocols energy-aware cannot provide for an order 917 of magnitude increase in energy efficiency. 919 Second, ICN network elements come with built-in caching capabilities, 920 which is often referred to as ubiquitous caching. Pushing data 921 objects to caches closer to end user devices, for example, could 922 significantly reduce the amount of transit traffic in the core 923 network, thereby reducing the energy used for data transport. Guan 924 et al. [EECCN] study the energy efficiency of CCNx (based on their 925 proposed energy model) and compare it with conventional content 926 dissemination systems such as CDNs and P2P. Their model is based on 927 the analysis of the topological structure and the average hop-length 928 from all consumers to the nearest cache location. Their results show 929 that ICN can be more energy efficient in delivering popular content. 930 In particular, they also note that different network element design 931 choices (e.g. the optical bypass approach) can be more energy- 932 efficient in delivering infrequently accessed content. 934 Lee et al. [EECD] investigate the energy efficiency of various 935 network devices deployed in access, metro, and core networks for both 936 CDNs and ICN. They use trace-based simulations to show that an ICN 937 approach can substantially improve the network energy efficiency for 938 content dissemination mainly due to the reduction in the number of 939 hops required to obtain a data object, which can be served by 940 intermediate nodes in ICN. They also emphasize that the impact of 941 cache placement (in incremental deployment scenarios) and 942 local/cooperative content replacement strategies need to be carefully 943 investigated in order to better quantify the energy efficiencies 944 arising from adopting an ICN paradigm. 946 Third, as mentioned earlier, energy efficiency can be tackled by 947 different ICN approaches in ways that it cannot in a host-centric 948 paradigm. We already mentioned that in ICN, perpetual (always-on) 949 connectivity is not necessary, therefore mechanisms that capitalize 950 on powering down network interfaces are easier to accommodate. Since 951 all ICN elements are aware of the user request and its corresponding 952 data response, due to the nature of name-based routing, they can 953 employ power consumption optimization processes for determining their 954 transmission schedule. For example, network coding [NCICN] or 955 adaptive video streaming [COAST] can be used in individual ICN 956 elements so that redundant transmissions, possibly passing through 957 intermediary networks, could be significantly reduced, thereby saving 958 energy by avoiding to carry redundant traffic. 960 Alternatively, approaches that aim to simplify routers could also 961 reduce energy consumption by pushing routing decisions to a more 962 energy-efficient entity. Along these lines, Ko et al. [ICNDC] design 963 a data center network architecture based on ICN principles and 964 decouple the router control-plane and data-plane functionalities. 965 Thus, data forwarding is performed by simplified network entities 966 while the complicated routing computation is carried out in more 967 energy-efficient data centers. 969 To summarize, energy efficiency has been discussed in ICN evaluation 970 studies but most published work is preliminary in nature. Thus, we 971 suggest that more work is needed in this front. Evaluating energy 972 efficiency does not require the definition of new scenarios or 973 baseline topologies, but does require the establishment of clear 974 guidelines so that different ICN approaches can be compared not only 975 in terms of scalability, for example, but also in terms to power 976 consumption. 978 2.9. Delay- and Disruption-Tolerance 980 Delay- and Disruption-Tolerant Networking (DTN) [DTN] [TBB13] 981 originated as a means to extend the Internet to interplanetary 982 communications. However, it was subsequently found to be an 983 appropriate architecture for many terrestrial situations as well. 984 Typically, this was where delays were greater than protocols such as 985 TCP could handle, and where disruptions to communications were the 986 norm rather than occasional annoyances, e.g., where an end-to-end 987 path does not necessarily exist when communication is initiated. DTN 988 has now been applied to many situations, including opportunistic 989 content sharing, handling infrastructural issues during emergency 990 situations (e.g., earthquakes) and providing connectivity to remote 991 rural areas without existing Internet provision and little or no 992 communications or power infrastructure. 994 The DTN architecture [RFC4838] is based on a "store, carry and 995 forward" paradigm that has been applied extensively to situations 996 where data is carried between network nodes by a "data mule", which 997 carries bundles of data stored in some convenient storage medium 998 (e.g., a USB memory stick). With the advent of sensor and peer-to- 999 peer (P2P) networks between mobile nodes, DTN is becoming a more 1000 commonplace type of networking than originally envisioned. Since ICN 1001 also does not rely on the familiar end-to-end communications 1002 paradigm, there are, thus, clear synergies [DTN]. It could therefore 1003 be argued that many of the key principles embodied within DTN also 1004 exist in ICN, as we explain next. 1006 First, both approaches rely on in-network storage. In the case of 1007 DTN, bundles are stored temporarily on devices on a hop-by-hop basis. 1008 In the case of ICN, information objects are also cached on devices 1009 in a similar fashion. As such, both paradigms must provision storage 1010 within the network. 1012 Second, both approaches espouse late binding of names to locations 1013 due to the potentially large interval between request and response 1014 generation. In the case of DTN, it is often impossible to predict 1015 the exact location (in a disconnected topology) where a node will be 1016 found. Similarly, in the case of ICN, it is also often impossible to 1017 predict where an information object might be found. As such, the 1018 binding of a request/bundle to a destination (or routing locator) 1019 must be performed as late as possible. 1021 Third, both approaches treat data as a long-lived component that can 1022 exist in the network for extended periods of time. In the case of 1023 DTN, bundles are carried by nodes until appropriate next hops are 1024 discovered. In the case of ICN, information objects are typically 1025 cached until storage is exhausted. As such, both paradigms require a 1026 direct shift in the way applications interact with the network. 1028 Through these similarities, it becomes possible to identify many DTN 1029 principles that are already in existence within ICN architectures. 1030 For example, ICN nodes will often retain publications locally, making 1031 them accessible later on, much as DTN bundles are handled. 1032 Consequently, these synergies suggest strong potential for marrying 1033 the two technologies. This, for instance, could include building new 1034 integrated Information-Centric Delay Tolerant Network (ICDTN) 1035 protocols or, alternatively, building ICN schemes over existing DTN 1036 protocols (or vice versa). 1038 The above similarities suggest that integration of the two principles 1039 would be certainly feasible. Beyond this, there are also a number of 1040 direct benefits identifiable. Through caching and replication, ICN 1041 offers strong information resilience, whilst, through store-and- 1042 forward, DTN offers strong connectivity resilience. As such, both 1043 architectures could benefit greatly from each other. Initial steps 1044 have already been taken in the DTN community to integrate ICN 1045 principles, e.g., the Bundle Protocol Query Block [BPQ] has been 1046 added to the DTN Bundle Protocol [RFC5050]. Whilst, similarly, 1047 initial steps have also been taken in the ICN community, such as 1048 [SLINKY]. In fact, the SAIL project has recently developed a 1049 prototype implementation of NetInf running over the DTN Bundle 1050 Protocol. 1052 For the purpose of evaluating the use of ICNs in a DTN setting, two 1053 key scenarios are identified in this document (note the rest of this 1054 section uses the term ICDTN). These are both prominent use cases 1055 that are currently active in both the ICN and DTN communities. The 1056 first is opportunistic content sharing, whilst the second is the use 1057 of ad hoc networks during disaster recovery (e.g., earthquakes). 1058 These are discussed in the context of a simulation-based evaluation; 1059 due to the scale and mobility of DTN-like setups, this is the primary 1060 method of evaluation used. Within the DTN community, the majority of 1061 simulations are performed using the Opportunistic Network Environment 1062 (ONE) simulator [ONE], which is referred to in this document. Before 1063 exploring the two scenarios, the key shared components of their 1064 simulation are discussed. This is separated into the two primary 1065 inputs that are required: the environment and the workload. 1067 In the case of both scenarios, the environment can be abstractly 1068 modeled by a time series of active connections between device pairs. 1069 Unlike other scenarios in this document, an ICDTN scenario does not 1070 depend on (relatively) static topologies but, rather, a set of time- 1071 varying disconnected topologies. In opportunistic networks, these 1072 topologies are actually products of the mobility of users. For 1073 example, if two users walk past each other, an opportunistic link can 1074 be created. There are two methods used to generate these mobility 1075 patterns and, in turn, the time series of topologies. The first is 1076 synthetic, whereby a (mathematical) model of user behavior is created 1077 in an agent-based fashion, e.g., random waypoint, Gauss-Markov. The 1078 second is trace-driven, whereby the mobility of real users is 1079 recorded and used. In both cases, the output is a sequence of time- 1080 stamped "contacts", i.e. a period of time in which two devices can 1081 communicate. An important factor missing from typical mobility 1082 traces, however, is the capacity of these contacts: how much data can 1083 be transferred? In both approaches to modeling mobility, links are 1084 usually configured as Bluetooth or WiFi (ONE easily allows this, 1085 although lower layer considerations are ignored, e.g., interference). 1086 This is motivated by the predominance of these technologies on 1087 mobile phones. 1089 The workload in an ICDTN is modeled much like the workload within the 1090 other scenarios. It involves object creation/placement and object 1091 retrieval. Object creation/placement can either be done statically 1092 at the beginning of the simulations or, alternatively, dynamically 1093 based on a model of user behavior. In both cases, the latter is 1094 focused on, as it models far better the characteristics of the 1095 scenarios. 1097 Once the environment and workload has been configured, the next step 1098 is to decide the key metrics for the study. Unlike traditional ICN, 1099 the quality of service expectations are typically far lower in an 1100 ICDTN, thereby moving away from metrics such as throughput. At a 1101 high-level, it is of clear interest to evaluate different ICN 1102 approaches with respect to both their delay- and disruption- 1103 tolerance, i.e., how effective is the approach when used in an 1104 environment subject to significant delay and/or disruption; and to 1105 their active support for operations in a DTN environment. 1107 The two most prominent metrics considered in a host-centric DTN are 1108 delivery probability and delivery delay. The former relates to the 1109 probability that a sent message will be received within a certain 1110 delay bound, whilst the latter captures the average length of time it 1111 takes for nodes to receive the message. These metrics are similarly 1112 important in an ICDTN, although they are slightly different due to 1113 the request-response nature of ICN. Therefore, the two most 1114 prominent evaluative metrics are: 1116 o Satisfaction Probability: The probability by which an information 1117 request (e.g., Interest) will be satisfied (i.e., how often a Data 1118 response will be received). 1120 o Satisfaction Delay: The length of time it takes an information 1121 request to be satisfied. 1123 Note that the key difference between the host-centric and 1124 information-centric metrics is the need for a round-trip rather than 1125 a one-way communication. Beyond this, depending on the focus of the 1126 work, other elements that may be investigated include name 1127 resolution, routing and forwarding in disconnected parts of the 1128 network; support for unidirectional links; number of round trips 1129 needed to complete a data transfer; long-term content availability 1130 (or resilience); efficiency in the face of disruption, and so on. It 1131 is also important to weigh these performance metrics against the 1132 necessary overheads. In the case of an ICDTN, this is generally 1133 measured by the number of message replicas required to access content 1134 (note that routing in a DTN is often replication-based, which leads 1135 to many copies of the same message). 1137 The first key baseline scenario in this context is opportunistic 1138 content sharing. This occurs when mobile nodes create opportunistic 1139 links between each other to share content of interest. For example, 1140 this might occur on an underground train, in which people pass news 1141 items between their mobile phones. Equally, content generated on the 1142 phones (e.g., tweets [TWIMIGHT]) could be stored for later forwarding 1143 (or even forwarded amongst interested passengers on the train). Such 1144 networks are often termed pocket-switched networks, as they are 1145 independently formed between the user devices. Here, the evaluative 1146 scenario of ICDTN microblogging is proposed. As previously 1147 discussed, the construction of such an evaluative scenario requires a 1148 formalization of its environment and workload. Luckily, there exist 1149 a number of datasets that offer exactly this information required for 1150 microblogging. 1152 In terms of the environment (i.e., mobility patterns), the Haggle 1153 project produced contact traces based on conference attendees using 1154 Bluetooth. These traces are best targeted at application scenarios 1155 in which a small group of (50-100) people are in a relatively 1156 confined space. In contrast, larger scale traces are also available, 1157 most notably MIT's Reality Mining project. These are better suited 1158 for cases where longer-term movement patterns are of interest. 1160 The second input, workload, relates to the creation and consumption 1161 of microblogs (e.g. tweets). This can be effectively captured 1162 because subscriptions conveniently formalize who consumes what. For 1163 bespoke purposes, specific data can be directly collected from 1164 Twitter for trace-driven simulations. Several Twitter datasets are 1165 already available to the community containing a variety of data, 1166 ranging from Tweets to follower graphs. Sources include: 1167 http://www.tweetarchivist.com/ 1168 http://twapperkeeper.com/ 1169 http://www.infochimps.com/collections/twitter-census 1170 http://socialcomputing.asu.edu/datasets/Twitter 1172 These datasets can therefore be used to extract information 1173 production, placement and consumption. 1175 The second key baseline scenario in this context relates to the use 1176 of ICDTNs in emergency scenarios. In these situations it is typical 1177 for infrastructure to be damaged or destroyed, leading to the 1178 collapse of traditional forms of communications (e.g., cellular 1179 telephone networks). This has been seen in the recent North India 1180 flooding, as well as the 2011 Tohoku earthquake and tsunami. Power 1181 problems often exacerbate the issue, with communication problems 1182 lasting for days. Therefore, in order to address this, DTNs have 1183 been used due to their high levels of resilience and independence 1184 from fixed infrastructure. The most prominent use of DTNs in 1185 disaster areas would be the dissemination of information, e.g., 1186 warnings and evacuation maps. Here, we focus on the dissemination of 1187 standard broadcast information that should be received by all 1188 parties. 1190 For the environmental setup, there are no commonly used mobility 1191 traces for disaster zones, unlike in the previous evaluative 1192 scenario. This is clearly due to the difficultly (near 1193 impossibility) of acquiring them in a real setting. That said, 1194 various synthetic models are available. The Post Disaster Mobility 1195 Model [MODEL1] models civilians and emergency responders after a 1196 disaster has occurred, with people attempting to reach evacuation 1197 points (this has also been implemented in ONE). [MODEL2] focuses on 1198 emergency responders, featuring the removal of nodes from the 1199 disaster zone, as well as things like obstacles (e.g. collapsed 1200 buildings). [MODEL3] also looks at emergency responders, but focuses 1201 on patterns associated with common procedures. For example, command 1202 and control centers are typically set up with emergency responders 1203 periodically returning. Clearly, the mobility of emergency 1204 responders is particularly important in this setting because they 1205 usually are the ones who will "carry" information into the disaster 1206 zone. It is recommended that one of these emergency-specific models 1207 are used during any evaluations, due to the inaccuracy of alternate 1208 models used for "normal" behavior. 1210 The workload input in this scenario is far simpler than for the 1211 previous scenario. In emergency cases, the dissemination of 1212 individual pieces of information to all parties is the norm. This is 1213 often embodied using things like the Common Alert Protocol (CAP). As 1214 such, small objects (e.g. 512KB to 2MB) are usually generated 1215 containing text and images; note that the ONE simulator offers 1216 utilities to easily generate these. These messages are also always 1217 generated by central authorities, therefore making the placement 1218 problem easier (they would be centrally generated and given to 1219 emergency responders to disseminate as they pass through the disaster 1220 zone). The key variable is therefore the generation rate, which is 1221 synonymous with the rate that microblogs are written in the previous 1222 scenario. This will largely be based on the type of disaster 1223 occurring, however, hourly updates would be an appropriate 1224 configuration. Higher rates can also be tested, based on the rate at 1225 which situations change (lands slides, for example, can exhibit 1226 highly dynamic properties). 1228 To summarize, this section has highlighted the applicability of ICN 1229 principles to existing DTN scenarios. Two evaluative setups have been 1230 described in detail, namely, mobile opportunistic content sharing 1231 (microblogging) and emergency information dissemination. 1233 2.10. Internet of Things 1235 Advances in electronics miniaturization combined with low-power 1236 wireless access technologies (e.g., ZigBee, NFC, Bluetooth and 1237 others) have enabled the coupling of interconnected digital services 1238 with everyday objects. As devices with sensors and actuators connect 1239 into the network, they become "smart objects" and form the foundation 1240 for the so-called Internet of Things (IoT). IoT is expected to 1241 increase significantly the amount of content carried by the network 1242 due to machine-to-machine (M2M) communication as well as novel user 1243 interaction possibilities. 1245 Yet, the full potential of IoT does not lie in simple remote access 1246 to smart object data. Instead, it is the intersection of Internet 1247 services with the physical world that will bring about the most 1248 dramatic changes. Burke [IoTEx], for instance, makes a very good 1249 case for creating everyday experiences using interconnected things 1250 through participatory sensing applications. In this case, inherent 1251 ICN capabilities for data discovery, caching, and trusted 1252 communication are leveraged to obtain sensor information and enable 1253 content exchange between mobile users, repositories, and 1254 applications. 1256 Kutscher and Farrell [IWMT] discuss the benefits that ICN can provide 1257 in these environments in terms of naming, caching, and optimized 1258 transport. The Named Information URI scheme (ni) [RFC6920], for 1259 instance, could be used for globally unique smart object 1260 identification, although an actual implementation report is not 1261 currently available. Access to information generated by smart 1262 objects can be of varied nature and often vital for the correct 1263 operation of large systems. As such, supporting timestamping, 1264 security, scalability, and flexibility need to be taken into account. 1266 Ghodsi et al. [NCOA] examine hierarchical and self-certifying naming 1267 schemes and point out that ensuring reliable and secure content 1268 naming and retrieval may pose stringent requirements (e.g., the 1269 necessity for employing PKI), which can be too demanding for low- 1270 powered nodes, such as sensors. That said, earlier work by Heidemann 1271 et al. [nWSN] shows that, for dense sensor network deployments, 1272 disassociating sensor naming from network topology and using named 1273 content at the lowest level of communication in combination with in- 1274 network processing of sensor data is feasible in practice and can be 1275 more efficient than employing a host-centric binding between node 1276 locator and the content existing therein. 1278 Burke et al. [NDNl] describe the implementation of a lighting control 1279 building automation system where the security, naming and device 1280 discovery NDN mechanisms are leveraged to provide configuration, 1281 installation and management of residential and industrial lighting 1282 control systems. The goal is an inherently resilient system, where 1283 even smartphones can be used for control. Naming reflects fixtures 1284 with evolved identification and node reaching capabilities thus 1285 simplifying bootstrapping, discovery, and user interaction with 1286 nodes. The authors report that this ICN-based system requires less 1287 maintenance and troubleshooting than typical IP-based alternatives. 1289 Biswas et al. [CIBUS] visualize ICN as a contextualized information- 1290 centric bus (CIBUS) over which diverse sets of service producers and 1291 consumers co-exist with different requirements. ICN is leveraged to 1292 unify different platforms to serve consumer-producer interaction in 1293 both infrastructure and ad hoc settings. Ravindran et al. [Homenet], 1294 show the application of this idea in the context of a home network, 1295 where consumers (residents) require policy-driven interactions with 1296 diverse services such as climate control, surveillance systems, and 1297 entertainment systems. Name-based protocols are developed to enable 1298 zero-configuration node and service discovery, contextual service 1299 publishing and subscription, policy-based routing and forwarding with 1300 name-based firewall, and hoc device-to-device communication. 1302 IoT exposes ICN concepts to a stringent set of requirements which are 1303 exacerbated by the amount of nodes, as well as by the type and volume 1304 of information that must be handled. A way to address this is 1305 proposed in [IoTScope], which tackles the problem of mapping named 1306 information to an object, diverting from the currently typical 1307 centralized discovery of services and leveraging the intrinsic ICN 1308 scalability capabilities for naming. It extends the base [PURSUIT] 1309 design with hierarchically-based scopes, facilitating lookup, access, 1310 and modifications of only the part of the object information that the 1311 user is interested in. Another important aspect is how to 1312 efficiently address resolution and location of the information 1313 objects, particularly when large numbers of nodes are connected, as 1314 in IoT deployments. In [ICN-DHT], Katsaros et al. propose a 1315 Distributed Hash Table (DHT) which is compared with DONA [DONA]. 1316 Their results show how topological routing information has a positive 1317 impact on resolution, at the expense of memory and processing 1318 overhead. 1320 The use of ICN mechanisms is IoT scenarios faces the most dynamic and 1321 heterogeneous type of challenges, when taking into consideration the 1322 requirements and objectives of such integration. The disparity in 1323 technologies (not only in access technologies, but also in terms of 1324 end-node diversity such as sensors, actuators and their 1325 characteristics) as well as in the information that is generated and 1326 consumed in such scenarios, will undoubtedly bring about many of the 1327 considerations presented in the previous sections. For instance, IoT 1328 shares similarities with the constraints and requirements applicable 1329 to vehicular networking. Here, a central problem is the deployment 1330 of mechanisms that can use opportunistic connectivity in unreliable 1331 networking environments (similarly to the vehicular networking and 1332 DTN scenarios). 1334 However, one important concern in IoT scenarios, also motivated by 1335 this strongly heterogeneous environment, is how content dissemination 1336 will be affected by the different semantics of the disparate 1337 information and content being shared. In fact, this is already a 1338 difficult problem that goes beyond the scope of ICN [SEMANT]. With 1339 the ability of the network nodes to cache forwarded information to 1340 improve future requests, a challenge arises regarding whether the ICN 1341 fabric should be involved in any kind of procedure (e.g., tagging) 1342 that facilitates the relationship or the interpretation of the 1343 different sources of information. 1345 Another issue lies with the need for having energy-efficiency 1346 mechanisms related to the networking capabilities of IoT 1347 infrastructures. Often, the devices in IoT deployments have limited 1348 battery capabilities, and thus need low power consumption schemes 1349 working at multiple levels. In principle, energy efficiency gains 1350 should be observed from the inherent in-network caching capability. 1351 However, this might not be the most usual case in IoT scenarios, 1352 where the information (particularly from sensors, or controlling 1353 actuators) is more akin to real-time traffic, thus reducing the scale 1354 of potential savings due to ubiquitous in-network caching. 1356 ICN approaches, therefore, should be evaluated with respect to their 1357 capacity to handle the content produced and consumed by extremely 1358 large numbers of diverse devices. IoT scenarios aim to exercise ICN 1359 deployment from different aspects, including ICN node design 1360 requirements, efficient naming, transport, and caching of time- 1361 restricted data. Scalability is particularly important in this 1362 regard as the successful deployment of IoT principles could expand 1363 both device and content numbers dramatically beyond all current 1364 expectations. 1366 2.11. Smart City 1368 The rapid increase in urbanization sets the stage for the most 1369 compelling and challenging environments for networking. By 2050 the 1370 global population will reach nine billion people, 75% of which will 1371 dwell in urban areas. In order to cope with this influx, many cities 1372 around the world have started their transformation toward the Smart 1373 City vision. Smart cities will be based on the following innovation 1374 axes: smart mobility, smart environment, smart people, smart living, 1375 and smart governance. In development terms, the core goal of a smart 1376 city is to become a business-competitive and attractive environment, 1377 while serving citizen well being [CPG]. 1379 In a smart city, ICT plays a leading role and acts as the glue 1380 bringing together all actors, services, resources (and their 1381 interrelationships), that the urban environment is willing to host 1382 and provide [MVM]. ICN appears particularly suitable for these 1383 scenarios. Domains of interest include intelligent transportation 1384 systems, energy networks, health care, A/V communications, peer-to- 1385 peer and collaborative platforms for citizens, social inclusion, 1386 active participation in public life, e-government, safety and 1387 security, sensor networks. Clearly, this scenario has close ties to 1388 the vision of IoT, discussed in the previous subsection, as well as 1389 to vehicular networking. 1391 Nevertheless, the road to build a real information-centric digital 1392 ecosystem will be long and more coordinated effort is required to 1393 drive innovation in this domain. We argue that smart city needs and 1394 ICN technologies can trigger a virtuous innovation cycle toward 1395 future ICT platforms. Recent concrete ICN-based contributions have 1396 been formulated for home energy management [iHEMS], geo-localized 1397 services [ACC], smart city services [IB], and traffic information 1398 dissemination in vehicular scenarios [WAKVWZ12]. Some of the 1399 proposed ICN-based solutions are implemented in real testbeds while 1400 others are evaluated through simulation. 1402 Zhang et al. [iHEMS] propose a secure publish-subscribe architecture 1403 for handling the communication requirements of Home Energy Management 1404 Systems (HEMS). The objective is to safely and effectively collect 1405 measurement and status information from household elements, aggregate 1406 and analyze the data, and ultimately enable intelligent control 1407 decisions for actuation. They consider a simple experimental test- 1408 bed for their proof-of-concept evaluation, exploiting open source 1409 code for the ICN implementation, and emulating some node 1410 functionality in order to facilitate system operation. 1412 A different scenario is considered in [ACC], where DHTs are employed 1413 for distributed, scalable, and geographically-aware service lookup in 1414 a smart city. Also in this case, the ICN application is validated by 1415 considering a small-scale testbed: a small number of nodes are 1416 realized with simple embedded PCs or specific hardware boards (e.g., 1417 for some sensor nodes); other nodes realizing the network connecting 1418 the principal actors of the tests are emulated with workstations. 1419 The proposal in [IB] draws from a smart city scenario (mainly 1420 oriented towards waste collection management) comprising sensors and 1421 moving vehicles, as well as a cloud computing system that supports 1422 data retrieval and storage operations. The main aspects of this 1423 proposal are analyzed via simulation using open source code which is 1424 publicly available. Some software applications are designed on real 1425 systems (e.g., PCs and smartphones). 1427 To sum up, smart city scenarios aim to exercise several ICN aspects 1428 in an urban environment. In particular, they can be useful to (i) 1429 analyze the capacity of using ICN for managing extremely large data 1430 sets; (ii) study ICN performance in terms of scalability in 1431 distributed services; (iii) verify the feasibility of ICN in a very 1432 complex application like vehicular communication systems; and (iv) 1433 examine the possible drawbacks related to privacy and security issues 1434 in complex networked environments. 1436 2.12. Operation across Multiple Network Paradigms 1438 Today the overwhelming majority of networks are integrated with the 1439 well-connected Internet with IP at the "waist" of the technology 1440 hourglass. However there is a large amount of ongoing research into 1441 alternative paradigms that can cope with conditions other than the 1442 standard set assumed by the Internet. Perhaps the most advanced of 1443 these is Delay- and Disruption-Tolerant Networking (DTN). DTN is 1444 considered as one of the scenarios for the deployment in 1445 subection 2.9 but here we consider how ICN can operate in an 1446 integrated network that has essentially disjoint "domains" (a highly- 1447 overloaded term!) or regions that use different network paradigms and 1448 technologies, but with gateways that allow interoperation. 1450 ICN operates in terms of named data objects so that requests and 1451 deliveries of information objects can be independent of the 1452 networking paradigm. Some researchers have contemplated some form of 1453 ICN becoming the new waist of the hourglass as the basis of a future 1454 reincarnation of the Internet, e.g., [ArgICN], but there are a large 1455 number of problems to resolve, including authorization and access 1456 control (see subsection 4.2) and transactional operation for 1457 applications such as banking, before some form of ICN can be 1458 considered as ready to take over from IP as the dominant networking 1459 technology. In the meantime, ICN architectures will operate in 1460 conjunction with existing network technologies as an overlay or in 1461 cooperation with the lower layers of the "native" technology. 1463 It seems likely that as the reach of the "Internet" is extended, 1464 other technologies such as DTN will be needed to handle scenarios 1465 such as space communications where inherent delays are too large for 1466 TCP/IP to cope with effectively. Thus, demonstrating that ICN 1467 architectures can work effectively in and across the boundaries of 1468 different networking technologies will be important. The NetInf 1469 architecture in particular targets the inter-domain scenario by the 1470 use of a convergence layer architecture [SAIL-B3] and PSIRP/PURSUIT 1471 is envisaged as a candidate for an IP replacement. 1473 The key items for evaluation over and above the satisfactory 1474 operation of the architecture in each constituent domain will be to 1475 ensure that requests and responses can be carried across the network 1476 boundaries with adequate performance and do not cause malfunctions in 1477 applications or infrastructure because of the differing 1478 characteristics of the gatewayed domains. 1480 2.13. Summary 1482 We conclude Section 2 with a brief summary of the evaluation aspects 1483 we have seen across a range of scenarios. 1485 The scalability of different mechanisms in an ICN architecture stands 1486 out as an important concern (cf. subsections 2.1-2, 2.5-7, 2.10-11,) 1487 as does network, resource and energy efficiency (cf. subsections 2.1, 1488 2.3-4, 2.7-8). Operational aspects such as network planing, 1489 manageability, reduced complexity and overhead (cf. subsection 2.2-4, 1490 2.7, 2.10) should not be neglected especially as ICN architectures 1491 are evaluated with respect to their potential for deployment in the 1492 real world. Accordingly, further research in economic aspects as 1493 well as in the communication, computation, and storage tradeoffs 1494 entailed in each ICN architecture is needed. 1496 With respect to purely technical requirements, support for multicast, 1497 mobility, and caching lie at the core of many scenarios (cf. 1498 subsections 2.1, 2.3, 2.5-6). ICN must also be able to cope when the 1499 Internet expands to incorporate additional network paradigms (cf. 1500 subsection 2.12). We have also seen that being able to address 1501 stringent QoS requirements and increase reliability and resilience 1502 should also be evaluated following well-established methods (cf. 1503 subsections 2.2, 2.9-10). 1505 Finally, we note that new applications that significantly improve the 1506 end user experience and forge a migration path from today's host- 1507 centric paradigm could be the key to a sustained and increasing 1508 deployment of the ICN paradigm in the real world (cf. subsections 1509 2.2-3, 2.6, 2.10-11). 1511 3. Evaluation Methodology 1513 As we have seen in the previous section, different ICN approaches 1514 have been evaluated in the peer-reviewed literature using a mixture 1515 of theoretical analysis, simulation and emulation techniques, and 1516 empirical (testbed) measurements. These are all popular methods for 1517 evaluating network protocols, architectures, and services in the 1518 networking community. Typically, researchers follow a specific 1519 methodology based on the goal of their experiment, e.g., whether they 1520 want to evaluate scalability, quantify resource utilization, analyze 1521 economic incentives, and so on, as we have discussed earlier. In 1522 addition, though, we observe that ease and convenience of setting up 1523 and running experiments can sometimes be a factor in published 1524 evaluations. 1526 It is worth pointing out that for well-established protocols, such as 1527 TCP, performance evaluation using actual network deployments has the 1528 benefit of realistic workloads and reflects the environment where the 1529 service or protocol will be deployed. However, results obtained in 1530 this environment are often difficult to replicate independently. 1531 Beyond this, the difficulty of deploying future Internet 1532 architectures and then engaging sufficient users to make such 1533 evaluation realistic is often prohibitive. 1535 Moreover, for ICN in particular, it is not yet clear what qualifies 1536 as a "realistic workload". As such, trace-based analysis of ICN is 1537 in its infancy, and more work is needed towards defining 1538 characteristic workloads for ICN evaluation studies. Accordingly, 1539 the experimental process itself as well as the evaluation methodology 1540 are being actively researched for ICN architectures. Numerous 1541 factors affect the experimental results, including the topology 1542 selected; the background traffic that an application is being 1543 subjected to; network conditions such as available link capacities, 1544 link delays, and loss-rate characteristics throughout the selected 1545 topology; failure and disruption patterns; node mobility; as well as 1546 other aspects such as the diversity of devices used, and so on, as we 1547 explain in the remainder of this section. 1549 Apart from the technical evaluation of the functionality of an ICN 1550 architecture, its future success will be largely driven by its 1551 deployability and economic viability. Thus evaluations should also 1552 include an assessment of incremental deployability in the existing 1553 network environment together with a view of how the technical 1554 functions will incentivize deployers to invest in the capabilities 1555 that allow the architecture to spread across the network. 1557 In this section, we present various techniques and considerations for 1558 evaluating different ICN architectures. We do not intend to develop 1559 a complete methodology or a benchmarking tool. Instead, this 1560 document proposes key guidelines alongside suggested data sets and 1561 high-level approaches that we expect to be of interest to ICNRG and 1562 the ICN community as a whole. Through this, researchers and 1563 practitioners alike would be able to compare and contrast different 1564 ICN designs against each other, and identify the respective strengths 1565 and weaknesses. 1567 3.1. ICN Simulators and Testbeds 1569 Since ICN is still an emerging area, the community is still in the 1570 process of developing effective evaluation environments, including 1571 simulators, emulators, and testbeds. To date, none of the available 1572 evaluation methodologies can be seen as the one and only community 1573 reference evaluation tool. Furthermore, no single environment 1574 supports all well-known ICN approaches. Simulators and emulators 1575 should be able to capture, faithfully, all features and operations of 1576 the respective ICN architecture(s). It is also essential that these 1577 tools and environments come with adequate logging facilities so that 1578 one can use them for in-depth analysis as well as debugging. 1579 Additional requirements include the ability to support mid- to large- 1580 scale experiments, the ability to quickly and correctly set various 1581 configurations and parameters, as well as to support the playback of 1582 traffic traces captured on a real testbed or network. Obviously, this 1583 does not even begin to touch upon the need for strong validation of 1584 any evaluated implementations. 1586 The rest of this subsection summarizes the ICN simulators and 1587 testbeds currently available to the community. 1589 3.1.1. CCN and NDN 1591 The CCN project has open-sourced a software reference implementation 1592 of the architecture and protocol called CCNx (www.ccnx.org). CCNx is 1593 available for deployment on various operating systems and includes C 1594 and Java libraries that can be used to build CCN applications. CCN- 1595 lite (www.ccn-lite.net) is a lightweight implementation of the CCN 1596 protocol, supports most of the key features of CCNx, and is 1597 interoperable with CCNx. The core CCNx logic has been implemented in 1598 about 1000 lines of code and is ideal for classroom work and course 1599 projects as well as for quickly experimenting with CCNx extensions. 1601 ndnSIM [ndnSIM] is a module that can be plugged into the ns-3 1602 simulator and supports the core features of CCN. One can use ndnSIM 1603 to experiment with various CCN applications and services as well as 1604 components developed for CCN such as routing protocols, caching and 1605 forwarding strategies. The code for ns-3 and ndnSIM is openly 1606 available to the community and can be used as the basis for 1607 implementing ICN protocols or applications. For more details see 1608 http://www.nsnam.org and http://www.ndnsim.net. 1610 ccnSim [ccnSim] is another CCN-specific simulator that was specially 1611 designed to handle forwarding of a large number of CCN-chunks. 1612 ccnSim is written in C++ for the OMNeT++ simulation framework 1613 (www.omnetpp.org). Interested readers could consider also the 1614 Content Centric Networking Packet Level Simulator [CCNPL]. Finally, 1615 CCN-Joker [CGB12] is an application-layer platform that can be used 1616 to build a CCN overlay. CCN-Joker emulates in user-space all basic 1617 aspects of a CCN node (e.g., handling of Interest and Data packets, 1618 cache sizing, replacement policies), including both flow and 1619 congestion control. The code is open source and is suitable for both 1620 emulation-based analyses and real experiments. 1622 An example of a testbed that supports CCN is the Open Network Lab 1623 (see https://onl.wustl.edu/). The ONL testbed currently comprises 18 1624 extensible gigabit routers and over 100 computers representing 1625 clients and is freely available to the public for running CCN 1626 experiments. Nodes in ONL are preloaded with CCNx software. ONL 1627 provides a graphical user interface for easy configuration and 1628 testbed set up as per the experiment requirements, and also serves as 1629 a control mechanism, allowing access to various control variables and 1630 traffic counters. It is also possible to run and evaluate CCN over 1631 popular testbeds such as PlanetLab (www.planet-lab.org), Emulab 1632 (www.emulab.net), and Deter (www.isi.deterlab.net) by directly 1633 running the CCNx open-source code on PlanetLab and Deter nodes, 1634 respectively. 1636 NEPI, the Network Experimentation Programming Interface, 1637 (http://nepi.inria.fr) is a tool developed for controlling and 1638 managing large-scale network experiments. NEPI provides an 1639 experiment description language to design network experiments, 1640 describing topology, applications, and a controller to automatically 1641 deploy those experiments on target experimentation environments, such 1642 as PlanetLab. The controller is also capable of collecting result and 1643 log files during the experiment execution. NEPI also allows to 1644 specify node selection filters while designing the experiment, 1645 thereby supporting automatic discovery and provisioning of testbed 1646 nodes during experiment deployment, without the user having to hand- 1647 pick them. It is simple and efficient to use NEPI to evaluate CCNx 1648 on large-scale testbeds such as PlanetLab. 1650 3.1.2. PSI 1652 The PSIRP project has open-sourced its Blackhawk publish-subscribe 1653 (Pub/Sub) implementation for FreeBSD; more details are available 1654 online at http://www.psirp.org/downloads.html. Despite being limited 1655 to one operating system, the code base also provides a virtual image 1656 to allow its deployment on other environments through virtualization. 1657 The code distribution features a kernel module, a file system and 1658 scope daemon, as well as a set of tools, test applications and 1659 scripts. This work was extended as part of the PURSUIT project, 1660 resulting in the development of the Blackadder prototype for Linux 1661 and FreeBSD. It currently runs on a testbed across Europe, America 1662 (MIT) and Japan (NICT). All sites are connected via OpenVPN, which 1663 exports a virtual Ethernet device to all machines in the testbed. In 1664 total, 40 machines in a graph topology containing one Topology 1665 Manager and one Rendezvous node that handle all publish/subscribe and 1666 topology formation requests are interconnected [PTA13]. 1668 Moreover, the ICN simulation environment [VBYR12] allows the 1669 simulation of new techniques for topology management following the 1670 Publish-Subscribe paradigm and the PSIRP approach. The simulator is 1671 based on the OMNET++ simulator and the INET/MANET frameworks. It is 1672 currently publicly available at 1673 http://sourceforge.net/projects/icnsim. A design characteristic of 1674 this platform is the separation between the network and topology 1675 management policies. An interface is used to provide this 1676 functionality and policies can be imported and applied in the network 1677 as topology manager applications running on top of this interface. 1679 3.1.3. NetInf 1681 The EU FP7 4WARD and SAIL projects have made a set of open-source 1682 implementations available; see http://www.netinf.org/open-source for 1683 more details. Of note, two software packages are available. The 1684 first one is a set of tools for NetInf implementing different aspects 1685 of the protocol (e.g., NetInf URI format, HTTP and UDP convergence 1686 layer) using different programming languages. The Java 1687 implementation provides a local caching proxy and client. The second 1688 one, is a OpenNetInf prototype from the 4WARD project. Besides a 1689 rich set of NetInf mechanisms implemented, it also provides a browser 1690 plug-in and video streaming software. 1692 The SAIL project developed a hybrid host-centric and information- 1693 centric network architecture called the Global Information Network 1694 (GIN). The prototype code for this can be downloaded from 1695 http://gin.ngnet.it. 1697 3.1.4. COMET 1699 The EU FP7 COMET project developed a simulator, called Icarus, which 1700 implements ProbCache [PCP12], centrality-based in-network caching 1701 [CHPP12] and the hash-route-based algorithms detailed in [SPP13]. 1702 The simulator is built in Python and makes use of the Fast Network 1703 Simulator Setup tool [SCP13] to configure the related parameters of 1704 the simulation. The simulator is available from: 1705 https://github.com/lorenzosaino/icarus/ 1707 3.1.5. Large-scale Testing 1709 An important consideration in the evaluation of any kind of future 1710 Internet mechanism, lies in the characteristics of that evaluation 1711 itself. Often, central to the assessment of the features provided by 1712 a novel mechanism, lies the consideration of how it improves over 1713 already existing technologies, and by "how much." With the 1714 disruptive nature of clean-slate approaches generating new and 1715 different technological requirements, it is complex to provide 1716 meaningful results for a network layer framework, in comparison with 1717 what is deployed in the current Internet. Thus, despite the 1718 availability of ICN implementations and simulators, the need for 1719 large-scale environments supporting experimental evaluation of novel 1720 research is of prime importance to the advancement of ICN deployment. 1722 In this regard, initiatives such as the Future Internet Research and 1723 Experimentation Initiative (www.ict-fire.eu), enable researchers to 1724 test new protocols and architectures in real conditions over 1725 production networks (e.g., through virtualization and software- 1726 defined networking mechanisms), simplifying the validation of future 1727 evolutions and reducing the gap between research and deployment. 1728 Similarly, Future Internet Design (www.nets-find.net) is a long-term 1729 initiative along the same direction in the US. GENI (www.geni.net) 1730 also offers experimentation infrastructure as does PlanetLab 1731 (www.planet-lab.org), which likely offers the largest testbed 1732 available today. Those wishing to perform smaller, more controlled 1733 experiments can also consider the Emulab testbed (www.emulab.net), 1734 which allows various topologies to be configured. 1736 Finally, the National Institute of Information and Communications 1737 Technology (NICT) builds and operates the high-performance testbed 1738 JGN-X (see http://www.jgn.nict.go.jp/english/index.html), which has 1739 cutting-edge network functions and technologies including those 1740 currently in development. JGN-X aims to establish new-generation 1741 network technology and accelerate the R&D in areas such as network 1742 virtualization and advanced operations of virtualized layers. JGN-X 1743 is used for collaboration among developers in order to foster the 1744 establishment and expansion of new-generation network technology. 1746 3.2. Topology Selection 1748 Section 2 introduced several topologies that have been used in ICN 1749 studies so far but, to date and to the best of our understanding, 1750 there is no single topology that can be used to easily evaluate all 1751 aspects of the ICN paradigm. There is rough consensus that the 1752 classic dumbbell topology cannot serve well future evaluations of ICN 1753 approaches. Therefore, one should consider a range of topologies, 1754 each of which would stress different aspects, as outlined earlier in 1755 this document. Current Internet traces are also available to assist 1756 in this, e.g. see http://www.caida.org/data/active/internet-topology- 1757 data-kit and 1758 http://www.cs.washington.edu/research/networking/rocketfuel. 1760 Depending on what is the focus of the evaluation, intra-domain 1761 topologies alone may be appropriate. However, those interested, for 1762 example, in quantifying transit costs will require inter-domain 1763 traces (note that the above CAIDA traces offer this). Scalability is 1764 an important aspect in such an evaluation. For instance, CAIDA's 1765 ITDK traces record millions of routers across thousands of domains. 1767 Beyond these "real-world" traces there is a wide range of synthetic 1768 topologies, such as the Barabasi-Albert model [BA99] and the Watts- 1769 Strogatz small-world topology [WS98]. These synthetic traces allow 1770 experiments to be performed whilst controlling various key parameters 1771 (e.g. degree). Through this, different aspects can be investigated, 1772 such as inspecting resilience properties. For some lines of ICN 1773 research, this may be more appropriate as, practically speaking, 1774 there are no assurances that a future ICN will share the same 1775 topology with today's networks. 1777 Besides defining the evaluation topology as a graph G = (V,E), where 1778 V is the set of vertices (nodes) and E is the set of edges (links), 1779 one should also clearly define and list the respective matrices that 1780 correspond to the network, storage and computation capacities 1781 available at each node as well as the delay characteristics of each 1782 link, so that the results obtained can be easily replicated in other 1783 studies. Recent work by Hussain and Chen [Montage], although 1784 currently addressing host-centric networks, could also be leveraged 1785 and be extended by the ICN community. Measurement information can 1786 also be taken from existing platforms such as iPlane 1787 (http://iplane.cs.washington.edu), which can be used to provide 1788 configuration parameters such as access link capacity and delay. 1789 Alternatively, synthetic models such as [KPLKTS09] can be used to 1790 configure such topologies. 1792 Finally, the dynamic aspects of a topology, such as node and content 1793 mobility, disruption patterns, packet loss rates as well as link and 1794 node failure rates, to name a few, should also be carefully 1795 considered. As mentioned in subsection 2.9, for example, contact 1796 traces from the DTN community could also be used in ICN evaluations. 1798 3.3. Traffic Load 1800 As we are still lacking ICN-specific traffic workloads we can 1801 currently only extrapolate from today's workloads. In this 1802 subsection we provide a first draft of a set of common guidelines, in 1803 the form of what we will refer to as a content catalog for different 1804 scenarios. This catalog, which is based on previously published 1805 work, could be used to evaluate different ICN proposals, for example, 1806 on routing, congestion control, and performance, and can be 1807 considered as other kinds of ICN contributions emerge. 1809 We take scenarios from today's Web, file sharing (BitTorrent-like) 1810 and User Generated Content (UGC) platforms (e.g., YouTube), as well 1811 as Video on Demand (VoD) services. Publicly available traces for 1812 these include those available from web sites such as 1813 http://mikel.tlm.unavarra.es/~mikel/bt_pam2004, 1814 http://multiprobe.ewi.tudelft.nl/multiprobe.html, 1815 http://an.kaist.ac.kr/traces/IMC2007.html, and 1816 http://traces.cs.umass.edu/index.php/Network/Network. 1818 The content catalog for each type of traffic can be characterized by 1819 a specific set of parameters: the cardinality of the estimated 1820 content catalog, the average size of the exchanged contents (either 1821 chunks or entire named information objects), and the statistical 1822 distribution that best reflect the popularity of objects and their 1823 request frequency. Table I summarizes such as content catalog. With 1824 this shared point of reference, the use of the same set of parameters 1825 (depending on the scenario of interest) among researchers will be 1826 eased, and different proposals could be compared on a common base. 1828 Several previous studies have stated that Zipf's law is the discrete 1829 distribution that best represents the request frequency in a number 1830 of application scenarios, ranging from typical Web access to VoD 1831 services. The key aspect of this distribution is that the frequency 1832 of a content request is inversely proportional to the rank of the 1833 content itself, i.e., the smaller the rank, the higher the request 1834 frequency. If we denote with M the content catalog cardinality and 1835 with 1 <= i <= M the rank of the i-th most popular content, we can 1836 express the probability of requesting the content with rank "i" as: 1838 P(X=i) = ( 1/i^(alpha) ) / C, with C = SUM(1 / j^(alpha)), alpha > 0 1840 where the sum is obtained considering all values of j, 1 <= j <= M. 1842 Table I. Content Catalog 1844 Traffic | Catalog | Mean Object Size | Popularity Distribution 1845 Load | Size | [L4][L5][L7][L8] | [L3][L5][L6][L11][L12] 1846 | [L1][L2]| [L9][L10] | 1847 | [L3][L5]| | 1848 ================================================================== 1849 Web | 10^12 | Chunk: 1-10 kB | Zipf with 1850 | | | 0.64 <= alpha <= 0.83 1851 ------------------------------------------------------------------ 1852 File | 5x10^6 | Chunk: 250-4096 kB | Zipf with 1853 sharing | | Object: ~800 MB | 0.75 <= alpha<= 0.82 1854 ------------------------------------------------------------------ 1855 UGC | 10^8 | Object: ~10 MB | Zipf, alpha >= 2 1856 ------------------------------------------------------------------ 1857 VoD | 10^4 | Object: ~100 MB | Zipf, 0.65 <= alpha <= 1 1858 ================================================================== 1860 * UGC = User Generated Content ** VoD = Video on Demand 1862 Further, a variation of the Zipf distribution, termed the Mandelbrot- 1863 Zipf distribution, has been suggested by [SH06] to better model 1864 environments where nodes can locally store previously requested 1865 content. For example, it was observed that peer-to-peer file sharing 1866 applications typically exhibited a 'fetch-at-most-once' style of 1867 behavior. This is because peers tend to persistently store the files 1868 they download, a behavior that may also be prevalent in ICN. 1870 3.4. Choosing Relevant Metrics 1872 ICN is a networking concept that spun out of the desire to align the 1873 operation model of a network with the model of its typical use. For 1874 TCP/IP networks, this means a fundamental change in data access and 1875 transport mechanisms from a host-to-host model to a user-to- 1876 information model. The premise is that the effort invested in 1877 changing models will be offset, or even surpassed, by the potential 1878 of a "better" network. However, such a claim can be validated only 1879 if it is quantified. 1881 Quantification of network performance requires a set of standard 1882 metrics. These metrics should be broad enough so that they can be 1883 applied equally to host-centric and information-centric (or other) 1884 networks. This will allow reasoning about a certain ICN approach in 1885 relation to an earlier version of the same approach, to a different 1886 ICN approach, and to the incumbent host-centric approach. It will 1887 therefore be less difficult to gauge optimization and research 1888 direction. On the other hand, metrics should be targeted to network 1889 performance primarily and should avoid unnecessary expansion into the 1890 physical and application layers. Similarly, at this point, it is 1891 more important to capture as metrics only the main figures of merit 1892 and to leave more esoteric and less frequent cases for the future. 1894 To arrive at a set of relevant metrics, it would be beneficial to 1895 look at the metrics considered in previously published evaluations 1896 for several ICN approaches, such as CCN [CCN] [VoCCN] [NDNProj]; 1897 NetInf [4WARD6.1] [4WARD6.3] [SAIL-B2] [SAIL-B3]; PURSUIT [PRST4.5], 1898 COMET [CMT-D5.2] [CMT-D6.2]; Connect [MCG11] [RealCCN]; and 1899 CONVERGENCE [ICN-Web] [ICN-Scal] [ICN-Tran]. The metrics used in 1900 these studies fall into two categories: metrics for the approach as a 1901 whole, and metrics for individual components (resolution, routing, 1902 etc.). Metrics for the entire approach are further subdivided into 1903 traffic and system metrics. 1905 It is important to note that sometimes ICN approaches do not name or 1906 define metrics consistently. This is a major problem when trying to 1907 find metrics that allow comparison between approaches. For the 1908 purposes of exposition, in what follows we have tried to smooth 1909 differences by pitting similarly defined metrics under the same name. 1910 Also, due to space constraints, we have chosen to report here only 1911 the most common metrics between approaches. For more details the 1912 reader should consult the references provided in this document for 1913 each approach. 1915 Traffic metrics in existing ICN approaches are summarized in Table 1916 II. These metrics capture mainly the perspective of the end user, 1917 i.e., the consumer, provider, or owner of the content or service. 1918 Depending on the level where these metrics are measured, we have made 1919 the distinction into user, application and network-level traffic 1920 metrics. So, for example, network-level metrics are mostly focused on 1921 packet characteristics, whereas user-level metrics can cover elements 1922 of human perception. The approaches do not make this distinction 1923 explicitly, but we can see from the table that CCN and NetInf have 1924 used metrics from all levels, PURSUIT and COMET have focused on 1925 lower-level metrics, and Connect and CONVERGENCE prefer higher-level 1926 metrics. Throughput and download time seem to be the most popular 1927 metrics altogether. 1929 Table II. Traffic metrics used in ICN evaluation studies 1931 User | Application | Network 1932 ====================================================== 1933 Download | Goodput | Startup | Throughput | Packet 1934 time | | latency | | delay 1935 ================================================================== 1936 CCN | x | x | | x | x 1937 ------------------------------------------------------------------ 1938 NetInf | x | | x | x | x 1939 ------------------------------------------------------------------ 1940 PURSUIT | | | x | x | x 1941 ------------------------------------------------------------------ 1942 COMET | | | x | x | 1943 ------------------------------------------------------------------ 1944 Connect | x | | | | 1945 ------------------------------------------------------------------ 1946 CONVERGENCE | x | x | | | 1947 ================================================================== 1949 While traffic metrics are more important for the end user, the owner 1950 or operator of the networking infrastructure is normally more 1951 interested in system metrics, which can reveal the efficiency of an 1952 approach. Although different ICN approaches have used system metrics 1953 in their respective evaluation studies, the situation is not as 1954 coherent as with the traffic metrics. The most common system metrics 1955 used are: protocol overhead, total traffic, transit traffic, cost 1956 savings, router cost, and router energy consumption. 1958 Besides traffic and systems metrics that aim to evaluate an approach 1959 as a whole, all of the surveyed approaches also evaluate the 1960 performance of individual components. Name resolution, request/data 1961 routing, and data caching are the most typical components, so Table 1962 III presents the popular metrics for each of those components. FIB 1963 size and path length, i.e., the routing component metrics, are almost 1964 ubiquitous between different studies, perhaps due to the networking 1965 background of the involved researchers. That might be also the 1966 reason for the sometimes decreased focus on traffic and system 1967 metrics, in favor of component metrics. It can certainly be argued 1968 that traffic and system metrics are affected by component metrics, 1969 however no approach has made the relationship clear. With this in 1970 mind, and also taking into account that traffic and system metrics 1971 are readily useful to end users and network operators, we will 1972 restrict ourselves to those in the following sections. 1974 Table III. Component metrics in current ICN evaluations 1976 Resolution | Routing | Cache 1977 ====================================================== 1978 Resolution | Request | FIB | Path | Size | Hit 1979 time | rate | size | length | | ratio 1980 ================================================================== 1981 CCN | x | | x | x | x | x 1982 ------------------------------------------------------------------ 1983 NetInf | x | x | | x | | x 1984 ------------------------------------------------------------------ 1985 PURSUIT | | | x | x | | 1986 ------------------------------------------------------------------ 1987 COMET | x | x | x | x | | x 1988 ------------------------------------------------------------------ 1989 CONVERGENCE | | x | x | | x | 1990 ================================================================== 1992 Before proceeding, we should note that we would like our metrics to 1993 be applicable to host-centric networks as well. Standard metrics 1994 already exist for IP networks and it would certainly be beneficial to 1995 take them into account. It is encouraging that many of the metrics 1996 used by existing ICN approaches can also be used on IP networks and 1997 that all of the approaches have tried on occasion to draw the 1998 parallels. 2000 3.4.1. Traffic Metrics 2002 At their core, host-centric and information-centric networking 2003 function as data transport services. Information of interest to a 2004 user resides in one or more storage points connected to the network 2005 and, on the user's request, the network transports this information 2006 to the user for consumption. We could therefore quantify the data 2007 transport performance of the network in terms of well-established 2008 Quality of Service (QoS) metrics. 2010 The IETF has been working for more than a decade on devising metrics 2011 and methods for measuring the performance of IP networks. The work 2012 has been carried out largely within the IPPM WG, guided by a relevant 2013 framework [RFC2330]. IPPM metrics include delay, delay variation, 2014 loss, reordering, and duplication. While the IPPM work is certainly 2015 based on packet-switched IP networks, it is conceivable that it can 2016 be modified and extended to cover ICN networks as well. However, 2017 more study is necessary to turn this claim into a certainty. Many 2018 experts have toiled for a long time on devising and refining the IPPM 2019 metrics and methods, so it would be an advantage to use IPPM on 2020 measuring ICN performance. In addition, IPPM works already for host- 2021 centric networks, so comparison with information-centric networks 2022 would entail only the ICN extension of the IPPM framework. Finally, 2023 an important benefit of measuring the transport performance of a 2024 network at its output, using QoS metrics such as IPPM, is that it can 2025 be done mostly without any dependence on particular applications. 2027 Another option for measuring transport performance would be to use 2028 QoS metrics, not at the output of the network like with IPPM, but at 2029 the input to the application. So for an application like live video 2030 streaming, the relevant metrics would be startup latency, playout lag 2031 and playout continuity. The benefit of this approach is that it 2032 abstracts away all details of the underlying transport network, so it 2033 can be readily applied to compare networks of different architecture 2034 (host-centric, information-centric, or other). As implied earlier, 2035 the drawback of this approach is its dependence on the application, 2036 so it is likely that different (types of) applications will require 2037 different metrics. It might be possible to identify standard metrics 2038 for each type of application, but the situation is not as clear as 2039 with IPPM metrics and further investigation is necessary. 2041 At a higher level of abstraction, we could measure the network's 2042 transport performance at the application output. This entails 2043 measuring the quality of the transported and reconstructed 2044 information as perceived by the user during consumption. In such an 2045 instance we would use Quality of Experience (QoE) metrics, which are 2046 by definition dependent on the application. For example, the 2047 standardized methods for obtaining a Mean Opinion Score (MOS) for 2048 VoIP (e.g., ITU-T P.800) is quite different from those for IPTV 2049 (e.g., PEVQ). These methods are notoriously hard to implement, as 2050 they involve real users in a controlled environment. Such 2051 constraints can be relaxed or dropped by using methods that model 2052 human perception under certain environments, but these methods are 2053 typically intrusive. The most important drawback of measuring 2054 network performance at the output of the application is that only one 2055 part of each measurement is related to network performance. The rest 2056 is related to application performance, e.g., video coding, or even 2057 device capabilities, both of which are irrelevant to our purposes 2058 here and are generally hard to separate. We therefore see the use of 2059 QoE metrics in measuring ICN performance as a poor choice at this 2060 stage. 2062 3.4.2. System Metrics 2064 Overall system metrics that need to be considered include 2065 reliability, scalability, energy efficiency, and delay/disconnection 2066 tolerance. In deployments where ICN is addressing specific 2067 scenarios, relevant system metrics could be derived from current 2068 experience. For example, in IoT scenarios, which were discussed 2069 earlier in subsection 2.10, it is reasonable to consider the current 2070 generation of sensor nodes, sources of information, and even 2071 measurement gateways (e.g., for smart metering at homes) or 2072 smartphones. In this case, ICN operation ought to be evaluated with 2073 respect not only to overall scalability and network efficiency, but 2074 also the impact on the nodes themselves. Karnouskos et al. [KVHHM11] 2075 provide a comprehensive set of sensor and IoT-related requirements, 2076 for example, which include aspects such as resource utilization, 2077 service life-cycle management and device management. 2079 Additionally, various specific metrics are critical in constrained 2080 environments, such as CPU processing requirements, signaling 2081 overhead, and memory allocation for caching procedures in addition to 2082 power consumption and battery lifetime. For gateway nodes, which are 2083 typically a point of service to a large number of nodes and have to 2084 satisfy the information requests from remote entities, we need to 2085 consider scalability-related metrics, such as frequency of requests 2086 received and processing of successfully satisfied information 2087 requests. 2089 Finally, given the in-network caching functionality in ICN, metrics 2090 for the efficiency and performance of in-network caching have to be 2091 defined, which can quantify the performance of in-network caching 2092 algorithms. A first step on this direction has been made in [L9]. 2093 The paper proposes a formula that approximates the proportion of time 2094 that a data object is stored in a network cache. The model takes as 2095 input the rate of requests for a given content, named the Content of 2096 Interest (CoI), and the rate of requests for all other data objects 2097 that go through the given network element (router) and move the CoI 2098 down in the (LRU) cache. The formula takes also into account the 2099 size of the cache of this router. 2101 The output of the model essentially reflects the probability that the 2102 CoI will be found in a given cache. The initial study [L9] is 2103 applied to the CCN/NDN framework, where contents get cached at every 2104 node they traverse, while efforts are underway to assess the accuracy 2105 of the model for other caching strategies. The formula according to 2106 which the probability or proportion is calculated is given by: 2108 pi = [mu/(mu+lambda)]^N, 2110 where lambda is the request rate for CoI, mu is the request rate for 2111 contents that move CoI down the cache, and N is the size of the cache 2112 (in slots). 2114 The formula can be used to assess the caching performance of the 2115 system and can also potentially be used to identify the gain of the 2116 system due to caching. This can then be used to compare against 2117 gains by other factors, e.g., addition of extra bandwidth in the 2118 network. 2120 3.5. Resource Equivalence and Tradeoffs 2122 As we have seen above, every information-centric network is built 2123 from a set of resources, which include link capacities, different 2124 types of memory structures and repositories used for storing named 2125 information objects and chunks temporarily (i.e. caching) or 2126 persistently, as well as name resolution and other lookup services. 2127 Complexity and processing needs in terms of forwarding decisions, 2128 management (e.g., need for manual configuration, explicit garbage 2129 collection, and so on), and routing (i.e., amount of state needed, 2130 need for manual configuration of routing tables, support for 2131 mobility, etc.) set the stage for a range of engineering tradeoffs. 2133 In order to be able to compare different ICN approaches it would be 2134 beneficial to to define equivalence in terms of different resources 2135 which today are considered incomparable. For example, would 2136 provisioning an additional 5 Mb/s link capacity lead to better 2137 performance than adding 100 GB of in-network storage? Within this 2138 context one would consider resource equivalence (and the associated 2139 tradeoffs) for example for cache hit ratios per GB of cache, 2140 forwarding decision times, CPU cycles per forwarding decision, and so 2141 on. 2143 3.6. Technology Evolution Assumptions 2145 TBD 2147 4. Security Considerations 2149 The introduction of an information-centric networking architecture 2150 and the corresponding communication paradigm changes many aspects of 2151 network security. Additional evaluation will be required to ensure 2152 relevant security requirements are appropriately met by the 2153 implementation of the chosen architecture in the scenarios presented 2154 in Section 2. 2156 The various ICN architectures that are currently proposed have 2157 concentrated on authentication of delivered content to ensure content 2158 integrity. However the approaches are primarily applicable to freely 2159 accessible content that does not require access authorization, 2160 although they will generally support delivery of encrypted content. 2162 The introduction of widespread caching mechanisms may also provide 2163 additional attack surfaces. The caching architecture to be used also 2164 needs to be evaluated to ensure that it meets the requirements of the 2165 usage scenarios. 2167 In practice, the work on security in the various ICN research 2168 projects has been heavily concentrated on authentication of content. 2169 In general, work on authorization, access control, privacy and 2170 security threats due to the expanded role of in-network caches has 2171 been quite limited. A roadmap for improving the security model in 2172 NetInf can be found in [RAA09]. In the rest of this section we 2173 briefly consider the issues at hand and provide pointers to the work 2174 that has been done on the security aspects of the architectures 2175 proposed. 2177 4.1. Authentication 2179 For fully secure content distribution, content access requires that 2180 the receiver needs to be able to reliably assess validity, 2181 provenance, and relevance. Validity relates to whether the received 2182 data object is a complete, uncorrupted copy of what was originally 2183 published. Provenance means that the receiver can identify the 2184 publisher, and, if so, whether it and the source of any cached 2185 version of the document can be adequately trusted. Relevance 2186 ascertains that the content obtained answers the question that the 2187 receiver asked. 2189 All ICN architectures considered in this document primarily target 2190 the validity requirement using strong cryptographic means to tie the 2191 content request name to the content. Provenance and relevance are 2192 directly targeted to varying extents: There is a tussle or trade-off 2193 between simplicity and efficiency of access and level of assurance of 2194 all these traits. For example, maintaining provenance information 2195 can become extremely costly, particularly when considering (historic) 2196 relationships between multiple objects. Architectural decisions have 2197 therefore been taken in each case as to whether the assessment is 2198 carried out by the ICN or left to the application. 2200 An additional consideration for authentication is whether a name 2201 should be irrevocably and immutably tied to a static piece of 2202 preexisting content or whether the name can be used to refer to 2203 dynamically or subsequently generated content. Schemes that only 2204 target immutable content can be less resource hungry as they can use 2205 digest functions rather than public key cryptography for generating 2206 and checking signatures. However, this can increase the load on 2207 applications as they are required to manage many names, rather than 2208 using a single name for an item of evolving content that changes over 2209 time (e.g. a piece of data containing an age reference). 2211 NetInf, for instance, uses the Named Information (ni) URI scheme 2212 [RFC6920] to identify content. This allows NetInf to assure validity 2213 without any additional information but gives no assurance on 2214 provenance or relevance. A "search" request allows an application to 2215 identify relevant content. Applications may choose to structure 2216 content to allow provenance assurance but this will typically require 2217 additional network access. NetInf validity authentication is 2218 consequently efficient in a network environment with intermittent 2219 connectivity as it does not force additional network accesses and 2220 allows the application to decide on provenance validation if 2221 required. NetInf primarily targets static content, but an extension 2222 would allow dynamic content to be handled. The immutable case only 2223 uses digest functions. 2225 DONA [DONA] and CCN [CCN] [SJ09] integrate most of the data needed to 2226 verify provenance into all content retrievals but need to be able to 2227 retrieve additional information (typically a security certificate) in 2228 order to complete the provenance authentication. Whether the 2229 application has any control of this extra retrieval will depend on 2230 the implementation. CCN is explicitly designed to handle dynamic 2231 content allowing names to be pre-allocated and attached to 2232 subsequently generated content. DONA offers variants for dynamic and 2233 immutable content. 2235 PSI allows the authentication mechanism to be chosen so that it can, 2236 in theory, adopt the authentication strategy of any other other 2237 architectures [PRST2.4]. In the light of such choices, however, 2238 interoperability (if required by the chosen deployment) needs to be 2239 taken care of through dedicated solutions. 2241 4.2. Authorization, Access Control and Statistics 2243 A potentially major concern for all ICN architectures considered here 2244 is that they do not provide any inbuilt support for an authorization 2245 framework or for statistics monitoring. Once content has been 2246 published and cached in servers, routers or end points not controlled 2247 by the publisher, the publisher has no way to enforce access control, 2248 determine which users have accessed the content or revoke its 2249 publication. In fact, in some cases, it is even difficult for the 2250 publishers themselves to perform access control, where requests do 2251 not necessarily contain host/user identifier information. 2253 Access could be limited by encrypting the content but the necessity 2254 of distributing keys out-of-band appears to negate the advantages of 2255 in-network caching. This also creates significant challenges when 2256 attempting to manage and restrict key access. An authorization 2257 delegation scheme has been proposed in [FMP12] but this requires 2258 access to a server controlled by the publisher to obtain an access 2259 token making it essentially just an out-of-band key distribution 2260 system. 2262 Evaluating the impact of the absence of these features will be 2263 essential for any scenario where an ICN architecture might be 2264 deployed. It may have a seriously negative impact on the 2265 applicability of ICN in commercial environments unless a solution can 2266 be found. 2268 4.3. Privacy 2270 Another area where the architectures have not been significantly 2271 analyzed is privacy. Caching implies a trade-off between network 2272 efficiency and privacy. The activity of users is significantly more 2273 exposed to the scrutiny of cache owners with whom they may not have 2274 any relationship. 2276 Although in many ICN architectures, the source of a request is not 2277 explicitly identified, an attacker may be able to obtain considerable 2278 information if s/he can monitor transactions on the cache and obtain 2279 details of the objects accessed, the topological direction of 2280 requests and information about the timing of transactions. The 2281 persistence of data in the cache can make life easier for an attacker 2282 by giving a longer timescale for analysis. 2284 The impact of CCN on privacy has been investigated in [Lau10]. The 2285 analysis in this master's thesis is to a large degree applicable to 2286 all of ICN architectures because it is mostly focused on the common 2287 caching aspect. The privacy risks of named data networking are also 2288 highlighted in [LLRSBK12]. Further work on privacy in ICNs can be 2289 found in [CDKU12]. 2291 4.4. Changes to the Network Security Threat Model 2293 The architectural differences of the various ICN models as compared 2294 to TCP/IP have consequences for network security. There is limited 2295 consideration of the threat models and potential mitigation in the 2296 various documents describing the architectures. The changed threat 2297 model is also discussed in [Lau10] and [CDKU12]. Some of the key 2298 aspects are: 2300 o Caching implies a tradeoff between network efficiency and user 2301 privacy as discussed in subsection 4.3. 2303 o More powerful routers upgraded to handle persistent caching 2304 increase the network's attack surface. This is particularly the 2305 case in systems (e.g., CCN) that may need to perform cryptographic 2306 checks on content that is being cached. For example, not doing 2307 this could lead routers to disseminate invalid content. 2309 o ICN makes it difficult to identify the origin of a request as 2310 mentioned in subsection 4.3, slowing down the process of blocking 2311 requests and requiring alternative mechanisms to differentiate 2312 legitimate requests from inappropriate ones, as access control 2313 lists (ACLs) will probably be of little value for ICN requests. 2315 o Denial-of-service (DoS) attacks may require more effort on ICN 2316 than in TCP/IP, but they are still feasible. One reason for this 2317 is that it is difficult for the attacker to force repeated 2318 requests for the same content onto a single node. Information- 2319 centric networks naturally spread content so that after the 2320 initial few requests, subsequent requests will generally be 2321 satisfied by alternative sources, blunting the impact of a DoS 2322 attack. That said, there are many ways around this, e.g., 2323 generating random suffix identifiers that always result in cache 2324 misses. 2326 o Per-request state in routers can be abused for DoS attacks. 2328 o Caches can be misused in the following ways: 2330 + Attackers can use caches as storage to make their own content 2331 available. 2333 + The efficiency of caches can be decreased by attackers with the 2334 goal of DoS attacks. 2336 + Content can be extracted by any attacker connected to the 2337 cache, putting users' privacy at risk. 2339 Appropriate mitigation of these threats will need to be considered in 2340 each scenario. 2342 5. IANA Considerations 2344 This document presents no IANA considerations. 2346 6. Acknowledgments 2348 This document has benefited from pointers to the growing ICN 2349 literature, suggestions, comments and proposed text provided by the 2350 following members of the IRTF Information-Centric Networking Research 2351 Group (ICNRG), listed in alphabetical order: Marica Amadeo, Hitoshi 2352 Asaeda, Claudia Campolo, Luigi Alfredo Grieco, Myeong-Wuk Jang, Ren 2353 Jing, Will Liu, Ioannis Psaras, Dirk Trossen, Jianping Wang, Yuanzhe 2354 Xuan, and Xinwen Zhang. 2356 7. Informative References 2358 [RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, 2359 R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant 2360 Networking Architecture", RFC 4838, April 2007. 2362 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 2363 Keranen, A., and P. Hallam-Baker, "Naming Things with 2364 Hashes", RFC 6920, April 2013. 2366 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 2367 "Framework for IP Performance Metrics", RFC 2330, May 2368 1998. 2370 [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol 2371 Specification", RFC 5050, November 2007. 2373 [ndnSIM] Afanasyev, A., Moiseenko, I., and L. Zhang, "ndnSIM: NDN 2374 simulator for NS-3", NDN Technical Report NDN-0005, 2375 Revision 2, October 2012. 2377 [NetInf] Ahlgren, B., D'Ambrosio, M., Marchisio, M., Marsh, I., 2378 Dannewitz, D., Ohlman, B., Pentikousis, K., Strandberg, 2379 O., Rembarz, R., and V. Vercellone, "Design considerations 2380 for a network of information", Proc. CoNEXT Re-Arch 2381 Workshop, p. 66. ACM, 2008. 2383 [ACM12] Amadeo, M., Campolo, C. and A. Molinaro, "Content-centric 2384 networking: is that a solution for upcoming vehicular 2385 networks?." In Int. workshop on Vehicular inter- 2386 networking, systems, and applications, pp. 99-102. ACM, 2387 2012. 2389 [CRoWN] Amadeo, M., Campolo, C. and A. Molinaro, "CRoWN: Content- 2390 Centric Networking in Vehicular Ad Hoc Networks", 2391 Communications Letters, IEEE, vol. 16, no. 9 (2012): 1380- 2392 1383. 2394 [AMR13] Amadeo, M., Molinaro, A., and G. Ruggeri, "E-CHANET: 2395 Routing, forwarding and transport in Information-Centric 2396 multihop wireless networks", Computer Communications 2397 (2013). 2399 [ANO10] Arianfar, S., Nikander, P., and J. Ott, "On content- 2400 centric router design and implications", Proc. Re- 2401 Architecting the Internet Workshop, p. 5. ACM, 2010. 2403 [AKH11] Arnould, G., Khadraoui D., and Z. Habbas, "A self- 2404 organizing content centric network model for hybrid 2405 vehicular ad-hoc networks." Proc. ACM Int. Symp. Design 2406 and analysis of intelligent vehicular networks and 2407 applications, pp. 15-22. ACM, 2011. 2409 [BK10] Bai, F. and B. Krishnamachari, "Exploiting the wisdom of 2410 the crowd: localized, distributed information-centric 2411 VANETs", Communications Magazine, IEEE, vol. 48, no. 5 2412 (2010): 138-146. 2414 [BA99] Barabasi, A. and R. Albert, "Emergence of scaling in 2415 random networks", Science, vol. 286, no. 5439, pp. 509- 2416 512, 1999. 2418 [CDKU12] Chaabane, A., De Cristofaro, E., Kaafar, M. A., and E. 2419 Uzun, "Privacy in Content-Oriented Networking: Threats and 2420 Countermeasures", arXiv:1211.5183, 2012. 2422 [CURLING] Chai, W. K., Wang, N., Psaras, I., and G. Pavlou, 2423 "CURLING: Content-Ubiquitous Resolution and Delivery 2424 Infrastructure for Next-Generation Services", 2425 Communications Magazine, IEEE, vol. 49, no. 3 (2011): 112- 2426 120. 2428 [CHPP12] Chai, W. K., He, D., Psaras, I., and G. Pavlou, "Cache 2429 'less for more' in information-centric networks," Proc. 2430 NETWORKING 2012, pp. 27-40. Springer, 2012. 2432 [CGB12] Cianci, I. Grieco, L. A., and G. Boggia, "CCN - Java 2433 Opensource Kit EmulatoR for Wireless Ad Hoc Networks", 2434 Proc. 7th Int. Conf. on Future Internet Technologies, pp. 2435 7-12. ACM, 2012. 2437 [FMP12] Fotiou, N., Marias, G. F., and G. C. Polyzos, "Access 2438 control enforcement delegation for information-centric 2439 networking architectures", Proc. ACM SIGCOMM Workshop on 2440 Information-centric networking, pp. 85-90. ACM, 2012. 2442 [Montage] Hussain, A. and J. Chen, "Montage Topology Manager: Tools 2443 for Constructing and Sharing Representative Internet 2444 Topologies", DETER Technical Report, ISI-TR-684, Aug. 2445 2012. 2447 [CCN] Jacobson, V., Smetters, D. K., Thornton, J. D., Plass, M. 2448 F., Briggs, N. H., and R. L. Braynard, "Networking Named 2449 Content", Proc. CoNEXT, pp. 1-12. ACM, 2009. 2451 [VoCCN] Jacobson, V., Smetters, D. K., Briggs, N. H., Plass, M. 2452 F., Stewart, P., Thornton, J. D., and R. L. Braynard, 2453 "VoCCN: Voice-over Content-Centric Networks", Proc. CoNEXT 2454 Re-Arch Workshop, pp. 1-6. ACM, 2009. 2456 [JBDMM+12] Jacobson, V., Braynard, R. L., Diebert, T., Mahadevan, P., 2457 Mosko, M., Briggs, N. H., Barber, S., et al., "Custodian- 2458 based information sharing", Communications Magazine, IEEE, 2459 vol. 50, no. 7 (2012): 38-43. 2461 [KVHHM11] Karnouskos, S., Villasenor-Herrera, V., Haroon, M., 2462 Handte, M. and P. J. Marron, "Requirement considerations 2463 for ubiquitous integration of cooperating objects", Proc. 2464 IFIP NTMS, pp. 1-5. IEEE, 2011. 2466 [KPLKTS09] Kaune, S., Pussep, K., Leng, C., Kovacevic, A., Tyson, G., 2467 and R. Steinmetz, "Modelling the internet delay space 2468 based on geographical locations", Proc. Euromicro, pp. 2469 301-310. IEEE, 2009. 2471 [SLINKY] Kawadia, V., Riga, N., Opper, J., and D. Sampath, "Slinky: 2472 An adaptive protocol for content access in disruption- 2473 tolerant ad hoc networks", Proc. MobiHoc Workshop on 2474 Tactical Mobile Ad Hoc Networking, 2011. 2476 [DONA] Koponen, T., Chawla, M., Chun, B. G., Ermolinskiy, A., 2477 Kim, K. H., Shenker, S., and I. Stoica, "A Data-Oriented 2478 (and Beyond) Network Architecture", ACM SIGCOMM Computer 2479 Communication Review, vol. 37, no. 4, pp. 181-192. ACM, 2480 2007. 2482 [Lau10] Lauinger, T., "Security and Scalability of Content-Centric 2483 Networking", Masters Thesis, Technische Universitaet 2484 Darmstadt and Eurecom, Sep. 2010. 2486 [LLRSBK12] Lauinger, Y., Laoutaris, N., Rodriguez, P., Strufe, T., 2487 Biersack, E., and E. Kirda, "Privacy Risks in Named Data 2488 Networking: What is the Cost of Performance?", ACM SIGCOMM 2489 Computer Communication Review 42, no. 5 (2012): 54-57. 2491 [Lin11] Lindgren, A., "Efficient content distribution in an 2492 information-centric hybrid mobile network", Proc. Consumer 2493 Communications and Networking Conference (CCNC), 2011 2494 IEEE, pp. 1134-1138. IEEE, 2011. 2496 [MPZ10] Meisel, M., Pappas, V., and L. Zhang, "Ad hoc networking 2497 via named data", Proc. Int. Workshop on Mobility in the 2498 Evolving Internet Architecture, pp. 3-8. ACM, 2010. 2500 [MCG11] Muscariello, L., Carofiglio, G., and M. Gallo, "Bandwidth 2501 and storage sharing performance in information centric 2502 networking", Proc. ACM SIGCOMM Workshop on Information- 2503 centric networking, pp. 26-31. ACM, 2011. 2505 [CCNPL] Muscariello, L. and M. Gallo, "Content centric networking 2506 packet level simulator", available online at 2507 http://code.google.com/p/ccnpl-sim/ 2509 [OLG10] Oh, S.-Y., Lau, D., and M. Gerla. "Content centric 2510 networking in tactical and emergency manets", Proc. 2511 Wireless Days (WD), 2010 IFIP, pp. 1-5. IEEE, 2010. 2513 [PTA13] Parisis, G., Trossen, D., and H. Asaeda, "A Node Design 2514 and a Framework for Development and Experimentation for an 2515 Information-Centric Network", IEICE Trans. Commun., vol. 2516 E96-B, no. 7, pp. 1650-1660, July 2013. 2518 [PCP12] Psaras, I., Chai, W., and G. Pavlou, "Probabilistic In- 2519 Network Caching for Information-Centric Networks", Proc. 2520 ACM SIGCOMM Workshop on Information-centric networking, 2521 pp. 55-60. ACM, 2012. 2523 [RAA09] Renault, E., Ahmad, A., and M. Abid, "Towards a Security 2524 Model for the Future Network of Information", Proc. Int. 2525 Conf. Ubiquitous Information Technologies and 2526 Applications, pp. 1-6. IEEE, 2009. 2528 [ccnSim] Rossini, G. and D. Rossi, "Large scale simulation of CCN 2529 networks", Proc. Algotel 2012 , La Grande Motte, France, 2530 May 2012. 2532 [SCP13] Saino, L., Cocora, C., and G. Pavlou, "A Toolchain for 2533 Simplifying Network Simulation Setup", Proc. SIMUTOOLS. 2534 ACM, 2013. 2536 [SPP13] Saino, L., Psaras, I. , and G. Pavlou, "Hash-routing 2537 Schemes for Information-Centric Networking", Proc. ACM 2538 SIGCOMM Workshop on Information-centric networking. ACM, 2539 2013. 2541 [SH06] Saleh, O., and M. Hefeeda, "Modeling and caching of peer- 2542 to-peer traffic", Proc. ICNP, pp. 249-258. IEEE, 2006. 2544 [SJ09] Smetters, D., and V. Jacobson, "Securing network content", 2545 Technical Report TR-2009-01, PARC, 2009. 2547 [TL12] TalebiFard, P. and V. Leung, "A content centric approach 2548 to dissemination of information in vehicular networks", 2549 Proc. ACM Int. Symp. Design and analysis of intelligent 2550 vehicular networks and applications, pp. 17-24. ACM, 2012. 2552 [PSI] Trossen, D. and G. Parisis, "Designing and realizing an 2553 information-centric internet", Communications Magazine, 2554 IEEE, vol. 50, no. 7 (2012): 60-67. 2556 [TKMEMT12] Tyson, G., Kaune, S., Miles, S., El-khatib, Y., Mauthe, 2557 A., and A. Taweel, "A trace-driven analysis of caching in 2558 content-centric networks", Proc. Computer Communications 2559 and Networks (ICCCN), 2012 21st International Conference 2560 on, pp. 1-7. IEEE, 2012. 2562 [TBB13] Tyson, G., Bigham J., and E. Bodanese, "Towards an 2563 Information-Centric Delay-Tolerant Network", Proc. IEEE 2564 INFOCOM Workshop on Emerging Design Choices in Name- 2565 Oriented Networking (NOMEN). 2013. 2567 [VBYR12] Vastardis, N., Bontozoglou, A., Yang, K., and M. Reed, 2568 "Simulation tools enabling research on Information-centric 2569 Networks", Proc. IEEE ICC, pp. 5833-5838. IEEE, 2012. 2571 [DMND] Wang, J., Wakikawa, R., and L. Zhang, "DMND: Collecting 2572 data from mobiles using named data", Proc. Vehicular 2573 Networking Conference (VNC), 2010 IEEE, pp. 49-56. IEEE, 2574 2010. 2576 [WAKVWZ12] Wang, L., Afanasyev, A., Kuntz, R., Vuyyuru, R., Wakikawa, 2577 R., and L. Zhang, "Rapid traffic information dissemination 2578 using named data", In Workshop on Emerging Name-Oriented 2579 Mobile Networking Design-Architecture, Algorithms, and 2580 Applications, pp. 7-12. ACM, 2012. 2582 [WWKVZ12] Wang, L., Wakikawa, R., Kuntz, R., Vuyyuru, R., and L. 2583 Zhang, "Data naming in vehicle-to-vehicle communications", 2584 Proc. Computer Communications Workshops (INFOCOM WKSHPS), 2585 2012 IEEE Conference on, pp. 328-333. IEEE, 2012. 2587 [WS98] Watts, D. J. and S. H. Strogatz, "Collective dynamics of 2588 small-world networks", Nature, vol. 393, no. 6684, pp. 40- 2589 "10, 1998. 2591 [NDNProj] Zhang, L., Estrin, D., Burke, J., Jacobson, V., Thornton, 2592 J. D., Smetters, D. K., Zhang, B., et al. , "Named Data 2593 Networking (NDN) Project", NDN Technical Report NDN-0001, 2594 Oct. 2010. 2596 [SoA] Ahlgren, B. et al., "A survey of information-centric 2597 networking", IEEE Commun. Mag., vol. 50, no. 7, July 2012. 2599 [ICN-SN] Mathieu, B. et al., "Information-centric networking: a 2600 natural design for social network applications", IEEE 2601 Commun. Mag., vol. 50, no. 7, July 2012. 2603 [VPC] Kim, J. et al., "Content Centric Network-based Virtual 2604 Private Community", Proc. ICCE. IEEE, 2011. 2606 [VPC2] Kim, D. and J. Lee, "CCN-based virtual private community 2607 for extended home media service", IEEE Trans. Consumer 2608 Electronics, vol. 57, no. 2, May 2011. 2610 [ACT] Zhu, Z. et al., "ACT: Audio Conference Tool Over Named 2611 Data Networking", Proc. SIGCOMM ICN Workshop. ACM, 2011. 2613 [G-COPSS] Chen, J. et al., "G-COPSS: A Content Centric Communication 2614 Infrastructure for Gaming Applications", Proc. ICDCS. 2615 IEEE, 2012. 2617 [SCES] Allman, M. et al., "Enabling an Energy-Efficient Future 2618 Internet through Selectively Connected End Systems", Proc. 2619 HotNets-VI. ACM, 2007. 2621 [EEMN] Pentikousis, K., "In Search of Energy-Efficient Mobile 2622 Networking", IEEE Commun. Mag., vol. 48, no. 1, Jan. 2010. 2624 [MOBSURV] Tyson, G. et al., "A Survey of Mobility in Information- 2625 Centric Networks: Challenges and Research Directions", 2626 Proc. MobiHoc Workshop on Emerging Name-Oriented Mobile 2627 Networking Design. ACM, 2012. 2629 [N-Scen] Dannewitz, C. et al., "Scenarios and research issues for a 2630 Network of Information", Proc. MobiMedia. ICST, 2012. 2632 [DTI] Ott, J. and D. Kutscher, "Drive-thru Internet: IEEE 2633 802.11b for 'automobile' users", Proc. INFOCOM. IEEE, 2634 2004. 2636 [PSIMob] Xylomenos, G. et al., "Caching and Mobility Support in a 2637 Publish-Subscribe Internet Architecture", IEEE Commun. 2638 Mag., vol. 50, no. 7, July 2012. 2640 [mNetInf] Pentikousis, K. and T. Rautio, "A Multiaccess Network of 2641 Information", Proc. WoWMoM. IEEE, 2010. 2643 [ArgICN] Trossen, D. et al., "Arguments for an information centric 2644 internetworking architecture", ACM SIGCOMM CCR, 40:26-33, 2645 Apr. 2010. 2647 [EconICN] Agyapong, P. and M. Sirbu, "Economic Incentives in 2648 Information Centric Networking: Implications for Protocol 2649 Design and Public Policy", IEEE Commun. Mag., vol. 50, no. 2650 12, Dec. 2012. 2652 [OptSC] Paolini, M. Optimizing the Small-Cell Business ROI, 2653 SmallCell Americas 2012, available online at 2654 www.smallcellsamericas.com/files/ 2655 monica_paolini_senza_fili_consulting.pdf 2657 [FEMTO] Rioridan, R. Using FemtoCloud technology to deliver 2658 femtocell-as-a-service, SmallCell Americas 2012, available 2659 online at www.smallcellsamericas.com/files/ 2660 1110rob_riordan_femto_america_2012.pdf 2662 [MLDHT] Liu H. et al., "A multi-level DHT routing framework with 2663 aggregation", Proc. SIGCOMM ICN Workshop. ACM, 2012. 2665 [RP-NDN] DiBenedetto S. et al., "Routing policies in named data 2666 networking", Proc. SIGCOMM ICN Workshop. ACM, 2011. 2668 [LIPSIN] Jokela P. et al., "LIPSIN: line speed publish/subscribe 2669 inter-networking", Proc. of ACM SIG-COMM 2009. 2671 [LANES] Visala K. et al., "LANES: An Inter-Domain Data-Oriented 2672 Routing Architecture", Proc. CoNEXT Re-Arch Workshop. 2673 ACM, 2009. 2675 [PSIRP1] Rajahalme, J. et al., "Inter-Domain Rendezvous Service 2676 Architecture", PSIRP Technical Report TR09-003, Dec. 2009. 2678 [ICCP] Rajahalme J. et al., "Incentive-Compatible Caching and 2679 Peering in DataOriented Networks", Proc. CoNEXT Re-Arch 2680 Workshop. ACM, 2008. 2682 [IDMcast] Rajahalme, J., "Incentive-informed Inter-domain 2683 Multicast", Proc. Global Internet Symposium 2010. 2685 [IDArch] Rajahalme J., "Inter-domain incentives and Internet 2686 architecture", PhD. Dissertation, Aalto University, Aug. 2687 2012. 2689 [SAIL-B2] SAIL, "NetInf Content Delivery and Operations", SAIL 2690 Project Deliverable D-B.2, May. 2012. 2692 [SAIL-B3] SAIL, "Final NetInf Architecture", SAIL Project 2693 Deliverable D-B.3 , Jan. 2013. 2695 [SAIL-A7] SAIL, "New business models and business dynamics of the 2696 future networks", SAIL Project Deliverable D-A.7, Aug. 2697 2011. 2699 [SAIL-A8] SAIL, "Evaluation of business models", SAIL Project 2700 Deliverable D-A.8, Jan. 2013. 2702 [EECCN] Guan, K. et al., "On the Energy Efficiency of Content 2703 Delivery Architectures", Proc. ICC Workshops. IEEE, 2011. 2705 [DTN] Fall, K., "A delay-tolerant network architecture for 2706 challenged internets", Proc. SIGCOMM. ACM, 2003. 2708 [BPQ] S. Farrell, A. Lynch, D. Kutscher, and A. Lindgren, 2709 "Bundle protocol query extension block", draft-irtf-dtnrg- 2710 bpq-00 (work in progress), May 2012. 2712 [TWIMIGHT] Hossmann, Theus, et al. "Twitter in disaster mode: smart 2713 probing for opportunistic peers", Proc. of the third ACM 2714 international workshop on Mobile Opportunistic Networks. 2715 ACM, 2012. 2717 [ONE] The Opportunistic Network Environment simulator. 2718 Available at http://www.netlab.tkk.fi/tutkimus/dtn/theone 2720 [IoTEx] Burke, J., "Authoring Place-based Experiences with an 2721 Internet of Things: Tussles of Expressive, Operational, 2722 and Participatory Goals", Proc. Interconnecting Smart 2723 Objects with the Internet Workshop. IAB, 2011. 2725 [IWMT] Kutscher, D. and S. Farrell, "Towards an Information- 2726 Centric Internet with more Things", Proc. Interconnecting 2727 Smart Objects with the Internet Workshop. IAB, 2011. 2729 [RFC6920] Farrell, S. et al., "Naming Things with Hashes", RFC 6920, 2730 April 2013. 2732 [NCOA] Ghodsi, A. et al., "Naming in Content-oriented 2733 Architectures", Proc. SIGCOMM ICN Workshop. ACM, 2011. 2735 [nWSN] Heidemann, J. et al., "Building efficient wireless sensor 2736 networks with low-level naming", Proc. SOSP. ACM, 2001. 2738 [NDNl] Burke, J. et al., "Authenticated Lighting Control Using 2739 Named Data Networking", NDN Technical Report NDN-0011, 2740 Oct. 2012. 2742 [IoTScope] Marias, G.F. et al., "Efficient information lookup for the 2743 Internet of Things", Proc. WoWMoM. IEEE, 2012. 2745 [PURSUIT] Fotiou, N. et al., "Developing Information Networking 2746 Further: From PSIRP to PURSUIT", Proc. BROADNETS. ICST, 2747 2010. 2749 [ICN-DHT] Katsaros, K. et al., "On inter-domain name resolution for 2750 information-centric networks", Proc. Networking. 2751 Springer, 2012. 2753 [SEMANT] Sheth, A. et al., "Semantic Sensor Web," Internet 2754 Computing, IEEE , vol.12, no.4, pp.78,83, July-Aug. 2008 2756 [CPG] Cianci, I. et al., "Content Centric Services in Smart 2757 Cities", Proc. NGMAST. IEEE, 2012. 2759 [MVM] Hernndez-Muoz, J.M. et al., "Smart cities at the forefront 2760 of the future Internet", The Future Internet. Springer, 2761 2011. 2763 [iHEMS] Zhang, J. et al., "iHEMS: An Information-Centric Approach 2764 to Secure Home Energy Management", Proc. SmartGridComm. 2765 IEEE, 2012. 2767 [ACC] Andreini, F. et al., "A scalable architecture for geo- 2768 localized service access in smart cities", Proc. Future 2769 Network and Mobile Summit. IEEE, 2011. 2771 [IB] Idowu, S. and N. Bari, "A Development Framework for Smart 2772 City Services, Integrating Smart City Service Components", 2773 Master Thesis. Lulea University of Technology, 2012. 2775 [L1] http://googleblog.blogspot.it/2008/07/we-knew-web-was- 2776 big.html 2778 [L2] C. Zhang, P. Dhungel, and K. Di Wu., "Unraveling the 2779 BitTorrent ecosystem", IEEE Transactions on Parallel and 2780 Distributed Systems, pp. 1164-1177, 2010. 2782 [L3] M. Cha, H. Kwak, P. Rodriguez, Y.-Y. Ahn, and S. Moon, "I 2783 tube, you tube, everybody tubes: analyzing the world's 2784 largest user generated content video system", Proc. ACM 2785 SIGCOMM conference on Internet measurement (IMC), San 2786 Diego (CA), USA, Oct. 2007. 2788 [L4] J. Zhou, Y. Li, K. Adhikari, and Z.-L. Zhang, "Counting 2789 YouTube videos via random prefix sampling", In Proc. of 2790 IMC'11, Berlin, Germany, Nov. 2011. 2792 [L5] C. Fricker, P. Robert, J. Roberts, and N. Sbihim, "Impact 2793 of traffic mix on caching performance in a content-centric 2794 network", Proc. Computer Communications Workshops (INFOCOM 2795 WKSHPS), 2012 IEEE Conference on, pp. 310-315. IEEE, 2012. 2797 [L6] H. Yu, D. Zheng, B. Y. Zhao, and W. Zheng, "Understanding 2798 user behavior in large-scale video-on-demand systems", In 2799 SIGOPS Oper. Syst. Rev., Vol. 40, pp. 333-344, April 2006. 2801 [L7] P. Marciniak, N. Liogkas, A. Legout, and E. Kohler, "Small 2802 is not always beautiful", In Proc. of IPTPS, 2803 International Workshop of Peer-to-Peer Systems, Tampa Bay, 2804 Florida (FL), USA, Feb. 2008. 2806 [L8] A. Bellissimo, B. Levine, and P. Shenoy, "Exploring the 2807 use of BitTorrent as the basis for a large trace 2808 repository", University of Massachusetts, Tech. Rep., 2809 2004. 2811 [L9] I. Psaras, R. G. Clegg, R. Landa, W. K. Chai, and G. 2812 Pavlou, "Modelling and Evaluation of CCN-Caching Trees", 2813 In Proc. of the 10th international IFIP conference on 2814 Networking, Valencia, Spain, May 2011. 2816 [L10] G. Carofiglio, M. Gallo, L. Muscariello, and D. Perino, 2817 "Modeling Data Transfer in Content-Centric Networking", In 2818 Proc. of ITC, San Francisco, USA, Sep. 2011. 2820 [L11] L. Breslau, P. Cao, L. Fan, G. Phillips, and S. Shenker, 2821 "Web caching and zipf-like distributions: evidence and 2822 implications", In Proc. of INFOCOM '99, New York (NY), 2823 USA, Mar. 1999. 2825 [L12] Mahanti, A., C. Williamson, and D. Eager., "Traffic 2826 analysis of a web proxy caching hierarchy", IEEE Network, 2827 Vol.14, No.3, pp.16-23, May/June 2000. 2829 [802.11p] "Information technology - Telecommunications and 2830 information exchange between systems - Local and 2831 metropolitan area networks - Specific requirements - Part 2832 11: Wireless LAN Medium Access Control (MAC) and Physical 2833 Layer (PHY) specifications Amendment 6: Wireless Access in 2834 Vehicular Environments", IEEE Standard 802.11p, 2010. 2836 [4WARD6.1] Ohlman, B. et al., "First NetInf Architecture 2837 Description", 4WARD Project Deliverable D-6.1, Apr. 2009. 2839 [4WARD6.3] Ahlgren, B. et al., "NetInf Evaluation", 4WARD Project 2840 Deliverable D-6.3, June 2010. 2842 [PRST2.4] Tagger, B., et al, "Update on the Architecture and Report 2843 on Security Analysis", Deliverable 2.4, PURSUIT EU FP7 2844 project, April 2012 2846 [PRST4.5] Riihijarvi, J. et al., "Final Architecture Validation and 2847 Performance Evaluation Report", PURSUIT Project 2848 Deliverable D4.5, Jan. 2013. 2850 [CMT-D5.2] B ben, A. et al, "Scalability of COMET System", COMET 2851 Project Deliverable D5.2, Feb. 2013. 2853 [CMT-D6.2] Georgiades, M. et al., "Prototype Experimentation and 2854 Demonstration", COMET Project Deliverable D6.2, Feb. 2013. 2856 [RealCCN] Perino, D. et al., "A Reality Check for Content Centric 2857 Networking", Proc. SIGCOMM ICN Workshop. ACM, 2011. 2859 [ICN-Web] Detti, A. et al., "Supporting the Web with an Information 2860 Centric Network that Routes by Name", Elsevier Computer 2861 Networks, vol. 56, no. 17, Nov. 2012. 2863 [ICN-Scal] Blefari Melazzi, N. et al., "Scalability Measurements in 2864 an Information-Centric Network", Springer Lecture Notes in 2865 Computer Science (LNCS), vol. 7586, 2012. 2867 [ICN-Tran] Salsano, S. et al., "Transport-Layer Issues in Information 2868 Centric Networks ", Proc. SIGCOMM ICN Workshop. ACM, 2012. 2870 [NDNpb] Xuan, Y. and Z. Yan, "Enhancing Routing Efficiency in 2871 Named Data Network with Piggybacked Interest", Proc. CFI. 2872 ACM, 2013. 2874 [CIBUS] Biswas, T. et al., "Contextualized Information-Centric 2875 Home Network", Proc. ACM SIGCOMM. ACM, 2013. 2877 [Homenet] Ravindran, R. et al., "Information-centric Networking 2878 based Homenet", Proc. International Workshop on Management 2879 of the Future Internet (ManFI). IFIP/IEEE, 2013. 2881 [MODEL1] Uddin, M.Y.S., Nicol, D.M., Abdelzaher, T.F., and R.H. 2882 Kravets, "A post-disaster mobility model for Delay 2883 Tolerant Networking", Simulation Conference (WSC), 2884 Proceedings of the 2009 Winter , vol., no., pp.2785,2796, 2885 13-16 Dec. 2009 2887 [MODEL2] Aschenbruck, N., Gerhards-Padilla, E., and P. Martini. 2888 "Modeling mobility in disaster area scenarios.", 2889 Performance Evaluation 66, no. 12 (2009): 773-790. 2891 [MODEL3] Cabrero, S., Paneda, X.G., Plagemann, T., Melendi, D., and 2892 R. Garcia. "An Overlay Routing Protocol for Video over 2893 sparse MANETs in Emergencies", Cadernos de Inform??tica 6, 2894 no. 1 (2011): 195-202. 2896 [EECD] Lee, U., Rimac, I., Kilper, D., and V. Hilt, "Toward 2897 energy-efficient content dissemination", IEEE Network, 2898 vol. 25, no. 2, March-April 2011. 2900 [ICNDC] Ko, B. J., Pappas, V., Raghavendra, R., Song, Y., 2901 Dilmaghani, R. B., Lee, K.-w., and D. Verma, "An 2902 information-centric architecture for data center 2903 networks", Proc. SIGCOMM ICN Workshop. ACM, 2012. 2905 [COAST] COAST, D5.1- File format specification and 3D video codec. 2906 Available: http://www.coast-fp7.eu/deliverables.html 2908 [NCICN] Montpetit, M. J., Westphal, C., and D. Trossen, "Network 2909 coding meets information-centric networking: an 2910 architectural case for information dispersion through 2911 native network coding", Proc. MOBIHOC NoM Workshop. ACM, 2912 2012. 2914 Authors' Addresses 2916 Kostas Pentikousis (editor) 2917 Huawei Technologies 2918 Carnotstrasse 4 2919 10587 Berlin 2920 Germany 2922 Email: k.pentikousis@huawei.com 2923 Borje Ohlman 2924 Ericsson Research 2925 S-16480 Stockholm 2926 Sweden 2928 Email: Borje.Ohlman@ericsson.com 2930 Daniel Corujo 2931 Instituto de Telecomunicacoes 2932 Campus Universitario de Santiago 2933 P-3810-193 Aveiro 2934 Portugal 2936 Email: dcorujo@av.it.pt 2938 Gennaro Boggia 2939 Dep. of Electrical and Information Engineering 2940 Politecnico di Bari 2941 Via Orabona 4 2942 70125 Bari 2943 Italy 2945 Email: g.boggia@poliba.it 2947 Gareth Tyson 2948 School and Electronic Engineering and Computer Science 2949 Queen Mary, University of London 2950 United Kingdom 2952 Email: gareth.tyson@eecs.qmul.ac.uk 2954 Elwyn Davies 2955 Trinity College Dublin/Folly Consulting Ltd 2956 Dublin, 2 2957 Ireland 2959 Email: davieseb@scss.tcd.ie 2961 Priya Mahadevan 2962 Palo Alto Research Center 2963 3333 Coyote Hill Rd 2964 Palo Alto, CA 94304 2965 USA 2966 Email: Priya.Mahadevan@parc.com 2968 Spiros Spirou 2969 Intracom Telecom 2970 19.7 km Markopoulou Avenue 2971 19002 Peania, Athens 2972 Greece 2974 Email: spis@intracom.com 2976 Antonella Molinaro 2977 Dep. of Information, Infrastructures, and Sustainable 2978 Energy Engineering 2979 Universita' Mediterranea di Reggio Calabria 2980 Via Graziella 1 2981 89100 Reggio Calabria 2982 Italy 2984 Email: antonella.molinaro@unirc.it 2986 Dorothy Gellert 2987 InterDigital Communications, LLC 2988 781 Third Avenue 2989 King Of Prussia, PA 19406-1409 2990 USA 2992 Email: dorothy.gellert@interdigital.com 2994 Suyong Eum 2995 National Institute of Information and Communications Technology 2996 4-2-1, Nukui Kitamachi, Koganei 2997 Tokyo 184-8795 2998 Japan 3000 Phone: +81-42-327-6582 3001 Email: suyong@nict.go.jp