On the Impact of Mobile Hosts in Peer-to-Peer Data Networks

Zhenyun Zhuang†, Sandeep Kakumanu†, Yeonsik Jeong†, Raghupathy Sivakumar†, Aravind Velayutham§†{zhenyun, ksandeep, ysjeong, siva}@ece.gatech.edu, Georgia Tech, Atlanta, GA 30332

§vel@asankya.com, 75 5th Street NW, Suite 212, Asankya Inc., Atlanta, GA 30308

AbstractPeer-to-peer (P2P) data networks dominate Internet

traffic, accounting for over 60% of the overall traffic in arecent study. In this work, we study the problems that arisewhen mobile hosts participate in P2P networks. We pri-marily focus on the performance issues as experienced bythe mobile host, but also study the impact on other fixedpeers. Using BitTorrent as a key example, we identify sev-eral unique problems that arise due to the design aspectsof P2P networks being incompatible with typical charac-teristics of wireless and mobile environments. Using theinsights gained through our study, we present a wirelessP2P (wP2P) client application that is backward compati-ble with existing fixed peer client applications, but whenused on mobile hosts can provide significant performanceimprovements.

1 IntroductionOver the last few years, peer-to-peer (P2P) data sharing

applications have experienced an explosive growth. By theend of 2005, a staggering 60% of the Internet data trafficconstituted of P2P file sharing [5]. While copyright con-cerns had earlier brought down popular P2P applicationssuch as Napster, several content owners and providers haveof late started embracing what is being seen as a technologythat has come to stay [1].

With P2P data sharing applications securing a dominantposition in the Internet landscape, an interesting question isto ask is: what is the performance of mobile users when par-ticipating in P2P data sharing? The question is significantbecause of two reasons: (a) as with any Internet applica-tion with emerging or established popularity, wireless andmobile users are increasingly adopting P2P data sharing ap-plications on devices such as laptops and PDAs [9]; And (b)there are several efforts underway to deliver P2P data shar-ing as the next killer application for mobile devices [17, 16].Initial instantiations of such efforts focus on sharing of ring-tones and music files, but are expected to evolve into othertypes of content including video.

Thus, in this work, we first investigate the followingquestion: what is the performance of a mobile user in a

wireless environment using a P2P data sharing applica-tion? As a corollary, we also investigate the following ques-tion: what is the performance of a fixed peer in a P2P net-work when using a mobile host as a corresponding peer?In answering the above questions, we find that several ofthe fundamental design principles and peculiarities used inP2P data sharing applications are inconsistent with the keylimiting characteristics of typical wireless and mobile en-vironments. Briefly, some of these issues include: (i) P2Papplications, unlike in typical scenarios where a mobile hostfunctions as a client, creates a scenario requiring the mobilehost to function as a server. This raises several implica-tions that we discuss later in the paper. (ii) P2P data sharinguniquely involve simultaneous bi-directional data transfer.This consequently results in the use of bi-directional TCP,a form of TCP not studied extensively for wireless environ-ments. (iii) P2P data networks, by virtue of being almost en-tirely supported by end-hosts, typically use incentives basedperformance delivery. In other words, a mobile host that hasuploaded more data is provided with higher performance.Such a mechanism exposes issues when applied as-is to awireless and mobile environment. (iv) While incentives en-courage P2P users to share data longer, P2P data fetching isalso adapted to increase the uniquely shareable data avail-able at a user. One such approach is performing random orrarest-first fetching. However, such techniques have severeimplications to the mobile user, especially during discon-nections. Using experiments on a real-life P2P data sharingnetwork, we profile the performance of a mobile user withrespect to the above issues.

Using insights gained through the aforementioned study,we present a deployable solution suite called wireless P2P(wP2P) that addresses the issues using changes only to theP2P application at the mobile host. wP2P uses techniquestransparent to the fixed peer, but uniquely relevant to thespecific issues pertaining to wireless and mobile hosts func-tioning in a P2P data network. While we elaborate onthe specifics of the solutions later in the paper, wP2P usesa combination of multiple proposed techniques in tandemincluding age based manipulation, incentive aware opera-tions, and mobility aware fetches. We evaluate wP2P with

an implemented prototype, and show that significant perfor-mance improvements can be achieved for mobile hosts andfixed peers when using wP2P at the mobile hosts. Thus, thecontributions of this work are twofold:• We consider the specific scenario of mobile hosts par-

ticipating in P2P data sharing applications, and investigateperformance issues such hosts face due to the unique designelements embedded in typical P2P applications. Using real-life experiments on a P2P data sharing network, we identifythese design elements that when combined with the uniquecharacteristics of wireless environments render the perfor-mance delivered to mobile users sub-par.• We present a deployable solution called wP2P that is

required to be instantiated only at the mobile host. And,when deployed thus, wP2P addresses the issues identifiedabove to deliver enhanced P2P data sharing performance tomobile users. Using a prototype implementation, we char-acterize the performance of wP2P and show that consider-able improvements can indeed be achieved.

The rest of the paper is organized as follows: Section2 presents the scope of this work and describes key back-ground material. Section 3 presents in detail the motivationresults that show the limiting performance existing P2P ap-plication design impose on mobile users. Section 4 outlinesthe key design basis and describes the wP2P solution in de-tail, while Section 5 presents the performance evaluation ofwP2P. Finally, Sections 6 and 7 discuss related-work andconclusions respectively.

2 Scope and BackgroundWe now briefly present the scope of this work and outline

some of the key elements of the BitTorrent protocol relevantto the focus of this work.

2.1 Scope of this work

• P2P Networks: While there are several forms of P2Pnetworks ranging from those that help in computing (grids)to those that help in communication (e.g. skype) to thosethat help in data-sharing, this work is entirely focused onP2P data sharing networks. Data sharing P2P networks areprimarily used for sharing files containing audio (e.g. mp3files), video (e.g. mpeg2 files), or data (e.g. linux distribu-tions). Examples of such networks include BitTorrent [1],eDonkey, Gnutella, and FastTrack. Recent study show thatP2P traffic is dominating Internet traffic and specifically, theBitTorrent [1] P2P network accounts for 30% of the overallInternet traffic [5]. Of this, video files account for more than62% of the P2P traffic. Measurement studies conducted re-cently observe far more wireless and mobile users on thenetwork than ever before [9].• BitTorrent: In this work, while we identify character-

istics of P2P networks that are generically applicable to all

four of the above networks, we use BitTorrent as the pri-mary example for all discussions, experiments, and trials.However, as necessary we also step back and investigate rel-evance of our discussions and interpretations for the othernetworks as well. We believe that this choice of BitTorrentas the key representative is justifiable from multiple stand-points including its dominance in terms of traffic carried,and its relative sophistication.•Wireless Technologies and Mobile Devices: While mo-

bile users with any type of wireless access can participate inP2P networks, the access technology typically used is wire-less LANs (WLANs). This is both because of the higherbandwidths available on WLANs, and the relatively loweror no cost models associated with such networks. Hence,we consider WLANs for the wireless environment in thispaper. Similarly, while other mobile devices such as PDAsand IP enabled cellphones are fair game for assuming mem-bership in P2P networks, we primarily consider laptops asthe mobile device in this work.• Metrics: We consider throughput performance as the

main metric in our evaluation and optimization considera-tions. The focus is more on the question: what is the per-formance of a mobile host when it participates in a P2Pnetwork? In addition, we also consider a corollary ques-tion: what is the performance of a fixed peer when it uses amobile host as a peer to download data from?

2.2 BitTorrent

BitTorrent, like other P2P data sharing protocols, usespeers that have downloaded a certain content as the sourcesfor the content subsequently for other peers that need thesame content. In the rest of this section, we outline some ofthe key elements of the BitTorrent protocol relevant to thefocus of this work.• Torrent: Any peer that wants to share a file through

the BitTorrent network creates a “.torrent” file that consistsof some meta data information (e.g. certificates for differentportions of the file that downloading clients can use to checkfor the validity of downloads) and the address of the trackerthat will act as the directory server for the file.• Tracker: The tracker is the entity that maintains, for

any given file that it tracks, all current peers that have the fileeither in its entirety or in parts. When it receives a requestfrom a client for a specific file, it furnishes the client withthe addresses of the peers associated with the file. The listof peer addresses is updated periodically to accommodatepeers leaving the network.• Swarm: All peers currently connected to each other

(logically) in the process of downloading a particular fileform a swarm for that file. From the standpoint of a sin-gle client, it uploads to some members in the swarm anddownloads from some members in the swarm. Because of

Internet

BitSpirit 3.2.215 Azureus 2.3.0.4

BitSpirit 3.2.215

BitSpirit 3.2.215

Azureus 2.3.0.4

Azureus 2.3.0.4

Peer

1…...

Other BitTorrent Peers

Peer

2

Figure 1. Network Testbed for P2P Evaluation

the incentive policy discussed later in this section, a down-loading client is likely to be uploading to a subset of themembers it is downloading from.• Tit-for-Tat: BitTorrent uses a tit-for-tat incentive policy

that controls the upload rate of one peer to another specificpeer based on the download rate the peer enjoys from thatother peer.• Rarest-first fetch: BitTorrent peers do not fetch parts

of the file in sequence. Instead, each peer picks the rarestof the blocks (in terms of the number of peers in the swarmthat have the block) preferably to download. This ensuresthat the rarest blocks of a file are propagated in the swarmfaster, reducing bottlenecks at the few peers that have theblock and increasing the availability of those blocks if thepeers that have them shutdown.• Seeds and leeches: Seeds are peers that have a com-

plete copy of a file, and leeches are peers that have a partialcopy of the file (which typically means that the peers aredownloading other parts as they are uploading the parts theyalready have).

Thus, when a peer wants to download a particular file,it downloads the torrent file, contacts the tracker specified,receives a list of addresses to contact, and joins the swarmfor downloads. As soon as it receives blocks of the file,it also begins uploading to other peers that require thoseblocks. When the entire file is downloaded, the peer maydecide to leave the swarm or stay back as a seed.

3 Motivation3.1 Testbed & Methodology

In this section, we use experiments performed on a Bit-Torrent network to study the performance of a mobile host.We identify several design characteristics of P2P data net-works that are incompatible with typical characteristics ofa wireless environment. We also use the insights gainedas the basis for the design of the wP2P solution presentedlater in the paper. While we present all the discussions inthe context of BitTorrent, we revisit the implications of thediscussions on the other P2P networks at the end of the sec-tion. The network testbed used in the experiments is shown

in Figure 1. The testbed consists of six locally controlledBitTorrent peers which run popular BitTorrent clients: threerun the Azureus client 2.3.0.4 on Linux, and the other threepeers run the BitSpirit 3.2.215 client on Windows.

3.2 Bi-directional TCP

As described in Section 2, most peers in BitTorrent up-load and download at the same time, and because of thetit-for-tat policy used by BitTorrent, several of the uploadsare to peers from which downloads are being done. Hence,it is common for data to be exchanged simultaneously be-tween peers in both directions. Given that BitTorrent (or forthat matter the other P2P applications) uses TCP, and thatTCP is inherently designed to be a bi-directional protocol,BitTorrent uses TCP in its true bi-directional mode. In otherwords, a single TCP connection is used to transfer data inboth directions between the peers.

While TCP is designed to be a bi-directional transportprotocol, few extensive studies of its behavior have beenperformed. More importantly, in the context of this work,very little is understood about the behavior of bi-directionalTCP in a wireless environment. In this context, we identifytwo issues with the use of bi-directional TCP by BitTorrentcentered around the behavior of TCP with respect to ACKpiggybacking and fast-retransmit under bi-directional con-ditions.• Piggybacking: When bi-directional TCP is used,

ACKs in the reverse path are almost always piggybackedon the data packets being sent in the reverse direction. Ina wireless environment, where random errors rates can benon-trivial, this potentially has an adverse impact on theconnection performance. More specifically, when ACKs arepiggybacked on data packets, the effective “length” of theACKs is longer than if they were sent as pure ACKs (non-piggybacked). Hence, for the same bit error rate (BER) in awireless environment, the effective packet error rate (PER)for the ACK traffic is larger. This in turn results in morenumber of ACK packets being lost on the reverse path justbecause they were piggybacked.

While it is true that TCP uses cumulative ACKs, andhence is relatively robust to ACK losses, there still is a neg-ative impact in terms of the overall throughput enjoyed by aconnection in the presence of higher number of ACK losses.More importantly, in a P2P network peers typically have alarge number of TCP connections ongoing even for a singleswarm (BitTorrent trackers typically provide addresses of50 peers in response to a request, but the overall swarm sizecan grow to numbers greater than 500), resulting in the aver-age congestion window size of a TCP connection to be rel-atively small. And, it is for connections with small conges-tion window sizes that a higher ACK loss rate can result ina non-trivial degradation in throughput. In other words, thedownload rate for a TCP connection from a particular peer

0 0.5 1 1.5 2

x 10−5

0

10

20

30

40

50

BER (Bit Error Rate)

Down

load

ing

Thro

ughp

ut (K

Bps) Bi−TCP

Uni−TCP

(a) Throughput comparison

0 1 2 3 4 50

5

10

15

20

25

30

35

Time (Seconds)

Num

ber o

f pac

kets

Buffer dropPackets sent from client

(b) Uni-directional: Packets

0 1 2 3 4 50

5

10

15

20

25

30

35

Time (Seconds)

Num

ber o

f pac

kets

Buffer dropPackets sent from client

(c) Bi-directional: PacketsFigure 2. Impact of Bi-Directional TCP

0 10 20 30 40 50 60 70 80 900

50

100

150

200

250

300

350

Uploading Speed Limit (vs. physical bandwidth (%))

Down

load

ing

Thro

ughp

ut (

KB/s

ec)

(a) Impact of upload: Wired

0 20 40 60 800

50

100

150

200

250

300

350

Uploading Speed Limit (vs. physical bandwidth (%))

Down

load

ing

Thro

ughp

ut (

KB/s

ec)

(b) Impact of upload: Wireless

0 10 20 30 400

20

40

60

80

100

120

140

160

Down

load

ed S

ize (M

B)

Time (Minutes)

No Mobility, UploadingNo Mobility, No UploadingMobility, UploadingMobility, No Uploading

(c) Impact of incentive and mobilityFigure 3. Impact of upload traffic on downloads (a, b), Impact of incentive and mobility (c)

will be smaller just because of ACKs being piggybacked inthe reverse direction.

We set up two peers which hold different portion ofshared data, and obtain the throughput values when eitheruni-TCP or bi-TCP is used. Specifically, when two peershold different data, they exchange data over bi-TCP. Whenonly one peer has the data the other needs, data are down-loaded using uni-TCP. Figure 2 (a) presents the 5-run aver-aged results of the download rate experienced by a peer un-der varying conditions of bit error rate on the wireless leg.Note that bi-directional connections will in general suffer inthroughput when compared to uni-directional connectionsbecause of the self-contention between packets being sentin the upstream and downstream directions. However, thatdifference is captured by the data-point at BER=01.• Fast Retransmit: The second issue with BitTorrent us-

ing bi-directional TCP occurs during congestion. TCP’s fastretransmit mechanism is based on the arrival of DUPACKs(duplicate ACKs) at the sender. When bi-directional TCPis used, TCP specifications stipulate that DUPACKs shouldnot be piggybacked. The reason for this stipulation is thatotherwise the sender has no way of knowing whether piggy-backed DUPACKs are due of losses, or due to the receiversending multiple data packets between two data packet ar-rivals (and hence piggybacking the same ACK sequencenumber on those data packets)2.

1While it might appear that peers are better off not uploading for thisreason, recall that BitTorrent’s tit-for-tat policy will render such a strategyineffective.

2Note that TCP specifications also stipulate that ALL packets exceptthe initial SYN packet has to have the ACK option bit set, and carry a validACK sequence number.

Hence, a TCP receiver will send only pure ACKs whenDUPACKs have to be transmitted due to losses. Whilethis design has no issues in a wired environment, it resultsin problems when performed as-is in a WLAN environ-ment. This is because, when congestion has occurred in theWLAN resulting in a packet drop, the DUPACKs sent backwill be explicitly de-coupled from the data stream in the re-verse path, thus actually increasing the number of packetsin transit on the wireless leg. While it is true that the TCPsender, when it receives the DUPACKs, will reduce its num-ber of outstanding packets in the network by half, the newtransmissions of pure ACKs essentially offsets the decreasein the number data-packets. Hence, as far as the wirelessleg is concerned, the number of packets in transit stays ap-proximately the same even after a congestion event!

Figures 2 (b, c) show the number of packets sent on thewireless leg with time for two BitTorrent connections of atypical run, one uni-directional and one bi-directional re-spectively. The congestion events are indicated in the samefigure (buffer drop) as well. It can be observed that while thenumber of packets on the wireless leg in general decreasesafter congestion events for the uni-directional connection,this is not true for the bi-directional TCP connection. This“mis-behavior” can potentially result in performance degra-dation for the connections due to deviation from the in-tended behavior of TCP’s congestion control.

We have thus far discussed the negative impact of us-ing bi-directional TCP connections. While it is true thatthe above problems will be issues for any application thatuses simultaneous data transfer using bi-directional TCP, itis noteworthy that P2P data networks are perhaps one of

the few instances where such bi-directional data transferdoes happen simultaneously and in large volumes. Applica-tions (or protocols) such as http or secure-shell, while usingbi-directional TCP, do not exercise the bi-directionality thesame way P2P networks do.

3.3 Uploads based Incentives

The tit-for-tat mechanism in BitTorrent encourageshigher rates for uploads to enjoy better download rates. Ina wired environment, it can be shown that peers enjoy theirbest download rates when their upload rates are high. Fig-ure 3(a) shows the aggregate download rate of five simulta-neous tasks as a function of the upload rate limit in a wiredsetting. The upload rate limit is represented as a fraction ofthe physical link capacity3. We observe that the downloadrate is an increasing function of the upload rate limit.

However, for a wireless environment, the relationshipbetween the enjoyed download rate and the upload rate limitchanges. Figure 3(b) shows the aggregate download rate ofthe same five tasks4. As shown, while the download ratesinitially increase with higher upload rates, beyond a muchsmaller upload rate (than 80%) the download rates actuallydrop. This is due to the shared channel nature of the wire-less link, where the uploads and downloads are contendingfor the same wireless channel bandwidth. This is in contrastto a wired setting where the uploads and downloads do notshare the same bandwidth resources. The same figure alsodemonstrates that shutting down the upload rates to zero isnot a solution either as the tit-for-tat strategy of BitTorrentwill kick-in punishing the peer with low download rates.

This problem of uploads contending with the downloadsalso goes beyond the incentives mechanism in BitTorrent.In a wired environment, peers have a relatively low dis-incentive to continue as a seed once the downloads are com-pleted with the argument being that upload bandwidth isanyway largely unused under most conditions except forTCP ACK traffic. However, in a wireless setting, a mobilepeer functioning as a seed can potentially impact its down-load rates for other non P2P applications without any directcounter-benefit for the user. While this contention betweenP2P uploads and other application downloads is true evenwhen the mobile peer is a leech, it can be argued that themobile user is at least receiving the benefit of the tit-for-tatscheme. However, when the peer converts to a seed, thisadvantage no longer remains. Hence, any viable solution tomotivate mobile peers to continue as a seed has to ensurethat the uploads do not negatively affect the downloads ofother applications.

3The network is Comcast Cable High-speed Internet with 4Mbps down-loading rate and 384Kbps upload rate.

4The network is Georgia Tech Wireless LAN 802.11G.

3.4 Incentives and Mobility

The tit-for-tat mechanism in BitTorrent is associatedwith a unique identifier for the peer called the peer-id. Thepeer-id is typically constructed as either a function of theIP address of the host and a random value, or simply as afunction of a mobile host specific random value. The peer-id is regenerated every time fetch tasks are reinitiated. Thuswhen a mobile host experiences a hand-off and receives anew IP address, the ongoing tasks are terminated and thetasks are re-initiated 5 thus generating a new peer-id. How-ever, since the peers track the goodness of correspondingpeers based on the peer-id, this results in the mobile peerlosing all the credit it has built with its corresponding peers.

Figure 3(c) show the effect of incentives on the downloadsize for a 100MB file as a function of time of a typical run.Under the no mobility scenario, we observe that the down-load size is lower when there is no upload traffic. This isthe normal incentive behavior. However when we introducemobility (IP address changes periodically) we see that theincentive mechanism is rendered ineffective. Not only is theactual download size lower than the no-mobility case, thereis marginal difference between the download rates with orwithout uploading. This is because every time the IP ad-dress changes, tasks are re-initiated and thus the host actsas a new peer without any previous incentives. Thus, themobility of a peer can have an adverse impact on the incen-tive mechanism of a P2P network.

3.5 Server Mobility

Peer address updates in BitTorrent happen at the gran-ularity of tens of minutes when a peer goes back to thetracker for an updated set of peers to use in its swarm. Evenwithin that period, the decision on whether to use a peer ornot for downloads is adjusted at the granularity of tens ofseconds. Note that this is understandable in a wired envi-ronment where disconnections of peers may not occur fre-quently. However, when a mobile peer undergoes a hand-off or simply gets disconnected, the fixed peers who wereclients with respect to the mobile peer will continue to tryto reach the mobile peer till either the peer selection algo-rithm chooses an alternate peer or the tracker provides al-ternate addresses or alternate peers (in the order of severalminutes).

Figure 4(a) shows the effect of server side mobility onthe throughput performance for a fixed peer of a typicalrun. The fixed peer is served by three mobile peers. TheIP address of the server is changed every fixed time intervaland the resultant throughput as enjoyed by the fixed peersis observed. We observe that as the time interval between

5We assume here that mobile IP is not used to handle mobility due toits slow deployment.

No Mobility Every 2 Min. Every 1.5 Min. Every 1 Min. Every 0.5 Min.0

50

100

150

200

250

300

Mobility Rate

Thro

ughp

ut (K

Bps)

One peer is mobileAll peers are mobile

(a) Impact of server mobility

0 20 40 60 80 1000

20

40

60

80

100

Downloaded Percentage (%)

Play

able

Per

cent

age

(%)

(b) 5MB file

0 20 40 60 80 1000

20

40

60

80

100

Downloaded Percentage (%)

Play

able

Per

cent

age

(%)

(c) 100MB fileFigure 4. Impact of server mobility (a), Impact of rarest first fetching (b, c)

successive IP change decreases (reflecting higher mobil-ity) the throughput falls. Furthermore, the degradation dueto mobility is amplified when the number of mobile peersamongst the corresponding peers is increased.

3.6 Rarest-first Fetches

As outlined in Section 2, BitTorrent employs a rarestfirst fetching paradigm. This results in any snapshot of thedownloaded content for a file not having any significant “in-sequence” data from the head of the file till a large percent-age of the file download is completed. Many media formats,on the other hand, allow for partial playback of content pro-vided the partial information is in sequence. For example,for an MPEG file of a 2 hour video, the download of the first30 minutes worth of the video will still allow for a playbackof that part of the video. Figures 4(b,c) show the playablefraction of two files being downloaded with increasing frac-tion of the actual downloads using rarest-fetch. The piecelength is the default value of 256 KB, and the results areaveraged over 10 runs. It can be observed that until a largepercentage of the whole file download is complete, a sig-nificant percentage of the file still remains unplayable. Fora 5 MB file, even with a 60% download fraction, less than10% of the file remains playable. In fact, for the 100 MBfile size scenario, more than 90% of the file size needs to bedownloaded to playback the first 2% of the video.

While this property of BitTorrent is an irritant even for afixed peer, it is justifiable for two reasons: (a) this enablesthe peer to contribute well to the P2P network as it is likelyto have blocks that are different from those at other peers;and (b) fixed peers do not have to concern themselves withwireless disconnections thus ensuring that the downloadswill eventually complete and will not be in vain.

However, for a mobile peer, this property can have moreserious implications. In the example of the 100 MB file, ifthe mobile peer gets disconnected from its wireless network(and remains so) after 90% of the file has been downloaded,the user still cannot playback more than 5% of the content.Furthermore, the 90% of the file size downloaded thus farusing the rarest-first algorithm in the interest of the well be-ing of the rest of the P2P network cannot be served back tothe P2P network anyway because of the disconnection!

3.7 Relevance to Other P2P Networks

Thus far, we have investigated properties of the BitTor-rent P2P data network that negatively impact performanceof a mobile peer. While not all the properties discussed thusfar are directly relevant in the context of the other three pop-ular P2P data networks (Gnutella, FastTrack, and eDonkey),a majority of the issues discussed apply. This is especiallytrue for the other third-generation P2P network - eDonkey,where a majority of the above issues still hold true exceptfor the problem with rarest first fetching. For the second-generation P2P networks represented by Gnutella and Fast-Track, a subset of the issues apply including the impactof mobility on incentives, the impact of server mobility,and the impact of uploads on downloads (for other appli-cations).

4 Design and SolutionIn this section, we outline some key design aspects of

the proposed wP2P solution that are targeted to address thelimitations of existing P2P data networks identified in Sec-tion 3. Before we outline the design, we briefly categorizethe different limitations into problem classes where prob-lems within a class all have a common underlying cause.We use the categorization to then position the design ba-sis for wP2P. The limitations identified in Section 3 can becategorized as follows:• Use of bi-directional TCP: While bi-directional TCP

has been in use by other applications such as http or secure-shell, P2P data networks uniquely use bi-directional TCPto transfer large volumes data in both directions simulta-neously. Hence, several quirks of bi-directional TCP thatdo not arise in wireless environments otherwise have to beaddressed.• Failure of incentives: While P2P data networks heavily

rely on incentives based mechanisms to encourage peers tocontribute to the network, such mechanisms are not tailoredfor the unique characteristics of wireless and mobile envi-ronments. Specifically, the problems of upload-downloadself-contention and identity loss after mobility fall underthis category of problems.•Disconnections and fetching: The newest generation of

VariablesCWND: Congestion window of TCP connectionγ: Connection status thresholdSTATUS: Status of the TCP connectionDUPACK CNT : Number of DUPACKs sent by MH

1 Calculate CWND of TCP connections;2 If CWND < γ3 Set STATUS to Y OUNG;4 Else5 Set STATUS to MATURE;6 End If7 Capture TCP packet transmitted by MH;8 If piggybacked ACK and STATUS = Y OUNG9 Decouple ACK from DATA; Send pure ACK;10 If DUPACK and STATUS = MATURE11 DUPACK CNT ++;12 If DUPACK CNT % 4 ==013 Drop DUPACK;

Figure 5. Pseudo-code : Age-based Manipu-lation

P2P data networks use multiple simultaneous fetches fromdifferent peers and fetch blocks in a non-sequential order.While such strategies have obvious benefits in a wired en-vironment, they compromise performance in a wireless set-ting. Problems that fall under this category include lack ofplayable content during disconnections.• Mobile host as a server: Unlike in other applications,

in P2P data networks, the mobile host uniquely functionsas a server that can be accessed by other peers. Hence,several problems attributed to wireless and mobile environ-ments that can be (and have been) solved or do not existwhen the mobile host acts only as a client either have to besolved differently or arise newly.

In the rest of the section, we present the design basisfor wP2P in the form of three principles that address theabove four categories of problems. One key property of allthe principles we present is that they are mobile host onlychanges that do not require any support from the fixed peers,and are fully backward compatible with already existingversions of the P2P (BitTorrent) protocols. Also, we presentany specific implementation details with respect to the Bit-Torrent protocol. However, all the solutions presented arepurely local to the mobile host and backward compatibleto all existing BitTorrent P2P client applications on fixedpeers.

4.1 Age-based performance optimization

The bi-directional TCP problem arises because of spe-cific quirks of the TCP design and how they relate to thewireless environment. However, at the same time, bi-directional TCP’s performance otherwise is desirable sinceit eliminates ACK overheads under normal conditions. Inother words, the solution to the problems with bi-directionalTCP is not to switch back to dual unidirectional TCP con-

nections as that would render the overall performance worsethan when using bi-directional TCP as pure ACKs in bothdirections consume precious bandwidth resources.

In this context, the Age-based Manipulation (AM) de-sign principle of wP2P involves the adaptive manipula-tion of the bi-directional TCP connections for better perfor-mance. Essentially, recalling the discussion on ACK lossrates in Section 3, an argument can be made that TCP’sthroughput performance is vulnerable to ACK losses onlywhen the congestion window is small. At larger congestionwindows, the higher ACK loss rates do impact progress,but not significantly. Hence, under age-based manipulation,explicit conversion of piggybacked ACKs to pure ACKs isperformed when the connection congestion window (cwnd)is small6 and piggybacked ACKs are let through as-is whenthe congestion window is larger than a threshold7.

Similarly, the use of pure ACKs during fast retransmitand the associated wireless link overload is addressed bythrottling the number of packets down explicitly such thatthe total number of packets, including the pure DUPACKs,outstanding amounts to half the number of outstandingpackets before the congestion detection. This is performedby explicitly dropping one-fourth of the DUPACKs in thereverse path during the first round-trip time after the firstDUPACK is generated. For example, if the cwnd is 100on congestion detection (assume one packet loss), 99 DU-PACKs will be generated by the receiver. If one-fourth ofthe DUPACKs are dropped, approximately 24 DUPACKswill be dropped resulting in 75 DUPACKs reaching thesender. The sender, when it performs fast retransmit andfast recovery, will thus send out 25 ((100/2)+75-100) newpackets. Thus, even if the 25 new packets generate 25 pureDUPACKs (assuming the receiver still is in loss recovery),that amounts to a total of 50 total packets equalling half ofthe number of packets outstanding before congestion detec-tion.

The pseudo-code for the AM component of wP2P so-lution is listed in Figure 5. First the AM component con-stantly monitors the congestion window of the TCP con-nection and if the current connection congestion window isless than a specified threshold value γ (set to 6 in our eval-uations as suggested in [10]), the connection status is set toYOUNG (Line 3). If the congestion window is greater thanthe threshold γ, the connection status is set to MATURE(Line 5). The AM component also maintains state about theTCP connection and captures TCP packets transmitted bythe mobile host. If the connection status is YOUNG, the AMmodule conveys any new ACK information piggybacked onDATA packets transmitted by the mobile host as separate

6Note that although this manipulation is done at the receiver, standardtechniques exist to track the sender congestion window at the receiver.

7A straightforward value for the threshold is 6 as it can be shown thatcongestion windows less than 6 are highly vulnerable to losses in eitherdirection [10].

VariablesUmax: Maximum upload limitUcur , Uprev : Current, previous upload stateDcur , Dprev : Current, previous download stateα, β: Upload increment and decrement factorUdec cnt: Upload decrement count

Initialization1 Ucur = Uprev = 0.5*Umax;2 Dcur = Dprev = 0; Udec cnt = 0;Update3 Determine current P2P download rate and store;4 If Dprev <> 05 If Dprev < Dcur

6 Ucur = Ucur + α; Udec cnt = 0;7 Else8 Increment Udec cnt; Ucur = Ucur − β ∗ Udec cnt;

Figure 6. Pseudo-code : Incentive-Aware Op-erations

pure ACKs (Line 9). This achieves better robustness forthe ACKs given a finite error rate in the wireless channel.The AM component also detects losses experienced by theTCP connection and performs the following operation dur-ing loss recovery. If the status of the connection encounter-ing loss is MATURE, the AM module drops one DUPACKevery four DUPACKs (Line 13).

4.2 Incentive-Aware operations

The problem of failure of incentives stems from the twodistinct conditions of the self contention in a wireless linkand mobility related identity loss. The Incentive-Aware op-erations (IA) principle in wP2P is used to address bothproblems. Essentially, one technique under incentive awareoperations in wP2P involves the adaptation of the uploadrate in order to find the smallest upload rate possible toachieve the maximum download rate. While this value forthe upload rate is trivial to determine in a wired setting, amore sophisticated algorithm is required in a wireless envi-ronment.

Since a wireless host uses a shared channel, the uploadand download traffic contend with each other and hence in-creased uploads might reduce the downloads possible. Inorder to strike the optimal balance between the two compet-ing issues (incentives and self-contention) wP2P performs aLinear Increase History-based Decrease (LIHD) algorithmthat adapts the uploading rate to an optimal value. The intu-ition behind the LIHD algorithm is that while increasing theupload rate, it is better to be conservative so that the mobilehost does not upload more than necessary. At the same timewhile reducing the uploads it is desirable to be aggressive.LIHD hence increases upload rates linearly when there isa positive correlation between the uploads and downloads,while decreasing the upload rates with increasing aggres-siveness when decreasing the uploads does not cause a de-crease in the downloads.

The Incentive-Aware (IA) component monitors uploadand download rates achieved by the P2P application. TheIA component uses window-averaged throughputs to deter-mine the upload rate control of the P2P application. It con-trols the upload rate in a way as to optimize the downloadsachieved by the mobile host. While the incentive mecha-nism requires a peer to upload as much data as possible, thewireless connection restricts the amount of uploads in or-der to maximize the downloads. Thus in order to achieveoptimal performance we need to operate at the peak of Fig-ure 3(b). If the download rate in the current time windowis greater than the download rate achieved in the preced-ing time window, then the IA component increments theupload-rate counter (Line 6 in Figure 6). On the other hand,if the download rate in the current time window is less thanthe previously recorded download rate, then the upload ratecounter is decremented by a value proportional to the num-ber of consecutive cutdowns of the upload rate (Line 8 inFigure 6). This procedure achieves the optimal trade-offbetween incentive driven P2P downloads and wireless con-tention of the uplink and downlink transmissions.

LIHD can also be used for controlling the rate of up-loads when the mobile peer becomes a seed, such that theuploads do not impact negatively any of the downloads be-ing performed by other non-P2P applications on the mobilepeer. We do not consider this aspect of the mechanism inthis paper, and leave it for future work.

Another technique wP2P uses that falls under this designprinciple is identity retention across hand-offs and withinthe same swarm. The rationale for generating uniquely dif-ferent peer-ids in BitTorrent is to be able to identify anddistinguish between clients with the same IP address (say,if the clients are behind a NAT), but at the same time con-fine the benefits of incentives accumulated by a peer to onlythat swarm in which the peer contributed. Since the typicalscenario for task initiation in wired environments is when apeer wants to download another data file, generating a newpeer-id is reasonable. However, in mobile environmentstask re-initiations can occur just because IP addresses havechanged. wP2P, in this context, performs identity retentionwithin a swarm, whereby even when task re-initiation is per-formed, as long as it is for a swarm the mobile peer was amember of before, the old peer-id is retained. This enablesthe mobile peer to leverage its previously accumulated in-centives. Thus, IA component stores the peer ID of the mo-bile host when the application is started and when there isIP layer handoff, the IA component restores the stored peerID to maintain incentives.

4.3 Mobility-Aware operations

In Section 3 we observed how in a mobile peer (as aclient) mobility can impact the performance of downloadsin BitTorrent. In this context, wP2P uses a Mobility-Aware

operations (MA) principle to deal with the problems associ-ated with mobility. MA consists of two techniques, namelyMobility-aware Fetching and Role Reversal.• Mobility-aware fetching (MF): This technique explic-

itly controls how data is fetched. The mechanism is that ofexponentially increasing altruism or exponentially decreas-ing selfishness. Essentially, a mobile peer fetches blocks insequence with a probability ps (=1 − pr), and fetches therarest-first block with a probability pr. This probability Pr

is a function of the network stability of the mobile host asmeasured by the amount of time elapsed since the last net-work disconnection of the mobile host (or the start of thedownload). During the initial phases of the download, themobile peer uses a small value (say, 20%) for pr, and expo-nentially increases pr as it downloads increasing fractionsof the total file.

The rationale for this design is as follows: during theinitial stages of downloads, if the mobile host gets discon-nected, there is no benefit due to the rarest-fetch mecha-nism either for the mobile host (in terms of playability) orto the P2P network (in terms of availability). Hence, it ismore desirable to fetch sequentially. However, as the mo-bile host stays connected for a longer period of time, itsutility to the P2P network has more stability and hence itis more meaningful to have available rare blocks. Further-more, if the mobile host now gets disconnected, the user stillhas a considerable portion of the data in-sequence for play-back. Thus, This mobility-aware adaptive content fetchingachieves a more desired tradeoff between sequential contentavailability for disconnected usage of content and usabilityof content for other peers to download.• Role Reversal (RR): The mobile host as a server prob-

lem primarily impacts connections when the mobile hostmoves and hence undergoes an IP address change. In thiscontext, the role reversal technique involves the mobile hostswitching its role to that of a client to address the aboveproblems. Note that the fact that a mobile host switches toacting as a client will not have any impact on the mobilehost still serving content to the peers it connects to as peerscan serve traffic irrespective of whether or not they initiatedthe connection.

RR technique of MA component monitors the IP ad-dress of the wireless interface. If it detects a change inthe IP address, RR will: (i) stores all the correspondingpeers with which P2P TCP connections have been estab-lished, (ii) transmits application termination messages to allthe stored peers, and (iii) issues application setup messagesto the stored peers.

4.4 Integrated Operations

For a particular connection, all the three components ofthe wP2P framework work in tandem to achieve optimalperformance. We can classify the operation of the compo-

nents with respect to the different periods of the P2P con-nection, as illustrated in Figure 7. After the connection issetup, Age-based Manipulation component kicks in duringearly stages of the connection. It also works during con-gestion recovery periods and after reconnection in case ofmobility. The operations of the Incentive-Aware componentare performed during steady-state of the TCP connections.Finally, the Mobility-Aware operations component is activeduring the steady-state period of the TCP connection andalso after IP address change due to reconnection.

Connection

Setup

Age-based

Manipulation

Congestion

Age-based

Manipulation

Mobility-aware Operations

Mobility

HandoffRe-Connect

Age-based

Manipulation

Incentive-aware Operations

Mobility-aware Operations

Incentive-aware Operations

Time

Figure 7. Integrated operations

5 Evaluation5.1 Implementation

We use a prototype implementation of wP2P that is builtas an enhancement to the CTorrent client version 1.2 [2].CTorrent is a lightweight C++ implementation of BitTor-rent protocol with about 10K lines of code. All the threecomponents of wP2P are implemented by modifying thesource code of CTorrent and adding a separate modulewhich works with a packet filtering utility widely avail-able in Linux distributions. In particular, the Incentive-Aware Operations and Mobility-Aware Operations compo-nents are implemented by directly modifying the CTorrentsource code, and the Age-based Manipulation component isrealized with the assistance of Netfilter utility [3]. We nowdescribe the network setup of our implementation followedby descriptions of the three individual wP2P components.• Network Setup: We use two wireless clients on a

popular BitTorrent network to compare the performancesof wP2P with a default version of BitTorrent. One of theclients has the modified CTorrent version and the other hasa plain vanilla version of the CTorrent (we call this as thedefault client). Linux machines connected to the Internetthrough ns-2 based wireless emulators are used for the twoclients. An illustration of the network setup is shown inFigure 10. We use ns-2 emulation to study the impact ofvarious issues of wireless environments like random wire-less losses, mobility and bandwidth. We emulate randomwireless losses using random bit errors. We emulate mo-bility by changing the IP addresses of the clients using the“ifup/ifdown” commands in Linux. We also monitor thebandwidth consumed at each client to enforce bandwidthlimitations.

• Age-based Manipulation: The operations of this com-ponent require the determination of age of the connection.The determination is based on the measurement of currentcongestion window. Since the information of congestionwindow typically is not available to the application itself,the realization of this component has to obtain such infor-mation from certain networking entities. Specifically, wechoose Netfilter utility to assist the implementation of thecomponent partly due to its wide deployment in Linux dis-tributions. A module in the user space keeps track of theamount of data sent by the remote peer in every round triptime (rtt), and uses the current value as an estimate of thatpeer’s TCP congestion window for the next rtt. We chosea congestion widow of size 9k bytes (approximately 6 fullpackets) as an indicator of the age of the flow. If the windowsize is less than the threshold, the connection is consideredto be young, and TCP ACKs are decoupled from the datapackets. Otherwise, the connection is set as mature, and thepackets are sent as such without modifications.

• Incentive-Aware Operations: This component em-ploys two techniques: identity retention and Linear IncreaseHistory based Decrease (LIHD) rate control. For the firsttechnique a static peer ID is used in lieu of a randomly gen-erated peer ID every time the IP address changes. For thesecond technique we modify CTorrent’s in-built capabilityto control upload and download limits. The default CTor-rent client allows uses to specify the upload and downloadslimits. We modify it to allow the adaptive LIHD rate controlalgorithm described in the previous Section. We use band-width monitors to check the current upload and downloadrates for the algorithm.

•Mobility-Aware Operations: The basic CTorrent clientdoes not implement the rarest first fetching algorithm com-monly used by BitTorrent clients. Hence we first implementthe rarest first fetching algorithm for the default client. Wethen modify this algorithm to include sequence informationand awareness of download progress. Specifically as de-scribed in Section 4, at the start of the download higherprobability is given for low sequence numbered pieces asopposed to high sequence numbered ones. As the downloadprogresses, the default rarest first search algorithm gainsprominence. The Role reversal technique aids in fast recov-ery from disconnections caused by mobility. Change of IPaddresses induced by mobility will render all existing con-nections unusable thus making the BitTorrent client lose alllive peers. The wP2P client monitors the number of livepeers, and infers mobility by the lack of any live peer. Oncemobility is detected, the client will immediately attempt tobuild new connections to remote peers to resume servingdata.

Internet

C2

P1

Pn

…...

Default

Ctorrent Client

BitTorrent

Peers

C1

wP2P

Ctorrent Client

P2

Wireless

Emulator

Wireless

Emulator

Figure 10. Testbed used in evaluation

5.2 Evaluation of wP2P

We now look at the effectiveness of the specific mecha-nisms employed by wP2P to address the limitations of de-fault BitTorrent clients in wireless environments.

5.2.1 Use of Bi-directional TCPwP2P addresses the problems of Bi-directional TCP inwireless environments using the AM component. We studythe impact of this component under varying random lossconditions emulated by varying the BERs ranging from1e − 6 to 1.5e − 5. Initially we setup a single seed fora 100MB file and use the two CTorrent clients as leeches.We allow each of the leech to initially download about 50%from the seed (and the other leech). We then remove theseed so that any further data transfer is just between the twoleech peers.

We compare the download rates observed by the twoleech peers for five runs and show the averaged results inFigure 8(a). We observe that wP2P outperforms the defaultCTorrent under all bit error rates because decoupling ACKsresult in smaller ACK losses for the connection, and in turn,larger throughput. Specifically, with all the four BER val-ues, wP2P achieves about 20% more throughput.

5.2.2 Failure of IncentivesAs discussed in the previous Section identity retention andLIHD rate control address the issue of failure or loss ofincentives. To evaluate identity retention we use the twoCTorrent clients to simultaneously download a Fedora-7-KDE-Live-i686.iso (http://torrent.fedoraproject.org/) im-age, a 688MB file shared among more than two hundredspeers when our experiments were conducted. The IP ad-dresses of the two clients are changed every one minute toemulate mobility. Figure 8(b) shows the total downloadedsize of a typical run for these two peers. The downloadedsize is plotted as a function of time. For the default clientwhenever incentives are lost the download rate is reset tothe initial nominal value unlike in wP2P where the incen-tives are maintained. Hence we find a higher downloadsfor wP2P compared to the default for the same time. After50 minutes of download we observe that wP2P downloadedabout 100MB more than the default.

1.0e−6 5.0e−6 1.0e−5 1.5e−50

5

10

15

20

25

30

35

Bit Error Rate

Thro

ughp

ut (K

Bps)

Default P2PwP2P

(a) Age-based manipulation

0 10 20 30 40 500

100

200

300

400

500

Downloading Time (Minutes))

Down

load

ed S

ize (M

B)

Default P2PwP2P

(b) Maintaining peer ID

50 100 150 2000

20

40

60

80

100

Physical Wireless Bandwidth (KBps)

Down

load

ing

Thro

ughp

ut (K

Bps) Default P2P

wP2P

(c) LIHDFigure 8. Age-based manipulation (a), Incentive-aware operations (b, c)

0 20 40 60 80 1000

20

40

60

80

100

Downloaded Percentage (%)

Play

able

Per

cent

age

(%)

Default P2PwP2P

(a) Mobility-aware Fetching (5 MB)

0 20 40 60 80 1000

20

40

60

80

100

Downloaded Percentage (%)

Play

able

Per

cent

age

(%)

Default P2PwP2P

(b) Mobility-aware Fetching (100 MB)

Every 6 Min. Every 4 Min. Every 2 Min.0

5

10

15

20

25

Mobility Rate

Uplo

adin

g Th

roug

hput

(KBp

s)

Default P2PwP2P

(c) Role-reversalFigure 9. Mobility-aware Fetching (a, b), Role reversal (c)

To evaluate the benefits of LIHD we vary the bandwidthof the wireless emulator from 50KBps to 200KBps. Figure8(c) shows the averaged results over 10 runs for the casewhen α = β = 10KBps (refer to Section 4 for defini-tions of α and β). We observe that, initially as the availablebandwidth increases both wP2P and the default client showincreased download throughputs, but beyond a certain pointthe default client starts losing achieved throughput. Witha bottleneck bandwidth of 200KBps we observe that wP2Poutperforms the default by as much as 70%.

5.2.3 Disconnections and FetchingFigures 9 (a) and (b) show the results of the Mobility-AwareFetching technique for different file sizes of the content be-ing downloaded and compare them against the default rarestfirst fetch algorithm. The results are averaged over 20 runs.In these experiments we set the value of pr (the rarest firstfetching probability) to be equal to the downloaded percent-age of file. Figure 9(a) shows the result of a 5 MB file.We observe that MF can achieve significantly better perfor-mance compared to the default. For instance when 50%of the data has been downloaded, MF can result in about30% of playable content while the default rarest first tech-nique can achieve only about 5%. The improvements areeven more prominent when the file size increases (20% asopposed to only 0.5% for the same 50% download).

5.2.4 Mobile host as a serverTo evaluate the role reversal technique we setup two mo-bile seeds in the above mentioned swarm(for the Fedora-7-KDE-Live-i686.iso image). Again we emulate mobility

by changing IP address. Figure 9(c) shows the 10-run av-eraged uploading throughput of the two clients with differ-ent disconnection rates (i.e., rate of change of the IP ad-dress). As the rate of connection disruptions increases theupload throughput naturally drops. The role reversal tech-nique of wP2P allows the client to achieve far more up-load rates when compared to the default client. We observethat with increasing rate of disruptions the performance im-provement of wP2P is higher. This is because when thereare frequent disruptions, the re-establishment time for de-fault P2P becomes a significant factor, whereas in wP2Pthe re-establishment time is reduced. We observe improve-ments of up to 50% in wP2P when connections are dis-rupted every 2 minutes.

6 Related WorkP2P Enhancements: There are several works in related

literature that propose to improve performance in P2P sys-tems. Among them, there is a significant amount of workthat focuses on incorporating better incentive schemes toencourage cooperative behavior and penalize free riders.Reputation based trust systems ([18] [7] [13]) and key shar-ing protocol ([21]) are works in this category and these worktry to prevent non-contributing nodes from gaining unde-served benefits from the system. Other work ([19], [14])design mechanisms to generate unique peer IDs that fea-ture desired properties. Some work ([15, 4, 12]) analyze theperformance characteristics of the BitTorrent protocol. Incomparison with these works, our work is focused on theunique challenges arise as mobile hosts join the p2p net-works. These challenges are not seen in fixed hosts andin wired networks. For instance, we deal with the incen-

tive loss problem experienced by mobile hosts instead ofproposing a new incentive mechanism.

Recently more and more p2p users go mobile and areconnected with wireless links. The authors in [9] analyzethe traffic pattern of a well established 802.11 WLAN net-work and show that P2P traffic including P2P data sharingand streaming has increased dramatically. The authors in[6] propose a cross-layer optimization of Gnutella for de-ployment in purely mobile ad hoc networks. Our work onthe other hand looks at the effect of mobile peers on an ex-isting P2P network.

Other Related Work: [20] addresses the issue of mobilityin an ongoing transport connection by providing transparentnetwork connection mobility using reliable sockets (rocks)and reliable packets (racks). [8] designs a mobility-awarefile system for partially connected operation. Specifically,it allows applications to maintain consistency on only thecritical portions of its data files. In [11] the authors designan algorithm to select a new resource provider for mobilepeers when mobility disconnects remote peers. In compar-ison, our work looks at issues faced by generic P2P datasharing applications on mobile hosts, identifying a varietyof challenges that arise when mobile hosts join the P2P net-works and act as P2P server.

7 ConclusionsIn this paper we investigated the issues with using mobile

hosts as peers in a P2P network. We identified several in-sights into the issues such hosts face using a real-life BitTor-rent P2P data network. We proposed a solution called wP2Pthat significantly improves performance and also evaluatedthe solution using a real life implementation as an extensionof the CTorrent client.

References

[1] BitTorrent. http://www.bittorrent.org/.

[2] Enhanced CTorrent, a lightweight C++ implementa-tion. http://www.rahul.net/dholmes/ctorrent/.

[3] Netfilter project. http://www.netfilter.org/.

[4] A. Bharambe, C. Herley, and V. Padmanabhan. Under-standing and deconstructing bittorrent performance.In ACM SIGMETRICS 2005.

[5] CacheLogic, http://www.cachelogic.com/home/pages/research/p2p2005.php. Peer-to-Peer in 2005, 2005.

[6] M. Conti, E. Gregori, and G. Turi. A cross-layer op-timization of gnutella for mobile ad hoc networks. InMobiHoc ’05, pages 343–354, 2005.

[7] C. Dellarocas. Immunizing online reputation report-ing systems against unfair ratings and discriminatory

behavior. In EC ’00: Proceedings of the 2nd ACMconference on Electronic commerce, pages 150–157,New York, NY, USA, 2000.

[8] D. Dwyer and V. Bharghavan. A mobility-aware filesystem for partially connected operation. ACM Oper-ating Systems Review, 31(1):24–30, Jan. 1997.

[9] T. Henderson, D. Kotz, and I. Abyzov. The changingusage of a mature campus-wide wireless network. InMobiCom ’04, pages 187–201, New York, NY, USA,2004.

[10] H.-Y. Hsieh, K.-H. Kim, and R. Sivakumar. Onachieving weighted service differentiation: An end-to-end perspective. In Proceedings of IEEE InternationalWorkshop on Quality of Service (IWQoS), 2003.

[11] C.-M. Huang, T.-H. Hsu, and M.-F. Hsu. A file discov-ery control scheme for p2p file sharing applications inwireless mobile environments. In ACSC ’05: Proceed-ings of the Twenty-eighth Australasian conference onComputer Science, pages 39–47, 2005.

[12] A. Legout, N. Liogkas, E. Kohler, and L. Zhang. Clus-tering and sharing incentives in bittorrent systems. InACM SIGMETRICS 2007.

[13] Q. Lian, Z. Zhang, M. Yang, B. Y. Zhao, Y. Dai, andX. Li. An empirical study of collusion behavior in themaze p2p file-sharing system. In IEEE ICDCS, 2007.

[14] L. Lu, J. Han, L. Hu, J. Huai, Y. Liu, and L. M. Ni.Pseudo trust: Zero-knowledge based authentication inanonymous peer-to-peer protocols. In IPDPS, 2007.

[15] D. Qiu and R. Srikant. Modeling and performanceanalysis of bit torrent-like peer-to-peer networks. InACM SIGCOMM 2004.

[16] Ringtonia, http://www.ringtonia.com/. Melodeo’s mo-bile phone P2P to launch.

[17] Roadcasting, http://www.roadcasting.org/. A new typeof radio.

[18] M. Srivatsa, L. Xiong, and L. Liu. Trustguard: coun-tering vulnerabilities in reputation management fordecentralized overlay networks. In WWW ’05, 2005.

[19] K. Wei, Y.-F. Chen, A. J. Smith, and B. Vo. Whopay:a scalable and anonymous payment system for peer-to-peer environments. In IEEE ICDCS, 2006.

[20] V. C. Zandy and B. P. Miller. Reliable network con-nections. In MobiCom ’02, 2002.

[21] Z. Zhang, S. Chen, and M. Yoon. March: A distributedincentive scheme for peer-to-peer networks. In IEEEINFOCOM 2007, Anchorage, Alaska, USA, 2007.