DTIC ADA436255: Exchange-Based Incentive Mechanisms for Peer-to-Peer File Sharing

0.16 MB·English

by  Defense Technical Information Center

1
Exchange-based Incentive Mechanisms for
Peer-to-Peer File Sharing
Kostas G. Anagnostakis and Michael B. Greenwald
CIS Department, University of Pennsylvania
200 S. 33rd Street, Philadelphia PA 19104, USA
anagnost,mbgreen @dsl.cis.upenn.edu
(cid:0) (cid:1)
Abstract—Performance of peer-to-peer resource sharing net- levels.However,this is easilysubvertedsincepeerscanclaim
works dependsuponthelevel of cooperation of theparticipants. anything with a simple modification to their software. In
To date, cash-based systems have seemed too complex, while
fact, such hacks are easily accessible [3] and widely used[4].
lighter-weight credit mechanisms have not provided strong in-
Other proposals to date require the use of a credit system
centives.
We propose exchange-based mechanisms for providing incen- which can be either centralized or decentralized. Centralized
tives for cooperation inpeer-to-peer file sharing networks.Peers mechanisms[5], [6] (e.g., using micropayments issued by a
give higher service priority to requests from peers that can trusted server or a centralized transaction clearing center)
provide a simultaneous and symmetric service in return. We
inheritthetypicaldisadvantagesofcentralizeddesigns(suchas
generalize this approach to -way exchanges among rings of
peers and present a search a(cid:0)lgorithm for locating such rings. indexing)in that they introducea single point of failure, may
We have used simulation to analyze the effect of exchanges on put a significant burden on a single peer and, perhaps most
performance.Ourresultsshowthatexchange-basedmechanisms importantly, it may be hard to design the right incentives for
can provide strong incentives for sharing, offering significant one or more peers to take up such a demandingand sensitive
improvements in service times for sharing users compared to
role.Recentproposalsfordecentralizedcreditmechanisms[7],
free-riders, without the problems and complexity of cash- or
[8]arebasedondistributedhashtables(DHTs)[9],[10],[11]
credit-based systems.
and therefore inherit another set of problems. For instance,
heterogenousnode capabilities make efficient allocation deci-
I. INTRODUCTION sionshard,transientpeerparticipationmaysignificantlystress
Peer-to-peer systems provide a powerful infrastructure for reconfiguration performance, and there are known classes of
large-scaledistributedcomputingapplications,mainlybecause attacks that are likely to be directed against the credit system
of the wide-spread cooperative resource sharing among par- service given its importance[12].
ticipants. Cooperation and the existence of a critical mass As an alternative,we proposea more lightweight approach
of participants with sufficient resources are key elements for that avoids the complexities of credit mechanisms. Rather
enabling a variety of novel applications such as file sharing, than building a system based on principles of monetary or
large-scale content distribution, and distributed data process- crediteconomies,westructurethesystemas a moreprimitive
ing. Performance in such systems depends on the level of exchange or barter economy. Users directly trade resources
cooperationby the system’s participants. While most existing between themselves, so little or no long-term bookkeeping
peer-to-peer architectures have assumed that participants are is required. Requests from peers that can provide a simul-
generally cooperative,there is growing evidence from widely taneous,symmetric,service in return(exchangetransfers) are
deployed systems suggesting the opposite. For instance, one given higher priority. The service need not be directly to the
study of the Gnutella file sharing system shows that almost provider (a pairwise exchange), but more generally priority
70% of the peers only consume resources and do not share is given to peers who participate in -way exchanges to
any files with the network[1]. The result of this kind of non- which the provider currently belongs. (cid:0)-way exchanges are
cooperation can vary between tolerable service degradation implemented as rings of peers, whe(cid:0)re each peer is served
and complete system collapse dependingon design goals and by its predecessor and se(cid:0)rves its successor in the ring. Non-
performance requirements. exchange transfers are only served if no other exchange is
Such problems have recently motivated work on incentive possibleandpeershavesparecapacity.Thepreferencegivento
mechanisms for peer-to-peer systems that stimulate cooper- exchangetransfersprovidesastrongincentiveforparticipants
ation between self-interested participants. Systems such as to cooperate.
KaZaA[2] attempted some rather naive methods where each The rest of the paper is organizedas follows. In Section II
peer announces its “participation level”, computed locally we describe prior work on incentive mechanisms in peer-to-
as a function of uptime, download and upload volume, and peer systems, and discuss the complexities of credit-based
give priority to remote peers that claim high participation systems and the limited effectiveness of the incentives in
lighter-weightsystems.InSectionIIIwepresenttheproposed
This work was partially supported by the DoD University Research Ini-
exchange mechanisms and discuss several key design issues
tiative (URI) program administered by the Office of Naval Research under
GrantN00014-01-1-0795. with respect to efficiency and security. In Section IV we
Report Documentation Page Form Approved
OMB No. 0704-0188
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it

does not display a currently valid OMB control number.
1. REPORT DATE 3. DATES COVERED
2005 2. REPORT TYPE -
4. TITLE AND SUBTITLE 5a. CONTRACT NUMBER
Exchange-based Incentive Mechanisms for Peer-to-Peer File Sharing
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S) 5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 8. PERFORMING ORGANIZATION
Office of Naval Research,800 N. Quincy Street,Arlington,VA,22217 REPORT NUMBER
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES) 10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
The original document contains color images.
14. ABSTRACT
Performance of peer-to-peer resource sharing networks depends upon the level of cooperation of the
participants. To date, cash-based systems have seemed too complex, while lighter-weight credit
mechanisms have not provided strong incentives. We propose exchange-based mechanisms for providing
incentives for cooperation in peer-to-peer file sharing networks. Peers give higher service priority to
requests from peers that can provide a simultaneous and symmetric service in return. We generalize this
approach to ��-way exchanges among rings of peers and present a search algorithm for
locating such rings. We have used simulation to analyze the effect of exchanges on performance. Our
results show that exchange-based mechanisms can provide strong incentives for sharing, offering
significant improvements in service times for sharing users compared to free-riders, without the problems
and complexity of cash- or credit-based systems.
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF: 17. LIMITATION OF 18. NUMBER 19a. NAME OF
ABSTRACT OF PAGES RESPONSIBLE PERSON

a. REPORT b. ABSTRACT c. THIS PAGE 10
unclassified unclassified unclassified
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
presentasimulationstudyanalyzingtheexchangemechanisms for the request, as well the upload and downloadvolumes for
and their effect on file sharing system performance. In Sec- the peer. The main advantage of this scheme is simplicity:
tion V we discuss open issues and directions for extending there is no communicationoverheadand a peer onlyneeds to
the results presented here. We summarize and conclude in maintaintheuploadanddownloadvolumesforeachpeerithas
Section VI. communicated. The approach is cheat-proof in the sense that
peers have no reason to tamper with the credit file. However,
anecdotal evidence[16] suggests that the approach does not
II. RELATEDWORK
consistently provide a clear performance advantage to users
The first known use of payment-based incentive mecha- who contribute resources to the network. Although there is
nisms in peer-to-peer file sharing was in the now defunct no clear evidence in terms of measurements to determine
MojoNation network[5]. Each user was given an initial en- precisely why this is happening, the credit approach appears
dowment called Mojo which he could spend on purchasing to have two main limitations.
files from other peers. The main limitations of this approach First, it is hard for a peer to strategize in terms of what
isthatalltransactionshadtobeclearedinacentralizedsystem, peers he wants to earn credit from in order to maximize ex-
and users were burdened with managing their Mojo. pectedbenefits.Alargefractionofpeersmaybedisconnected
A distributedcash-basedsystemforpeer-to-peersystems is resulting in delays in rewarding credit; other peers may leave
presented in [7]. The system uses a currency called karma thesystempermanently,resultinginlossofcredit;othersmay
which is maintained for each user by a collection of random not have any object the peer is interested in, and some may
participants called a bank-set that is located using a DHT not share content at all. The use of “waiting time” as a factor
lookup. Users need to negotiate the price of serving an in computing queue rank further complicates this problem. It
object through an auction mechanism, and coordinate with results in giving weaker performanceadvantage to users with
the bank-set for transferring karma between accounts. Each establishedcredit,aspeersthatdonothaveanycreditcanstill
user receives an initial amount of karma when signing up use the system if they are patient enough.Tuning the scoring
withthesystem,andthesystemensuresthattherateatwhich function to reduce the effect of waiting time is possible, but
users can create new identities is limited through the use of resultinneverservingusersthatdon’thaveestablishedcredit,
a cryptographic puzzle. To address inflation or deflation, the evenifestablishingcreditwiththosepeerscouldbebeneficial
system needs to periodically normalize the total amount of in the future.
currencyinthesystem.Theresultis afully-fledgedeconomic One practical workaround to address this problem1 is to
system that is in principle more flexible than an exchange
control the set of shared files in a way that increases credit
system. In an idealized setting, a cash-based scheme may be
with peers likely to be useful for a given set of requests in
abletoofferastrongerperformanceadvantagetocontributing
the near future. For instance, if a peer is requesting an object
peers,asitisnotsubjecttothe“doublecoincidenceofwants”
in category , then it makes sense to limit sharing to only
constraintthatdrivesexchanges.Inpracticehowever,thecash- thoseobjects(cid:1)thatarealreadyavailableandbelongtocategory
based approach has two main limitations.
. Assuming that remote peers sharing the requested object
First, it suffers from all the complexities of currency man- (cid:1)are likely to request objects from the same category,the peer
agement. If the mechanisms used to negotiate prices, adjust is more likely to earn credit and therefore improve queue
accountstoinflationanddeflationandmanageauser’sbudget rankand reducewaitingtime onthose peers. In this scenario,
are not made completely transparent to the user, then such the credit system essentially approximates exchanges, at the
a system is likely to have a high cost in terms of user cost of additional effort to get the conditions right for this to
attention[13] which is suggested as a major reason why happen.
micropaymentschemesareunlikelytogetwideracceptancein
A second problem with the pairwise credit system is that
general[14]. The feasibility of such mechanisms has not been
there is no clear incentive for individual peers to cooperate
proven to date.
in supporting the credit system, although this approach could
Second, the need to provide start-up funds to new users
in principle lead to a better global operating point. There
creates a potential loophole in the economy. Specifically, the
is also no strong individual incentive not to honor credit,
cryptographic puzzle used for protecting against the creation
but in practice certain variants of the eMule client do not
of newuser identifiersandtransferof creditto existingactive
support the credit system, which also means that a fraction
users may not be sufficient, as it may not be able to offer a
ofthecreditearnedessentiallygetslost.Themechanismdoes
satisfactory trade-off between keeping fake accounts out and
not directly penalize clients for this type of defection, and
allowing legitimate new users in. In essence, it is possible to
building additional protection (e.g., monitoring compliance
earn cash in return for CPU cycles, without doing any useful
and maintaining blacklists) adds complexity.
work for the system.
In [17] the authors argue that peer-to-peer “bartering”
A lightweight, pair-wise credit system is implemented in
is an appropriate way to bootstrap peer-to-peer economies,
the eMule system[15]. The goal of the credit system is to
focusing on systems like PlanetLab[18] where peers share
reward users contributing to the network by reducing their
basic resourceslike computing,storageandnetworkcapacity.
waiting time in the upload queue. For each request in the
upload queue the peer computes the Queue Rank based on
1Thishasbeensuggestedonmessageboardsasastrategythathasworked
a scoring function that depends on the current waiting time inpractice.
2
P2...Pn-2
Theyproposetheexchangeofsignedresourceticketsbetween
system participants that can be stored, traded and used for
allocating resources. Strictly speaking, this is closer in spirit o1 P1 P2 o2 o1 P1 P3 o3 o1 P1 Pn-1on-1
to credit economies involving personal debt certificates than
barter.Thisapproachiswellsuitedforsystemswithasmallset
P2 Pn
ofhomogeneousresourceslike CPU, storageandnetworkca- o2 on
pacity.Insuchsystemstheexchangemechanismsareunlikely
to be useful, as there is little meaning in instant exchanges Fig.1. Pairwise,3-wayandn-wayexchanges
of same-type resources. In contrast, file sharing systems are
content-oriented, providing a high level of specialization in
Allexchangesareperformedonefixed-sizeblockatatime.
terms of the objects served by each peer. This fits well with
Transfers are terminated if one of the two communicating
the instant exchange model.
peersdisconnects,ifthetransferiscompleted,orifthesource
The work most closely related to ours is Bittorrent, a
deletestheobject.Itisquitecommonforonesidetoterminate
system for large-scale content distribution where peers ex-
first, when it completes its own download, because object
change blocks of the same file in an effort to expedite the
sizes may differ and the system allows partial and concurrent
distribution of large files [19]. The approach is more limited
transfers.
in that it only supports pairwise exchanges on the same file,
Non-exchangetransfers will only be served if no exchange
and appears to be vulnerable to freeriding middlemen (we
is possible and the peer has a free uploadslot, althoughthese
defer discussion of this flaw and solutions to Section III-
slots will be reclaimed as soon as another exchangebecomes
B). No evidence is provided on the actual contribution of
possible. Peers who share more are more likely to be able
the exchange mechanism, as the system was not used at a
to participate in an exchange, directly rewarding them with
scale comparable to popular file-sharing systems to observe
faster transfers. Thus, the power of the proposed approach is
any substantial diversity in peer behavior. To the best of our
derivedfromtheprioritygivenbythesystemtoexchangeover
knowledge, our study is the first to investigate the effect of
non-exchangetransfers.
exchangemechanismsonpeerperformanceandtheirvalueas
an incentive mechanism in a file-sharing system.
A. Exchange transfers
Peersmustgiveprioritytoexchangetransfers.Itistherefore
III. EXCHANGEMECHANISMS
imperative that feasible exchanges be identified.
In this paper we consider a file sharing system where each Pairwise exchanges are easily detected. Each peer A reg-
peer has fixed upload and download capacity. The upload ularly examines its incoming request queue and determines
capacity is more likely to be the resource bottleneck than the if, for any pending request, the remote peer B has some
download capacity. To manage the upload link, we respond objectthatA is interestedinthatwouldqualifyfora pairwise
toallrequestsinrelativelylarge,equal,fixed-size,blocks.We exchange. Although pairwise exchanges are simple, unfortu-
assumethatthesystemsupportspartialtransfersandthatpeers nately,requestsfrequentlydonotresolveintoconvenientpairs.
can download different parts of the same object concurrently Fortunately, it is easy to compute feasible -way ex-
from multiple sources. To focus on the main point of this changes.Let bethedirectedgraphwhosevertice(cid:0)sarenodes
paper, we ignore the details of object lookup. We note that inthepeer-to(cid:2)-peersystem,andwhoselabelededgesrepresent
ourapproachcanworkwithseveralknownsearchmechanisms requests.Anedgefromnode to withlabel represents
includingbroadcastinGnutella-likenetworksoraDHTquery arequestfrom to forob(cid:3)je(cid:0)ct (cid:3)(cid:1).Itisclearth(cid:4)a(cid:0)tanycycle
insystemslikeChord.Whenapeerisinterestedinanobjectit of length in (cid:3)(cid:0)repr(cid:3)e(cid:1)sents a feas(cid:4)ib(cid:0)le -way exchange.
canuseoneofthesemethodstolocateuptoacertainfraction How ca(cid:5)n we(cid:2)compute cycles in , a(cid:5)potentially enormous
of peers that currently have the object. graph? First, we have empirically(cid:2)determined that -way
Each peer has an incoming request queue (IRQ) where exchanges, where , do not substantially improv(cid:5)e the
remote peers register their interest for a local file. A transfer likelihoodofsucces(cid:5)sfu(cid:6)le(cid:0)xchangesoverexchangeswhere
tosatisfyarequestisinitiatediftwoconditionsaremet.First, (seeSectionIV).Therefore,itissufficienttolimitthesea(cid:5)rc(cid:1)h
theremustbesufficientcapacityat bothpeersforthetransfer. (cid:0)for cycles to chains of up to 5 predecessors. Second, we note
The local peer must have upload capacity (an open fixed- that a request from in the incoming request queue of
size slot on the upload link), and the remote peer must have represents an edge in(cid:7) from to , and therefore pee(cid:8)rs
sufficient download capacity. Second, either the transfer is an already have informatio(cid:2)nabout a(cid:7)parti(cid:8)al local subgraphof .
exchangetransfer, or else no other requestin the IRQ is both Each peer maintains a request tree as follows. A peer w(cid:2)ith
an exchange transfer and satisfies the first condition. no incoming requests has an empty Request Tree. For peers
In practice, the local node does not check the download with non-empty incoming request queues, let each request in
capacity of the remote node, but assumes it is sufficient. the IRQ include the contents of its request tree (pruned to a
Inadequatedownloadcapacityterminatesthetransferwhenthe depth of 5). ’s Request Tree consists of an implicit root, ,
remotenodecannotreceiveitsincomingrequest,itterminates as the parent(cid:7)of the set of Request Trees accompanying ea(cid:7)ch
its outgoing upload, and issues the request again when a entry in the IRQ. Then, can initiate an -way exchange if
download is feasible. anypeerintheRequestT(cid:7)reeownsanyobjec(cid:5)tcurrentlydesired
3
by . If a suitable peer is found, and that peer appears at
A
dept(cid:7)h in the tree (the depth includes as the root), then
we can(cid:5)construct a ring of peers, f(cid:7)or , each o1 o2 o3
carryingobject andreques(cid:5)tingobjec(cid:9)t(cid:1) (cid:2) (cid:0) (cid:10).(cid:11)Ea(cid:5)chpeer P2
P1 P4
providesanobje(cid:4)c(cid:1)ttotheirpredecessoran(cid:4)d(cid:2)(cid:1)(cid:3)ge(cid:0)t(cid:4)s(cid:2)a(cid:3)n(cid:4)(cid:5)objectfrom
their successor. o8
o5 o6 o7
o4
inspectstheRequestTreebeforetransmittinganyrequest
and(cid:7)after receiving each request. Prior to transmission of a P11 P5 P6
P9 P3
request for object , inspects the entire Request Tree to
see if any peer pro(cid:4)v(cid:0)ide(cid:7)s . On receipt of each request, , o9 o10 o11
need only inspect the inc(cid:4)o(cid:0)ming Request Tree associated (cid:12)wit(cid:7)h
P10 P7 P8
—butitchecksthepeersintheRequestTreeforanyobject
t(cid:12)hat still wants.
(a)
No(cid:7)te that at the time decides to request object it
“discovers” a (possibly inc(cid:7)omplete) set of peers who pro(cid:4)v(cid:0)ide
A
object , but it actually issues requests to only a subset of
those p(cid:4)e(cid:0)ers. It can use the original provider list to compute a o1 o2 o3
cyclecontainingapeer, ,evenifitdidnotoriginallytransmit
P2
arequestto .Atthein(cid:3)it(cid:1)ialrequesttime, hadnopreference P1 P4
for becaus(cid:3)e(cid:1) hadnowayofknowingth(cid:7)at wasapotential o8
part(cid:3)ic(cid:1)ipant in a(cid:7)n -way exchange. (cid:3)(cid:1) o4 o5 o6 o7
In practice, (cid:5)must circulate a token through the proposed
P11 P5 P6
ring to determ(cid:7)ine whether everyone is still willing to serve. P9 P3
The ring can be invalid for several reasons. First, in the time
o9 o10 o11
between the original requests and the ring initiation attempt,
some peers may have gone offline, or crashed. Second, other P10 P7 P8
peers may have already constructed rings of their own, in-
cluding some of ’s intended participants (it is possible that (b)
several peers alon(cid:7)g the intended cycle will attempt to create
the same ring roughly simultaneously). Fig. 2. can be served by some object on P9. The entire request tree
Aninterestingquestionishowtoprioritizedifferentfeasible is shown i(cid:0)n (a). The cycle for the 3-way exchange that tries to initiate
is shown in (b). P3 may have simultaneously discovered (cid:0)a cycle through a
exchanges that can satisfy a given request. In principle, a
target ofP2other than .Bothringsneed P2,soonlyonewill beinitiated
preference for larger rings should have a positive effect on successfully. (cid:0)
overall performance, as more peers are served. On the other
hand, peers would prefer smaller rings as the search cost is
lower, and the expected exchange volume is also more likely assume a new identitythat is not blacklisted,as is the case in
to be higher for smaller rings, as the probability of a peer most file sharing systems today[20].
either disconnecting or completing is higher for larger rings. It is possible to limit the damage done by cheating by
Assuming peers care less about globalperformanceand more exchangingblockssynchronouslyandvalidatingeachreceived
about their own benefit, there is no clear incentive to put block before transferring the next one. This requires a trust-
additional effort into looking for larger rings when even a worthysourceofinformationfortheactualvalidchecksumsof
pairwise exchangehas been locatedthat has equal (orhigher) the blocks being probed. The maximum benefit for a cheater
expected utility. in this case would be equal to the block size. If the block
size is bytes and the round-trip time between the
two pee(cid:13)r(cid:0)s(cid:6)i(cid:7)s(cid:8)(cid:9)(cid:5)(cid:10)(cid:0)seconds, this limits the maximum exchange
B. Preventing cheating rate to (cid:14)(cid:11)(cid:12)(cid:12) bytes/second. As this may be less than
Since the system gives priorityto exchangetransfers,mali- the slot(cid:13)(cid:0)c(cid:6)a(cid:7)p(cid:8)a(cid:9)c(cid:5)i(cid:10)ty(cid:0),(cid:15)(cid:14)p(cid:11)e(cid:12)e(cid:12)rs may want to use a window protocol
cious peers may attempt to cheat. For example, a peer could and increase the window size to fill up the slot capacity-
claim that there is an an exchangeable object available and delayproduct,at the expenseof increasingrisk. A reasonable
serve junk in exchange for real data. approachwouldbetostart theexchangewithasmall window
Several mechanisms can be used to address this problem. and increase after a number of rounds.A cheater would need
Peers can locally blacklist cheating peers and refuse to serve to have at least a few real blocks in order to increase the
them later. In a large and dynamic system this is likely to window. It is very likely that even this level of cooperation
be ineffective as cheaters may perform well enough even if would have a positive effect on the system as a whole.
they can cheat each peer only once. Cooperative blacklisting Another problem is that a peer could act as a middleman
couldhelp tacklethis problem,althoughit requiresadditional between two peers that could perform an exchange directly
mechanisms which may themselves be subject to attacks. In witheachother,andobtainanobjectwithoutdoinganyuseful
both cases, the problem persists if it is easy for a peer to workforthe system. Specifically,lets assume that peer has
(cid:7)
4
peer upload has wants
object andwantsobject ,andpeer hasobject andwants
A 10 - x
object(cid:16). The cheating pe(cid:17)er , inter(cid:8)ested in obje(cid:17)ct claims B 5 x y
thathe(cid:16)hasobject andwants(cid:1)object whentalkingt(cid:16)o ,and C 10 y x
that he has object(cid:17) and wants obje(cid:16)ct when talking(cid:7)to . D 10 y x
Peer wouldstartg(cid:16)ettingblocksof fr(cid:17)om andexchangi(cid:8)ng TABLEI
them(cid:1)forblocksof with whichin(cid:17)turna(cid:8)repassedto for EXAMPLEMIDDLEMANSCENARIORESULTINGINNON-RINGEXCHANGE
moreblocksof .I(cid:16)nthis s(cid:7)cenario,peer doesnotcontr(cid:8)ibute
any useful work(cid:17)to the system, and can(cid:1)still get high-priority
service. If this is allowed to happen,then the exchange-based
5 C y
incentives break down. 5
Tightercontrolisneededtoaddressthisproblem,involving 5
x B A
the use of a trusted peer as a mediator. Both directions of the 5
transfer can be encrypted,each with a secret key only known 5 D y
to the sendingpeer and the mediator.In the controlheaderof
each transfer block, the sending peer also includes a peer-of- Fig.3. Exampleofnon-ringexchange
originidentifier.Thecontrolheaderisalsoencrypted,sothata
middlemancannot modifyit. When the transferis completed,
thetrustedpeermediatestheexchangeofthesecretkeys,after cost, is useful for the system as a whole, and respects their
ensuring that neither side of the exchange has cheated. The desire not to store or share objects. For instance, considerthe
mediator can do this by verifying the validity of a certain scenario of Table I.
smallnumberofrandomlychosenblocksfromeachsideofthe Althoughpeer has no exchangeableobject, it is possible
transfer.Thekeysaresenttothepeersindicatedinthecontrol to substitute a pu(cid:7)re object exchange with a mixed object-
headerofthetest blocks.Inthisway,amiddlemanwouldnot capacity exchange as shown in Figure 3: peer sends to
beabletodecrypttheblockshepeddledbetweenthetwopeers (5 upload units), peer forwards to and(cid:8) (5 up(cid:16)load
in the scenario discussed above, and his participation in the (cid:7)units each for a total of(cid:7)10), and (cid:16)and(cid:1) sen(cid:18)d to (5
transfer would offer him no benefit. uploadunitseachforatotalof10).(cid:1)Inthis(cid:18)scenario,(cid:17)ther(cid:7)esult
One remaining issue with this approach is that the mid- isthesamefor and comparedtoapureobjectexchange,
dleman can initially obtain two blocks, one for each object but both and(cid:1) inc(cid:18)rease their utility, since gets object
peers and are interested in, and carry out small, one at a rat(cid:7)e of 10(cid:8)when he would normally on(cid:8)ly be able to
block t(cid:7)ransfers(cid:8)with each peer, and then presenting the newly (cid:17)get it at a rate of 5, and peer gets object at a rate of
acquired block for an exchange with the other peer. Since 5 when he would not be able t(cid:7)o participate at(cid:16)all in a pure
he starts this process with real data that is not encrypted, object exchange. Of course, this requires a generalization of
the protection offered by the mediator is not sufficient in theexchangemechanismtonon-ringtopologies,whichwedo
this case. Although we do not have a similar solution for not discuss or analyze further in this paper.
this problem, we argue that this way of increasing one’s
performance without doing useful work is unlikely to be
IV. SIMULATION
possible at a large enough scale to be practical for cheaters
A. Environment
as a general strategy, and a threat to the exchange-based
system. First, the cheating peer needs to wait in low-priority We simulate a small, 200-node file-sharing system where
queues to get the ’bait’ blocks anyway, for both files, adding each peer has fixed and asymmetric upload and download
some latency to the process. Second, the number of potential capacitye.g.theavailablecapacityisnotaffectedbyotheruser
“victim”peersdecreaseswiththenumberofblocksthecheater trafficandthereistypicallymuchmoredownloadthanupload
has available. Third, since the cheater needs to have two capacity. We assume that the core network is sufficiently
blocks,oneforeachpeer,heisalsoconstrainedbythenumber overprovisioned,delayandlossarenegligiblesothattheonly
of peer-pairs interested in those blocks. Fourth, the cheater is bottleneck in the system is a peer’s connection.
wasting his resources because he is using part of his upload The object popularity model is similar to the model pre-
capacity for an object that is totally useless to him. unless of sentedin[21].Objectsareorganizedincategories.Eachpeeris
courseheisinterestedinbothobjects.ifnot,hemaybebetter interested in categories, which are selected at initialization
off using this capacity for real exchanges. Fifth, the peers he time. The po(cid:19)pularity of a category of rank is computed as
is targeting are likely to be talking to each other already so i.e. the probability of (cid:10)a request for an
(cid:1)
they may be uninterested in what he has to offer, and they (cid:20)ob(cid:7)je(cid:1)ct i(cid:3)n(cid:15)(cid:4)c(cid:3)at(cid:5)ego(cid:10)(cid:21)r(cid:22)y(cid:7)(cid:6) is For each of the
(cid:1) (cid:1) (cid:2) (cid:13)
may have already committed all of their upload capacity to categories assign(cid:10)ed t(cid:3)o(cid:7)e(cid:1)ach(cid:20)(cid:7)p(cid:15)ee(cid:0)r(cid:13)w(cid:5)e(cid:6)(cid:20)a(cid:7)lso assign a local
eachother.Finally,additionalconstraintscanbedesignedinto p(cid:19)reference distribution with uniformly random weights for
the system to discourage this behavior, such as giving higher eachcategory.Thelocalpreferencedistributionisindependent
priority to longer exchanges. from global popularity. When a peer issues a request, it
Since users are considered to be self-interested rather than chooses a categorybased on the local preferencedistribution,
malicious,the best way to discouragethis behavioris to offer and then picks an object in that category, also based on a
an alternative that gives them better performance at a lower distribution where the popularity of an object of rank is
(cid:10)
5
number of peers 200
160
download capacity 800 kbit/s
upload capacity 80 kbit/s 140
ul/dl slot size 10 kbit/s es)
content categories 300 nut 120
mi
ocabtjeegcotsripese/rpeceartegory uunniiffoorrmm((11,,83)00) me ( 100
category popularity f=0.2 d ti 80
a
object popularity f=0.2 o
object size 20 MB (all objects) wnl 60
o
storage capacity per peer uniform(5,40) d
n 40
(nr. of objects) a
e
queue for incoming requests 1000 m 20
max pending objects 6
fraction of freeloaders in system 50% 0
140 120 100 80 60 40
TABLEII upload capacity (kb/sec)
BASICSIMULATIONPARAMETERS pairwise/sharing 2-5-way/sharing
pairwise/non-sharing 2-5-way/non-sharing
5-2-way/sharing no exchange
5-2-way/non-sharing
Fig.4. Meandownload timevs.uploadcapacity
computedas andtheprobabilityofarequest
(cid:1)
for an object(cid:20)in(cid:3) (cid:1)cat(cid:3)e(cid:15)g(cid:4)o(cid:3)r(cid:5)y (cid:10)(cid:21)(cid:22)is(cid:3)(cid:6) . For
(cid:1) (cid:1) (cid:2) (cid:13)
the distribution becomes u(cid:10)nifo(cid:3)r(cid:3)m(cid:1), a(cid:20)nd(cid:3)(cid:15)fo(cid:0)r(cid:13)(cid:5)(cid:6)(cid:20)(cid:3) it bec(cid:22)om(cid:1)e(cid:2)s resources are shifted to sharing users because we prioritize
zipf-like. Note that measurements of real-(cid:22)wo(cid:1)rld(cid:3)file-sharing exchanges over non-exchangesand so a larger fraction of the
systems suggest zipf-like locality[22]. upload resources can be given to users that can participate in
Each peer has up to a maximum number of pending exchanges. For 40 kbit/s upload capacity the use of pairwise
requests.Requestsaregeneratedfastenoughsothateachpeer exchangesresultsindownloadtimesforsharingusersthatare
reaches this maximum early enough in the simulation, and less than half of the download times for non-sharing users.
throughout an experiment a new request is issued as soon The use of higher-order exchanges in addition to pairwise
as a pending download is completed. As the factor of the (denoted as 2-5-way and 5-2-way in the graph) gives sharing
objectpopularitydistributionincreases, peersare incr(cid:22)easingly users four times better performance than non-sharing users.
likely to request an objectalreadyavailable locally.In reality, When using the exchange mechanism the improvement for
peers are unlikely to request objects they already have and sharing users is also significant compared to a system where
the effect of such “cache hits” on our measurements could noexchangemechanismsareintroduced(“noexchange”inthe
be misleading. To avoid such effects we therefore choose to graph): downloads are roughly twice as fast when exchanges
ignore hits and continue to generate candidate requests until are used. This observation suggests that sharing peers have a
a miss is found. This may shift the distribution of requests goodincentiveto deploy the proposedexchangemechanism.
more towards uniform, but the resulting bias is more on the In Figure 5 we present the fraction of exchange requests
conservative side. in the system as load increases. We see that the fraction of
Each peer can store up to a maximum number of objects. exchange requests increases almost linearly with load; as the
We initially place objects on each peer based on the peer’s object popularity model does not change, the difference is
categorypreferences.In regularintervals, peers examinetheir becauseas loadincreasesalargerfractionofthetransferslots
storage and remove random objects if the maximum number oneachpeeraregiventoexchangetransfers.We alsoseethat
of objects is exceeded. A peer postpones removing an object pairwise only performs slightly worse than 5-2-way and 2-5-
if it is used in an ongoing exchange. way. If peers aggressively seek out feasible longer exchange
ThesystemparametersforsimulationareshowninTableII. rings before resorting to shorter rings, the system performs
slightly better than if peers only look for longer rings when
no shorter rings are feasible.
B. Results
The benefit of seeking and using higher-order exchange
Thekeymetricforpeerperformanceinfilesharingsystems rings is shown in Figure 6. We observe that there is a
is object downloadtime. We thereforeobtain the meanobject significant difference between and , suggesting
download time for sharing and non-sharing users in a non- that higher-order exchanges a(cid:0)re (cid:1)ind(cid:0)eed v(cid:0)alu(cid:1)ab(cid:7)le. However,
exchange,pairwise,5-2-way(e.g.choosinglongerovershorter much larger rings ( ) do not offer any substantial
exchange rings), and 2-5-way (e.g. choosing shorter over improvement. (cid:0) (cid:6) (cid:0)
longer rings) exchange system. We first look at behavior as In Figure 7 we present the distribution of the amount of
loadinthesystemincreases.TheresultsareshowninFigure4. data transfered per session. We see that exchanges have a
As expected, as the upload capacity is reduced, the mean higher transfer volume, as normal transfer sessions tend to
download time increases for both sharing and non-sharing be canceled and replaced by exchanges.We also observethat
users,butincreasesfasterfornon-sharingcomparedtosharing the transfer volume is much higher for shorter rings than for
users. This happens because as the system gets more loaded, longer, as there is a higher probability of a peer completing
6
1 120
100
0.8
ns me 80
ssio 0.6 ad ti
e o
on of s 0.4 n downl 60
cti ea 40
a m
fr
0.2 20
0 0
1 2 3 4 5 6 7
140 120 100 80 60 40
Maximum exchange ring size N
upload capacity (kb/sec)
N-2-way / non-sharing 2-N-way / non-sharing
pairwise 5-2-way 2-5-way N-2-way / sharing 2-N-way / sharing
Fig.5. Fraction ofexchange transfersvs.uploadcapacity Fig. 6. Differentiation of mean download times for sharing vs. non-sharing
usersasafunction ofthemaximumexchange size
1 1
ns 0.75 ns 0.75
o o
si si
s s
e e
s s
of 0.5 of 0.5
n n
o o
cti cti
a 0.25 a 0.25
fr fr
0 0
0 5000 10000 15000 20000 0 50 100 150 200
amount of data transferred per session (kb) waiting time
non-exchange 4-way non-exchange 4-way
pairwise 5-way pairwise 5-way
3-way 3-way
Fig.7. CDFfortransferbytespertraffictype Fig.8. CDFfortransferstarting timespertraffictype
a transfer and therefore dropping the exchange when there exchanges.
are many peers compared to when there are only two peers.
Thishelpsexplainwhyhigher-orderexchangescontributeless We also determined the effect of the object popularity
thanpairwiseexchangestotheoverallimprovement.Notethat distribution on performance. In Figure 9 we show the mean
in the current simulation model peers always pick the first download time for different types of exchange configurations
feasible exchange in the search process. There may be other as a function of the object and category popularity factor .
feasibleexchangeswithalongerexpectedlife-cycle.Thus,the As expected, the difference in performance between sharin(cid:22)g
system could be modified for determining the best possible and non-sharing users increases as the factor approaches
exchange, at the expense of increased search time and cost. 1, resembling a zipf-like distribution, although(cid:22) the relative
benefit is significant even when object popularity is more
In Figure 8 we present the distribution of the waiting evenly distributed. In this experiment, the difference between
times for different classes of transfers. The waiting time for 5-2-way and 2-5-way exchanges becomes more clear, and
a session is the differencein time between the originalobject it seems that 2-5-way perform slightly better, not because
request and the start of a transfer. We see that waiting times they improve the performance of sharing users but because
for non-exchange transfers are substantially worse than for they reduce performance of non-sharing users. This happens
exchange transfers, as the system gives absolute priority to because exchange transfers displace non-exchange transfers
exchanges. This difference is the key reason why exchanges and 2-5-way are longer-lived on average than 5-2-way, even
providesignificantly better performanceto sharingusers. The if they have similar aggregate transfer volumes, as shown in
waitingtimeisonlyslightlyworseforhigher-orderexchanges Figure10.Becausetheyhavesimilartransfervolumestheydo
compared to pairwise exchanges, meaning that this is not not affect the performance of sharing users as much, but, as
the cause for the relatively smaller benefit of higher-order they are more long-lived, they tend to displace non-exchange
7
160 400
s) 140 350
e
ut 300
min 120 MB)
me ( 100 me ( 250
wnload ti 80 sfer volu 125000
o n
d 60 a
n tr 100
a
e
m 40 50
20 0
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
object popularity factor f object popularity factor f
pairwise/sharing 2-5-way/sharing pairwise/sharing 2-5-way/sharing
pairwise/non-sharing 2-5-way/non-sharing pairwise/non-sharing 2-5-way/non-sharing
5-2-way/sharing no exchange 5-2-way/sharing no exchange
5-2-way/non-sharing 5-2-way/non-sharing
Fig.9. Meandownload timevs.object popularity factor Fig.10. Transfervolume(MB)vs.object popularity factor
g
n
ari 4.5 160
h
s
nload time, sharing vs. non- 23..3455 wnload time (minutes) 1116802400000
w o
o 2 d
n d an 40
mea 1.5 me 20
p:
u
ed 1 0
pe 2 3 4 5 6 7 8 9 10 0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1
s
max. outstanding requests per peer fraction of non-sharing peers
cat/peer pairwise/sharing 2-5-way/sharing
2 4 8 pairwise/non-sharing 2-5-way/non-sharing
5-2-way/sharing no exchange
5-2-way/non-sharing
Fig. 11. Ratio of mean download times for different maximum pending Fig.12. Meandownloadtimesvs.fractionofnon-sharingpeersinthesystem
requestsizesandnumberofcategories eachpeerisinterested in
appear to be significant.
transfers for a longer time. These results indicate that giving We must note that since we do not explicitly model idle
preference to pairwise over higher-orderexchanges is a good peers that have no outstanding requests, this also provides an
engineering choice, in addition to being cheaper in terms of indirect measure of the effect of idle users on system perfor-
search cost. mance.Idleusersdonotparticipateinexchangesandtherefore
In Figure 11 we present the ratio of mean download times do not discriminate between sharing and non-sharing peers,
between sharing and non-sharing users as a function of the dampening the effect of exchanges on relative performance.
maximumnumberofoutstandingrequestsoneachpeeraswell The effect of the number of categories per peer is also
as the number of categories each peer is interested in. The significant,asitgenerallyincreasestheprobabilityoflocating
maximum number of outstanding requests increases system a feasible exchange. If the number of maximum outstanding
load,butalsoincreasesthenumberoffeasibleexchangesinthe requestsis small, theeffectappearsto be reversed,with more
system. Upto a certainpointthis results ina betterdownload categoriesperpeergivingaslightlysmallerrelativebenefitto
timeratioforsharingusers,asthe fractionofthetotal system sharing peers.
capacitydevotedtoexchangestendstoincrease.Theimprove- All of the previous simulations assumed a fixed fraction
ment levels off and even decreases as the maximum number (50%) of peers were good citizens and shared. Figure 12
of outstanding requests increases. This can be explained by investigatesthe effect of frequencyof uncooperativebehavior
the increased competition between sharing users, that seems on mean download times, to see whether incentives to share
toreducetheirrelativebenefit,althoughthereductiondoesnot continueevenifthevastmajorityofpeersdonotcooperate(or,
8
contrarily, if almost everyone cooperates). The measurements represent the set of peers in the request tree2, and ignore the
showthatthegapinmeandownloadtimespersists,regardless detailedstructureoftherequesttreeandtheobjectsassociated
of the fraction of non-sharing nodes. The explanation for with each edge. This is likely to offer significant savings
this is straightforward. We use the “no-exchange” case as especially considering the size of object and file identifiers
a baseline, i.e. mean download time in a system in which in modernfile sharingsystems and thelikelihoodof thesame
everytransferisgrantedandnopreferenceisgiventosharers. peers. The main difference in the process of setting up an
When almost everyone is sharing, then sharers get the same exchange is that the initiator does not have access to the
performance as no-exchange (sharers rarely get an advantage full subgraph, and can only determine that a cycle exists, but
from sharing), however, the non-sharers get a large penalty. cannotidentifyallthemembersoftheexchange.Theinitiator
Ontheotherhand,whenalmosteveryoneisnon-sharing,they must depend on next-hop lookups at each node instead of
rarely compete with a sharer, so the non-sharers receive the source-routingthe request token around the ring, and there is
same performanceas “no-exchange”.However,the infrequent a non-zero chance of false positives due to the probabilistic
sharer gets a big reward, because theyare almost always able nature of Bloom filters. The space savings of this scheme
to preempt other transfers and get immediate service. are likely to be important for peers with a large number of
incoming requests, and the peers close to them in the request
graph. The details of this scheme (e.g. how to adapt, how
to use hybrids consisting of both Bloom filters and complete
V. DISCUSSION
requesttrees,howtoprotectagainstcheating,etc.)aresubject
to future work.
For the purpose of this study we have focused on a
It is hard to speculate on how the incentives provided by
rathersimplisticsimulationscenario,andaspecificfile-sharing
exchangeswouldaffectpeerbehavior.Onedirectionforfuture
model.Wediscusssomeofthelimitationsofouranalysisand
work is therefore to determine how the proposed exchange
how the mechanisms proposed could be improved further.
mechanisms interact with replication mechanisms. In the cur-
Intermsofsimulation,thebasicassumptions(e.g.overpro-
rentmodel,peersonlystoreobjectstheyaredirectlyinterested
visioned core network, asymmetric bandwidth, zipf-like pop-
in.Inanexchangesystem,usershaveanincentivetoreplicate
ularity) seem to agree with real-world measurements. Many
popularobjectsthatareindemand,asthisislikelytoincrease
oftheothercharacteristicsofthecurrentmodeltendto erron
their chances of participating in exchanges which, being
the conservative side. Firstly, we assume that a peer cannot
prioritized, would give them a performance improvement. In
serve an object unless it has been fully received. In reality,
essence,popularobjectstaketheroleofcurrencyinexchange
manypeer-to-peersystems (forexample,eMule[15])doserve
economies as they are easily exchangeable for other goods.3
“chunks” of incomplete objects. If this is incorporated in the
There are three main limitations in the exchange approach
model, the opportunity for exchanges is likely to increase
as presented in this paper. First, peers are assumed to be
further. In fact, this form of exchange is implemented in the
equallyinterestedinalloftheirrequests.Itwouldbeusefulto
Bittorrent system[19].
investigate non-uniformutility models, as many existing file-
Secondly, we have assumed that transfer slots are fixed,
sharingsystemsalreadyallowuserstoexpresstheirpreference
regardless of the type of transfer. This means that exchanges
in terms of “low”, “medium” or “high” priority. This kind of
cannot use more capacity than the standard transfer slot,
informationcouldbeusedtonegotiateasymmetricexchanges,
although peers would clearly have interest in doing so. We
based on some form of bargainingor auction.
also assume that a peer can only have one registered request
Second, peers can leverage their ability to participate in
onagivenpeerforagivenobject.Thus,ifmultipleexchanges
exchangesonly when they have pendingrequests themselves.
are possible, whether pairwise or with different values of ,
It wouldbedesirableto providea strongerincentiveforusers
only one can be chosen. (cid:0)
to actually stay connected even if they cannot immediately
Thirdly, in our simulation all peers have very similar char-
participate in some exchange.
acteristics, ignoring the widespread heterogeneity observed
Finally, we have only considered peers for which down-
in real-world systems. For example, the existence of “super-
loading increases utility and uploading either does not affect
peers” (e.g., peers with substantially better network capacity
or reduces utility. The incentive structure is different in peer-
or storage) is likely to have a positive effect on exchange
to-peer content distribution systems: peers increase utility by
mechanisms, especially as a way to stimulate the deployment
pushing content out, and cooperating peers could help by
of exchange-capableclients.
downloading and re-distributing content on behalf of others.
Finally, we have ignored the complexity issues of commu- It would be interesting to see how exchange mechanisms can
nicating request tree information.The cost of communicating
the full request tree may be prohibitivefor peers with a large 2We require a different Bloom filter for each level in the request tree so
number of incoming requests and peers close to them in the that peers can trim the request tree by one level when they initiate a new
request.Further,weneedadistinct setofBloomfiltersforeachentryatthe
requestgraph.Iftherequesttreeisupdatedincrementally,this
top level of the incoming request queue, so that a peer can reconstruct the
islikelytointroducesomelatencyinthesearchprocesswhich nexthopintheexchange ringwhenaringinitiation tokencomesdown.
isnotreflectedinthewaitingtimesofexchangetransfersinthe 3We do not expect users to manually replicate objects or to patch their
file-sharing software for that purpose. Rather, it is likely that developers of
currentsimulationmodel.However,therearewaysofreducing
file-sharingclientswillseizetheopportunitytobuildsoftwarethatisexpected
thiscost.Inparticular,wecanuseasetofBloomfilters[23]to toperformbetter.
9