Free-riding in BitTorrent Networks with the Large View Exploit Michael Sirivianos, Jong Han Park,...

Free-riding in BitTorrent Networks with the Large View

Exploit

Michael SirivianosMichael Sirivianos, Jong Han Park, Rex Chen and , Jong Han Park, Rex Chen and

Xiaowei YangXiaowei Yang

University of California, IrvineUniversity of California, Irvine

Feb 26, 2007 @ IPTPSFeb 26, 2007 @ IPTPS

Why free-ride in BitTorrent?

Very successful P2P content distribution system

Built-in incentives for clients to upload positively correlates a client’s download and upload

rates

BitTorrent users may still choose to free-ride

If they can download as fast as protocol compliant clients

Slow uplink, quota on outgoing traffic, less risk of legal action

Internet

Can’t even browse!

Upload at 10KB/sec1.5Mbps/ 128Kbps

ADSL

Our contributions

Free-ride while maintaining high download rates

Identify an effective free-riding exploit for BitTorrent

Implement exploit in Enhanced CTorrent

Experimental evaluation Public swarms ~300-leecher PlanetLab swarms

Outline

Motivation and contribution

BitTorrent overview

The exploit

Experimental evaluation

Related work

Conclusion and Future work

BitTorrent overview

File is divided into chunks (e.g. 256KB) Seeders have all chunks of the file Leechers have some or no chunks of the file

Leecher A

Leecher B

Leecher CSeeder

Tracker1 2 3

BitTorrent overview

Clients (seeders or leechers) contact the tracker Tracker has complete view of the swarm

Leecher A

Leecher B

Leecher CSeeder

Tracker

ViewSeeder

Leecher A

Leecher B

Leecher C

BitTorrent overview

Leecher A

Leecher B

Leecher CSeeder

Tracker

Partial View

Seeder

Leecher B

ViewSeeder

Leecher A

Leecher B

Leecher C

Tracker sends partial view to clients Clients connect to peers in their partial view

BitTorrent overview

Every 10 sec, seeders sample their peers’ download rates Seeders unchoke 4-10 interested fastest downloaders

Leecher A

Leecher B

Seeder

Tracker

Leecher C

1 2 3

BitTorrent overview

Clients announce available chunks to their peers Leechers request chunks from their peers (locally rarest-first)

Leecher A

Leecher B

Seeder

Tracker

1

2

Leecher C

3

BitTorrent overview

Leecher A

Leecher B

Seeder

Tracker

1

Leecher C

Rate-based tit-for-tat

Every 30 sec, leechers optimistically unchokes 1-2 peers

BitTorrent overview

Leecher A

Leecher B

Seeder

Tracker

1

Leecher C


Every 30 sec, leechers optimistically unchoke 1-2 peers

Every 10 sec, leechers sample their peers’ upload rates

BitTorrent overview

Leecher A

Leecher B

Seeder

Tracker

3 2

Leecher C


Every 30 sec, client optimistically unchokes 1-2 peers

Every 10 sec, seeder samples its peers’ upload rates

Leecher unchokes 4-10 fastest interested uploaders

Outline


BitTorrent overview

The exploit


Related work

Conclusion and future work

Large view exploit

Observations Seeders do not consider whether leechers upload

to others

Optimistic unchoking is generous (10 sec)

Modify client to exploit altruism Connect from and disconnect to tracker every 15

sec

Repeatedly request and obtain a partial view

Connect to all clients in the combined large view

It is more likely to connect to seeders

It is more likely to be optimistically unchoked by leechers

Outline


BitTorrent overview

The exploit


Related work



Evaluation goals: Determine effectiveness of the large view exploit

Determine behavior of swarms as % free-riders increases

Performance metric

File download completion time

Free-riding in public swarms

Methodology CTorrent free-rider and compliant (unmodified)

leecher

Compliant leecher connects to at most 50 peers

Leechers download ~500MB-2GB files in ~50-650 client swarms

Leechers run on two identical machines and in the same LAN

Neither leecher is rate-limited

Leechers simultaneously join the swarm


In 12/15 swarms, free-rider does better than compliant client

Swarm

#seeders

#leechers

13 9 64

14 91 392


Swarm

#seeders

#leechers

13 9 64

14 91 392

In 12/15 swarms, free-rider does better than compliant client

Methodology BNBT Easy tracker, and CTorrent clients

Clients download a 12MB file

~300 leechers rate-limited at 30KB/sec

1 initial seeder rate-limited at 120KB/sec

Leechers remain online after download completion

Compliant leechers connect to at most 50 peers

Results collected over 10 runs

Free-riding in PlanetLab-residing swarms


Experiment 1: 100% compliant clients


Experiment 1: 100% compliant clients Experiment 2: 10% free-riders that connect to 50 peers only


Experiment 1: 100% compliant clients Experiment 2: 10% free-riders that connect to 50 peers only 10% free-riders do much worse than 90% compliant


Experiment 1: 100% compliant clients


Experiment 1: 100% compliant clients Experiment 2: 10% free-riders that employ large view exploit


Experiment 1: 100% compliant clients Experiment 2: 10% free-riders that employ large view exploit 10% free-riders do slightly better than 90% compliant


Experiment 1: 100% compliant clients Experiment 2: 10% free-riders that employ large view exploit 10% free-riders do slightly better than 90% compliant 10% free-riders do slightly worse than 100% compliant

60% free-riders do worse than 40% compliant


60% free-riders do worse than 40% compliant 60% free-riders do much worse than 100% compliant


60% free-riders do worse than 40% compliant 60% free-riders do much worse than 100% compliant Free-riders are compelled to start uploading


Outline


BitTorrent overview

The exploit


Related work


Related Work

BitThief (HotNets ‘06) Large view is central technique

Random chunk scheduling instead of locally rarest-first

We evaluate exploit in medium scale PlanetLab swarms

BitTyrant (NSDI ‘07) Connects to many peers too

Does not free-ride

Strategically selects per peer upload rates

Outline


BitTorrent overview

The exploit


Related work


Conclusion

The large view exploit is effective A free-rider can achieve better or slightly worse download rates

than protocol compliant clients

Selfish (rational) users may opt to free-ride

Good download rates without utilizing uplink

However, bad download rates when many free-riders in swarm

Future work – Is the exploit dangerous?

Can the exploit lead to ``tragedy of the commons” ?

Until free-riders realize they obtain bad download rates

What if cooperative clients employ large view too?

Not as altruistic (?) Clients discover fastest peers and neglect slow ones

Higher chunk announcement message overhead More informed rarest-first chunk scheduling All clients get optimistically unchoked equally as often

Thank You!

Technical report, source code and testbed scripts available at: www.ics.uci.edu/~msirivia/large-view

Questions?Questions?

Why free-ride?

4 users sharing very slow uplink

1.5Mbps/128KbpsADSL

Can’t even browse!Upload at 10KB/sec

Other reasons to not upload Access provider imposes quotas on outgoing traffic

Reduce risk of legal action for unauthorized content distr.

Why free-ride?

Depends on user’s utility function Goal may not be to maximize download rate

Goal may be to achieve a certain download rate,

while minimizing uplink utilization

Utility Download rate

Upload rate

0

Download rate of compliant clients

Diminishing returns

Download rate

Utility

Bad browsing experience

Future work - Address the exploit

View-limiting Tracker registers each client’s partial view

Client is identified by IP

Client has only N active peers in registered view

But, view can be obtained from peers too Peer Exchange, Trackerless BitTorrent

Connection verification Client A accepts connection from B

A queries tracker whether B has A in its registered view

If B does not have A in its registered view, A disconnects from B

Public Torrent Composition

Why free-ride?

Utility Download rate

Upload rate

0

Download rate of compliant clients

Diminishing returns

Download rate

Utility

Bad browsing experience

Can whitewashing help free-riders?

CTorrent favors for optimistic unchoking Leechers with no chunks

Leechers that have not been recently unchoked

Official BitTorrent selects leechers at random

Azureus favors leechers with less byte trade deficit

CTorrent modification to whitewash leechers

Disconnect from and reconnect to leecher after being choked

Suppress chunk announcements

5% free-riders that don’t whitewash do almost as good as

5% free-riders that whitewash

Whitewashing does not help free-riders



5% free-riders that whitewash



5% free-riders that whitewash CTorrent’s optimistic unchoking selection is more random

than intended

Whitewashing does not speed up downloading

10% free-riders still do slightly better than 90% compliant 1% free-riders that whitewash complete in ~650 sec 1% free-riders that don’t whitewash complete in ~640 sec

CTorrent Unchoking

Every 10 secs gets the fastest n downloaders. It unchokes them, while it chokes all others, the non-interested and the slowest.

Every 30 secs, it selects the n-1 fastest downloaders and one peer that is not the fastest. It checks each interested peer one by one. The slowest uploader among the so far collected n-1 fastest peers and the new peer is replaced with the so far selected to be optimistically unchoked as follows:

If slowest has no data, slowest is selected to be opt unchoked with 75% prob and the so far selected to be opt unchoked peer is selected with 25%. Otherwise, if slowest is choked and so far opt unchoked client is not, or if both are choked but slowest waited longer, or if both are unchoked but slowest had less time unchoked, slowest is selected as follows: slowest is selected if it has no data, or if so far opt unchoked has data, or with 25% prob. If none of the above applies the so far opt unchoked remains unchoked.

Whitewashing harms performance in general because it interferes with clustering of compliant peers. But it does not improve performance for FRs.

BitTorrent View Re-request Official BT client by default allows 80 connections. The BT code says that if the client accepts incoming connections it only requests view aggressively if clients are less than minpeers/3.

if self.last_time > bttime() - self.config['rerequest_interval']:

return

if self.ever_got_incoming():

getmore = self.howmany() <= self.config['min_peers'] / 3

else:

getmore = self.howmany() < self.config['min_peers']

if getmore or bttime() - self.last_time > self.announce_interval:

self._announce()

by default, minimum 300 sec between requesting view, rerequest_interval = 300 sec, self.announce_interval = 3600

BitTorrent modelled as IPD

Tit-for-Tat Cooperate at first round

Do what the other player did in previous round

Tit-for-Tat is winning strategy When players do not know number of rounds

Tit-for-Tat not the best strategy When players know how many rounds will play

Can play with many players

Best strategy may be to defect after first round

Obtain large portion of content without cooperating

GET RID OF IT?

Free-riding in BitTorrent Networks with the Large View Exploit Michael Sirivianos, Jong Han Park,...

Documents

Transcript of Free-riding in BitTorrent Networks with the Large View Exploit Michael Sirivianos, Jong Han Park,...