Robust and Efficient Incentives for Cooperative Content Distribution

Robust and Efficient Incentives for Cooperative Content Distribution

Robust and Efficient Incentives for Cooperative

Content Distribution

Michael Sirivianos Xiaowei Yang Stanislaw Jarecki

Department of Computer Science

University of California, Irvine

{msirivia,xwy,stasio}@ics.uci.edu

Abstract—Content distribution via the Internet is becoming increasingly popular. To be cost-effective, commercial content providers are now using peer-to-peer (P2P) protocols such as

BitTorrent to save bandwidth costs and to handle peak demands.

When an online content provider uses a P2P protocol, it faces an incentive issue: how to motivate its clients to upload to their peers.

This paper presents Dandelion, a system designed to address this issue. Unlike previous incentive-compatible systems, such as

BitTorrent, our system provides non-manipulable incentives for clients to upload to their peers. A client that honestly uploads to its peers is rewarded in the following two ways. First, if its peers are unable to reciprocate its uploads, the content provider rewards the client’s service with credit. This credit can be redeemed for discounts on paid content or other monetary rewards. Second, if the client’s peers possess content of interest and have appropriate uplink capacity, the client is rewarded with reciprocal uploads from its peers.

In designing Dandelion, we trade scalability for the ability to provide robust incentives for cooperation. The evaluation of our prototype system on PlanetLab demonstrates the viability of our approach. A Dandelion server that runs on commodity hardware with a moderate access link is capable of supporting up to a few thousand clients. These clients are able to download content at rates comparable to those of BitTorrent clients.

Index Terms—Peer-to-peer, content distribution, incentives, fair-exchange, symmetric cryptography.

I. Introduction

Content distribution via the Internet is becoming increasingly popular among the entertainment industry and the consumers alike. Apple’s iTunes music store recently became the third largest music retailer in the US, surpassing Amazon and

Target [1]. Netflix is now offering movie rentals online [2].

However, the increasing demand for digital content is overwhelming the infrastructure of online content providers [3].

An attractive approach for commercial online content distribution is the use of peer-to-peer (P2P) protocols. This approach does not require a content provider to over-provision its bandwidth to handle peak demands, nor does it require the provider to rely solely on purchased service from a third-party such as Akamai. Instead, a P2P protocol such as BitTorrent [4] harnesses its clients’ bandwidth for content distribution, and saves the bandwidth and computing resources of a content provider. Huang et al. [5] recently showed that peer-assisted content distribution can substantially reduce the operating costs of Video on Demand services. Leading content providers such as Warner Bros and 20th Century Fox have now partnered with BitTorrent, Inc [6]. This trend indicates that P2P protocols enable a site to cost-effectively distribute content.

When an online content provider uses a peer-to-peer protocol, it faces an incentive issue: how to motivate clients that possess content to upload to others. This issue is of paramount importance because the performance of a P2P network is highly dependent on the users’ willingness to contribute their uplink bandwidth. However, selfish (rational) users tend not to share their bandwidth without external incentives [7].

Although the popular BitTorrent protocol, has incorporated the rate-based tit-for-tat incentive mechanism, this mechanism bears two weaknesses. First, it does not encourage clients to seed, i.e. to upload to other peers after completing the file download. Second, it is vulnerable to manipulation [8–

12], allowing modified clients to free-ride and still achieve download rates equal to or higher than the ones of cooperative clients (Sections II-B,VI-C).

A content provider with paying customers needs to offer better quality of service guarantees than the ones offered by existing P2P content distribution systems. If the content provider uses a protocol that offers strong incentives for cooperation, clients with abundant bandwidth may become reliable uploaders, enabling the content provider to both save on its bandwidth cost and to offer speedy downloading services to its customers.

In [13] we explored the design space of a protocol called

Dandelion, which provides provably non-manipulable incentives for seeding and is not susceptible to free-riding. Although the protocol was shown to be robust and sufficiently scalable, its incentive mechanism was completely centralized. In this paper, we built upon our initial design and propose changes that partially decentralize the protocol. These changes render the protocol more scalable, while they maintain its original desirable properties, i.e. robust incentives for cooperation and performance comparable to the most efficient content distribution systems to date. Our modified protocol provides robust incentives through the use of two mechanisms.

The first mechanism guarantees strict fair-exchange of content uploads for virtual currency (credit). Cooperative clients earn credit when they upload valid content to their peers. A client that does not possess content that interests a selfish peer (i.e. a peer that does not upload unless it expects to be rewarded) cannot download content from the selfish peer without paying credit, neither can it obtain credit for uploads it did not perform. Credit can be redeemed at a content provider for discounts on the content or for other types of monetary

1

awards. Given appropriate pricing schemes, a selfish client is motivated to serve content to its peers, regardless of whether its peers possess content that interests it.

The second mechanism renders the protocol more scalable by partially decentralizing it. It employs tit-for-tat (TFT) between clients that are mutually interested in each other’s content. By employing a stricter TFT variation, it prevents meaningful exploitation of the initial tit-for-tat offers by freeriders that connect to many more peers than the protocol specifies (Section II-B).

A key challenge is to make the virtual-currency system efficient and practical while robust to manipulation. We address this challenge based on the insight that in the problem domain of online content distribution, the content provider itself is a trusted third party and can mediate the content exchange between its clients. Based on this observation, we design a protocol in which clients exchange data for credit and a server mediates this exchange. The server uses only efficient symmetric cryptography on critical data paths and sends only short messages to its clients.

Our work makes the following contributions:

1) The design of Dandelion, a novel hybrid incentive scheme that is suitable for P2P content distribution. It employs an efficient cryptographic fair exchange scheme for trading content uploads for virtual currency, and a mechanism for peers to barter content uploads.

2) The prototype implementation of a Dandelion-based system that is suitable for commercial P2P distribution of static content.

3) The evaluation of Dandelion on PlanetLab [14], which identifies the scalability limits of our incentive mechanism, demonstrates the plausibility of our approach, and thoroughly investigates free-riding in realistic PlanetLab-residing BitTorrent-like networks.

The rest of this paper is organized as follows. Section II provides background and motivates our design. Section III provides an overview of Dandelion and describes the system model under which it is designed to operate. Section IV describes the design of Dandelion and discusses its properties.

Section V describes the implementation of our prototype system. Section VI presents the experimental evaluation of our implementation. In Section VII we discuss prior work and cryptographic fair exchange schemes. We conclude in

Section VIII.

II. Background

Dandelion is specifically designed to address the incentive issues in P2P content distribution protocols such as BitTorrent [4] and eMule [15]. In this section, we motivate the design of Dandelion, by discussing the weaknesses of BitTorrent’s incentive mechanism.

In the rest of this paper we use a BitTorrent-like terminology. A seeder refers to a client that uploads to its peers despite not being interested in the content being distributed

(e.g. a client that uploads although it has completed its file download). A leecher refers to a client that is interested in the content being distributed (e.g. a client that has not completed its file download). A free-rider refers to a client that downloads content from other peers without incurring any cost, i.e without uploading content or without expending virtual currency. A swarm refers to all clients that actively participate in the protocol for a given content item. The

choking algorithm refers to the client function of selecting peers to upload content to (unchoke) in parallel, based on a predetermined criterion. Optimistic unchoking refers to the action of temporarily unchoking a peer, although that peer does not currently satisfy the said criterion. Clients optimistically unchoke a peer in expectation that the peer will eventually satisfy the unchoking criterion.

A. Impact of Seeding

The popular BitTorrent protocol employs the rate-based “titfor-tat” incentive mechanism [4]. A peer prefers to upload to (unchoke) another peer that reciprocally uploads useful parts of the same file. This mechanism mitigates free-riding, but does not provide explicit incentive for seeding. Although several BitTorrent deployments rely on clients to honestly report their uploading history [16], and use this history to decide which clients can join a swarm, practice has shown that clients can fake their upload history reports [17] or collude

[18].

Seeders improve download completion times, because they increase the content availability and the aggregate upload bandwidth. In Section VI-B1 (Figure 4) we show that the download rates of leechers in BitTorrent swarms decreases substantially as the portion of clients that seed increases.

B. Free-riding in BitTorrent

A general observation is that since BitTorrent’s tit-for-tat incentives reward cooperative clients with improved download times, clients are always incentivized to upload. This observation relies on the assumption that users aim only at maximizing their download rates. However in practice, BitTorrent users may be reluctant to upload even if uploading improves their download times. For example, users with access providers that impose quotas on outgoing traffic or users with limited uplink bandwidth (e.g. 1.5Mbps/128Kbps ADSL) may wish to save their uplink for other critical tasks.

Considering the trade-off between performance and susceptibility to free-riding [19], BitTorrent purposely does not implement a strict tit-for-tat (TFT) strategy. In particular, it employs rate-based instead of chunk-level TFT, and BitTorrent clients optimistically unchoke peers for relatively long periods of time (10 to 30 seconds). Furthemore, BitTorrent seeders select peers to upload to regardless of whether those peers upload to others.

Based on the above observations and previous work on

BitTorrent exploitation [8–10], in [11], we modify a BitTorrent client to employ the “large view” exploit to free-ride. The client obtains a larger than normal view of the swarm, either by repeatedly requesting partial views from the BitTorrent tracker or by exchanging views with its peers [20, 21]. Subsequently, it connects to all peers in its view, while it does not upload any content. Using this exploit in a sufficiently large swarm, a modified client can find more seeders, which do not employ tit-for-tat. It can also increase the frequency with which it

2

becomes optimistically unchoked, compared to a compliant client, which typically connects to 50-100 peers. In particular, we show that our modified free-rider client is able to download faster than or almost as fast as its tit-for-tat compliant counterparts in public and PlanetLab-residing torrents. The same weakness of BitTorrent’s incentives is experimentally demonstrated in a recent work by Locher et al. [12]. In addition, a more recent study [22], reported that the portion of peers that free-ride and are able to attain good download rates (up to 300KB/sec) is already larger than expected (up to

10%).

Drawing from the above observations, we believe that the

“large view” exploit has the potential to be widely adopted leading to performance degradation in BitTorrent swarms.

Dandelion’s non-manipulable incentives explicitly address this issue.

III. Overview and System Model

We now provide an overview of Dandelion and describe the system model under which it is designed to operate.

Our system is designed for BitTorrent-like content distribution. When a content provider is overloaded, the Dandelion server redirects clients to other clients that are able to serve their requests for content. The content provider splits content into verifiable chunks, and clients exchange carefully selected chunks. The content is split into multiple chunks in order to enable clients to upload as soon as they receive and verify a small portion of the content. It is also split in order to increase the entropy of content in the network, facilitating chunk exchanges among peers. We discuss the trade-offs in selecting a chunk size in the case of static content distribution in Section VI-B3.

Dandelion employs a hybrid incentive mechanism. In case a client has content that interests a peer, but that peer does not have content that interests the client or the peer is unable to reciprocate at the same rate that the client uploads to it, the system entices the selfish client to upload by explicitly rewarding the client with virtual credit. The server maintains a virtual economy and associates each client with its credit balance. A Dandelion client employs a tit-for-tat mechanism when its peers can reciprocate with content of interest. That is, the client would upload content to a peer at the same rate that the peer uploads content to the client.

We assume three types of clients, which we define as follows:

Malicious clients aim at harming the system without benefiting themselves. They misbehave as follows: a) they may attempt to make honest clients appear as malicious or dishonest, or they may attempt to cause them to be charged for chunks they did not obtain; b) they may attempt to perform a Denial of Service (DoS) attack against the server or selected clients (this attack would involve only protocol messages, as we consider bandwidth or connection flooding attacks outside the scope of this work); and c) they may upload invalid chunks aiming at disrupting the distribution of content.

Selfish (rational) clients share a utility function. This function describes the cost they incur when they upload a chunk to their peers and when they pay virtual currency to download a chunk. It also describes the benefit they gain when they are rewarded in virtual currency for correct chunks they upload and when they download chunks they wish to acquire at good download rates. A selfish client aims at maximizing its utility. We assume that the content provider prices a peer’s accumulated virtual currency appropriately: the benefit that a selfish client gains from acquiring virtual currency for content it uploads exceeds the cost of utilizing its uplink to upload it.

A selfish client may consider manipulating the credit system in order to increase its utility by misbehaving as follows: a) it may not upload chunks to a peer, and yet claim credit for them; b) it may upload garbage either on purpose or due to communication failure, and yet claim credit; c) it may obtain chunks from selfish clients, and yet attempt to avoid being charged; d) it may attempt to download content from selfish peers without having sufficient credit; e) it may attempt to boost its credit by colluding with other clients or by opening multiple Dandelion accounts; and f) it may attempt to employ the “large view” exploit and connect to more peers than the protocol specifies aiming at exploiting the initial tit-for-tat offers its peers.

Altruistic clients upload correct content to their peers regardless of the cost they incur and they do not expect to be rewarded.

We assume weak security of the IP network, meaning that a malicious or a selfish client cannot interfere with the routing and forwarding function, and cannot corrupt messages, but it can eavesdrop messages. In addition, we assume that communication errors may occur during message transmissions.

IV. Design

In this section, we describe the design of Dandelion, which explicitly addresses the challenges posed by selfish and malicious clients, as well as the challenges posed by the communication channel. We introduce our cryptographic protocol for the fair and non-repudiable exchange of content uploads with virtual credit. We also describe our hybrid incentive scheme, which combines the fair-exchange protocol with a tit-for-tat incentive mechanism, in order to reduce the load that the cryptographic protocol induces on the server.

Our design is based on the premise that although a low cost server may not have sufficient network I/O resources to directly serve content to its clients under overload, it may have sufficient CPU, memory, and I/O resources to execute many symmetric cryptography operations, to maintain protocol state for many clients, to access its clients’ protocol state, and to receive/send short messages. However, CPU, memory and I/O are still limited resources. Therefore we aim at making the design as efficient as possible.

A. Credit as Incentives

We aim at providing strong incentives for a selfish client to upload to a peer that does not possess content of interest or to a peer that is unable to upload as fast as the client uploads to it.

To this end, we employ a cryptographic fair-exchange protocol.

This protocol involves only efficient symmetric cryptographic operations. The server acts as the trusted third party (TTP)

3

4 mediating the exchanges of content for credit among its clients.

When a client A uploads to a client B, it sends encrypted content to client B. To decrypt, B must request the decryption key from the server. The requests for keys serve as the proof that A has uploaded some content to B. Thus, when the server receives a key request, it credits A for uploading content to B, and charges B for downloading content.

When a client A sends invalid content to a client B, B can determine that the content is invalid only after receiving the decryption key and being charged. To address this problem, our design includes a non-repudiable complaint mechanism. If

A intentionally sends garbage to B, A cannot deny that it did.

In addition, B is prevented from falsely claiming that A has sent it garbage.

1) Credit Management

Dandelion’s incentive mechanism creates a virtual economy, which enables a variety of application scenarios. Selfish clients may sell upload service to peers that are unable to reciprocate with equally fast uploads. Those peers spend

c

>

0 credit units for each chunk they download from the selfish client and the selfish client earns

r

>

0 credit units for each chunk it uploads to those peers. A client can acquire a chunk from a peer that is not interested in the client’s content only if the client’s credit is greater than

c

. We set

c

=

r

, so that two colluding clients cannot increase the sum of their credit by falsely claiming that they upload to each other.

Our protocol is intended for the case in which users maintain paid accounts with the content provider, such as in Netflix.

A client is awarded sufficient initial credit to download the complete paid content from its peers. The content provider may redeem a client’s credit for monetary rewards, such as discounts on content prices or service membership fees, similar to the mileage programs of airline companies. This motivates a client to upload to others and earn credit. A user cannot boost its credit by presenting multiple IDs (Sybil attack [23]) and claiming to have uploaded to some of its registered IDs. This is because each user maintains an authenticated paid account with the provider. The user essentially purchases its initial credit, and the net sum in an upload-download transaction between any two IDs is zero.

the server maintain loosely synchronized clocks using standard techniques, such as the Network Time Protocol (NTP).

Every client A that wishes to join the network must establish a transport layer secure session with the server S, e.g. using

TLS [25]. A client sends its ID and password over the secure channel. The server S generates a random secret key, denoted

K

SA

, which is shared with A. K

SA

is also sent over the secure channel. This key is used both for symmetric encryption and for computing a MAC. If the two schemes are not known to be secure when the same key is reused, two distinct keys should be generated. The rest of the messages that are exchanged between the server and the clients are sent over an insecure communication channel (e.g. plain TCP), which must originate from the same IP as the secure session. Similarly, all messages between clients are sent over an insecure communication channel.

Each client A exchanges only short messages with the server. To prevent forgery of the message source and replay attacks, and to ensure the integrity of the message, each message includes a sequence number and a digital signature.

The signature is computed as the MAC of the message and the sequence number, keyed with the secret key K

SA

that A shares with the server. Each time a client or the server receive a message from each other, they check whether the sequence number succeeds the sequence number of the previously received message and whether the MAC-generated signature verifies. If either of the two conditions is not satisfied, the message is discarded. The sequence number is reset when time period i changes.

X

−→ Y :[name] Z,W denotes that the client or server X sends to Y a message of type name, which contains Z and W .

3) Exchanging Content Uploads for Credit

2) Setting and Notation

Before we describe our fair-exchange protocol, we introduce the setting and the notation.

By hXi we denote the description of an entity or object, e.g.

hXi denotes a client’s X ID, while X denotes the client itself. H is a cryptographic hash function such as SHA-1, MAC is a Message Authentication Code such as HMAC [24], and i refers to a time period. By i

X

MAC

K

we denote i at client or server X .

[X,Y ] denotes the MAC of the concatenation of items

X and Y , using the key K.

Each user applies for a Dandelion account and is associated with a persistent ID. The server S associates each client with its authentication information (client ID and password), the content (e.g. a file) hFi it currently downloads or seeds, its credit balance, and the content it can access. The clients and

Figure 1.

The Dandelion protocol. The arrow numbers correspond to the protocol messages and steps listed in Section IV-A3. The messages are sent in the order they are numbered.

Next, we describe Dandelion’s cryptographic fair-exchange protocol. The following description omits the sequence number and the signature in the messages between clients and the server. Figure 1 depicts the message flow in our protocol. We also list the security properties of our design.

For brevity of presentation, we omit proofs on why these properties hold. They can be found in [26]. We also list the security properties of our design.

Step 1:

The protocol starts with the client B sending a request for the content item hFi to S.

5

B

−→ S:[content request] hFi

Step 2: If B has access to hFi, S chooses a short list of peers hPi list

, among the ones that are currently in the swarm for hFi. The policy with which these peers are selected depends on the specifics of the content distribution system. Each list entry contains the ID of the peer and the peer’s inbound

Internet address. For every peer A in P list

, S sends a ticket

T

SA

= MAC

K

SA

[hAi, hBi, hFi,t] to B, where t is the timestamp of the current time. The tickets T

SA

are only valid for a certain time length L

peer

and allow B to request chunks of the content hFi from client A. When T

SA

expires and B still wishes to download from A, B requests a new T

SA

from S.

To ensure integrity in the case of static content or video on demand, S also sends to B the SHA-1 hash H

(c) for all chunks c of hFi.

S

−→ B:[content response] T

SA

, hPi list

,

H

(c) list

, hFi,t, i

Step 3: The client B forwards this request to each A

P

S

list the rest of this description, we list only the steps that involve

B, and a specific client A.

. In

C as H

(C). Subsequently, it computes its commitment to the encrypted chunk as T

The tickets T

AS

AS

= MAC

K

SA

[hAi, hBi, hFi, hci, H(C),t].

are only valid for a certain time length

L key

, which forces B to expedite paying for decrypting the encrypted chunks. This fact allows A to promptly acquire credit for its service. A sends the following to B.

A

−→ B:[chunk response] T

AS

, hFi, hci,C,t, i

A

Observation 1 A malicious client B can abandon the protocol after receiving the encrypted chunk without completing the transaction. In such case, A does not receive any credit, even though B has consumed A’s resources. This is a Denial of

Service (DoS) attack against A. Note that this attack would require client B to expend resources proportional to the resources of the victim A, therefore it is not particularly practical. Nevertheless, we prevent clients that have been designated as misbehavers (blacklisted) or clients that do not maintain paid accounts with the content provider from launching such attack; the server S issues short-lived tickets

T

SA

(step

(2)) only to authorized and non-blacklisted clients.

B

−→ A:[content request] T

SA

, hFi,t, i

S

Step 7: Since B does not know the key K

SA

to generate k hci that was used in step

(6), it needs to request k hci from the server. As soon as B receives the encrypted chunk, B computes its own hash over the received ciphertext C

′ and forwards the following to S.

Step 4: If current-time

t + L

peer

and T

SA

is not in A’s cache, A verifies whether T

SA

= MAC

K

SA

[hAi, hBi, hFi,t].

If the verification fails, A drops this request. Also, if i

S

is greater than A’s current time period i

A

, A learns that it should renew its key with S soon. Otherwise, A caches T

SA

and periodically sends the chunk announcement message described below, for as long as the timestamp t is fresh.

This message contains a list of chunks that A owns, hci list

. B also does so in separate chunk announcement messages. The specifics of which chunks are announced and how frequently depend on the type of content distribution.

A

−→ B:[chunk announcement] hci list

T

AS

B

−→ S:[decryption key request] hAi, hFi, hci, H(C

,

i

A

),t,

Observation 2 To maintain an efficient content distribution pipeline, a client needs to relay a chunk to its peers as soon as it receives it. However, the chunk may be invalid due to communication error or due to client misbehavior. The performance of the system would be severely degraded if clients wasted bandwidth to relay invalid content. To address this issue, Dandelion clients send a decryption key request to the server immediately upon receiving the encrypted chunk.

This design choice enables clients to promptly retrieve the chunk in its non-encrypted form and verify its integrity prior to uploading the chunk to their peers.

Step 5: B and A determine which chunks to download from each other according to a chunk selection policy, e.g.

BitTorrent’s locally-rarest-first is suitable for static content distribution. while for streaming content or video on demand other policies are appropriate [27, 28]. A can request chunks from B, after it requests and retrieves T request for the missing chunk c to A.

SB

from S. B sends a

B

−→ A:[chunk request] T

SA

, hFi, hci,t, i

S

Observation 3

If a client does not have sufficient credit, it cannot download chunks from a selfish peer that is not interested in the client’s content. Our design choice to involve the server in the fair exchange of content uploads for credit enables the server to check a client’s credit balance, before the client retrieves the decryption key of a chunk.

Step 6: B’s chunk requests are served by A as long as the timestamp t is fresh, and T

SA

is cached or verifies.

If A is altruistic, it sends the chunk c to B in plaintext and the per-chunk transaction ends here. Otherwise, A encrypts c using a symmetric encryption algorithm Enc, as

C

= Enc

k

hci

(c). k hci is a key and encryption initialization vector pair generated as (MAC

K

SA

MAC

K

SA

[hAi, hBi, hFi, hci,t, 0],

[hAi, hBi, hFi, hci,t, 1]). Next, A hashes the ciphertext

Lemma 1

A selfish or a malicious client cannot assume another authorized client A’s identity and issue messages under A, aiming at obtaining service at the expense of A, charging A for service it did not obtain or causing A to be blacklisted. In addition, it cannot issue a valid T

SA

for an invalid chunk that it sends to a client B and cause B to produce a complaint message that would result in a verdict against A.

6

Proof 1 The only way a misbehaving client can be successful in such attack is by obtaining the user authentication information or the shared secret key K

SA

. However user authentication, and the transmission of the shared secret key

K

SA

is performed over the secure session between A and the server S.

S

−→ B:[decryption key response] hAi, hFi, hci, k

′ hci

B uses k

′ hci to decrypt the chunk as c we explain the complaint mechanism.

= Dec

k

′ hci

(C

). Next,

Otherwise, if H

(C

′′

) 6= H(C

), S decides that B was cheated by

A, blacklists A, revokes the corresponding credit charge on B and notifies B that its complaint has been resolved. Similarly,

B disconnects from A and blacklists it. In addition, the server may penalize the misbehaver by imposing a high credit charge.

The server disconnects from a blacklisted client E, marks it as blacklisted in the credit file and denies access to E if it attempts to login. Future complaints that concern E and are non-duplicate, non-expired and with valid tickets, are ruled against E without further processing.

Step 8: If current-time off, S checks if T

AS

The ticket’s T

AS

t + L

= MAC

key

K

SA

, and i

A

is not too much

[hAi, hBi, hFi, hci, H(C

′ verification may fail either because C

),t].

6= C due to transmission error in step

(6) or because A or B are misbehaving. Since S is unable to determine which is the case, it punishes neither A or B and does not update their credit. It does not send the decryption key to B but it notifies B of the discrepancy. In this case, B is expected to disconnect from A and blacklist it in case A repeatedly sends invalid chunk response messages. If B keeps sending invalid decryption key requests that involve A, S penalizes him. If the verification succeeds, S checks whether B has sufficient credit to purchase the chunk c. It also checks again whether

B has access to the content hFi. If B is approved, S charges

B and rewards A with

c

credit units. Subsequently,

S

computes

k

MAC

K

SA

′ hci as (MAC

K

SA

[hAi, hBi, hFi, hci,t, 0],

[hAi, hBi, hFi, hci,t, 1]) and sends it to B.

Step 9: If the decryption fails or if H

(c

) 6= H(c) (step (2)),

B complains to S by sending the following message.

Lemma 2 If the server S charges a client B

c

credit units for a chunk c received from a selfish client A, B must have received the correct c, regardless of the actions taken by A.

Proof 2 B gets charged only if the ticket T

AS

that S gets from

B in step

(8) verifies. This means that the values A sent to B in

Step

(7) are the ones A used to compute T

AS

H

(C

′ and that H

(C) =

). Since H is a second pre-image resistant cryptographic hash that B computes itself on C

′ received from A, C

= C

.

Thus, B is charged only if the encrypted chunk received by

B is the encrypted chunk to which A has committed to. Since the same k hci is used by A to encrypt c into C decrypt C into c

, C

= C

′ implies that c

= c.

′ and by B to

If A encrypts an invalid chunk c and sends it to B, B can issue a complain to S. For the complaint to be ruled against

B, we should have H

(C

) = H(C

′′

), where C

′′ is computed by S in step

(9). Since T

AS

is accepted by S, all the values S used to compute T

AS

are the ones that A sent to B, and the hash H

(C

) is correctly computed over the ciphertext C that

A sent to B. Consequently, S would generate the same k hci with the one A used. Therefore, S’s encryption C

′′ would not be the same as the C that A sent to B. Consequently, H

(C

) would not be equal to H

(C

′′

) and S would reverse B’s charge.

B

−→ S:[complaint] hAi, hFi, hci, T

AS

,

H

(C

),t, i

A

L

S ignores this message if current-time > t

+ L

key

key

>

L key

. L

key

L

key

, where should be greater than the time needed for B to receive a decryption key response, decrypt the chunk and send a complaint to the server. With this condition, a misbehaving client A cannot avoid having complaints ruled against it, even if A ensures that the time elapsed between the moment A commits to the encrypted chunk and the moment the encrypted chunk is received by B is slightly less than L

key

. S also ignores the complaint message if a complaint for the same

A and c is in a cache of recent complaints that S maintains for each client B. Complaints are evicted from this cache once

current-time > t

+ T

key

If T

AS

6=MAC

K

SA

.

[hAi, hBi, hFi, hci, H(C

),t], S punishes B.

This is because S has already notified B that T

AS

is invalid in step

(7). If T

AS

verifies, S caches this complaint, re-computes

k

′ hci once again, retrieves c from its storage, and encrypts c himself using k

H

(C

′ hci

, C

′′

= Enc

k

′ hci

(c). If the hash of the ciphertext

′′

) is equal to the value H(C

) that B sent to S, S decides that A has acted correctly and B’s complaint is unjustified.

Subsequently, S drops the complaint request and blacklists B.

It also notifies A, which disconnects from B and blacklists it.

Lemma 3 If a selfish client A always encrypts chunk c anew when serving a request, as described in Step

(6), and if B gets correct c from A, then A is awarded

c

credit units from

S, and B is charged

c

credit units from S.

Proof 3 A generates k hci using a secure MAC function and a secret key K

SA

, which is unknown to B because it was transmitted over the secure session between A and the server

S. Therefore, the only way for B to retrieve k hci is to request it from S (step

(7)), in which case S logs a charge against B.

The only way B can possibly avoid this charge is by sending a complaint to S, which includes T

AS

H

(C

′ and

). For the complaint to be ruled in favor of B, it should hold that H

(C

) 6= H(C

′′

), where C

′′ is computed by S in step

(9). However, S will accept T

AS

T

AS

= MAC

K

SA

[hAi, hBi, hFi, hci, H(C

′ only if

),t]. This means that all the values S used to compute T

AS

to B, and that the hash H

(C

′ are the ones that A sent

) is correctly computed over the ciphertext C that A sent to B. Since this is the case,

S would decrypt e to the same k hci encryption C

′′ that A used, hence S’s would be the same as the C that A computed.

Consequently, H

(C

) would be equal to H(C

′′

) and B would be unable to reverse its charge.

Lemma 4

A malicious client cannot replay previously sent valid requests to the server or generate decryption key requests or complaints under A’s ID, aiming at A being charged for service it did not obtain or being blacklisted because of invalid or duplicate complaints.

Proof 4

All messages exchanged between a client A and the server are digitally signed with the shared secret key K

SA

and include sequence numbers. Both the client and the server store the last sequence number seen by each other and the sequence numbers are reset upon i change. Thus, a malicious client cannot forge the source of the request, neither it can resent a request that has already been received.

Figure 2.

UL and DL indicates the maximum rate with which a client can upload and download content, respectively. Optimally, client A should upload plaintext at 10KB/sec, 20KB/sec and 50KB/sec to B, C and D, respectively. In addition, it should upload encrypted content at 10KB/sec to any two of clients B, C of D.

Observation 4

A malicious client cannot DoS attack the server by sending invalid content to other clients or repeatedly sending invalid complaints aiming at causing the server to perform the relatively expensive complaint resolution. That client must be a user registered with the system, otherwise it is not able to cause issuance of complaints that merit resolution. Even if the client is a registered user, it becomes blacklisted by both the server and its peers the moment an invalid complaint is ruled against it. In addition, a malicious client cannot attack the server by sending valid signed messages with duplicate valid complaints. Our protocol detects duplicate complaints through the use of timestamps and caching of recent complaints.

Since a verdict on a complaint can adversely affect a client, each client needs to ensure that the commitments it generates are correct even in the rare case of a local I/O error. Therefore, a client always verifies the read chunk against its hash before it encrypts the chunk and generates its commitment.

B. Rate-based Tit-for-Tat with Trade Surplus

Limiting

In this section, we describe how Dandelion combines the cryptographic fair-exchange of content uploads for credit, with tit-for-tat (TFT) exchange of content uploads.

The cryptographic fair-exchange-based portion of our incentive mechanism addresses the fairness issue in tit-for-tat-based cooperative content distribution. Users that cannot upload at the rate their peers upload to them, pay the excess offered bandwidth in credit. When two clients are mutually interested in each other’s content and are able to upload to each other at the same rate, they are able to use tit-for-tat incentives. The tit-for-tat portion of our incentive mechanism aims at reducing the decryption key request load on the server. It enables a pair of clients to barter their uplink resources without requiring the server to mediate their transactions.

A Dandelion client must be able to switch between the two modes of the incentive scheme depending on content availability and peer upload and download rates. Therefore, we need an algorithm that aims at reducing the amount of encrypted chunks uploaded to each peer, while it ensures that the client uploads to its peers at the maximum rate its peers can download from it.

We exemplify the above criterion in Figure 2. From the perspective of a client, this is a simple local linear optimization problem. It can be solved by allocating uplink bandwidth for plaintext uploads to match each peer’s content upload rate in a decreasing order, starting from the fastest uploader. The remaining uplink bandwidth is allocated for encrypted content uploads.

However, such bandwidth allocation algorithm requires a client to perform fine-grained adjustments of encrypted and plaintext content upload rates per peer, while ensuring that the chosen upload rates are in fact rates with which peers can download from the client. This fine-grained resource allocation is difficult to achieve in the context of BitTorrent-like content distribution. The rates with which peers can upload and download from each other vary substantially over time, due to content availability and overlay network churn. Inaccuracies in allocating plaintext and encrypted content upload rates result in uplink under-utilization, increased decryption key request load on the server or excessive susceptibility to free-riding.

Rather than employing a complex per-peer resource allocation algorithm, we use the following simple scheme. At any moment a client selects a specified number of peers to which it may upload to (see next subsection for details on the downloader selection criteria). If a client does not expect its peers to obtain content that interests the client (e.g. if the client is a seeder in BitTorrent-like distribution), it always uploads encrypted chunks. Otherwise, for each of its peers, the client maintains a variable that indicates the trade surplus in the tit-for-tat exchanges of plaintext content.

The trade surplus is equal to the number of plaintext chunks the client has uploaded to its peer minus the number of plaintext chunks the client has downloaded from its peer. For the purpose of maintaining the trade surplus while preventing whitewashing [29], the client keeps persistent session information for each of its peers, and identifies peers by their IP.

Each client responds to requests for chunks from its selected downloader peers with plaintext chunks if the trade surplus is less than or equal to a specified threshold s. Otherwise if the surplus exceeds s, the client responds with encrypted chunks.

As s increases, trading flexibility also increases. This en-

7

ables a client to upload plaintext chunks in case its peers only temporarily cannot match the client’s upload rate, resulting in reduction of encrypted chunk transmissions. However, a large s makes the system more susceptible to free-riders. We experimentally analyze this trade-off in Section VI-C.

1) Downloader Selection

Dandelion’s downloader selection algorithm aims at reducing the amount of content that is transmitted encrypted, and thus requires the involvement of the server. At the same time it aims at increasing a client’s uplink and downlink utilization. It is similar to BitTorrent’s choking algorithm. In the following description, n denotes the number of peers that download in parallel from a client. o denotes the number of peers that are optimistically selected as downloaders.

The algorithm is periodically executed by each client every

T secondS. It is also executed when a peer that is selected to be downloader disconnects. The algorithm proceeds as follows: a) if the client is a leecher, peers that are interested in the client’s content are ranked based on the rate with which they upload plaintext to the client, else if the client is a seeder, peers are ranked based on the rate with which they download from the client; b) the client selects as downloaders the n

o top ranked peers; and c) every O seconds, the client randomly selects o additional downloaders from the non-selected nodes that are interested in the client’s content., These o downloaders remain selected for the next O seconds and during that period they are not ranked in step (a). Step (c) is performed in expectation of discovering a fast uploader and to jumpstart peers that recently joined the swarm.

When a leecher selects the fastest plaintext uploaders, it selects peers that are more likely to match its plaintext upload rate and thus exchange chunks in a tit-for-tat fashion. This results in invoking the cryptographic fair-exchange mechanism less often. A similar property has been shown to hold for

BitTorrent’s chocking algorithm, which induces clustering between peers that have comparable upload rates [30, 31].

By dynamically adjusting n we ensure that the uplink of a client is not underutilized At the same time, downloader selection and dynamic n adjustment improves download completion times by limiting the number of peers a client concurrently uploads to. Consequently, complete chunks are made available to other peers and relayed by them at faster rates.

2) Mitigating Free-riding

The above hybrid incentive scheme is in theory susceptible to the “large view” exploit (Section II-B). A client may attempt to open connections to numerous peers aiming at exploiting the trade surplus threshold (s) plaintext chunks that its peers upload in expectation of TFT reciprocation.

However, our incentive mechanism substantively mitigates the effectiveness of the large view exploit in the following three ways. First, rational Dandelion seeders always use the cryptographic fair exchange mechanism to ensure that they are rewarded for their service with credit, therefore free-riders that connect to them never benefit. Second, our hybrid incentive scheme limits the amount of content a free-rider can obtain for free by imposing an upper limit to the plaintext chunk trade surplus between any two leechers. Third, by biasing the downloader selection towards the fastest plaintext content uploaders instead of the fastest content uploaders, free-rider peers cannot increase the frequency with which they become unchoked by uploading encrypted content at high rates. As a result, in steady state, free-riders download plaintext only when they are optimistically unchoked.

Unlike chunk-level tit-for-tat [9, 32] or rate-based tit-for-tat with very short optimistic unchoking period, our hybrid incentive scheme does not penalize cooperative peers that have reduced upload capacity. Dandelion clients that have substantially slower uplink than downlink or have no content to reciprocate with, can still download the offered content by paying the excess service in virtual credit.

Observation 5

A free-rider client that does not upload any plaintext content and is unwilling to expend credit to purchase chunks obtains substantially lower download rates than protocol-compliant clients. We support this statement in Section VI-C, where we provide an experimental evaluation of free-riding in realistic Dandelion swarm settings.

In our experiments, free-riders attain low download rates, however they do not incur any cost in terms of virtual credit or uplink utilization. Clients that wish to achieve good download rates but at a lower cost, may violate the fairness properties of the scheme by employing the large view exploit, while expending credit to download from peers. Since our scheme relies on monetary rewards to foster cooperation, manipulation of its incentive mechanism translates to monetary losses for the content provider and its cooperative clients. Hence, free-riding is a highly undesirable behavior. Fortunately, our system enables the content provider to regulate free-riding by adjusting the trade surplus threshold.

C. Discouraging Unauthorized Content distribution

As discussed above, a client that is interested in its peers’ content, is incented to upload to those peers through the use of a tit-for-tat-based incentive mechanism, regardless of whether the peer is authorized by the content provider.

On the other hand, a Dandelion client that is not interested in an unauthorized peer’s content is discouraged from uploading to that peer. This is because such client has no incentive to upload to the unauthorized peer other than the credit he could earn through the use of Dandelion’s cryptographic fairexchange protocol. However, the Dandelion server mediates all transactions that employ the fair-exchange protocol. Hence, the server is able to not reward a client that serves unauthorized peers.

Clients are able to verify the legitimacy of requests for service (step

(4) in Section IV-A3), hence they can avoid wasting bandwidth to serve unauthorized clients. Furthermore, precisely because of this ability, clients can be held legally liable if they choose to send content to unauthorized clients.

These properties discourage users from using Dandelion for illegal content replication and make our solution even more appealing to distributors of copyright-protected digital goods.

8

For example, selfish seeders have no incentive to facilitate unauthorized content distribution. Our scheme motivates seeders to behave selfishly and not altruistically. That is, seeders are reluctant to waste bandwidth to upload to unauthorized users because they can use their bandwidth to upload to authorized users and earn monetary rewards.

In some BitTorrent deployments, content access policies are enforced by requiring authentication with the tracker.

However, an unauthorized peer can join the network simply by finding a single colluding peer that is willing to share its swarm view with it. The unauthorized peers can then download content from authorized seeders, which are by definition altruistic and have no real motivation to deny service to unauthorized peers. Consequently, a single authorized, rational but misbehaving peer can facilitate illegal content replication at a large scale.

D. Discussion

Owing to Lemmas 1, 2 and 3, as well as Observations 3 and 5, and given that the content provider employs appropriate pricing schemes, Dandelion ensures that selfish (rational) clients increase their utility when they upload correct chunks, while misbehaving clients cannot increase their utility. Consequently, Dandelion entices selfish clients to upload to their peers, resulting in a Nash equilibrium of cooperation.

V. Implementation

This section describes a prototype C implementation of the Dandelion system, which is suitable for static content distribution. It uses the OpenSSL toolkit for cryptographic operations.

A. Server Implementation

The server and the credit base are logical modules and can be distributed over a cluster to improve scalability. For simplicity, our current implementation combines the content provider and the credit base at a single server. It is our future work to adopt load balancing techniques in order to split the load of a Dandelion server over multiple machines.

The server implementation is single-threaded and eventdriven. The network I/O operations are asynchronous, and data are transmitted over TCP. In order to scale to thousands of simultaneously connected clients, the server employs the

epoll event dispatching mechanism. The server stores in heap memory information for each of the clients with which it has an active Dandelion session.

The server uses standard file I/O system calls to efficiently manage persistent client information, which is stored in a simple file called the credit file. Each client is assigned an entry in the credit file, which keeps the client’s credit, its authentication information and its file access control information. Each entry has the same size and the client ID determines the offset of the entry of each client in the file, thus each entry can be efficiently accessed for both queries and updates.

The server queries and updates a client’s credit from and to the credit file upon every transaction. Yet, it does not force commitment of the update to persistent storage. Instead, it relies on the OS to asynchronously perform the commitment.

If the server application crashes, the update will still be copied from the kernel buffer to persistent storage. Still, the OS may crash or the server may lose power before the updated data have been committed. However, in practice, a typical

Dandelion deployment would run a stable operating system and use backup power supply. In addition, transactions would not involve very large amounts of money per user. Hence, we believe it is preferable not to incur the high cost of committing the credit updates to non-volatile memory after every transaction (operation 14 in Table I, Section VI-A2).

B. Client Implementation

The client side is also single-threaded and event-driven. A client may leech or seed multiple files at a time. A client can be decomposed into two logical modules: a) the connection

management module; and b) the peer-serving module.

The connection management module performs peering and

uploader discovery. With peering, each client obtains a random partial swarm view from the server and strives to connect to O

(log n) peers, where n is the number of nodes in the

Dandelion swarm, as communicated to the node by the server.

As a result, the swarm approximates a random graph with logarithmic out-degree, which has been shown to have high connectivity [33]. With uploader discovery, a client attempts to remain connected to a minimum number of uploading peers.

If the number of recent uploaders drops below a threshold, a client requests from the server a new swarm view and connects to the peers in the new view.

The peer-serving module performs content reconciliation and downloader selection. Content reconciliation refers to the function of announcing recently received chunks, requesting missing chunks, requesting decryption keys for received encrypted chunks, and replying to chunk requests. To efficiently utilize their downlink bandwidth using TCP, clients strive to keep at all times a specified number of outstanding chunk requests [4, 34] that have been sent to a peer and have not been responded to. We described downloader selection in detail in

Section IV-B1.

VI. Evaluation

The goals of this experimental evaluation are: a) to identify the scalability limits of Dandelion’s centralized nonmanipulable virtual-currency; b) to demonstrate the importance of incentives for seeding and compare the performance of our Dandelion-based content distribution to BitTorrent; c) to examine the trade-off between performance and scalability in selecting the chunk size; and d) to demonstrate our hybrid incentive scheme’s resilience to free-riding.

1

A. Server Performance

In this section, we evaluate and profile the server in terms of decryption key and complaint request throughput.

1) Server Throughput

A Dandelion server mediates the chunk exchanges between its clients. The client plaintext download throughput and the

1

Dandelion’s source code for Linux and scripts to run our experiments can be found at www.ics.uci.edu/

∼ msirivia/dandelion.

9

10

3000

2500

2000

1 Mb/s

2 Mb/s

3 Mb/s

4 Mb/s

5 Mb/s

1500

1000

500

0

0 1 2 3 4 5

Request rate (req/sec per client)

(a)

6

100

80

60

1Mbps

2Mbps

3Mbps

4Mbps

5Mbps

40

20

0

0 1 2 3 4 5

Request rate (req/sec per client)

(b)

6

100

10

1

0.1

0

1Mbps

2Mbps

3Mbps

4Mbps

5Mbps

1 2 3 4 5

Request rate (req/sec per client)

(c)

6

Figure 3.

Server decryption key response throughput evaluation. as a function of specified per-client key request rate, for varying server ratelimits.

1000 clients send decryption key requests. (a) Aggregate decryption key response throughput of the Dandelion server; (b) server’s CPU

utilization(%); (c) server’s memory utilization (% in logarithmic scale).

scalability of our system is bound by how fast a server can process their decryption key requests (step

(7), Section

IV-A3). Both the server’s computational resources and bandwidth may become the performance bottleneck. We deploy a

Dandelion server on a dual Pentium D 2.8GHZ/1MB CPU with 1GB RAM and 250GB/7200RPM HDD running Linux

2.6.5-1.358smp, which shares a 100Mbps Ethernet II link.

To mitigate bandwidth variability in the shared link and to emulate a low cost server with uplinks and downlinks that range from 1Mbps to 5Mbps, we rate-limit our Dandelion server at the application layer. We deploy

∼1000 clients that run on

∼100 distinct PlanetLab hosts.

The clients send requests for decryption keys to the server and we measure the aggregate rate with which all clients receive decryption key responses. The server always queries and updates the credit base from and to the credit file without forcing commitment to disk. We run each experiment for a specified per-client request rate, which varies from 1 to 6 req/sec. For each request rate, the experiment duration was 10 minutes and the results were averaged over 10 runs. The clients may send requests at less than the specified rate, because 10 clients compete for the same network and CPU resources on each machine. The clients may send a new request prior to receiving the response from the server.

Figure 3(a) depicts the server’s decryption key throughput for varying server bandwidth. As the bandwidth increases from 1Mbps to 5Mbps, the server’s decryption key response throughput increases. This indicates that for 1Mbps to 4Mbps access links, the bottleneck is the bandwidth. The results show that a server running on our commodity PC with 4Mbps or 5Mbps access link can process up to

∼3105 decryption key requests per second. This indicates that with a 256KB chunk size, this server may simultaneously support almost

3100 clients that download only encrypted chunks at 256KB/s.

With a larger chunk size, each such client receives complete chunks at a lower rate, which means that it sends decryption key requests less often. Thus the number of supported clients increases with the chunk size.

We also run experiments with

∼ 500 clients each set to send 10 req/sec (not depicted in Figure 3). By comparing the throughput of the 5Mbps server’s throughput in this case

(3114 req/sec) with its throughput when

∼ 1000 clients send

5 req/sec each (3105 req/sec), we infer that the system’s performance in the examined range of number of connections is independent of the number of connected clients.

Figures 3(b) and 3(c) show the average CPU and memory utilization at the server over the duration of the above experiments. We observe that for 5Mbps, the server’s CPU utilization reaches

∼100%, indicating that the bottleneck is the CPU. In

Figure 3(c), we see that the server consumes a very small portion of the available memory, even under overload.

A Dandelion server is also responsible for resolving complaints (step

(9), Section IV-A3). A complaint resolution involves the expensive disk I/O operation for reading a chunk.

Therefore it represents a performance bottleneck in case the system receives too many complaints. In an experiment with

∼1000 clients sending 5 decryption key request per second, and

∼30 clients sending 1 complaint resolution request (involving a randomly selected 128KB chunk of a 1GB file), the 5Mbps server was able to deliver 1540 decryption key responses per second along with 21 complaint resolution responses per second. In an experiment with

∼60 complaint sending clients, we measured the maximum complaint resolution throughput of a 5Mbps Dandelion server to be 52 complaint responses per second.

Note that the server does not need to deliver a high complaint resolution throughput for the reasons listed in

Observation 4, Section IV-A3. In addition, the expensive disk

I/O operation can be performed using asynchronous disk I/O, allowing for decryption key requests to be processed efficiently while the server is waiting for disk I/O operations to complete.

2) Server Profiling

We profile the cost of operations at the server aiming at identifying the performance bottlenecks of our design. The machine used for profiling is the same as the one used in the previous section.

Table I lists the cost of Dandelion operations. Timings for operations 1-4 and 6-8 are obtained using getrusage() over

10000 executions. Timings for operations 5, 9 and 12-14 are approximated using gettimeofday() over 10000 executions.

Operation 5 reads from the disk a new randomly selected

128KB chunk of a 1GB file in each execution. Operations 12-

14 are performed on a credit file with 10000 44-byte entries.

11

Dandelion operation

1

2

5

6

3

4

7

8

CPU-centric Operation

Authenticate decryption key request

58 bytes

Generate ticket for decryption key 38 bytes key request or complaint verification

Compute decryption key

Sign decryption key response

Read chunk

Encrypt chunk

Hash encrypted chunk

Event dispatching epoll wait())

19 bytes

46 bytes

128 KB

128 KB

128 KB

N/A

9 on 1000 socket descriptors

Establish SSL session

(SSL accept())

Communication Operation

10 Receive decryption key request

11 Transmit decryption key response

N/A

96 bytes

84 bytes

Credit Management Operation

12 Query credit file

13 Update credit file without commit to disk (rely on OS)

14 Update credit file and force commit to disk

Size

N/A

N/A

N/A

Table I.

Timings of Dandelion operations.

Time (ms)

.018

.018

.018

.018

18

.715

.487

0.002

19

∼.26

∼.24

∼0.004

∼0.02

∼9.25

Timings for operations 10 and 11 are approximated according to our application layer rate-limiting for 5Mbps uplink and downlink. They are provided as reference for comparison with

CPU-centric and credit management operations. Operation 6 uses 8-byte-block Blowfish-CBC with 128-bit key and 128bit initialization vector.Operations 1-4 use HMAC-SHA1 with

128-bit key. Operation 7 uses SHA-1. For operation 14, we use fsync() and we disable HDD caching.

The main task of a Dandelion server is to: a) receive the decryption key request (operation 10); b) authenticate the message (operation 1); c) verify the ticket (operation 2); d) compute the decryption key (operation 3); e) query and update the credit of the two clients involved (operations 12 and 13); f) sign the decryption key response (operation 4); and g) send the decryption key response (operation 11).

The signed decryption key request and response messages are sent over an insecure TCP connection. A client establishes and uses the secure TLS channel with the server (operation 9) only to send authentication information (once per Dandelion session) and the key (the same key is used for a relatively long period) that the server and a client share.

As can be seen in Table I, the per-decryption-key-request cryptographic operations of the server (operations 1-4) are highly efficient (total 72µsec), as only symmetric cryptography is employed. The credit management operations (12 and 13) are also efficient (total 24µsec). The communication costs of receiving and sending decryption key responses (operations

11-12) are clearly higher than the cryptographic computation costs. Operations 11-12 can take place concurrently with each other and the computational operations.

Committing the credit file per transaction (operation 14), could yield 10-20 times lower decryption key response throughput than relying on the OS to commit credit file updates

(operations 13).

The cost of a complaint is a lot higher because in addition to authenticating the message and verifying a ticket, it involves reading a chunk (operation 5), encrypting it with the sender client’s key (operation 6), and hashing the encrypted chunk

(operation 7).

The cost of event dispatching (operation 8) is not significant if we use the highly efficient and scalable epoll instead of the

select API. Indicatively, the less scalable select() costs 0.009

ms when used to dispatch 500 sockets and 0.017 ms when used to dispatch 1000 sockets. On the other hand, epoll wait() costs approximately only 0.002 ms for both 1000 and 100 sockets. This reveals that the choice of event dispatching mechanism is critical for the performance of the system. Under the same experimental configuration with the one used in

Section VI-A1, a 5Mbps server that used select() instead of

epoll wait() was able to process only 799 decryption key requests per second.

B. System Performance

In this section, we experimentally evaluate the behavior of the entire Dandelion system on PlanetLab. We demonstrate the performance gains of providing incentives for seeding.

In addition, we examine the impact of chunk size on the performance of the system. Last, we compare our system’s performance to BitTorrent’s. In all experiments, we run a

Dandelion server on a highly available PlanetLab host. We rate-limit the server at 5Mbps.

Leechers are given sufficient initial credit to completely download a file. Dandelion clients always respond to chunk requests from their selected downloaders. We also set the TCP sender and receiver buffer size equal to 120KB in order to cover the bandwidth-delay product. We have adjusted both Bit-

Torrent’s and Dandelion’s parameters (number of outstanding requests, number of unchoked peers, timeouts, socket buffer sizes, etc) to achieve good performance under our bandwidth distribution in the PlanetLab environment. In particular, we set the parameters described in Section IV-B1 as follows: T =10,

n=10, o=2 and O=10. All clients remain online seeding after finishing their download, unless noted otherwise in certain experiments.

We aim at making our evaluation representative of real

Internet peer-to-peer content distribution swarms. We partially emulate a typical client uplink bandwidth distribution [35]

(Table II) by applying per-client application layer rate-limiting.

Since PlanetLab resources are shared among competing slices, some hosts are unable to achieve some of the high bandwidth values specified by that distribution. To address this issue, we observe that the upload rate of 80% of hosts in that distribution is less than or equal to 256KB/sec. To accommodate those 80% of nodes, we used PlanetLabs resource reservation service, called Sirius, which ensures that our slice obtains at least 2Mbps on each PlanetLab host. For the remaining

20% of hosts, which require bandwidth between 500KB/sec and 10000KB/sec, we were unable to identify hosts able to consistently achieve such high rates, thus we assigned

256KB/sec upload rates to those nodes. The initial seeders in each experiment are rate-limited at 256KB/sec.

Due to PlanetLab’s bandwidth constraints, our bandwidth distribution has

∼80% less swarm-wide average upload capac-

12

Portion of nodes

Bandwidth (KB/sec)

Portion of nodes

Bandwidth (KB/sec)

0.05

0.05

0.1

0.1

40 50 55 60

0.1

70

0.1

65

0.05

0.1

0.1

0.25

75 100 200 256

Table II.

Distribution of upload bandwidth of Dandelion and BitTorrent peers as used in our PlanetLab experiments. This distribution draws from the one reported in [35], but due to PlanetLab bandwidth costraints we omit hosts with upload capacity higher than 256KB/sec.

ity than the one of the distribution reported in [35]. Although our distribution does not faithfully reflect real Internet conditions, it enables us to derive conclusions on the behavior of real BitTorrent swarms that do not include very high capacity peers. At the same time, we are able to perform repeatable and reproducible experiments with reduced bandwidth variability.

For each configuration we repeat the experiment 5 times and we extract mean values and 95% confidence intervals over the swarm-wide file download completion times.

1400

1200

1000

800

600

400

200

0

BitTorrent 25% seeders

Dandelion 25% seeders

BitTorrent 100% seeders

Dandelion 100% seeders

1 5 10

File Size (MB)

25 50 100

Figure 4.

Swarm-wide mean download completion times of

200

leechers as a function of file size for varying portion of leechers that become seeders.

1) Impact of Seeders

One of Dandelion’s main advantages is that it provides robust incentives for clients to seed. With this series of experiments, we quantify the performance gains from the existence of seeders under a flash-crowd scenario. Under different scenarios, seeders may play a more or a less beneficial role. For example, the existence of additional high capacity seeders is critical for the performance of swarms of peers with asymmetric low capacity links. Seeders are also critical in case the content provider does not have the resources to adequately seed the content.

In each experiment, we deploy

∼200 leechers and one initial seeder. Leechers start downloading the file almost simultaneously. The duration of each experiment is 3600sec.

We show the impact of seeders in both Dandelion and

BitTorrent (CTorrent 1.3.4 [36]) swarms by varying the probability that a leecher remains online to seed a file after it completes its download. In each experiment, a swarm has one initial seeder. Upon completion of its download, each leecher stays in the swarm and seeds with probability a. Probability

a varies in 10% and 100%. We set the trade surplus threshold variable (see Section IV-B) equal to the number of chunks in the file and the chunk size equal to 128KB.

Figure 4 depicts the mean download completion time over all

∼200 leechers as a function of the file size, for varying

a. The results show the beneficial impact of seeders and the importance of a mechanism to robustly incentivize seeding.

For example, for a 100MB file, we observe a swarm-wide mean download completion time of 1059sec and 1220sec when Dandelion leechers become seeders with 100% and 25% probability, respectively. If we express the impact of seeders as the ratio of the mean download time for a

= 100% over the mean download time for a

= 25%, we observe that the impact is reduced as the file size increases. The larger the file is, the longer clients remain online to download it, resulting in clients contributing their upload bandwidth for longer periods. For smaller files however, leechers rely heavily on the initial seeder and the leechers that become seeders to download their content from. Therefore for small files, a reduction in probability a results in substantially longer download completion times.

2) Comparison with BitTorrent

Figure 4 also shows the mean download completion time of

∼200 tit-for-tat compliant BitTorrent leechers. The purpose of this illustration is to show that Dandelion can attain performance comparable to the one achieved by BitTorrent, although it frequently requires the involvement of the server and it employs a modified downloader selection algorithm.

Although Dandelion appears to outperform BitTorrent for certain file sizes, we do not claim that it is in general a betterperforming protocol. The performance of both protocols is highly dependent on numerous parameters, which we have not exhaustively analyzed.

3) Selecting Chunk Size

1600

1400

1200

1000

800

10 MB File

100 MB File

600

400

200

0

64 256 512 1024

Chunk Size (KB)

2048

Figure 5. Swarm-wide mean download completion times of

200 leechers

as a function of chunk size for 10MB and 100MB file.

This experiment aims at examining the trade-offs involved in selecting the size of the chunk, the verifiable transaction unit in Dandelion. Intuitively, since clients are able to serve a chunk only as soon as they complete its download, a smaller chunk size yields a more efficient distribution pipeline. In addition, when the file is divided into many pieces, chunk scheduling techniques such as rarest-first can be more effective, because clients can promptly discover and download content of interest.

13

However, a smaller chunk size increases the rate with which key requests are sent to the server, reducing the scalability of the system. In addition, due to TCP’s slow start, a small chunk size cannot ensure high bandwidth utilization during the

TCP transfer of any chunk. Furthermore, small chunks yield increased control overhead.

In each configuration, we deploy approximately 200 Dandelion leechers and one initial seeder. Leechers start downloading files almost simultaneously emulating a flashcrowd. The duration of each experiment for the 10MB and 100MB file is 600sec and 3600sec, respectively. We set the trade surplus threshold parameter (see Section IV-B) equal to the number of chunks in the file.

Figure 5 shows the leecher mean download completion time as a function of the chunk size. For the small 10MB file, we obtain the best performance for chunk size equal to 128KB.

The system’s performance degrades with the chunk size. For the larger 100MB file, the beneficial impact of small chunks is less significant, because there are sufficiently many distinct chunks for peers to exchange. For example, for a 100MB file, a 256KB chunk size yields notably better performance than a

128KB chunk size.

computed over the file download completion time. Otherwise, its download rate is computed over the experiment duration.

1) Connecting to Many Peers and Downloading from

Seeders

We investigate how the number of peers that free-riders connect to affects the free-riders’ download rates. We also compare the performance of free-riders with the performance of cooperative peers. In addition, we evaluate the effectiveness of free-riding when seeders do not employ Dandelion’s virtual currency system, but instead upload altruistically.

1

0.8

0.6

0.4

0.2

0

0

50 connections

100 connections

5 10 15 20 25

Download Rate (KB/sec)

30 35

C. Resilience to Free-riding

In this section, we evaluate the hybrid incentive scheme’s resilience to free-riding. We also quantify the gains this scheme offers with respect to reduction of the load on the server.

In each experiment, we deploy

∼200 leechers, which include free-riders, and one initial seeder. All clients join the swarm simultaneously to download a 100MB file divided in

128KB chunks. All clients are given sufficient credit to download the complete file. In addition, clients always respond to chunk requests from their selected downloaders. The duration of each experiment is 2200sec.

Free-riders never upload encrypted or plaintext content and never expend credit to acquire decryption keys for encrypted chunks they may receive. They rely only on the initial s plaintext chunks of the hybrid incentive mechanism for their downloads. In each experiment we have a group of 10 freeriders and a group of 10 cooperative clients all of which have upload and download rate-limits equal to 256KB/sec. In the rest of this evaluation we call the groups of the 10 freeriders and of the 10 cooperative peers that are rate-limited at

256KB/sec, the free-rider and the reference cooperative group.

The rest of the leechers are upload-rate-limited according to the distribution of Table II, as in Section VI-B. Cooperative clients connect to roughly only 50 peers at a time, while we vary the number of peers that free-riders connect to.

The rest of the client settings (TCP buffer size, number of downloaders, etc) are the same as in Section VI-B.

For each configuration we repeat the experiment 5 times and we extract cumulative distribution functions (CDF), mean values and 95% confidence intervals of client download rates.

If the client is able to complete its download during the experiment (almost always true for cooperative peers), its download rate is equal to the amount of downloaded content

Figure 6.

CDF of the group of 10 free-riders that connect to

∼ 50

peers and the group of 10 free-riders that connect to

∼ 100 peers. Free-

riders in the first and second group have average download rates equal to 14.4KB/sec and 16.5KB/sec, respectively.

1

0.8

0.6

0.4

0.2

0

0

Free-riders - 170 connections

Cooperative - 50 connections

50 100 150

Download Rate (KB/sec)

200

Figure 7. CDF of the group of 10 free-riders that connect to

200 peers

and of the group of 10 reference cooperative peers that connect to

∼ 50

peers. Free-riders in the first group and cooperative peers in the second group have average download rates equal to 19.7KB/sec and 169.6KB/sec, respectively.

For the experiments depicted in Figures 6 and 7, we set the trade surplus threshold s larger than the number of chunks in the file (1000). Under this setting, clients employ the cryptographic fair exchange mechanism only when they are seeders, and employ rate-based tit-for-tat when they are leechers. As can be seen in Figures 6 and 7, the rate with which free-riders download content increases with the number of peers that they connect to (14.4KB/sec, 16.5KB/sec and

19.7KB/sec for free-riders that connect to approximately 50,

100 and 170 peers, respectively). Owing to the limitations of

14

1

0.8

0.6

0.4

50 connections

100 connections

0.2

In this series of experiments, seeders always upload encrypted content and clients in the group of 10 free-riders connect to

∼170 peers. Free-riders do not download from seeders. We vary the trade surplus threshold s. As can be seen in Figure 9, the performance of free-riders degrades as the trade surplus threshold decreases from s

= 1000 to s = 4. If the threshold is too low (e.g. s

= 4), the incentive scheme becomes strict rate-based tit-for-tat; leechers optimistically unchoke the free-riders for a very short period and never unchoke them again, because they kept record of the previous transaction with them.

0

0 50 100 150

Download Rate (KB/sec)

200

25

Figure 8.

CDF of the group of 10 free-riders that connect to

∼ 50 and

of the group of 10 free-riders that connect to

∼ 100 peers, when seeders

upload plaintext chunks to both groups, as is the case with BitTorrent.

Free-riders in the first and second group have average download rates equal to 167.1KB/sec and 179.8KB/sec, respectively.

20

15

10 our experimental testbed, our evaluation examines only the cases in which free-riders are able to connect to at most 170 peers. Although we do not claim that the performance of freeriders increases linearly with the number of connected peers, it is reasonable to assume that a free-rider that joins a very large swarm and connects to many hundreds of peers can achieve substantial download rates.

In Figure 7, we also compare the performance of a group of 10 free-riders with the performance of the reference cooperative group. As can be seen, the download rates of freeriders (19.7KB/sec on average) are a lot lower than the ones of cooperative peers (169.6KB/sec on average). However, as mentioned in Section IV-B2, these relatively low download rates correspond to monetary losses for the content provider and the cooperative peers. To address this problem, Dandelion is able to impose a more restrictive trade surplus threshold at the cost of increasing the frequency with which the server is called upon to mediate fair-exchanges between peers.

Figure 8 depicts the case in which seeders do not employ the cryptographic fair exchange to obtain credit for their service. In this case, Dandelion’s incentives are identical to

BitTorrent’s, and free-riders are able to obtain content from altruistic peers (e.g. BitTorrent seeders). It can be seen that under the bandwidth distribution used in our experiments, freeriders are not penalized even if they do not employ the “large view” exploit. For example, free-riders that connect to

∼50 peers obtain average download rates equal to 167.1KB/sec, which is almost the same with the one achieved by cooperative peers (169.6KB/sec). We conclude that seeders is a significant source of altruism, which can be readily exploited by freeriders. Dandelion’s credit-based incentives fully address this weakness; it enables seeders to increase their utility by behaving selfishly and uploading only encrypted content.

2) Role of Trade Surplus Threshold

5

0

140

120

100

80

60

40

20

0

4 8 16 32 64

Trade Surplus Threshold

1000

Figure 9.

Mean download rates of 10 Dandelion free-rider clients in a swarm of

200 leechers as a function of the trade surplus threshold s.

0

Average

Maximum

4 8 16 32 64

Trade Surplus Threshold

1000

Figure 10.

The average and the maximum decryption key request rate

at the server as a function of the trade surplus threshold s. Request rates

are extracted in 10 sec intervals over the duration of the experiment.

In Figure 10, we observe that the load on the server decreases as s increases. The case for s=0 corresponds to the case in which the

∼190 cooperative clients use the cryptographic fair-exchange mechanism for all chunk exchanges. These results show that under our network configuration, reducing the average download rate of free-riders from 19.7KB/sec

(s=1000) to 11.35KB/sec (s=4) comes at the cost of increasing the server’s average decryption key request load by almost

100% (from 23.6 req/sec to 43.1 req/sec).

We now evaluate the effectiveness of the reduction of trade surplus threshold in mitigating free-riding, and the impact this reduction has on the load of the server.

VII. Related Work

In this section we discuss previous work on incentives for cooperation in peer-to-peer content distribution systems as

15 well as previous work on cryptographic fair exchange.

A. Pairwise Currency as Incentives

In P2P content distribution protocols that employ pairwise virtual currency (credit) as incentives, clients maintain credit balances with each of their peers. In this context, credit refers to any metric of a peer’s cooperativeness.

An eMule [15] client rewards cooperative peers by reducing the time the peers have to wait until they are served by the client. Swift [37] introduces a pairwise credit-based trading mechanism for peer-to-peer file sharing networks and examines the available peer strategies. In [9], the authors suggest tackling free-riding in BitTorrent by employing chunk-level titfor-tat, which is similar to pairwise credit incentives. Keidar et al. [38] present the design of a P2P multicast protocol in which a client tracks the difference between the amount of data the peer has sent to the client so far and the expected per-link throughput. These pairwise credit-based incentive mechanisms bear weaknesses that are similar to the ones of rate-based tit-for-tat: a) they provide no explicit incentives for seeding; and b) they can be manipulated by free-riders that obtain a

“large view” of the network, and initiate short-lived sessions with numerous peers to exploit the initial offers in pairwise transactions.

Scrivener [39] combines pairwise credit balances with a transitive trading mechanism. Its incentive mechanism is based on the premise that a client remains perpetually interested in exchanging the earned pairwise credit for content downloads from the same network. Unlike Scrivener, credit earned by

Dandelion clients can be converted into monetary rewards, providing strong incentives for clients to upload even if the network ceases to offer content that interests the client.

BAR Gossip [27] is suitable for P2P streaming of live content. Owing to its public-key-based cryptographic fair exchange mechanism it is robust to clients that attempt to freeride. However, clients that receive initial optimistic offers from their peers need to expend bandwidth in order to reciprocate with invalid chunk transmissions. Its verifiable peer selection prevents clients from selecting many and particular victim peers to DoS attack. However, its verifiable peer selection technique assumes that no client can join the network after the streaming session starts. Since BAR Gossip is designed for P2P streaming, it does not need to provide incentives for seeding. Therefore, it ensures the fair exchange of content uploads between clients that are interested in the same live broadcast. On the other hand, Dandelion, which needs to incentivize seeding for static content distribution or video on demand, guarantees fair exchange of content uploads for virtual currency.

B. Global Currency as Incentives

It has been widely proposed to use global virtual currency to provide incentives in P2P content distribution systems.

This is the basis of the incentive mechanism employed by

Dandelion: for each client, the system maintains a credit balance, which is used to track the bandwidth that the client has contributed to the network.

Karma [40] employs a global credit bank and certified-mailbased [41] fair exchange of content for reception proofs. It distributes credit management among multiple nodes. Karma’s distributed credit management improves scalability. However, it does not guarantee the integrity of the global currency when the majority of the nodes that comprise the distributed credit bank are malicious or in a highly dynamic network. Furthermore, Karma relies on a secure DHT to ensure that credit queries are resolved by appropriate nodes. In contrast, Dandelion’s centrally maintained global currency is non-manipulable by clients, enabling a content provider to incentivize client cooperation by offering monetary rewards.

Horne et al. [42] proposed an encryption- and erasurecode-based fair exchange scheme for exchange of content for proofs of service, but did not provide an experimental evaluation. Their scheme detects cheating with probabilistic guarantees, whereas Dandelion deterministically detects and punishes cheaters.

Li et al. [43] proposed a scheme for incentives in P2P environments that uses fair exchange of proof of service with chunks of content. The selfish client encrypts a chunk and sends it to its peer, the peer responds with a public-key cryptographic proof of service, and the client completes the transaction by sending the decryption key. A trusted third party (TTP) is involved only in the following cases: a) the selfish client presents the proofs of service to obtain credit; b) the peer complains for receiving an invalid chunk; and c) the peer complains for not receiving the decryption key from the selfish client. However, unless the server incurs the high cost of frequently renewing the public key certificates of each client, the credit system is vulnerable to clients that obtain content from selfish peers, despite those clients not having sufficient credit. In contrast, in Dandelion, the TTP mediates every cryptographic fair exchange of chunk uploads for credit, effectively preventing a client from obtaining any chunks from selfish peers without having sufficient credit.

PPay [44] and WhoPay [45] are recent micropayment proposals that employ public key cryptography and are designed for the P2P content distribution case. MojoNation [46] used a combination of pairwise balances and tokens that can be cashed in a central broker. When the debt during pairwise transactions exceeds a specified threshold, the side with the negative balance transfers a credit token to the other by contacting a broker. A very recent BitTorrent extension

[47] exchanges cryptographically signed proofs of service for content uploads. The above schemes do not guarantee fair exchange of content for payment. Free-riders may establish short-lived sessions to many peers, and download small portions of content or obtain payments from without paying or uploading. In addition, free-riders may send to the uploaders proofs of payment that do not reflect real credit value. As a result, free-riders may acquire substantial amount of content without uploading or paying credit, respectively. In addition, free-riders may send payments that do not reflect real credit value, also known as double-spending. WhoPay employs a decentralized double-spending detection mechanism that is based on a distributed DHT-based database, but this mechanism is vulnerable to peer collusions, and attacks on

16

DHT routing.

Similar to Kazaa, Maze [48] users are rewarded with points for uploading, and expend points for successful downloads.

Users that obtain more points than a specified threshold are assigned high bandwidth quotas. However, the system relies on users faithfully reporting the amount of content they download and upload and it does not provide strong identities. Thus, as reported in [48], it is vulnerable to misuses such as Sybil attacks, peer collisions. It is also vulnerable to source code modifications similar to the ones experienced in Kazaa [17],

C. Reputation Mechanisms

Reputation mechanisms, e.g. [49–51], may allow seeders to rank their leechers based on the rate with which the leechers upload to their peers. By employing these mechanisms, the system can in theory prevent free-riders from downloading from seeders. As proposed in [52], the peers of leechers would report to the seeders, with which the leechers are connected, information about the rates with which the leechers uploads to their peers, and the reputation mechanism would be used to rank the truthfulness of the peer reports and the cooperativeness of the leechers. However, reputation systems are vulnerable to the Sybil attack [23] and collisions, especially in swarms with small populations, and in the best case offer probabilistic guarantees of reputation correctness.

Furthermore, reputation-based incentive mechanisms offer coarse-grained evaluation of a peer’s level of cooperation, thus they are unsuitable for schemes that employ monetary rewards.

D. Double-spending Prevention

Osipkov et al. [53] propose a scheme to prevent doublespending in a micropayment-based market, under which clients purchase service from web servers. The following issues set obstacles in deploying their solution in the P2P content distribution setting. First, it requires a relatively static set of entities (e.g. peers) that act as witnesses/trackers of coin transactions, thus it is not suitable for a highly dynamic P2P environment. Second, this solution addresses witnesses that wronfully claim that a coin has been double-spent, but in our setting this is not a compelling problem. We are mostly concerned with witnesses that collude with peers by lying that a coin has not been double-spent. Their solution assumes that witnesses don’t have incentives to collude with clients under their web-server/client setting, but this assumption does not hold under our setting. Last, their scheme employs complex cryptography, making its correct implementation a difficult task.

E. Cryptographic Fair-Exchange

There are two main classes of solutions for the classic cryptographic fair exchange problem. One uses simultaneous exchange by interleaving the sending of the message with the sending of the receipt [54–58]. These protocols rely on the assumption of equal computational and bandwidth capacity, which does not suit the heterogeneous P2P setting.

The other class relies on the use of a trusted [59–62] or semi-trusted [63, 64] third party (TTP). The main differences of our scheme are as follows: 1) In the optimistic fair exchange schemes proposed in [59–61] the TTP is involved only when a party misbehaves and does not complete the transaction.

However, the TTP cannot decide which party has misbehaved, but can only complete the transaction itself, if presented with proof that the parties initially intended to perform the transaction. They assume that the cost of sending the data is small and can be repeated by the TTP. However in Dandelion, transmission of data is the most expensive resource and our scheme aims at the fair exchange of this resource; 2) Unlike

[63] and [64], our scheme does not rely on untrusted clients to become semi-TTP; 3) Unlike [62], our scheme does not use public key cryptography for encryption and for committing to messages, and only requires one client rather than two to contact the TTP for each transaction. The technique they use to determine whether a message originates from a party is similar to the one used by our complaint mechanism, but our work also addresses the specifics of determining the validity of the message.

VIII. Conclusion

This paper describes Dandelion: an incentive system for cooperative (P2P) distribution of paid content. Its primary function is to enable a content provider to motivate its clients to contribute their uplink bandwidth.

Dandelion rewards cooperative clients with virtual currency

(credit) or with reciprocal uploads from their peers. Since it employs a non-manipulable cryptographic scheme for the fair exchange of content uploads for credit, the content provider is able to redeem a client’s credit for monetary rewards.

Thus, our system provides strong incentives for clients to seed content and to not free-ride.

Our experimental results show that a Dandelion server running on commodity hardware and with moderate bandwidth can scale to a few thousand clients. Dandelion’s deployment in medium size swarms demonstrates that seeding substantially improves swarm-wide performance and that a Dandelionbased content distribution system can attain performance comparable to BitTorrent. It also shows that our system penalizes free-riders. These facts illustrate the plausibility of our design choice: centralizing the incentive mechanism in order to increase resource availability in P2P content distribution.

Acknowledgments

We are thankful to Nikitas Liogkas, Eddie Kohler and the anonymous USENIX reviewers for their fruitful feedback on this work. We also thank Jong Han Park, Rex Chen, Denh Sy and Lichun Bao with Calit2 for providing assistance, space and equipment for our experiments. This work was supported in part by NSF award CNS-0627166.

References

[1] “iTunes Store Tops Three Billion Songs,” http://www.apple.com/au/ hotnews/, July 2007.

[2] “Netflix Offers Subscribers the Option of Instantly Watching Movies on their PCs,” www.netflix.com/MediaCenter?id=5384, Jan 2007.

[3] “Music denied - Shoppers overwhelm iTunes,” edition.cnn.com/

2006/TECH/internet/12/28/itunes.slowdown.ap/index.html?eref=rss topstories, 2006.

17

[4] B. Cohen, “Incentives Build Robustness in BitTorrent,” in P2P Econ,

2003.

[5] C. Huang, J. Li, and K. W. Ross, “Can Internet Video-on-Demand Be

Profitable?” in SIGCOMM, 2007.

[6] “BitTorrent, Inc launches the BitTorrent entertainment network,” www.bittorrent.com/about/press/bittorrent-inc-launches-the-bittorrententertainment-network, Feb 2007.

[7] D. Hughes, G. Coulson, and J. Walkerdine, “Free Riding on Gnutella

Revisited: The Bell Tolls?” in IEEE Distributed Systems Online, 2005.

[8] J. Shneidman, D. Parkes, and L. Massoulie, “Faithfulness in Internet

Algorithms,” in PINS, 2004.

[9] S. Jun and M. Ahamad, “Incentives in BitTorrent Induce Free Riding,” in P2P Econ, 2005.

[10] N. Liogkas, R. Nelson, E. Kohler, and L. Zhang, “Exploiting BitTorrent

For Fun (But Not Profit),” in IPTPS, 2006.

[11] M. Sirivianos, J. H. Park, R. Chen, and X. Yang, “Free-riding in

BitTorrent Networks with the Large View Exploit,” in IPTPS, 2006.

[12] T. Locher, P. Moor, S. Schmid, and R. Wattenhofer, “Free Riding in

BitTorrent is Cheap,” in HotNets, November 2006.

[13] M. Sirivianos, J. H. P. X. Yang, and S. Jarecki, “Dandelion: Cooperative

Content Distribution with Robust Incentives,” in USENIX, 2007.

[14] B. Chun, D. Culler, T. Roscoe, A. Bavier, L. Peterson, M. Wawrzoniak, and M. Bowman, “PlanetLab: an Overlay Testbed for Broad-coverage

Services,” in SIGCOMM CCR, 2003.

[15] “The eMule Project,” www.emule-project.net.

[16] N. Andrade, M. Mowbray, A. Lima, G. Wagner, and M. Ripeanu,

“Influences on Cooperation in Bittorrent Communities,” in P2P Econ,

2005.

[17] “Kazaa Lite,” en.wikipedia.org/wiki/Kazaa Lite.

[18] 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 ICDCS, 2007.

[19] B. Fan, D.-M. Chiu, and J. C. Lui, “The Delicate Tradeoffs in BitTorrentlike File Sharing Protocol Design,” in ICNP, 2006.

[20] “Peer exchange,” www.azureuswiki.com/index.php/Peer Exchange.

[21] “Trackerless BitTorrent,” www.bittorrent.com/trackerless.html.

[22] M. Zghaibeh and K. G. Anagnostakis, “On the impact of p2p incentive mechanisms on user behavior,” in NetEcon+IBC, 2007.

[23] J. R. Douceur, “The Sybil Attack,” in IPTPS, 2002.

[24] M. Bellare, R. Canetti, and H. Krawczyk, “Keying Hash Functions for

Message Authentication,” in LNCS, vol. 1109, 1996.

[25] http://www.ietf.org/rfc/rfc4346.txt.

[26] M. Sirivianos, X. Yang, and S. Jarecki, “Robust and Efficient Incentives for Cooperative Content Distribution,” UCI, Tech. Rep., 2006, uCI-ICS

TR 07-10. [Online]. Available: www.ics.uci.edu/

∼ msirivia/publications/ dandelion-ton-submission-tr.pdf

[27] H. Li, A. Clement, E. Wong, J. Napper, I. Roy, L. Alvisi, and M. Dahlin,

“BAR Gossip,” in OSDI, 2006.

[28] B. Cheng, X. Liu, Z. Zhang, and H. Jin, “A measurement study of a peer-to-peer video-on-demand system,” in IPTPS, 2007.

[29] M. Feldman, C. Papadimitriou, J. Chuang, and I. Stoica, “Free-Riding and Whitewashing in Peer-to-Peer Systems,” in IEEE JSAC, May 2006.

[30] A. Legout, N. Liogkas, E. Kohler, and L. Zhang, “Clustering and Sharing

Incentives in BitTorrent Systems,” 2007.

[31] A. Gai, F. Mathieu, J. Reynier, and F. Montgolfier, “Clustering and

Sharing Incentives in BitTorrent Systems,” 2007.

[32] A. Bharambe, C. Herley, and V. Padmanabhan, “Understanding and

Deconstructing BitTorrent Performance,” in SIGMETRICS, 2005.

[33] B. Bollobas, “Random Graphs,” in Academic Press, 1985.

[34] D. Kostic, A. Rodriguez, J. Albrecht, and A. Vahdat, “Maintaining High

Bandwidth Under Dynamic Network Conditions,” in USENIX, 2005.

[35] M. Piatek, T. Isdal, T. Anderson, A. Krishnamurthy, and A. Venkataramani, “Do Incentives Build Robustness in BitTorrent?” in NSDI, 2006.

[36] “Enchanced CTorrent,” www.rahul.net/dholmes/ctorrent.

[37] K. Tamilmani, V. Pai, and A. Mohr, “SWIFT: A System with Incentives for Trading,” in P2P Econ, 2004.

[38] I. Keidar, R. Melamed, and A. Orda, “EquiCast: Scalable Multicast with

Selfish Users,” in PODC, 2006.

[39] P. Druschel, A. Nandi, T.-W. J. Ngan, A. Singh, and D. Wallach,

“Scrivener: Providing Incentives in Cooperative Content Distribution

Systems,” in Middleware, 2005.

[40] V. Vishnumurthy, S. Chandrakumar, and E. G. Sirer, “KARMA: A

Secure Economic Framework for P2P Resource Sharing,” in P2P Econ,

2003.

[41] B. Schneier, Applied Cryptography, 2nd edition, 1995.

[42] B. Horne, B. Pinkas, and T. Sander, “Escrow Services and Incentives in

Peer-to-peer networks,” in EC, 2001.

[43] J. Li and X. Kang, “Proof of Service in a Hybrid P2P Environment,” in

ISPA Workshops, 2005.

[44] B. Yang and H. Garcia-Molina, “PPay: Micropayments for Peer-to-peer

Systems,” in CCS, 2003.

[45] K. Wei, Y.-F. Chen, A. J. Smith, and B. Vo, “WhoPay: a Scalable and

Anonymous Payment System for Peer-to-Peer Environments,” in ICDCS,

2006.

[46] “The MNet Project,” mnetproject.org.

[47] “The Snowball Traceability Protocol,” http://developer.

snowballnetworks.com/trac.

[48] M. Yang, H. Chen, B. Y. Zhao, Y. Dai, , and Z. Zhang, “Deployment of a Large-scale Peer-to-Peer Social Network,” in WORLDS, 2004.

[49] S. D. Kamvar, M. T. Schlosser, and H. Garcia-Molina, “The eigentrust algorithm for reputation management in p2p networks,” in WWW, 2003.

[50] A. Blanc, Y.-K. Liu, and A. Vahdat, “Designing Incentives for Peer-to-

Peer Routing,” in INFOCOM, 2004.

[51] Q. Lian, P. Yu, M. Yang, Z. Zhang, Y. Dai, and X. Li, “Robust incentives via multi-level tit-for-tat,” in IPTPS, 2006.

[52] M. Li, J. Lu, and J. Wu, “Free-riding on bittorrent-like peer-to-peer file sharing systems: Modeling analysis and improvement,” in TPDS, 2007.

[53] I. Osipkov, E. Y. Vasserman, N. Hopper, and Y. Kim, “Combating double-spending using cooperative p2p systems,” in ICDCS, 2007.

[54] E. F. Brickell, D. Chaum, I. Damg, and J. V. de Graaf, “Gradual and

Verifiable Release of a Secret,” in CRYPTO, 1988.

[55] R. Cleve, “Controlled Gradual Disclosure schemes for Random bits and their Applications,” in CRYPTO, 1989.

[56] I. B. Damg, “Practical and Provably Secure Release of a Secret and

Exchange of Signatures,” in EUROCRYPT, 1994.

[57] T. Okamoto and K. Ohta, “How to Simultaneously Exchange Secrets by

General Assumptions,” in CCS, 1994.

[58] S. Even, O. Goldreich, and A. Lempel, “A Randomized Protocol for

Signing Contracts,” in Communications of the ACM, vol. 28, no. 6,

1985.

[59] N. Asokan, M. Schunter, and M. Waidner, “Optimistic Protocols for Fair

Exchange,” in CCS, 1997.

[60] J. Zhou and D. Gollmann, “An Efficient Non-repudiation Protocol,” in

CSFW, 1996.

[61] F. Bao, R. Deng, and W. Mao, “Efficient and Practical Fair Exchange

Protocols with Off-line TTP,” in S&P, 1998.

[62] J. Zhou and D. Gollmann, “A Fair Non-repudiation Protocol,” in S&P,

1996.

[63] K. Franklin and M. K. Reiter, “Fair exchange with a semi-trusted third party,” in CCS, 1997.

[64] M. K. Franklin and G. Tsudik, “Secure Group Barter: Multi-party Fair

Exchange with Semi-Trusted Neutral Parties,” in Financial Cryptogra-

phy, 1998.

Michael Sirivianos is a Ph.D. candidate in Computer Science at the University of California, Irvine.

His research interests include cooperative content distribution, network security and human verifiable secure device pairing. He received a B.S in Electrical and Computer Engineering from the National Technical University of Athens in 2002, and an M.S. in

Computer Science from the University of California,

San Diego in 2004.

Xiaowei Yang is an assistant professor of Computer

Science at the University of California, Irvine. Her research interests include congestion control, quality of service, Internet routing architecture, and network security. She received a B.E. in Electronic Engineering from Tsinghua University in 1996, and a Ph.D.

in Computer Science from MIT in 2004.

Stanislaw Jarecki is an Assistant Professor of

Computer Science and Engineering at the University of California, Irvine. His research interests are cryptography, security, and distributed algorithms.

He received a B.S. in Computer Science from MIT in 1996, and a Ph.D. in computer science from MIT in 2001.

Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement