On the performance of ad hoc routing protocols under a peer-to-peer application

J. Parallel Distrib. Comput. 65 (2005) 1337–1347www.elsevier.com/locate/jpdc

On the performance of ad hoc routing protocols under a peer-to-peerapplication

Leonardo B. Oliveira, Isabela G. Siqueira∗, Antonio A.F. LoureiroComputer Science Department, Federal University of Minas Gerais, ICEx, Av. Antônio Carlos, 6627 Pampulha, Belo Horizonte, Minas Gerais,

CEP 31270-010, Brazil

Received 1 January 2004; accepted 11 May 2005Available online 15 July 2005

Abstract

Mobile ad hoc networks (MANETs) and peer-to-peer (P2P) applications are emerging technologies based on the same paradigm: theP2P paradigm. Motivated, respectively, by the necessity of executing applications in environments with no previous infra-structure and thedemand for applications that share files or distribute processing through the Internet, MANETs and P2P applications have received someinterest from research community. As a characteristic of the distributed model, which they follow, such technologies face a difficult taskof routing requests in a decentralized environment. In this paper, we conducted a detailed study of a Gnutella-like application runningover a MANET where three different protocols were considered. The results show that each protocol that were analyzed performed wellin under some conditions and for some metrics, while had drawbacks in others.© 2005 Elsevier Inc. All rights reserved.

Keywords:P2P over MANETs; MANETs; Peer-to-Peer applications; Gnutella; Ad hoc routing protocol; Performance evaluation; Simulation

1. Introduction

The recently introduced peer-to-peer (P2P) paradigm [15]is the basis for both Mobile Ad hoc Networks (MANETs)[7] and popular Internet P2P applications (e.g. SETI@home,Napster, Gnutella, Freenet). One of the most significant char-acteristics of the P2P paradigm is the fact that central units,which are responsible for managing and meeting the needsof the network, are non-existent. In this model, nodes haveequivalent functionalities and provision capabilities and, asa consequence, are called “peer” entities. Every peer is ableto send and reply to request messages originated from eachother. This shows the dual interface of these peers, sincethey might play the role of servers and clients simultane-ously. That is the reason why they are also named “servents”(servers/clients).

∗ Corresponding author. Fax: +55 31 3499 5858.E-mail addresses:[email protected](L.B. Oliveira),

[email protected](I.G. Siqueira),[email protected](A.A.F. Loureiro).

0743-7315/$ - see front matter © 2005 Elsevier Inc. All rights reserved.doi:10.1016/j.jpdc.2005.05.023

Similar to the architecture on which they are based,MANETs and P2P applications have recently attractedboth research community and media attention. The growthof computing resources for mobile devices has been thekey contributing factor for the focus on MANETS. More-over, the launch of new applications—such as rescue teammanagement in disaster situations or the exchange of in-formation in battle fields[26,1]—generates an increase indemand for networks without previous infra-structure. Thespread out of P2P applications, on the other hand, can beattributed to their success as content sharing and distributedprocessing platforms [23,1]—where parallel applicationsrun on available peers.

Based on the same paradigm, both P2P applicationnetworks—composed by a set of servers implementing aP2P application—and MANETs have common characteris-tics and functionalities. In essence, both are self-organizingnetworks, have dynamic topology, and are responsible forrouting queries in a distributed environment. Figs. 1(a)and (b) exhibit a MANET and a P2P Application diagram,respectively.

1338 L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347

Transmission Range

Out of range

Direction and velocity

Ad Hoc Connection

(a)

(b)

Fig. 1. MANET and P2P application diagrams: (a) A MANET diagram;(b) a P2P application diagram[21].

Because nodes in MANETS usually have low computingcapacity and, therefore, are unable to play the role of serversall the time,—or even supply many clients simultaneously—a P2P application appears to be a powerful tool to spreadinformation on this type of scenario. In other words, sincea P2P application network does not possess a unique ser-vice provider at a certain time, but many servents that playthis role, the assignment of distributed network tasks amongnodes prevents them to become overloaded. In addition,we envision that some applications enabled by MANETs(e.g., rescue team communication in disaster situations andexchange of information in battle fields[1,26]) will haveeach instance working in cooperation with the others (i.e.,sending and replying to queries like peers). For instance,a rescue team participant might require information aboutnearest neighbor location. That is true a central server couldbe responsible for store information, but this approach notonly would be more expensive (this would require more hopsand constant location updates), but also less resilient—a sin-gle point o failure is not desirable in rescue team situationsand servers would be target of attacks in battle field con-

Fig. 2. A diagram of a P2P application over a MANET.

texts. A novel diagram of a P2P application running over aMANET is shown in Fig.2.

The main purpose of this work is to learn about the perfor-mance of ad hoc routing algorithms in a scenario in which aP2P application runs over a MANET. In order to accomplishthe desired goals, we have conducted simulation experimentsof some well-known ad hoc routing protocols. The resultshelp clarifying the differences between P2P applicationsand client/server ones showing the usability of such net-works, and discovering possible improvements in MANETrouting.

The destination-sequenced distance-vector routing(DS-DV) [18], the dynamic source routing protocol (DSR)[10], and the ad hoc on demand distance vector (AODV)[19] are the protocols evaluated in this work. The reasonsfor the choice are twofold. First, the nature of those al-gorithms is distinct. While DSDV is pro-active, DSR andAODV are reactive—though the last employs methodsof the two formers. Second, the three have already beenexhaustively tested and validated [2]. The results point outthat each one of these protocols performed well in somescenarios yet had drawbacks in others. This confirms theimportance of considering characteristics of both appli-cation and network in order to have the best integratedsolution.

The rest of this paper is organized as follows. Section 2discusses the related work and Section 3 presents a com-parison between MANETs and P2P application networks.Section 4 briefly describes the routing protocols used inthis work. In Section 5, the P2P application is discussed.The simulation scenarios are described in Section 6 andthe performance evaluation metrics in Section 7. Section8 discusses the simulation results. Section 9 provides adiscussion about the P2P application in comparison withthe client/server results. Finally, Section 10 presents ourconclusions.

L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347 1339

2. Related work

It was only recently that the scientists realized the synergybetween MANETs and P2P networks and started studyingboth systems acting together. This was a very important steptowards providing more applicability for MANETs. Never-theless, still many open issues remain.

Schollmeier et al.[21] and Borg [1] discussed similaritiesand differences of MANETs and P2P networks. The formerfocus mainly in routing aspects and the latter discusses con-tent discovery, security, quality of service, etc.

Kortuem presented Proem [13,12], a middleware platformfor developing and deploying P2P applications tailored topersonal area networks (PANs), a special class of MANETs.

Hu et al. [8] proposed dynamic P2P source routing(DPSR), a routing ad hoc protocol that integrates strategiesused by DSR routing protocol and Pastry P2P protocol [20]to improve scalability.

Papadopouli and Schulzrinne [16,17] and Klemm et al.[11] presented P2P data sharing systems tailored to MAN-break ETs namelyseven degrees of separation(7DS) andoptimized routing independent overlay network(ORION),respectively. 7DS focus on enabling the exchange of dataamong peers not directly connected to the Internet by explor-ing peer mobility, while ORIOM concentrates on file sharingapplications by setting up overlay routes on demand.

Franciscani et al. [6] concentrated on minimizing theimpact of the highly dynamic topology obtained through thecombination of P2P networks and MANETs. They proposedalgorithms for configuring and reconfiguring these networks.In their algorithms, three combinations of neighborhoodassignment are compared: (1)regular, where P2P neighbor-hood corresponds to the physical neighborhood; (2)random,where authors try to achieve the small-world [14,25] phe-nomenon by picking each neighbor at random among onlinepeers; (3) andhybrid, where links are built following a hier-archy and each peer communicates through an intermediate.

Ding and Bhargava [4] performed a theoretical compar-ison between P2P systems over MANETs (broadcast overbroadcast; broadcast; DHT over broadcast; DHT over DHT;and DHT) and presented important results inO-notation.Nevertheless, they do not evaluate real P2P systems and donot take into account practical aspects (e.g., mobility andchannel error) in their work.

Table 1Differences between P2P application networks and MANETs

Item P2P Network MANET

Motivation for creating the network Create a logical infra-structure to provide a service Create a physical infra-structure to provide connectivityConnection between two nodes Fixed medium and direct Wireless and indirectConnection confidence High (physical connections, many paths) Low (wireless connections)Peer location Any internet point Restricted areaStructure Physical apart from logical structure Physical structure corresponds to logical structureRouting Only reactive algorithms possible, reliable algorithms

not implemented yetReactive, pro-active and reliable algorithms exist

Peer behavior Fixed MobileBroadcast Virtual, multiple unicasts Physical, to all nodes in transmission range area

3. Comparison between MANETs and P2P applicationnetworks

P2P applications and MANETs have several aspects incommon[22,9,13,1]. Both MANETs and P2P applicationnetworks lack managing and centralizing units, since thenetwork is established as soon as the participants opt tointeract with one another. The decision to connect to thenetwork can be taken at distinct moments, so variance isconstantly introduced in the environment.

Another similarity is their dynamic topology, which isa result of the constant changes in connections used bypeers. In MANETs these alterations are mainly caused bynode mobility. That is, as a node moves, it might leavethe transmission range area of its current neighbors andhas its links broken as a consequence. Thus, in order toreestablish contact with peer entities, the peers must setnew connections. Conversely, what causes the dynamictopology of P2P application networks is the low avail-ability of peers. In this scenario applications are executedmostly over fixed networks and the main reason for linkbreakage is not the mobility of nodes, but the short sessionduration.

Curiously, because P2P applications are usually built overa network which is based on the client/server model, theirnetworks present some characteristics that differ from theP2P paradigm. MANETs, on the other hand, have their owncommunication mechanism and, therefore, are more faithfulto the distributed model.

As previously mentioned, in the P2P architecture peerscan communicate with one another without interven-tion of any centralized access point. Paradoxically, P2Papplications are, in fact, clients of services provided byexternal servers—such as DHCP (dynamic host configu-ration protocol), DNS (domain name service), and webservers. In MANETs, requests are really handled by anynetwork participant. Another evidence that MANETs aremore in conformity with the P2P paradigm than P2Papplication networks is the fact that in the former, thepeers are only a single-hop away from their neighbors,whereas in the last, the neighbors are just logic ones andmight be geographically many hops apart. Typical dif-ferences between both technologies [22] are described inTable 1.

1340 L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347

4. Ad hoc routing protocols

In this section, we briefly describe the routing protocolsused in this work.

4.1. DSDV

The DSDV[18] is a variation of the distance vector rout-ing protocol modified for ad hoc networks. The changeswere performed in order to reduce looping properties thatwould be present in the original protocol. DSDV is a hop-by-hop routing and pro-active protocol that provides eachnode a routing table that lists the next-hop information foreach reachable destination. Thus, it requires periodic broad-casting of routing updates and triggered beacon messages,which leads to an increase in routing overhead.

4.2. DSR

DSR [10] employs an on-demand approach regardingroute discovery and maintenance processes. The key differ-ence of the protocol from other on-demand routing proto-cols is the fact that it adopts the source routing strategy—asits own name indicates. That is, the complete path from thesource to destination is carried in each packet. Such pathis discovered through routing query broadcasts. DSR alsoprovides each node a route cache for decreasing the numberof control messages sent. In order to update its respectivecaches, every intermediate node makes use of the sourceroute information available in the packet it forwards.

The main advantage of the approach adopted by DSR isthat no additional mechanism is necessary to detect routingloops. The disadvantage, clearly, is the overhead caused bythe introduction of source routing information in the headerof the data packet.

4.3. AODV

The AODV [19] is a reactive protocol which combinesboth DSR and DSDV characteristics. It borrows the ba-sic route discovery and route-maintenance of DSR as wellas hop-by-hop routing, sequence numbers and beacons ofDSDV. When a source node desires to establish a commu-nication session, it initiates a route discovery process to lo-cate the destination node, by generating a “route request”message, which might be replied by the intermediate nodesin the path to destination or the destination node itself. Atthe time of arrival, the “route reply” message contains thewhole path to destination. To handle the case in which aroute does not exist, or the query or reply packets are lost,the source node rebroadcasts the query packet if no reply isreceived by the source after a time-out.

5. Description of the P2P implemented protocol

In order to achieve the previously described purposes, itwas required to implement a P2P application in the simula-

tor. The adoption of special strategies was entailed, whichwould be dispensable in a client/server architecture. This isdue to the P2P decentralization and dynamic nature and alsoto the role played by the servents in the P2P application net-work, which alternates from server to client and from clientto server.

The implemented protocol is mainly based on Gnutellaprotocol, which is used for P2P communication in Gnutelladecentralized file-sharing system in the Internet. The mainreason for choosing Gnutella protocol is the simplicity of itscommunication model. Since it was developed neither forbest performance nor for best scalability, it is very suitablefor evaluating network performance. Furthermore, Gnutellaprotocol is regarded as being able to adapt very well to dy-namically changing peer populations, which is a very im-portant characteristic.

Although Gnutella was taken as a reference, the pro-tocol was altered for the simulator environment and alsofor ad hoc networks. The strategies adopted are describedbelow.

5.1. Joining the network

A peer desiring to join the P2P application network startsby sending abroadcast-send message through the networkin order to elect its “neighbors”, which may be used for mes-sage flooding. The initial replies will settle virtual connec-tions between the new servent and each answerer. Each oneof these connections is maintained by an entry in a neighborslist which has predefined maximum size. It is important tonotice that virtual neighbors are not equivalent to physicalneighbors, although this is likely to occur at the beginningsince answers of near hosts tend to arrive more quickly.

5.2. Content discovery

The fact that a P2P application network does not possessa server that centralizes information complicates the task oflocating data. In a client/server architecture, this is not aproblem since the client knows the server address in advance.The strategy widely adopted, which has also been used inthis work, is sending aquery-send message through thenetwork order to gather information. This message containsthe required file identification—its name—and the identifi-cation of the peer that is consulting, the “query-source”.

The transmission of queries in the P2P application net-work is carried out through controlled flooding. The ser-vent that receives a query message will forward it in casethe file wanted is not stored in its node. The process goeson until the information source is found or the message isdropped due to a TTL (time-to-live) expiration. Whenever asource is located, i.e., when a “query-hit” event occurs, thepeer that owns the file wanted (“file-source”) sends a replyto the “query-source” peer validating its availability for filetransfer.

L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347 1341

Table 2Messages transmitted in P2P application network

Message type Function Size (Bytes)

broadcast-send Look for neighbors 23broadcast-reply Answer abroadcast-send 38ping Check the activity of a peer 23pong Answer aping 38query-send Search for a file 26query-forward Retransmit a query originated by another peer 26query-reply Answer a query (aquery-hithas occurred) 26push-request Require the transfer of a file 51pull-request Transmit data (pieces of a file) 210 (maximum)

5.3. Content dissemination

After receiving the first reply, the “query-source” ser-vent establishes an end-to-end communication with the “file-source”. The file is fragmented into small pieces and eachpiece is sent inside apull-data message from the “file-source” to the “query-source”. The service for transferringdata is datagram, typical of wireless environments.

5.4. Controlled flooding

Each peer of the network maintains a cache in order toavoid duplicate query processing. This is possible since thequery message is uniquely identified by the pair (query-id,query-source).

The P2P message header has a TTL field to prevent amessage being forwarded infinitely in the P2P applicationnetwork. The idea is similar to TTL field of the Internetprotocol (IP). The next hop of a node in P2P, though, mightbe another node which is not directly connected.

5.5. Neighborhood control

P2P application networks have a dynamic behavior, asmentioned before. Peers can leave or join the network atanytime they necessitate. This implies the employment ofa special control scheme for maintaining an up-to-date listof neighbors. To solve the problem in the implemented pro-tocol, all peers have to send periodicalping messages totheir neighbors to check if they are still “alive”. When noanswer is detected, i.e., when apong message is not re-ceived, the related peer is removed from the neighbor list andabroadcast-send message is sent to find another neighbor.

5.6. Message size

Messages that circulate among peers may have a variablesize and the maximum value is 210 bytes, based on theGnutella Protocol. Table2 presents the message types sentby the peers with their respective functions and sizes.

6. Simulation scenarios

In order to evaluate the accomplish the purposes of thiswork, we have conducted simulation experiments using the

network simulator (ns-2) [5] and its CMU wireless andmobility extension [24]. We have considered a set of defaultsettings. Some of them were varied throughout the simu-lation experiments. The variations can give findings on theperformance of the algorithms for diverse scenarios.

The default settings taken into consideration are the fol-lowing. It was constructed a 200× 200 m2 topology com-posed of 40 mobile nodes, 12 of which implementing a sin-gle instance of the P2P application.

The mobility scheme employed was the random way point(since it is frequently used for individual movements [2]).We have chosen as default settings a pause-time of 50 s anda maximum speed of 0.5 m/s.

The transmission range of all nodes was set to 50 m. Theradio propagation model chosen was the Shadowing Propa-gation Model with a rate of 95% of correct reception withinthe range area. The IEEE 802.11 was the protocol used inthe MAC layer, with 2 Mbits/s of bandwidth. The radio in-terface chosen was the 914 MHz Lucent WaveLAN. The to-tal simulation time for all scenarios was set to be 300 s.

In respect to P2P application parameters, the maximumsize of the neighbors list, for neighborhood control, was setto 3. Also, the initial number of files per peer was set tobe 10. The choice of the initial file names as well as theirsizes follow the normal distribution model. The average filesize is adjusted to 10 kB. This reduced value was estimatedtaking into account the low bandwidth of mobile scenar-ios, as well as memory and energy constraints of mobiledevices.

For controlled flooding, the TTL of thequery-send mes-sages were set to 3—large enough for queries to reach mostof the peers in the simulated scenario. During the simula-tion, 10 searches are scheduled for each peer. The schedul-ing time is uniformly distributed and at each time the searchis carried out only if the peer is part of the P2P network atthe moment.

The choice of the file to be searched follow the normaldistribution model. Theping messages were sent with adefault rate of 6 per minute and thepong messages werewaited for no longer than 10 s. Thebroadcast-send intervaltime was 2 s.

In the simulation, nodes start with 100 J of energy each.The power loss for transmission was set to 0.330 and0.230 W for reception [3].

1342 L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347

During the simulation, both the peer entrance timeand the exit time were uniformly distributed in order tosimulate the dynamic topology of the P2P applicationnetwork.

Each simulation was run 33 times, with different seeds forthe random number generator, on ns-2.1b8a[5] and its CMUwireless and mobility extension [24]. The results representthe average values on the 33 runs.

7. Evaluation metrics

The performance evaluation of ad hoc routing protocolssupporting a P2P application examined four metrics: work-load, mobility, network density and peer quantity. The met-rics were chosen considering its significance for each eval-uation parameter.

7.1. Workload

It shows the workload introduced into the network bythe P2P application. Its increase might place undesirablechanges in network performance, such as latency, packetdropping and control overhead. The term latency suggeststhe amount of time spent for a specific event to happen, suchas a query-hit or the reception of a response. The overheadwas measured only in terms of packets, since the cost toaccess the medium to transmit a packet is significantly moreexpensive than the cost of adding a few extra bytes to anexisting packet.

As a consequence, the network may not provide a goodservice for the application. We have chosen to vary the to-tal number of queries generated by P2P peers (1, 10, 100,and 1000) as well as the average size of the files transferredthrough the network (1, 10, 100, and 100 kB) with the aim ofinvestigating the protocols scalability. The results, for low,medium and high workload, are presented in Section 8. Thefollowing metrics were evaluated: number of initiated filetransfers, throughput, percentage of queries not responded,delivery rate, energy consumption, and routing overhead as-sociated to the ad hoc network.

7.2. Mobility

It represents the speed and pause time applied to thead hoc nodes. Simulation experiments considering mobilitywere conducted, and the protocol capability in adapting todistinct speed (0.1, 0.5, 2.5, and 10 m/s) and pause time (0,60, 120, 180, 240, and 300 s) of node values was analyzed.The metrics chosen were path length, connectivity amongapplication peers, and latency.

7.3. Network density

It affects greatly the performance of the ad hoc network,and, therefore, is an important point of analysis. Simula-

tion experiments considering different values of transmis-sion range (1, 10, 100, and 100 m) and number of nodes(0, 20, 40, 60, and 80) that populate the network were per-formed. In the last case, the number of peers was maintainedat 30% of the total number of nodes. Percentage of queriesnot responded, path length, latency, routing overhead, con-nectivity among application peers, and delivery rate werethe metrics employed to evaluate the three protocols.

7.4. Peer quantity

In order to investigate the influence of the amount of peersover the protocols, the number of nodes was left unmodifiedand the number of peers was varied (10, 20, 30, and 40).This type of analysis is important because it demonstratesthe scalability of the ad hoc routing protocols taking intoaccount the number of application instances that run overthe network. This is essential for selecting the best algorithmin case of deploying a P2P application. The metrics chosenwere routing overhead, latency, path length, throughput, andenergy consumption.

8. Simulation results

This section presents the results according to the fourmetrics described above.

8.1. Workload

The three routing protocols introduced distinguishingamounts of overhead when the number of queries by a nodewas varied. As shown in Fig.3(a), the DSDV exhibits themost overhead, followed by AODV and then DSR. Theformer, for one query, introduced ten times more controlpackets than DSR. Comparing DSDV to AODV and DSRon-demand protocols, the considerable increase in overheadobtained was due to route update messages that are con-stantly triggered by DSDV. Although DSDV produced moreoverhead, it demonstrated to have a steady behavior con-sidering workload increase. The others, in contrast, did notsuggest to be as scalable—the DSR overhead, specifically,duplicated from one extreme of thex-axis to the other.

DSDV was the protocol which consumed the greatestamount of energy for lower, medium, and higher loads, asdepicted in Fig. 3(b). This is a result of the higher numberof control packets sent and received by the nodes.

Fig. 4(a) depicts the fraction of messages delivered to theapplication, as the shared file sizes were incremented. Forall protocols, the curves assumed almost identical shapes. Itcan be noticed that while for 1 kB files the delivery rate ishigher than 90%, for 1000 kB practically all packets weredropped. This is due mainly to the low bandwidth availablein the ad hoc network.

The results for initiated file transfers indicate that for allprotocols the best performance is achieved when the averagefile size is 10 kB. This metric is represented by the number

L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347 1343

0

500

1000

1500

2000

2500

1 10 100 1000

Num

ber

of P

acke

ts

Number of Queries

DSDVDSR

AODV

0

1

2

3

4

5

6

1 10 100 1000

Con

sum

ed E

nerg

y (J

)

Number of Queries

DSDVDSR

AODV

(a)

(b)

Routing Overhead

Energy Consumption

Fig. 3. Number of queries variation: (a) Routing overhead; (b) energyconsumption.

of pull-request messages received in Fig.4(b), which canalso be considered a result of throughput.

On the whole, DSDV performed better for extremelyhigh loads. It obtained the lowest number of queries not re-sponded, the highest throughput and more files successfullytransferred. From Fig. 4(b) it is clear that DSR and AODVdid not support the application requirements, in contrast toDSDV. This is due to the huge congestion generated, whichcaused difficulties for them to find routes on demand.

8.2. Mobility

Figs. 5(b) and (a) show the behavior of the connectionsamong peers. Is is noticed that none of the protocols had aremarkable performance compared to the others. For lowermobility, the average number of neighbors and the amountof ping messages sent were reduced, while the number ofbroadcast-send messages and the number of queries notresponded grew for all protocols. That is, DSDV, DSR andAODV produced more information unavailability and worseP2P connectivity.

As the mobility was incremented, surprisingly, the con-nectivity degree rose (see Fig. 5(a)). This apparently anoma-

0

10

20

30

40

50

60

70

80

90

100

110

1 10 100 1000

Del

iver

y R

ate

(%)

File Size (KB)

DSDVDSR

AODV

Delivery Rate for Application

100

150

200

250

300

350

400

450

1 10 100 1000

Num

ber

of P

acke

ts

File Size (KB)

DSDVDSR

AODV

pull-data Messages Received

(a)

(b)

Fig. 4. File size variation: (a) Delivery rate for application; (b)pull-datamessages received.

lous behavior was mainly caused by the partitioning of thenetwork. When the mobility is low, the network might iso-late peers during the whole simulation, whereas in a highermobility scenario these partitions are eliminated because ofa peer movement. As a result, for high pause-time values,i.e., for low mobility, the number of queries not respondedis also high.

Paradoxically, Fig.6(a) demonstrates that the increase inspeed did not have significant influence after 2.5 m/s. It isimportant to observe, though, that the DSDV and AODVcurves stabilized earlier than the DSR curve.

Fig. 6(b) shows the time elapsed for a query-hit to hap-pen after thequery-send message was sent. Both DSDVand AODV protocols had similar behaviors and showed tobe insensitive to the node speed, whereas DSR was verysensitive to the node speed.

DSR was the protocol which presented the highest num-ber of hops and latency, when mobility was increased. Theterm hops suggests the average amount of hops for a queryto reach an information source. Due to its source routingnature, in case nodes move at high speeds, a route generatedmight become outdated, even at the time when the packetis traversing the network from the source to the destina-tion. As a result, more time and hops are consumed withrouting.

1344 L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347

0.5

0.6

0.7

0.8

0.9

1

1.1

1.2

1.3

0 60 120 180 240 300

Num

ber

of N

eigh

bors

Pause Time (s)

DSDVDSR

AODV

Neighbors

50

55

60

65

70

75

80

85

90

0 60 120 180 240 300

Que

ries

not R

espo

nded

(%

)

Pause Time (s)

DSDVDSR

AODV

Queries not Responded

(a)

(b)

Fig. 5. Pause time variation: (a) Neighbors; (b) queries not responded.

8.3. Network density

Concerning routing overhead, as shown in Fig.7(a),DSDV was badly affected by the increase in the num-ber of the network nodes, as it requires periodic rout-ing updates and broadcasting of triggered beacon mes-sages. In contrast, this scenario modification did notinfluence the other two protocols, which indicated toscale gracefully. Curiously, this performance declina-tion did not appear when the transmission range wasextended.

The three protocols behaved equivalently for both num-ber of nodes and transmission range variation with respectto connectivity among application peers. The protocols hadtheir latency intensified for a denser network, as presentedin Fig. 7(b). Particularly, DSDV appears to be less scalableregarding this metric due to its routing overhead, as previ-ously highlighted.

Regarding both number of queries not responded and net-work delivery rate, DSDV, DSR, and AODV performanceswere similar. The former protocol, despite producing morerouting overhead, managed to maintain the same deliv-

1

1.5

2

2.5

3

3.5

4

4.5

0.1 0.5 2.5 10

Hop

s

Speed (m/s)

DSDVDSR

AODV

(a)

(b)

0

0.02

0.04

0.06

0.08

0.1

0.12

0.1 0.5 2.5 10

Late

ncy

(s)

Speed (m/s)

DSDVDSR

AODV

Latency for Query-Hit

Hops for Finding Information

Fig. 6. Speed variation: (a) Hops for finding information; (b) latency forquery-hit.

ery rate for a denser network. Fig.8(a) shows the resultsobtained for the delivery rate.

In respect to path length, it was observed that this metricis very dependable on network density, as shown in Fig.8(b). The highest average of hops and forwarded packetswas offered by DSR and DSDV protocols, for denser andless dense networks, respectively. The former result can beeasily explained, as DSR does not take into account pathoptimality when routes are generated. The last, though, canbe considered a positive result, since the others obtainednearly zero average hops. In other words, this result meansthat DSDV is the only protocol that really delivers packetsand provides support to the P2P application layer in lessdense scenarios. Regarding the curve shapes of the threeprotocols, a change in the behavior could be detected. At thispoint, the number of hops falls suddenly, as a consequence ofthe proximity of the desired information. That is, when thenumber of existent nodes in the network is higher, it is morelikely that the required information is stored on a near oreasily reachable node. Furthermore, when the transmissionrange is expanded, the packets predictably tend to arrive inthe destination with less hops.

L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347 1345

0

1000

2000

3000

4000

5000

6000

7000

0 10 20 30 40 50 60 70 80

Num

ber

of P

acke

ts

Number of Nodes

DSDVDSR

AODV

Routing Overhead

0

0.05

0.1

0.15

0.2

0.25

0 10 20 30 40 50 60 70 80

Lat

ency

(s)

Number of Nodes

DSDVDSR

AODV

(b)

(a)

Latency for Receiving a query-reply

Fig. 7. Nodes variation: (a) Routing overhead; (b) latency for receivinga query-reply.

8.4. Peers

Fig. 9(a) indicates that the DSR protocol needs more hopsto find information than the others (nearly 2 times morehops than AODV, in the worst case), in agreement with thepreviously described results. Nevertheless, the shape of thecurves is similar for the three protocols. When the network ispopulated with less instances of P2P applications, the desiredinformation tends to be found in a fewer number of P2P hops.Also in this case, the amount of P2P neighbors of a peer islower, since the number of reachable peers is lower as well.As a result, the network is likely to become partitioned, andin the rare cases in which the information is found, it will belocated in one or two hops apart. The growth in the numberof peers, by contrast, may expand the route lengths of theP2P application layer, allowing information to be found ina greater amount of P2P hops, and obviously the same fornetwork hops. After a certain point in the increase of peers,the number of neighbors reached its maximum value and nomore influence was detected.

All protocols were affected equivalently by the through-put. AODV was responsible for the best performance con-

0

10

20

30

40

50

60

70

80

0 10 20 30 40 50 60 70 80

De

live

ry R

ate

(%)

Number of Nodes

DSDVDSR

AODV

Delivery Rate for Application

0

0.5

1

1.5

2

2.5

3

3.5

1 10 100 1000

Hop

s

Transmission Range (m)

DSDVDSR

AODV

Hops for Finding Information(b)

(a)

Fig. 8. Nodes and transmission range variation: (a) Delivery rate forapplication; (b) hops for finding information.

cerning routing overhead, while DSDV, as usual, generatedmore routing control packets. AODV also achieved betterresults respecting time. DSR, in contrast, presented the high-est latency not only because it does not provide an optimalpath, but also due to the fact that packets to be transmittedare held in its buffer until the path to destination is found.

Finally, Fig. 9(b) presents the energy consumption. It ispossible to observe that the shape of the curves for all theprotocols evaluated was similar, considering the increasingof peers. AODV, however, provided less consumption (0.35 Jless, approximately), since it possess the lower overhead.

9. Comparison between P2P and client/serverapplications

In this section a performance comparison between appli-cations based on P2P and client/server paradigms is pre-sented. The results concerning the client/server applicationwere obtained mainly from [2].

First, regarding mobility, P2P and client/serverapplications exhibit considerable differences. Unlike the

1346 L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347

0

1

2

3

4

5

10 15 20 25 30 35 40

Hop

s

Number of Peers

DSDVDSR

AODV

(a)

0

1

2

3

4

5

10 15 20 25 30 35 40

Con

sum

ed E

nerg

y (J

)

Number of peers

DSDVDSR

AODV

Energy Consumption

Hops for Finding Information

(b)

Fig. 9. Peers variation: (a) Hops for finding information; (b) energyconsumption.

client/server model, in which the shortest path was obtainedby DSR and DSDV in the simulated application, AODVwas the protocol that presented the best performance, deliv-ering the queries with the lowest hops average. This resultshows that the merge between hop-by-hop routing of DSDVand route-discovery of DSR is less affected by the mobilityproperty when a P2P application is considered.

Second, in both paradigms DSDV demonstrated to havethe highest and steadiest overhead. However, the discrepancybetween it and the other protocols is higher with the P2Papplication execution. It happens due to the growth in thetopology dynamism caused by this type of application. Manylink breakages occur and, as a result, a great amount ofupdate messages need to be triggered. Despite the fact thatAODV still has more overhead than DSR, the separationbetween the performance of both has decreased 60% at most,comparing with the results of a client/server application.

In respect to the delivery rate, the network performancesupporting a P2P application presented a worse result. Withthe increase in the amount of nodes, the rate achieved at most80%, whereas in client/server applications, it was achievednearly 100%.

The most interesting result, possibly, was obtained withthe mobility variation. Contrary to the scenarios that runapplications based on a client/server model, the resultsachieved in this work reveal that P2P applications are notsuitable for low mobility scenarios. First of all, it is impor-tant to emphasize that this kind of distributed applicationsare built to function in high dynamic scenarios, so it is rea-sonable that they present a low performance in more stablescenarios. Furthermore, when a peer moves, despite beinglikely to lose physical connections in the ad hoc networklevel, it might not only maintain its P2P application links,but also establish others. And since the peers are highly de-pendable on their set of neighboring peers to communicatewith the rest of the P2P application network, an increase intheir amount of neighbors becomes an advantage.

10. Conclusion and future work

In the last few years, mobile ad hoc networks (MANETs)and peer-to-peer applications have started to be deployed,leading to a greater interest in the network community dueto their distinct characteristics from traditional networks.Both MANETs and P2P applications have several points incommon since they are based on the same model. There-fore, it is natural to study both MANETs and P2P applica-tions together. In this paper we conducted a detailed study ofa Gnutella-like application running over a MANET wherethree different routing protocols were considered. It is inter-esting to notice that each of the protocols that was analyzedperformed well in some scenarios for some metrics yet haddrawbacks in others. This conclusion shows the importanceof identifying more precisely characteristics of the P2P ap-plication itself (workload, peer quantity) and characteristicsof the network and mobile devices (mobility, network den-sity) before committing to a particular protocol.

Future work will focus on improving performance of P2Papplications over MANETs. Some of the strategies, whichmay be adopted are: modify existent ad hoc protocols or evenpropose other ones, use multicast protocols to disseminateinformation, and develop a middleware so that one layer—network or application—can take better advantage of theservices of the other layers.

References

[1] J. Borg, A comparative study of ad hoc & peer to peer networks,Master’s Thesis, University College London, 2003.

[2] J. Broch, D.A. Maltz, D.B. Johnson, Y.-C. Hu, J. Jetcheva, Aperformance comparison of multi-hop wireless ad hoc networkrouting protocols, in: Proceedings of the Fourth annual ACM/IEEEInternational Conference on Mobile Computing and Networking,ACM Press, Dallas, Texas, United States, 1998, pp. 85–97.

[3] J.-C. Cano, P. Manzoni, A performance comparison of energyconsumption for mobile ad hoc network routing protocols, in: EighthInternational Symposium on Modeling, Analysis and Simulation ofComputer and Telecommunication Systems (MASCOTS’00), IEEEComputer Society, San Francisco, CA, 2000, pp. 57–64.

L.B. Oliveira et al. / J. Parallel Distrib. Comput. 65 (2005) 1337–1347 1347

[4] G. Ding, B. Bhargava, Peer-to-peer file-sharing over mobile adhoc networks, in: Second IEEE Annual Conference on PervasiveComputing and Communications Workshops, Orlando, Florida, 2004,pp. 104–108.

[5] K. Fall, K. Varadhan, Network Simulator Notes and Documentation,The VINT Project, February 2001.

[6] F.P. Franciscani, M.A. Vasconcelos, R.P. Couto, A.A.F. Loureiro,(Re)Configuration algorithms for peer-to-peer over ad hoc networks,J. Parallel Distrib. Comput. (JPDC) 65 (2) (2005) 234–245.

[7] Z.J. Haas, J. Deng, B. Liang, P. Papadimitratos, S. Sajama, Wirelessad hoc networks, in: J.G. Proakis (Ed.), Wiley Encyclopedia ofTelecommunications, Wiley, New York, 2002.

[8] Y.C. Hu, S.M. Das, H. Pucha, Exploiting the synergy between peer-to-peer and mobile ad hoc networks, in: HotOS-IX: Ninth Workshopon Hot Topics in Operating Systems, Lihue, Kauai, Hawaii, 2003.

[9] Y.C. Hu, S.M. Das, H. Pucha, Exploiting the synergy between peer-to-peer and mobile ad hoc networks, in: Proceedings of the NinthWorkshop on Hot Topics in Operating Systems (IX HotOS), 2003.

[10] D.B. Johnson, D.A. Maltz, Dynamic source routing in ad hoc wirelessnetworks, in: C.E. Perkins (Ed.), Ad Hoc Networking, Addison-Wesley, Reading, MA, 2001, pp. 139–172, (also appeared in IEEEComputer Communications).

[11] A. Klemm, C. Lindemann, O.P. Waldhorst, A special-purposepeer-to-peer file sharing system for mobile ad hoc networks, in:IEEE Semiannual Vehicular Technology Conference (VTC2003-Fall),2003.

[12] G. Kortuem, Proem: a middleware platform for mobile peer-to-peercomputing, SIGMOBILE Mobile Computing and CommunicationReview, vol. 6, No. 4, 2002, pp. 62–64.

[13] G. Kortuem, J. Schneider, D. Preuitt, T.G.C. Thompson, S. Fickas,Z. Segall, When peer-to-peer comes face-to-face: collaborative peer-to-peer computing in mobile ad hoc networks, in: IEEE FirstInternational Conference on Peer-to-Peer Computing, Linkopings,Sucia, 2001, pp. 75–91.

[14] S. Milgram, The small-world problem, Psychol. Today 1 (1) (1967)60–67.

[15] A. Oram, Peer-To-Peer: Harnessing the Power of DisruptiveTechnologies, First ed., O’Reilly, 2001, iSBN:0-596-00110-X.

[16] M. Papadopouli, H. Schulzrinne, Effects of power conservation,wireless coverage and cooperation on data dissemination amongmobile devices, in: Second ACM International Symposium on Mobilead hoc Networking & Computing, ACM Press, New York, 2001, pp.117–127.

[17] M. Papadopouli, H. Schulzrinne, A performance analysis of 7ds apeer-to-peer data dissemination and prefetching tool for mobile users,in: Advances in Wired and Wireless Communications, IEEE SarnoffSymposium Diges, Ewing, USA, 2001.

[18] C.E. Perkins, P. Bhagwat, Highly dynamic destination-sequenceddistance-vector routing (DSDV) for mobile computers, in:Proceedings of ACM Conference on Communications Architectures(SIGCOMM’94), Protocols and Applications, ACM Press, London,United Kingdom, 1994, pp. 234–244.

[19] C.E. Perkins, E.M. Royer, Ad hoc on-demand distance vector routing,in: Proceedings of the Second IEEE Workshop on Mobile ComputingSystems and Applications, New Orleans, LA, 1999, pp. 90–100.

[20] A. Rowstron, P. Druschel, Pastry: scalable, distributed object locationand routing for large-scale peer-to-peer systems, in: Proceedingsof IFIP/ACM International Conference on Distributed SystemsPlatforms (Middleware’01), 2001, pp. 329–350.

[21] R. Schollmeier, I. Gruber, M. Finkenzeller, Routing in peer-to-peer and mobile ad hoc networks: a comparison, in: InternationalWorkshop on Peer-to-Peer Computing, Pisa, Italy, 2002, held inconjunction with IFIP Networking 2002.

[22] R. Schollmeier, I. Gruber, M. Finkenzeller, Routing in peer-to-peerand mobile ad hoc networks: a comparison, in: Revised Papers fromthe NETWORKING 2002 Workshops on Web Engineering and Peer-to-Peer Computing, Springer-Verlag, Pisa, Italy, 2002, pp. 172–186.

[23] D. Talia, P. Trunfio, Toward a synergy between p2p and grids, IEEEInternet Comput. 7 (4) (2003) 94–95.

[24] The cmu monarch projects wireless and mobility extension to ns,work in Progress, September 2004.

[25] D. Watts, S. Strogatz, Collective dynamics of= small-world’networks, Nature 393 (6) (1998) 440–442.

[26] L. Zhou, Z.J. Haas, Securing ad hoc networks, IEEE Network 13(6) (1999) 24–30.

Leonardo B. Oliveira received his B.Sc.(2003) and M.Sc. (2004) degrees in Com-puter Science from Federal University of Mi-nas Gerais (UFMG), Brazil. He is currentlypursuing a doctoral degree at University ofCampinas (UNICAMP), Brazil. Leonardo’sprimary research interests include P2P net-works over MANETs and security in sensorad hoc networks.

Isabela G. Siqueira received her B.Sc. de-gree in Computer Science from the Fed-eral University of Minas Gerais (UFMG),Brazil, in 2003. She is currently pursuingher M.Sc. degree in Computer Science at thesame university. Her main research interestsinclude Peer-to-Peer computing, MANETs,and topology control in sensor networks.

Antonio A.F. Loureiro holds a B.Sc. anda M.Sc. in Computer Science, both fromthe Federal University of Minas Gerais(UFMG), and a Ph.D. in Computer Sciencefrom the University of British Columbia,Canada. Currently he is an Associate Pro-fessor of Computer Science at UFMG. Hismain research areas are mobile Comput-ing, distributed algorithms, and networkmanagement.