idnits 2.17.1 draft-irtf-icnrg-evaluation-methodology-00.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 (October 21, 2013) is 3840 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 EICT 4 Intended Status: Informational B. Ohlman 5 Expires: April 24, 2014 Ericsson 6 E. Davies 7 Trinity College Dublin 8 S. Spirou 9 Intracom Telecom 10 G. Boggia 11 Politecnico di Bari 12 P. Mahadevan 13 PARC 14 October 21, 2013 16 Information-centric Networking: Evaluation Methodology 17 draft-irtf-icnrg-evaluation-methodology-00 19 Abstract 21 This document surveys the evaluation tools currently available to 22 researchers in the information-centric networking (ICN) area and 23 provides suggestions regarding methodology and metrics. Finally, 24 this document sheds some light on the impact of ICN on network 25 security. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2013 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Evaluation Methodology . . . . . . . . . . . . . . . . . . . . 4 64 2.1. ICN Simulators and Testbeds . . . . . . . . . . . . . . . 4 65 2.1.1. CCN and NDN . . . . . . . . . . . . . . . . . . . . . 4 66 2.1.2. Publish/Subscribe Internet Architecture . . . . . . . 6 67 2.1.3. NetInf . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.1.4. COMET . . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.1.5. Large-scale Testing . . . . . . . . . . . . . . . . . 7 70 2.2. Topology Selection . . . . . . . . . . . . . . . . . . . . 8 71 2.3. Traffic Load . . . . . . . . . . . . . . . . . . . . . . . 9 72 2.4. Choosing Relevant Metrics . . . . . . . . . . . . . . . . 11 73 2.4.1. Traffic Metrics . . . . . . . . . . . . . . . . . . . 13 74 2.4.2. System Metrics . . . . . . . . . . . . . . . . . . . . 15 75 2.5. Resource Equivalence and Tradeoffs . . . . . . . . . . . . 16 76 3. ICN Security Aspects . . . . . . . . . . . . . . . . . . . . . 16 77 3.1. Authentication . . . . . . . . . . . . . . . . . . . . . . 17 78 3.2. Authorization, Access Control and Statistics . . . . . . . 19 79 3.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 19 80 3.4. Changes to the Network Security Threat Model . . . . . . . 20 81 4. Security Considerations . . . . . . . . . . . . . . . . . . . 21 82 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 83 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 84 7. Informative References . . . . . . . . . . . . . . . . . . . . 21 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 87 1. Introduction 89 Information-centric networking (ICN) marks a fundamental shift in 90 communications and networking. As discussed in [draft-irtf-icnrg- 91 scenarios], the development phase that ICN is going through, and the 92 plethora of approaches to tackle the hardest problems, make this a 93 very active and growing research area but, on the downside, it also 94 makes it more difficult to compare different proposals on an equal 95 footing. Different ICN approaches have been evaluated in the peer- 96 reviewed literature using a mixture of theoretical analysis, 97 simulation and emulation techniques, and empirical (testbed) 98 measurements. These are all popular methods for evaluating network 99 protocols, architectures, and services in the networking community. 100 Typically, researchers follow a specific methodology based on the 101 goal of their experiment, e.g., whether they want to evaluate 102 scalability, quantify resource utilization, analyze economic 103 incentives, and so on, as we have discussed earlier. In addition, 104 though, we observe that ease and convenience of setting up and 105 running experiments can sometimes be a factor in published 106 evaluations. 108 It is worth pointing out that for well-established protocols, such as 109 TCP, performance evaluation using actual network deployments has the 110 benefit of realistic workloads and reflects the environment where the 111 service or protocol will be deployed. However, results obtained in 112 this environment are often difficult to replicate independently. 113 Beyond this, the difficulty of deploying future Internet 114 architectures and then engaging sufficient users to make such 115 evaluation realistic is often prohibitive. 117 Moreover, for ICN in particular, it is not yet clear what qualifies 118 as a "realistic workload". As such, trace-based analysis of ICN is 119 in its infancy, and more work is needed towards defining 120 characteristic workloads for ICN evaluation studies. Accordingly, 121 the experimental process itself as well as the evaluation methodology 122 are being actively researched for ICN architectures. Numerous 123 factors affect the experimental results, including the topology 124 selected, the background traffic that an application is being 125 subjected to, network conditions such as available link capacities, 126 link delays, and loss-rate characteristics throughout the selected 127 topology; failure and disruption patterns; node mobility; as well as 128 other aspects such as the diversity of devices used, and so on, as we 129 explain in the remainder of this section. 131 Apart from the technical evaluation of the functionality of an ICN 132 architecture, its future success will be largely driven by its 133 deployability and economic viability. Thus any evaluation will also 134 have to include an assessment of its incremental deployability in the 135 existing network environment together with a view of how the 136 technical functions will incentivize deployers to invest in the 137 capabilities that allow the architecture to spread across the 138 network. 140 This document incorporates input from ICNRG participants and their 141 corresponding text contributions, has been reviewed by several ICNRG 142 active participants (see section 6), and represents the consensus of 143 the research group. That said, note that this document does not 144 constitute an IETF standard; see also [RFC5743]. 146 The remainder of this document is organized as follows. Section 2 147 presents various techniques and considerations for evaluating 148 different ICN architectures. Then, Section 3 discusses the impact of 149 ICN on network security. 151 2. Evaluation Methodology 153 At this stage, we do not intend to develop a complete methodology or 154 a benchmarking tool. Instead, this document proposes key guidelines 155 alongside suggested data sets and high-level approaches that we 156 expect to be of interest to the ICN community as a whole. Through 157 this, researchers and practitioners alike would be able to compare 158 and contrast different ICN designs against each other, as well as 159 against the state of the art in host-centric solutions, and identify 160 the respective strengths and weaknesses. 162 2.1. ICN Simulators and Testbeds 164 Since ICN is still an emerging area, the community is still in the 165 process of developing effective evaluation environments, including 166 simulators, emulators, and testbeds. To date, none of the available 167 evaluation methodologies can be seen as the one and only community 168 reference evaluation tool. Furthermore, no single environment 169 supports all well-known ICN approaches. Simulators and emulators 170 should be able to capture, faithfully, all features and operations of 171 the respective ICN architecture(s). It is also essential that these 172 tools and environments come with adequate logging facilities so that 173 one can use them for in-depth analysis as well as debugging. 174 Additional requirements include the ability to support mid- to large- 175 scale experiments, the ability to quickly and correctly set various 176 configurations and parameters, as well as to support the playback of 177 traffic traces captured on a real testbed or network. Obviously, 178 this does not even begin to touch upon the need for strong validation 179 of any evaluated implementations. 181 The rest of this subsection summarizes the ICN simulators and 182 testbeds currently available to the community. 184 2.1.1. CCN and NDN 185 The CCN project has open-sourced a software reference implementation 186 of the architecture and protocol called CCNx (www.ccnx.org). CCNx is 187 available for deployment on various operating systems and includes C 188 and Java libraries that can be used to build CCN applications. CCN- 189 lite (www.ccn-lite.net) is a lightweight implementation of the CCN 190 protocol, supports most of the key features of CCNx, and is 191 interoperable with CCNx. The core CCNx logic has been implemented in 192 about 1000 lines of code and is ideal for classroom work and course 193 projects as well as for quickly experimenting with CCNx extensions. 195 ndnSIM [ndnSIM] is a module that can be plugged into the ns-3 196 simulator and supports the core features of CCN. One can use ndnSIM 197 to experiment with various CCN applications and services as well as 198 components developed for CCN such as routing protocols, caching and 199 forwarding strategies. The code for ns-3 and ndnSIM is openly 200 available to the community and can be used as the basis for 201 implementing ICN protocols or applications. For more details see 202 http://www.nsnam.org and http://www.ndnsim.net. 204 ccnSim [ccnSim] is another CCN-specific simulator that was specially 205 designed to handle forwarding of a large number of CCN-chunks. 206 ccnSim is written in C++ for the OMNeT++ simulation framework 207 (www.omnetpp.org). Interested readers could consider also the 208 Content Centric Networking Packet Level Simulator [CCNPL]. Finally, 209 CCN-Joker [CCNj] is an application-layer platform that can be used to 210 build a CCN overlay. CCN-Joker emulates in user-space all basic 211 aspects of a CCN node (e.g., handling of Interest and Data packets, 212 cache sizing, replacement policies), including both flow and 213 congestion control. The code is open source and is suitable for both 214 emulation-based analyses and real experiments. 216 An example of a testbed that supports CCN is the Open Network Lab 217 (see https://onl.wustl.edu/). The ONL testbed currently comprises 18 218 extensible gigabit routers and over a 100 computers representing 219 clients and is freely available to the public for running CCN 220 experiments. Nodes in ONL are preloaded with CCNx software. ONL 221 provides a graphical user interface for easy configuration and 222 testbed set up as per the experiment requirements, and also serves as 223 a control mechanism, allowing access to various control variables and 224 traffic counters. It is also possible to run and evaluate CCN over 225 popular testbeds such as PlanetLab (www.planet-lab.org), Emulab 226 (www.emulab.net), and Deter (www.isi.deterlab.net) by directly 227 running the CCNx open-source code on PlanetLab and Deter nodes, 228 respectively. 230 NEPI, the Network Experimentation Programming Interface, 231 (http://nepi.inria.fr) is a tool developed for controlling and 232 managing large-scale network experiments. NEPI provides an experiment 233 description language to design network experiments, describing 234 topology, applications, and a controller to automatically deploy 235 those experiments on target experimentation environments, such as 236 PlanetLab. The controller is also capable of collecting result and 237 log files during the experiment execution. NEPI also allows to 238 specify node selection filters while designing the experiment, 239 thereby supporting automatic discovery and provisioning of testbed 240 nodes during experiment deployment, without the user having to hand- 241 pick them. It is simple and efficient to use NEPI to evaluate CCNx on 242 large-scale testbeds such as PlanetLab. 244 2.1.2. Publish/Subscribe Internet Architecture 246 The PSIRP project has open-sourced its Blackhawk publish-subscribe 247 (Pub/Sub) implementation for FreeBSD; more details are available 248 online at http://www.psirp.org/downloads.html. Despite being limited 249 to one operating system, the code base also provides a virtual image 250 to allow its deployment on other environments through virtualization. 251 The code distribution features a kernel module, a file system and 252 scope daemon, as well as a set of tools, test applications and 253 scripts. This work was extended as part of the PURSUIT project, 254 resulting in the development of the Blackadder prototype for Linux 255 and FreeBSD. It currently runs on a testbed across Europe, America 256 (MIT) and Japan (NICT). All sites are connected via OpenVPN, which 257 exports a virtual Ethernet device to all machines in the testbed. In 258 total, 40 machines in a graph topology containing one Topology 259 Manager and one Rendezvous node that handle all publish/subscribe and 260 topology formation requests are interconnected [IEICE]. 262 Moreover, the ICN simulation environment [ICN-Sim] allows the 263 simulation of new techniques for topology management following the 264 Publish-Subscribe paradigm and the PSIRP approach. The simulator is 265 based on the OMNET++ simulator and the INET/MANET frameworks. It is 266 currently publicly available at 267 http://sourceforge.net/projects/icnsim. A design characteristic of 268 this platform is the separation between the network and topology 269 management policies. An interface is used to provide this 270 functionality and policies can be imported and applied in the network 271 as topology manager applications running on top of this interface. 273 2.1.3. NetInf 275 The EU FP7 4WARD and SAIL projects have made a set of open-source 276 implementations available; see http://www.netinf.org/open-source for 277 more details. Of note, two software packages are available. The 278 first one is a set of tools for NetInf implementing different aspects 279 of the protocol (e.g., NetInf URI format, HTTP and UDP convergence 280 layer) using different programming languages. The Java 281 implementation provides a local caching proxy and client. The second 282 one, is a OpenNetInf prototype from the 4WARD project. Besides a 283 rich set of NetInf mechanisms implemented, it also provides a browser 284 plug-in and video streaming software. The SAIL project developed a 285 hybrid host-centric and information-centric network architecture 286 called the Global Information Network (GIN). The prototype for this 287 can be downloaded from http://gin.ngnet.it. 289 2.1.4. COMET 291 The EU FP7 COMET project developed a simulator, called Icarus, which 292 implements ProbCache [PROBCACHE], centrality-based in-network caching 293 [CL4M] and the hash-route-based algorithms detailed in [HASHROUTE]. 294 The simulator is built in Python and makes use of the Fast Network 295 Simulator Setup tool [FNSS] to configure the related parameters of 296 the simulation. The simulator is available from: 297 https://github.com/lorenzosaino/icarus/ 299 2.1.5. Large-scale Testing 301 An important consideration in the evaluation of any kind of future 302 Internet mechanism, lies in the characteristics of that evaluation 303 itself. Often, central to the assessment of the features provided by 304 a novel mechanism, lies the consideration of how it improves over 305 already existing technologies, and by "how much." With the 306 disruptive nature of clean-slate approaches generating new and 307 different technological requirements, it is complex to provide 308 meaningful results for a network layer framework, in comparison with 309 what is deployed in the current Internet. Thus, despite the 310 availability of ICN implementations and simulators, the need for 311 large-scale environments supporting experimental evaluation of novel 312 research is of prime importance to the advancement of ICN deployment. 314 In this regard, initiatives such as the Future Internet Research and 315 Experimentation Initiative (www.ict-fire.eu), enable researchers to 316 test new protocols and architectures in real conditions over 317 production networks (e.g., through virtualization and software- 318 defined networking mechanisms), simplifying the validation of future 319 evolutions and reducing the gap between research and deployment. 320 Similarly, Future Internet Design (www.nets-find.net) is a long-term 321 initiative along the same direction in the US. GENI (www.geni.net) 322 also offers experimentation infrastructure as does PlanetLab 323 (www.planet-lab.org), which likely offers the largest testbed 324 available today. Those wishing to perform smaller, more controlled 325 experiments can also consider the Emulab testbed (www.emulab.net), 326 which allows various topologies to be configured. 328 The Asia Future Internet Forum (www.asiafi.net) has also designed a 329 testbed mainly used for ICN experiments. This testbed consists of 330 multiple servers located in Asia and will be (presumably) expanded 331 with servers in other locations. Each testbed server includes 332 multiple Linux kernel-based LXCs. One container is called "bridge 333 container" and the other container is called "user container". A 334 bridge container has a global IP address used to connect to the 335 physical network through bridge mode, and a local (private) IP 336 address. A user container, which is assigned to each researcher, 337 connects to the bridge container in the same server using their local 338 IP addresses. A user container connects to the researcher's remote 339 containers located in different servers via tunnels established 340 between its local bridge container and the remote bridge containers. 342 Finally, the National Institute of Information and Communications 343 Technology (NICT) builds and operates the high-performance testbed 344 JGN-X (see http://www.jgn.nict.go.jp/english/index.html), which has 345 cutting-edge network functions and technologies including those 346 currently in development. JGN-X aims to establish new-generation 347 network technology and accelerate the R&D in areas such as network 348 virtualization and advanced operations of virtualized layers. JGN-X 349 is used for collaboration among developers in order to foster the 350 establishment and expansion of new-generation network technology. 352 2.2. Topology Selection 354 [draft-irtf-icnrg-scenarios] introduced several topologies that have 355 been used in ICN studies so far but, to date and to the best of our 356 understanding, there is no single topology that can be used to easily 357 evaluate all aspects of the ICN paradigm. There is rough consensus 358 that the classic dumbbell topology cannot serve well future 359 evaluations of ICN approaches. Therefore, one should consider a 360 range of topologies, each of which would stress different aspects, as 361 outlined earlier in this document. Current Internet traces are also 362 available to assist in this, e.g. see 363 http://www.caida.org/data/active/internet-topology-data-kit and 364 http://www.cs.washington.edu/research/networking/rocketfuel. 366 Depending on what is the focus of the evaluation, intra-domain 367 topologies alone may be appropriate. However, those interested, for 368 example, in quantifying transit costs will require inter-domain 369 traces (note that the above CAIDA traces offer this). Scalability is 370 an important consideration in this choice of this with CAIDA's ITDK 371 traces recording millions of routers across thousands of domains. 373 Beyond these traces there is a wide range of synthetic topologies, 374 such as the Barabasi-Albert model [BA] and the Watts-Strogatz small- 375 world topology [WATTS]. These synthetic traces allow experiments to 376 be performed whilst controlling various key parameters (e.g. degree). 377 Through this, different aspects can be investigated, such as 378 inspecting resilience properties. For some research, this may be 379 more appropriate as, practically speaking, there are no assurances 380 that a future ICN will share the same topology with today's networks. 382 Besides defining the evaluation topology as a graph G = (V,E), where 383 V is the set of vertices (nodes) and E is the set of edges (links), 384 one should also clearly define and list the respective matrices that 385 correspond to the network, storage and computation capacities 386 available at each node as well as the delay characteristics of each 387 link, so that the results obtained can be easily replicated in other 388 studies. Recent work by Hussain and Chen [Montage], although 389 currently addressing host-centric networks, could also be leveraged 390 and be extended by the ICN community. Measurement information can 391 also be taken from existing platforms such as iPlane 392 (http://iplane.cs.washington.edu), which can be used to provide 393 configuration parameters such as access link capacity and delay. 394 Alternatively, synthetic models such as [DELAY] can be used to 395 configure such topologies. 397 Finally, the dynamic aspects of a topology, such as node and content 398 mobility, disruption patterns, packet loss rates as well as link and 399 node failure rates, to name a few, should also be carefully 400 considered. As mentioned in [draft-irtf-icnrg-scenarios], for 401 example, contact traces from the DTN community could also be used in 402 ICN evaluations. 404 2.3. Traffic Load 406 As we are still lacking ICN-specific traffic workloads we can 407 currently only extrapolate from today's workloads. In this 408 subsection we provide a first draft of a set of common guidelines, in 409 the form of what we will refer to as a content catalog for different 410 scenarios. This catalog, which is based on previously published 411 work, could be used to evaluate different ICN proposals, for example, 412 on routing, congestion control, and performance, and can be 413 considered as other kinds of ICN contributions emerge. 415 We take scenarios from today's Web, file sharing (BitTorrent-like) 416 and User Generated Content (UGC) platforms (e.g., YouTube), as well 417 as Video on Demand (VoD) services. Publicly available traces for 418 these include those available from web sites such as 419 http://mikel.tlm.unavarra.es/~mikel/bt_pam2004, 420 http://multiprobe.ewi.tudelft.nl/multiprobe.html, 421 http://an.kaist.ac.kr/traces/IMC2007.html, and 422 http://traces.cs.umass.edu/index.php/Network/Network. 424 The content catalog for each type of traffic can be characterized by 425 a specific set of parameters: the cardinality of the estimated 426 content catalog, the average size of the exchanged contents (either 427 chunks or entire named information objects), and the statistical 428 distribution that best reflect the popularity of objects and their 429 request frequency. Table I summarizes the content catalog. With 430 this shared point of reference, the use of the same set of parameters 431 (depending on the scenario of interest) among researchers will be 432 eased, and different proposals could be compared on a common base. 434 Table I. Content Catalog 436 Traffic | Catalog | Mean Object Size | Popularity Distribution 437 Load | Size | [L4][L5][L7][L8] | [L3][L5][L6][L11][L12] 438 | [L1][L2]| [L9][L10] | 439 | [L3][L5]| | 440 ================================================================== 441 Web | 10^12 | Chunk: 1-10 kB | Zipf with 442 | | | 0.64 <= alpha <= 0.83 443 ------------------------------------------------------------------ 444 File | 5x10^6 | Chunk: 250-4096 kB | Zipf with 445 sharing | | Object: ~800 MB | 0.75 <= alpha<= 0.82 446 ------------------------------------------------------------------ 447 UGC | 10^8 | Object: ~10 MB | Zipf, alpha >= 2 448 ------------------------------------------------------------------ 449 VoD | 10^4 | Object: ~100 MB | Zipf, 0.65 <= alpha <= 1 450 ================================================================== 452 * UGC = User Generated Content ** VoD = Video on Demand 454 Several studies in the past years have stated that Zipf's law is the 455 discrete distribution that best represents the request frequency in a 456 number of application scenarios, ranging from the Web to VoD 457 services. The key aspect of this distribution is that the frequency 458 of a content request is inversely proportional to the rank of the 459 content itself, i.e., the smaller the rank, the higher the request 460 frequency. If we denote with M the content catalog cardinality and 461 with 1 <= i <= M the rank of the i-th most popular content, we can 462 express the probability of requesting the content with rank "i" as: 464 P(X=i) = ( 1/i^(alpha) ) / C, with C = SUM(1 / j^(alpha)), alpha > 0 466 where the sum is obtained considering all values of j, 1 <= j <= M. 468 Further, a variation of the Zipf distribution, termed the Mandelbrot- 469 Zipf distribution, has been suggested by [P2PMod] to better model 470 environments where nodes can locally store previously requested 471 content. For example, it was observed that peer-to-peer file sharing 472 applications typically exhibited a 'fetch-at-most-once' style of 473 behavior. This is because peers tend to persistently store the files 474 they download, a behavior that may also be prevalent in ICN. 476 2.4. Choosing Relevant Metrics 478 ICN is a networking concept that spun out of the desire to align the 479 operation model of a network with the model of its typical use. For 480 TCP/IP networks, this means to change the mechanisms of data access 481 and transport from a host-to-host model to a user-to-information 482 model. The premise is that the effort invested in changing models 483 will be offset, or even surpassed, by the potential of a "better" 484 network. However, such a claim can be validated only if it is 485 quantified. 487 Quantification of network performance requires a set of standard 488 metrics. These metrics should be broad enough so they can be applied 489 equally to host-centric and information-centric (or other) networks. 490 This will allow reasoning about a certain ICN approach in relation to 491 an earlier version of the same approach, to another ICN approach or 492 to the incumbent host-centric approach. It will therefore be less 493 difficult to gauge optimization and research direction. On the other 494 hand, the metrics should be targeted to network performance only and 495 should avoid unnecessary expansion into the physical and application 496 layers. Similarly, at this point, it is more important to capture as 497 metrics only the main figures of merit and to leave more esoteric and 498 less frequent cases for the future. 500 To arrive at a set of relevant metrics, it would be beneficial to 501 look at the metrics used in existing ICN approaches, such as CCN 502 [CCN] [VoCCN] [NDNP], NetInf [4WARD6.1] [4WARD6.3] [SAIL-B2] [SAIL- 503 B3], PURSUIT [PRST4.5], COMET [CMT-D5.2] [CMT-D6.2], Connect [SHARE] 504 [RealCCN], and CONVERGENCE [ICN-Web] [ICN-Scal] [ICN-Tran]. The 505 metrics used in these approaches fall into two categories: metrics 506 for the approach as a whole, and metrics for individual components 507 (resolution, routing, etc.). Metrics for the entire approach are 508 further subdivided into traffic and system metrics. It is important 509 to note that the various approaches do not name or define metrics 510 consistently. This is a major problem when trying to find metrics 511 that allow comparison between approaches. For the purposes of 512 exposition, in what follows we have tried to smooth differences by 513 pitting similarly defined metrics under the same name. Also, due to 514 space constraints, we have chosen to report here only the most common 515 metrics between approaches. For more details the reader should 516 consult the references for each approach. 518 Traffic metrics in existing ICN approaches are summarized in Table 519 II. These are metrics for evaluating an approach mainly from the 520 perspective of the end user, i.e., the consumer, provider, or owner 521 of the content or service. Depending on the level where these 522 metrics are measured, we have made the distinction into user, 523 application and network-level traffic metrics. So for example, 524 network-level metrics are mostly focused on packet characteristics, 525 whereas user-level metrics can cover elements of human perception. 526 The approaches don't make this distinction explicitly, but we can see 527 from the table that CCN and NetInf have used metrics from all levels, 528 PURSUIT and COMET have focused on lower-level metrics, and Connect 529 and CONVERGENCE prefer higher-level metrics. Throughput and download 530 time seem to be the most popular metrics altogether. 532 Table II. Traffic metrics used in ICN evaluations 534 User | Application | Network 535 ====================================================== 536 Download | Goodput | Startup | Throughput | Packet 537 time | | latency | | delay 538 ================================================================== 539 CCN | x | x | | x | x 540 ------------------------------------------------------------------ 541 NetInf | x | | x | x | x 542 ------------------------------------------------------------------ 543 PURSUIT | | | x | x | x 544 ------------------------------------------------------------------ 545 COMET | | | x | x | 546 ------------------------------------------------------------------ 547 Connect | x | | | | 548 ------------------------------------------------------------------ 549 CONVERGENCE | x | x | | | 550 ================================================================== 552 While traffic metrics are more important for the end user, the owner 553 or operator of the networking infrastructure is normally more 554 interested in system metrics, which can reveal the efficiency of an 555 approach. The various ICN approaches have used system metrics, but 556 unfortunately the situation is not as coherent as with the traffic 557 metrics. The most common system metrics used are: protocol overhead, 558 total traffic, transit traffic, cost savings, router cost, and router 559 energy consumption. 561 Besides the traffic and systems metrics that aim to evaluate an 562 approach as a whole, all of the surveyed approaches also evaluate the 563 performance of individual components. The name resolution, 564 request/data routing, and data caching are the most typical 565 components, so Table III presents the popular metrics for each of 566 those components. FIB size and path length, i.e., the routing 567 component metrics, are almost ubiquitous among approaches, perhaps 568 due to the networking background of the involved researchers. That 569 might be also the reason for the sometimes decreased focus on traffic 570 and system metrics, in favor of component metrics. It can certainly 571 be argued that traffic and system metrics are affected by component 572 metrics, however no approach has made the relationship clear. With 573 this in mind, and also taking into account that traffic and system 574 metrics are readily useful to end users and network operators, we 575 will restrict ourselves to those in the following sections. 577 Table III. Component metrics in existing ICN approaches 579 Resolution | Routing | Cache 580 ====================================================== 581 Resolution | Request | FIB | Path | Size | Hit 582 time | rate | size | length | | ratio 583 ================================================================== 584 CCN | x | | x | x | x | x 585 ------------------------------------------------------------------ 586 NetInf | x | x | | x | | x 587 ------------------------------------------------------------------ 588 PURSUIT | | | x | x | | 589 ------------------------------------------------------------------ 590 COMET | x | x | x | x | | x 591 ------------------------------------------------------------------ 592 CONVERGENCE | | x | x | | x | 593 ================================================================== 595 Before proceeding, we should note that we'd like our metrics to be 596 applicable to host-centric networks as well. Standard metrics 597 already exist for IP networks and it would certainly be beneficial to 598 take them into account. It is encouraging that many of the metrics 599 used by existing ICN approaches can also be used on IP networks and 600 that all of the approaches have tried on occasion to draw the 601 parallels. 603 2.4.1. Traffic Metrics 605 At their core, host-centric and information-centric networking 606 function as data transport services. Information of interest to a 607 user resides in one or more storage points connected to the network 608 and, on the user's request, the network transports this information 609 to the user for consumption. We could therefore do worse than to 610 quantify the data transport performance of the network in terms of 611 Quality of Service (QoS) metrics. 613 The IETF has been working for more than a decade on devising metrics 614 and methods for measuring the performance of IP networks. The work 615 has been carried out largely within the IPPM WG, guided by a relevant 616 framework [RFC2330]. IPPM metrics include delay, delay variation, 617 loss, reordering, and duplication. While the IPPM work is certainly 618 based on packet-switched IP networks, it is conceivable that it can 619 be modified and extended to cover ICN networks as well. However, more 620 study is necessary to turn this claim into a certainty. Many experts 621 have toiled for a long time on devising and refining the IPPM metrics 622 and methods, so it would be an advantage to use IPPM on measuring ICN 623 performance. In addition, IPPM works already for host-centric 624 networks, so comparison with information-centric networks would 625 entail only the ICN extension of the IPPM framework. Finally, an 626 important benefit of measuring the transport performance of a network 627 at it's output, using QoS metrics such as IPPM, is that it can be 628 done mostly without any dependence to applications. 630 Another option for measuring transport performance would be to use 631 Quality of Service metrics, not at the output of the network like 632 with IPPM, but at the input to the application. So for an 633 application like live video streaming the relevant metrics would be 634 startup latency, playout lag and playout continuity. The benefit of 635 this approach is that it abstracts away all details of the underlying 636 transport network, so it can be readily applied to compare between 637 networks of different concepts (host-centric, information-centric, or 638 other). As implied earlier, the drawback of the approach is its 639 dependence on the application, so it is likely that different (types 640 of) applications will require different metrics. It might be 641 possible to identify standard metrics for each type of application, 642 but the situation is not as clear as with IPPM metrics and further 643 investigation is necessary. 645 At a higher level of abstraction, we could measure the network's 646 transport performance at the application output. This entails 647 measuring the quality of the transported and reconstructed 648 information as perceived by the user during consumption. In such an 649 instance we would use Quality of Experience (QoE) metrics, which are 650 by definition dependent on the application. For example, the 651 standardized methods for obtaining a Mean Opinion Score (MOS) for 652 VoIP (e.g., ITU-T P.800) is quite different from those for IPTV 653 (e.g., PEVQ). These methods are notoriously hard to implement, as 654 they involve real users in a controlled environment. Such 655 constraints can be relaxed or dropped by using methods that model 656 human perception under certain environments, but these methods are 657 typically intrusive. The most important drawback of measuring 658 network performance at the output of the application is that only one 659 part of each measurement is related to network performance. The rest 660 is related to application performance, e.g., video coding, or even 661 device capabilities, both of which are irrelevant to our purposes 662 here and are generally hard to separate. We therefore see the use of 663 QoE metrics in measuring ICN performance as a poor choice. 665 2.4.2. System Metrics 667 Overall system metrics that need to be considered include 668 reliability, scalability, energy efficiency, and delay/disconnection 669 tolerance. In deployments where ICN is addressing specific 670 scenarios, relevant system metrics could be derived from current 671 experience. For example, in IoT scenarios, which were discussed 672 earlier in [draft-irtf-icnrg-scenarios], it is reasonable to consider 673 the current generation of sensor nodes, sources of information, and 674 even measurement gateways (e.g., for smart metering at homes) or 675 smartphones. In this case, ICN operation ought to be evaluated with 676 respect not only to overall scalability and network efficiency, but 677 also the impact on the nodes themselves. Karnouskos et al. 678 [SensReqs] provide a comprehensive set of sensor and IoT-related 679 requirements, for example, which include aspects such as resource 680 utilization, service life-cycle management and device management. 682 Additionally, various specific metrics are also critical in 683 constrained environments, such as CPU processing requirements, 684 signaling overhead, and memory allocation for caching procedures in 685 addition to power consumption and battery lifetime. Also, in nodes 686 acting as gateways, which typically not only act as a point of 687 service to a large number of nodes, but also have to satisfy the 688 information requests from remote entities; they need to consider 689 scalability-related metrics, such as frequency and processing of 690 successfully satisfied information requests. 692 Finally, given the in-network caching functionality of Information- 693 Centric Networks, metrics for the efficiency and performance of in- 694 network caching have to be defined. Such metrics will need to guide 695 researchers and operators regarding the performance of in-network 696 caching algorithms. A first step on this direction has been made in 697 [L9]. The paper proposes a formula that approximates the proportion 698 of time that a content stays in a network cache. The model takes as 699 input the rate of requests for a given content (the Content of 700 Interest) and the rate of requests for all other contents that go 701 through the given network element (router) and move the CoI down in 702 the (LRU) cache. The formula takes also into account the size of the 703 cache of this router. 705 The output of the model essentially reflects the probability that the 706 CoI will be found in a given cache. The initial study [L9] is 707 applied to the CCN/NDN framework, where contents get cached at every 708 node they traverse, while efforts are underway to assess the accuracy 709 of the model for other caching strategies. The formula according to 710 which the probability or proportion is calculated is given by: 712 pi = [mu/(mu+lambda)]^N, 714 where lambda is the request rate for CoI, mu is the request rate for 715 contents that move CoI down the cache and N is the size of the cache 716 (in slots). 718 The formula can be used to assess the caching performance of the 719 system and can also potentially be used to identify the gain of the 720 system due to caching. This can then be used to compare against gains 721 by other factors, e.g., addition of extra bandwidth in the network. 723 2.5. Resource Equivalence and Tradeoffs 725 As we have seen above, every ICN network is built from a set of 726 resources, which include link capacities, different types of memory 727 structures and repositories used for storing named information 728 objects and chunks temporarily (i.e. caching) or persistently, as 729 well as name resolution and other lookup services. Complexity and 730 processing needs in terms of forwarding decisions, management (e.g. 731 need for manual configuration, explicit garbage collection, and so 732 on), and routing (i.e. amount of state needed, need for manual 733 configuration of routing tables, support for mobility, etc.) set the 734 stage for a range of engineering tradeoffs. 736 In order to be able to compare different ICN approaches it would be 737 beneficial to be able to define equivalence in terms of different 738 resources which today are considered incomparable. For example, 739 would provisioning an additional 5 Mb/s link capacity lead to better 740 performance than adding 100 GB of in-network storage? Within this 741 context one would consider resource equivalence (and the associated 742 tradeoffs) for example for cache hit ratios per GB of cache, 743 forwarding decision times, CPU cycles per forwarding decision, and so 744 on. 746 3. ICN Security Aspects 748 The introduction of an information-centric networking architecture 749 and the corresponding communication paradigm changes many aspects of 750 network security. These will affect all the scenarios described in 751 [draft-irtf-icnrg-scenarios]. Additional evaluation will be required 752 to ensure relevant security requirements are appropriately met by the 753 implementation of the chosen architecture in the various scenarios. 755 The various ICN architectures that are currently proposed have 756 concentrated on authentication of delivered content to ensure the 757 integrity of the content. However the approaches are primarily 758 applicable to freely accessible content that does not require access 759 authorization, although they will generally support delivery of 760 encrypted content. 762 The introduction of widespread caching mechanisms may also provide 763 additional attack surfaces. The caching architecture to be used also 764 needs to be evaluated to ensure that it meets the requirements of the 765 usage scenarios. 767 In practice, the work on security in the various ICN research 768 projects has been heavily concentrated on authentication of content. 769 Work on authorization, access control, privacy and security threats 770 due to the expanded role of in-network caches has been quite limited. 771 A roadmap for improving the security model in NetInf can be found in 772 [NETINFSC]. In the rest of this section we briefly consider the 773 issues and provide pointers to the work that has been done on the 774 security aspects of the architectures proposed. 776 3.1. Authentication 778 For fully secure content distribution, content access requires that 779 the receiver needs to be able to reliably assess: 781 validity: is it a complete, uncorrupted copy of what was 782 originally published; 784 provenance: can the receiver identify the publisher, and, if so, 785 whether it and the source of any cached version of the 786 document can be adequately trusted; and 788 relevance: is the content an answer to the question that the 789 receiver asked. 791 All the ICN architectures considered in this document primarily 792 target the validity requirement using strong cryptographic means to 793 tie the content request name to the content. Provenance and 794 relevance are directly targeted to varying extents: There is a 795 tussle or trade-off between simplicity and efficiency of access and 796 level of assurance of all these traits. For example, maintaining 797 provenance information can become extremely costly, particularly when 798 considering (historic) relationships between multiple objects. 799 Architectural decisions have therefore been taken in each case as to 800 whether the assessment is carried out by the ICN or left to the 801 application. 803 An additional consideration for authentication is whether a name 804 should be irrevocably and immutably tied to a static piece of 805 preexisting content or whether the name can be used to refer to 806 dynamically or subsequently generated content. Schemes that only 807 target immutable content can be less resource hungry as they can use 808 digest functions rather than public key cryptography for generating 809 and checking signatures. However, this can increase the load on 810 applications. This is because they are required to manage many names, 811 rather than using a single name for an item of evolving content that 812 changes over time (e.g. a piece of data containing an age reference). 814 NetInf uses the Named Information (ni) URI scheme [RFC6920] to 815 identify content. This allows NetInf to assure validity without any 816 additional information but gives no assurance on provenance or 817 relevance. A "search" request allows an application to identify 818 relevant content and applications may choose to structure content to 819 allow provenance assurance but this will typically require additional 820 network access. NetInf validity authentication is consequently 821 efficient in a network environment with intermittent connectivity as 822 it does not force additional network accesses and allows the 823 application to decide on provenance validation if required. NetInf 824 primarily targets static content, but an extension would allow 825 dynamic content to be handled. The immutable case only uses digest 826 functions. 828 DONA [DONA] and CCN [CCN], [SECCONT] integrate most of the data 829 needed to verify provenance into all content retrievals but need to 830 be able to retrieve additional information (typically a security 831 certificate) in order to complete the provenance authentication. 832 Whether the application has any control of this extra retrieval will 833 depend on the implementation. CCN is explicitly designed to handle 834 dynamic content allowing names to be pre-allocated and attached to 835 subsequently generated content. DONA offers variants for dynamic and 836 immutable content. 838 PURSUIT [PSTSEC] appears to allow implementers to choose the 839 authentication mechanism so that it can, in theory, emulate the 840 authentication strategy of any of the other architectures. It is not 841 clear whether different choices would lead to lack of 842 interoperability. 844 3.2. Authorization, Access Control and Statistics 846 A potentially major concern for all the ICN architectures considered 847 here is that they do not provide any inbuilt support for an 848 authorization framework or for statistics monitoring. Once content 849 has been published and cached in servers, routers or end points not 850 controlled by the publisher, the publisher has no way to enforce 851 access control, determine which users have accessed the content or 852 revoke its publication. In fact, in some cases, it is even difficult 853 for the publishers themselves to perform access control, where 854 requests do not necessarily contain host/user identifier information. 856 Access could be limited by encrypting the content but the necessity 857 of distributing keys out-of-band appears to negate the advantages of 858 in-network caching. This also creates significant challenges when 859 attempting to manage and restrict key access. An authorization 860 delegation scheme has been proposed [ACDICN] but this requires access 861 to a server controlled by the publisher to obtain an access token 862 making it essentially just an out-of-band key distribution system. 864 Evaluating the impact of the absence of these features will be 865 essential for any scenario where an ICN architecture might be 866 deployed. It may have a seriously negative impact on the 867 applicability of ICN in commercial environments unless a solution can 868 be found. 870 3.3. Privacy 872 Another area where the architectures have not been significantly 873 analyzed is privacy. Caching implies a trade-off between network 874 efficiency and privacy. The activity of users is significantly more 875 exposed to the scrutiny of cache owners with whom they may not have 876 any relationship. 878 Although in many ICN architectures, the source of a request is not 879 explicitly identified, an attacker may be able to obtain considerable 880 information if s/he can monitor transactions on the cache and obtain 881 details of the objects accessed, the topological direction of 882 requests and information about the timing of transactions. The 883 persistence of data in the cache can make life easier for an attacker 884 by giving a longer timescale for analysis. 886 The impact of CCN on privacy has been investigated in a useful 887 master's thesis [CCNSEC]. The analysis in this thesis is mostly 888 applicable to all of the ICN architectures because it is mostly 889 focused on the common caching aspect. The privacy risks of named 890 data networking are also highlighted in [CCNPRIV]. Further work on 891 privacy in ICNs can be found in [CONPRV]. 893 3.4. Changes to the Network Security Threat Model 895 The architectural differences of the various ICN models as compared 896 to TCP/IP have consequences for network security. There is limited 897 consideration of the threat models and potential mitigation in the 898 various documents describing the architectures. The references 899 [CCNSEC] and [CONPRV] also consider the changed threat model. Some 900 of the key aspects are: 902 o Caching implies a tradeoff between network efficiency and user 903 privacy as discussed in Section 3.3. 905 o More powerful routers upgraded to handle persistent caching 906 increase the network's attack surface. This is particularly the 907 case in systems (e.g., CCN) that may need to perform cryptographic 908 checks on content that is being cached. For example, not doing 909 this could lead routers to disseminate invalid content. 911 o ICNs makes it difficult to identify the origin of a request as 912 mentioned in Section 4.3 slowing down the process of blocking 913 requests and requiring alternative mechanisms to differentiate 914 legitimate requests from inappropriate ones as access control 915 lists (ACLs) will probably be of little value for ICN requests. 917 o Denial-of-service (DoS) attacks may require more effort on ICN 918 than on TCP/IP but they are still feasible. One reason for this 919 is that it is difficult for the attacker to force repeated 920 requests for the same content onto a single node; ICNs naturally 921 spread content so that after the initial few requests, subsequent 922 requests will generally be satisfied by alternative sources, 923 blunting the impact of a DoS attack. That said, there are many 924 ways around this, e.g., generating random suffix identifiers that 925 always result in cache misses. 927 o Per-request state in routers can be abused for DoS attacks. 929 o Caches can be misused in the following ways: 931 + Attackers can use caches as storage to make their own content 932 available. 934 + The efficiency of caches can be decreased by attackers with the 935 goal of DoS attacks. 937 + Content can be extracted by any attacker connected to the 938 cache, putting users' privacy at risk. 940 Appropriate mitigation of these threats will need to be considered in 941 each scenario. 943 4. Security Considerations 945 This document does not impact the security of the Internet. 947 5. IANA Considerations 949 This document presents no IANA considerations. 951 6. Acknowledgments 953 Daniel Corujo and Gareth Tyson contributed to an earlier version of 954 this document. 956 This document has benefited from reviews, pointers to the growing ICN 957 literature, suggestions, comments and proposed text provided by the 958 following members of the IRTF Information-Centric Networking Research 959 Group (ICNRG), listed in alphabetical order: Marica Amadeo, Hitoshi 960 Asaeda, Claudia Campolo, Suyong Eum, Dorothy Gellert, Luigi Alfredo 961 Grieco, Myeong-Wuk Jang, Ren Jing, Will Liu, Antonella Molinaro, 962 Ioannis Psaras, Dirk Trossen, Jianping Wang, Yuanzhe Xuan, and Xinwen 963 Zhang. 965 7. Informative References 967 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 968 (IRTF) Document Stream", RFC 5743, December 2009. 970 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 971 "Framework for IP Performance Metrics", RFC 2330, May 972 1998. 974 [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 975 Keranen, A., and P. Hallam-Baker, "Naming Things with 976 Hashes", RFC 6920, April 2013. 978 [ndnSIM] Afanasyev, A. et al., ndnSIM: NDN simulator for NS-3 NDN 979 Technical Report NDN-0005, Revision 2, October 2012. 981 [ccnSim] Rossini, G. and D. Rossi, "Large scale simulation of CCN 982 networks", Proc. Algotel 2012 , La Grande Motte, France, 983 May 2012. 985 [CCNPL] Muscariello, L., "Content centric networking packet level 986 simulator", available online at 987 http://perso.rd.francetelecom.fr/muscariello/sim.html 989 [CCNj] Cianci, I. et al. "CCN - Java Opensource Kit EmulatoR for 990 Wireless Ad Hoc Networks", Proc. 7th ACM Int. Conf. on 991 Future Internet Technologies, Seoul, Korea, Sept., 2012. 993 [IEICE] G. Parisis, D. Trossen, and H. Asaeda, "A Node Design and 994 a Framework for Development and Experimentation for an 995 Information-Centric Network", IEICE Trans. Commun., vol. 996 E96-B, no. 7, pp.1650-1660, July 2013. 998 [ICN-Sim] N. Vastardis et al., "Simulation Tools Enabling Research 999 on Information-centric Networks", Proc. ICC FutureNet 1000 Workshop. IEEE, 2012. 1002 [PROBCACHE] I. Psaras, W. Chai, G. Pavlou, "Probabilistic In-Network 1003 Caching for Information-Centric Networks", Proc. SIGCOMM 1004 ICN Workshop. ACM, 2012. 1006 [CL4M] Chai, W. K. et al., "Cache 'Less for More' in Information- 1007 centric Networks", Proc. Networking. IFIP, 2012. 1009 [HASHROUTE] L. Saino, I. Psaras, G. Pavlou, "Hash-routing Schemes for 1010 Information-Centric Networking", Proc. SIGCOMM ICN 1011 Workshop. ACM, 2013. 1013 [FNSS] L. Saino, C. Cocora and G. Pavlou, "A Toolchain for 1014 Simplifying Network Simulation Setup", Proc. SIMUTOOLS. 1015 ACM, 2013. 1017 [BA] Barabasi, A. and R. Albert, "Emergence of scaling in 1018 random networks", Science, vol. 286, no. 5439, pp. 509- 1019 512, 1999. 1021 [WATTS] Watts, D. J. and S. H. Strogatz, "Collective dynamics of 1022 small-world networks", Nature, vol. 393, no. 6684, pp. 40- 1023 "10, 1998. 1025 [Montage] Hussain, A. and J. Chen, "Montage Topology Manager: Tools 1026 for Constructing and Sharing Representative Internet 1027 Topologies", DETER Technical Report, ISI-TR-684, Aug. 1028 2012. 1030 [DELAY] Kaune, S. et al., "Modelling the Internet Delay Space 1031 Based on Geographical Locations", Proc. Euromicro, Weimar, 1032 Germany, 2009. 1034 [L1] http://googleblog.blogspot.it/2008/07/we-knew-web-was- 1035 big.html 1037 [L2] Zhang, C., Dhungel, P., and K. Di Wu., "Unraveling the 1038 BitTorrent ecosystem", IEEE Transactions on Parallel and 1039 Distributed Systems, pp. 1164-1177, 2010. 1041 [L3] Cha, M., Kwak, H., Rodriguez, P., Ahn, Y.-Y., and S. Moon, 1042 "I tube, you tube, everybody tubes: analyzing the world's 1043 largest user generated content video system", Proc. ACM 1044 SIGCOMM conference on Internet measurement (IMC), San 1045 Diego (CA), USA, Oct. 2007. 1047 [L4] Zhou, J., Li, Y., Adhikari, K., and Z.-L. Zhang, 1048 "Counting YouTube videos via random prefix sampling", In 1049 Proc. of IMC'11, Berlin, Germany, Nov. 2011. 1051 [L5] Fricker, C., Robert, P., Roberts, J. and N. Sbihim, 1052 "Impact of traffic mix on caching performance in a 1053 content-centric network", In Proc. of IEEE NOMEN 2012, 1054 Workshop on Emerging Design Choices in Name-Oriented 1055 Networking, Orlando, USA, Mar. 2012. 1057 [L6] Yu, H., Zheng, D., Zhao, B. Y. and W. Zheng, 1058 "Understanding user behavior in large-scale video-on- 1059 demand systems", In SIGOPS Oper. Syst. Rev., Vol. 40, pp. 1060 333-344, April 2006. 1062 [L7] Marciniak, P., Liogkas, N., Legout, A. and E. Kohler, 1063 "Small is not always beautiful", In Proc. of IPTPS, 1064 International Workshop of Peer-to-Peer Systems, Tampa Bay, 1065 Florida (FL), USA, Feb. 2008. 1067 [L8] Bellissimo, A., Levine, B. and P. Shenoy, "Exploring the 1068 use of BitTorrent as the basis for a large trace 1069 repository", University of Massachusetts, Tech. Rep., 1070 2004. 1072 [L9] Psaras, I. et al., "Modelling and Evaluation of CCN- 1073 Caching Trees", In Proc. of the 10th international IFIP 1074 conference on Networking, Valencia, Spain, May 2011. 1076 [L10] Carofiglio, G., Gallo, M., Muscariello, L., and D. Perino, 1077 "Modeling Data Transfer in Content-Centric Networking", In 1078 Proc. of ITC, San Francisco, USA, Sep. 2011. 1080 [L11] Breslau, L., Cao, P., Fan, L., Phillips, G. and S. 1081 Shenker, "Web caching and zipf-like distributions: 1083 evidence and implications", In Proc. of INFOCOM '99, New 1084 York (NY), USA, Mar. 1999. 1086 [L12] Mahanti, A., Williamson, C., and D. Eager., "Traffic 1087 analysis of a web proxy caching hierarchy", IEEE Network, 1088 Vol.14, No.3, pp.16-23, May/June 2000. 1090 [P2PMod] Saleh, O., and M. Hefeeda, "Modeling and caching of peer- 1091 to-peer traffic", Proc. ICNP. IEEE, 2006. 1093 [CCN] Jacobson, V. et al., "Networking Named Content", Proc. 1094 CoNEXT. ACM, 2009. 1096 [VoCCN] Jacobson, V. et al., "VoCCN: Voice-over Content-Centric 1097 Networks", Proc. CoNEXT Re-Arch Workshop. ACM, 2009. 1099 [NDNP] Zhang, L. et al., "Named Data Networking (NDN) Project", 1100 NDN Technical Report NDN-0001, Oct. 2010. Available: 1101 http://named-data.net/publications/techreports/ 1103 [4WARD6.1] Ohlman, B. et al., "First NetInf Architecture 1104 Description", 4WARD Project Deliverable D-6.1, Apr. 2009. 1106 [4WARD6.3] Ahlgren, B. et al., "NetInf Evaluation", 4WARD Project 1107 Deliverable D-6.3, June 2010. 1109 [SAIL-B2] SAIL, "NetInf Content Delivery and Operations", SAIL 1110 Project Deliverable D-B.2, May. 2012. 1112 [SAIL-B3] Kutscher, D. (ed.) et al., "Final NetInf Architecture", 1113 SAIL Project Deliverable D-B.3 , Jan. 2013. Available: 1114 http://www.sail-project.eu/deliverables/ 1116 [PRST4.5] Riihijarvi, J. et al., "Final Architecture Validation and 1117 Performance Evaluation Report", PURSUIT Project 1118 Deliverable D4.5, Jan. 2013. 1120 [CMT-D5.2] B ben, A. et al, "Scalability of COMET System", COMET 1121 Project Deliverable D5.2, Feb. 2013. 1123 [CMT-D6.2] Georgiades, M. et al., "Prototype Experimentation and 1124 Demonstration", COMET Project Deliverable D6.2, Feb. 2013. 1126 [SHARE] Muscariello, L. et al., "Bandwidth and storage sharing 1127 performance in information centric networking", Proc. 1128 SIGCOMM ICN Workshop. ACM, 2011. 1130 [RealCCN] Perino, D. et al., "A Reality Check for Content Centric 1131 Networking", Proc. SIGCOMM ICN Workshop. ACM, 2011. 1133 [ICN-Web] Detti, A. et al., "Supporting the Web with an Information 1134 Centric Network that Routes by Name", Elsevier Computer 1135 Networks, vol. 56, no. 17, Nov. 2012. 1137 [ICN-Scal] Blefari Melazzi, N. et al., "Scalability Measurements in 1138 an Information-Centric Network", Springer Lecture Notes in 1139 Computer Science (LNCS), vol. 7586, 2012. 1141 [ICN-Tran] Salsano, S. et al., "Transport-Layer Issues in Information 1142 Centric Networks ", Proc. SIGCOMM ICN Workshop. ACM, 2012. 1144 [SensReqs] Karnouskos, S. et al., "Requirement considerations for 1145 ubiquitous integration of cooperating objects", Proc. 1146 NTMS. IFIP, 2011. 1148 [NETINFSC] Renault, E, Ahmad, A., and M. Abid, "Towards a Security 1149 Model for the Future Network of Information", Proc. Conf. 1150 Ubiquitous Information Technologies and Applications, 1151 IEEE, 2009. 1153 [DONA] Koponen, T. et al., "A Data-Oriented (and Beyond) Network 1154 Architecture", Proc. SIGCOMM. ACM, 2007. 1156 [SECCONT] Smetters, D., and V. Jacobson, "Securing network content", 1157 Technical Report TR-2009-01, PARC, 2009. 1159 [PSTSEC] Tagger, B., et al, "Update on the Architecture and Report 1160 on Security Analysis", Deliverable 2.4, PURSUIT EU FP7 1161 project, April 2012. 1163 [ACDICN] Fotiou, N. et al., "Access control enforcement delegation 1164 for information-centric networking architectures", Proc. 1165 SIGCOMM ICN Workshop. ACM, 2012. 1167 [CCNSEC] Lauinger, T., "Security and Scalability of Content-Centric 1168 Networking", Masters Thesis, Technische Universitaet 1169 Darmstadt and Eurecom, Sep. 2010. 1171 [CCNPRIV] Lauinger, Y., et al, "Privacy Risks in Named Data 1172 Networking: What is the Cost of Performance?", ACM SIGCOMM 1173 Computer Communication Review Editorial Note, vol. 42, 1174 iss. 5, 2012 1176 [CONPRV] Chaabane, A et al, "Privacy in Content-Oriented 1177 Networking: Threats and Countermeasures", arXiv:1211.5183, 1178 2012. 1180 Authors' Addresses 1182 Kostas Pentikousis (editor) 1183 EICT GmbH 1184 Torgauer Strasse 12-15 1185 10829 Berlin 1186 Germany 1188 Email: k.pentikousis@eict.de 1190 Borje Ohlman 1191 Ericsson Research 1192 S-16480 Stockholm 1193 Sweden 1195 Email: Borje.Ohlman@ericsson.com 1197 Elwyn Davies 1198 Trinity College Dublin/Folly Consulting Ltd 1199 Dublin, 2 1200 Ireland 1202 Email: davieseb@scss.tcd.ie 1204 Spiros Spirou 1205 Intracom Telecom 1206 19.7 km Markopoulou Avenue 1207 19002 Peania, Athens 1208 Greece 1210 Email: spis@intracom.com 1212 Gennaro Boggia 1213 Dep. of Electrical and Information Engineering 1214 Politecnico di Bari 1215 Via Orabona 4 1216 70125 Bari 1217 Italy 1219 Email: g.boggia@poliba.it 1221 Priya Mahadevan 1222 Palo Alto Research Center 1223 3333 Coyote Hill Rd 1224 Palo Alto, CA 94304 1225 USA 1227 Email: Priya.Mahadevan@parc.com