Incentives Build Robustness in BitTorrent Bram Cohen

Motivation Scalability issues for client/server systems –Server’s workload grows linearly with number of clients –Flash crowd problem Single server

An “Ideal” Solution: IP Multicast Same stream is shared by all clients receiving same data Requires infrastructure-level changes –Security issues No widely accepted transport protocol on IP multicast layer Single server

Current Approaches Server farms replace central server –Scalability problem continues –Expensive to maintain Content delivery networks (CDNs) –Akamai, … –Still expensive Peer-to-peer systems (P2P) –Newer approach

P2P Systems (I) Let clients, now called peers, share the server workload –Peers forward all the data they receive to other peers

P2P Systems (II)

Advantages P2P solutions are – Scalable: Downloading bandwidth grows with number of peers – Easy to deploy: No additional hardware No change to network infrastructure – Cheap

Issues Organizing data transfers: –Figuring which peers have which chunks of data –Deciding where to send these chunks Dealing with churning: –Peers come and go Enforcing fairness: –Some peers do not upload as many data as they download

BitTorrent Unstructured P2P System –Peers have no parent peers or child peers C entralized tracker –Collects information on peers –Responds to requests for that information Built-in fairness incentive – Rechoking favors cooperative peers Simple user interface

Importance

Deployment (I) Decision to use BitTorrent is made by publisher of file Users join BitTorrent to get a file they want –Most users stops uploading once they have downloaded the file –Standard implementation keeps uploading until the BT window closes

Deployment (II) In a typical deployment –Number of downloaders having parts of the file ( leeches ) increases very fast then peaks at a maximum before decreasing exponentially –Number of downloaders having the whole file ( seeds ) increases more slowly then peaks at a maximum before decreasing exponentially

Evolution

Starting a BT (I) To start a BT, publisher puts on a web server a static file with information about –The file –Its length –Its name, –Hashing information –The URL of a tracker

The tracker Helps downloaders find each other Uses a simple protocol layered on top of HTTP –New downloader sends information about What file it’s downloading What port it’s listening on … –Tracker replies with a list of peers that are downloading the same file

Starting a BT (II) Next step is starting a downloader having the whole contents of the file –The seed Web server and tracker have very low bandwidth requirements Seed must upload at least once whole file contents

Connecting with peers Standard tracker algorithm returns random lists of peers –Random graphs are very robust BitTorrent cuts files into pieces of fixed size, typically a quarter megabyte Each downloader –Reports to its peers what pieces it has –Starts exchanging these pieces with them

Ensuring data integrity Torrent file on web server has SHA1 hashes of all the pieces Peers don’t report that they have a piece until they’ve checked its hash – Could have used erasure codes

Pipelining Must avoid delays between pieces being sent –BT breaks pieces further into sub-pieces (typically 16KB in size) –Always keeps several requests pipelined at once –Sends a new request each time a sub-piece arrives

Piece Selection (I) Downloaders requesting pieces follow four policies – Strict Priority Finish first downloading pieces of which downloader has one or more sub-pieces Gets complete pieces as quickly as possible

Piece Selection (II) – Rarest First Download first the pieces that the fewest of their own peers have Ensures that peers have the pieces that most of their peers want

Piece Selection (III) – Random First Piece New peer should get its first complete piece as quickly as possible Rare pieces can be downloaded from fewer peers than other pieces New peer will select first pieces to download at random until it has obtained a complete piece

Piece Selection (IV) – Endgame Mode At end of download –Peer will send to all other peers requests for sub-pieces it doesn’t have yet from all other –Will send cancels for all sub-pieces which arrive Objective is to speed up end of download

Overview Torrent fileTracker Two nodes and their peers A seed Downloaders

BT Choking Algorithm Penalizes peers that do not reciprocate – Tit-for-tat policy Every ten seconds, each peer selects four less cooperating peers it will choke –Will refuse to upload data to these peers for ten seconds –Long enough for TCP to reach full capacity with the new transfers

Optimistic Unchoking At all times, each BT peer has single ‘optimistic unchoke’, –Unchoked regardless of its current upload –Rotated every third rechoke period (30 seconds) –“ Correspond very strongly to always cooperating on the first move in prisoner’s dilemma.”

Upload only mode A peer that has the whole content of the file it wanted to download starts privileging peers that use best its upload bandwidth

Anti-snubbing A peer might be sometimes choked by all peers from which it was downloading “ To mitigate this problem, when over a minute goes by without getting a single piece from a particular peer, BitTorrent assumes it is ’snubbed’ by that peer and doesn’t upload to it except as an optimistic unchoke ”

Actual deployments BT routinely serves –Files hundreds of megabytes in size –To hundreds of simultaneous downloaders Can have over a thousand concurrent downloaders. Sole scaling bottleneck appears to be the bandwidth overhead of the tracker –One thousandth of total traffic