Mobile Hosts Participating in Peer-to-Peer Data Networks: Challenges and Solutions

Noname manuscript No.
(will be inserted by the editor)
Mobile Hosts Participating in Peer-to-Peer Data
Networks: Challenges and Solutions
Zhenyun Zhuang†
· Sandeep Kakumanu†
· Yeonsik Jeong‡
· Raghupathy
Sivakumar†
· Aravind Velayutham§
Received: date / Accepted: date
Abstract Peer-to-peer (P2P) data networks dominate
Internet traffic, accounting for over 60% of the over-
all traffic in a recent study. In this work, we study the
problems that arise when mobile hosts participate in
P2P networks. We primarily focus on the performance
issues as experienced by the mobile host, but also study
the impact on other fixed peers. Using BitTorrent as a
key example, we identify several unique problems that
arise due to the design aspects of P2P networks be-
ing incompatible with typical characteristics of wire-
less and mobile environments. Using the insights gained
through our study, we present a wireless P2P (wP2P)
client application that is backward compatible with ex-
isting fixed-peer client applications, but when used on
mobile hosts can provide significant performance im-
provements.
Keywords Mobility · Wireless Networks · Peer-to-
peer
1 Introduction
Over the last few years, peer-to-peer (P2P) data sharing
applications have experienced an explosive growth. In
recent years, a staggering 60% of the Internet data traf-
fic constituted of P2P file sharing [1]. While copyright
† Zhenyun Zhuang, Sandeep Kakumanu, Raghupathy Sivakumar
Georgia Institute of Technology, Atlanta, USA,
E-mail: {zhenyun, ksandeep, siva }@ece.gatech.edu
‡ Yeonsik Jeong
SungKongHoe University, Seoul, Korea,
E-mail: ysjeong@skhu.ac.kr
§ Aravind Velayutham
Asankya Inc., Atlanta, USA,
E-mail: vel@asankya.com
concerns had earlier brought down popular P2P ap-
plications such as Napster, several content owners and
providers have of late started embracing new types of
P2P technology that have come to stay [2]. P2P data
sharing is now not only being considered as a means
for consumer level data exchange, but also as a viable
means of delivering data from professional content pro-
ducers to their consumers ([3–5]). Hence, the dominance
of P2P traffic in the Internet is expected to continue to
grow in the near future.
With P2P data sharing applications securing a dom-
inant position in the Internet landscape, a natural ques-
tion to ask is: what is the performance of mobile users
when participating in P2P data sharing? The question
is significant because of the following two reasons. First,
as with any Internet application with emerging or es-
tablished popularity, wireless and mobile users are in-
creasingly adopting P2P data sharing applications on
devices such as laptops and PDAs [6]. With the number
of users using wireless technologies for Internet access
growing rapidly, it is inevitable that P2P data sharing
over wireless and mobile environments will assume sig-
nificance. Second, there are several efforts underway to
deliver P2P data sharing as the next killer application
for mobile devices ([7,8]). Initial instantiations of such
efforts focus on sharing of ring-tones and music files,
but are expected to evolve into other types of content
including video. Thus, in both contexts, it is important
to consider what levels of performance such users will
enjoy, and investigate the match-ups between the typ-
ical designs of P2P data sharing applications and the
characteristics of wireless and mobile environments.
Thus, in this work, we first investigate the following
question: what is the performance of a mobile user in a
wireless environment using a P2P data sharing appli-
cation? As a corollary, we also investigate the following

2
question: what is the performance of a fixed peer in a
P2P network when using a mobile host as a correspond-
ing peer? In answering the above questions, we find
that several of the fundamental design principles and
peculiarities used in P2P data sharing applications are
inconsistent with the key limiting characteristics of typ-
ical wireless and mobile environments. Briefly, some of
these issues include: (i) P2P applications, unlike in typ-
ical scenarios where a mobile host functions as a client,
create a scenario requiring the mobile host to function
as a server. This raises several implications including
mobility and Power Save Mode (PSM) on server sides.
(ii) P2P data sharing uniquely involve simultaneous bi-
directional data transfer. This consequently results in
the use of bi-directional TCP, a form of TCP not stud-
ied extensively for wireless environments. (iii) P2P data
networks, by virtue of being almost entirely supported
by end-hosts, typically use incentive-based performance
delivery. Because of this, a mobile host that has up-
loaded more data is provided with higher performance.
Such a mechanism exposes issues when applied as-is to
a wireless and mobile environment. (iv) While incen-
tives encourage P2P users to stare data longer, P2P
data fetching is also adapted to increase the uniquely
shareable data available at a user. One such approach
is performing random or rarest-first fetching. However,
such techniques have severe implications to the mobile
user, especially during disconnections. With a real-life
P2P data sharing network, we study the performance
of mobile users with respect to the above issues.
Using insights gained through the aforementioned
study, we present a deployable solution suite called wP2P
that addresses the issues by only changing the P2P
application at the mobile host. wP2P uses techniques
transparent to the fixed peer, but uniquely relevant
to the specific issues pertaining to wireless and mobile
hosts functioning in a P2P data network. Specifically,
wP2P uses a combination of four design principles in-
cluding Age based Manipulation, Incentive Aware oper-
ations, Mobility-aware Fetching, and Role Reversal. We
evaluate the effectiveness of wP2P through both simu-
lations and prototyping, and the evaluations show that
significant throughput performance improvements can
be achieved for mobile hosts and fixed peers, when us-
ing wP2P at the mobile hosts. Thus, the contributions
of this work are twofold:
• We consider the specific scenario of mobile hosts
participating in P2P data sharing networks, and inves-
tigate performance issues such hosts face due to the
unique design elements embedded in typical P2P ap-
plications. Using real-life P2P experiments, we iden-
tify these design elements that when combined with the
unique characteristics of wireless environments render
the performance delivered to mobile users sub-par.
• We present a deployable solution called wP2P
that is required to be instantiated only at the mo-
bile host and can deliver enhanced P2P data sharing
performance to mobile users. Using a prototype imple-
mentation, we characterize the performance of wP2P
and show that considerable improvements can indeed
be achieved.
The rest of the paper is organized as follows: Sec-
tion 2 presents the scope of this work and describes key
background material. Section 3 presents in detail the
motivation results that show the limiting performance
that existing P2P application design imposes on mo-
bile users. Section 4 presents the key design principles
of wP2P and the realizations of the principles. Sections
5 presents the evaluation results with both simulation
and prototype implementation. Finally, Section 6 dis-
cusses related work and Section 7 concludes the work.
2 Background and Scope
In this section, we describe the scope of this work, as
well as the necessary backgrounds of P2P networks.
2.1 Scope of this work
• P2P Networks: While there are several forms of
P2P networks ranging from those that help in comput-
ing (e.g., grids) to those that help in communication
(e.g., Skype) to those that help in data-sharing, this
work is entirely focused on P2P data sharing networks.
Data sharing P2P networks are primarily used for shar-
ing files containing audio (e.g., mp3 files), video (e.g.,
mpeg2 files), or data (e.g., Linux distributions). Ex-
amples of such networks include BitTorrent [2], eDon-
key [9], Gnutella [10], and FastTrack [11]. Interestingly,
the above four example networks account for almost all
the P2P traffic in the Internet and together constituted
more than 60% of the Internet traffic in recent studies
[1]. Specifically, traffic carried using BitTorrent account
for over 30% of the overall Internet traffic. Also, video
files account for more than 62% of P2P traffic.
In this work, while we identify characteristics 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 tri-
als. However, as necessary we also step back and investi-
gate relevance of our discussions and interpretations for
the other networks as well. We believe that this choice of
BitTorrent as the key representative is justifiable from
multiple standpoints including its dominance in terms

3
of traffic carried, and its relative sophistication. Exam-
ple (and popular) clients that implement BitTorrent are
Linux-based Azureus and Windows-based BitSpirit.
• Data Types: While BitTorrent is primarily used
for sharing video files that are large in size (e.g., few
hundreds of megabytes or more), a non-trivial amount
of its traffic also includes audio (e.g., few megabytes or
more) and software distribution. Hence, in this work,
we consider file data sizes that represent both ends of
the above spectrum.
• Wireless Technologies and Mobile Devices: Mea-
surement studies conducted recently (such as [6]) ob-
serve far more wireless and mobile users on the net-
work than ever before. While mobile users with any
type of wireless access can participate in P2P networks,
the access technology typically used is wireless LANs
(WLANs). This is because of both the higher band-
widths available on WLANs, and the relatively lower or
no-cost models associated with such networks. Hence,
we consider WLANs for the wireless environment in
this paper. However, we revisit this assumption later
in the paper to discuss implications of our inferences
and proposed strategies for other types of wireless envi-
ronments. Similarly, while other mobile devices such as
PDAs and IP-enabled cell phones become more prac-
tical for assuming membership in P2P networks, we
primarily consider laptops as the mobile device in this
work.
• Metrics: We consider throughput performance
as the main metric in our evaluation and optimization
considerations. While the focus is more on the ques-
tion: what is the performance of a mobile host when
it participates in a P2P network? We also consider a
corollary question: what is the performance of a fixed
peer when it uses a mobile host as a peer to download
data from?
2.2 BitTorrent
BitTorrent, like other P2P data sharing protocols, uses
peers that have downloaded a certain content as the
sources for the content subsequently for other peers that
need the same content. Any peer that implements the
BitTorrent protocol can participate in a BitTorrent net-
work. We now outline some of the key elements of the
BitTorrent protocol that are relevant to the focus of
this work.
• Torrent file: Any peer that wants to share a file
through the BitTorrent network creates a “.torrent” file
that consists of some meta data information (e.g., cer-
tificates for different portions of the file that download-
ing clients can use to check for the validity of down-
loads) and the address of the tracker that 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 file either in its entirety or in parts. When
it receives a request from a client for a specific file,
it furnishes the client with the addresses of the peers
associated with the file. The list of peer addresses is
updated periodically to accommodate peers leaving and
joining the network. Since peers download parts of the
file out of sequence, two peers that start downloading
at approximately the same time can still provide data
to each other quickly.
• Swarm: All peers currently connected to each other
in the process of downloading a particular file form a
swarm for that file. From the standpoint of a single
client, it uploads to some members in the swarm and
downloads from some members in the swarm. Because
of the incentive policy discussed later in this section, a
downloading client is likely to be uploading to members
it is downloading from.
• Tit-for-Tat: BitTorrent uses a tit-for-tat incentive
policy that controls the upload rate of one peer to other
peers based on the download rate the peer enjoys from
that other peer.
• Rarest-first fetch: BitTorrent peers do not fetch
parts of the file in sequence. Instead, each peer picks
the rarest of the blocks (in terms of the number of peers
in the swarm that have the block) preferably to down-
load. This ensures that the rarest blocks of a file are
propagated in the swarm faster, reducing bottlenecks
at the few peers that have the block and increasing the
availability of those blocks if the peers that have them
shutdown.
• Seeds and leeches: Seeds are peers that have a
complete copy of a file, and leeches are peers that have
a partial copy of the file, which typically means that the
peers are downloading other parts as they are uploading
the parts they already 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 swarm for downloads. As soon as it receives
blocks of the file, it also begins uploading to other peers
that require those blocks. When the entire file is down-
loaded, the peer may decide to leave the swarm or stay
back as a seed.
2.3 Other P2P Data Networks
While BitTorrent has a centralized aspect to its oper-
ation in the form of the tracker, Gnutella and Fast-

4
Fig. 1 Network Testbed for P2P Evaluation (All six BitTorrent peers are inside Georgia Tech campus)
Track belong to the category of decentralized P2P net-
works where peers search for content in directories dis-
tributed around the network. Gnutella and FastTrack
albeit differ in the way peers act as content directories.
Any peer can act as a host for the directory of con-
tent in Gnutella Network. On the other hand FastTrack
distinguishes between peers that have slow connectiv-
ity to those peers (i.e., super nodes) that have faster
and stable connections. FastTrack achieves robust con-
tent search service by using the ultra-peer architecture
where only super nodes act as content directories.
Although the above mentioned P2P networks vary
in the way content search is performed, all of them rely
on direct downloading and uploading of content. Single
HTTP connections are employed for data transfer from
the content source to the requesting peer. The third
generation of P2P data networks use multiple down-
loads from several peers to accelerate the content fetch-
ing process, and networks like eDonkey (and BitTor-
rent) fall under this category. An important difference
between eDonkey and BitTorrent is the way multiple
fetches are performed for a particular content. eDonkey
performs contiguous downloads from multiple peers as
opposed to random fetches performed by BitTorrent.
3 Motivation
In this section, we use experiments performed on a Bit-
Torrent network to study the performance of a mobile
host in a P2P data network. We identify several design
characteristics of P2P data networks that are incom-
patible with typical characteristics of a wireless envi-
ronment. We also use the insights gained as the basis
for the design of the wP2P solution presented later in
the paper. While we present all the discussions in the
context of BitTorrent, we revisit the implications of the
discussions on the other P2P networks at the end of the
section.
3.1 Testbed & Methodology
The main network testbed used in the experiments is
shown in Figure 1. The testbed under our control con-
sists of six BitTorrent peers, three of which run the
Azureus client 2.3.0.4 on Linux, and other three peers
run the BitSpirit 3.2.215 client on Windows. All six
peers are inside Georgia Tech campus. They are all con-
nected to Internet through wireless LAN and thus par-
ticipating in larger P2P networks. To evaluate the per-
formance under various network conditions, we also in-
troduce an emulator for each BitTorrent client. The em-
ulators run Linux-based Ubuntu OS with kernel mod-
ules to mimic the wireless-related characteristics includ-
ing bit error rate, mobility, delay and bandwidth.
We identify totally six issues when mobile hosts par-
ticipate in P2P networks, and each of them will be elab-
orated in this section. Based on where the particular
issue arises, we broadly classify these issues into three
categories: Issues with Bi-directional traffic, Downloader-
side issues, and Uploader-side issues.
3.2 Issues with Bi-directional traffic
Issues with Bi-direction traffic are caused by the data
exchange between two peers over wireless media. Two
issues fall into this category: Bi-directional TCP and
Uploads based Incentives.
3.2.1 Bi-directional TCP
As described in Section 2, most peers in BitTorrent up-
load and download at the same time, and because of
the tit-for-tat policy used by BitTorrent, several of the
uploads are to peers from which downloads are being
done. Hence, it is common for data to be exchanged
simultaneously between peers in both directions. Given

5
0 1 2 3
x 10
−5
0
0.2
0.4
0.6
0.8
1
1.2
Bit Error Rate
Throughput(Mbps)
Uni−TCP
Bi−TCP
Double TCP
(a) Throughput Comparison
0 1 2 3 4 5
0
5
10
15
20
25
30
35
Time (Seconds)
Numberofpackets
Buffer drop
Packets sent from client
(b) Uni-directional TCP: Packets
0 1 2 3 4 5
0
5
10
15
20
25
30
35
Time (Seconds)
Numberofpackets
Buffer drop
(c) Bi-directional TCP: Packets
Fig. 2 Impact of Bi-directional TCP
that BitTorrent (or for that matter the other P2P ap-
plications) uses TCP, and that TCP is inherently de-
signed to be a bi-directional protocol, BitTorrent uses
TCP in its true bi-directional mode. Thus, a single TCP
connection is used to transfer data in both directions
between the peers. While TCP is designed to be a bi-
directional transport protocol, few extensive studies of
its behavior have been performed. More importantly,
in the context of this work, very little is understood
about the behavior of bi-directional TCP in a wireless
environment.
In this context, we identify two issues with the use of
bi-directional TCP by BitTorrent. These two issues are
centered around the behavior of TCP with respect to
ACK piggybacking and fast-retransmit under bi-directional
conditions.
• ACK Piggybacking: When bi-directional TCP is
used, TCP ACKs in the reverse path are piggybacked
on the data packets being sent in the reverse direction
to avoid sending separate ACK and data packets. In
a wireless environment, where random errors rates can
be non-trivial, this potentially has an adverse impact
on the connection performance. More specifically, when
ACKs are piggybacked on data packets, the effective
“length” of the ACKs is longer than if they were sent as
pure ACKs (non-piggybacked). Hence, for the same bit
error rate (BER) in a wireless environment, the effective
packet error rate (PER) for the ACK traffic is larger.
This in turn results in more ACK packets being lost on
the reverse path just because they were piggybacked.
Specifically, for a given packet of size S bytes, assuming
the uniform BER is b, the PER can be calculated as
1 − (1 − b)S
.
While it is true that TCP uses cumulative ACKs,
and hence is relatively robust to ACK losses, there still
is a negative impact in terms of the overall throughput
enjoyed by a connection in the presence of higher num-
ber of ACK losses. More importantly, in a P2P network
peers typically have a large number of TCP connections
ongoing even for a single swarm (BitTorrent trackers
typically provide addresses of 50 peers in response to a
request, but the overall swarm size can easily grow to
numbers greater than 1000, as we observed from our ex-
periments), resulting in the average congestion window
size of a TCP connection to be relatively small. And,
it is for connections with small congestion window sizes
that a higher ACK loss rate can result in a non-trivial
degradation in throughput. Thus, the download rate for
a TCP connection from a particular peer will be smaller
just because of ACKs being piggybacked in the reverse
direction.
We setup experiments to obtain the results with re-
spect to the use of uni-directional TCP and bi-directional
TCP. The network setup is as follows. To study the im-
pact of bit error rate, we implement a kernel module
with NetFilter [12] to probabilistically drops packets
based on packet lengths and assumed bit error rates. To
simulate the special feature of shared-media in 802.11,
we implement a shared-bandwidth emulation module
which embeds at the NF IP FORWARD point inside
the NetFilter framework. The maximum bandwidth is
set to 300 KB per second (i.e., 2.4 Mbps). 1
We consider three scenarios: single uni-directional
TCP, single bi-directional TCP and double uni-directional
TCP. We manipulate the shared data file on the testbed
to create all scenarios. (i) For uni-directional TCP, we
ask a peer to seed a file, and another peer purely down-
loads the file. (ii) For bi-directional TCP, we use two
other peers to download the file for a period of time.
After these two peers have downloaded about half of
the file, we remove other peers and only keep the two
peers. Since these two peers each has a random portion
of the file, they begin to exchange data between them.
We observe that the two peers are sending and receiv-
ing data on a single TCP connection. For this scenario,
we only consider the throughput of one direction (i.e.,
the larger one). (iii) For double uni-directional TCP, we
1 Note that though we could perform experiments by relying
on the “ture” shared-media of the WiFi networks, experimenting
under more-controlled environments help filter out other irrele-
vant factors such as interferences from other WiFi networks.

6
first set up the scenario of single uni-directional TCP,
then creates another uni-directional TCP along the op-
posite direction with Iperf. Given two peers A and B,
A is downloading from B with BitTorrent, and con-
currently A is also uploading to B with Iperf. For this
scenario, we consider the aggregate throughput.
Figure 2(a) presents results of the download rate
experienced by a peer under varying conditions of bit
error rate. Each data point is the average of five 10-
minute runs. We observe that the aggregate through-
put of double uni-directional TCPs result in highest
throughput, which can be easily explained by the higher
usage of the bandwidth with two connections.. The bi-
directional TCP has the lower throughput than uni-
directional TCP, which indicates the impact of ACK
piggybacking. What is more interesting is that the degra-
dation in throughput performance with increasing BER
is faster in the case of bi-directional TCP. In addition,
while it might appear that peers are better off not up-
loading for this reason, recall that the tit-for-tat policy
used by BitTorrent will render such a strategy ineffec-
tive.
• Fast Retransmit: The second issue with BitTor-
rent using bi-directional TCP occurs during conges-
tion. TCP’s fast retransmit mechanism is based on the
arrival of DUPACKs (duplicate ACKs) at the sender.
When bi-directional TCP is used, TCP specifications
stipulate that DUPACKs should not be piggybacked.
The reason for this stipulation is that otherwise the
sender has no way of knowing whether piggybacked DU-
PACKs are due to losses, or due to the receiver sending
multiple data packets between two data packet arrivals
(and hence piggybacking the same ACK sequence num-
ber on those data packets).
Hence, a TCP receiver will send only pure ACKs
when DUPACKs have to be transmitted due to losses.
While this design has no issues in a wired environment,
it results in problems when performed as-is in a WLAN
environment. This is because, when congestion has oc-
curred in the WLAN resulting in a packet drop, the DU-
PACKs sent back will be explicitly de-coupled from the
data stream in the reverse path, thus actually increas-
ing the number of packets in transit on the wireless leg.
While it is true that the TCP sender, when it receives
the DUPACKs will reduce its number of outstanding
packets in the network by half according to TCP speci-
fication, the new transmissions of pure ACKs essentially
offsets the decrease in the number data-packets. Hence,
as far as the wireless leg is concerned, the number of
packets in transit stays approximately the same even
after a congestion event.
Figures 2 (b,c) show the number of packets sent
by a client on the wireless leg with time for two Bit-
Torrent connections, one uni-directional TCP and one
bi-directional TCP, respectively. For the connection us-
ing uni-directional TCP, the client is sending data to
another BitTorrent peer. For the connection using bi-
directional TCP, the client is both sending to and re-
ceiving from another peer. The congestion events are
indicated as buffer drops in the figure as well. It can
be observed that while the number of packets on the
wireless leg in general decreases after 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 degradation for
the connections due to deviation from the intended be-
havior of TCP’s congestion control.
We have thus far discussed the negative impact of
using bi-directional TCP connections. While it is true
that the above problems will be issues for any appli-
cation that uses simultaneous data transfer with bi-
directional TCP, it is noteworthy that P2P data net-
works are perhaps one of the few instances (if not the
only) where such bi-directional data transfer does hap-
pen simultaneously and in large volumes. Applications
(or protocols) such as http or secure-shell, while using
bi-directional TCP, do not exercise the bi-directionality
the same way as P2P networks do. For example, both
the above applications have distinct request-response
patterns that render simultaneous data transfers at high
volumes unnecessary in both directions.
3.2.2 Uploads-based Incentives
The tit-for-tat incentive mechanism in BitTorrent en-
courages higher rates for uploads to enjoy better down-
load rates. In a wired environment, it can be shown that
peers enjoy their best download rates when their upload
rates are high. Figure 3(a) shows the aggregate down-
load rates of 4 simultaneous tasks (i.e., top 4 torrents of
Fedora 10 [13]) as a function of the upload rate limit in
a wired setting. The network is set up with the kernel-
module-based bandwidth emulator we discussed before.
Specifically, the bandwidth is capped to 2.4 Mbps for
both uplink and downlink. We show the results of three
separate runs, and each data point shows the result of
1-hour running. We observe that the download rate is
an increasing function of the upload limit. Since with
wired links, the uplink and downlink physically do not
affect each other, we believe that the results are caused
by the incentive mechanism embedded in BitTorrent.
This inference is further supported by variable software
manuals and user-experiences, most of which state that
the recommended uploading rate should be typically
around 80% of the upload capacity. The remaining 20%

7
0 500 1000
0
200
400
600
800
1000
1200
DownloadingThroughput(Kbps)
Uploading Limit (Kbps)
Run 1
Run 2
Run 3
(a) Wired Network
0 500 1000
0
200
400
600
800
1000
1200
Uploading Limit (Kbps)
Run 1
Run 2
Run 3
(b) Wireless Network
0 10 20 30 40
0
20
40
60
80
100
120
140
160
DownloadedSize(MB)
Time (Minutes)
No Mobility, Uploading
No Mobility, No Uploading
Mobility, Uploading
Mobility, No Uploading
(c) Downloading Process of a 100 MB File
Fig. 3 Effect of upload traffic on downloads (a,b), Effect of Incentive and Mobility (c)
capacity is reserved to allow for the pure TCP ACK
traffic on the reverse path for other connections.
For a wireless environment, however, the relation-
ship between the enjoyed download rate and the upload
rate limit changes. Using the same kernel module but
with a shared bandwidth-cap between uplink and down-
link, we show the aggregate download rate of the same
four tasks in Figure 3(b). As shown, while the download
rates initially increase with higher upload rates, beyond
a much smaller upload rate (400Kbps, much less than
80% in wired networks) the download rates actually
drop. This is due to the shared channel nature of the
wireless link, where the uploads and downloads are con-
tending for the same wireless channel bandwidth. This
is in contrast to a wired setting where the uploads and
downloads do not share the same bandwidth resources.
The same figure also demonstrates that shutting down
the upload is not a solution either as the tit-for-tat
strategy of BitTorrent will kick-in punishing the peer
with low download rates.
This problem of uploads contending with the down-
loads also goes beyond the incentives mechanism in Bit-
Torrent. In a wired environment, peers have a relatively
low dis-incentive to continue as a seed once the down-
loads are completed with the argument being that up-
load bandwidth is anyway largely unused under most
conditions except for TCP ACK traffic. Thus, peers in
wired networks are more willing to upload other peers
by acting as servers. However, in a wireless setting, a
mobile peer functioning as a seed can potentially impact
its download rates for other non-P2P applications with-
out any direct counter-benefit for the user. While this
contention between P2P uploads and other application
downloads is true even when the mobile peer is a leech,
it can be argued that the mobile user is at least receiv-
ing the benefit of the tit-for-tat scheme. However, when
the wireless peer converts to a seed, this advantage no
longer remains. Hence, any viable solution to motivate
mobile peers to continue as a seed has to ensure that
the uploads do not negatively affect the downloads of
other applications.
3.3 Downloader-side issues
Downloader-side issues occur in the downloading pro-
cess on P2P clients. These issues include: Incentives and
Mobility and Rarest-first Fetches.
3.3.1 Incentives and Mobility
The tit-for-tat mechanism in BitTorrent is associated
with a unique identifier for the peer called the peer-id.
The peer-id is typically constructed as either a function
of the IP address of the host and a random value, or
simply as a function of a mobile host specific random
value. The peer-id is regenerated every time fetch tasks
are re-initiated. Thus when a mobile host experiences
a hand-off and receives a new IP address, the ongoing
tasks are terminated and the tasks are re-initiated2
thus
generating a new peer-id. However, since the peers track
the goodness of corresponding peers based on the peer-
id, this results in the mobile peer losing all the credit
it has built with its corresponding peers.
Figure 3(c) shows the effect of incentives on the
downloaded sizes of a 100MB file as a function of time.
Under the no-mobility scenario, we observe that the
download size is lower when there is no upload traffic.
This is the normal incentive behavior. However when
we introduce mobility by switching IP address every
one minute, we see that the incentive mechanism is
rendered ineffective. Not only is the actual download
size lower than the no-mobility case, there is marginal
difference between the download rates with or without
uploading. This is because every time the IP address
changes, tasks are re-initiated and thus the host acts as
a new peer without any previous incentives. Thus, the
mobility of a peer can have an adverse impact on the
incentive mechanism of a P2P network.
2 We assume here that mobile IP [14] is not used to handle
mobility.

8
256KB 512KB 1MB 5MB
0
20
40
60
80
100
120
140
160
180
Data Size
Throughput(KBps)
Server PSM OFF
Server PSM ON
(a) Effect of PSM (Client PSM OFF)
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5
0
1
2
3
4
5
6
7
x 10
4
Time (Seconds)
TCPSeq.Number
Server PSM ON (BT Msg)
Server PSM ON (Data)
Server PSM OFF (BT Msg)
Server PSM OFF (Data)
(b) Progress of packet sequences
0 0.5 1 1.5 2
0
0.5
1
1.5
2
2.5
3
3.5
Time (Seconds)
Packets
Server PSM ON (BT Msg)
Server PSM ON (Data)
Server PSM OFF (BT Msg)
Server PSM OFF (Data)
(c) Microscopic progress
Fig. 5 PSM on Server side
3.3.2 Rarest-first Fetches
As outlined in Section 2, BitTorrent employs a rarest-
first fetching paradigm. This results in any snapshot of
the downloaded content for a file not having any signif-
icant “in-sequence” data from the head of the file till
a large percentage of the file download is completed.
Many media formats, on the other hand, allow for par-
tial playback of content provided the partial informa-
tion is in sequence. For example, for an MPEG file of a
2 hour video, the download of the first 30 minutes worth
of the video will still allow for a playback of that part
of the video. Figure 4(a) shows the playable fraction of
two files being downloaded with increasing fraction of
the actual downloads using rarest fetch. It can be ob-
served that until a large percentage of the whole file
download is complete, a significant percentage of the
file still remains unplayable. For 5 MB file, even with
a 60% download fraction, less than 20% of the file re-
mains playable. In fact, for the 100 MB file size scenario,
more than 90% of the file size needs to be downloaded
to playback the first 5% of the video.
While this property of BitTorrent is an irritant even
for a fixed peer, it is justifiable for two reasons: (a) this
enables the peer to contribute well to the P2P network
as it is likely to have blocks that are different from
those at other peers; and (b) fixed peers do not have to
0 20 40 60 80 100
0
20
40
60
80
100
Downloaded Percentage (%)
PlayablePercentage(%)
5MB File
100MB File
Fig. 4 Impact of Rarest-first Fetching
concern themselves with wireless disconnections thus
ensuring that the downloads will eventually complete
and will not be in vain.
However, for a mobile peer, this property can have
more serious implications. In the example of the 100
MB file, if the 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 far using the rarest-first
algorithm in the interest of the well being of the rest
of the P2P network cannot be served back to the P2P
network anyway because of the disconnection.
3.4 Uploader-side Issues
Uploader-side issues are caused by the fact that P2P
clients are also serving as “servers” in the sense that
they supply data to other clients. We identify two is-
sues in this category: Power-saving Mode and Server
Functionality, and Server Mobility.
3.4.1 Power-saving Mode and Server Functionality
Most mobile devices employ a power-saving mode (PSM)
of operation to shutdown their radios and conserve en-
ergy. In the 802.11 PSM operation, the radio goes to
sleep when there is no data to send or receive, and
wakes up after a 100 ms interval or when there is data
to send, whichever event occurs first. During the period
of sleep, if the access-point receives packets meant for
the mobile device, it buffers the packets and advertises
the presence of the buffered packets in periodic beacons
to the mobile devices. A mobile device that wakes up
after the 100 ms interval will poll the access-point for
data if it finds that the beacons advertise data buffered
for that device.
When a mobile device is merely acting as a client (as
in traditional client-server applications), the use of the
PSM does not severely impact the initiation of connec-
tions because the radios are required to wake-up when

9
there is data (or in this case TCP SYNs) to be trans-
mitted, and clients always initiate connections. How-
ever, in a P2P network, where a mobile host can act
as the server, when other peers initiate connections to
the mobile host, the mobile host has no way of know-
ing that connection initiation messages are pending for
reception at the access point till it wakes up from its
fixed sleep interval, polls the access-point, receives all
buffered data ahead of the initiation message one by
one, and finally receives the initiation message.
Thus, the start-up time during connection initia-
tion for the corresponding peers, when attempting to
connect to a mobile peer that acts as a server can be
strongly influenced by the PSM operations at the mo-
bile host because of three reasons. First, each of the
message/packet exchanges can be delayed in the form of
inflated transaction time. Second, if the available band-
widths are low this problem is exacerbated because of
the need to drain the buffered data at the access point
that is queued ahead of the initiation message(s). Third,
if the access-point PSM buffer is full when the initiation
messages arrive, potential message drops and associated
delays will arise as well.
Such adverse impact on the connection during its in-
fancy also has other implications. For example, TCP’s
rtt and rttavg calculations are significantly impacted
by even a small number of samples during connection
initiation because of the small congestion windows dur-
ing start-up. Figure 5(a) shows the impact of PSM on
the performance experienced by peers trying to use the
mobile peer as a server. We observe that turning on
the PSM at the mobile peer acting as the server results
in a throughput reduction of up to 40% depending on
downloaded file size. Thus we see that the PSM can
potentially harm the peer-to-peer connection. Figure
5(b) shows the actual time instants at which different
TCP packets (both for BitTorrent protocol messages
and actual data) are received when the PSM is either
turned on or off for a single TCP connection. We ob-
serve that the TCP sequence number increases much
faster when PSM is turned on, which proves that the
impact on the start up delay has a significant impact on
the connection progress. In addition to Figure 5(b), we
also provide the microscopic view of the start-up delay
in Figure 5(c). The figure shows 6 BitTorrent protocol
messages and the first data packet along the time line.
We observe that the start-up delay of the data trans-
mission is about 1 second.
3.4.2 Server Mobility
P2P peers update address list of other peers to estab-
lish connections to them. Peer address updates in Bit-
Torrent typically happen at the granularity of minutes
when a peer goes back to the tracker for an updated
set of peers to use in its swarm. Even within that pe-
riod, the decision on whether to use a peer or not for
downloads is adjusted at the granularity of tens of sec-
onds. Note that this is understandable in a wired envi-
ronment where disconnections of peers may not occur
frequently. However, when a mobile peer undergoes a
hand-off or simply gets disconnected, the fixed peers
who were clients with respect to the mobile peer will
continue to try to reach the mobile peer till either the
peer selection algorithm chooses an alternate peer (af-
ter 10-20 seconds) or the tracker provides alternate ad-
dresses or alternate peers (after a few minutes if not
longer).
Figure 6 shows the effect of server side mobility
on the throughput performance for fixed peers. The
client is receiving data from three other peers (i.e., the
servers). The IP address of the server is changed every
fixed time interval and the resultant throughput as en-
joyed by the fixed peers is measured. We observe that
as the time interval between successive IP change de-
creases (reflecting higher mobility) the throughput falls.
Specifically, with current BitTorrent peer-updating model,
the time required for a practical IP-address update of
a serving neighbor takes the following three sequential
steps: (i) the peer acquires a new IP address and re-
ports to the tracker; (ii) the downloading peer requests
for peer-list update from the tracker; and (iii) the down-
loading peer chooses the peer with a new IP and ini-
tiates the connection. These steps can take as much
as several minutes depending on factors such as swarm
size. Furthermore, the degradation due to mobility is
amplified when the number of mobile peers amongst
the corresponding peers is increased.
No Mobility 3 Min. 2 Min. 1.5 Min.
0
500
1000
1500
2000
2500
Mobility Rate
Throughput(Kbps)
One peer is mobile
All peers are mobile
Fig. 6 Impact of server mobility

10
3.5 Relevance to Other P2P Networks
Thus far, we have investigated properties of the BitTor-
rent P2P data network that negatively impact perfor-
mance of a mobile peer. While we use BitTorrent, a pop-
ular flavor of P2P systems, to describe the various chal-
lenges faced by P2P applications in wireless and mobile
environments, we feel that it is necessary to broaden
our research results to other P2P systems. Admittedly,
a thorough investigation requires considerable research
efforts and we view this as future work. Briefly, while
not all the properties discussed thus far are directly rel-
evant in the context of the other popular P2P data net-
works such as Gnutella, FastTrack, and eDonkey, many
of the issues discussed in this work apply with vary-
ing extents. Specifically, (i) Any P2P network that uses
TCP and allows data exchange on the same connec-
tion has issue of bi-directional TCP. We do notice that
many current P2P softwares use TCP due to TCP’s
advantages when compared to UDP. (ii) P2P networks
that accumulate incentives based on the amount of data
transmitted to other peers has the upload-based incen-
tive. For example, many flavors of Gnutella have in-
centive mechanisms. Such incentive mechanisms might
suffer from mobility depending on the exact realiza-
tions. (iii) When media files that allow partial play-
back are shared by P2P networks, fetching sequences af-
fect the playback performance. If non-sequential fetch-
ing algorithm is used, the playable percentage will be
much smaller than the downloaded percentage. (iv) The
proper functioning of P2P networks relies on the con-
tributions of all peers. So when uploading data, server
mobility and PSM on mobile hosts can have impact on
the uploading performance.
4 wP2P Design
In this section, we first summarize the limitations with
current P2P designs by characterizing the limitations
into four problem classes. We then outline the key de-
sign aspects of the proposed wP2P solution that are
targeted to address the limitations of existing P2P data
networks identified in Section 3. We present the de-
sign basis for wP2P in the form of four principles that
address the above four categories of problems. These
principles are Role Reversal, Age-based Manipulation,
Incentive Aware operations and Mobility-aware Fetch-
ing.
For each of the four principles, we first highlight the
design rationales that serve as the basis of the each de-
sign principle. We then present the algorithmic details
of the realizations of the different principles. We de-
note the realizations of the different design principles
as components. We present the realizations in the con-
text of a P2P client application, and hence, an imple-
mentation of the mechanisms would involve updating
the P2P application. We believe that such a deploy-
ment model is very justifiable in the context of P2P
data networks where it is not uncommon to receive up-
dates to the P2P client application. Also, we present
any specific implementation details with respect to the
BitTorrent protocol. However, all the realizations pre-
sented are purely local to the mobile host and backward
compatible to all existing BitTorrent P2P client appli-
cations on fixed peers.
4.1 Insights into the problems
Before we proceed to the design, we characterize the
insights into the problems identified in Section 3 by
categorizing the different limitations into four problem
classes. Problems within a class all have a common un-
derlying cause. We use the categorization to then posi-
tion the design basis for wP2P. The limitations identi-
fied in Section 3 can be categorized as follows:
• Mobile host as a server: Unlike in other applica-
tions, in P2P data networks, the mobile host uniquely
functions as a server that can be accessed by other peers.
Hence, several problems attributed to wireless and mo-
bile environments that can be (and have been) solved
have to be solved differently. Moreover, some other prob-
lems related to such environments that do not exist
when the mobile host acts only as a client arise newly.
Instantiations of this category of problems include the
impact of PSM on the server performance, and server
mobility.
• 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 TCP to transfer large volumes data in both
directions simultaneously. Hence, several quirks of bi-
directional TCP that do not arise in wireless environ-
ments otherwise have to be addressed. Instantiations of
this category of problems include the ACK piggyback-
ing problem and the DUPACK decoupling and overload
during congestion.
• Failure of incentives: While P2P data networks
heavily rely on incentives based mechanisms to encour-
age peers to contribute to the network, such mecha-
nisms are not tailored for the unique characteristics
of wireless and mobile environments. Specifically, the
problems of upload-download self-contention and iden-
tity loss after mobility fall under this category of prob-
lems.
• Disconnections and fetching: The newest genera-
tion of P2P data networks use multiple simultaneous

11
fetches from different peers and fetch blocks in a non-
sequential order. While such strategies have obvious
benefits in a wired environment, they compromise per-
formance in a wireless setting. Problems that fall under
this category include lack of playable content during
disconnections and redundant fetching of partial blocks
after reconnections.
4.2 Role Reversal
The problem of mobile host as a server primarily im-
pacts connections either when the mobile host uses PSM
or when the mobile host moves (and hence undergoes
an IP address change). In this context, the role rever-
sal design principle of wP2P involves the mobile host
switching its role to that of a client at specific points in
time to address the above problems. Note that the fact
that a mobile host switches to acting as a client will
not have any impact on the mobile host still serving
content to the peers it connects to, as peers can serve
traffic irrespective of whether or not they initiated the
connection.
Essentially, for both the problems in this category,
the TCP connection “suffers” due to delays or disrup-
tions, and the impact of the delays or disruptions can
have a non-trivial impact even on the overall perfor-
mance of the connection, especially when the file size
or the remaining file size is small. Under role reversal,
a mobile host acting as a server, upon detecting a con-
nect request (i.e., TCP SYN) delayed by the PSM or
a hand-off, explicitly issues a TCP-Reset to the cor-
responding peer for previous connection. Further, the
mobile host re-initiates a new connection to that same
peer, thus acting as the client. Once the new connection
is setup, because of the bi-directional nature of the ap-
plication semantics and the bi-directional nature of the
TCP connection, the mobile host can serve the content
as a server. However, having replaced a “suffering” (i.e.,
the progress of the connection is unnecessarily delayed,
in the case of PSM) or stalled (in the case of server mo-
bility) connection with a newly formed “healthy” con-
nection (i.e., the progress of the connection is smooth)
allows the peers to achieve much better performance.
The Role Reversal (RR) component realizes this
design principle and kicks in during connection setup
and during mobility-induced network changes. Figure
7(a) shows the pseudo-code of the RR component. Dur-
ing connection initiation, the RR component captures
packets and checks the TCP flag in the captured packet.
If the SYN flag is set in the TCP packet and PSM mode
is enabled on the wireless transceiver, then the RR
component issues an application-close (Line 4 of Figure
7(a)) to the TCP layer triggering a TCP RST packet
to the peer which initiated the connection through the
SYN packet. After the application close, the RR compo-
nent sends an application-open (Line 5 of Figure 7(a)) to
establish a P2P connection to the corresponding peer.
In this fashion, the RR component changes the mo-
bile host to act as a TCP client as opposed to a TCP
server. The RR component ignores the SYN packet if
PSM mode is not turned on.
The RR component also monitors the IP address
of the wireless interface. If it detects a change in the
IP address, the RR component: (i) stores the necessary
information of all the corresponding peers with which
P2P TCP connections have been established, (ii) trans-
mits application termination messages to all the stored
peers, and (iii) issues application setup messages to the
stored peers.
4.3 Age-based Manipulation
The bi-directional TCP problem arises because of spe-
cific quirks of the TCP design and how they relate to
the wireless environment. However, at the same time,
bi-directional TCP’s performance otherwise is desirable
since it eliminates ACK overheads under normal con-
ditions. In other words, the solution to the problems
with bi-directional TCP is not to switch back to dual
uni-directional TCP connections, as doing so would ren-
der the overall performance worse than when using bi-
directional TCP as pure ACKs in both directions and
consume precious bandwidth resources.
In this context, the age-based manipulation design
element of wP2P involves the adaptive manipulation
of the bi-directional TCP connections for better per-
formance. Essentially, recalling the discussion on ACK
loss rates in Section 3, an argument can be made that
TCP’s throughput performance is vulnerable to ACK
losses only when the congestion window is small. At
larger congestion windows, the higher ACK loss rates
do impact progress, but not significantly. Hence, under
age-based manipulation, explicit conversion of piggy-
backed ACKs to pure ACKs is performed when the con-
nection congestion window (i.e., cwnd) is small. Note
that although this manipulation is done at the receiver,
standard techniques exist to track the sender conges-
tion window at the receiver. Piggybacked ACKs are let
through as-is when the congestion window is larger than
a threshold. A straightforward value for the threshold is
6 as it can be shown that congestion windows less than
6 are highly vulnerable to losses in either direction [15].
Similarly, the use of pure ACKs during fast retrans-
mit and the associated wireless link overload is ad-
dressed by throttling the number of packets down ex-
plicitly such that the total number of packets ( includ-
ing the pure DUPACKs) outstanding amounts to half

12
(a) Role Reversal Component
1 Monitor packets received
2 If captured packet has TCP-SYN flag set
3 If PSM is turned on
4 Send Application Close;
5 Send Application Open to peer;
6 End If
7 End If
8 Monitor IP-addr of wireless NIC;
9 If IP-addr changes
10 Issue Application Close to the peers;
11 Send Application Fetch of partial blocks;
12 End If
(b) Age-based Manipulation Component
Variables
CWND: Congestion window of TCP connection
γ: Connection status threshold
STATUS: Status of the TCP connection
DUPACK CNT: Number of DUPACKs sent by MH
1 Calculate CWND of TCP connections;
2 If CWND < γ
3 Set STATUS to Y OUNG;
4 Store PSM status and Turn PSM OFF;
5 Else
6 Set STATUS to MATURE;
7 Set PSM of wireless NIC to stored status;
8 End If
9 Capture TCP packet transmitted by MH;
10 If the packet is piggybacked ACK
11 If STATUS is Y OUNG
12 Decouple ACK from DATA;
13 Send pure ACK;
14 End If
15 End If
16 If DUPACK is transmitted by MH
17 If STATUS is MATURE
18 DUPACK CNT ++;
19 If DUPACK CNT % 4 ==0
20 Drop DUPACK;
21 End If
22 End If
23 End If
(c) Incentive Aware Operations Component
Variables
Umax: Maximum upload limit
Ucur, Uprev: Current, previous upload state
Dcur, Dprev: Current, previous download state
α, β: Upload increment and decrement factor
Udec cnt: Upload decrement count
Initialization
1 Ucur = Uprev = 0.5*Umax;
2 Dcur = Dprev = 0; Udec cnt = 0;
Update
3 Determine current P2P download rate and store;
4 If Dprev <> 0
5 If Dprev < Dcur
6 Ucur = Ucur + α; Udec cnt = 0;
7 Else
8 Increment Udec cnt; Ucur = Ucur − β ∗ Udec cnt;
9 End If
10 End If
(d) Mobility-aware Fetching Component
Variables
Pr: Probability of performing rarest-first fetch
σ: Probability increment value
∆: Aging timer interval
Initialization
1 Pr = 0.1;
Maturity-timer Expired
2 Pr = Pr + σ;
3 Reset maturity-timer from ∆ seconds;
4 Pick a random number r (0 < r < 1);
5 If r < Pr
6 Perform rarest-first fetch;
7 Else
8 Request the next in-sequence piece;
9 End If
Mobile Handoff
10 Set Pr = 0.1;
11 For each request stored
12 End For
Fig. 7 Pseudo-code : (a) Role Reversal, (b) Age-based Manipulation, (c) Incentive Aware Operations, (d) Mobility-aware Fetching
the number of outstanding packets before the conges-
tion detection. This is performed by explicitly dropping
one-fourth of the DUPACKs in the reverse path dur-
ing the first round-trip time after the first DUPACK is
generated. For example, if the cwnd is 100 on conges-
tion detection (assume one packet loss), 99 DUPACKs
will be generated by the receiver. If one-fourth of the
DUPACKs are dropped, approximately 24 DUPACKs
will be dropped resulting in 75 DUPACKs reaching the
sender. The sender, when it performs fast retransmit
and fast recovery, will thus send out 25 (i.e., (100/2)+75-
100) new packets. Thus, even if the 25 new packets gen-
erate 25 pure DUPACKs (assuming the receiver still is
in loss recovery), that amounts to a total of 50 total
packets equalling half of the number of packets out-
standing before congestion detection.
Finally, the age-based manipulation principle also
applies to one other technique of controlling when PSM
is employed, and when it is not. Essentially, when a mo-
bile peer has TCP connections in their infancy, PSM is
turned off at the mobile. This includes the period right
after role reversal is performed. The PSM is turned back
on after the connections cross the infancy threshold in
terms of their cwnd.
The pseudo-code for the Age-based Manipulation
(AM) component is listed in Figure 7(b). First the AM

13
component constantly monitors the congestion window
of the TCP connection. If the current connection con-
gestion window is less than a specified threshold value γ
(set to 6 in our evaluations [15]), the connection status
is set to YOUNG (Line 3 in Figure 7(b)) and disables
PSM on the wireless interface of the mobile host. If the
congestion window is greater than the threshold γ, the
connection status is set to MATURE (Line 6 in Figure
7(b)).
The AM component also maintains state about the
TCP connection and captures TCP packets transmitted
by the mobile host. If the connection status is YOUNG,
the AM module conveys any new ACK information pig-
gybacked on DATA packets transmitted by the mo-
bile host as separate pure ACKs (Line 13 in Figure
7(b)). This achieves better robustness for the ACKs
given a finite error rate in the wireless channel. The
AM component also detects losses experienced by the
TCP connection and performs the following operation
during loss recovery. If the status of the connection en-
countering loss is MATURE, the AM module drops one
DUPACK every four DUPACKs (Line 20). Specifically,
wP2P captures and manipulates TCP packets in wP2P
using frameworks such as WinpkFilter [16] (for Win-
dows OS) and NetFilter [12] (for Linux OS) that act
transparently to the existing protocol stack of the net-
work.
4.4 Incentive aware operations
The problem of failure of incentives stems from the two
distinct conditions of the self contention in a wireless
link and mobility-related identity loss. The incentive-
aware operations principle in wP2P is used to address
both problems.
Essentially, one technique under incentive aware op-
erations in wP2P involves the adaptation of the upload
rate in order to find the smallest upload rate possible to
achieve the maximum download rate. While this value
for the upload rate is trivial to determine in a wired
setting, a more sophisticated algorithm is required in a
wireless environment.
Since a wireless host uses a shared channel, the up-
load and download traffic contend with each other and
hence increased uploads might reduce the downloads
possible. In order to strike the balance between the two
competing issues (i.e., incentives and self-contention)
wP2P performs a Linear Increase History-based De-
crease (LIHD) algorithm that adapts the uploading rate.
The intuition behind the LIHD algorithm is that while
increasing the upload rate, it is better to be conser-
vative so that the mobile host does not upload more
than necessary. At the same time while reducing the up-
loads it is desirable to be aggressive, while at the same
time performing as close to the optimal rate as possible.
LIHD hence increases upload rates linearly when there
is a positive correlation between the uploads and down-
loads, while decreasing the upload rates with increasing
aggressiveness when decreasing the uploads does not
cause a decrease in the downloads.
LIHD can also be used for controlling the rate of up-
loads when the mobile peer becomes a seed, such that
the uploads do not impact negatively any of the down-
loads being performed by other non-P2P applications
on the mobile peer. We do not consider this aspect of
the mechanism in this paper, and leave it for future
work.
The Incentive Aware (IA) component monitors up-
load and download rates achieved by the P2P appli-
cation and uses window-averaged throughput to deter-
mine the upload rate control of the P2P application.
Specifically, as shown in Figure 7(c), the component is
invoked periodically. For each period, the downloading
throughput is calculated and compared to the previ-
ous period. if the downloading throughput sees an in-
crease, then it suggests that the uploading is unlikely
interfering with the downloading and a larger uploading
rate likely results in even better downloading through-
put. Thus the uploading rate is increased linearly by
a guard value of α (Line 6 in Figure 7(c)). Otherwise,
if the downloading throughput decreases, then it sug-
gests the opposite, and the uploading rate is curbed
more aggressively. Specifically, the upload rate counter
is decremented by a value proportional to the number
of consecutive cutdowns of the upload rate (Line 8 in
Figure 7(c))
IA also identities retention across hand-offs and within
the same swarm. The rationale for generating uniquely
different peer-ids in BitTorrent is to be able to identify
and distinguish between clients with the same IP ad-
dress (say, if the clients are behind a NAT), but at the
same time confine the benefits of incentives accumu-
lated by a peer to only that swarm in which the peer
contributed. Since the typical scenario for task initi-
ation in wired environments is when a peer wants to
download another data file, generating a new peer-id is
reasonable. However, in mobile environments task re-
initiations can occur just because IP addresses have
changed. wP2P, in this context, performs identity re-
tention within a swarm, whereby even when task re-
initiation is performed, as long as it is for a swarm the
mobile peer was a member of before, the old peer-id is
retained. This enables the mobile peer to leverage its
previously accumulated incentives. The IA component
stores the peer ID of the mobile host when the applica-
tion is started and when there is IP layer handoff, the

14
Role
Reversal
Role Reversal
Connection
Setup
Age-based
Manipulation
Congestion
Age-based
Manipulation
Mobility-aware Fetching
Mobility
Handoff Re-Connect
Age-based
Manipulation
Incentive-aware Operations
Mobility-aware Fetching
Incentive-aware Operations
Time
Fig. 8 Integrated operations
IA component restores the stored peer ID to maintain
incentives.
4.5 Mobility-aware fetching
In Section 3 we observed how in a mobile peer (as a
client) mobility can impact the performance of down-
loads in BitTorrent. In this context, wP2P uses a mobility-
aware fetching principle that explicitly controls how
data is fetched both during steady-state, and upon re-
connections after disconnections.
The mechanism that falls under this principle is that
of exponentially increasing altruism or exponentially
decreasing selfishness. Essentially, a mobile peer fetches
blocks in sequence with a probability ps (=1 − pr), and
fetches the rarest-first block with a probability pr. Dur-
ing the initial phases of the download, the mobile peer
uses a small value (say, 0.1) for pr, and exponentially
increases pr as it downloads increasing fractions of the
total file.
The rationale for this design is as follows: during
the initial stages of downloads, if the mobile host gets
disconnected, there is no benefit due to the rarest-fetch
mechanism either for the mobile host (in terms of playa-
bility) or to the P2P network (in terms of availability).
Hence, it is more desirable to fetch sequentially. How-
ever, as the mobile host stays connected for a longer
period of time, its utility to the P2P network has more
stability and hence it is more meaningful to have avail-
able rare blocks. Furthermore, if the mobile host now
gets disconnected, the user still has a considerable por-
tion of in-sequence data for playback.
Mobility-aware Fetching (MF) component, as the
final piece of the wP2P framework, helps in achieving
ideal fetching of file sequences by being aware of the
connection stability of the mobile host. The pseudo-
code for the MF component is listed in Figure 7(d).
The MF component performs rarest-first fetches with a
specific probability Pr. This probability Pr is a function
of the network stability of the mobile host as measured
by the amount of time elapsed since the last network
disconnection of the mobile host (or the start of the
download). This mobility-aware adaptive content fetch-
ing achieves an optimal tradeoff between sequential con-
tent availability for disconnected usage of content and
usability of content for other peers to download.
4.6 Integrated Operations
We can classify the operation of the four components
of the wP2P framework with respect to the different
periods of the P2P connection. The operation of the
four components are illustrated in Figure 8. The Role
Reversal component is employed during connection es-
tablishment and immediately after mobility-induced IP
handoffs. The operations of the Incentive Aware com-
ponent are performed during steady-state of the TCP
connections. Age-based Manipulation component kicks
in during early stages of the connection and during con-
gestion recovery periods. Finally, the Mobility-aware
Fetching component is active during the steady-state
period of the TCP connection and also after IP address
change due to reconnection.
5 Evaluation
In this section we evaluate the performance of wP2P.
5.1 Evaluation Methodology
The evaluation is performed both with NS2-based[17]
simulations and prototype-based experiments. Since Bit-
Torrent protocol in the study has various software im-
plementations, and different implementations may dif-
fer in certain aspects of protocol standards, we believe
such simulations with embedded design principles can
help capture the trend of performance enhancement de-
livered by wP2P.
To further evaluate the effectiveness of our proposed
wP2P solution, we built a prototype which implements
most of the mechanisms contained in wP2P. The pri-
mary goal of building such a prototype is to prove that

15
256KB 512KB 1MB 5MB
0
20
40
60
80
100
120
140
160
180
Data Size
UploadingThroughput(Kbps)
Default P2P (PSM ON)
Default P2P (PSM OFF)
wP2P
(b) Impact of data size (No mobility)
No Mobility 8 Min. 6 Min. 4 Min. 2 Min.
0
50
100
150
Mobility Rate
UploadingThroughput(Kbps)
Default P2P
wP2P
(a) Impact of server mobility
Fig. 9 Role Reversal: Simulation results (a) and Prototype results (b)
the proposed wP2P architecture does indeed work with
real applications.
The metrics we study in this evaluation are average
throughput, download size for a given time and percent-
age of playable content for media files. We compare our
results with a default-P2P application under various
scenarios.
5.1.1 Simulation Setup
We use the NS2-based simulator to evaluate all our
algorithms. The topology used in our simulations is
shown in Figure 10. The network consists of both wired
and mobile hosts. All our algorithms are added as mod-
ules to the wireless nodes in the simulator. Unless other-
wise specified, all the wireless links have a bandwidth of
2Mbps and use the IEEE 802.11b standard. The wired
network has 50ms-delay links between the individual
hosts. The mobile hosts M1 and some other peers con-
tains the new wP2P implementation. The maximum
number of upload connections from M1 is set to be
4, and the number of download connections can range
from 1 to 100. All traffic is generated using FTP over
TCP, and data points in all results are averaged over 5
runs unless otherwise specified.
InternetM1
P1
P2
P100
…...
wP2P Module
P99
wP2P
peers
Default
P2P
Peers
Uploading
Downloading
Fig. 10 Simulation Setup
5.1.2 Prototype Setup
We use a prototype implementation of wP2P that is
built as an enhancement to the CTorrent client ver-
sion 1.2 [18]. CTorrent is a lightweight C++ implemen-
tation of BitTorrent protocol with about 10K lines of
code. The four components of wP2P are implemented
by either modifying the source code of CTorrent or
adding a separate module which works with a packet
filtering utility widely available in Linux distributions.
Specifically, the Role Reversal, Incentive Aware Opera-
tions and Mobility-aware Fetching components are im-
plemented by directly modifying the CTorrent source
code, and the Age-based Manipulation component is
realized with the assistance of Netfilter utility [12]. We
now describe the network setup of our implementation
followed by descriptions of the four individual wP2P
components.
• Implementation details. (I) The prototype realizes
RR by modifying the source code of CTorrent. IP ad-
dress change induced by mobility will render all current
connections unusable, and CTorrent client will eventu-
ally lose all live peers. Thus, the prototype stores the
remote peers to which it is serving data, monitors the
number of live peers, and infers mobility when there
are no live peers existing. Once mobility is detected,
the mobile host will immediately attempts to build new
connections to the stored remote peers to resume serv-
ing data. (II) AM needs to determine connection ages,
and the determination is based on the measurement
of current congestion window. Since the information of
congestion window typically is not available to the ap-
plication itself, the realization of this component has
to obtain such information from certain networking en-
tities. Specifically, we choose Netfilter utility to assist
the implementation of the component partly due to its
wide deployment in Linux distributions. A module in
the user space keeps track of the amount of data sent
by the remote peer in every round trip time (rtt), and

16
uses the current value as an estimate of that peer’s TCP
congestion window for the next rtt. We chose a conges-
tion widow of size 9k bytes (approximately 6 full pack-
ets) as an indicator of the age of the flow. If the window
size is less than the threshold, the connection is consid-
ered to be young, and TCP ACKs are decoupled from
the data packets. Otherwise, the connection is set as
mature, and the packets are sent as such without mod-
ifications. (III) IA prototyping employs two techniques:
identity retention and LIHD rate control. For identity
retention a static peer ID is used in lieu of a randomly
generated peer ID every time the IP address changes.
For LIHD we modify CTorrent’s in-built capability to
control upload and download limits. The default CTor-
rent client allows uses to specify the upload and down-
loads limits. We modify it to allow the adaptive LIHD
rate control algorithm described in the previous Sec-
tion. We use bandwidth monitors to check the current
upload and download rates for the algorithm. (IV) The
basic CTorrent client does not implement the rarest-
first fetching algorithm commonly used by BitTorrent
clients. Hence we first implement the rarest-first fetch-
ing algorithm for the default client. We then modify
this algorithm to prototype MF by including sequence
information and awareness of download progress.
• Prototype Testbed: We use two wireless clients in
a popular BitTorrent network to compare the perfor-
mances of wP2P with a default version of BitTorrent.
One of the clients has the modified CTorrent version
and the other has a plain vanilla version of the CTor-
rent, which we refer to as default-P2P. Linux machines
connected to the Internet through NS2 based wireless
emulators are used for the two clients. An illustration
of the network setup is shown in Figure 11. We use NS2
emulation [19] to study the impact of various issues of
wireless environments like random wireless losses, mo-
bility and bandwidth. Specifically, we emulate random
wireless 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 moni-
tor the bandwidth consumed at each client to enforce
bandwidth limitations.
Internet
C2
P1
Pn
…...
Default
Ctorrent Client
BitTorrent
Peers
C1
wP2P
Ctorrent Client
P2
Wireless
Emulator
Wireless
Emulator
Fig. 11 Testbed used in prototyping
5.2 Role Reversal
When a mobile host serves as a server, it receives re-
quests from clients and sends data back. Figure 9(a)
shows throughput obtained for varying file sizes at the
server for default-P2P with PSM turned ON, default-
P2P with PSM turned OFF and wP2P. The figure shows
that PSM turned OFF gives the best performance. This
is expected because when there is no PSM, packets can
be sent as and when required. However, the presence of
PSM affects default-P2P. This is because the startup
delay for connection establishment increases initial rtt
estimation, which results in lesser throughput. Using
the role reversal component, a new connection is estab-
lished with lower initial rtt thus improving throughput
performance. Smaller file sizes show greater improve-
ments because the effect of the start up delay is more
significant.
• Prototype Results. To evaluate the role reversal
technique we setup two mobile seeds in a live swarm
which shares the file of Fedora-7-KDE-Live-i686.iso im-
age [13]. Figure 9(b) shows the 10-run averaged up-
loading throughput of the two clients with different
disconnection rates (i.e., rate of change of the IP ad-
dress). As the rate of connection disruptions increases
the upload throughput naturally drops. The role re-
versal technique of wP2P allows the client to achieve
far more upload rates when compared to the default
client. We observe that with increasing rate of disrup-
tions the performance improvement of wP2P is higher.
This is because when there are frequent disruptions, the
re-establishment time for default-P2P becomes a signifi-
cant factor, whereas in wP2P the re-establishment time
is reduced. We observe improvements of up to 50% in
wP2P when connections are disrupted every 2 minutes.
5.3 Age-based Manipulation
For bi-directional TCP, piggybacked ACKs are more
susceptible to losses than individual ACKs. Figure 12(a)
compares the downloading throughput observed using
a uni-directional TCP connection, bi-directional TCP
connection and wP2P as a function of bit error rate.
The wP2P algorithm requires the receiver to know the
sender’s congestion window. In the simulation we as-
sume the receiver side can obtain the current sender
side congestion window size. Based on this value, the
receiver opportunistically adapts the piggybacking of
ACKs. In real life, TCP behavior inference tools such
as TBIT [20] can be used to identify the sender side con-
gestion window size at the receiver. With increasing bit
error rates, the packet loss rates increase and results in
smaller congestion windows. In this case uni-directional
TCP will give the best performance because ACKs suf-

17
0 0.2 0.4 0.6 0.8 1
x 10
−5
0
50
100
150
200
Bit Error Rate
Throughput(Kbps)
Uni−directional
Bi−directional
wP2P
(a) Impact of BER
11 11.5 12 12.5 13 13.5 14 14.5 15
0
5
10
15
20
25
Time
Numberofpackets
Buffer drop
(b) Microscopic-view of packets
0 0.5 1 1.5
x 10
−5
0
5
10
15
20
25
30
35
Bit Error Rate
Throughput(Kbps)
Default P2P
wP2P
(c) Impact of BER
Fig. 12 Age-based Manipulation: Simulation results (a,b) and Prototype results (c)
fer lesser losses than in the bi-directional case. wP2P
performs very close to uni-directional performance.
In bi-directional TCP flows, we observe that the
number of packets in transit originating from the mo-
bile host does not reduce even when congestion occurs.
Figure 12(b) shows the number of packets sent by the
mobile host running wP2P at different times when there
is a bi-directional TCP flow between the mobile host
and a wired host. We also show the congestion events
on the same graph. We observe that when a congestion
event (i.e., buffer drop at the AP) happens the number
of packets in transit decreases for wP2P, albeit with a
small time shift. This is because of the time taken for
the information about the congestion event to reach the
mobile host.
• Prototype Results. wP2P addresses the problems
of Bi-directional TCP in wireless environments using
the AM component. We study the impact of this com-
ponent under varying random loss conditions emulated
by varying the BERs ranging from 0 to 1.5e−5
. We com-
pare the download rates observed and show the aver-
aged results in Figure 12(c). We observe that wP2P
outperforms the default CTorrent under all bit error
rates because decoupling ACKs result in smaller ACK
losses for the connection, and in turn, larger through-
put. Specifically, with all the four BER values, wP2P
achieves about 15% to 20% more throughput.
5.4 Incentive Aware Operations
For evaluating the benefits of the LIHD algorithm in
wP2P, we study the download throughput by varying
two different parameters: α (i.e., Upload increment)
and bottleneck bandwidth. We compare wP2P for two
different upload rates, 50kbps and 800kbps, signifying
low and high uploads. Figure 13(a) shows the effect
of different bottleneck bandwidths. In the Figure, two
default-P2P clients having fixed uploading rate are com-
pared to wP2P. At low bottleneck bandwidths all three
show similar download rates. This is because of the con-
tention between uploads and downloads. However when
the bottleneck bandwidths are higher, wP2P adapts to
higher uploading rate, which leads to more downloads
and thus wP2P achieves maximum download rate. In
Figure 13(b) we vary the incentive parameter α. A large
value of α results in higher downloads even for small up-
loads. wP2P would operate at the optimal upload rate
that results in maximum download rates. We find that
wP2P gives the best performance for all values of α.
Figure
Figure 13(c) shows the total downloaded size as a
function of time for default-P2P where incentives are
lost during connection disruptions (due to mobility)
and wP2P where incentives are maintained. We as-
sume that the connection disrupts every one minute.
For default-P2P whenever incentives are lost the down-
load rate is reset to the minimum value unlike in wP2P
where the incentives are maintained. Thus we find a
larger total downloaded size for the same time using
wP2P.
• Prototype Results. As discussed in the previous
section identity retention and LIHD rate control ad-
dress the issue of failure or loss of incentives. To eval-
uate the benefits of LIHD we vary the bandwidth of
the wireless emulator from 50Kbps to 200Kbps. Figure
14(a) shows the averaged results over 10 runs for the
case when α = β = 10Kbps (refer to Section 4 for def-
initions of α and β). We observe that, initially as the
available bandwidth increases both wP2P and the de-
fault client show increased download throughput, but
beyond a certain point the default client starts losing
achieved throughput. With a bottleneck bandwidth of
200Kbps we observe that wP2P outperforms the default
by as much as 70%.
To evaluate identity retention we use the two CTor-
rent clients to simultaneously download a Fedora-7-KDE-
Live-i686.iso image [13], a 688MB file shared among
more than two hundreds peers when our experiments
were conducted. The IP addresses of the two clients are
changed every one minute to emulate mobility. Figure
14(b) shows the total downloaded size of a typical run
for these two peers. The downloaded size is plotted as a
function of time. After 50 minutes of download we ob-

18
0.2 Mbps 0.5 Mbps 1 Mbps 2 Mbps 50 Mbps
0
20
40
60
80
100
120
140
160
180
200
Different Bandwidth (α=10)
Throughput(Kbps)
Default P2P (Upload 50 Kbps)
wP2P
(b) Impact of physical bandwidth
4 6 8 10 12
0
20
40
60
80
100
120
140
160
180
200
α
Throughput(Kbps)
wP2P
(a) Impact of α
0 2 4 6 8 10 12 14 16
0
20
40
60
80
100
120
DownloadedSize(MB)
Time (Minutes)
Default P2P
wP2P
(c) Maintaining incentives
Fig. 13 Incentive aware Operations: Simulation results
50 100 150 200
0
20
40
60
80
100
Physical Wireless Bandwidth (Kbps)
Default P2P
wP2P
(a) Impact of physical bandwidth
0 10 20 30 40 50
0
100
200
300
400
500
Downloading Time (Minutes))
DownloadedSize(MB)
Default P2P
wP2P
(b) Maintaining incentives
Fig. 14 Incentive aware Operations: Prototype results
serve that wP2P downloaded about 100MB more than
the default.
5.5 Mobility-Aware Fetching
Mobility-aware Fetching is capable of achieving two ben-
efits from the client’s perspective: enhanced playable
percentage and improved downloading time. We show
the effectiveness of adaptive fetching in Figures 15 (a)
with respect to the playable percentage. The figure shows
the result of a 100 MB file. We observe that adaptive
fetching can achieve far better performance than de-
fault P2P fetching. For instance, when 50% of data has
been downloaded, Adaptive fetching can achieve about
20% of playable percentage; on the contrary, default-
P2P fetching only attains 1.4%: a 14-fold difference.
• Prototype Results. Figures 15 (b) shows the re-
sults of the Mobility-aware Fetching of the content be-
ing downloaded and compare them against the default
rarest first fetch algorithm. The results are averaged
over 20 runs. In these experiments we set the value of
pr (i.e., the rarest-first fetching probability) to be equal
to the downloaded percentage of file. We observe that
MF can achieve significantly better performance com-
pared to the default P2P. For instance when 50% of
the data has been downloaded, MF can result in about
20% of playable content while the default rarest first
technique can achieve only about 0.5%.
6 Related Work
6.1 P2P Data Sharing Networks
Peer-to-peer data sharing networks have evolved in the
way content searches and data transfer are performed.
The first generation of P2P data sharing networks such
as Usenet, Napster, etc performed a centralized search
for content. The second generation of P2P networks
like Gnutella [10] and FastTrack [11] use decentralized
content searches. The third generation of P2P data net-
works (eDonkey [9], BitTorrent [2]) use both distributed
searches and multiple downloads from several peers to
accelerate the content fetching process.
6.2 P2P Enhancements
There are many works in literature that propose to im-
prove performance of P2P systems. Some of these works
focus on incorporating better incentive schemes to en-
courage cooperative behavior and penalize free riders.
Reputation-based trust systems ([21–23]) and key shar-
ing protocol ([24]) are works in this category and these
work try to prevent non-contributing nodes from gain-
ing undeserved benefits from the system. Other work
([25,26]) design mechanisms to generate unique peer-
IDs that feature desired properties. Some work ([27–
30]) analyze the performance characteristics of the Bit-
Torrent protocol. In comparison with these works, our
work is focused on the unique challenges arise as mobile
hosts join the p2p networks. These challenges are not
seen in fixed hosts and in wired networks. For instance,
0 20 40 60 80 100
0
20
40
60
80
100
Default P2P
wP2P
(a) Simulation results
0 20 40 60 80 100
0
20
40
60
80
100
Default P2P
wP2P
(b) Prototype results
Fig. 15 Mobility-aware Fetching (100 MB files)

19
we deal with the incentive loss problem experienced by
mobile hosts instead of proposing a new incentive mech-
anism.
Recently more and more p2p users go mobile and
are connected with wireless links. The authors in [6]
analyze the traffic pattern of a well-established 802.11
WLAN network and show that P2P traffic including
P2P data sharing and streaming has increased dramat-
ically. The authors in [31] propose a cross-layer opti-
mization of Gnutella for deployment in purely mobile
ad hoc networks. [32] designs an algorithm to select a
new resource provider for mobile peers when mobility
occurs to the remote peers. Our work on the other hand
looks at the effect of mobile peers on an existing P2P
network.
6.3 Mobility
Works abound to address the mobility issue. Mobile
IP (RFC 2002) [14] is the current IETF standard for
supporting mobility on the Internet. It provides trans-
parent support for host mobility by inserting a level
of indirection into the routing architecture. Work [33]
deals with end-to-end applications and designs an ar-
chitecture for Internet host mobility. It uses dynamic
updates to the Domain Name System to track host
location. Work [34] addresses the issue of mobility in
an ongoing transport connection by providing trans-
parent network connection mobility using reliable sock-
ets (rocks) and reliable packets (racks). In work [35] a
mobility-aware file system for partially connected oper-
ation is presented. Specifically, it allows applications to
maintain consistency on only the critical portions of its
data files. In work [32] the authors design an algorithm
to select a new resource provider for mobile peers when
mobility disconnects remote peers. In comparison, our
work looks at issues faced by generic P2P data shar-
ing applications on mobile hosts, identifying a variety
of challenges that arise when mobile hosts join the P2P
networks and act as P2P server.
6.4 PSM
Power save mode in 802.11 is proposed to save en-
ergy on mobile clients. To maximize the efficiency of
PSM, work in [36] proposes BSD (bounded slowdown)
to adapt sleeping durations depending on past activities
to ensure no connections are punished more than a fac-
tor of p. Work in [37] suggests a set of design elements
to turn on or off power save mode according to appli-
cations. Work in [38] introduces proxies to buffer data
in order and proposes a new scheduling algorithm to
decide which flow should be served at which time, thus
mobile clients can sleep as long as possible. Similarly
[39] performs traffic shaping for applications and help
the prediction approach more efficient. Work [40] ad-
justs the waking up and sleeping time of the NIC based
on prediction of the next incoming packets. In stream-
ing systems, this approach is less effective because data
are typically received continuously. One solution is to
transmit data packets as bursts, which allows NIC to
sleep more time between bursts. However the bursty-
ness may cause unnecessary congestion. Work [41] stud-
ies these impacts and adapt burst length to achieve im-
proved trade-off between power efficiency and conges-
tion tolerance.
7 Conclusion and Future Work
In this paper we have investigated the issues with using
mobile hosts as peers in the P2P network. We identify
several insights into the issues such hosts face using a
real-life BitTorrent P2P data network. We then pro-
pose a solution called wP2P that significantly improves
performance.
Open research issues include the exact translation
of the solutions to other P2P data networks, and con-
sideration of the issues and solutions for other wireless
network environments.
Acknowledgements We thank all anonymous reviewers for their
valuable comments.
References
1. “Peer-to-peer in 2005,” CacheLogic, http://www. cachel-
ogic.com/home/pages/research/p2p2005.php, 2005.
2. “Bittorrent,” http://www.bittorrent.org/.
3. “Mandriva distribution,” http://www.mandriva.com/en
/download.
4. “Fedora distribution,” http://fedoraproject.org/en/get-
fedora.
5. “Arch linux,” http://www.archlinux.org/download/.
6. T. Henderson, D. Kotz, and I. Abyzov, “The changing us-
age of a mature campus-wide wireless network,” in MobiCom
’04: Proceedings of the 10th annual international conference
on Mobile computing and networking, New York, NY, USA,
2004.
7. “A new type of radio,” Roadcasting, http://www. roadcast-
ing.org/.
8. “Melodeo’s mobile phone p2p to launch,” Ringtonia,
http://www.ringtonia.com/.
9. “edonkey2000,” http://en.wikipedia.org/wiki/EDonkey2000.
10. T. Klingberg and R. Manfredi, “Gnutella 0.6,” Gnutella
Protocol Development, http://rfc-gnutella.sourceforge.
net/src/rfc-0-6-draft.html, 2002.
11. “Fasttrack,” http://en.wikipedia.org/wiki/FastTrack.
12. “Netfilter project,” http://www.netfilter.org/.
13. “Torrent server for the fedora project,” http://torrent. fedo-
raproject.org/.
14. C. Perkins, “Mobile IP,” IEEE Communications Magazine,
vol. 40, no. 5, pp. 66–82, May 2002.

20
15. H.-Y. Hsieh, K.-H. Kim, and R. Sivakumar, “On achieving
weighted service differentiation: An end-to-end perspective,”
in IEEE IWQoS ’03: Proceedings of the International Work-
shop on Quality of Service, Monterey, CA, USA, 2003.
16. “Winpkfilter,” http://www.ntkernel.com/.
17. “The network simulator,” http://www.isi.edu/nsnam/ns.
18. “Enhanced ctorrent, a lightweight c++ implementation,”
http://www.rahul.net/dholmes/ctorrent/.
19. K. Fall, “Network emulation in the vint/ns simulator,” in
ISCC ’99: Proceedings of the The Fourth IEEE Symposium
on Computers and Communications, Washington, DC, USA,
1999.
20. J. Pahdye and S. Floyd, “On inferring tcp behavior,” in SIG-
COMM ’01: Proceedings of the 2001 conference on Applica-
tions, technologies, architectures, and protocols for computer
communications, New York, NY, USA, 2001.
21. M. Srivatsa, L. Xiong, and L. Liu, “Trustguard: countering
vulnerabilities in reputation management for decentralized
overlay networks,” in WWW ’05: Proceedings of the 14th
international conference on World Wide Web, New York,
NY, USA, 2005.
22. C. Dellarocas, “Immunizing online reputation reporting sys-
tems against unfair ratings and discriminatory behavior,” in
EC ’00: Proceedings of the 2nd ACM conference on Elec-
tronic commerce, New York, NY, USA, 2000.
23. Q. Lian, Z. Zhang, M. Yang, B. Y. Zhao, Y. Dai, and X. Li,
“An empirical study of collusion behavior in the maze p2p
file-sharing system,” in IEEE ICDCS ’07: Proceedings of
27th IEEE International Conference on Distributed Com-
puting Systems, 2007.
24. Z. Zhang, S. Chen, and M. Yoon, “March: A distributed in-
centive scheme for peer-to-peer networks,” in IEEE INFO-
COM ’07: Proceedings of the 26th IEEE International Con-
ference on Computer Communications, Anchorage, Alaska,
USA, 2007.
25. 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 ’06: Proceedings of 27th
IEEE International Conference on Distributed Computing
Systems, 2006.
26. L. Lu, J. Han, L. Hu, J. Huai, Y. Liu, and L. M. Ni, “Pseudo
trust: Zero-knowledge based authentication in anonymous
peer-to-peer protocols,” in IPDPS ’07: Proceedings of the
21th IEEE International Parallel and Distributed Process-
ing Symposium, 2007.
27. D. Qiu and R. Srikant, “Modeling and performance analysis
of bittorrent-like peer-to-peer networks,” in SIGCOMM ’04:
Proceedings of the 2004 conference on Applications, tech-
nologies, architectures, and protocols for computer commu-
nications, New York, NY, USA, 2004.
28. A. R. Bharambe, C. Herley, and V. N. Padmanabhan,
“Some observations on bittorrent performance,” SIGMET-
RICS Perform. Eval. Rev., 2005.
29. A. Legout, N. Liogkas, E. Kohler, and L. Zhang, “Cluster-
ing and sharing incentives in bittorrent systems,” in SIG-
METRICS ’07: Proceedings of the 2007 ACM SIGMETRICS
international conference on Measurement and modeling of
computer systems, New York, NY, USA, 2007.
30. N. Parvez, C. Williamson, A. Mahanti, and N. Carls-
son, “Analysis of bittorrent-like protocols for on-demand
stored media streaming,” SIGMETRICS Perform. Eval.
Rev., 2008.
31. M. Conti, E. Gregori, and G. Turi, “A cross-layer optimiza-
tion of gnutella for mobile ad hoc networks,” in MobiHoc
’05: Proceedings of the 6th ACM international symposium
on Mobile ad hoc networking and computing, New York, NY,
USA, 2005.
32. C.-M. Huang, T.-H. Hsu, and M.-F. Hsu, “A file discov-
ery control scheme for p2p file sharing applications in wire-
less mobile environments,” in ACSC ’05: Proceedings of the
Twenty-eighth Australasian conference on Computer Sci-
ence, 2005, pp. 39–47.
33. A. Snoeren and H. Balakrishnan, “An end-to-end approach
to host mobility,” in Proceedings of ACM MOBICOM,
Boston, MA, USA, Aug. 2000.
34. V. C. Zandy and B. P. Miller, “Reliable network connec-
tions,” in MobiCom ’02: Proceedings of the 8th annual in-
ternational conference on Mobile computing and networking,
New York, NY, USA, 2002.
35. D. Dwyer and V. Bharghavan, “A mobility-aware file sys-
tem for partially connected operation,” SIGOPS Oper. Syst.
Rev., 1997.
36. R. Krashinsky and H. Balakrishnan, “Minimizing energy for
wireless web access with bounded slowdown,” in MobiCom
’02, New York, NY, USA, 2002.
37. M. Anand, E. B. Nightingale, and J. Flinn, “Self-tuning wire-
less network power management,” in MobiCom ’03: Proceed-
ings of the 9th annual international conference on Mobile
computing and networking, New York, NY, USA, 2003.
38. H. Zhu and G. Cao, “On supporting power-efficient stream-
ing applications in wireless environments,” IEEE Transac-
tions on Mobile Computing, 2005.
39. S. Chandra and A. Vahdat, “Application-specific network
management for energy-aware streaming of popular multi-
media formats,” in Proceedings of the General Track: 2002
USENIX Annual Technical Conference, Berkeley, CA, USA,
2002.
40. H. Yan, R. Krishnan, S. A. Watterson, and D. K. Lowenthal,
“Client-centered energy savings for concurrent http connec-
tions,” in NOSSDAV ’04: Proceedings of the 14th interna-
tional workshop on Network and operating systems support
for digital audio and video, New York, NY, USA, 2004.
41. J. Korhonen and Y. Wang, “Power-efficient streaming for
mobile terminals,” in NOSSDAV ’05: Proceedings of the in-
ternational workshop on Network and operating systems sup-
port for digital audio and video, New York, NY, USA, 2005.

Mobile Hosts Participating in Peer-to-Peer Data Networks: Challenges and Solutions

More Related Content

What's hot (15)

Viewers also liked (20)

Similar to Mobile Hosts Participating in Peer-to-Peer Data Networks: Challenges and Solutions (20)

More from Zhenyun Zhuang (7)

Recently uploaded (20)

Mobile Hosts Participating in Peer-to-Peer Data Networks: Challenges and Solutions