Incentives Build Robustness in Bit Torrent Bram Cohen

Incentives Build Robustness in Bit. Torrent Bram Cohen

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

An “Ideal” Solution: IP Multicast Single server • 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

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

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

P 2 P Systems (II)

Advantages • P 2 P 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

Bit. Torrent • Unstructured P 2 P System – Peers have no parent peers or child peers • Centralized tracker – Collects information on peers – Responds to requests for that information • Built-in fairness incentive – Rechoking favors cooperative peers

Importance

Deployment (I) • Decision to use Bit. Torrent is made by publisher of file • Users join Bit. Torrent 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

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 • Bit. Torrent 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 SHA 1 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 subpieces (typically 16 KB 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 subpieces which arrive • Objective is to speed up end of download

Overview Torrent file Download ers A seed Tracker Two nodes and their peers

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, Bit. Torrent 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