Free-riding in BitTorrent Networks with the Large View Exploit Michael Sirivianos, Jong Han Park, Rex Chen and Xiaowei Yang University of California, Irvine Feb 26, IPTPS Feb 26, 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

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

BitTorrent overview  Clients (seeders or leechers) contact the tracker  Tracker has complete view of the swarmViewSeeder Leecher A Leecher B Leecher C

BitTorrent overview 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

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

BitTorrent overview  Rate-based tit-for-tat Every 30 sec, leechers optimistically unchokes 1-2 peers

BitTorrent overview  Rate-based tit-for-tat Every 30 sec, leechers optimistically unchoke 1-2 peers Every 10 sec, leechers sample their peers’ upload rates

BitTorrent overview  Rate-based tit-for-tat 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  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  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  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  Related work  Conclusion and future work

Experimental evaluation  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 ~ client swarms Leechers run on two identical machines and in the same LAN Neither leecher is rate-limited Leechers simultaneously join the swarm

Free-riding in public swarms  In 12/15 swarms, free-rider does better than compliant client Swarm#seeders#leechers

Free-riding in public swarms Swarm#seeders#leechers  In 12/15 swarms, free-rider does better than compliant client

Free-riding in public swarms Swarm#seeders#leechers  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

Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that connect to 50 peers only

Free-riding in PlanetLab-residing swarms  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

Free-riding in PlanetLab-residing swarms  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

Free-riding in PlanetLab-residing swarms

 Experiment 1: 100% compliant clients

Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that employ large view exploit

Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that employ large view exploit  10% free-riders do slightly better than 90% compliant

Free-riding in PlanetLab-residing swarms  Experiment 1: 100% compliant clients  Experiment 2: 10% free-riders that employ large view exploit  10% free-riders do slightly better than 90% compliant

Free-riding in PlanetLab-residing swarms  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

Free-riding in PlanetLab-residing swarms  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

Free-riding in PlanetLab-residing swarms

 60% free-riders do worse than 40% compliant Free-riding in PlanetLab-residing swarms

 60% free-riders do worse than 40% compliant Free-riding in PlanetLab-residing swarms

 60% free-riders do worse than 40% compliant  60% free-riders do much worse than 100% compliant Free-riding in PlanetLab-residing swarms

 60% free-riders do worse than 40% compliant  60% free-riders do much worse than 100% compliant Free-riding in PlanetLab-residing swarms

 60% free-riders do worse than 40% compliant  60% free-riders do much worse than 100% compliant  Free-riders are compelled to start uploading Free-riding in PlanetLab-residing swarms

Outline  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  Related work  Conclusion and future 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  Motivation and contribution  BitTorrent overview  The exploit  Experimental evaluation  Related work  Conclusion and future 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: Questions?

Why free-ride? 4 users sharing very slow uplink  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

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?

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 don’t whitewash do almost as good as 5% free-riders that whitewash

Whitewashing does not help free-riders  5% free-riders that don’t whitewash do almost as good as 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?