Charge routing networking : using lightning strikes to add dynamicity to CCN

(1)

Charge Routing Networking: Using Lightning Strikes to

Add Dynamicity to CCN

Franck Franck

A thesis submitted to the University of Dublin, Trinity College in fulfilment of the requirements for the degree of

Doctor of Philosophy (Computer Science)

(2)

Declaration

I declare that this thesis has not been submitted as an exercise for a degree at this or any other university and it is entirely my own work.

I agree to deposit this thesis in the Universitys open access institutional repository or allow the Library to do so on my behalf, subject to Irish Copyright Legislation and Trinity College Library conditions of use and acknowledgement.

Franck Franck

(3)

Acknowledgements

First and foremost, I would like to thank my supervisors, Prof. Eric Jul and Dr. M´elanie Bouroche for their expertise, guidance, and patience during my work on this Ph.D. thesis.

Thank you to the Irish Research Counsil and Bell Labs for providing the funding through the Enterprise Partnership programme, without which I would not have been able to complete this thesis.

I would also like to thank my friends and family for endless support for my endeavors and unwavering belief that I would be able to see it through to the end, even when I was not so sure myself.

Thank you to Dirk Hasselbalch for gentle and not-so-gentle prods and pokes to keep me on the path to Ph.D.-ship, and for good-natured company and support over the past three years.

Thank you to Suzette Wagner, Jette Færch Weiss, Ivana Dusparic, and Clovis Chap-man for using the time and effort to proofread my thesis and provide me with a treasure trove of suggested improvements.

(4)

Abstract

This thesis presents a novel routing mechanism designed to improve the performance of information-centric networks where there is a large degree of content producer mobility. Usage patterns on the Internet have changed a lot since the network was first designed and deployed in the 1960ies. From being a point-to-point communications and resource sharing platform, the Internet has evolved into the planet’s premier content distribution platform. This change in the way the network is being used means that the under-lying transport mechanisms, in the form of TCP, UDP, and IP, are no longer as well suited to catering for the network’s netizens as they were when they were first designed. Where the protocols concern themselves with transporting opaque data streams from one named endpoint in the network to another, their users are more concerned with what data is delivered to their systems and less with where it came from. Users no longer care whether they are connected to a server in Ireland or Columbia, as long as it delivers the content they request from it. As a result, a research sphere has sprung up around a replacement paradigm called Information-Centric Networking (ICN). ICNs make content, and the names that it is addressable by, the primary routing mechanism in the network, rather than IP addresses as is the case today. This makes them uniquely suitable to servicing the needs of modern users, in that both network and users can now focus on what content is delivered rather than where to retrieve it from.

(5)

In this thesis, we address an oft-overlooked network feature: Content producer mobility. It is a feature that still requires research to be fully supported in ICNs without resorting to using mobility anchors or a partially-fixed infrastructure. Our starting point is one ICN in particular—Content-Centric Networking (CCN)—and we present extensions that allow it to support a fully-mobile network infrastructure. We choose to focus on CCN because it is the most well-supported and mature of the ICNs currently out there. We expand CCN into a new paradigm, called Charge Routing Networking (CRN), that allows for a much greater degree of flexibility toward mobile content producers than CCN. CRN takes inspiration from how lightning strikes work in nature and model a transfer of content from a producer to a consumer in the same way as a lightning bolt transfers charge from a cloud to the ground. With CRN, producers can pre-seed paths in the network, which let consumers discover the content that the producers make avail-able, by making a series of path-of-least-resistance routing decisions.

We experimentally demonstrate and evaluate the features of CRN and compare them to their CCN counterparts in a collection of simulated networks. We simulate two applications in these networks: A high-throughput, latency-sensitive video streaming application, and a low-throughput, non-latency-sensitive Twitter-like social networking application.

We show how CRN can outperform CCN by on average 38 % to 79 %, measured on delivery faults under the streaming application, and 6 % to 38 %, measured on content delivery volume under the social networking application. We also show how, when the overhead of the extra traffic introduced by CRN is low compared to the total traffic vol-ume, or when node churn in the network is modest, CRN achieves this using on average 3 % to 84 % less total traffic than the comparable CCN solution. In the best cases, CRN can reduce delivery faults by more than 99 % and decrease traffic volume by 97 %. Fi-nally, we show that at the very worst case—low throughput, high CRN overhead—CRN can consume up to four and a half times more network traffic than CCN under similar conditions.

(6)

(7)

List of Tables

2.1 TCP/IP-CCN-CRN Comparison. CRN builds on CCN, there are many points of similar-ity. This thesis focuses mainly on the producer mobility aspect of CRN. . . 28

4.1 CCNInterestand Routing Table on NodeC. An exampleInterestfor the content named /A/chirps/1that Cwants to dispatch. The outgoing face is found by performing a longest-prefix match between longest-prefixes in the routing table and the name in theInterest. In this case,

entry 1 is the best match, and theInterestwill be sent on face 1.. . . 61

4.2 Routing Table with Authoritative Lookup. The way routing table entry matching is done, especially for I2 should be considered carefully. If longest-prefix matching is used, a non-optimal route will be chosen for theInterest, whereas having to find all matches forI2in the table and sorting them by resistance will complicate the lookup procedure. . . 65

5.1 Baseline Comparison of CCN, non-mobile CCN, and CRN. In anon-mobile setting, as our baseline here with 32 nodes, all three paradigms process all available frames in the

network without any being undelivered or late. While there are vast differences in number of

bytes,Interests, andData packets sent, it can clearly be seen that this is due to one CCN

implementation being tuned to expect mobility in the network. . . 107

5.2 32-node Low Mobility Comparison of CCN, non-mobile CCN, and CRN. Mobile CCN and CRN exhibits similar performance with regards to delivery faults. Mobile CCN

delivery faults standard deviation are lower than CRN, while non-mobile CCN is orders of

magnitude less successful. . . 110

5.3 64-node Low Mobility Comparison of CCN, non-mobile CCN, and CRN. CRN present numbers in-between the two CCN siblings, with higher traffic numbers than non-mobile

(13)

5.4 128-node Low Mobility Comparison of CCN, non-mobile CCN, and CRN. Here, CRN presents an advantage over both CCN paradigms in the delivery faults metric. It also

uses alomst three times the traffic volume of non-mobile CCN to do so. . . 111

5.5 256-node Low Mobility Comparison of CCN, non-mobile CCN, and CRN. In the largest randomly-generated network, CRN uses the least traffic and has the fewest delivery

faults. . . 112

5.6 32-node BRITE Network Low Mobility Comparison of CCN, non-mobile CCN, and CRN. Non-mobile CCN delivers the fewest frames, with mobile CCN coming second and

CRN delivering the most. . . 112

5.7 64-node BRITE Network Low Mobility Comparison of CCN, non-mobile CCN, and CRN. CRN manages to deliver more frames than either of the other paradigms. . . 113

5.8 128-node BRITE Network Low Mobility Comparison of CCN, non-mobile CCN, and CRN. CRN uses more traffic than non-mobile CCN, but also delivers more data. . . . 113

5.9 256-node BRITE Network Low Mobility Comparison of CCN, non-mobile CCN, and CRN. . . 113

5.10 Chirper, 32-node Low Mobility Comparison of CCN, non-mobile CCN, and CRN. The difference in the number of delivered chirps is not great between mobile CCN and CRN. . 115

5.11 Chirper, 64-node Low Mobility Comparison of CCN, non-mobile CCN, and CRN. There is not much difference in the number of delivered chirps between mobile CCN and CRN. 115

5.12 Chirper, 128-node Low Mobility Comparison of CCN, non-mobile CCN, and CRN. Non-mobile CCN does not deliver many chirps in this scenario, while the other paradigms fare

better. . . 116

5.13 Chirper, 256-node Low Mobility Comparison of CCN, non-mobile CCN, and CRN. CRN lies close to mobile CCN traffic-wise, and when considering the number of delivered chirps. 116

5.14 Chirper, 32-node BRITE-generated, Low Mobility Comparison of CCN, non-mobile CCN, and CRN. . . 116

(14)

5.18 64-node High Mobility Comparison of CCN, non-mobile CCN, and CRN. . . 119

5.21 32-node, BRITE-generated, High Mobility Comparison of CCN, non-mobile CCN, and CRN. . . 121

5.22 64-node, BRITE-generated, High Mobility Comparison of CCN, non-mobile CCN, and CRN. CRN presents with the lowest faulty frame count, while using more than four times

the traffic of non-mobile CCN, but still less than mobile CCN. . . 121

5.25 Chirper, 32-node, High Mobility Comparison of CCN, non-mobile CCN, and CRN.123

5.26 Chirper, 64-node, High Mobility Comparison of CCN, non-mobile CCN, and CRN.123

5.27 Chirper, 128-node, High Mobility Comparison of CCN, non-mobile CCN, and CRN. . . 124

5.28 Chirper, 256-node, High Mobility Comparison of CCN, non-mobile CCN, and CRN. . . 124

5.29 Chirper, 32-node BRITE-generated, High Mobility Comparison of CCN, non-mobile CCN, and CRN. . . 125

5.32 Comparison, Delivery Faults, CRN vs. CCN, Streamer Scenarios. A comparative table, summing up the scores of CRN vs. mobile CCN from sections 5.10 and 5.11. The

numbers are differences in percentage points. Note that negative scores indicate that CRN

performs better than CCN. . . 127

5.33 Comparison, Content Delivery, CRN vs. CCN, Chirper Scenarios. A comparative table, summing up the scores of CRN vs. mobile CCN from sections 5.10 and 5.11. Note that

(15)

5.34 Comparison, Traffic Usage, CRN vs. CCN, All Scenarios. A comparative table, sum-ming up the scores of CRN vs. mobile CCN from sections 5.10 and 5.11. For all lines, negative

(16)

List of Figures

1.1 Video-on-Demand, TCP/IP vs. CCN. Under TCP/IP, each client (C1throughCn) creates

its own stream and the bandwidth demand accumulates as one travels upstream. Under CCN,

in-network caching allows each router to deliver content independently, and bandwidth demand

does not accumulate upstream. . . 3

1.2 Research Question. . . 5

2.1 Figures Legend. Throughout the thesis we will be using these symbols in illustrative figures. 17

2.2 The Internet Hourglass under CCN. The thin waist of the Internet has been moved from IP to content-based routing and IP is now an optional lower-level transport mechanism.

Illustration copied fromNetworking Named Content [Jacobson 09]. . . 18

3.1 Lightning Bolt with Leaders. The XKCD webcomic that inspired the thesis authors to ex-amine lightning strikes in more detail has an interesting description of how these actually work.

Copyright c2012-2014 Randall Munroe,http://what-if.xkcd.com/16/, used in accordance

with copyright license. . . 40

3.2 C’s Egress Resistance Table for LinkL. The table contains the resistance values thatD has indicated that it can routeInterests at. For example, anInterestfor/A/chirps/42will

need to overcome a resistance of 10 to arrive at a content source. . . 42

3.3 Charge Propagation for anInterest.Ecreates anInterestfor/A/statuswith an initial charge value of 32. As the Interestpropagates through the network segment, the charge

dissipates. WhenDforwards it, it subtracts 13, and whenCforwards it, it subtracts another

(17)

3.4 Interest Path Exploration. (a) In the beginning,Ahas a routing cost of 20 for/X/status. (b) It decides, however, to explore the network for other paths to the content, and issues an

Interestwith a much higher charge value than that (128). (c)Bsubtracts it local bias (5)

from the Interest. Because of the high charge value, B decides to split theInterestand

explore theB-Clink for routes to the content. . . 44

3.5 Propagation of an UpdateMessage. (a) A issues a newUpdateMessagefor the namespace /A/status. (b) NodesBandCreceive theUpdateMessagefromA. They add their own local

bias to the resistance it conveys and forward it to their downstream neighbours. . . 46

4.1 Namespace Explosion – Initial Setup. A three-node network. NodeAhas just published the content /A/chirps/1. The link betweenAandBhas a resistance of 5 each way, and the link betweenBandChas a resistance of 10 each way. . . 57

4.2 Namespace Explosion – UpdateMessage Propagation. A issues an UpdateMessageto B, which in turn relays it toC. The resistance information in theUpdateMessageaccumulates as

it travels through the network, reflecting the cost of the links it traverses. . . 57

4.3 Namespace Explosion – Interest from B. B requests the first chirp available underA’s namespace. TheInterestfor the content is sent with a charge of 5 as directed by the previous

UpdateMessage.Aresponds with theData/A/chirps/0. . . 58

4.4 Namespace Explosion – Caching at B. B decides to cache/A/chirps/0 and is willing to route it to other nodes if requested. It thus sends anUpdateMessagetoCto inform it of the

new, cheaper cost of requesting content at this namespace. . . 59

4.5 Namespace Explosion – Interest from C. Ctries to request/A/chirps/1fromBwith a charge value of 10. TheInterestis routed toB, which does not have the content, and is then

discarded because its charge is depleted. . . 59

4.6 Namespace Challenge – Omitting Cache Announcements.Ais the producer for the names-pace A/chirpsand Cis requesting content from within that namespace. Z has previously

requested and cached the content thatCis interested in, but because it cannot announce the

presence of the content, Cis forced to route over the more costly route C-B-Ainstead of

simply sending anInteresttoZ. . . 67

4.7 Network with a Loop. NodesA,B, andCeach take a 3 resistance toll for routing content, whileZtakes a hefty 4096. Pis the producer and thus delivers it for free. Note howAbelieves

(18)

4.8 Producer, P, Moves. The content producer,P, moves to another location in the network— this one has a very high-resistance link fromAtoZ. Before moving,PinformsAthat content

will no longer be available on that link (N/A). . . 76

4.9 A Issues UpdateMessages. This figure is “zoomed” in on the S-W section of Figure 4.8. A realizes that it has lost its best route to the content and advisesBandCof what it believes

to be the new best routes. . . 77

4.10 B and C Propagate the Change. Having had their best routes (that do not involve routing in a loop back to each other) updated,BandCissueUpdateMessages to inform each other of

the change. . . 77

4.11 Full-Circle Propagation. The sequence of UpdateMessages ripples back to A and cause updates to the routes that were the basis of the first UpdateMessages. A will thus have to

update these routes and inform its neighbours, and the cycle repeats. . . 78

5.1 Points of Attachment. Conceptual overview of the networking model of our simulations. Each Point of Attachment may host several agents, all of which may consume or produce

content on the CCN/CRN network. . . 99

5.2 Degree of Connectivity Impact on 128-node, 8-producer Networks. At a DoC of 1.0, CRN experiences problems delivering Streamer frames on time. . . 104

5.3 Number of Producers Impact on a 128-node Networks. CRN behaves erratically with low-DoC networks, but once connectivity improves, so does delivery performance, and the

higher-DoC networks all exhibit better performance than their CCN counterparts. The graph

consists of 10 simulation runs per plot point, and the population standard deviation between

runs has been plotted as error bars. . . 106

6.1 UpdateMessage Ripple Effect. Connectivity toZis lost. If the nodes timeout in the order A-B-C, it may cause a storm ofUpdateMessages to be issued. . . 133

(19)

Chapter 1

Introduction

“Desire is the key to motivation, but it’s

determination and commitment to an unrelenting

pursuit of your goal a commitment to excellence

-that will enable you to attain the success you seek.” — Mario Andretti

This thesis presents and evaluates a new routing paradigm, called Charge Routing Networking (CRN), in the networking research sphere known as Information-Centric Networking (ICN). We build on an existing scheme called Content-Centric Networking (CCN) to augment it with new capabilities that will allow it to work more robustly in a mobile networking environment. Such environments may be prevalent in the future networks due to the emergence of mobile always-on devices. Our paradigm is presented and evaluated using simulation.

In this chapter, we present the background of and motivation for this research topic and give a very high-level overview of our solution. We also present the main research question that we focus on throughout the thesis.

(20)

of the structure of the thesis.

1.1

Background and Motivation

The Internet has changed much since it was first created: Founded on research first started in the 1960ies, the transport paradigm of the Internet was envisioned to be that of a resource sharing platform: A computer in one location should be able to utilize some resource (e.g., a printer or harddisk) connected to another, remote, computer by communicating with that computer over a network. Thus, the Internet Protocol (IP) underlying Internet traffic transport was designed to provide a communications channel for two endpoints (computers), identified by IP addresses. The contents of the conversation is opaque and unimportant to IP, as it is not expected to be relevant for any third parties. The way we use the Internet today is very different from that resource sharing paradigm envisioned in its early days. Today, the average Internet user is not concerned with which endpoint she is communicating with, but more concerned with what content can be provided to her. She simply specifies the name of some piece of content to her web browser, FTP program, or BitTorrent client, and they take care of the how and where to acquire it. Resource sharing is still present in some incarnations (e.g., cloud storage), but the Internet has expanded from being a resource sharing platform, into a content distribution platform. This shift in usage has brought with it problems and inefficiencies in the Internet because the underlying transport mechanism was designed for resource sharing, not for content distribution.

Content-Centric Networking [Jacobson 09] is a new networking paradigm that attempts to tackle many of the pain points that this schism has brought with it, by promoting the network transport mechanisms from mere bit-pipes transferring opaque streams of data, to content-aware caches that can authenticate and route content based on local decisions. All nodes in a CCN network can participate in the distribution of content because they know what content is being transmitted and are allowed to cache it for later reuse. CCN nodes are thus first-class citizens when it comes to content distribution, and also in the areas of security and flow control.

(21)

addresses a number of issues that remain unsolved with the current TCP/IP regime.

[image:21.595.128.505.120.317.2]

(a)Video-on-Demand under TCP/IP. (b)Video-on-Demand under CCN.

Fig. 1.1: Video-on-Demand, TCP/IP vs. CCN. Under TCP/IP, each client (C1throughCn) creates its

own stream and the bandwidth demand accumulates as one travels upstream. Under CCN, in-network caching

allows each router to deliver content independently, and bandwidth demand does not accumulate upstream.

(22)

designed as a one-to-many transport paradigm that lets routers fetch content once and redistribute it many times.

The main problems that CCN addresses compared to TCP/IP are:

• Content Reuse By allowing in-network caches everywhere in the network, and by uniquely identifying all content in a router-visible way, CCN can ensure that a given piece of content is only transferred across any given network link once. By caching content the first time it is delivered, and fulfilling subsequent requests for that content from local cache, a node can reduce load on upstream network links, alleviating congestion in the routing fabric of the network.

• Content Locality As a consequence of the content reuse feature of CCN, content requests are always fulfilled from the nearest upstream router that has delivered the requested content before. Thus, content is moved closer to its consumers and roundtrip times for delivery are improved. As the bandwidth of network links increases, this roundtrip time will become a more dominant factor when measuring content retrieval times under TCP/IP.

• Content Verification To address the content reuse and content locality issues, CCN has made content self-certifying by requiring it to be digitally signed be-fore transfer. This helps solve security-related issues such as content authenticity verification and man-in-the-middle attacks.

• Mobile Consumers Routing of content is done by following the reverse path through the network of the request that elicited the content, and is done on a one-request-one-reply basis. Thus, CCN consumers can always establish a routing path if they know where to send content requests, and there are no sessions that break when a consumer moves in the network. Consumer mobility is therefore intrinsically supported by CCN, in contrast to TCP/IP, which expects a fixed IP address for sessions to work properly.

1.2

Problem Statement

(23)

While CCN supports mobility among content consumers gracefully, it has no measures aimed at tackling the case when producers do not stay in one place in the network. The performance of CCN hinges on being able to reliably locate content sources (be they content producers or caches) and routing requests to them, and therefore, designing fast and efficient routing protocols that ensure this can happen is an important challenge to research.

In this thesis, we investigate the problem of creating a routing protocol for CCN-based networks (i.e., without an underlying IP infrastructure) that may have no fixed infras-tructure to rely on for routing. Thus, we examine a routing protocol design space that encompasses not only mobile phone-like networks that have a fixed backhaul, but also Mobile Ad-hoc Networks (MANETs) and sporadic networks where most or all of the infrastructure is made up of mobile nodes.

As mobile devices and on-the-go content production becomes more and more prevalent among Internet users, we believe that this is an area that must be investigated and have its shortcomings under CCN addressed.

1.2.1 Research Question

Within the area of research that focuses on supporting mobile content producing nodes under CCN, we have identified the main question that we work with throughout this thesis: We attempt to answer the research question in Figure 1.2 by designing,

imple-Can we extend CCN in such a way as to improve reorganization after topology changes in the network, thus

improving performance in networks with mobile content producers?

Fig. 1.2: Research Question.

(24)

1.3

Solution Overview

In this thesis, we present an evolution of CCN into what we have chosen to call Charge Routing Networking, which is aimed mainly at enabling mobile content producers, but brings with it other advantages as well. As we show in later chapters, CRN can provide a significant drop in delivery failures of frames in a simulated mobile high-throughput, latency-sensitive scenario, while significantly improving the network efficiency compared to CCN. We also show how it can be used in a less throughput-intensive, non-latency-sensitive scenario without adversely degrading the network performance compared to the equivalent CCN implementation.

Our proposed solution, Charge Routing Networking, is a routing paradigm developed on top of CCN that potentially allows faster discovery of mobile devices, a higher degree of dissemination flexibility toward the content producer, and better resource utilization in the CCN-enabled network. These are pain points that CCN presents in networking environments with mobile content producers [Kutscher 13].

Faster route discovery is accommodated by two factors: Firstly, by allowing nodes to

push small route information packets to their neighbours, thus alerting the network to changes in topology, and secondly, by not only allowing, butencouraging content requests to take “detours” in the network to discover alternative paths between producers and consumers.

(25)

1.4

Goals

The goals of this thesis are as follows:

• Develop a New Routing Paradigm We motivate, design, and present the Charge Routing Networking paradigm

• Demonstrate Validity Using Simulation We evaluate the Charge Routing Networking paradigm by simulating two applications and several network environ-ments to quantify its advantages and disadvantages compared to CCN.

1.5

Approach

In this thesis, we discuss the design of CRN and how it allows CRN to be more reactive to network topology changes than CCN. This discussion mainly focuses on presenting novel algorithms that allow CRN to achieve better performance than CCN on key metrics. We then create an experimental simulation prototype CRN network, along with a simulator implementation of CCN, which we use to demonstrate the advantages and drawbacks of each network type. We do so by implementing two ICN-based applications that can run on either network and compare the results when identical application parameters are used in simulations with the two paradigms. We analyze each of these scenarios with respect to a number of metrics that we deem are important to a CCN-based network, such as the number of delivery faults, the resource consumption at the nodes and the total bandwidth usage. We compare these measurements head-to-head as we run identical simulations with the only difference being the network paradigm powering the content transport. The applications that we have chosen for our evaluation are:

• Streamer, a one-to-many realtime video streaming service that is intended to provide real-time video feeds from one content producer node to several clients, even when that producer is mobile and thus changes place in the network.

• Chirper, a Twitter-like application that allows a user to follow a number of friends in the network and receive their micro-blog status updates.

(26)

1.6

Results

(***) We show that in our moderately high traffic volume Streamer application scenario, CRN holds a advantage over CCN when it comes to delivering content streamed from mobile content producers. It can achieve a factor of two to almost one hundred reduction in delivery faults, while decreasing traffic volume by a factor of two to twenty. In the low traffic volume Chirper application scenarios, we show how CRN can provide a slightly faster recovery from mobility events at the producers than CCN while using 30 % to 50 % less traffic when node churn is low and providing 15 % decrease to 450 % increase in traffic volume when churn is high.

Thus, we show the advantages and drawbacks of CRN, depending on deployment sce-nario. While it can increase the traffic load on our simulated low-throughput application due to the overhead of maintaining routing tables on the nodes, it decreases it dramat-ically under the high-throughput Streamer application simulations. When namespace fragmentation is high, it can cause routing tables on the CRN nodes to become much larger than the CCN equivalents. Exactly how much larger depends on the namespace usage of the applications using the network.

1.7

Contributions

• The Charge Routing Networking Paradigm The main contribution of this thesis to the state of the art is that of the CRN paradigm. It improves on key aspects of CCN and adds features that may be useful in a real-world network. Part of this paradigm are the algorithms that, when taken as a whole, make up CRN. We have filed a patent covering the central concepts of CRN as part of this work [Franck 14a].

(27)

1.8

Conclusion

The conclusion of this thesis is that CCN can indeed be extended to provide better support for mobile content producer nodes in some scenarios—mainly when latency-sensitive data is delivered. CRN is a capable paradigm that can improve network traffic consumption over CCN in high-throughput scenarios. It can offer better reorganization recovery for networks that are prone to changes in topology, i.e., networks with mobile nodes, particularly mobile content producers. It thereby increases performance in such CCN networks. The magnitude of the performance increase depends on the scenario in which CRN is deployed. For applications that have a high traffic volume and are latency-sensitive, we demonstrate improvements in both delivery faults and traffic volume. For low traffic volume, non-latency-sensitive applications, the gains in delivered content are only slight, and CRN can cause traffic usage in the network to increase, especially when there is high churn in the node population.

While it does present performance improvements over CCN in certain scenarios, it has also proven to bring with it a number of challenges, especially in the area of routing table performance on the CRN nodes. How severely affected the nodes are compared to CCN nodes depends on the way network applications make use of the namespace. Thus, as it stands, CRN is not a plug-in replacement for CCN but rather an evolution that improves performance under some scenarios, while it may compromise it under other scenarios.

1.9

Thesis Structure

The thesis is structured as follows:

• Chapter 1—the chapter your are reading—is the introduction where we provide

a high-level overview of the problem we are tackling, the approach we have taken to solving it, and the results we have uncovered in doing so.

(28)

which CCN is based is examined in detail, and we also provide an overview of the most relevant related work.

• Chapter 3 is an introduction to CRN itself and discusses in detail how it differs from CCN. We present an overview of the networking scenarios that CRN has been designed for and how natural lightning strikes inspired the extensions to the CCN paradigm that are the basis of CRN. We then describe these extensions in more detail and show how they can bring new features to CRN.

• Chapter 4 is an in-depth analysis of the CRN paradigm. In it, we present the benefits that CRN brings over CCN and the challenges that it brings with it as well. We also outline several approaches to how to overcome or mitigate these challenges.

• Chapter 5 presents the implementation details of our simulated CCN and CRN networks as well as the two applications we employ to quantify the differences between the two paradigms. We present and discuss the results of our implemen-tation and simulation work, and conclude that CRN is particularly beneficial in high-throughput environments.

• Chapter 6 contains work we have done on topics that are not at the core of this thesis. We present a number of new ideas that could add desirable features to CRN and plans of attack for how we believe it would be most useful to investigate them. We also list a number of experiments that we believe could provide important insight into CRN, but that are out of scope for this thesis.

• Chapter 7 presents the conclusions drawn from all the previous chapters of the thesis.

1.10

Introduction Summary

(29)

(30)

Chapter 2

Background

“No one undertakes research in physics with the

intention of winning a prize. It is the joy of

discovering something no one knew before.”

—Stephen Hawking

In this chapter, we present the work that forms the foundation of Charge Routing Net-working and motivate why we believe it to be a significant improvement over the current state of the art. We then provide a glossary of the terms used throughout this thesis, before giving an in-depth description and evaluation of the work that makes up CCN, as it is the ICN base we have chosen to build CRN upon. Throughout the chapter, we discuss specific features and properties of CRN. These will be shown and demonstrated in later chapters.

Section 2.1 provides the background for the issue of mobile content producers in CCN, and Section 2.2 motivates why it is prudent to solve this issue. Section 2.3 is a list of the terminology used throughout the thesis. Section 2.4 is a literature review of the seminal article we base our work on, and sections 2.5 and 2.6 present an evaluation of the CCN paradigm in relation to our own CRN paradigm. Section 2.7 discusses how we will perform an evaluation of CRN, and Section 2.8 presents related research work.

2.1

Origins

(31)

the Internet transfers more than 920 EB of data every single day [Intel 13], most of it in the form of World-Wide Web content, and nearly all of it by means of the UDP/IP and TCP/IP protocols invented by early resource sharing Internet pioneers. IP (and, some argue, UDP and TCP) is said to make up the ’thin waist’ of the hourglass-shape collection of Internet protocols because all traffic must pass through it at some point to traverse the Internet. They are endpoint-oriented protocols that facilitate one-to-one communication for Internet hosts. This makes them a poor fit for the problem of content dissemination, which is inherently data-oriented one-to-many communication. The problems caused by this misalignment manifest themselves as repeated transmission of content, causing congestion on network links that aggregate many endpoints, i.e., the backbone of the Internet. Therefore, research has suggested that it may be time to find a new transport mechanism for that narrow waist [Popa 10] [Fotiou 12].

Content-Centric Networking [Jacobson 09] (CCN) presents a new way to deal with the challenges that face the Internet in the area of content dissemination, by routing data based onwhat it is rather thanwhohas it. This property allows content to automatically flow toward where it is needed—at the edges of the network—and lighten the load on a possibly congested Internet backbone.

While CCN addresses many of the current pain points that have emerged on the Internet, we believe mobile content producers will become a challenge for CCN and most other ICN paradigms that have been presented to the research community thus far.

2.2

Motivation

To provide the reader with a better background of why we have chosen to work with the problem of mobile content producers, this section presents a discussion of the background and our reasoning behind this choice.

(32)

The Trouble with Mobility

Mobile computational devices are becoming more and more prevalent on the Internet, and thus nodes that are not static in the network are an important challenge for ICN research to tackle [Kutscher 13] [Tyson 13]. CCN has made great strides toward intrinsic management of mobile consumer nodes by simply routingDatapackets along the reverse path of their soliciting Interests (see Section 2.4 for an in-depth description of CCN). Interests are routed on a per-packet longest prefix match basis, and because there is no concept of an end-to-end route in CCN, it essentially makes no difference whether a consumer issues them from one location or another, as long as that consumer stays put until the reply is routed back. Should the consumer change location mid-routing, it will have to re-issue the Interestand wait for a new reply.

Things, however, do not work quite as easily when it comes to supporting content pro-ducer mobility in CCN networks.

When a producer changes location, it is not sufficient to re-issue orphaned Interests— the routing state on (potentially all) nodes in the network needs to be updated to enable the Interests to find the producer node at its new location. This is the issue we are addressing in this thesis: We introduce CRN which, at its heart, is a novel approach to disseminating and discovering topology changes in CCN networks with mobile content producers.

Our use-case throughout this thesis will be one of a network of mobile devices that act as both content producers and consumers and that are free to travel throughout the net-work by simply unregistering from one point of attachment and registering at another. We have chosen to base our work on CCN because it already handles the case of mobile consumers nicely, but does not provide a robust approach to supporting mobile producer. If CCN is to be deployed in networks that contain such mobile content producers, it is important to examine how well they are supported, and if CCN can be augmented for better support.

2.3

Glossary

(33)

Networking Named Content [Jacobson 09], which we discuss in Section 2.4.

• Content The basic entity that CRN talks about is content. Content is a binary information “blob” that is opaque to the network stack. It can be subdivided into

chunks, which are the units that the routing apparatus works on. Thus, several chunks may have to be assembled after delivery to recreate a piece of content.

• Content ProducerContent always needs to be delivered from somewhere in the CRN network. Being based on CCN, CRN will happily deliver a piece of content from any cache that it can find in the network. However, for some aspects of the enhancements that CRN make over CCN, it becomes important to distinguish between two types of content-holding nodes: We will use the term producer when we are talking about a node that is the origin of content for some namespace. In other words, it holds the software that produces the content. Conversely, we use the term cache to mean a non-content producing node in the network that has cached the content in transit. We use the termrepository to mean either producer or cache.

• Content Consumer A request in the CRN network is always initiated by some node that wishes to consume some content. Aconsumer is thus a node that sends a request for content to a repository in the system. We also use the termsrequester

or client to mean consumer. A node in a CCN or CRN network can be both a producer and a consumer.

• Namespace When CRN talks about a piece of content, it does so by using its

namespace. A namespace is a routable label that uniquely identifies any content on the network. It is thus parsed and interpreted by the network stack as it is routed.

(34)

• DataThe response to anInterestis aDatapacket. It contains the ContentName field from theInterestthat solicited it, and a binary payload that is the requested content chunk itself. Here as well, other fields may be included, but our interest is in those two.

• Face An entry point into a node’s CRN networking stack is called aface. Faces are often physical network interfaces, but may also be message passing interfaces for local content delivery within a node.

• Content Store (CS) The Content Store is a content cache that resides on each node. WhenDatais routed through the network, each node on its path may choose to cache it in its CS and later serve it as response to incoming Interests.

• Forwarding Information Base (FIB)TheForwarding Information Base works in the same way as the FIB in many other networking protocol designs [Jacob-son 09]: It tells a node where it might find more information about a given routable element. In the case of CRN, it maps a namespace to faces that are expected to bring an Interestcloser to locating its requested content. The CRN FIB works by longest-prefix matches, so partial matches can be used where complete ones cannot be found.

• Pending Interest Table (PIT) ThePending Interest Table is where each node keeps track of which Interests it has forwarded, and which faces they were re-ceived on, until they are fulfilled. Multiple identical Interests can be aggregated into a single entry with multiple incoming faces, and whenDatais received, it will be matched against the PIT and forwarded on all faces marked as incoming for the soliciting Interest.

While the above list is presented in the context of CRN, most of the terms are the same as, and indeed originate from, the CCN design.

2.3.1 Figures Legend

(35)

Fig. 2.1: Figures Legend. Throughout the thesis we will be using these symbols in illustrative figures.

2.4

Content-Centric Networking

The work in this thesis, while in nature it applies to most ICN paradigms, is presented as an evolution of the CCN paradigm presented by Van Jacobsen et al. [Jacobson 09]. Naturally, many points of comparison between CCN and CRN are presented throughout the thesis, and we therefore feel it prudent to introduce CCN.

While much development and research has gone into expanding and changing CCN [ccn 14, min 14, ndn 15], we have taken the stance in this thesis that the work presented here must be applicable to as much of the CCN ecosystem as possible rather than a specific branch of development that has gone into CCN. Therefore, the developments we present here are based on the work presented inNetworking Named Content [Jacob-son 09], and as a basis of comparing CRN to CCN we have developed a CCN imple-mentation that adheres strictly to what is presented in that paper.

Networking Named Content

(36)

2.4.1 Motivation

Some historical insight provides the motivational background for CCN: Being designed in the 1960ies and 1970ies, IP is a resource sharing architecture. By creating a virtual networked tunnel between exactly two hosts, peripherals attached to one host could be utilized by the other. Over the past 50 years, however, the Internet has evolved to a state where the main usage paradigm looks a lot different from the connection-oriented resource sharing. Today, the Internet is mainly about content; users are no longer interested in specifying who they talk to, orwhere that someone is. Instead, they talk about what they want delivered to their system.

This contrast between system design and the actual usage patterns of the Internet has introduced ever-widening fissures in its foundation, especially in terms of availability,

security, and location-dependence. Thus, the authors of Networking Named Content

argue, there is a need to replace or augment IP with something that works at the same level as the users and “talks about data” rather than “to nodes” [Jacobson 09].

2.4.2 Routing on Content

CCN aims to change content delivery on the Internet by replacing the IP routing mech-anism that makes up the thin waist of its hourglass architecture [Deering 01] with some-thing that is oriented toward content names rather than host addresses. Figure 2.2 illustrates this. Participating nodes in the network are thus always aware of the content

Fig. 2.2: The Internet Hourglass under CCN. The thin waist of the Internet has been moved from IP to content-based routing and IP is now an optional lower-level transport mechanism. Illustration copied from

Networking Named Content [Jacobson 09].

(37)

neither packet origin nor destination. The only form of topology that a CCN node is aware of, is a list of faces. Similarly to IP, a CCN node maintains a FIB. But where IP’s FIB is a mapping of IP addresses to a single face, CCN maps namespaces to lists of faces (a given namespace may be available on more than one face). In addition, CCN maintains a ContentStore (CS) where it may cache passing content and a Pending In-terest Table (PIT) that keeps track of outstanding content requests.

For delivery of content, CCN recognizes just two kinds of network packets: Interests and Data. An Interest, as the name suggests, expresses an interest in a uniquely de-fined content chunk, andData contains that content chunk as it is being routed back to the requester.

2.4.3 Forwarding

When a piece of content is requested in a CCN network, an Interestis created at the requesting node. The Interest contains two fields that are important in the context of this thesis: A ContentName field specifying the name of the content theInterestis requesting, and a Nonce field that is chosen at random and that uniquely identifies the Interest. Assuming that the node does not have the content cached locally, the node’s CCN network stack initially examines its FIB for entries that match a prefix of the Interest’s ContentName. If it finds any, the Interestis issued on all faces that have a match for the longest prefix. If none is found, the node first broadcasts the Interest on any face that is broadcast capable, and then sends it on the remaining faces in turn. As theInterestmakes its way to another (intermediate) node, that node will search, in order, its CS, its PIT, and its FIB to determine how to handle it. If an exact match for the Interest’s ContentName is found in the CS, the content cached there is returned as Data on the face that the Interest arrived on. If not, the PIT will be searched. If an exact match for both ContentName and Nonce is found there, the Interest’s in-coming face is recorded in the list of faces that have requested the content. If the PIT search finds no matches, the FIB is searched for somewhere to forward theInterestby longest-prefix matching against its ContentName. If any route is found, the Interest is forwarded on all matching faces and a new PIT entry is created.

(38)

re-questing node(s). By matching the Nonce field of incoming Interests to those found in its PIT, a node can detect if an Interestis received more than once and aggregate the duplicates into a single PIT entry to ensure loop-free routing.

Because it records the incoming faces for any Interests it forwards, a node may route matching Data back on those faces as it becomes available, and thus it will propagate toward the requesting node. Forwarding Data always consumes the matchingInterest in the PIT, andData that does not have a matching PIT entry is simply discarded. This routing paradigm fulfills three important properties that, the authors argue, are vital to building a more efficient, content-based Internet:

• Route SymmetryDatatraffic in CCN follows the same route as was taken by the Interest that solicited it. This symmetry is an important property that allows CCN to perform more sophisticated flow control than IP, based on prediction of Data traffic flow in response to Interestrouting.

• Local Flow Balance CCN communications do not have endpoints, so all trans-missions are local between two adjacent nodes. Each node is therefore directly involved in balancing the flow on its links. This is in contrast with TCP/IP where the endpoints dictate flow balance. This means that each node involved in the routing of a packet flow can make its own local decisions about what to forward and what not to, and because of the breadcrumbs left behind by outstanding Interests, each node can also predict traffic flow in the near future. This results in a more local control of flow, where communication endpoints cannot overwhelm intermediate routers with traffic.

• Content DiffusionContent in a CCN network is automatically moved around in the network to where there is demand for it. In fact, any given piece of content will only cross any link once no matter how many consumers request it (not accounting for cache evictions). This effectively distributes communication load away from the congested center of the Internet cloud and toward the edges of the network.

2.4.4 Security

(39)

communicating with. Instead, trust must be placed with what you are transferring, in other words, with the content itself.

Authenticity is implemented in CCN by requiring that content chunks be digitally signed so any node can authenticate the payload independently. This, of course, requires a pub-lic key cryptography framework in place, and the CCN specifications provide for different such algorithms to be used, depending on the performance or security requirements of a particular piece of content. Issues of what cryptography schemes to use and how to distribute the required keys is left to be agreed upon at the application level, and thus with the developers that choose CCN as their transport.

Privacy is provided by means of encrypting/decrypting content prior to transmission and after reception. It is thus also managed at the application level, and neither in-termittent nodes nor OS-level network stacks will have to decrypt network packets to deliver content. The level of privacy desired can be varied by choosing what parts of a content chunk to encrypt. By encrypting the path name as well as the content, for example, namespace privacy can be obtained—most likely at the expense of routing ef-ficiency.

Network Security in CCN is maintained by the adherence to the flow balance between InterestandDatapackets as discussed above. This balance, as well as the aggregation of both types of traffic when identical packets are delivered, mean that a Data-based Distributed Denial-of-Service (DDoS) attack (where attackers attempt to have a third party send large volumes of Datatraffic to a victim) is not possible, while anInterest -based DDoS attack, such as those carried out by botnetworks under an attacker’s control on the Internet today, is more easily detected and thwarted: Because a node knows to expect a Data packet in return when it forwards anInterest, alarms may be set off if it suddenly forwards large amounts of Interests for some neighbor for some namespace that never delivers Data in return. CCN networks are by no means immune to security threats, but they have taken steps to counter some of the most prevalent threats on the Internet today [Jacobson 09].

(40)

Section 4.6.

2.4.5 IP Compatibility

Networking Named Content devotes quite a bit of space to discussing possible upgrade paths from an IP network to a CCN network. CCN is designed to allow an incremental deployment of CCN-capable nodes on an intra-domain level by passing CCN-specific type-length-value (TLV) blocks over the Interior Gateway Protocol (IGP) and on the inter-domain level by agreeing on a CCN discovery mechanism such as DNS Service (SRV) records [Gulbrandsen 00] or Anycast [Metz 02] IP addresses. This has the effect of creating CCN-enabled network “islands” segregated by IP-only routers that act merely as bridges between the islands rather than participate in the network. Such segregation does not allow for optimal content routing across the bridges, but within each island, it would work as a full-fledged CCN network.

The article thus provides a path to gradually upgrade the network of, for example, an ISP without replacing the infrastructure.

The IP compatibility aspects of CRN are identical to those discussed in the context of CCN, as we discuss in Section 4.2.

2.4.6 Performance

CCN is designed from the ground up to utilize the lessons learned from implementing and using TCP/IP on a large scale over the last five decades, while acknowledging the need for a transport mechanism that is more intelligent than the “bit pipe” approach of the Internet today. Thus, while CCN can service bit pipe needs like TCP/IP, it essen-tially aims to supplant higher-level protocols such as HTTP. This shines through when the performance of CCN is scrutinized: Compared to raw TCP/IP, CCN’s performance in terms of bandwidth utilization is roughly 20 % lower. This is to be expected due to the header overhead introduced by the advanced facilities offered by CCN.

(41)

Multi-use HTTP traffic (multiple consumers requesting the same content over a con-gested network link) is where CCN is meant to tackle the congestion of the Internet, and that shows in the performance measurements. The congestion scenario is simulated by transferring several identical content blobs over a low-bandwidth link onto a high-bandwidth local area network and measuring the time to completion. In this case, the transfer time increases proportionally to the total number of requests when TCP/IP is used as transport, while it increases proportionally to the number of unique content chunks being transported over the low-bandwidth link in CCN’s case.

A further advantage of CCN is its inherent ability to take advantage of multiple net-work links on a single node: Since CCN traffic cannot loop, it is not limited to routing on a spanning tree network, and any node can dynamically choose the most opportune face(s) on which to route a packet. This is demonstrated in a Voice-over-CCN scenario where multiple network interfaces are used to connect two CCN nodes. The nodes select network links as conversation progresses, and when those links are broken by physically disconnecting the network cables, the nodes must switch. CCN can handle such failover with no loss of packets and only a small number of packets being dropped by the appli-cation’s voice codec due to late arrival.

Improving network performance in scenarios where CCN may struggle is a primary goal of the CRN design work, and thus we examine the performance differences between our CCN and CRN implementations in some detail in Chapter 5.

2.5

Evaluation of CCN

(42)

in the network.

Comparison Basis

For the work done in this thesis, we are taking a “clean slate” approach to networking; in other words, we are investigating a CCN-only network that does not rely on the services provided by an underlying TCP/IP transport can be improved in its handling of mobile content producing nodes. We do thus not aim to provide a comparison to TCP/IP itself, but solely to CCN. The mobility issues we are investigating in this thesis have over time been addressed or worked around in the TCP/IP stack, but still remain somewhat unclear for a network operator looking to deploy a CCN-only network.

2.5.1 CCN: A Revolutionary Improvement on TCP/IP

We believe that CCN is an interesting research prospect that can improve data transport in suitable small-scale networks. We believe that it does so by improving on TCP/IP in four key areas, which we will discuss below. These areas correlate well with the key points of Networking Named Content [Jacobson 09], and that is no accident. They are, we believe, facilitators that will enable netizens to develop features and services that can not be provided on the Internet currently.

Content Diffusion and Caching

The term “going viral”, used today in the context of the Internet [Dic 14], is meant to describe the unforeseen virus-like spread of a piece of content that has grown very popular among users. Just as with the spread of a disease, predicting what content will go viral is a challenging problem that we have yet to solve, and thus we cannot always prepare for it by re-hosting the viral content on high-bandwidth hosts or distributing it to CDNs around the world. In fact, the Internet only works as well as it does because most content currently is hosted fairly centrally in massive data centres with very high Internet bandwidth. If we are to create a truly distributed network, which we believe will bring many benefits with it, we must thus solve the problem of how to host popular content on systems that do not have virtually unlimited CPU power and network bandwidth. This is where CCN may bridge the gap between legacy and future.

(43)

hosting can be moved out of the data centres and into the hands of the people who produce the content themselves. This, in turn, will help address issues such as privacy concerns, network neutrality, and content ownership, while lowering the content delivery latency.

Distributed Network Security

If content hosting moves from the data centres onto people’s own devices, we need safeguards in the network that will help protect those devices from abuse by malicious entities. Fortunately, CCN has built-in protection from most of the kinds of cyber-attacks that we see on the Internet today. By removing the concept of endpoints in the network, CCN also removes the (ability and) need to trust any node in the network. Thus, network entities cannot pretend to be anything that they are not. This forces the network to rely on every node that routes the data to participate in maintaining security rather than leaving that task to applications of the communication endpoints as is the case with TCP/IP. Any CCN node can intelligently examine and evaluate the traffic flows that it is forwarding and discard any packets that are deemed to be duplicates or malicious. Thus, an attacking node would need to generate valid, cryptographically signed, and highly varied packet flows to perform any kind of attack and would then have to defeat any intelligent attack analysis algorithms on the intermediate nodes. By tasking the whole network with defending against wrongdoers, and providing the tools to do so, attacks such as denial-of-service or flooding become much easier to defend against and may be stopped much closer to the attacker than today. This is not a means to defend against all malicious traffic, however. If, for example a botnet in a CCN network is able to cause a node,A, to generate valid content on a large range of different routable namespaces, there is no way in CCN to stop them from exhaustingA’s bandwidth or on-board resources by sending a very large number of Interests for different namespaces. As long as the content they are requesting is not cached anywhere along the way, and the issuedInterests generateDatapackets, distinguishing the botnet traffic from good-natured traffic is virtually impossible.

(44)

Intrinsic Content Authenticity

By incorporating a public key cryptography infrastructure into the network transport, CCN can provide the best of two worlds by combining distributed content caching with authenticated content. Users of a CCN network never need to worry about who crafted the content they are consuming: It is easily verifiable by the attached digital signature. This alleviates the threat of spoofing and man-in-the-middle attacks which are the attack vectors for the countless identity theft issues that we see on the Internet today. Being able to trust content no matter how you got a hold of it is a vital piece of the CCN puzzle and an enabler for many of the features we discuss above.

Consumer Mobility

The main pain point of CCN that CRN is meant to address in content consumption networks, is node mobility. Devices today tend to move around much more than what has historically been the case; mobile phones for example will roam among available cell towers as they move physically, and will switch from 3G network to WiFi network when a familiar access point is in range. This is a behavior that TCP/IP was not originally designed to handle well [Kutscher 13], and several additions to the paradigm have been proposed to remedy the situation [Perkins 10, Bosch 13].

CCN handles node mobility differently: The only requirement that CCN imposes on its requesting nodes mobility-wise, is that they remain in place from the time they issue an Interest to the time the correspondingData packet has been delivered along the trail of breadcrumbs left behind the InterestThis restricts nodes to immobility for at most˙ a few hundred milliseconds from a content request, on average. At worst, aDatapacket will become undeliverable due to a moved node, and that node will then have to re-issue the Interest that solicited it. The scale of this problem is also lessened considerably because CCN does not have IP’s connection-oriented TCP protocol, so no state needs to be re-established when a mobile node moves a network conversation to a new point in the network.

2.5.2 Handling Mobile Content Production

(45)

turn our attention to mobility of the content repositories that receive theInterests and deliver theData. Interests have no breadcrumbs to follow toward a repository, but must rely on the information present in each node’s FIB. If a repository moves, then the FIB must be updated to reflect that a new set of faces must take over delivery of content for a given namespace prefix. In CCN, this happens by a process of timeouts and flooding: When anInterestis forwarded to a location where a servicing content repository used

to be, it will reach a dead end and nothing will happen until that Interesttimes out, indicating that delivery is not possible. Once the timeout is reached, the requesting node can react by ignoring its FIB and flooding theIntereston all its faces in the hope that it can find another cache that holds the content.

Improving CCN

This process of timeouts and flooding is one of the aspects that we wish to address with the creation of CRN. By letting network nodes communicate changes in network or namespace topology to their neighbours, we aim to enable a rapid response from nodes to changes in the network, thereby providing faster FIB convergence to the updated scenario with the ultimate aim of updating FIBs even before any Interests have been issued for the content that has moved.

The approach we take to enabling such rapid response takes its inspiration from how natural lightning strikes deliver charge from a cloud to the ground. We call this charge modelling, and it is discussed in detail in Section 3.2.1.

Because we are focusing on the mobility aspect of CCN, there are many aspects of the paradigm that are out of scope for this thesis, such as, e.g., caching and scalability issues and the security features of CCN. Thus, we focus our work solely on the routing and strategy layers of CCN.

2.5.3 Content Volatility

(46)

of a piece of content when that content is prone to being updated.

In this thesis, we also briefly explore the idea of using charge modelling to model content volatility. By assigning a charge to each piece of Data, the content producers can give other nodes hints about how long it is safe to cache them for, or how far from their origin they should be stored. We explore these concepts in more detail in Section 4.1.3.

2.6

Comparison Summary

To provide an overview of the three main modes of content transport we are considering here, we present a table that highlights the main features we discuss throughout this thesis. Table 2.1 shows a summary of the advantages and drawbacks of each of the three

TCP/IP CCN CRN Consumer mobility Yes Yes Yes Producer mobility Yes No Yes Distributed flow control No Yes Yes Content diffusion No Yes Yes Content authentication No Yes Yes Volatile content support Yes No Yes High bit-pipe efficiency Yes No No

Table 2.1: TCP/IP-CCN-CRN Comparison. CRN builds on CCN, there are many points of similarity. This thesis focuses mainly on the producer mobility aspect of CRN.

(47)

retains the same name, while the content may change over time. Bit-pipe efficiency is the degree to which the paradigms fully utilize the network traffic to move content. Here, CCN introduces some overhead compared to TCP/IP in the form of content locators, encryption headers, and more. CRN is expected to introduce more overhead than CCN where raw bit-pipe effiency is concerned, as it adds metatraffic that establishes routes to mobile nodes.

We are not aiming for an exhaustive comparison between the three here, but are merely interested in how well they support the main mode of Internet usage, which is content consumption. This comparison is done on a protocol level; many application-specific tools such as content distribution networks or peer-to-peer networking technologies have been developed that allow TCP/IP to do content diffusion ot content authentication. However, the premise of CCN—which we base the work in this thesis on—is to investigate whether some networks can be better served with a different transport mechanism. CCN thus aims to bring these features from the application level down into the networking stack and make them ubiquitous.

We have highlighted the features that we believe distinguish CRN from CCN. In the following chapters, we will examine and back up the claims made here.

2.7

Evaluating CCN and CRN

(48)

inNetworking Named Content that cast even further doubt on its ability to support such nodes. Thus, in order to facilitate experimentation and comparison of CRN to CCN under a best-case interpretation, and to avoid comparison to any single implementation that may perform particularly poorly in our scenarios, we have opted to create a new implementation.

In both our CCN and CRN implementations, we have chosen to omit a large part of the CCN feature set, as they are not relevant to the comparisons we are looking for. Thus, our two OMNeT++ modules used for simulations throughout this thesis contain the following:

• PIT, FIB, CSBoth implementations have their own PITs and FIBs, and the CS codebase is shared between the two. Since the inner workings of PITs and FIBs are essential to how routing is done, we have seen it as a necessity to provide full implementations of the features that each of these provide.

• Strategy Layer The strategy layer is where routing decisions happen, and thus it is arguably the most important piece of the puzzle that is CRN. It is where we can provide a differentiation, and therefore it is implemented at a detailed level.

• Forwarding Engine At the lowest level of our simulation, is a packet issuing/re-ceiving engine that does the actual moving of bits. We assume a very flexible link layer directly underneath our forwarding engines, and thus packet can be any size (in other words, no chunking is done in the transport layer). Content versioning is not implemented.

(49)

2.8

Related Work

In this section, we present and relate the state of the art of academic research that has formed the basis and inspiration for the work that has gone into CRN.

Much work, particularly recently, has been done on CCN mobility research, and we feel it is important to highlight how CRN compares to this work. We thus draw analogies through the collected body of research and show how our paradigm has been inspired by, but still differs from, what has already been done; we do this by explaining and motivating the design decisions we have made based on existing publications.

2.8.1 Fully Mobile Infrastructure

(50)

No Mapping Overlay

A New Perspective on Mobility Support [Zhu 13] suggests that for larger networks, the best approach to providing mobility support for nodes is to use a mapping-based overlay, such as a DNS-like system (as used by, e.g., DONA [Koponen 07]), that can map a node’s “home” address to a “mobile” address where it currently resides. Other approaches (such as NetInf [Dannewitz 13]) forego the DNS systems and opt for a distributed name reso-lution overlay or a distributed routing overlay (such as done by PSIRP [Bari 12]). The common denominator for these systems is that they map a permanent locator (either a node address or a fixed content namespace) to a temporary locator. There are two problems with t