An architecture for P2P locality in managednetworks using hierarchical trackers

Charles Miers, Marcos Simplicio,Walter Goya, Tereza Carvalho

Escola Politécnica, University of São PauloSão Paulo, SP, Brazil

{cmiers,mjunior,wgoya,carvalho}@larc.usp.br

Victor SouzaEricsson Research, Packet Technologies

CDNs and Cloud ComputingKista, Sweden

victor.souza@ericsson.com

Abstract—Peer-to-peer (P2P) networks have in the past yearsbecome a very attractive method for delivery of media contentover the Internet. Many factors have contributed to this success,but the low delivery costs and the inherent scalability of theP2P networks whereby consumers of content are also potentialsources are among the most prominent ones. However, theeffectiveness and performance of many popular P2P networks(such as BitTorrent based ones) is highly dependent on how welltrackers select peers that will provide a content. The peers chosenby a tracker will directly affect the user-perceived performanceof the service and the usage of network resources. Moreover,P2P networks have usually no locality awareness, resulting insub-optimal utilization of network resources. In order to addressthese issues, we propose a novel hierarchical architecture forP2P locality targeted at managed P2P networks based on theBitTorrent protocol. We then show, through experimentation,that the adoption of the proposed architecture leads to significantnetwork efficiency improvements without compromising end-userexperience.

I. INTRODUCTION

The application of peer-to-peer (P2P) technologies are veryquickly evolving from illegal file transferring to legally autho-rized delivery of media content over the Internet [1], [2]. Thissuccess is due in part to the scalability of peer-to-peer systems,and also to reduced delivery costs for the source of content.In reality, this technology allows the costs to be shifted fromthe content distributor to the users and network operators:the users share part of their uplink, hard disk and processingcapacities for the benefit of the peer-to-peer community; atthe same time, network operators involuntarily end up payingmore transit fees, since peer-to-peer protocols have no networkawareness. In extreme cases, upgrade of the network maybecome necessary.

It is a fact, though, that many network operators haveunderstood the advantages of peer-to-peer systems and are alsotrying to utilize them in the best way [3], [4], [5]. A goodexample of this trend is the development of hybrid contentdelivery networks [6], [7] that combine the stability of a serverorganization based on surrogate servers with abundant peer re-sources. The intrinsic scalable nature of peer-to-peer systems,whereby consumers are also sources of a content, implies thatscale is usually not a problem as long as the balance of peers’input resources minus peers’ requested resources is positive.Nonetheless, the lack of network locality awareness persists.

Additionally, guaranteeing the user experience, which forstreaming services translates to the assurance of a minimumdownload rate, remains a challenging issue.

In a BitTorrent system, one or more servers known astrackers coordinate the establishment of the initial P2P com-munications between peers [8]. A tracker essentially managesa content swarm, which aggregates information about peers in-terested in some content. More specifically, BitTorrent clientsconnect to a tracker specified in a torrent file, and then receivea list of peers that are downloading and/or uploading therequested content; the client will then join the swarm, exchang-ing content chunk bitmaps with other peers and downloadingthe corresponding content chunks [9]. Multiple trackers for thesame content are allowed, but each tracker manages one swarmof that content [10]; therefore, in order to take advantage ofmultiple trackers, a BitTorrent client must join each one ofthese swarms. By default, the list provided by a BitTorrenttracker contains 50 randomly selected peers that are potentialsources of a content. When downloading content, the re-questing node will establish simultaneous connections to fourof those peers, chosen through standard BitTorrent policieswhose main goal is to promote content sharing (e.g., optimistunchoking and rarest first [10]). Although this approach givesthe peers a reasonable degree of freedom when choosing thepeers to establish connections with, it is important to notethat the list of peers initially obtained from the tracker isof major importance, since it determines the peers that canactually be selected in this manner. Therefore, the trackerperforms a role of main importance in the BitTorrent model.This motivates the development of enhanced peer selectionmechanisms providing a better use of network resources thanthe original BitTorrent protocol and allowing the enforcementof business rules.

This paper addresses these issues by presenting a novelarchitecture for locality in managed P2P networks (in whichthe connections among the network elements are planned andthese elements can be controlled by a management system)based on the BitTorrent protocol. In such networks, theP2P system has direct access to the network elements (e.g.,routers), and can thus obtain network information in a reliableand swift manner via resource management protocols (e.g.,Simple Network Management Protocol version 2 – SNMPv2);

206978-1-4244-8909-1/$26.00 c©2010 IEEE

This paper was peer reviewed at the direction of IEEE Communications Society by subject matter experts for publication in the CNSM 2010

proceedings.

since the network operator has more knowledge and con-trol over the network, the P2P mechanisms can run moreefficiently than in a standard BitTorrent implementation. Wetake advantage of this information and develop a hierarchicaltracker organization which, according to the results obtainedwith our prototype testbed, provides superior performancewhen compared to standard P2P techniques. The remainderof this document is organized as follows. Section II identifiessome significant issues with regular BitTorrent protocols, withspecial focus on the usage of the network resources when theyare deployed in managed networks. Section III addresses theproblems presented in the previous section, introducing thereasoning behind the design of our proposal. The proposedsolution is detailed in section IV, which also provides someusage examples. We then present, in section V, the resultsobtained when applying the proposed scheme to the hybridtimeshift TV prototype described in [4]. Section VI presentsour final considerations and discusses future work.

II. PROBLEM DEFINITION AND RELATED WORK

One of the most well-known problems with the BitTorrentarchitecture is the lack of locality awareness [11]: a peer whojoins a swarm will receive a list of peers that is randomlyselected by the tracker [3], [12], and may thus downloadcontent from peers that are very distant network-wise, evenif many peers nearby already have that same content.

A possible solution for this issue is to employ databasesof IP geo-location to create locality awareness [13]. Thisapproach is not very accurate, though, since these databasescontain errors and, even more importantly, geographical dis-tance does not necessarily imply network distance. Moreover,the usage of the network resources is not taken into accountin the peer selection process. Since the peers choose otherpeers from this (randomly generated) list provided by thetracker by means of standard BitTorrent policies, and thoseaim basically to motivate content sharing and to maintainthe content available in the swarm, network resources areoften sub-optimally utilized [12], [14]. Finally, given that theBitTorrent tracker does not know which peers contain eachpart of the content in the swarm, the peer lists returned canalso include peers having none of the desired parts [9]. Theeffort wasted when communicating with such unusable peerscould considerably affect the quality of the P2P-based service.

The work being standardize in IETF [15] and influenced by[16] tries to solve the locality question by utilizing a “savvy”tracker that has more knowledge about the network topologyand about the peers. Nonetheless, without the solution hereinproposed for data aggregation, those approaches are likely tomeet serious scalability problems.

Due to such problems, we claim that the above trackermodel for delivery of P2P content is far from ideal when oneconsiders managed operator networks, in which the operatordoes have a lot of information about the network topology andcurrent network load on links. Hence, in scenarios involvingthe delivery of Video on Demand (VoD) via P2P, where the op-erator must ensure a given download rate (and, consequently,

the playback continuity), the simple deployment of existingtracker techniques is presumably not a suitable approach.

III. PROPOSED SOLUTION

A simple approach for addressing the problem presented insection II is to create an enhanced tracker, which employs threedifferent inputs when compiling its peer lists: network usageinformation (e.g., available link bandwidth), network topologyand content availability on peers. This information can be usedto create a weighted graph reflecting the network topology andstatus, as well as operator/business policies and other relevantconstraints; therefore, the list of peers returned by the trackersupon a peer’s request will not be random, but instead the resultof an informed calculation. However, as the size of the networkgrows, the number of contents to be managed and of peersparticipating in a swarm would result in an enormous overheadon such enhanced tracker. Therefore, despite the advantages ofthis approach, such a tracker would very quickly suffer fromscalability issues.

In order to create a solution combining scalability and thecreation of optimized peer lists, we propose a distributedhierarchical tracker organization in which each tracker isresponsible for a portion of the network, and the informationis aggregated (condensed) upwards in this hierarchy. Themain differences between existing solutions and the proposedtracker are that the latter (1) builds a network topology map,(2) a content bit map for the peers and (3) employs updatedlink condition information obtained from routers. The resultis a design based on the BitTorrent architecture and protocols,but that takes into account existing research efforts concerningtraffic engineering [17] and network optimization [18], [19],allowing trackers to explore the network information whenselecting peers for any given purpose by defining the costcalculation formula, as further detailed.

A. Tracker domains

The core of the proposed architecture lies on the fact that wepartition the network in a static manner (domains) and thenmake each tracker responsible for a single region, creatingdifferent tracker domains. Figure 1 illustrates the concept,depicting a two-level hierarchic architecture.

Figure 1. Hierarchy of trackers

A peer always contacts the tracker that is responsible forits respective domain when joining a swarm. Whenever thedesired content is not available in the local tracker, the request

2010 International Conference on Network and Service Management – CNSM 2010 207

is forwarded to the next tracker in the hierarchy, until thecontent is found or deemed to be inexistent in the entirenetwork. Moreover, all peers notify their own tracker aboutthe content chunks they have available.

Each domain in this model is determined by the networkoperator, according to factors such as the number of peersto be served in that region of the network. The hierarchyscheme adopted, together with the appropriate specification ofthe graph weights, provides a powerful and straightforwardlocality mechanism: nearby peers will always be preferredsince searches are always first local but still providing sup-port to a structured search for peers in the entire network.Naturally, each tracker domain can be configured individuallyfor employing the locality criteria that best fits the domainnecessities, leading to a highly flexible solution that allowsan elevated degree of configurability for the most differentnetwork scenarios.

B. Data aggregation

In the proposed solution, the trackers are organized in ahierarchy where information is aggregated as one traversesthe tree of trackers. This is accomplished in the followingmanner. As previously stated, each tracker is responsible fora domain of the whole network, and the peers connected tosome region will only contact their respective tracker bothfor obtaining the list of peers of a swarm and to notify theavailability of content blocks. A tracker reports which content(and which parts) are available in the region it manages tothe tracker hierarchically above it. Whenever the status of thecontent changes, a new update message is sent upwards thehierarchy, thus allowing trackers closer to the Root Tracker toidentify all available content delivered over P2P in the lowerlevels of the hierarchy at any given moment.

The overhead resulting of the management effort on higher-level trackers is counterbalanced by the fact they deal onlywith other trackers, not with peers, thus improving thesystem’s scalability. At the same time, data aggregation isachieved since trackers up in the hierarchy only know thata given content chunk/block is available in a given domain. Inthis context, whenever a tracker cannot fulfill a request fromsome entity (either tracker or peer), it will send a message tothe next tracker upwards in the hierarchy. This process is thenrepeated until the request is answered, or the Root Trackerinforms that the content is not available in the whole network.

IV. IMPLEMENTATION OF THE SOLUTION

In order to evaluate the locality mechanism proposed twolevels of trackers will be assumed in the remainder of thispaper: leaf trackers (TrackerN) and a Root Tracker. It shouldbe noted though that more levels of hierarchy may be neededdepending on the size of the network to be managed.

A. Tracker implementation

In order to allow the tracker to calculate a list of peers basedon locality and costs, each tracker (including the Root Tracker)locally stores a weighted graph with the network topology

of its domain, in such a manner that: edges represent thenetwork links; nodes represent peers and network elements;and weights of the edges are computed by previously definedcriteria.

In the weighted graph, the distance between two peersindicates the cost for that connection. Therefore, if a requestingpeer can download the desired content from several otherpeers, the one with the lowest cost represents the best choicefor acquiring the data. Consequently, the criteria adopted tocompute the edge weight and the algorithm for determiningthe shortest path will define the quality of the peer selection,impacting on the usage of network resources. Since networklinks can be asymmetric, we use directed graphs to representthe downlink and uplink costs of a link. Figure 2 shows anexample of a direct graph of Tracker2 from Figure 1.

Figure 2. Tracker2 weighted graph for asymmetric network links

The edges represent the cost of a link and, as such, theyshould be calculated using up-to-date network usage infor-mation available to the tracker. Information that can be usedin this manner includes, but it is not limited to: total andcurrent link bandwidth, latency and packet loss. Alternatively,the network operator may decide to statically set the cost ofa link based on business rules.

In a general way, the network graph allows the networkadministrator to traffic engineer the peer-to-peer data transfersby using a tracker architecture that compiles peer lists torequesting peers according to current network load conditions.

Since each tracker is responsible for the peers belonging toa very well defined domain, the hierarchy provides inherentlocality: as discussed in section III, if the local tracker domaincontains suitable peers, those will always be preferred. In ourimplementation, the tracker was designed to return a peerlist containing the minimal number of peers necessary toobtain the content, according to the locality criteria definedby the operator. This approach avoids obtaining content fromdistant peers in the network. Moreover, the criteria have aconsiderable range of customization, allowing the networkowners to adjust the application behavior (and consequentlythe network traffic) according to their needs. Figure 3 showshow a tracker deals with peer requests and how locality isachieved.

208 2010 International Conference on Network and Service Management – CNSM 2010

Figure 3. Enabling locality in the hierarchy

Suppose a peer 𝑃𝑟𝑒𝑞 requests some content that is unavail-able in the domain of its own tracker, 𝑇𝑟𝑒𝑞. In this case,𝑇𝑟𝑒𝑞 will contact the Root Tracker trying to obtain a listof other trackers that have the requested content. The RootTracker verifies its table to identify suitable trackers. If thecontent is available in more than one tracker, the Root Trackeruses its graph to select the most appropriate tracker for thatspecific task, 𝑇𝑝𝑟𝑜𝑣 . Then 𝑇𝑟𝑒𝑞 communicates with 𝑇𝑝𝑟𝑜𝑣 inorder to obtain a list of peers that are temporarily added to𝑇𝑟𝑒𝑞’s own swarm/domain. When a peer in the domain of𝑇𝑟𝑒𝑞 has acquired the content, such external peers can finallybe removed from the swarm/domain of 𝑇𝑟𝑒𝑞.

B. Tracker hierarchy and data aggregation

The proposed tracker graphs are used to compute the bestroute between origin (requesting the content) and destination(have the content) peers. However, among all peers available,only a subset has the requested content chunk. Each tracker hasits own table (Content Table) containing the information of theon-line peers under its domain and the content of each peer.The Root Tracker also has a Content Table, that relates thecontent to trackers instead of peers. Thus, such peers must beidentified prior to the application of a shortest path algorithm.

Thereafter, the tracker verifies if the content is availablein a given peer in the following manner. In a first step, thetracker verifies its Content Table to identify if there are peerswith the requested content. If the ensemble of peers obtainedin this manner is enough to satisfy the peer’s request, thetracker returns this list of peers. Otherwise, in a second step,the tracker tries to locate the content available in the domainsof other trackers by communicating with the Root Tracker.

Both steps require the tracker or the Root Tracker to verifythe content availability under its own domain. This verification

consists in consulting the content ID (as in the BitTorrentprotocol) in a Content Table maintained by the tracker, whichis updated according to the information provided by the peersin that tracker’s domain. The fields required for implementingsuch a table are:

∙ Content ID: a unique identifier;∙ Peer ID: a unique identification of the peer;∙ Content blocks: a bit field containing all available blocks

in the peer.The utilization of this table is another important modi-

fication of the BitTorrent protocol proposed in this paper.The inclusion of an entry on the table happens whenever apeer joins a swarm on the Tracker. Thereafter, the registryinformation is updated based on the information providedby the peers by messages reporting its available content.Analogously, a registry line is deleted from the table whenthe tracker detects an active disconnection of the peer fromthe swarm or a connection time-out.

The Root Tracker Content Table is maintained by the RootTracker and updated according to the information provided bythe lower level trackers available under its domain. The RootTracker Content Table is composed of:

∙ Content ID: the same ID used on the peer;∙ Tracker ID: unique tracker identification on the operator

domain;∙ Content blocks: a bit field containing all available blocks

in the lower level tracker domain.When a tracker 𝑇 starts to manage a new content, a new

entry must be inserted into the Root Tracker Content Table.Furthermore, the update of an entry on 𝑇 ’s Content Tablemust produce an update on the Root Tracker Content Table.Hence, as soon as a peer finishes downloading a new block, 𝑇updates the table entry corresponding to that content and, if thedownloaded block is new in that domain, 𝑇 triggers the updateof the Root Tracker’s table. Finally, a Root Tracker registrywill only be deleted when the content is no longer availablein any of the trackers in the network. Figure 4 illustrates thedomains of the trackers and Root Tracker from Figure 1.

Figure 4. Root Tracker, Tracker and their domains

Tables I, II, and III exemplifies Content Tables of Tracker1,Tracker2, and Tracker3 respectively. Note that each tracker hasknowledge only about the chunks and blocks in its own do-main. Moreover, and unlike the original implementation of the

2010 International Conference on Network and Service Management – CNSM 2010 209

BitTorrent protocol, the entries in the Content Table indicatenot only the content, but also which blocks are possessed byeach peer. Whenever a registry is inserted, modified or deletedin their own tables, trackers send an update message to theRoot Tracker containing a compilation of the content blocksavailable under their domains. This compilation is computedby applying a logical OR operation on the Content Blocksfield of the registries with the same Content ID.

Table IEXAMPLE OF TRACKER CONTENT TABLE FROM TRACKER1 DOMAIN

Content ID Peer ID Content Blocks

100001 Peer1 0000111000100001 Peer2 1100011111100002 Peer1 1111100000

Table IIEXAMPLE OF TRACKER CONTENT TABLE FROM TRACKER2 DOMAIN

Content ID Peer ID Content Blocks

100001 Peer3 0000111100100001 Peer5 1111000000100002 Peer4 1111100000100003 Peer6 0001111000

Table IIIEXAMPLE OF TRACKER CONTENT TABLE FROM TRACKER3 DOMAIN

Content ID Peer ID Content Blocks

100001 Peer8 1111111111100002 Peer8 1111111111100003 Peer8 1111111111

Table IV shows the Root Tracker Content Table result-ing from the aggregation of the information received fromTracker1, Tracker2, and Tracker3. Note the Root Tracker hasno information about the peers whatsoever, as they are notnecessary for the functioning of the locality service at theRoot Tracker level. Therefore, the Root Tracker concentratesinformation about the content available in all trackers inthe operator domain, using the Content ID to index thisinformation.

Table IVEXAMPLE OF ROOT TRACKER CONTENT TABLE

Content ID Tracker ID Content Blocks

100001 Tracker1 1100111111

100001 Tracker2 1111111100

100001 Tracker3 1111111111

100002 Tracker1 1111100000

100002 Tracker2 1111100000

100002 Tracker3 1111111111

100003 Tracker2 0001111000

100003 Tracker3 1111111111

The adoption of Content Tables for leaf trackers and RootTracker allows the network operator to identify the contentdistribution in the entire operator domain. Therefore, when apeer requests a content block, the tracker can find all peersthat seed the desired content, whether these seeders are in thetracker’s own domain or not. The selection of peers is thencalculated by minimizes the result cost of the communication(e.g., using shortest path algorithm [20]).

V. EXPERIMENTATION

In order to evaluate the performance of the proposed solu-tion, we developed a prototype based on the IPTV (IP Tele-vision) system with hybrid distribution architecture (Multicastand P2P) described in [4]. We will present a short descriptionof this system only to provide the necessary information tounderstand our tests.

A. IPTV system

The main idea of this IPTV System is to take advantageof the live transmission to cache the content in a distributedway, avoiding retransmissions across the network when thesame content is requested as time-shift or VoD service. Oneassumption considered regarding the live transmission is thatwe are using native IP multicast, since the IPTV provider hascontrol over the network (for example, network providers thatown the network and are interested in offering TV servicesover the IP infrastructure). This IPTV System allows that theresources available in the end-user equipments (e.g., set-topbox) can be used to help in the distribution (e.g.,the userallows the use of his idle resources in exchange of a cheaperservice or a better experience). Another interesting feature ofthis IPTV system is that it allows the re-usage of contentalready distributed to other users, thus enabling video deliveryservices such as Time-Shift [21].

The architecture of this IPTV System comprises four mainmodules: Tracker, Proxy, Cache, and Client (peer). TheTracker module concentrates the information about the peersand the content swarms, returning the peer lists when a Clientjoins to a swarm and requests a content. The Proxy module isresponsible for receiving contents from the external network(e.g., a unicast video stream from a Content Provider) andretransmitting the content in the access network through IPmulticast, avoiding the duplication of the video stream in thenetwork links and the overload of the network and videoserver. The Cache module takes advantage of the multicast,joining the multicast group in order to receive and cache thecontent for later time-shift availability. The Client module isable to join a multicast group in order to play a live channel,or to obtain (and further provide) time-shifted contents. TheClient requests the blocks in the order they will be presented,since the content is being simultaneously played and it isnecessary to avoid interruptions. We choose to do not useCache module on the current testbed because it does not existon regular BitTorrent protocol.

The main attractive of this IPTV system is that it employsa slightly modified P2P algorithm, which does not depend onthe availability of the entire content from the very beginningof the transmission.

B. Testbed architecture and test descriptions

Our main goal when deploying the proposed architecture inthis IPTV scenario was to make a better usage of networkresources enabled by the fact that it runs on a managednetwork. This prototype was deployed in the testbed depicted

210 2010 International Conference on Network and Service Management – CNSM 2010

in Figure 5, and several tests were executed in order to measurenetwork resources usage and also the startup time.

Figure 5. Testbed architecture

The Tracker1 and Proxy module are co-located for simplic-ity. The Proxy is used to convert the multicast streams to ourBitTorrent data format, create the related meta-data, and alsoworks as a peer. The network resource usage measured cor-responds to the amount of traffic generated by the requestingclient/peer, from the beginning of the test to the end of the dataacquiring process. The startup time is measured as the elapsedtime between the moment a peer request some content andthe moment the first frame of this content is displayed on thescreen. We then use this information to evaluate the efficiencyof our locality-based solution when compared to a scenariowhere it is not deployed.

This testbed network architecture was chosen to reproducethe different network levels (Edge Network, MAN, and WAN)as presented in Figure 1. All resources of our testbed areallocated exclusively for our tests, thus avoiding externalinterferences in our measurements. A general description ofthe testbed is given below:

∙ IPTV System: developed using the Java language, usesa modified version of Java BitTorrentAPI1 and jVLC2.The IPTV system was installed on a clean installationof Ubuntu 8.10, and the clock of the computers weresynchronized using NTP (Network Time Protocol).

∙ Network: we use an isolated private network in which alllinks are on a dedicated switch (1 Gbps ports) and eachsubnet has a specific VLAN (traffic isolation).

∙ Computers: all computers are 1U servers with the fol-lowing configuration: Pentium QuadCore 2.4 GHz, 4 GiBRAM, 500 GiB Hard Disk, and 4 Ethernet adapters.

∙ Routers: the routers are 1U servers running Vyatta Com-munity Edition3 version 5.

1http://sourceforge.net/projects/bitext/2http://javaplayer.sourceforge.net/doc/vlc/JVLC.html3http://www.vyatta.com

As discussed in section IV, our solution allows the com-putation of the weight 𝑤 of the graph edges to be fullycustomizable, according to any desired criteria. In the imple-mented prototype, we decided to use a criteria based on linkprioritization, and to make it susceptible to changes on theavailable link bandwidth, according to the following formula:

𝑤 =1

(𝑃𝑟𝑖𝑜𝑟𝑖𝑡𝑦𝑉 𝑎𝑙𝑢𝑒 ∗𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒𝐵𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ)

The 𝑃𝑟𝑖𝑜𝑟𝑖𝑡𝑦𝑉 𝑎𝑙𝑢𝑒 is defined by the network operator andrepresents the priority in the selection of the link in a rangeof [1− 100], where the value 1 represents the highest priority.In our tests, we chose 𝑃𝑟𝑖𝑜𝑟𝑖𝑡𝑦𝑉 𝑎𝑙𝑢𝑒 = 80 to all networklinks, aiming at making the weights more susceptible tofluctuations in the value of 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒𝐵𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ. The valueof 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒𝐵𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ is collected by the trackers usingSNMP probes (measured in Kbps), which are sent to thenetwork elements of interest. The probing rate adopted in ourtests is 1 probe every 30 seconds and, thus, the weight of theedges as seen by the trackers and Root Tracker are recalculatedevery 30 seconds. In order to select the best peers for a giventask, the tracker applies Dijkstra’s algorithm on its local graph,thus choosing the paths having the lowest weights (note thata higher 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒𝐵𝑎𝑛𝑑𝑤𝑖𝑑𝑡ℎ leads to a lower value of 𝑤).

We consider four test cases in our evaluation, described inthe following:

∙ Test 0: A single tracker without the locality service. Peer1requests some content available in all other peers, andonly Tracker1 is enabled.

∙ Test 1: All trackers enabled with the locality service.Peer1 requests a content available in all the other peers.

∙ Test 2: All trackers enabled with the locality service.Peer5 requests some content not available under its owndomain (managed by Tracker2), but that is available inthe domain of Tracker1.

∙ Test 3: All trackers enabled with the locality service.Peer1 requests a content available in all other peers,but the network conditions change while the contentis being acquired; since the peers from which Peer1is acquiring the content become unable to provide therequired throughput, Peer1 needs a new list of peers.

The size of the content file used in the tests is 388.8 MiB(runtime: 04:30min). Our IPTV system divides the content inblocks with the size of two seconds, resulting in 135 torrentfiles (meta-data). The network traffic during each test wascaptured using the tcpdump sniffer4 on the elements involvedin each test case. Additionally, we developed a set of filtersfor tshark5 to summarize the resulting dump files and togenerate data for our analysis; this allows us to measure thenetwork traffic in each network link and the time taken byeach operation. Each test case was repeatedly run (namely, 10times); the results presented correspond to the average of themeasurements.

4http://www.tcpdump.org/5http://www.wireshark.org/docs/man-pages/tshark.html

2010 International Conference on Network and Service Management – CNSM 2010 211

C. Results: Test 0

Figure 6 shows the amount of network traffic in eachnetwork link for Test 0. There is network traffic in all linksexcept for Link 8, in which the content is not available.

Figure 6. Network traffic measured in Test 0

This result is explained by the fact that Peer1 (the requestingpeer) received from the tracker a list containing all thepeers from the swarm. Thus, in this non-optimized BitTorrentsystem, Peer1 opening multiple connections trying to obtainthe content from all the peers available in the network.

D. Results: Test 1

Figure 7 shows the results of the measurements of Test 1.

Figure 7. Network traffic measured in Test 1

In this case, since our hierarchical tracker system is enabled,the peer list returned to Peer1 by by Tracker1 contains onlythe two peers closest to Peer1 (according the results obtainedfrom Tracker1 graph computations). Thus, there is networktraffic only in the links used by Peer1 to obtain the contentfrom Peer2 and Peer4 (namely, Links 2, 3, 4, and 9).

E. Results: Test 2

Figure 8 shows the network traffic measured in Test 2. Sincethe content requested by Peer5 is not available under its owndomain (Scope 2), Tracker2 contacts the Root Tracker andobtains a tracker list in which that content is available; in thiscase, this list contains only Tracker1. Tracker2 then contactsTracker1, requesting a list with the best peers (relatively toTracker2’s position) having the desired content.

Figure 8. Network traffic measured on Test 2

The graph of the network traffic shows that the peerscontacted by Peer5 while obtaining the content were Proxy andPeer4, the closest peers according to the graph computations.

F. Results: Test 3

In this test, when Peer1 starts acquiring the content, theconditions are identical to those in Test 1; hence, as before,Tracker1 returns to Peer1 a list containing only Peer2 andPeer4. However, after 1 minute Peer4 starts sending a 1.2GiBfile to Router R2, considerably affecting the quality of Link2. As a result, the next time Peer1 requests a peer list toTracker1, Peer1 receives a list containing only Peer2 and Peer3for downloading the next torrent blocks. When the file copyoperation is finished, the peer list returned by the Tracker1 toPeer1 is again composed by Peer2 and Peer4. Figures 9 and10 presents the measurement results.

Figure 9. Network traffic measured on Test 3

Figure 10. Use of network links 2 and 5 during Test 3

G. Results analysis

Since the tests scenario of our hierarchical tracker solutionis an IPTV system, the aspects we consider in our evaluationare both the usage of the available network resources and thecontent playback performance in the clients. This latter aspectis evaluated in terms of startup time – a critical metric on aIPTV-System, since it is directly related to QoE (Quality-of-Experience) of the users [22] – and video continuity – i.e.,once the first block of the requested content is played, it isnecessary to keep receiving the next content blocks in orderto avoid interruptions.

Table V shows the elapsed time between the content requestand the presentation of the first frame in the screen, as wellas the average for the download time of all the 135 contentblocks.

212 2010 International Conference on Network and Service Management – CNSM 2010

Table VCOMPARISON BETWEEN THE STARTUP TIME OF THE TESTS

Test Startup Time (ms) Block Download Time (ms)

Test 0 2054 1095

Test 1 1681 1191

Test 2 2309 1703

Test 3 1708 1196

Table V shows that the startup time of our hierarchicaltracker system (Test 1) is lower than the one achieved withoutany locality service, when the content is available under thedomain. In fact, note that this reduction in the startup timeaccompanies the optimization of the network resources usage,since the results from Figure 7 shows that only two peersare needed in the process and there is network traffic onfewer links. On the other hand, the startup time measuredin Test 2 is the highest one measured due to the initialcontrol communication between trackers to obtain a peer listof Tracker1 domain.

Test 1 achieves an average Block Download Time similarto Test 0, even though the former uses only two peers insteadof all peers simultaneously as on the latter. We note that eventhough Test 1 does not present the best average Block Down-load Time, the values obtained with fewer network resourcesand peers are quite close to the best results and they satisfythe IPTV system requirements. Since each content block isequivalent to two seconds, a Block Download Time belowtwo seconds is enough to assure that the content playback isnot be interrupted, showing the suitability of the measuredresults. Moreover it shows that our proposal achieves the goalto optimize the network resources usage that is not achievedby BitTorrent and also presents a reduction on the startup time.Thus we demonstrated that our hierarchical tracker systemproduces better results than an IPTV System based only on aregular BitTorrent.

VI. CONSIDERATIONS AND FUTURE WORK

In this paper, we propose a hierarchical tracker architectureto tackle the well known problem of locality awareness inmanaged P2P networks. The network operator can configurethe 𝑃𝑟𝑖𝑜𝑟𝑖𝑡𝑦𝑉 𝑎𝑙𝑢𝑒 on the edges of the tracker graph to avoidnetwork traffic on a set of network links in order to reduce itsnetwork operation costs. Thus, the architecture allows opera-tors to employ the P2P technology in a cost-efficient manner,optimizing the network resources usage for content distributionin a scalable way. Moreover, the solution does not compromiseservice quality, as corroborated by experimentation in an IPTVscenario. We measured the network overhead due to controltraffic (SNMP probes, communication among Trackers andRoot Tracker, and peers and Tracker) and the total amount ofthis network traffic was not expressive enough to compromisethe overall system performance.

We are currently working on a simulation framework thatwould allow us to further evaluate the scalability of theproposed architecture of hierarchical trackers. In this manner,we expect to be also able to better understand the behaviorof larger systems, and to identify strategies for enhancing thecomputation of the edge weights on a real network.

ACKNOWLEDGMENT

This work has been supported by the Research and Devel-opment Centre, Ericsson Brazil.

REFERENCES

[1] “Spotify music service.” [Online]. Available: http://www.spotify.com[2] “Bbc iplayer.” [Online]. Available: http://www.bbc.co.uk/iplayer[3] H. Xie, A. Krishnamurthy, A. Silberschatz, and Y. R. Yang,

“P4p: Explicit communications for cooperative control betweenp2p and network providers,” p. 7, 2008. [Online]. Available:http://www.dcia.info/documents/P4P_Overview.pdf

[4] D. Gallo, C. Miers, V. Coroama, T. Carvalho, V. Souza, and P. Karlsson,“A multimedia delivery architecture for iptv with p2p-based time-shiftsupport,” in CCNC’09: Proceedings of the 6th IEEE Conference onConsumer Communications and Networking Conference. Piscataway,NJ, USA: IEEE Press, 2009, pp. 447–448. [Online]. Available:http://dx.doi.org/10.1109/CCNC.2009.4784884

[5] T. Lohmar and J. Kritzner, “Evaluation of content distribution networks(CDN) for on-demand content in IPTV environments,” Ph.D. disserta-tion, Rheinisch-Westfälische Technische Hochschule Aachen, 2008.

[6] C. Huang, A. Wang, J. Li, and K. W. Ross, “Understanding hybrid cdn-p2p: why limelight needs its own red swoosh,” in NOSSDAV, 2008.

[7] H. Yin, X. Liu, T. Zhan, V. Sekar, F. Qiu, C. Lin, H. Zhang, and B. Li,“Design and deployment of a hybrid cdn-p2p system for live videostreaming: experiences with livesky,” in MM ’09: Proceedings of theseventeen ACM international conference on Multimedia. New York,NY, USA: ACM, 2009, pp. 25–34.

[8] A. L. Jia and D. M. Chiu, “Designs and evaluation of a tracker in P2Pnetworks,” in Proceedings of the 8th International Conference on Peer-to-Peer Computing. IEEE Computer Society, 2008, pp. 227–230.

[9] B. Cohen, “The bittorrent protocol specification,” 2008. [Online].Available: http://www.bittorrent.org/beps/bep_0003.html

[10] ——, “Incentives build robustness in bittorrent,” 2003. [Online].Available: http://citeseer.ist.psu.edu/cohen03incentives.html

[11] M. W. Barbosa, M. M. Costa, J. M. Almeida, and V. A. F. Almeida,“Using locality of reference to improve performance of peer-to-peerapplications,” in Proc. of the 4th international workshop on Softwareand performance. California/USA: ACM, 2004, pp. 216–227.

[12] R. Paul, “Verizon embraces P4P, a more efficient peer-to-peertech,” 2008. [Online]. Available: http://arstechnica.com/news.ars/post/20080314-verizon-embraces-p4p-a-more-efficient-peer-to-peer-tech.html

[13] H. Cai and J. Wang, “Exploiting geographical and temporal locality toboost search efficiency in peer-to-peer systems,” IEEE Transactions onParallel and Distributed Systems, vol. 17, no. 10, pp. 1189–1203, 2006.

[14] A. Legout, G. Urvoy-Keller, and P. Michiardi, “Rarest first and chokealgorithms are enough,” in IMC ’06: Proc. of the 6th ACM SIGCOMMconference on Internet measurement. USA: ACM, 2006, pp. 203–216.

[15] J. Peterson, V. Gurbani, and E. Marocco, “Alto WG, application layertraffic optimization working group,” http://tools.ietf.org/wg/alto/, 2010.

[16] H. Xie, A. Krishnamurthy, A. Silberschatz, and Y. R. Yang,“P4p: Explicit communications for cooperative control betweenp2p and network providers,” p. 7, 2008. [Online]. Available:http://www.dcia.info/documents/P4P_Overview.pdf

[17] J. Rexford, “Refactoring network control and management: A case forthe 4D architecture,” University of Princeton, Tech. Rep., 2008. [Online].Available: http://www.cs.princeton.edu/~jrex/papers/4D-report.pdf

[18] ——, “Network protocols designed for optimizability,” in InformationSciences and Systems, 2006 40th Annual Conference on, 2006, pp.351–354. [Online]. Available: 10.1109/CISS.2006.286491

[19] U. Wen, W. Wang, and C. Yang, “Traffic engineeringand congestion control for open shortest path firstnetworks,” Omega, vol. 35, no. 6, pp. 671–682, Mar.2006. [Online]. Available: http://www.sciencedirect.com/science/article/B6VC4-4KMYG65-2/2/070e058bcbfd95374e89675e0ffa24a8

[20] E. Dijkstra, “A note on two problems in connexion with graphs,”Numerische Mathematik, vol. 1, no. 1, pp. 271, 269, Dec. 1959.

[21] D. Gallo, V. Coroama, C. Miers, T. Carvalho, V. Souza, and P. Karlsson,“Time-Shift based on P2P: exploiting network resources for a hybridIPTV architecture,” in I2TS 2008, Dec. 2008.

[22] J. Greengrass, J. Evans, and A. Begen, “Not all packets are equal, parti: Streaming video coding and sla requirements,” Internet Computing,IEEE, vol. 13, no. 1, pp. 70 –75, jan.-feb. 2009.

2010 International Conference on Network and Service Management – CNSM 2010 213