BAR gossip. Antonio Massaro. May 9, May 9, / 40

Transcription

1 BAR gossip Antonio Massaro May 9, 2016 May 9, / 40

2 MAD services Single nodes cooperate to provide services in Multiple Administrative Domains Internet routing File distribution Archival storage Cooperative backup Mad services may fail Nodes can break down Nodes can be malicious Nodes can act selfishly The challenge Develop a protocol that is resilient to malicious and selfish behaviour May 9, / 40

3 BAR model Nodes can be Byzantine: act in arbitrary ways Altruistic: act as prescribed by the protocol Rational: deviate from the protocol only if convenient May 9, / 40

4 The setting: p2p gossip for media streaming PROs Absorbs peak partecipation Costs shifted to clients Self-organizing Robust, scalable, adaptive Challenges Guarantee reliable, stable, timely throughput Clients may deviate from the protocol Li, Harry C., et al. "BAR gossip." Proceedings of the 7th symposium on Operating systems design and implementation. USENIX Association, 2006 May 9, / 40

5 The basic idea May 9, / 40

6 The basic idea 1. multicast May 9, / 40

7 The basic idea 2. p2p exchange May 9, / 40

8 The basic idea Warning Rational clients may prefer not to share May 9, / 40

9 Impact of rational clients on reliability May 9, / 40

10 Impact of rational clients on bandwidth May 9, / 40

11 Impact of rational clients on reliability, BAR gossip May 9, / 40

12 Impact of rational clients on bandwidth, BAR gossip May 9, / 40

13 BAR gossip protocol: the setting Application Altruistic broadcaster BAR clients Static membership Full membership list Updates expire after finite time Cryptography RSA public/private keys All messages are signed The cryptosystem cannot be subverted Incentives Benefit: playing updates Cost: upload/download Clients provably deviant risk eviction May 9, / 40

14 BAR gossip protocol: overview At each round, the broadcaster multicasts to a subset of clients. Balanced Exchange Optimistic Push 1 Partner selection 2 Exchange histories 3 Trade equal number of updates 1 Partner selection 2 Exchange histories 3 Trade a possibly unequal number of updates What if a client lags behind? May 9, / 40

15 BAR gossip protocol: overview Trusted agent of the broadcaster At each round, polls random clients If a client has a POM 1, it sends it to the auditor If it has no POM, it sends a dummy message (why? what is its dimension?) The broadcaster includes deviant clients in the evicted list, and broadcasts it in subsequent rounds 1 Proof Of Misbehavior May 9, / 40

16 Balanced Exchange overview 1 Partner selection Key design aspects: 2 History exchange Restricted choice 3 Update exchange Delayed gratification 4 Key exchange Balanced exchage is incentive compatible and NASH equilibrium May 9, / 40

17 Assumptions 1 Rational clients will not issue a POM against themselves 2 Rational clients will not enter an exchange with a byzantine client May 9, / 40

18 1. Partner selection Note: in traditional gossip, a rational client could exploit randomness to hide a strategy on partner s selection 1 S sends a seed to R as the signed round number. R=PRNG(< r > S ) 2 R checks: The seed refers to the right round He is the correct client to be selected Deterministic yet unpredictable A rational client sends the correct seed (otherwise POM) A rational client accepts only correct seeds (why...?) May 9, / 40

19 2. History exchange 1 S sends a hash of its history 2 R sends its history 3 S sends its history R cannot use any strategy (he does not know H s ) A rational client sends a history coherent with the hash A rational client accepts only valid histories May 9, / 40

20 3. Briefcase exchange Both R and S do: 1 Generate a key as #(private key, seed) 2 Encript the updates to be exchanged 3 Send a plain text description of the updates and the encripted updates Wrong update description abort exchange A rational client will send the appropriate plaintext A rational client sends encripted updates coherently with the plaintext description May 9, / 40

21 4. Key exchange Both R and S do: 1 Send key request 2 Respond to key request Fair exchange of decription keys is impossible without a trusted third party. Pagnia, Henning, and Felix C. Gartner. On the impossibility of fair exchange without a trusted third party. Technical Report TUD-BS , Darmstadt University of Technology, Department of Computer Science, 1999 We opt for fair enough exchange, based on a credible threat. May 9, / 40

22 4. Key exchange How do we convince a rational client to respond? Repeated requests A rational client minimizes the cost sending the key A rational client will send key requests If a rational client responds, it sends the correct key If a rational client does not receive a key response, it will resend its key request May 9, / 40

23 Balanced exchange Balance exchange is incentive compatible May 9, / 40

24 Optimistic push overview 1 Partner selection 2 History exchange 3 Possibly unequal update exchange 4 Key exchange May 9, / 40

25 Optimistic push May 9, / 40

26 Optimistic push May 9, / 40

27 Optimistic push May 9, / 40

28 Optimistic push, problems How do we force lagging clients to send as many updates as possible? Require both briefcases to have equal length Possibly including junk May 9, / 40

29 Optimistic push, problems What if a client sends junk instead of updates? May 9, / 40

30 Optimistic push, problems What if a client sends junk instead of updates? Junk is larger than real updates. Rational clients will not prefer optimistic push to balanced exchange. May 9, / 40

31 Optimistic push. History exchange 1 S sends its history and a list of missing updates ids that it wants. 2 If R can satisfy S s request, it sends c ids from S s history that it wants. May 9, / 40

32 Optimistic push. Briefcase exchange 1 S sends the c updates. 2 R sends b updates from the missing list and c b junk updates, b maximal such that b c. May 9, / 40

33 Bar Gossip recap Balanced exchange Optimistic push Partner selection History exchange Trade equal number of updates Partner selection History exchange Trade possibly unequal number of updates Incentive compatible Incentive compatible? Don t know: explore the strategy space by simulations! May 9, / 40

34 Strategies for a rational client in OP Objective: evaluate unilateral rational deviation in OP. Assumption: consider just pure strategies Strategy Accepts Op Initiates OP Returns Proactive/Data Y Y Data Proactive/Junk Y Y Junk Proactive/None N Y None Passive/Data Y N Data Passive/Junk Y N Junk Passive/None N N None May 9, / 40

35 Reliability for unilateral rational deviations If all clients follow BAR Gossip, there is no obvious incentive for deviation Conjecture: BAR gossip is almost NASH May 9, / 40

36 Rational collusion Rational collusion is explored by simulation, in a simplified setting Exchange within the colluding group has 0 cost Exchange within the colluding group is immediate Colluding clients do not enter Optimistic Push If collusion group reaches 50%, the probability is 93% May 9, / 40

37 Byzantine deviation Byzantine deviation is explored by simulation, in a simplified setting Byzantine clients increase cost and decrease benefit of all players Induce other clients to exchange max number of updates Never enter key/updates exchange Byzantine clients are never evicted If 20% of the clients are byzantine, the probability of receiving an update decreases just by 7 % May 9, / 40

38 Open points Is BAR gossip a Nash equilibrium for rational clients? A complete analysis of optimal strategies for colluding rational clients. A complete analysis of the effect of byzantine strategies. Dynamic membership. May 9, / 40

39 Conclusions BAR gossip is the first protocol defined under the BAR model Key ideas: verifiable randomness restricted choice fair enough key exchange If up to 20% of the nodes are Byzantine or up to 40% collude, a correct node will recieve more than 93% updates timely. May 9, / 40

40 Bibliography May 9, / 40

41 Amitanand S Aiyer, Lorenzo Alvisi, Allen Clement, Mike Dahlin, Jean-Philippe Martin, and Carl Porth. Bar fault tolerance for cooperative services. In ACM SIGOPS operating systems review, volume 39, pages ACM, Harry C Li, Allen Clement, Mirco Marchetti, Manos Kapritsos, Luke Robison, Lorenzo Alvisi, and Mike Dahlin. Flightpath: Obedience vs. choice in cooperative services. In OSDI, volume 8, pages , Harry C Li, Allen Clement, Edmund L Wong, Jeff Napper, Indrajit Roy, Lorenzo Alvisi, and Michael Dahlin. Bar gossip. In Proceedings of the 7th symposium on Operating systems design and implementation, pages USENIX Association, May 9, / 40