Keywords

1 Introduction

In today’s Internet there are multiple users and servers located around the world. Internet applications have advanced from simple end-to-end communication applications to online-games, peer-to-peer file sharing applications, and video streaming services among others. The Internet was built on the host-centric paradigm, which states that end-to-end connectivity between hosts is a prerequisite for effective communication. However, most of the traffic in today’s Internet is related to content distribution applications [1, 2], which include file sharing; audio/video streaming; groupware instant messaging (akin to Twitter) and status notification; and collaboration applications. For handling content traffic, new kinds of technologies have been developed. Peer-to-peer networks have proven to be efficient in file sharing by making the information available to a large number of users. Content distribution networks (CDNs) are useful in pulling the load away from a central server by distributing information to servers located close to the users. However, these technologies are still based on end-to-end connectivity, tying the content to specific hosts. The inability of the current Internet architecture calls for a transition to information-centric networking. Network of Information (NetInf) is an information-centric approach taken within the EU-funded FP7 4WARD project [3]. NetInf proposes a uniform mechanism for locating and retrieving content, which is more suitable to the usage of the current Internet. Currently, relationships between different copies of the same content are not represented. NetInf aims at employing access patterns similar to anycasting to obtain the closest replica of the content in a networking sense. It has been considered as a viable architecture for mobile networking, since it may reduce energy consumption of mobile devices and provide ubiquitous Internet access [4]. Research on information-centric networking is active, and in addition NetInf there are other proposals, such as PSIRP [5] and Content Centric Networking [2].

Information-centric networking allows users to focus on the information objects they need, rather than pointing to a specific, physical location of the data. Instead of connecting nodes and their processes, information-centric networking aims at connecting information consumers with information producers and distributors. The networking paradigm called NetInf [6] adopts this approach. Currently, the IP address is both an identifier and a locator. It expresses where the content is located and the name of the location. Thus, when content is moved to a different location its name also changes. The dual role of an identifier and locator should be excluded by using a flat namespace for persistent identification of content [7]. The content should be retrievable by a common known name even if it moves to another location. Flat namespace means that there is no hierarchy in the naming of content.

The NetInf information model has two objects: the bit-level object (BO) and the information object (IO) [7]. BO is a digital representation of the information: a specific sequence of bits located in a file, on the wire, in the air, or any other possible location. BOs can be divided into smaller pieces, to support features such as swarming in BitTorrent. An IO is a general term for a piece of content or information [6, 8]. By using IOs it is possible to locate content, regardless of irrelevant characteristics, such as, encoding of a certain song. In an information-centric network the same IO can reside in multiple copies at different locations [7]. The principle of object resolution in NetInf is that objects are retrieved based on their unique identifiers. To find an object in the network, users query a NetInf name resolution system. Routing forwards the object retrieval query to the storage location of the object, where it can be forwarded to the requesting client.

This paper describes an information-centric multiaccess supported NetInf simulation model with the OMNeT++ discrete event network simulator [9] and analyzes the simulation results. This paper builds upon, and extends our previous work on a proof-of-concept prototype for multiaccess NetInf [10]. In particular, this paper centers on feasibility on a larger scale and quantifies in this context the individual NetInf node performance improvement. In earlier work we showed that with an information-centric approach, it is possible to make significant gains in performance [11]. The scenario involved multiaccess content distribution for the case of video streaming in a large wireless metropolitan area network (WMAN). It was also shown that an information-centric approach may be instrumental in reducing the energy use of WMANs and information and communication technology (ICT) in general [12].

This paper presents the first simulation study on a multiaccess supported information-centric approach in a wireless peer-to-peer network. Reducing inter-domain traffic and improving download speeds of end users in peer-to-peer networks has been studied before. BitTorrent Ono [13] uses biased neighbour selection to find peers that are close in a networking sense. An ISP-supported oracle has been suggested in [14, 15]. However, these solutions are still based on end-to-end connectivity, i.e., the content is located at specific hosts in the network. In addition to peer-to-peer file sharing, information-centric networking is naturally suitable for content distribution scenarios such as A/V streaming. Downloading the closest possible replica can minimize the amount of inter-domain traffic and speed up streaming video.

This paper is structured as follows. Section 2 describes our methodology and details the simulation environment. Section 3 presents evaluation results and Sect. 4 concludes the paper and lists items for future work.

2 Simulation Scenario

The performance gains of a multiaccess supported information-centric approach are evaluated with a simulation model, which was implemented in the OMNeT++ discrete event simulator v.3.3p1, INET Framework [16] v.20061020, and OverSim [17] v.20080919. We enhance the BitTorrent module described in [18] to support our information-centric approach. The net-work topology includes several network domains or subnets. Each domain contains a seeder, a tracker, and a certain number of wireless access points. Figure 22.1 shows the simulation scenario, illustrating only a fragment of the network topology due to space constraints. The tracker inside the domain is called a subtracker (a normal BitTorrent tracker). A separate subnet called the Core Network holds a core NetInf tracker. As an approximation, the core NetInf tracker acts as a global NetInf name resolution point and the subtrackers are local NetInf name resolution points.

Fig. 22.1
figure 1

Simulation scenarios: topology (fragment)

The simulation area is a residential area of 0.675 km2 (900 × 750 m), consisting of 30 wireless access points, an access router, three backbone routers, ten gateway routers, ten sub trackers, a core tracker, a fixed number of downloaders and ten seeders. The network consists of ten domains and each domain has three wireless access points. A gateway router is located at the edge of a domain and it is used for connecting the domain to a backbone router. Multiaccess nodes are placed in two adjacent wireless access points located in different domains. The simulation experiments also include single access nodes, which are placed in a random wireless access point. In Fig. 22.1 a multiaccess node is connected to two networks and holds two IP addresses. To support information exchange between the trackers, a signaling protocol was developed and evaluated with a proof-of-concept prototype [10]. The protocol was implemented in a testbed as an extension of the signaling protocol used in standard BitTorrent communication. In this paper, we focus on the most relevant elements as shown in Fig. 22.2. In a crude approximation, IOs can be mapped to the equivalent of the torrent file and the tracker’s response in BitTorrent and BOs correspond to the content distributed by the swarm.

Fig. 22.2
figure 2

Signaling and information exchange schema

Once a NetInf node joins the network, it tries to get associated to a WLAN access point and establish a TCP connection with the core tracker. Multiaccess nodes form a connection with the core tracker via both interfaces. The core tracker implements part of the functionalities of an IO resolution server, which is used to map IOs to a BO or to other IOs. Upon connection establishment, the tracker request message is sent. The core tracker responds with a tracker response containing a corresponding IO. This IO points to the respective IO resolution server in the network domain of the NetInf node. For a multiaccess NetInf node, the resolution can occur simultaneously in two different domains. A BO is the actual sequence of bits of a file and for the BO resolution the node can contact either of the local resolution servers. For a BitTorrent-like NetInf operation, the BO resolution corresponds to pointing to the seeders (and leechers when appropriate) of the swarm. In the last step, the NetInf node establishes connections with the NetInf nodes and uses the standard BitTorrent protocol to obtain the BO. This approach aims at retrieving the content from the closest peer possible, making sure of using local resources first and avoiding cross-domain traffic.

The metrics of interest for our evaluation are the download duration of a file, the amount of packets received by the routers and the average download and upload throughputs. The amount of received packets in routers is used for quantifying the traffic flows in the network: how much traffic is maintained inside the network domains and how much traffic travels out-side. Our simulation parameters are given in Table 22.1.

Table 22.1 Simulation parameters

3 Results

The simulation experiments include conducting ten independent runs with an active user population of 40 and the following three configurations: single access (SA) NetInf, multiaccess (MA) NetInf, and standard BitTorrent. With single access NetInf all nodes have one WLAN interface and with multiaccess NetInf two WLAN interfaces. The last configuration includes the normal topology-unaware overlay BitTorrent net-work. In this scenario, there are no subtrackers; the peers con-tact a single tracker in the network for finding other peers.

Table 22.2 shows the average number of received packets by all backbone routers for ten simulation runs. It shows that both multiaccess and single access NetInf can drastically reduce the traffic load on the backbone routers. With standard BitTorrent the amount of packets received by the backbone routers rises up to over 8 million, while with multiaccess and single access NetInf the amount is approximately 160 000, which indicates a 98 % reduction. The reason for this is that NetInf maintains the traffic inside the network domains and only sends packets to the core network domain to reach the core tracker. Standard BitTorrent is a network topology unaware overlay protocol. Connections are formed with all peers available and packets are sent to multiple different domains in the network. Table 22.2 shows that an information-centric approach can also reduce the packets received by the gateway routers. With standard BitTorrent the received packets rise up to nearly ten million and with NetInf the amount is well below four million. The total reduction in received packets is 62 % for multiaccess NetInf and 66 % for single access NetInf. The reason is the topology unawareness of BitTorrent. Once a BitTorrent node completes the download of a piece, it sends HAVE messages to all connected peers, which increases the number of received packets at the gateway routers. In an information-centric approach the HAVE messages are sent only to nodes inside the domain.

Table 22.2 Average number of received packets

4 Conclusion and Future Work

To sum up, the information-centric approach is an efficient solution for content distribution applications and the results have created incentives for future work in this area. Further work must be done to explore larger network configurations, support mobility, and evaluate energy efficiency aspects.