Slide 1

Unstructured P2P Networks Achieving Robustness and Scalability in Data Dissemination Scenarios Michael Mirold Seminar on Advanced Topics in Distributed Computing 2007/2008 Slide 2 2 Introduction Structured P2P Node graph with predefined structure Examples Chord Pastry CAN Unstructured P2P Random node graph Examples Gnutella BitTorrent Slide 3 3 Part I Do Ut Des, Tit-for-Tat or How Leech Proof is BitTorrent Really? Bases on papers: Incentives Build Robustness in BitTorrent, Bram Cohen Do Incentives Build Robustness in BitTorrent?, Michael Piatek, Tomas Isdal, Thomas Anderson, Arvind Krishnamurthy, Arun Venkataramani Slide 4 4 What is BitTorrent? Used for distribution of single files File is split into pieces (32kB 2MB) Pieces are distributed within a swarm denotes all nodes that are interested in the file Downloaded pieces are redistributed No single server: True peer-to-peer (except perhaps of tracker) Slide 5 5 How Does BitTorrent Work? (1) Want really badly to make everyone enjoy my new holiday pictures (HDR some GB) 1.2 Put Torrent-File onto web server Initial Seed Tracker Ordinary Web Server 1.3 Register as downloader 1.1 Create Torrent-File Torrent File - url of tracker - name: name of file - piece length - pieces (conc. of SHA1 hashes of all pieces) - file length Slide 6 6 How Does BitTorrent Work? (2) Initial Seed Tracker 2.1 Request Torrent-File Ordinary Web Server 2.3 Send peer set (Local Neighborhood) 2.2 Register as downloader 2.4 Open connection 2.7 Send pieces 2.5 Handshake 2.6 Request Slide 7 7 B choke At some Unspecial Moment seed swarm non-seed our node active set peer set active set statically sized Slide 8 8 BitTorrent in Action Slide 9 9 Achieving Fairness in BitTorrent Basis: Tit-for-Tat strategy Famous in game theory (considered best strategy for winning Prisoners Dilemma) Idea: Be cooperative to others Penalize defective behaviour but dont be too unforgiving Put in BitTorrent context Grant upload capacity to n best uploaders n: size of active set + # of optimistic unchokes Choke, i.e. stop uploading to, peers that dont perform well recompute choking every 10 seconds However: Optimistically unchoke peers twice every 30 seconds Reward good uploaders with capacity Slide 10 10 Sounds good in theory, but what if you have LOTS of upload capacity? most of your peers are slower (see later) nevertheless you must choose a few fastest peers probably already done AND you have split your upload capacity equally! you give your capacity away for free this is called ALTRUISM Altruism THE source of unfairness in BitTorrent Unfair peers only need 1.be slightly better than average 2.prefer rich girls, i.e. highly altruistic peers remember: active set has static size Slide 11 11 Unfairness/Altruism Illustrated Measure of altruism Slide 12 12 Unfairness/Altruism Illustrated (2) Altruism as wasted upload capacity slow clients never get reciprocated every byte is wasted fast clients contribute more than necessary Slide 13 13 Real World Observations Reference implementation uses active set size of This is what you are competing against be a bit faster! If you can upload > 14kB/s reciprocation prob > 99% !! Slide 14 14 The Optimal Active Set Size * * for a peer with 300 kB/s UL capacity Optimal Set Size Slide 15 15 BitTyrant A Selfish BitTorrent Client Based on Azureus Client publicly available at http://bittyrant.cs.washington.edu Exploiting the unfairness in BitTorrent Minimizing altruism to improve efficiency Mechanisms: choose only best peers with respect to UL/DL ratio (see next slide) deviate from equal split optimize active set size Slide 16 16 Peer Choice Optimization Algorithm Step invariant: Maintain u p, d p of peer p d p : Estimated download performance from p u p : Estimated upload needed for reciprocation with p Initially: set according to theor. distribution Each step: Rank order peers according to and choose best peers for unchoking After each round: Has p unchoked us? Has p not unchoked us? Has p unchoked us for the last r rounds? Slide 17 17 Experiences using BitTyrant Multiple BitTyrant peers: depends on a few factors and not easily comparable strategic, i.e. peers use adapted choking algorithm swarm performance improved compared to BitTorrent strategic & selfish, i.e. peer doesnt give back excess capacity swarm performance decreases dramatically One BitTyrant peer: median: 72% Slide 18 18 Personal Opinion Paper shows nice hack Paper shows that there is no perfect fairness Paper shows a sensible optimization But: I think, model is too restricted Peoples goals unconsidered Altruistic people are often just that: altruistic (they dont mind performing suboptimal) Everyone glad with BitTorrent, why optimize? And: will this paper make the world a better place? Slide 19 19 Part II Getting Almost Reliable Broadcast with Almost no Pain: Lightweight Probabilistic Broadcast Bases on papers: Lightweight Probabilistic Broadcast, 2003, Eugster, Guerraoui, Handurukande & Kouznetsov Slide 20 20 Background & Motivation Large scale event dissemination Processes p 1, , p n subscribe for topic t Event e with topic t is delivered to p 1, , p n Reliable Broadcast scales poorly Network level Broadcast/Multicast lacks reliability guarantees also scalability problems Complete view on the network leads to unsustainable memory demands Slide 21 21 The lpbcast Protocol System contains n processes = {p 1, , p n } dynamically joining and leaving Processes subscribe to a single topic easily extendible to multiple topics joining/leaving == subscribing/unsubscribing Gossip sent to F random nodes in view i of process p i F is fanout of process view i is subset of procs currently known by p i Gossips sent out periodically (non-synchronized) Slide 22 22 Gossips gossip: all-in-one record containing gossip.events: event notifications gossip.subs: subscriptions, gossip.unsubs: unsubscriptions, gossip.eventIds: history of events ids received so far Containers dont contain duplicates, i.e. they are set-like lists Slide 23 23 Processes Every process p has several buffers: view (fixed maximum size l): contains processes that are known to / seen by p subs (fixed maximum size |subs| M ): contains subscriptions received by p unsubs (fixed maximum size |unsubs| M ): contains unsubscriptions received by p events (fixed maximum size |events| M ): contains event notifications since last gossip emission eventIds (fixed maximum size |eventIds| M ): ids of events seen so far retrieveBuf: contains ids of events seen in gossip.eventids but not known Slide 24 24 Example Fanout: 3 |view| M = 8 Process p i view (p i ) Slide 25 25 lpbcast procedures Upon receiving a gossip message 1.Update view and unSubs with unsubscriptions 2.Update view with new subscriptions 3.Update events with new notifications 1.deliver notifications 2.update retrieveBuf for later retrieval of notifications 4.Perform housekeeping (truncate containers) When sending a gossip message fill gossip message accordingly Slide 26 26 Example: Zeit T0 12 view2 subs2 unSubs events eventId subs1, 2 unSubs events eventId GOSSIP 3 view2 Subs2 unSubs eventse3 eventId view3 subs3 unSubs eventse3, e4 eventIde3,e4 subs3, 2 unSubs eventse3 eventIde3 GOSSIP subs3, 2 unSubs eventse3, e4 eventIde3, e4 GOSSIP Slide 27 27 Example: Zeit T1 1 2 view2 subs2 unSubs events eventId subs1, 2 unSubs eventse18 eventId GOSSIP 3 view2 Subs2 unSubs events eventIde3, e4 view1,3 subs1,3 unSubs eventse5 eventIde3,e4,e5 subs3, 2 unSubs events eventIde3, e4 GOSSIP subs1,2,3 unSubs eventse5 eventIde3, e4,e5 GOSSIP subs1,2,3 unSubs eventse5 eventIde3,e4, e5 GOSSIP Slide 28 28 Analytical Evaluation of lpbcast Assumptions: constant during evaluation synchronous rounds upper bound on latency identical fanout F for all processes probability of message loss probability of crash random view ind. uniformly distributed Slide 29 29 Analytical Evaluation Turns out that throughput is independent from view size l provided that views are uniformly distributed Membership stability (no partitioning) increases with growing view size and/or system size partitioning probability increases slowly with rounds: 10 12 rounds for n=50, l=3 Slide 30 30 Practical Observations Throughput does depend a bit on l Explanation: views not as uniformly distributed as assumed Slide 31 31 Time to Infect all Processes Simulation meets measurements pretty well Fanout 3 1 msg injected System size varies Slide 32 32 Thank you for listening!