Efficient Condition-Based Consensus in Asynchronous Distributed - - PowerPoint PPT Presentation

Efficient Condition-Based Consensus

in Asynchronous Distributed Systems

Achour Most´ efaoui, Sergio Rajsbaum Michel Raynal and Matthieu Roy mroy@irisa.fr

Efficient Condition-Based Consensus – p.1/25

Summary

• Computation model and the Consensus

Problem

• The Condition-Based approach
• Definitions,
• A simple protocol.
• Efficient protocol for consensus
• A hierarchy of conditions,
• A tailored read/write primitive,
• A generic formula for defining conditions.

Efficient Condition-Based Consensus – p.2/25

Computation Model

• An a priori known set of
• processes

,

• Communication via Shared Memory

(supposed to be reliable)

• Asynchronous
• Model of failures: Fail-stop.
• At most

processes may crash,

• A correct process is a process that does

not crash.

Efficient Condition-Based Consensus – p.3/25

The Consensus Problem

Specification:

• Termination: Every correct process eventually

decides some value,

• Validity: A decided value is a proposed value,
• Agreement: No two processes decide

different values.

Efficient Condition-Based Consensus – p.4/25

Impossibility Theorem

• Fischer-Lynch-Paterson’s Impossibility result

(FLP 85)

• There is no deterministic protocol that

solves the consensus problem is an asynchronous distributed system prone to even a single crash failure

Efficient Condition-Based Consensus – p.5/25

Solving the Consensus

How to circumvent FLP result ?

Efficient Condition-Based Consensus – p.6/25

Solving the Consensus

How to circumvent FLP result ?

• Change specification
• set agreement (Chaudhuri 90)

Efficient Condition-Based Consensus – p.6/25

Solving the Consensus

How to circumvent FLP result ?

• Change specification
• set agreement (Chaudhuri 90)
• Add oracles
• Failure detectors (Chandra & Toueg 91)
• Random generator (Ben Or 83, Rabin 83)

Efficient Condition-Based Consensus – p.6/25

The Condition-Based Approach

• FLP says: “you can’t build a protocol that

solves consensus for any input configuration”

Efficient Condition-Based Consensus – p.7/25

The Condition-Based Approach

• FLP says: “you can’t build a protocol that

solves consensus for any input configuration”

• We define a set
• f input configurations that

for which the consensus problem is solvable despite up to crashes.

0111 1000 1001 1011 1100 1111 0110 0101 1101 0100 0011 1010 0010 0001 0000 1110

V ={0,1}, and n=4 V: set of proposable values V^n: set of all possible input vectors

Efficient Condition-Based Consensus – p.7/25

The Condition-Based Approach

• FLP says: “you can’t build a protocol that

solves consensus for any input configuration”

• We define a set
• f input configurations that

for which the consensus problem is solvable despite up to crashes.

0111 1000 1111 0100 0010 0001 0000 1110 1011 0011 1101

Decide 0 Decide 1

1010 1100 1001 0110 0101

Efficient Condition-Based Consensus – p.7/25

Previous Works on Conditions

• STOC’01: A characterization of Conditions

that make the Consensus problem solvable.

• PODC’01: A hierarchy of conditions that

shows a tradeoff between termination and communication load.

• SIROCCO’01: an early stopping protocol, an

adaptative version of PODC protocol.

Efficient Condition-Based Consensus – p.8/25

The Condition-Based Approach

We want to design protocols that:

• Are always safe (agreement and validity),
• Solve consensus when the inputs (proposed

values) satisfy an a priori known pattern,

• Make the best effort to terminate,e.g. always

terminate when no process crashes.

Efficient Condition-Based Consensus – p.9/25

The Condition-Based Approach

We want to design protocols that:

• Are always safe (agreement and validity),
• Solve consensus when the inputs (proposed

values) satisfy an a priori known pattern,

• Make the best effort to terminate,e.g. always

terminate when no process crashes. Let’s change the termination property:

• if the input pattern belongs to the condition

and no more than processes crash, then every correct process decides.

Efficient Condition-Based Consensus – p.9/25

Some notations

• is the set of proposable values, and

denotes “no value”,

• an input vector
• is an
• entry vector of

: if

proposes

, then

• ☎✝✆

,

• ✠

• ☛

denotes the number of occurrences of

in

• .
• a Condition

is a subset of

.

Efficient Condition-Based Consensus – p.10/25

Local views

• a local view , denoted
• , is an
• entry vector
• f

that contains at most ,

• ☎

dominates

• ✆

, denoted

• ✆
• ☎

, if

• ☎
• ✆

• ✆

• ☎

,

• if
• ✞

, let the uncertainty neighborhood of

• be

• ☞

• ☛

.

Efficient Condition-Based Consensus – p.11/25

Acceptability of a Condition

A condition is said to be

• weak-acceptable iff

there exist a predicate and a function

• s. t. :
• Property T

: (Termination)

• ✞

• ✞

• ☛
• Property A

: (Agreement)

• ✆

• ☎

• ✆
• ☎

• ✆

• ☎

• ✡
• ✆

• ✡
• ☎

• Property V

: (Validity)

• ✞

• ☛
• ✡
• ☛

= a non- value of

• Efficient Condition-Based Consensus – p.12/25

Acceptability of a Condition

• the predicate

tells a process if it can decide based on its local view,

• the function
• calculates the decision value

for a process that can terminate. Theorem : The set of

• weak-acceptable

conditions is exactly the set of conditions for which there exists a protocol.

Efficient Condition-Based Consensus – p.13/25

A simple protocol

Each process

• writes its input value in a shared vector
• ,
• reads
• using snapshot until it gets a view
• containing at least
• non-

values,

• if

• ☛

holds,

• then it calculates

• ✡
• ☛

, writes it into a decision vector and decides

,

• else it writes

in and repeats reading until it reads a non-

value or until all processes have written a , then it decides.

Efficient Condition-Based Consensus – p.14/25

A simple protocol (2)

The former protocol

• can be used with any acceptable condition
• uses a strong tool : snapshot
• generates an order on local views
• reduces the “entropy” of the global view
• but is costly
• can the read/write model be weakened ?
• Yes, if conditions are stronger

Efficient Condition-Based Consensus – p.15/25

A Hierarchy of Condition

The acceptability properties can be made stronger:

• the previous definition of Property A

was:

• ✆
• ☎

• ✆

• ☎

• ✡
• ✆

• ✡
• ☎

• ✆
• ☎

: all views are ordered.

Efficient Condition-Based Consensus – p.16/25

A Hierarchy of Condition

The acceptability properties can be made stronger:

• the previous definition of Property A

was:

• ✆
• ☎

• ✆

• ☎

• ✡
• ✆

• ✡
• ☎

• ✆
• ☎

: all views are ordered.

• we define
• Agreement by replacing

• ✆
• ☎

by

• ✆
• ☎

• r

• ✆

• ☎

• ☛

• processes are not ordered if they have

enough information.

Efficient Condition-Based Consensus – p.16/25

A Hierarchy of conditions

• If
• ✁

is the set of

• ☛

acceptable conditions, then

• ✁✆☎

• ✁

• ✂

• ✝

• What is the interest of such a hierarchy ?
• a small
• gives bigger conditions, but

requires a strong read/write model.

• ✞✠✟

• ☞

• when
• increases, conditions get smaller,

but synchrony requirements are reduced.

• ✏

• ✆

• Efficient Condition-Based Consensus – p.17/25

Reducing communication load

How to implement a primitive that ensures

• ✆
• ☎

• r

• ✆

• ☎

• ☛

?

Efficient Condition-Based Consensus – p.18/25

Reducing communication load

How to implement a primitive that ensures

• ✆
• ☎

• r

• ✆

• ☎

• ☛

?

• using a tree similar to Attiya and Rachmann

tree for the snapshot(Atomic snapshots in

• ✁✄✂

• perations, PODC’93).
• The structure of the tree is static,
• Each node contains data structures that are

read and wrote by processes during the execution of the primitive,

• Every process traverses the tree from the root

to a leaf.

Efficient Condition-Based Consensus – p.18/25

Reducing communication load (2)

• At each node, a process:
• writes its knowledge in the node’s array

Efficient Condition-Based Consensus – p.19/25

Reducing communication load (2)

• At each node, a process:
• writes its knowledge in the node’s array
• reads the total amount of information wrote

by him and (eventually) other processes in the node,

Efficient Condition-Based Consensus – p.19/25

Reducing communication load (2)

• At each node, a process:
• writes its knowledge in the node’s array
• reads the total amount of information wrote

by him and (eventually) other processes in the node,

• goes in the right or left son depending on

the informations collected and the position

• f the node.

Efficient Condition-Based Consensus – p.19/25

The strong-collect tree

log

2(f/2+1)

[n−f, n] (...) (...)

[n−f, n−f+1] [n−f/2+1, n]

f/2 trivial interval leaves (f/2+1)/2 leaves

{n−f/2+1} [n−f/2, n] {n−f+1} {n−f} {n−(3f+6)/4} {n−(3f+2)/4} {n−(3f−2)/4} {n−(3f−6)/4} [n−(3f+6)/4,n−(3f+2)/4] [n−(3f−2)/4,n−(3f−6)/4]

[n−f, n−(3f+2)/4] [n−(3f−2)/4, n]

Efficient Condition-Based Consensus – p.20/25

Shortening the tree traversal

• To ensure agreement, there is an additional

parameter,

• , that depends of the condition:
• a process must be sure that if it early

decides, then all the other processes will decide the same value.

• At each node, a process tests a predicate
• ✁

,

• depending on
• , its knowledge of the

system, and the node.

Efficient Condition-Based Consensus – p.21/25

A way to define hierarchical conditions

The former protocol is used with a hierarchical

• condition. How to define such a hierarchy ?

Efficient Condition-Based Consensus – p.22/25

A way to define hierarchical conditions

The former protocol is used with a hierarchical

• condition. How to define such a hierarchy ?
• define a positive weight
• n the input

alphabet ,

• use the weight-based definition of a condition:

• ✞
• ✁

iff

• ☎

• ✂

• ☛
• ✡

• ✄

• ☛
• ✡

• ☛

max

• ✡

• ✡

Efficient Condition-Based Consensus – p.22/25

A way to define hierarchical conditions

The former protocol is used with a hierarchical

• condition. How to define such a hierarchy ?
• define a positive weight
• n the input

alphabet ,

• use the weight-based definition of a condition:

• ✞
• ✁

iff

• ☎

• ✂

• ☛
• ✡

• ✄

• ☛
• ✡

• ☛

max

• ✡

• ✡

• every positive weight function defines a

hierarchy of acceptable conditions

Efficient Condition-Based Consensus – p.22/25

Examples - Two conditions

• Condition C1
• ✡
• ✞

iff

• ☛
• ✝

• ☛

• defined by
• ✡

The value that appears the most often has to bypass the second one by at least

• ccurrences.

Efficient Condition-Based Consensus – p.23/25

Examples - Two conditions

• Condition C1
• ✡
• ✞

iff

• ☛
• ✝

• ☛

• defined by
• ✡

The value that appears the most often has to bypass the second one by at least

• ccurrences.
• Condition C2
• ✡
• ✞

iff

• ✁

• ☛

• ☛

• defined by
• ✡

• ✁

if

.

Efficient Condition-Based Consensus – p.23/25

Evaluation

Condition

for binary consensus with

processes.

• suitable for small values of

.

Efficient Condition-Based Consensus – p.24/25

Conclusion

So, what is a condition-based protocol ?

• a protocol that is guaranteed to terminate in a

priori known cases;

• cases of non-convergence are assumed to
• ccur rarely,
• when not in condition, the protocol does its

best to terminate.

• some sort of “compilation” of cases to reduce

communication between processes

• a tradeoff between termination and

communication

Efficient Condition-Based Consensus – p.25/25