RFC 7476
Information-Centric Networking: Baseline Scenarios
Pages: 45
Informational
Informational
Part 1 of 3 – Pages 1 to 11
Internet Research Task Force (IRTF) K. Pentikousis, Ed. Request for Comments: 7476 EICT Category: Informational B. Ohlman ISSN: 2070-1721 Ericsson D. Corujo Universidade de Aveiro G. Boggia Politecnico di Bari G. Tyson Queen Mary, University of London E. Davies Trinity College Dublin A. Molinaro UNIRC S. Eum NICT March 2015 Information-Centric Networking: Baseline ScenariosAbstract
This document aims at establishing a common understanding about a set of scenarios that can be used as a base for the evaluation of different information-centric networking (ICN) approaches so that they can be tested and compared against each other while showcasing their own advantages. Towards this end, we review the ICN literature and document scenarios which have been considered in previous performance evaluation studies. We discuss a variety of aspects that an ICN solution can address. This includes general aspects, such as, network efficiency, reduced complexity, increased scalability and reliability, mobility support, multicast and caching performance, real-time communication efficiency, energy consumption frugality, and disruption and delay tolerance. We detail ICN-specific aspects as well, such as information security and trust, persistence, availability, provenance, and location independence. This document is a product of the IRTF Information-Centric Networking Research Group (ICNRG).
Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Research Task Force (IRTF). The IRTF publishes the results of Internet-related research and development activities. These results might not be suitable for deployment. This RFC represents the consensus of the Information- Centric Networking Research Group of the Internet Research Task Force (IRTF). Documents approved for publication by the IRSG are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7476. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Table of Contents
1. Introduction ....................................................3 1.1. Baseline Scenario Selection ................................4 1.2. Document Goals and Outline .................................5 2. Scenarios .......................................................6 2.1. Social Networking ..........................................6 2.2. Real-Time Communication ....................................7 2.3. Mobile Networking ..........................................9 2.4. Infrastructure Sharing ....................................11 2.5. Content Dissemination .....................................13 2.6. Vehicular Networking ......................................14 2.7. Delay- and Disruption-Tolerance ...........................17 2.7.1. Opportunistic Content Sharing ......................20 2.7.2. Emergency Support and Disaster Recovery ............21 2.8. Internet of Things ........................................22 2.9. Smart City ................................................25 3. Cross-Scenario Considerations ..................................27 3.1. Multiply Connected Nodes and Economics ....................27 3.2. Energy Efficiency .........................................31 3.3. Operation across Multiple Network Paradigms ...............33 4. Summary ........................................................34 5. Security Considerations ........................................35 6. Informative References .........................................36 Acknowledgments ...................................................44 Authors' Addresses ................................................441. Introduction
Information-centric networking (ICN) marks a fundamental shift in communications and networking. In contrast with the omnipresent and very successful host-centric paradigm, which is based on perpetual connectivity and the end-to-end principle, ICN changes the focal point of the network architecture from the end host to "named information" (or content, or data). In this paradigm, connectivity may well be intermittent. End-host and in-network storage can be capitalized upon transparently, as bits in the network and on storage devices have exactly the same value. Mobility and multiaccess are the norm, and anycast, multicast, and broadcast are natively supported. It is also worth noting that with the transition from a host-centric to an information-centric communication model the security paradigm changes as well. In a host-centric network, the basic idea is to create secure (remote-access) tunnels to trusted providers of data. In an information-centric network, on the other hand, any source (cache) should be equally usable. This requires some mechanism for
making each information item trustworthy by itself; this can be achieved, for example, by name-data integrity or by signing data objects. Although interest in ICN is growing rapidly, ongoing work on different architectures, such as NetInf [NetInf], the original Content-Centric Networking [CCN], and its successors, Project CCNx [CCNx] and Named Data Networking (NDN) [NDNP], the Publish-Subscribe Internet (PSI) architecture [PSI], and the Data-Oriented Network Architecture [DONA] is far from being completed. One could think of ICN today as being at a stage of development similar to that of packet-switched networking in the late 1970s when different technologies, e.g., DECnet, Internetwork Packet Exchange (IPX), and IP, just to name a few, were being actively developed and put to the test. As such, ICN's current development phase and the plethora of approaches to tackle the hardest problems make this a very active and growing research area, but, on the downside, it also makes it more difficult to compare different proposals on an equal footing. This document aims to partially address this by establishing a common understanding about potential experimental setups where different ICN approaches can be tested and compared against each other while showcasing their advantages. The first draft version of this document appeared in November 2012. It was adopted by ICNRG at IETF 87 (July 2013) as the document to address the work item on the definition of "reference baseline scenarios to enable performance comparisons between different approaches". Earlier draft versions of this document have been presented during the ICNRG meetings at IETF 85, IETF 86, IETF 87, IETF 88, IETF 89, and the ICNRG interim meeting in Stockholm in February 2013. This document has been reviewed, commented, and discussed extensively for a period of nearly two years by the vast majority of ICNRG members, which certainly exceeds 100 individuals. It is the consensus of ICNRG that the baseline scenarios described in this document should be published in the IRTF Stream of the RFC series. This document does not constitute a standard.1.1. Baseline Scenario Selection
Earlier surveys [SoA1] [SoA2] note that describing ICN architectures is akin to shooting a moving target. We find that comparing these different approaches is often even more tricky. It is not uncommon that researchers devise different performance evaluation scenarios, typically with good reason, in order to highlight the advantages of their approach. This should be expected to some degree at this early stage of ICN development. Nevertheless, this document shows that
certain baseline scenarios seem to emerge in which ICN architectures could showcase their comparative advantages over current systems, in general, and against each other, in particular. This document surveys the peer-reviewed ICN literature and presents prominent evaluation study cases as a foundation for the baseline scenarios to be considered by the IRTF Information-Centric Networking Research Group (ICNRG) in its future work. There are two goals for this document: first, to provide a set of use cases and applications that highlight opportunities for testing different ICN proposals; second, to identify key attributes of a common set of techniques that can be instrumental in evaluating ICN. Further, these scenarios are intended to equip researchers with sufficient configuration data to effectively evaluate their ICN proposals in a variety of settings, particularly extending beyond scenarios focusing simply on traditional content delivery. The overall aim is that each scenario is described at a sufficient level of detail, and with adequate references to already published work, so that it can serve as the base for comparative evaluations of different approaches. Example code that implements some of the scenarios and topologies included in this document is available from <http://telematics.poliba.it/icn-baseline-scenarios>.1.2. Document Goals and Outline
This document incorporates input from ICNRG participants and their corresponding text contributions, has been reviewed by several ICNRG active participants (see Section 7), and represents the consensus of the research group. However, this document does not constitute an IETF standard, but is an Informational document; see also [RFC5743]. As mentioned above, these scenarios are intended to provide a framework for evaluating different ICN approaches. The methodology for how to do these evaluations as well as definitions of metrics that should be used are described in a separate document [EVAL-METHOD]. In addition, interested readers should consider reviewing [CHALLENGES]. The remainder of this document presents a number of scenarios grouped into several categories in Section 2, followed by a number of cross- scenario considerations in Section 3. Overall, note that certain evaluation scenarios span across these categories, so the boundaries between them should not be considered rigid and inflexible. Section 4 summarizes the main evaluation aspects across the range of scenarios discussed in this document.
2. Scenarios
This section presents nine scenario categories based on use cases and evaluations that have appeared in the peer-reviewed literature.2.1. Social Networking
Social-networking applications have proliferated over the past decade based on overlay content dissemination systems that require large infrastructure investments to roll out and maintain. Content dissemination is at the heart of the ICN paradigm. Therefore, we would expect that social-networking scenarios are a "natural fit" for comparing ICN performance with traditional client-server TCP/IP-based systems. Mathieu et al. [ICN-SN], for instance, illustrate how an Internet Service Provider (ISP) can capitalize on CCN to deploy a short-message service akin to Twitter at a fraction of the complexity of today's systems. Their key observation is that such a service can be seen as a combination of multicast delivery and caching. That is, a single user addresses a large number of recipients, some of which receive the new message immediately as they are online at that instant, while others receive the message whenever they connect to the network. Along similar lines, Kim et al. [VPC] present an ICN-based social- networking platform in which a user shares content with her/his family and friends without the need for centralized content servers; see also Section 2.4, below, and [CBIS]. Based on the CCN naming scheme, [VPC] takes a user name to represent a set of devices that belong to the person. Other users in this in-network, serverless social sharing scenario can access the user's content not via a device name/address but with the user's name. In [VPC], signature verification does not require any centralized authentication server. Kim and Lee [VPC2] present a proof-of-concept evaluation in which users with ordinary smartphones can browse a list of members or content using a name, and download the content selected from the list. In other words, the above-mentioned evaluation studies indicate that with ICN there may be no need for an end-to-end system design that intermediates between content providers and consumers in a hub-and- spoke fashion at all times. Earlier work by Arianfar et al. [CCR] considers a similar pull-based content retrieval scenario using a different architecture, pointing to significant performance advantages. Although the authors consider a network topology (redrawn in Figure 1 for convenience) that has certain interesting characteristics, they do not explicitly address social networking in their evaluation scenario. Nonetheless,
similarities are easy to spot: "followers" (such as C0, C1, ..., and Cz in Figure 1) obtain content put "on the network" (I1, ..., Im, and B1, B2) by a single user (e.g., Px) relying solely on network primitives. \--/ |C0| /--\ +--+ +--+ +--+ +--+ *=== |I0| === |I1| ... |In| |P0| \--/ +--+ +--+ +--+ +--+ |C1| \ / o /--\ +--+ +--+ o o |B1| === |B2| o o o o o o +--+ +--+ o o / \ o o +--+ +--+ +--+ +--+ o *=== |Ik| === |Il| ... |Im| |Px| \--/ +--+ +--+ +--+ +--+ |Cz| /--\ Figure 1. Dumbbell with Linear Daisy Chains In summary, the social-networking scenario aims to exercise each ICN architecture in terms of network efficiency, multicast support, caching performance and its reliance on centralized mechanisms (or lack thereof).2.2. Real-Time Communication
Real-time audio and video (A/V) communications include an array of services ranging from one-to-one voice calls to multiparty multimedia conferences with support ranging from whiteboards to augmented reality. Real-time communications have been studied and deployed in the context of packet- and circuit-switched networks for decades. The stringent Quality of Service (QoS) requirements that this type of communication imposes on network infrastructure are well known. Since one could argue that network primitives that are excellent for information dissemination are not well-suited for conversational services, ICN evaluation studies should consider real-time communication scenarios in detail. Notably, Jacobson et al. [VoCCN] presented an early evaluation where the performance of a VoIP (Voice over IP) call using an information- centric approach was compared with that of an off-the-shelf VoIP implementation using RTP/UDP. The results indicated that despite the extra cost of adding security support in the ICN approach, performance was virtually identical in the two cases evaluated in
their testbed. However, the experimental setup presented is quite rudimentary, while the evaluation considered a single voice call only. Xuan and Yan [NDNpb] revisit the same scenario but are primarily interested in reducing the overhead that may arise in one- to-one communication employing an ICN architecture. Both studies illustrate that quality telephony services are feasible with at least one ICN approach. That said, future ICN evaluations should employ standardized call arrival patterns, for example, following well- established methodologies from the QoS and QoE (Quality of Experience) evaluation toolbox and would need to consider more comprehensive metrics. Given the widespread deployment of real-time A/V communications, an evaluation of an ICN system should demonstrate capabilities beyond feasibility. For example, with respect to multimedia conferencing, Zhu et al. [ACT] describe the design of a distributed audio conference tool based on NDN. Their system includes ICN-based conference discovery, speaker discovery, and voice data distribution. The reported evaluation results point to gains in scalability and security. Moreover, Chen et al. [G-COPSS] explore the feasibility of implementing a Massively Multiplayer Online Role-Playing Game (MMORPG) based on CCNx code and show that stringent temporal requirements can be met, while scalability is significantly improved when compared to a host-centric (IP-based) client-server system. This type of work points to benefits for both the data and control path of a modern network infrastructure. Real-time communication also brings up the issue of named data granularity for dynamically generated content. In many cases, A/V data is generated in real-time and is distributed immediately. One possibility is to apply a single name to the entire content, but this could result in significant distribution delays. Alternatively, distributing A/V content in smaller "chunks" that are named individually may be a better option with respect to real-time distribution but raises naming scalability concerns. We observe that, all in all, the ICN research community has hitherto only scratched the surface of illustrating the benefits of adopting an information-centric approach as opposed to a host-centric one, and thus more work is recommended in this direction. Scenarios in this category should illustrate not only feasibility but reduced complexity, increased scalability, reliability, and capacity to meet stringent QoS/QoE requirements when compared to established host- centric solutions. Accordingly, the primary aim of this scenario is to exercise each ICN architecture in terms of its ability to satisfy real-time QoS requirements and provide improved user experience.
2.3. Mobile Networking
IP mobility management relies on anchors to provide ubiquitous connectivity to end-hosts as well as moving networks [MMIN]. This is a natural choice for a host-centric paradigm that requires end-to-end connectivity and a continuous network presence for hosts [SCES]. An implicit assumption in host-centric mobility management is therefore that the mobile node aims to connect to a particular peer, as well as to maintain global reachability and service continuity [EEMN]. However, with ICN, new ideas about mobility management should come to the fore, capitalizing on the different nature of the paradigm, such as native support for multihoming, abstraction of network addresses from applications, less dependence on connection-oriented sessions, and so on [MOBSURV]. Dannewitz et al. [N-Scen] illustrate a scenario where a multiaccess end-host can retrieve email securely using a combination of cellular and Wireless Local Area Network (WLAN) connectivity. This scenario borrows elements from previous work, e.g., [DTI], and develops them further with respect to multiaccess. Unfortunately, Dannewitz et al. [N-Scen] do not present any results demonstrating that an ICN approach is, indeed, better. That said, the scenario is interesting as it considers content specific to a single user (i.e., her mailbox) and does point to reduced complexity. It is also compatible with recent work in the Distributed Mobility Management (DMM) Working Group within the IETF. Finally, Xylomenos et al. [PSIMob] as well as Pentikousis [EEMN] argue that an information-centric architecture can avoid the complexity of having to manage tunnels to maintain end-to- end connectivity as is the case with mobile anchor-based protocols such as Mobile IP (and its variants). Similar considerations hold for a vehicular (networking) environment, as we discuss in Section 2.6. Overall, mobile networking scenarios have not been developed in detail, let alone evaluated at a large scale. Further, the majority of scenarios discussed so far have related to the mobility of the information consumer, rather than the source. We expect that in the coming period more papers will address this topic. Earlier work [mNetInf] argues that for mobile and multiaccess networking scenarios we need to go beyond the current mobility management mechanisms in order to capitalize on the core ICN features. They present a testbed setup (redrawn in Figure 2) that can serve as the basis for other ICN evaluations. In this scenario, node "C0" has multiple network interfaces that can access local domains N0 and N1 simultaneously, allowing C0 to retrieve objects from whichever server (I2 or I3) can supply them without necessarily needing to access the servers in the core network "C" (P1 and P2). Lindgren [HybICN] explores this
scenario further for an urban setting. He uses simulation and reports sizable gains in terms of reduction of object retrieval times and core network capacity use. +------------+ +-----------+ | Network N0 | | Network C | | | | | | +--+ | ==== | +--+ | | |I2| | | |P1| | | +--+ | | +--+ | | \--/ | | | +-----|C0|---+ | | | /--\ | | | | +--+ | | | | |I3| | | +--+ | | +--+ | ==== | |P2| | | | | +--+ | | Network N1 | | | +------------+ +-----------+ Figure 2. Overlapping Wireless Multiaccess The benefits from capitalizing on the broadcast nature of wireless access technologies has yet to be explored to its full potential in the ICN literature, including quantifying possible gains in terms of energy efficiency [E-CHANET]. Obviously, ICN architectures must avoid broadcast storms. Early work in this area considers distributed packet suppression techniques that exploit delayed transmissions and overhearing; examples can be found in [MobiA] and [CCNMANET] for ICN-based mobile ad-hoc networks (MANETs), and in [RTIND] and [CCNVANET] for vehicular scenarios. One would expect that mobile networking scenarios will be naturally coupled with those discussed in the previous sections, as more users access social-networking and multimedia applications through mobile devices. Further, the constraints of real-time A/V applications create interesting challenges in handling mobility, particularly in terms of maintaining service continuity. This scenario therefore spans across most of the others considered in this document with the likely need for some level of integration, particularly considering the well-documented increases in mobile traffic. Mobility is further considered in Section 2.7 and the economic consequences of nodes having multiple network interfaces is explored in Section 3.1. Host-centric mobility management has traditionally used a range of metrics for evaluating performance on a per-node and network-wide level. The first metric that comes to mind is handover latency, defined in [RFC5568] as the "period during which the mobile node is
unable to send or receive packets". This metric should be considered in ICN performance evaluation studies dealing with mobility. Note that, in IP-based networks, handover latency has been addressed by the introduction of mobility management protocols that aim to hide node mobility from the correspondent node, and often follow a make- before-break approach in order to ensure seamless connectivity and minimize (or eliminate altogether) handover latency. The "always-on" and "always best connected" [ABC] paradigms have guided mobility management research and standardization for a good decade or so. One can argue that such mechanisms are not particularly suited for ICN. That said, there has been a lot of interest recently in distributed mobility management schemes (see [MMIN] for a summary), where mobility management support is not "always on" by default. Such schemes may be more suitable for ICN. As a general recommendation, ICN designs should aim to minimize handover latency so that the end- user and service QoE is not affected adversely. Network overhead, such as the amount of signaling necessary to minimize handover latency, is also a metric that should be considered when studying ICN mobility management. In the past, network overhead has been seen as one of the main factors hindering the deployment of various mobility solutions. In IP-based networks, network overhead includes, but is not limited to, tunneling overhead, in-band control protocol overhead, mobile terminal and network equipment state maintenance and update. ICN designs and evaluation studies should clearly identify the network overhead associated with handling mobility. Alongside network overhead, deployment complexity should also be studied. To summarize, mobile networking scenarios should aim to provide service continuity for those applications that require it, decrease complexity and control signaling for the network infrastructure, as well as increase wireless capacity utilization by taking advantage of the broadcast nature of the medium. Beyond this, mobile networking scenarios should form a cross-scenario platform that can highlight how other scenarios can still maintain their respective performance metrics during periods of high mobility.
(page 11 continued on part 2)