An Investigation into the Application of Content-Centric Networking within Challenged Network Environments using CCNx

(1)

(2)

IT 14 032

Examensarbete 45 hp Juni 2014

An Investigation into the Application of

Content-Centric Networking within Challenged Network Environments using CCNx

Tarek Elshaarani

Institutionen för informationsteknologi

(3)

(4)

Teknisk- naturvetenskaplig fakultet UTH-enheten

Besöksadress:

Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0

Postadress:

Box 536 751 21 Uppsala

Telefon:

018 – 471 30 03

Telefax:

018 – 471 30 00

Hemsida:

http://www.teknat.uu.se/student

Abstract

An Investigation into the application of

Content-Centric Networking within Challenged Network Environments using CCNx

Tarek Elshaarani

Information Centric Network (ICN) architectures offer a viable design to cope with the disruptive nature of Challenged Network environments. They aim to address the challenges of unreliable connectivity and location transparency to offer a delay- and disruption-tolerant solution. Named Data Networking (NDN), a prominent ICN architecture, uses a publish/subscribe-driven model and relies on two main message units for communication, called Interests and Data. Instead of a host-based model for data retrieval, an addressing scheme based on named data is utilized. The naming of data allows for retrieval of data from the network without the knowledge of individual hosts.

This thesis studies NDN behavior in a disruptive network environment. More specifically, we use CCNx as an implementation of a Content-Centric Networking protocol that inherits key characteristics from NDN. We study the behavior of CCNx using the Haggle testbed to simulate a simple disruptive network environment.

We develop a delay/disruption-tolerant framework based on CCNx and implement the game Tic-Tac-Toe using that framework. The framework design is presented with an analysis into various alternatives that were considered. A more complex five-node experiment with link disruption is performed using the framework to evaluate CCNx in a real world scenario. We conclude that CCNx is good at handling disruptions associated with Challenged Networks.

Examinator: Ivan Christoff

Ämnesgranskare: Christian Rohner Handledare: Frederik Hermans

(5)

(6)

Acknowledgments

I must thank my parents for their continuous support through challenging times. Special thanks go to Frederik Hermans and Fredrik Bjurefors for their help without this thesis would not be complete.

(7)

Chapter 1 Introduction

A boom in user-generated content along with the widespread use of social networks has created a significant increase in the amount of data generated on a daily basis. A major contributor to this increase is the ubiquity of mobile devices that allow users to generate and consume data without being restricted to location. Despite the advances in wireless communications that allow for larger coverage areas and higher transmission rates, current networks fall short in situations where there is no connectivity due to ge- ographical limitations or when there are disruptions that affect the infrastructure. Such situations present two main challenges with regards to data distribution: 1) Unreliable connectivity 2) Location transparency. There is an ongoing effort to improve upon both factors to enhance user experience. This thesis investigates Content-Centric Networking (CCN) as one such paradigm that attempts to overcome these challenges.

Unreliable Connectivity The conventional method of data distribution involves end-to-end connection between nodes on a network to query, publish, and retrieve information. Existing communication protocols offer unsatisfac- tory performance in situations where connectivity is unreliable. TCP/IP is known to perform poorly in such environments, especially because end-to-end paths between communicating nodes are often unreliable resulting in continuous interruptions[4]. While TCP/IP has evolved to accommodate different types of networks and suit a variety of environments, it still is not suited for some situations when used over high latency, unreliable, or dynamic networks. This is mainly due to the basic requirement to have an end-to-end connection between hosts for data to be exchanged.

Location transparency Another shortcoming with conventional network architectures is in situations where node location is dynamic due to mobility.

(11)

If the node holding particular data is not accessible on the network at a particular instance, the information is subsequently unavailable due to the lack of stable end-to-end connectivity. Furthermore, if the node reconnects to the network from a different location, the data cannot be retrieved from the location it was previously known to be found. The dynamic nature of the nodes makes it unfeasible to apply conventional indexing methods that map data to specific locations from which it can be retrieved.

1.1 Challenged Networks

To address the issues of both intermittent connectivity and location transparency, experimental network architectures offer different approaches that do not rely on reliable end-to-end connectivity between nodes or precise knowledge of their location. These alternate architectures are particularly relevant to one group of networks, henceforth referred to as Challenged Net- works. This family of networks provide a set of unconventional architectures that attempt to address problems that are not offered by other widely de- ployed network architectures, namely TCP/IP-based ones. They operate in conditions where there is a low power requirement, sparse connectivity, fre- quent mobility, and more importantly, unpredictable link disruptions. This is particularly true for wireless networks where connectivity can be intermittent due to power or coverage limitations, interference resulting in re-high transmission rates, and other mitigating factors. The nature of intermittent connectivity may vary from milliseconds to hours during often with only small windows of opportunity for data to be exchanged[3].

The characteristics lead to the basic issue that concerns such networks, which is the the lack of continuous end-to-end communication between nodes.

A generally accepted approach applied to address this drawback is a tech- nique commonly referred to as store-and-forward. This in-network caching solution takes advantage of using resources of reachable nodes on the network as intermediaries to store data until it can be routed to the destination.

While they follow those general guidelines, there are several types of Chal- lenged Networks that address various issues slightly differently than the oth- ers and each are a topic of research on their own. A number of the most prominent are introduced briefly below.

Delay Tolerant Networks: They are mainly concerned with being resilient to communication delays, high latency, or round trip times. One application of this network would be in inter-planetary communication[3][2].

(12)

Disruption Tolerant Networks: These are similar to Delay Tolerant Net- works, and commonly grouped with them, but are more focused on prevention and recovery from link degradation and disruption. The nodes on the network must be able to both reconnect from link failures as well as recover from potential data loss or inconsistency if transfer is interrupted. This may be applicable to high availability networks and military use[3].

Opportunistic Networks: Commonly considered a subset of Disruption Tolerant Networks, this type of network makes no assumptions about reliable underlying infrastructure. They are mainly associated with ad- hoc wireless mobile networks where there is a high rate of mobility and unpredictable connectivity or coverage between nodes. Due to the lack of consistent connectivity, most communication is asynchronous and routed on a hop-by-hop basis using opportunistic routing techniques.

This type of network can be used to disseminate information in cases of natural disasters or censorship[6].

1.2 Information-Centric Networking

One proposed paradigm that offers a solution for Challenged Networks is Information-Centric Networking. In contrast to IP-based networks which are mainly concerned with host-based addressing on the network, Information- Centric Networks (ICNs) use naming schemes to label information that can be queried and retrieved from the network. In this sense, the data distribution method is abstracted from the node level to an information level and is independent of its location. Communication is carried out in terms of requesting and publishing named information where the replication of data is handled at the network layer regardless of the originating source. This char- acteristic makes ICN architectures attractive for use in Challenged Network environments including applications such as content distribution (CDNs), disruption recovery, and flash-crowd handling.

While a number of different ICN architectures have been proposed, they all rely on three basic principles. The first is that all data is represented as objects, which are manipulated by publish and subscribe operations obsolet- ing the importance of data locality. The second is caching is an inherent part of the architecture supported by all nodes in the network assisting in both the acquisition and dissemination of information. The third and final principle is objects, representing data, are intrinsically secure using cryptographic signatures created by the original publisher, which can be verified by con-

(13)

sumers. On the other hand, there are many more characteristics that differ between architectures. These include naming and name resolution, routing, caching mechanisms, Error and Flow control, privacy, network heterogene- ity, and performance. Each of these properties is worthy of being a research area of its own account[5]. Nonetheless, ICNs are claimed to be a scalable and cost-effective solution that may replace conventional end-to-end point networks and offer more in areas where such networks are lackluster such as mobility and disruption tolerance.

Some of the prominent ICN-based projects include 4WARD, Sail, Pursuit, Connect, and Comet[9]. One of such ICN projects that currently enjoys growing interest from the research community is Named Data Networking (NDN). NDN is based on principles of an ICN, yet still builds upon the strengths of host-centric networks[13].

1.2.1 Named Data Networking

As with other ICN architectures, NDN is publish/subscribe-driven using basic message units called Interest and Data. Interest messages represent requests for data, or Content Objects. Data messages carry Content Objects as responses to Interest messages. Each node on the network is considered a router, which has one or more interfaces, commonly referred to as faces.

Each node also has the ability to store data in a local repository called a Content Store. The Content Store also acts as a cache for Content Objects on nodes that do not originally hold the data. Content Objects are referred to by a unique naming scheme consistent throughout the network and are all signed crytographically. Additionally, each node maintains two tables: 1) a Forwarding Information Base (FIB) that maps Content Object names to faces that they can be found; mainly used for routing 2) a Pending Inter- est Table (PIT) that maps Interests to the face from which that they were received.

A requester or consumer of a data controls the flow of communication and it is their responsibility to ensure that the required data is received correctly.

The requester sends out an Interest message on the network by its unique name. An intermediate node on the network that receives this packet will look up the requested object in its local Content Store in an attempt to fulfill that request. If that object is found, then a Data message containing the Content Object is sent back to the over the same face. In the case that it is not locally cached, an entry is added to a PIT to record where the Interest message came from. This also helps limit the number of Interests generated on the network as only one will be forwarded regardless of how many are

(14)

face to route this Interest. Because FIB entries used for routing can be prefix based, they allow for flexibility in terms of specifying the destination interfaces on which messages are to be forwarded. It is also possible to forward a request to all available faces. The Interest is forwarded over those faces until it reaches a node which can satisfy that request. That node will then use the PIT to identify which face the request came from and send a Data message back containing the Content Object requested. Because message traversal information is not stored, the return path of the Data message may not necessarily be identical to the one used by the one taken by the corresponding Interest message. Any intermediate nodes between that node which responds to the request and the original requester will store the response in their Content Store and remove the entry for that Interest from their PIT[7].

Interests can be sent using multicast or broadcast mechanisms to allow for a greater search space. A Data packet is only sent as a response to a corresponding Interest and a node will only respond with one Data packet on each face for as many Interests it receives. These properties, along with Content Store caching, provide means that allow data to be sent returned to the requester efficiently from a nearby node, with resilience to mobility and link disruption.

While one aim of the NDN project is to build a foundation for the next generation of an Internet-capable architecture, it is also particularly inter- esting when applied to Challenged Networks. While it would theoretically provide a good platform due to the nature of the architecture, it is important to test and validate these claims in order to have a better understanding of the characteristics that make it successful[13].

(15)

Chapter 2 Problem Definition and Thesis Contributions

The fundamental principle of Information-Centric Networks not relying on end-to-end connectivity raises a claim that they are a viable contender for use within the perturbed nature of Challenged Networks. This thesis aims to understand the behavior as well as evaluate the performance of the Named Data Networking (NDN) architecture in the context of Challenged Networks, with a particular focus on its disruption tolerance capabilities. Experimentation focuses on scenarios in which end-to-end connectivity between the produc- ers and consumers of information is unreliable as a result of link disruption, for example, due to mobility. The effects of link disruption on the need for data re-transmission is a key topic of this investigation. The experiments are designed around a prototype NDN implementation, called CCNx. The experiments are run using the Haggle[8] testbed to simulate link disruptions between nodes.

The questions posed below guide the structure of the work presented in this thesis. The answers to those questions, in turn, define its contributions.

How do link disruptions affect CCNx behavior?

CCNx behavior is studied by running a set of simple experiments that simulate link disruption scenarios to observe the effect on request and response messages exchanged between nodes. This allows for a better understanding of the messaging protocol and how re-transmission operates. The experiments highlight the importance of caching as an inherent feature of CCNx.

They also illustrate the effects on performance as a result of introducing relay nodes as well as increasing the re-transmission rate. This work is presented in Chapter 4.

(16)

How can an application be designed on top of CCNx to tolerate link disruption?

CCNx is used as a foundation for a multi-player game platform (DTGP) that is designed to suit a Challenged Network environment. The understanding of message re-transmission behavior from Chapter 4 is applied to the design of the platform. A Tic-Tac-Toe implementation that runs on top of the platform is presented as a sample turn-based game. Key design factors for the platform including node discovery, addressing, and game state representation are discussed in Chapter 5. A number of other designs that were investigated during the design process are also discussed.

How does a delay-tolerant application behave with link disruptions?

The sample delay-tolerant implementation of Tic-Tac-Toe is evaluated by running a link disruption simulation in a five node configuration. The network-focused perspective from which the experiments are analyzed is ex- plained. Additionally, the metrics collected from the experiments are analyzed and presented including request satisfaction ratio, number of requests required to complete a game, and the amount of time to satisfy a request.

This work is presented in Chapter 6.

The thesis does not investigate NDN issues specific to addressing and routing. A basic naming and addressing mechanism for CCNx is assumed and introduced in Chapter 3. The subject of security is also not discussed and for the purposes of our scenarios, all data is assumed to be in clear text with a minimal cryptographic footprint that is inherent to the protocol and is ignored in all calculations.

(17)

Chapter 3 A Brief Introduction to CCNx

CCNx is a Content-Centric Networking transport protocol based on blocks of named data[11]. CCNx is also regarded as an architecture on which delay/disruption-tolerant applications can be built upon. CCNx follows the basic principles of ICNs in that it abstracts location by identifying data instead of hosts on the network. Nodes that are a part of a CCNx network also function as routers that forward requests and data as appropriate. It is based upon basic NDN principles introduced in section 1.2.1. Throughout this thesis, CCNx¹ is used to evaluate the claims of how well NDN may perform in a Challenged Network setting. The key CCNx constructs are introduced below as they are referenced throughout the remainder of this document[11].

Node: Describes an entity on the network that may communicate with oth- ers using the CCNx protocol. A node will run one or more applications as well as a CCNx daemon (CCNd) that implements the protocol itself and manages low-level communication.

Face: An interface on a node that can be used to send or receive data. On a physical level, this may correspond to various antennas or network interfaces that allow access to other nodes over different communication mediums. Logically speaking, different faces are assigned as communication gateways for applications and to specify network routes to other nodes.

Interest Message: This is the basic construct used by the CCNx protocol to designate requests for data. The message is specified as a URI in the form: ccnx://data/xyz.

1CCNx version 0.6.0 is used for all experimentation.

(18)

Content Object: This is the basic construct used by the CCNx protocol to designate data responses to Interest messages. A Content Object is encoded and signed by the node that sends it. A Content Object corresponds to one and only one Interest Message that is consistent throughout the network.

Content Store: A local cache on each node on the CCNx network that allows faster retrieval of data as well as contributes to the in-network caching properties of the architecture.

Prefix: Commonly referred to as a CCNx Prefix, this identifies an entire or partial CCNx URI. Prefixes are used to match an Interest to its corresponding Content Object.

Forwarding Information Base (FIB): A data structure that maintains a mapping of CCNx prefixes and the outbound faces on which they can be reached. This table is populated over time as nodes on the network observe Interests fulfilled by Content Objects.

Pending Interest Table (PIT): A data structure that maintains a list of Interests received by the node it resides on. The list is used to track requests that have not yet been satisfied.

Additionally, a number of factors particularly relevant to CCNx behavior as it is used throughout this thesis are introduced below.

Message Exchange Interests and Content Objects are the only forms of communication between nodes. Those two messages are used by CCNx for various purposes during node start up, identification, and security. Through- out this thesis, much of the message exchange is considered spurious and the focus is only on message interaction that affects the outcome of the experiment.

Data Delivery While it can run using layer 2 broadcast or multicast delivery, CCNx also runs on top of UDP or TCP for experimental purposes.

For the purposes of the experiments presented, UDP is used to communicate between nodes on the network. Being a connection-less protocol, UDP fa- cilitates the simulation of link disruption and avoids any discrepancies that may be introduced by TCP in a challenged network environment.

(19)

Naming and Addressing Throughout this thesis, CCNx names follow a simple prefix with the structure ccnx://data/object. No complex hierar- chy or structure is required for the experiments used. This also simplifies forwarding as each node on the network will have an entry in its FIB for that specific prefix and the address of the node that stores that data or acts as an intermediate router to it.

(20)

Chapter 4 Evaluating NDN Performance in a Challenged Network

A number of simple experiments using CCNx were conducted in order to identify its behavior in a Challenged Network environment, particularly with regards to Interest re-transmission. The experiments are designed around two main nodes: a receiver node that requests a certain CCNx URI, and a sender node that listens for and replies with Content Objects that match a particular prefix corresponding to locally stored data. Additional nodes are added to act as relays between the two main nodes. These intermediate nodes have no applications running on them except for the CCNx daemon. Once the receiver node receives the data it requests, the experiment is terminated.

In each case, Interest satisfaction response times are measured and presented at the end of the experiment.

The experiments presented in this chapter help understand CCNx Inter- est re-transmission behavior using variations in link availability and interruption between the nodes throughout different stages in the CCNx message exchange.

4.1 Haggle Testbed

To facilitate the simulation of link disruptions, the Haggle testbed[8] is used.

This testbed allows the specification of intervals during which links between specific nodes are either up or down. The application running on each node will then react to the state of the network. While it is out of scope of this document to go into detail of how the testbed is designed, a number of mod- ifications were made that are worth mentioning as they had a considerable effect on accuracy and consistency of the results collected and behavior ob-

(21)

served.

Threading: Early attempts to run the experiments on the testbed resulted in inconsistent results due to synchronization issues between the testbed components, namely the two main nodes and the testbed driver application. To resolve this, a control thread was added to the testbed driver code to provide a centralized launch mechanism amongst all nodes participating in an experiment. After each node completes its initialization, it sends a beacon back to the testbed driver. When the testbed driver accounts for all nodes participating in that specific experiment, it broadcasts a start signal to those nodes. When each node receives this signal, the application is started. This solution allowed the results to be more predictable, especially with regards to the first Interest in each experiment, which otherwise may be difficult to account for.

Uni-directional Link Disruption: The Haggle testbed utilizes iptables as a method to simulate and control link disruptions. The configuration file associated with each experiment specifies the interval when a link is up. If an interval is not specified, the link is down. When simulating situations where there is a link breakage immediately after an Interest is sent by one node and before it is sent by another, (i.e. experiment 1c) it is difficult to guarantee that iptables would have executed the firewall rules quickly enough, especially when the time window is so small. As an alternative, a modification was made to allow the configuration file for an experiment to specify when a link between two nodes can be considered half open effectively allowing uni-directional traffic for the duration of that interval.

Configuration: Various configuration changes were made to the structure of the configuration file and associated scripts to allow for the modi- fications presented above as well as other logistics such as specifying different applications or configuration files for on each node.

4.2 Notes on Data Collection

The intervals measured include all CCNx protocol activities, including key retrieval and content object verification, beyond the initial registration of the application with its CCNd instance. The time involved in cryptographic activity is inherently absolved from the comparison by being included in all measurements.

(22)

Due to the characteristics of the underlying testbed, the measured response times for the experiments may deviate from the norm in certain situations. The discrepancies are mainly a result of synchronization issues between the nodes that are running as virtual machines on the same physical hardware. This makes it difficult to control precise execution times and may introduce minor drifts with clocks that influence data collection, especially with the short time frames used within the experiments. The code running on the nodes has been tuned to better handle these synchronization issues, albeit not perfectly. Despite these imperfections, the discrepancies are minor and can be treated as outliers as they no real impact on the total time of Interest success, especially when an Interest must be re-transmitted.

4.3 CCNx Interest Re-transmission Behavior

4.3.1 Experiment 1: Network with two nodes and one link

This experiment involves two nodes, N₁ and N₂, which communicate over a single link. N₂ is the receiver node, while N₁ is the sender node.

Figure 4.1 Experiment 1 Network Topology

It includes three different scenarios to analyze Interest re-transmission between the sender and receiver nodes. Figure 4.1 illustrates the topology of the network. The following scenarios are tested:

(a) No interruptions or disconnections.

(b) Link is down from start of run. (Interest not transmitted)

(c) Link is down shortly after start of run. (Interest transmitted, response lost)

The following parameters are defined for the scenarios in the experiment:

• Interest timeout period: 2 seconds

• Interval between Interest re-transmissions: 5 seconds

• Size of data: 512 bytes

(23)

Scenario 1a: No link disruptions

This scenario involves no link interruptions or disconnections. It establishes a baseline for delays to be expected under non-impaired network conditions.

The receiver (N₂) requests information from the sender (N₁). It is expected that the first Interest is immediately satisfied.

Figure 4.2 Experiment (1a) Link between nodes is always up

Observations:

Based on a number of 10 runs, the scenario yields the expected end result of the data being received with a single Interest (i₁). The following information shows response times for the requested data being successfully received:

Minimum=11, Maximum=19, Average=15.5 (milliseconds) Discussion:

As shown in figure 4.2, N₂ requests the CCN URI ccnx://test/1 at the application level which runs on top of the CCNx daemon instance running on the same node. The application sends an Interest specifying the URI using the network face that is connected to the daemon. The Interest has a number

(24)

of parameters, most notably its lifetime¹, which is set to 4 seconds for this experiment[10]. The Interest triggers an interest_from event on the the local CCNx daemon which results in that Interest being added to the local Pending Interest Table (PIT) as there is no existing entry. A look-up is then performed on the Forwarding Information Base (FIB) which returns a match for the prefix ccnx://test on a face that connects to the other node. The CCNx daemon then triggers an interest_to event which relays the request over that network face to N₁. Once the Interest is sent, the CCNx daemon adds the Interest to its PIT.

The CCNx daemon on N₁ receives the Interest on its network face and queries its PIT, which results in no matches. The FIB is then checked for the same prefix and a match is found. The daemon then forwards the Interest to the application face. The application responds by sending back a matching Content Object to the daemon. Signature verification is then performed by the daemon to verify the Content Object integrity. When verification is complete, a consume event is issued by the daemon followed by a content_from event that identifies that the daemon has sent the data across the network.

At this point, the Interest is considered satisfied and can be removed from the PIT.

At this point, the file is cached as a Content Object in the Content Store on N₁. A consume event followed by a content_to event results in the Content Object being sent over the network. The data packet is received on N₂’s daemon and processed through a content_from event on the daemon.

A look-up is performed in the PIT and a match is found because of the earlier Interest sent by N₂. A consume event sends the matching Content Object to the application face interested in the prefix. Finally, a content_to event signals that the application reads the data from the local CCN daemon Content Store into memory and writing it to disk to conclude the transfer.

The experiment demonstrates the behavior of two CCNx nodes in the absence of link disruptions. An average retrieval time of 15.5 milliseconds was recorded.

Scenario 1b: Link interruption before request is sent

This scenario tests Interest re-transmission by the receiving node (N₂). This is done by simulating a loss of connectivity for a duration of 4 seconds when the experiment is first started. It is expected that this loss will result in the first Interest being sent from N₂to be lost and force a timeout before another Interest is resent, which can then be fulfilled.

1The lifetime is not readily configurable based on the implementation code and http://www.ccnx.org/pipermail/ccnx-dev/2010-August/000249.html up to version 0.6.0).

(25)

Figure 4.3 Experiment (1b) Link down before Interest is sent Observations:

Based on a number of 10 runs, the scenario yields the expected end result of the data being received based on the second Interest. The following information shows response times for the requested data being successfully received:

Minimum=8013, Maximum=8066, Average=8019.5 (milliseconds) These times are noticeably longer than the ones from experiment 1b. The result recorded is a combination of the timeout period for the first Interest, the retry interval, and the successful Interest response time. This total retrieval time observed also includes any additional time required to minimize synchronization issues between the applications.

In addition, the following times identify the response time for the (second) successful Interest:

Minimum=11, Maximum=65, Average=18.2 (milliseconds)

These times are very similar to the times recorded in scenario 1a for an immediate (first) successful Interest.

(26)

N₂starts in the same manner it did for scenario 1a as shown in figure 4.3.

It requests the CCN URI ccnx://test/1 at the application level. A match is not found in the local Content Store or the PIT, so the Interest is added to PIT for the lifetime of the that Interest. The FIB is then searched and a match is found for that prefix. The Interest is sent over the network and the daemon awaits a response. Because the connection between the two nodes is down at this point in time, the Interest never reaches N₁. After a lifetime of 4 seconds, an interest_expiry event is triggered signaling the end of the lifetime and corresponding entry is removed from the PIT.

The application on N₂ is designed to retry the requests 3 times with a retry interval of 4 seconds in between attempts. After it timeouts from the first Interest, it waits for the user specified retry interval and sends another request. The second time an Interest is sent, the link between the two nodes is up and the Interest reaches N₁. On N₁, the CCN daemon receives the Interest and follows the same steps outlined in scenario 1a until the data is received.

While the total retrieval time is higher to account for the first lost Interest, the average response time for the second Interest is similar to the one recorded in scenario 1a. In this case, we observe a higher maximum retrieval time for the successful Interest, but this is likely to be attributed to the node synchronization discrepancies discussed earlier and can be largely ignored.

Scenario 1c: Link interruption after request is sent

This scenario tests Interest re-transmission by the receiving node (N₂). In this case, link interruption is introduced after the Interest is received by the sender node (N₁). It is expected that this interruption will result in the loss of the first Interest and after its lifetime expires, a second Interest is sent, which is then satisfied.

(27)

Figure 4.4 Experiment (1c) Link down after Interest is sent

Observations:

Based on a number of 10 runs, the scenario yields the expected end result of the data being received based on the second Interest. The following information shows response times for the requested data being successfully received:

Minimum=8006, Maximum=8012, Average=8007.7 (milliseconds) These times are similar to the ones observed in scenario 1b due to the Interest lifetime expiry, retry delay, and second Interest being the main con- tributing factors.

These retrieval times are slightly shorter than the ones recorded in scenarios 1a and 1b.

(28)

In this scenario, N₂ behaves the same way as it did in scenarios 1a and 1b. Figure 4.4 illustrates when the Interests are sent throughout the timeline of the experiment. A request is made for the CCN URI by the application which triggers an Interest that is sent over the network. In this case, the link between the two nodes is up when the Interest is received by N₁, however, the link drops before a response in the form of a Content Object is sent back.

N₁ follows the normal procedure by searching for the requested prefix in its Content Store, loading the Content Object from the local application, then sending it back over the network. However, because the connection is lost by the time the Content Object is sent back, the CCN daemon on N₂had already expired the Interest from its PIT which results in the Content Object being discarded. The receiving application will then send a new Interest after its retry interval elapses, which corresponds to when the connection is restored.

This allows the second Interest to propagate successfully, and the Content Object to be sent back without interruption or delay.

It should be noted that in this case, the Content Object by the CCN daemon on N₁making it unnecessary to propagate the Interest to the application running on that node. The prefix is matched directly to the Content Store and is sent back over the network without intervention from the application reducing the response time. This explains the faster retrieval time for the successful Interest than in the previous scenarios.

Conclusion

Throughout the simple experiments conducted with a single link connecting two nodes, it can be concluded that the CCNx daemon does not submit Interest messages other than those expressed by the application driving the requests. This follows the experiment design so that Interests can be studied individually. When Interests are lost or not satisfied due to transmission errors, it is the responsibility of the application to send another Interest until valid data is received. It is important to note that although the CCNx daemon does not attempt to re-transmit Interests itself, it does provide the capability of validating data being received by matching it to the Interest information as well as originating Content Object.

In a Delay Tolerant environment, it will be the responsibility of the application to make sure that there is a continuous stream of Interests to recover from a loss of connectivity.

(29)

4.3.2 Experiment 2: Network with three nodes and two links

This experiment involves three nodes, N₁ and N₂ as well as R, which acts as a relay node. N₁ is the sender node, while N₂ is the receiver following the notation in experiment 1.

The experiment tests scenarios similar to the ones outlined in Experiment 1 with the addition of the relay node. Figure 4.5 illustrates the topology of the network. The three scenarios are:

(a) Both links are up.

(b) Link between N₁ and R is down before Interest reaches R.

(c) Link between N₂ and R is down just after Interest reaches R.

The following parameters are defined for the scenarios in the experiment:

• Interval between Interest retries: 5 seconds

Scenario 2a: No link disruptions

This scenario involves no link interruptions or disconnections. The receiver (N₂) requests information from the sender (N₁). It is expected that the response data is promptly returned through the relay node. Figure 4.6 illustrates the connectivity between the nodes throughout the timeline of the experiment as well as when the Interest is sent. In this scenario, there is a single Interest that is sent from N2 to R.

(30)

Figure 4.6 Experiment (2a) Links between nodes are always up

Observations:

Based on a number of 10 runs, the scenario yields the expected end result of the data being received based on the first Interest. The following information shows response times for the requested data to be successfully received by (N₂):

In this case, N₂ sends an Interest which must be propagated to N₁. As an intermediate relay node, R relays the Interest to N₁. N₁ then sends data back to R, which relays it back to N₂.

Analysis:

The application running on N₂ requests the CCN URI ccnx://test/1.

The request in the form of an Interest message is sent to the local daemon instance running on the same node. The Interest is then added to the local PIT. A look-up is then performed on the FIB which returns a match for the prefix ccnx://test on a face that connects to R. When the Interest message reaches R, it is added to the PIT. The FIB is then searched for the prefix which returns a face connected to N₁. As a result, the Interest message is

(31)

then forwarded to N₁ where it is also added to the PIT. The prefix matches data which is locally served by the node, which is consequently retrieved from the application and sent back over the network. The data first arrives at R where it is cached in its Content Store. The PIT entry for that Interest is removed as it has been satisfied and the data is relayed back to N₂.

This process is very similar to scenario 1a when there are no disconnections or interruptions between two nodes. The only exception is the additional relaying operation that is performed by R. The introduction of an additional node results in a slightly longer retrieval time than in scenario 1a which can be attributed to the additional network hop required through the relay node.

Scenario 2b: Link disruption before request is sent

This scenario involves testing Interest re-transmission by the receiving node (N₂). The link between R and N₁is down at the beginning of the experiment.

This link is restored after four seconds. It is expected that more than one Interest will be sent before the request is satisfied.

Figure 4.7 Experiment (2b) Link between N₁ and R is down before Interest reaches R

(32)

Based on a number of 10 runs, the scenario shows that two interests are required to successfully complete the request. The following information shows the total time for the requested data to be successfully received by N₂:

Minimum=8018, Maximum=8021, Average=8019.8 (milliseconds) In addition, the following measurements identify the response time for the (second) successful Interest:

The total time it takes for Interest to be fulfilled is much longer than scenario 2a due to the first Interest being lost. This is similar to what was observed in scenario 1b. On the other hand, the time it takes to satisfy the second Interest is largely unchanged from scenario 2a.

Analysis:

This is similar to the scenario described in scenario 2a with the exception of the connection between R and N₁ being unavailable at the start of the run. As shown in figure 4.7, the Interest sent from the application on N2

reaches R, but cannot be relayed to N₁ because the link is down. After the lifetime of the Interest expires, the PIT entries expire on both nodes and the Interest message is discarded. No Interests reach N1 up to this point.

After the Interest retry interval (5 seconds) elapses, the application on N₂ re-sends the Interest which is then sent to R and this time relayed to N₁. N1 identifies the URI in the request and replies with the requested data. The data is first cached in the Content Store on R, then once it arrives at N₂ is also cached and forwarded back to the application.

The total time required to fulfill the request is noticeably longer than scenario 2a due to the need for the second Interest to be sent. This involves the time required for the Interest to expire, the application wait time, the time for the second Interest to be sent, and finally the time required for the response to be relayed back. The time for the successful Interest to be fulfilled is similar to scenario 2a. This is expected as after the first Interest message expires, the entire process must be repeated without knowledge of the prior attempt.

Scenario 2c: Link disruption after request is sent

This scenario also involves testing Interest re-transmission by the receiving node N₂. However, in this case, the link between N₂ and R is down immediately after the Interest is sent from N₂. The link between N₁ and R is

(33)

operational throughout the experiment. It is expected that more than one Interest will need to be sent before the request is satisfied. Figure 4.8 shows connectivity between the nodes throughout the timeline of the experiment.

Figure 4.8 Link between N₂ and R is down just after Interest reaches R

Observations:

Based on a number of five runs, the results show that two Interests are required for the request to be satisfied. The following measurements show the total time for the request data to be successfully received by N2:

Minimum=8007, Maximum=8010, Average=8008.5 (milliseconds) In addition, the following times identify the response time for the (second) successful Interest:

The results demonstrate that the total time required to fulfill the request is higher than the one observed in scenario 2a. This is directly correlated to the fact that two Interests are required to satisfy the request. On the other hand, the retrieval times for the successful Interest are noticeably lower than scenarios 2a and 2b.

(34)

This scenario is similar to scenario 2b, except that it forces Interest re- transmission at a different point of time in the experiment. As opposed to N₁ not receiving the first Interest message in scenario 2b, the first Interest reaches N₁through R. However, immediately after the Interest leaves N₂, the connection between N₂ and R is lost.

Because the Interest reaches R, it is added to its PIT and based on the FIB forwarded to N₁. N₁ then sends the data back to R, which attempts to send the data back to N₂ but fails due to the link being down. The PIT entry expires on all three nodes, but the Content Object remains cached in the Content Store of both R and N₁.

After the Interest retry interval (5 seconds) elapses, N₂ will send another Interest. When this message reaches R, the URI is looked up in the Content Store. Since the corresponding Content Object is still cached, a response is directly sent back to N₂. N₁ plays no role in satisfying the second Interest message.

The total time to satisfy the request is slightly shorter than scenario 2b due to the fact that the second Interest does not need to propagate to N₁. Additionally, the response time for the second successful Interest message is noticeably shorter as well confirming that data is being retrieved from the relay node’s Content Store rather than being forwarded on the network, essentially requiring one less network hop to fulfill the request.

Conclusion

Similar to the observations from experiment 1, we confirm that the application is responsible to ensure that Interests are re-transmitted as required to fulfill requests. The behavior of the relay node confirms that CCNx does not interfere with Interest re-transmission in this particular setup. It also highlights the advantages of caching Content Objects in the local Content Store which is an important advantage in a Delay/Disruption-Tolerant environment. Additionally, the experiments show that the introduction of a relay node did not negatively impact performance by a large margin.

It should be noted that in a network with more relay nodes, we would expect the performance would be similar since re- transmitted Interests would be satisfied by the closest node on the network. In a Delay/Disruption- Tolerant setting, it would be beneficial to have Interests re-transmitted at shorter Intervals without explicit requests from the application. This would ensure that there is a larger window of opportunity around link outages for the data to be retrieved as well as a greater chance of requested data being cached on more nodes in the network resulting in faster retrieval times overall.

It should be noted that the re-transmission intervals will need to be tuned to

(35)

suit the environment. If the links between the nodes are regularly down for long periods of time, it is more practical to prolong the interval as opposed to re-transmitting Interests that are guaranteed to be lost.

(36)

4.4 DTNx: Enhanced Re-transmission

From experiments 1 and 2, it was concluded that it would be beneficial to have re-transmit Interests at shorter intervals without the knowledge of the application. To test this, a separate application, DTNx, was added to each relay node. The application listens for Interests on the network and continuously re-transmits them until a corresponding Content Object is received.

This mechanism forces the CCNx daemon on each node to keep Interests alive in the PIT and increases the probability of both Interest messages and Content Objects being transferred over the network independently of the application sending the original Interest. This allows for data retrieval without end-to-end connectivity between the sender and receiver at any one point in time. It also forces nodes to cache Content Objects along the path the Interests are sent. DTNx does not manipulate or consume the response data.

To test the effect of DTNx, two additional experiments were performed.

Experiment 3 compares the impact on communication between two nodes, while experiment 4 incorporates three nodes. Each experiment includes two scenarios which are identical except for the inclusion of DTNx in the second. In both experiments, three Interests are sent by the application, once per minute. The status of links between the nodes changes throughout the timeline of the experiment. In scenarios where DTNx is introduced, it will re-transmit all unsatisfied Interests every five seconds. Re-transmission of a particular Interest stops when the corresponding Content Object is received.

A timeout value of three minutes is chosen² to avoid endless re-transmission.

In a real-life application, the Interest re-transmission interval and the re- transmission timeout value would be dependent on network properties such as connectivity patterns and the cost Interest transmission.

One implementation note that should be mentioned is that although CCNx has a built-in re-transmission feature, this was disabled in the same way it was for experiments 1 and 2. This allows us to observe the effects of introducing DTNx without additional CCNx generated Interests influencing the results.

Observations for experiments 3 and 4 will mainly focus on the effects of DTNx rather than delve into re-transmission details already described for experiments 1 and 2.

2A three minute timeout was chosen as it exceeds the time frame of the experiment.

(37)

4.4.1 Experiment 3: Network with two nodes and one link

This experiment is similar to experiment 1 with the additional introduction of the DTNx application. The objective is to study the effect of DTNx on Inter- est re-transmission and performance of the 2-node network. The experiment is split into two scenarios that are based on the same Haggle testbed trace file that specifies when link disruptions will occur. The first scenario uses an un- modified CCNx environment. The second scenario introduces DTNx to the nodes. N₂ is the receiving node requesting information and N₁ is the sender publishing data. The prime symbol (^’) indicates that DTNx is running on the node. Figure 4.9 illustrates the topology of the network for Experiment 3.

Figure 4.9 Experiment 3 Network Topology The parameters used for this experiment are:

• Application retry interval: 60 seconds

• DTNx retry interval: 5 seconds

Scenario 3a: Default CCNx behavior

This scenario is similar to scenario 1a except for a longer intervals between Interests sent by the application requesting data. The connection between the node is lost directly after an Interest is transmitted by N₂. The connection is re-established towards the end of the experiment timeline. Because there is no direct connectivity between both nodes until the end of the experiment, it is expected that a response will not be received until then.

(38)

Figure 4.10 Re-transmission of Interests generated by N₂

Observations:

Based on a number of 10 runs, the results show that three Interests are required for the request to be satisfied. Figure 4.10 maps the Interests sent with the connectivity between the nodes throughout the timeline of the experiment. The following measurements show the total time for the request data to be successfully received by N₂:

Minimum=126006, Maximum=126036, Average=126014 (milliseconds) In addition, the following times identify the response time for the (third) successful Interest:

Analysis:

The first Interest from N₂ reaches N₁ before the link is dropped. The request is fulfilled by the application on N₁ and cached in its local Content Store, however, the Content Object is not received by N₂. When the three second request timeout elapses, the application waits for 60 seconds before

(39)

sending a second request. At that point in time, the link is still down and the Interest is lost. After a further retry interval, a third Interest is sent and the link is up between both nodes. Once received by N₁, the Interest is satisfied directly from the Content Store without intervention from the application. The Content Object is sent back to N₂, where it is cached in the local Content Store and relayed to the application.

Scenario 3b: CCNx with DTNx on all nodes

This scenario introduces DTNx on both nodes under the same network conditions as scenario 3a. Because the DTNx application on N₂^’ re-transmits at a much shorter interval than the application, it is expected that data will be retrieved earlier.

Figure 4.11 Re-transmission of Interests generated by N₂^’ with DTNx

Observations:

Based on a number of 10 runs, the results show that two Interests are required for the request to be satisfied. Figure 4.11 illustrates the points in time when Interests are sent related to node connectivity as well as the additional DTNx Interests that are generated. The following measurements show the total time for the request data to be successfully received by N₂^’:

(40)

The amount of time to receive a response is nearly half the time required for scenario 3a. Additionally, the amount of time for the successful interest is also noticeably lower.

Analysis:

Similar to the first scenario, the first Interest from N₂^’ reaches N₁^’ and is cached locally. Between the first and second Interest sent by N₂^’, the DTNx instance on N2’ is continuously sending additional Interests every five seconds. This results in the data being retrieved from N₁^’ and cached locally on N₂^’ without the application being aware of it. When the second Interest is sent by the application, it can be retrieved directly from the local Content Store on N₂^’. This scenario requires ones less Interest to be sent by N₂^’ than in scenario 3a because by the time the application sends a second Interest, the data is already locally cached and can be retrieved without relying on the network connection being available.

4.4.2 Experiment 4: Network with three nodes and two links

This experiment is similar to experiment 3 except for the addition for a third node which acts as a CCNx relay node, N_R, between the sender, N₁, and receiver, N₂ nodes. The timeline of the experiment is also slightly modified to accommodate the additional link. While scenario 4a tests normal CCNx behavior, scenario 4b adds DTNx to each of the nodes on the network to gauge its effect. The prime symbol (^’) indicates that DTNx is running on the node. Both scenarios 4a and 4b use the same Haggle testbed trace file that dictates link disruptions. Figure 4.12 illustrates the network topology for experiment 4.

The parameters used for this experiment are identical to the ones used in experiment 3.

(41)

Scenario 4a: Default CCNx behavior

This scenario tests CCNx behavior in a network with three nodes, one being a relay node. The connection between N2 and R is referred to as Link 1, while the one between N₁ and R is referred to as Link 2. Figure 4.13 shows the connectivity between nodes throughout the experiment as well as when Interests generated by N2 are sent.

Figure 4.13 Re-transmission of Interests generated by N₂

Observations:

Based on a number of 10 runs, the results show that three Interests are required for the request to be satisfied. The following measurements show the total time for the request data to be successfully received by N₂:

Minimum=126015, Maximum=126022, Average=126018 (milliseconds) In addition, the following times identify the response time for the (third) successful Interest:

(42)

The first Interest is sent from N₂ to R. Because Link 2 is down, the Interest does not propagate to N₁. When the second Interest is sent, Link 1 is again up, but Link 2 is down, which means this Interest can reaches R, but not N₁. When the third Interest is sent by N₂, both links are up and the data can be retrieved successfully through R. In this case, the data is only cached locally on each node after the third request is sent. In this scenario, there is a basic end-to-end connectivity requirement between the nodes for the data to be retrieved.

Scenario 4b: CCNx with DTNx on all nodes

This scenario is identical to scenario 4a except for the fact that DTNx is running on all nodes. The connection between N₂^’ and R^’ is referred to as Link 1, while the one between N₁^’ and R^’ is referred to as Link 2. Figure 4.14 shows the connectivity between the nodes throughout the experiment as well as the instances where Interests are sent.

Figure 4.14 Re-transmission of Interests generated by N₂^’ with DTNx

Observations:

Based on a number of 10 runs, the results show that two Interests are required for the request to be satisfied. The following measurements show the total time for the request data to be successfully received by N₂^’:

(43)

Minimum=63002, Maximum=63003, Average=63002.4 (milliseconds) In addition, the following times identify the response time for the (second) successful Interest:

Mirroring the results in experiment 3, scenario 4b shows a noticeably quicker response time for the data as well as the satisfaction time for the successful Interest.

Analysis:

The first Interest is sent from N₂^’ and reaches R^’. Because Link 2 is down, the Interest does not propagate to N1’. When the second Interest is sent, Link 1 is again up, but Link 2 is down, which means this Interest also reaches R^’, but not N₁^’. When the third Interest is sent by N₂^’, both links are up and the data can be retrieved successfully. In this case, the data is only cached locally on each node after the third request is sent.

In this scenario, the data was retrieved with one less Interest than scenario 4a and much faster, since it is cached locally. Despite there being no direct route between N₂^’ and N₁^’ when the first 2 Interests are sent by the application, it is still possible to retrieve the data through R^’ because the increase in frequency of DTNx re-transmission requests results in a higher probability for the window in which a link between 2 of the nodes is up can be taken advantage of.

4.4.3 Conclusion

Experiments 3 and 4 tested the effects of running DTNx on all nodes and the results show that it has proved beneficial. DTNx builds upon fundamental CCN architecture principles to achieve two main goals. Firstly, by re-transmitting more Interests at shorter intervals, more windows of opportunity for end-to-end communication between nodes are created. Secondly, the increase in re-transmission allows nodes to cache Content Objects which in turn enables data retrieval without end-to-end connectivity. In some instances, applications were able to retrieve data from local cache even though the nodes were completely isolated from the network. In scenarios 3b and 4b, there was one less Interest required to retrieve the data compared to scenarios that did not utilize DTNx.

Although the experiments present a simplified view of connectivity in a controlled environment, they provide valuable insight into factors that have

(44)

an impact on the introduction of DTNx to the nodes. The number of relay nodes and the re-transmission rate are key variables that could be further investigated to find optimal values best suited for a particular environment.

Further experimentation is necessary to identify how those variables would impact larger scale networks. Finally, we believe it would be beneficial to implement re-transmission control mechanisms within the CCNx implemen- tations itself to observe how much of an impact it would have without the overhead of the DTNx layer.

(45)

Chapter 5 A real application:

Delay/Disruption Tolerant Game Platform (DTGP)

To complement the basic simulations run that test CCNx behavior in a Chal- lenged Network setting, an implementation of Tic-Tac-Toe was developed to evaluate its behavior and performance in a real application. Tic-Tac-Toe is a two player turn-based game in which players place a mark (normally either X or O) on a 3x3 grid in an attempt to complete three of the same mark symbol in a row. The main requirements for designing such a game was that it must conform with the CCNx Interest-driven model and satisfy both conditions of location independence and disruption tolerance. A framework, referred to as Delay/Disruption-Tolerant Game Platform (DTGP), was developed to take advantage of CCNx characteristics, particularly in relation to delay and disruption tolerance.

In section 5.1, the design of the DTGP framework is introduced with an in-depth discussion of bootstrapping, addressing, and game state handling.

Section 5.2 introduces a number of alternative designs for various aspects of the framework with justification as to why they were not chosen.

Chapter 6 describes experimentation conducted to evaluate the framework by running the Tic-Tac-Toe implementation on the Haggle testbed.

Interest re-transmission behavior and efficiency is determined by analyzing the number of Interests required per game and the Interest satisfaction ratio.

The performance is also studied by measuring the satisfaction time for each Interest traversing the network.

(46)

5.1 Framework Design

To implement a CCNx version of Tic-Tac-Toe, we developed a framework to utilize CCNx and potentially be adapted for other similar turn-based games. The framework, named DTGP, relies on two main generalization APIs. Firstly, the network API which is designed around two basic operations: get and put. These simple operations abstract the underlying network architecture while maintaining the basic principles of an ICN. Secondly, the application API which abstracts dependencies between the game and the network layer to basic functionality such as initialization, running, and ter- minating. It is up to the game to implement each of these functions by applying the game logic in conjunction with the network API.

The result is a game that runs on top of CCNx without requiring much understanding from the developer about the details of an ICN, yet can still function in a Challenged Network setting. It should also be noted that while the network API used may also theoretically be used with a TCP/IP network, this has not been tested. An interest message is sent over the network through the get method presented by the framework, while a response or Content Object is delivered using the put method.

In the simple scenario of a game of Tic-Tac-Toe, there are two players: A and B which have no prior knowledge of each other except for being on the CCNx network at some point in space and time. There are also two distinct types of nodes:

1. Host nodes that listen for new game requests 2. Initiator nodes that send new game requests

A is a Host node that starts running the game first. A initializes a new game object and continuously listens for Interest messages from nodes interested in playing a new game. Player B, an Initiator node, then runs the game and sends Interest messages that request a new game with a unique game ID. The uniqueness of the game ID is crucial due to the nature of the CCN. This is discussed in some more detail in section 5.1.1. When the Interests from B reach A, A creates a new game object and sends it back as a Content Object (CO) to B. When B receives the CO, the Interest for the new game is satisfied and the game can begin.

(47)

Figure 5.1 Illustration of message exchange in a typical game of Tic-Tac-Toe For simplicity, we assume that Host nodes always play the first move.

Figure 5.1 illustrates the message exchange between two nodes in a typical game of Tic-Tac-Toe. After B receives the game CO, a new request is sent for move #1. Player A receives the Interest message and sends the response back followed by a new Interest for move #2. Player B receives the CO,

An Investigation into the Application of Content-Centric Networking within Challenged Network Environments using CCNx

Examensarbete 45 hp Juni 2014

An Investigation into the Application of

Content-Centric Networking within Challenged Network Environments using CCNx

Tarek Elshaarani

Institutionen för informationsteknologi

Abstract

An Investigation into the application of

Content-Centric Networking within Challenged Network Environments using CCNx

Acknowledgments

Contents

Chapter 1 Introduction

1.1 Challenged Networks

1.2 Information-Centric Networking

1.2.1 Named Data Networking

Chapter 2

Problem Definition and Thesis Contributions

Chapter 3

A Brief Introduction to CCNx

Chapter 4

Evaluating NDN Performance in a Challenged Network

4.1 Haggle Testbed

4.2 Notes on Data Collection

4.3 CCNx Interest Re-transmission Behavior

4.3.1 Experiment 1: Network with two nodes and one link

4.3.2 Experiment 2: Network with three nodes and two links

4.4 DTNx: Enhanced Re-transmission

4.4.1 Experiment 3: Network with two nodes and one link

4.4.2 Experiment 4: Network with three nodes and two links

4.4.3 Conclusion

Chapter 5

A real application:

Delay/Disruption Tolerant Game Platform (DTGP)

5.1 Framework Design