Lottery-based Pricing Scheme for Peer to Peer Networks - CiteSeerX

Lottery-based Pricing Scheme for Peer to Peer Networks Manaf Zghaibeh

Dr. Fotios C. Harmantzis

Telecommunications Management Stevens Institute of Technology Hoboken, New Jersey 07030 Email: [email protected]

Telecommunications Management Stevens Institute of Technology Hoboken, New Jersey 07030 Email: [email protected]

Abstract— Users in Peer-to-Peer (P2P) networks tend to exploit the maximum resources they are able to obtain, offering minimum resources in response. This behavior undermines the goal of P2P in spreading files through the network and imposes the concept of free-riding. In this paper we propose a Lotterybased pricing mechanism to enhance the sharing level in P2P network and help increasing the number of objects disseminated. The scheme is an extension of the traditional micropayment mechanism. Our scheme provides higher payoff for peers who contribute to the P2P network and higher cost for peers who act selfishly and choose not to share resources. Finally, we present our simulation results to demonstrate the performance of our proposed mechanism.

I. I NTRODUCTION Client-Server models have widely served users around the world; that model was the basic architecture which helped in the spread of information. However, many obstacles, e.g., bandwidth, scalability, reliability and most importantly cost, were motives for looking for new paradigms. An alternative structure or model was the peer to peer, P2P, file sharing [16]. Users around the world are enjoying the attractive properties of P2P, those that somehow the Client-Server model could not provide efficiently [11]. The concept of P2P is simple: P2P refers to a class of systems and applications that employ distributed resources to perform a critical function in a decentralized manner [3]. The users of the system or the peers are anonymous entities sharing their resources or distributed resources to benefit from each other within a scalable, stable and reliable environment. P2P became very appealing for users: hundreds of P2P applications have been used, millions of downloads have been performed, billions of users around the world have downloaded KaZaA and BitTorrent [14], [18]. Cooperation is highly appreciated in P2P networks. With no cooperation among peers, the network will reach a point where it will be difficult to obtain resources. Therefore, because of the essence of autonomous peers and the absence of any central authority or explicit punishment policies [2], peers act in a rational selfish way causing a major difficulty in enforcing cooperation among them. Peers that act selfishly are called F ree − Riders. Free-Riding is a serious problem of P2P; for example, 70% of peers in Gnutella system enjoyed the benefits of the system without contributing [8], [14]. Free-riding caused

the need for social and economical mechanisms necessary to balance resource usage and effort in P2P systems [2]. Social mechanisms are such as encouraging trustworthy behavior by managing peers’ reputation, undertaking trustinference mechanisms by which information about users behavior can be propagated throughout the system. [4], [5], [6]. These social incentive techniques encourage trustworthy behavior and maximize social welfare; however, they are vulnerable to collusion and rely heavily on users’ history. Furthermore, there is no cost on users’ identities: a defecting user can easily change his identity and enters the social game again and again [6]. Moreover, it may become appealing for peers to cooperate repeatedly with peers whom they had established successful relationships, limiting the overall utility of the system [4]. Finally, there is also considerable implementation overhead associated with such methods [5]. To further efficiency, researchers extended the social mechanisms into economical ones by applying pricing schemes. Pricing has proved to be an effective mean to control computer networks. It helps in recovering cost for the network operators and in providing incentives for users to cooperate [17]. Several approaches have already been proposed for P2P: Flat Rate [7], Auction-based [9], Micropayment and StockMarket approach [7], [9], [12] etc. All of them focus on motivating users to open resources and not decline requests. In this paper we propose a novel Lottery-based P2P pricing scheme. We argue that it contributes in efficiency and simplicity for P2P systems. Our model is motivated by the micropayment scheme [19]. It provides: a) higher number of disseminated objects comparing to the traditional micropayment schemes, b) higher revenue for peers who intend to participate and contribute with other peers, and c) higher cost for those who choose to behave selfishly. The rest of this paper is organized as follows: In Section 2, we review some of the important related work. Section 3 we describe our Lottery-based P2P pricing methodology. Section 4 covers our results and the discussion, while in Section 5 we conclude our paper. II. R ELATED W ORK One of the primary goals of a micropayment scheme was to encourage users to stabilize their download/upload behav-

ior by providing them with incentives. The only incentive provided by traditional micropayment mechanisms is a reward/punishment strategy. A traditional micropayment scheme mainly charges users for every object they download from the system and rewards them for every upload they provide. In addition, the system counts the number of downloaded and uploaded objects; then a function maps the difference between the two counts to a financial transfer. [7] depicts a detailed description regarding a traditional micropayment mechanism. As a user successfully downloads an object from a provider peer, the central authority, a server in [7], increments the download count of the user who downloaded the object and the upload count of the user who provided the object. On certain times, periods, or cycles, an amount of money will be charged or paid to the user depending on the difference between his two counts. Naturally, if the user uploaded more than he downloaded, then he will get paid. Several types of micropayment mechanism have been derived [10], [19], [20]. The major difference among them evolved on how the digital coins should be transferred within a secure environment, without increasing complexity. However, the reward/punishment incentive remains as the perpetual principle for all of them. The Lottery-based scheme extends the reward/punishment incentive by introducing a discounted price incentive policy. Our approach can work with several known micropayment protocols including DigiCash [22], Millicent [23] and PPay [19]. However, our work builds upon some of the contributions of [19], especially what concerns the definition of the broker, the coins and the mechanisms in which the coins are purchased, transferred and cashed. [19] implements the concept of self-managed, floating currency. A peer purchases a raw digital coin X0 from a broker Br in exchange with real-world money. The issued coin X0 has the following form: X0 = {P1 , sn}SKBr Where sn is the serial number of the issued coin and SK is a secret key. Now the coin X0 is defined as a micropayment issued by broker Br , belongs to peer P1 and uniquely recognized by sn. When using the micropayment for purchasing an object, the consumer peer stamps the micropyament with a sequence number seq. For example, when P1 purchases an object O from peer P2 , he sends him the following assigned micropaymnet: AP1 ,P2 = {P1 , seq1 , X0 }SKP1 After completing the exchange, P2 becomes the holder of the micropayment X0 . However, if P2 wants to spend this particular coin on purchasing an object from peer P3 , he still has to get P1 s involvement in order to reassign the coin to P3 . That is, P1 has to revise the sequence number seq1 to seq2 as follows: P2 sends a request to P1 to reassign X0 to P3 : RP1 ,P2 ,P3 = {P3 , seq2 , X0 }SKP1

P1 responds by updating the sequence number of X0 from seq1 to seq2 and sending the new assignment to P2 and P3 : AP1 ,P3 = {P3 , seq2 , X0 }SKP1 Certainly, after the reassignment of X0 , the old release of X0 that had seq1 implanted in is no longer valid. III. L OTTERY- BASED MECHANISM A. System Overview In this paper we consider a P2P file sharing network where peers in that network are similar in terms of their bandwidth capacities and different in terms of their interests. We assume that peers in general are not altruistic. Objects in a traditional micropayment system have one price. Our proposed system is an extension to the traditional micropayment system. However, any object in this system could have one of the following two prices: X0 or X0 +Y0 , where X0 and Y0 are micropayments and X0 >> Y0 . We call X0 the discounted price and X0 +Y0 the regular price. The micropayments X0 and Y0 are systemdefined self-managed floating digital coins [19]. They have no meaning outside the boundaries of this P2P network. A new peer joins the network purchases the digital coins X0 and Y0 from a broker who is also responsible for issuing and caching the coins with real-world money. Since we do not consider an explicit strategy to punish defectives in our model, we assume that our system does not handle partial downloads/uploads. Each object is transferred as a single chunk each round. Thus, a provider peer who is involved in an upload, stays available until the consumer peer obtains the whole object. Transfer of an object completes when the consumer peer finishes its download. If the provider peer disconnects before the consumer peer obtains the whole object, the consumer peer has the right to request the object later for the discounted price X0 . On contrary, if a consumer peer disconnects before getting the whole objects, then the provider peer has no obligations towards him. Each peer in the proposed network plays the roles of consumer and provider. Peers estimate the worthiness of their requested object. Each client maintains two history tables. The first table is the public History table that contains records for each consumer peer the holder peer had dealt with recently. Each provider peer refers to this table to determine whether the peers he had dealt with recently qualify to get the discounted price on their next transactions with him. The second table is the private History table that contains records for the peers who consider the holder as a preferred customer. At time t=0, or when new peers join the network, history tables are initialized to zero. PPay protocol mechanisms are used for purchasing objects as we mentioned previously. Different files have different popularities [1]; in this paper we ignore this aspect. B. Mechanism The mechanism is divided into two sub-procedures: (1) the lottery procedure and (2) the preferred client procedure.

To illustrate, a group of peers P~r = {P1 , P2 , P3 , ..., Pn } are willing to obtain the object Oa from a provider peer Pa . Each member of the group P~r sends a purchase request to Pa indicating his willingness to buy the object Oa . Moreover, each peer in P~r is aware that the object Oa has two systemdefined prices: X0 and X0 + Y0 , and hence, might purchase the object for one of these two prices. Acknowledging the purchase requests, the provider peer Pa admits the members of the group P~r into slots SOa in order to assign for each one of them a price. The slots SOa , which we call consumers’ row, identify the provider peers capacity to serve consumer peers who are requesting the object Oa , or the maximum number of peers that are able to download the object Oa without generating negative externalities to Pa . After admitting the members of the group P~r into the slots, the provider peer Pa checks his public History table to determine the status of each consumer peer: public History(Pa , Pi ) where Pi ∈ P~r . That is to determine whether the consumer peer is a preferred client and therefore he qualifies for the discounted price X0 or not. If the consumer peer is found to be a preferred client i.e., public History(Pa , Pi ) = pref erred, then the mechanism excludes him from the consumers’ row and uploads the object Oa to him for a price X0 . As a consequence, the mechanism updates the history entry associated with that consumer peer to not pref erred. However, if the consumer peer has no entry in Pa ’s history table i.e., public History(Pa , Pi ) = 0, or it has an entry but is set to not pref erred i.e., public History(Pa , Pi ) = not pref erred, then he stays in the consumers’ row. After evaluating the history table, excluding and then serving the preferred clients, the provider peer Pa randomly assigns X0 + Y0 to half of the remaining clients and X0 to the other half. To establish this stage, Pa divides the remaining clients in the consumers’ row into two equal-sized groups: Pa simply runs a Bernoulli trial for each of the remaining clients to decide to which group the client belongs. Pa performs K Bernoulli trials until one or both of the groups are filled. Please note that if the number of remaining peers after excluding the preferred clients is odd, Pa makes the group that will be assigned the price X0 bigger by one. That implies the following: if only one client is found in the consumers’ row, then Pa will assign him the price X0 . Consequently, Pa updates his public History table as follows: if Pi has been assigned a price X0 then public History(Pa , Pi ) = not pref erred elseif Pi has been assigned a price X0 + Y0 then public History(Pa , Pi ) = pref erred Accordingly, each consumer peer denotes in his private History table the peers that consider him as a preferred client i.e., private History(Pa , Pi ) = pref erred. If the peer Pi is willing to obtain an object O1 , he searches the network for it. If the query returns with a set of peers who own the object, Pi looks up his private History table for an entry for one of those peers. If private History(Pm , Pi ) = pref erred, that is if Pi finds himself as a preferred client to

a peer Pm , then Pi requests the object O1 from Pm for the discounted price X0 . Otherwise, if Pi fails to find an entry for one of those peers in his private History, then he chooses one of them as a provider peer and submits the request to him. Should the peer keep his history tables or should he reset them? Keeping the history tables will constrain the system. We do not wish peers to keep logs for every client they had dealt with previously. This could cause the history tables to grow huge; furthermore, keeping the history tables forever will be very similar to other credit algorithms, which we believe that they lack flexibility. Consider that peer A is a preferred client for peer B (that is public History(B, A) = pref erred), it is not reasonable for B to wait for A for long time to redeem an object for the discounted price X0 . The goal behind resetting the history tables is to encourage peers to increase their transactions. Keeping the window open for long time will reduce the degree of the network’s activity. On the other hand, making the peers acquainted that the public History table will not be saved forever, will form an incentive to them to use discounted prices and request objects fast. As a result, disseminating objects in the network. Moreover, recall that in micropayment protocol currency worth little. For example, in our system both X0 and Y0 are small amounts of real world money. Limited number of transactions would generate negligible profit to the peer; therefore, conducting more transactions is a sustainable strategy a peer can follow to incur more profit. Finally, in setting the mechanism of our system, we do not want to impose permanent obligations on consumers. The idea we convey here is to promote sharing by undertaking a scheme that provides higher payoff for peers who contribute more to the P2P network, and higher cost for those who act selfishly and choose not to share resources. The mechanism is not intended to enforce sharing. How long a peer in our proposed system should keep his History tables? Regarding the public History table, there are many answers to that question. If a peer does not reset his public History table for long time, clients with pref erred entries will accumulate in the table, preventing him from running the lottery algorithm. Therefore, reducing his probability of selling objects for the original price X0 + Y0 , is an obstacle from incurring more profit. On the other hand, resetting the table very often might sound tempting for a while, since this will release the holder of the table from providing objects to consumers at discounted prices. However, this action has a drawback: it forbids the holder of the table from having guaranteed consumers who will pay X0 each. This is undoubtedly better than selling nothing or at least taking the risk in waiting for consumers to submit their requests and then run the lottery algorithm. Furthermore, when a peer resets his public History table he realizes that peers who were preferred in his table and did not have the chance to enjoy the benefit of obtaining objects for discounted prices, might ban him in the future as a mean of punishment for his behavior. Shunning defective peers is widely used in P2P networks. This can be achieved by maintaining a list of peers who denied service and refuse to serve them in the future. However,

TABLE I

resetting the public History should not be considered as a punishment unless all of the peers in the public History table had denied service to the holder. Undertaking this behavior might degrade the performance of the system. From another point of view, micropayment schemes are very close to the real life business structures: selling and buying goods to people who signify their interests and follow different strategies to achieve them. Similarly, in micropayment schemes including our system, peers follow different strategies to pursue their goals. However, that can not be on the cost of others. Therefore, we believe that the resetting behavior should be a system-related parameter. Regarding the private History table, a peer can keep it as long as he wants. In fact, we do not find it judicious for a peer to reset his private History table since it aids him getting objects in his future transactions for discounted price X0 . However, this table certainly expires if the other side, the provider peers, reset their public History tables. Another issue concerning the history table arises here; why to keep the history tables at the peers side? Why not saving them at a central node? These are very valid questions and they may advocate a tougher policy in dealing with peers. The main advantage of not keeping the history tables at the peers sides is that it thwarts the peers from resetting the tables whenever they want and it inflicts more restrictions on them to respect their obligations. Although it relieves the peer from local book keeping, it generates more traffic: each peer has to contact the central node to update his tables and to obtain information about his clients. However, involving central nodes for saving history tables and for consulting, is an inefficient solution since most of P2P networks are moving towards decentralization rather than centralization. Moreover, in micropayment schemes acceptable level of security is good enough for the system to perform well [19]. In fact, it might be counterproductive to impose high level of security and regulation restrictions on the system, since this might mortify its performance: less regulation is good regulation.

For the second area, we evaluate how competent the lottery mechanism disseminates objects by matching it up to the traditional micropayment mechanism. To do so, we introduce 60 distinct objects to the system at round 1 and monitor the number of objects disseminated during 150 rounds. We simulate a small 200-peers network, in which peers are similar in their download/upload capacities, and different in terms of their requested objects and classes as mentioned above. At time t=0, peers purchase random number of digital coins X0 and Y0 from the broker Br . In our simulation model, peers consult decision arrays based on their classification and preferences prior making any decision. During the first round of the simulation, each peer explores the objects he wishes to request, determines his potential providers and establishes his history tables. After the first round, each peer seeks the best providers available based on his private history table. Likewise, each provider peer consults his public history table after the first round to determine consumer peers who qualify for discounted price. Peers are allowed to request a fraction of the maximum number of objects they want to download per round. We define the resetting factor f as the ratio between the number of preferred clients to the total number of entries in the public history table. We run the simulation using three factors: f = 0.3, f = 0.7 and f = 1

IV. S IMULATION PARAMETERS

V. RESULTS AND D ISCUSSION

After describing the mechanism, we wish to analyze its performance. The areas we want to investigate are (a) the fairness of the mechanism, and (b) the effectiveness of the mechanism in disseminating objects. In order to probe the first area, we classify the following three types of peers: The first class is the rational selfish peers who prefer not to share objects and focus their activities into downloading. The second class defines moderately active peers who balance between their download and upload volume. The third class is the other extreme: peers who dedicate most of their performance into uploading. We want to explore how the lottery mechanism treats each of the previously mentioned classes in terms of profits and looses. Furthermore, we analyze how resetting the history tables affects the efficiency of the mechanism. Therefore, we run the simulation under different resetting factors.

In this section we discuss the simulation results of our proposed network. Our simulation implements the mechanism described in section II. Metrics used in evaluating file sharing networks are concentrated on load, bandwidth, and processing cost [19], [21]. However, in our simulation we focus more on the following: • Evaluating the performance of the Lottery-based scheme in terms of disseminating objects comparing to the traditional micropayment scheme. • Determining how providing discounted prices affects the behavior of both provider and consumer peers. • We compare peers’ net revenues under the three reset factors mentioned in the previous section. That gives us an insight on how the factor f affects peers’ profit/loss and how setting different values of f supports different sharing strategies.

SYSTEM AND SIMULATION PARAMETERS

Number of peers Number of distinct objects Maximum number of objects allowed to be requested X0 Y0 Online time Peers’ percentage Class1: selfish peers Class2: moderate peers Class3: heavy uploaders

200 60 7 per round 1 0.2 uniform(1,300) round 40% 30% 30%

3000

Lottery Traditional Micropayment

Number of objects

2500 2000 1500 1000 500 0 0

Fig. 1. inated

20

40

60

80 Rounds

100

120

140

Lottery vs. (Traditional) Micropayment: Number of objects dissem-

Percentage of objects (%)

100 80 60 40

35 29

20 3

0 0.3

0.7 Resetting factor f

1

Fig. 2. Percentage of the number of objects purchased for X0 without entering the lottery draw to the total number of objects purchased by all peers

100 Percentage of objects (%)

In Fig. 1 we observe the behaviors of the Lottery-based and the traditional micropayment schemes, as they disseminate objects in the network. Obviously seen, the Lottery-based performs better than the traditional micropayment in that aspect. After introducing the 60 distinct objects into the network in round 1, the traditional micropayment scheme spread about 2000 objects after 20 rounds of transactions, compared to 2800 objects spread by the Lottery-based. After 100 rounds of transactions, the Lottery-based spread about 9200 objects, compared to 6400 objects spread by the traditional micropayment. That is more than 25% of the objects. The extra cost signified by the micropayment Y0 validates this behavior. As peers pay X0 + Y0 to purchase resources, they tend to compensate the extra cost by offering more resources for trade, thus boosting the number of transactions. In the thirstiest round, the number of disseminated objects drastically drops by almost half in both schemes. The reason for that drop is that a significant number of objects had been distributed in the network, therefore after each round there are less objects to be traded (unless some new objects are being introduced which is not the case in our simulation). On the other hand, as peers sell objects for X0 + Y0 , they incur more profit and that might be a justification for them to decrease their sharing level, thus reduce the number of disseminated objects. This reasoning is understandable as for selfish peers: if there is no crucial need for sharing, they do not share. However, for heavy uploaders peers this is unlikely to happen, since they desire more profit and their strategy is based on sharing.

80 60 40 25

20 0

17

1

0.3

0.7 Resetting factor f

1

Fig. 3. Percentage of the number of objects purchased for X0 without entering the lottery draw to the total number of times each peer was set as a preferred client

For the second goal of our simulation we study the effectiveness of offering objects for discounted price. That is, determining whether this action provided an incentive to users to a) share more resources, and b) acquire more resources. To do so, we count the number of objects that were purchased for the discounted price X0 without entering the lottery draw. Fig.2 relates that number to the total number of objects purchased by all peers during all rounds using different values of f . The number of objects purchased for the discounted price X0 without entering the lottery draw increases as f increases. This percentage was as high as 35% for f = 1 and as low as 3% for f = 0.3. This is expected since the higher the value of f , the longer the public History tables will be maintained, which increases peers’ chances in obtaining objects for X0 . Fig. 3 represents the ratio between the total number of objects purchased for X0 without entering the lottery draw, to the total number of times each peer was set as a preferred client in other peers public History tables. This ratio gives us a better understanding on how successful the peers were in acquiring objects for the discounted price X0 . Evidently, that success has a profound bond with the resetting factor f . To increase cooperation, the system might set higher values of f . Consequently, that gives other peers who have been set as preferred clients better opportunities to purchase objects for discounted price. That is clearly seen in Fig. 3: for f = 0.3, the ratio does not exceed 1%, however, it goes up to 25% for f = 1.

f=1 f=0.3 f=0.7

Micropayments

320

this strategy was a major incentive for peers to purchase more objects thus increasing the number of transferred objects.

Heavy uploaders

R EFERENCES

220

120

Moderate peers

Selfish peers 20

−80

0

50

Fig. 4.

100 Peers

150

200

Peers’ net profit/loss

In Fig. 4 we present the net profit of the peers in the network. The figure signifies the three classes of the peers. The maximum profit earned by the heavy uploaders peers crops up at f = 0.7 and the minimum net profit occurred at f = 0.3. In contrast to that, selfish peers suffered from maximum loss level at f = 0.7 and minimum loss level at f = 0.3. However, refraining from resetting the public History table until it is totally filled, f = 1, came in between the other two values. VI. CONCLUSION We have introduced a decentralized lottery-based pricing mechanism as an extension to the PPay micropayment scheme. Each object in the lottery-based network has two prices, a regular price X0 +Y0 and a discounted price X0 and it might be sold for one of them. The provider peer assigns one of these two prices to each of his consumers based on lottery draws. After completing the transactions, the provider peer will consider the peers who paid the regular price as preferred clients. Thus, each one of them will have the opportunity in the future to purchase an object from him for the discounted price. The Lottery-based scheme promotes cooperation in peer-to-peer file-sharing networks. It provides incentives to users to share more resources comparing to other micropayment mechanisms. The scheme provides higher payoff to the peers who choose to share more objects. In contrast, it imposes higher cost on those peers who choose not to cooperate. Furthermore, one of the important advantages of our mechanism is that it helps in increasing the number of transferred objects in the network, which basically supports the purpose of the business-oriented P2P networks. To support our findings, we have simulated a 200-peers P2P network. In our simulation we measured the number of objects disseminated using the lottery-based mechanism comparing to a traditional micropayment mechanism. Moreover, our simulation results showed that using two different prices in a micropayment network provided a major incentive to the peers to cooperate and share more resources in order to maximize their profits. Finally, our simulation focused on the effectiveness of the preferred-client strategy. The results showed that undertaking

[1] P. Antoniadis, C. Courcoubetis and R. Weber, An Asymptotically Optimal Scheme for P2P File Sharing, In Second Workshop on the Economics of Peer-to-Peer Systems, Harvard University. [2] J. Shneidman and D. C. Parkes, Rationality and Self-Interest in Peer to Peer Networks, In Proceedings of Second International Workshop on Peer-to-Peer Systems (IPTPS-2003). [3] D. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins, and Z. Xu, P2P Computing, Tech. Rep. HPL-200257, Hewlett Packard Laboratories, 2002. [4] R. Morselli, J. Katz and B. Bhattacharjee, A Game-Theoretic Framework for Analyzing Trust-Inference Protocols, 2nd Workshop on the Economics of P2P Systems, Cambridge, MA, USA, June 2004 [5] Z. Despotovic and K. Aberer, Maximum Likelihood Estimation of Peers Performance in P2P Networks, The Second Workshop on the Economics of P2P Systems, Harvard University, Cambridge, MA, USA, June 2004. [6] K. Lai, M. Feldman, I. Stoica and J. Chuang, Incentives for Cooperation in Peer-to-Peer Networks, Workshop on Economics of P2P Systems. June 2003. Berkeley, CA [7] P. Golle, K. Leyton-Brown and I. Mironov, Incentives for Sharing in P2P Networks, Proceedings of the 3rd ACM conference on Electronic Commerce. [8] E. Adar and B. Huberman, Free Riding on Gnutella, First Monday, 5(10), October 2000. [9] D. Hausheer, Economics of Peer-to-Peer Systems, Dagstuhl Seminar on P2P Systems and Applications, March, 2004 [10] C. Li, B. Yu, M. Singh and K. Sycara, A Dynamic Pricing mechanism for P2P Referral Systems, Proceedings of Third International Joint Conference on Autonomous Agents and Multi-Agent Systems [11] M. Ramanathan, V. Kalogeraki and J. Pruyne, Finding Good Peers in P2P Networks, International Parallel and Distributed Computing Symposium (IPDPS), Fort Lauderdale, Florida (April 2002) [12] P. Dasgupta and V. Kalogeraki, Auctioning Strategies in an Agent Enabled P2P Marketplace, Proceedings of the Sixth International Conference on Artificial Intelligence, Las Vegas, NV, June 24-27, 2002 [13] A. Agrawal and H. Casanova, Clustering Hosts in P2P and Global Computing Platforms, Cluster Computing and the Grid, 2003. Proceedings. CCGrid 2003. 3rd IEEE/ACM International Symposium on ,12-15 May 2003 [14] K. Ranganathan, M. Ripeanu, A. Sarin and I. Foster, To Share or not to Share An Analysis of Incentives to Contribute in Collaborative File Sharing Environments. Workshop on Economics of P2P Systems, June 2003 [15] KaZaA website. http://www.kazaa.com. [16] D. Barkai, An Introduction to P2P Computing, Intel Developer Update Magazine, February 2000. [17] R. Cocchi, S. Shenker, D. Estrin and L. Zhang, Pricing in Computer Networks: Motivation, Formulation and Example. ACM/IEEE Transactions on Networking, 1993. [18] BitTorrent website. http://www.bittorrent.com. [19] B. Yang and H. Garcia-Molina, PPay: Micropayments for P2P Systems, In ACM CCS 2003 [20] B. Yu, M. Singh, Incentive Mechanisms for P2P Systems, Proceedings of the 2nd International Workshop on Agents and P2P Computing (AP2PC), Melbourne, July 2003, Springer. [21] K. Anagnostakis and M. Greenwald, Exchange-based Incentive Mechanisms for P2P File Sharing, Technical Report MS-CIS-03-27; Department of Computer and Information Science, The University of Pennsylvania, August 2003 [22] DigiCash website. http://www.degicash.com [23] S. Glassman, M. Manasse, M. Abadi, P. Gauthier, and P. Sobalvarro, The millicent protocol for inexpensive electronic commerce, In Proc. of WWW4, 1995