Distributed Algorithms Lecture 10b – by Ali Ghodsi Fault-Tolerance in Asynchronous Networks – Probabilistic Consensus.

Slides:



Advertisements
Similar presentations
ON THE COMPLEXITY OF ASYNCHRONOUS GOSSIP Presented by: Tamar Aizikowitz, Spring 2009 C. Georgiou, S. Gilbert, R. Guerraoui, D. R. Kowalski.
Advertisements

Impossibility of Distributed Consensus with One Faulty Process
Impossibility of Consensus in Asynchronous Systems (FLP) Ali Ghodsi – UC Berkeley / KTH alig(at)cs.berkeley.edu.
1 © R. Guerraoui The Limitations of Registers R. Guerraoui Distributed Programming Laboratory.
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Authored by: Seth Gilbert and Nancy Lynch Presented by:
1 Indranil Gupta (Indy) Lecture 8 Paxos February 12, 2015 CS 525 Advanced Distributed Systems Spring 2015 All Slides © IG 1.
6.852: Distributed Algorithms Spring, 2008 Class 7.
Distributed Systems Overview Ali Ghodsi
Announcements. Midterm Open book, open note, closed neighbor No other external sources No portable electronic devices other than medically necessary medical.
Distributed Algorithms – 2g1513 Lecture 10 – by Ali Ghodsi Fault-Tolerance in Asynchronous Networks.
Outline. Theorem For the two processor network, Bit C(Leader) = Bit C(MaxF) = 2[log 2 ((M + 2)/3.5)] and Bit C t (Leader) = Bit C t (MaxF) = 2[log 2 ((M.
Distributed Computing 8. Impossibility of consensus Shmuel Zaks ©
Consensus problem Agreement. All processes that decide choose the same value. Termination. All non-faulty processes eventually decide. Validity. The common.
Byzantine Generals Problem: Solution using signed messages.
Failure Detectors. Can we do anything in asynchronous systems? Reliable broadcast –Process j sends a message m to all processes in the system –Requirement:
Consensus Algorithms Willem Visser RW334. Why do we need consensus? Distributed Databases – Need to know others committed/aborted a transaction to avoid.
1 Principles of Reliable Distributed Systems Lecture 6: Synchronous Uniform Consensus Spring 2005 Dr. Idit Keidar.
1 Principles of Reliable Distributed Systems Lecture 3: Synchronous Uniform Consensus Spring 2006 Dr. Idit Keidar.
Sergio Rajsbaum 2006 Lecture 3 Introduction to Principles of Distributed Computing Sergio Rajsbaum Math Institute UNAM, Mexico.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 7: Failure Detectors.
CPSC 668Set 9: Fault Tolerant Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
CPSC 668Set 9: Fault Tolerant Consensus1 CPSC 668 Distributed Algorithms and Systems Spring 2008 Prof. Jennifer Welch.
Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 6: Synchronous Byzantine.
1 Fault-Tolerant Consensus. 2 Failures in Distributed Systems Link failure: A link fails and remains inactive; the network may get partitioned Crash:
Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 5: Synchronous Uniform.
Randomized Protocols for Asynchronous Consensus James Aspnes Distributed Computing (2003) 16:
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 6: Impossibility.
Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 6: Synchronous Byzantine.
CPSC 668Set 11: Asynchronous Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2006 Prof. Jennifer Welch.
CPSC 668Set 11: Asynchronous Consensus1 CPSC 668 Distributed Algorithms and Systems Fall 2009 Prof. Jennifer Welch.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 12: Impossibility.
Distributed Algorithms: Agreement Protocols. Problems of Agreement l A set of processes need to agree on a value (decision), after one or more processes.
CS 425 / ECE 428 Distributed Systems Fall 2014 Indranil Gupta (Indy) Lecture 19: Paxos All slides © IG.
Distributed Systems Tutorial 4 – Solving Consensus using Chandra-Toueg’s unreliable failure detector: A general Quorum-Based Approach.
On the Cost of Fault-Tolerant Consensus When There are no Faults Idit Keidar & Sergio Rajsbaum Appears in SIGACT News; MIT Tech. Report.
Systems of Distributed systems Module 2 - Distributed algorithms Teaching unit 2 – Properties of distributed algorithms Ernesto Damiani University of Bozen.
 Idit Keidar, Principles of Reliable Distributed Systems, Technion EE, Spring Principles of Reliable Distributed Systems Lecture 7: Failure Detectors.
Consensus and Related Problems Béat Hirsbrunner References G. Coulouris, J. Dollimore and T. Kindberg "Distributed Systems: Concepts and Design", Ed. 4,
On Probabilistic Snap-Stabilization Karine Altisen Stéphane Devismes University of Grenoble.
Distributed Consensus Reaching agreement is a fundamental problem in distributed computing. Some examples are Leader election / Mutual Exclusion Commit.
Lecture 8-1 Computer Science 425 Distributed Systems CS 425 / CSE 424 / ECE 428 Fall 2010 Indranil Gupta (Indy) September 16, 2010 Lecture 8 The Consensus.
Distributed Algorithms – 2g1513 Lecture 9 – by Ali Ghodsi Fault-Tolerance in Distributed Systems.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS Fall 2011 Prof. Jennifer Welch CSCE 668 Set 11: Asynchronous Consensus 1.
Consensus and Its Impossibility in Asynchronous Systems.
Review for Exam 2. Topics included Deadlock detection Resource and communication deadlock Graph algorithms: Routing, spanning tree, MST, leader election.
Consensus with Partial Synchrony Kevin Schaffer Chapter 25 from “Distributed Algorithms” by Nancy A. Lynch.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 8 Instructor: Haifeng YU.
Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved Chapter 8 Fault.
DISTRIBUTED ALGORITHMS AND SYSTEMS Spring 2014 Prof. Jennifer Welch Set 11: Asynchronous Consensus 1.
MPRI – Course on Concurrency Probabilistic methods in Concurrency Catuscia Palamidessi INRIA Futurs and LIX
CS 425/ECE 428/CSE424 Distributed Systems (Fall 2009) Lecture 9 Consensus I Section Klara Nahrstedt.
Distributed systems Consensus Prof R. Guerraoui Distributed Programming Laboratory.
Chap 15. Agreement. Problem Processes need to agree on a single bit No link failures A process can fail by crashing (no malicious behavior) Messages take.
Agreement in Distributed Systems n definition of agreement problems n impossibility of consensus with a single crash n solvable problems u consensus with.
Chapter 21 Asynchronous Network Computing with Process Failures By Sindhu Karthikeyan.
1 Fault tolerance in distributed systems n Motivation n robust and stabilizing algorithms n failure models n robust algorithms u decision problems u impossibility.
Fault tolerance and related issues in distributed computing Shmuel Zaks GSSI - Feb
DISTRIBUTED ALGORITHMS Spring 2014 Prof. Jennifer Welch Set 9: Fault Tolerant Consensus 1.
CS4231 Parallel and Distributed Algorithms AY 2006/2007 Semester 2 Lecture 9 Instructor: Haifeng YU.
1 Fault-Tolerant Consensus. 2 Communication Model Complete graph Synchronous, network.
The consensus problem in distributed systems
CS 525 Advanced Distributed Systems Spring 2013
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
CS 525 Advanced Distributed Systems Spring 2018
Distributed Consensus
Agreement Protocols CS60002: Distributed Systems
CS 425 / ECE 428 Distributed Systems Fall 2017 Indranil Gupta (Indy)
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Distributed systems Consensus
Presentation transcript:

Distributed Algorithms Lecture 10b – by Ali Ghodsi Fault-Tolerance in Asynchronous Networks – Probabilistic Consensus

2 Impossibility of Consensus We know there exists an infinite execution in any consensus algorithm for asynchronous networks that tolerates  1 failure Why exactly is such an algorithm not a consensus algorithm?

3 Definition: T-crash fair executions A t-crash-robust algorithm is a consensus algorithm if it satisfies:  Termination All correct processes eventually decide  Agreement In any configuration, the decided processes should have decided for the same value (0 or 1)  Non-triviality There exists at least one possible input configuration where the decision is 0 There exists at least one possible input configuration where the decision is 1  Example, maybe input “0,0,1”->0 while “0,1,1”->1

4 Definition: T-crash fair executions A t-crash-robust algorithm is a consensus algorithm if it satisfies:  Termination All correct processes eventually decide  Agreement In any configuration, the decided processes should have decided for the same value (0 or 1)  Non-triviality There exists at least one possible input configuration where the decision is 0 There exists at least one possible input configuration where the decision is 1  Example, maybe input “0,0,1”->0 while “0,1,1”->1

5 How to make it possible Lets make an algorithm that makes such infinite executions unlikely! Even if such infinite executions would be unlikely, this would not formally be a consensus algorithm How to change the definition?  What do we require for “probabilistic consensus” algorithms?

6 Probabilistic Consensus A probabilistic t-crash-robust algorithm is a consensus algorithm if it satisfies:  Termination/Convergence lim P[a correct process has not decided after k steps] = 0 k→   Agreement In any configuration, the decided processes should have decided for the same value (0 or 1)  Non-triviality There exists at least one possible input configuration where the decision is 0 There exists at least one possible input configuration where the decision is 1  Example, maybe input “0,0,1”->0 while “0,1,1”->1

7 Count and receive N-t votes Bracha & Tuoeg Probabilistic Consensus Can tolerate t < N/2 crash-failures  N=10 t=4, N=11 t=5 Cannot wait on more than N-t receives varvalue p : (0,1)init x p msgs p [0..1] : intinit 0 begin while y p =b do begin msgs p [0]:=msgs p [1]:=0; shout ; while msgs p [0]+msgs p [1] < N-t do begin receive ; msgs p [v]++; end if msgs p [0]>msgs p [1] then value p :=0 else value p :=1; end Two counters (vector), both initially 0 My initial value Keep looping until decisionBroadcast my value and my round numberReset both counters to 0Choose majority

8 If in the right round Proceed as before! Bracha & Tuoeg Probabilistic Consensus Asynchronism:  Shout and receives should go in rounds  Avoid messages being consumed in the wrong round varvalue p : (0,1)init x p round p : intinit 0 msgs p [0..1] : intinit 0 begin while y p =b do begin msgs p [0]:=msgs p [1]:=0; shout ; while msgs p [0]+msgs p [1] < N-t do begin receive ; if r>round p then send to p; else if r=round p then begin msgs p [v]++; end if msgs p [0]>msgs p [1] then value p :=0 else value p :=1; round p ++; end Also send round number Keep track of rounds (initally 0) Postpone future messagesAlso receive round numberMove into next round

9 Idea:  If any node sees more than N/2 similar values, it has witnessed an absolute majority Each time you vote V, announce the number of V’s you have seen  I.e. attach the weight of your vote Other nodes can tell from your weight if you are a witness or not The vote of a witness overrides any other votes If more than t witnesses are seen in one round, finally decide! Absolute Majority

varvalue p : (0,1)init x p round p : intinit 0 weight p : intinit 1 msgs p [0..1] : intinit 0 witness p [0..1]: intinit 0 begin while y p =b do begin witness p [0]:=withness p [1]:=msgs p [0]:=msgs p [1]:=0; shout ; while msgs p [0]+msgs p [1]<N-t do begin receive ; if r>round p then send to p; else if r=round p then begin msgs p [v]++; if w > N/2 then witness p [v]++; end if witness p [0]>0 then value p :=0 else if witness p [1]>0 then value p :=1 else if msgs p [0]>msgs p [1] then value p :=0 else value p :=1; weight p :=msgs p [value p ]; if witness p [value p ]>t then y p =value p ; round p ++; end shout end Idea: If any node sees more than N/2 similar values, it has witnessed an absolute majority Weight is initially 1Counter for number of witnesses for 0 and 1Reset number if witnesses in each roundAlso send the weight of the voteAlso receive the weight of the voteSomeone’s weight is more than N/2, then it has seen half of the votes in one round! Increment the witness counter for that value Witnesses override your next voteBefore voting, calculate the weight of the vote If more than t witnesses, decide, and we are DONE Before terminating, give a witness vote in the two following rounds

11 Proving Probabilistic Consensus Agreement  If any process decides, then all processes decide in the next two rounds Proof:  First notice that in one round, no two processes can witness for different values (0/1) I.e, for two witnesses p and q: p receives > N /2 ones, and q receives > N /2 zeroes  We know processes decide if they see t witnesses If p decides 1 in round k, there were > t witnesses in the round So everyone in round k has seen at least one witness for 1 Everyone will therefore vote 1 in round k+1 In round k+2, everyone will have seen t witnesses, and hence will decide!

12 Convergence? How do we know we will ever see a first decide?  Termination/Convergence lim P[a correct process has not decided after k steps] = 0 k→  Assume fair scheduling  In any round, for any two nodes p and q, p will receive a message from q with positive probability For a subset S of correct processes N-t, there exists some positive probability p (maybe very small) that every process in S receives the votes of the processes in S in some round K  With probability p 3 this happens in the next two rounds also  Hence in round K, processes in S receive the same vote and vote similarly in round K+1  In round K+1, there will exist N-t similar votes, hence someone in S have seen a witness in the next round (decide)

13 Summary We have shown that probabilistic consensus algorithms exist for the asynchronous networks It can tolerate up to approx. half of the processes failing!