Convergence Refinement

1
Convergence Refinement

• Murat Demirbas Anish Arora
• The Ohio State University

2
A basic question in fault-tolerance

• Is fault-tolerance preserved under program
  refinement ?
• In other words,
• given a high-level program A that is
  fault-tolerant ,
• is a low-level implementation C of A
• yielded by a standard compiler or program
  transformer
• also fault-tolerant ?

3
A counterexample A toy infinite loop

• int x0
• while( xx )
• x0
• This program outputs 0 always
• it is live even if x is corrupted

• 0 iconst_0
• 1 istore_1
• 2 goto 7
• 5 iconst_0
• 6 istore_1
• 7 iload_1
• 8 iload_1
• 9 if_icmpeq 5
• 12 return
• Corresponding byte code can lose liveness
• if x is corrupted between lines 7 8

4
Another counterexample Bid Server

• High-level server
• maintains best K bids
• replaces minimum stored bid x with an incoming
  bid v iff xltv
• gracefully tolerates Byzantine failure of single
  bid location ,
• maintains (K-1) of best K bids

• Sorted-list implementation of server
• stores best K bids in increasing order
• incoming bid is considered only if it is larger
  than head of list
• does not tolerate single Byzantine failure
• e.g., of head of list

5
So, what went wrong?

• Standard compilers and transformers yield
  refinements
• Intuitively, refinement means that every properly
  initialized computation of C is is a computation
  of A
• Refinements are clearly insufficient, because
  they dont take into account states reached in
  the presence of faults
• E.g.

s
s
F
F
s0
s0
s1
s2
s3
s1
s2
s3
A
C
6
Fault-tolerance refinement isnt just
refinement

• What happens when compilers / transformers are
  modified to refine even from non-initialized
  states? ( Everywhere refinement )
• Unfortunately, fault-tolerance preserving
  refinements are not always everywhere
  refinements Leal 00
• intuitively because in the presence of faults C
  may not use the identical recovery path that A
  would
• In this paper, we develop an alternative notion
  of refinement that
• suffices for stabilization fault-tolerance
  preserving implementations
• applies also to masking fault-tolerance
  preserving implementations

7
Outline of talk

• Definition
• Compositionality
• role in wrapper-based design of stabilization
• An illustration
• deriving Dijkstras stabilizing programs from
  simple token rings

8
Definition Model

• A system is an automaton (?,T,I)
• ? state space, T set of transitions, I set
  of initial states
• Computation is a maximal sequence of
  states-transitions pairs
• C is stabilizing to A
• iff
• every computation of C has a suffix that is
  a suffix of some computation of A that starts at
  an initial state of A
• Note C and A may have different state spaces,
  relative to an abstraction function that is total
  and onto from C to A

9
Definition Convergence refinement C ? A

• C is a convergence refinement of A
• iff
• C refines A , and
• every computation c of C is a compressed form
  of some computation a of A
• Compressed means that c can omit a finite number
  of states in a, except its initial state and
  final state (if any)
• a s1 s2 s3 s4 s5 s6 a s1 s2
  s3 s4 s5 s6
• c s1 s4 s6 ? c s1 s0 s4
  s6 ?

10
Convergence refinement preserves stabilization

• C is a convergence refinement of A
• ? C tracks A from all states with only a finite
  number of compressions
• ? stabilization of A is preserved in C
• Theorem
• C ? A and A is stabilizing to B
• ?
• C is stabilizing to B

11
Outline of talk

• Definition
• Compositionality
• role in wrapper-based design of stabilization
• An illustration
• deriving Dijkstras stabilizing programs from
  simple token rings

12
Compositionality of convergence refinement

• A desirable property of convergence refinement is
  that if the union of two high-level components is
  stabilizing, then so is the union of their
  low-level convergence refinements
• Lemma
• If C ? A , A ? W is stabilizing to A
• then C ? W ? A ? W
• and hence C ? W is also stabilizing to A
• Theorem
• If C ? A , W ? W , A ? W is
  stabilizing to A
• then C ? W ? A ? W
• and hence C ? W is also stabilizing to A

13
Outline of talk

• Definition
• Compositionality
• role in wrapper-based design of stabilization
• An illustration
• deriving Dijkstras stabilizing programs from
  simple token rings

14
Deriving Dijkstras token ring programs

• After all these years of staring at Dijkstras
  program , why chose them as the illustration ?
• No previous work has been able to derive
  Dijkstras programs as refinements of simple
  token rings
• Next Steps
• Chose a simple token ring program BTR
• Add an abstract stabilization wrapper W to BTR
• Convergence refine BTR into BTR4 and W into
  W
• BTR?W results in Dijkstras 4-state token ring
  program
• The paper contains derivations for K-state
  3-state programs also

15
Step 0 Bidirectional token ring, BTR

• Propagate up-token at j
• ?t.j ?? ??t.j ?t.(j1)
• Bounce up-token at N
• ?t.N ?? ??t.N ?t.(N-1)
• Propagate down-token at j
• ?t.j ?? ?? t.j ?t.(j-1)
• Bounce down-token at 0
• ?t.0 ?? ?? t.0 ?t.1

16
Step 1 Stabilization wrappers for BTR

• W1 ensures that there exists at least one token
  in the system
• (?j j?N ??t.j ? ??t.j ) ?? ?t.N
• W2 ensures eventually at most one token exists in
  the system
• ?t.j ? ?t.j ?? ??t.j ??t.j
• (BTR ? W1 ? W2) is stabilizing to BTR
• Notice that W1 accesses to global state

17
Step 2 A 4 state implementation

• How to localize W1 ?
• Implement bits ?t.j and ?t.j in terms of 2 bits
  up.j and c.j
• up.0 true and up.Nfalse ensures that in any
  state there exists two adjacent processes that
  point to each other
• Up-token at j
• j and (j-1) point to each other
• c values at j and (j-1) differ
• formally , ?t.j ? c.j ? c.(j-1) ? up.(j-1) ?
  ?up.j
• Down-token at j
• j and (j1) point to each other
• c values at j and j1 are the same
• formally , ?t.j ? c.jc.(j1) ? ?up.(j1) ?
  up.j

18
BTR after the mapping

• Propagate up-token at j
• c.j ? c.(j-1) ? up.(j-1) ? ?up.j ?? c.j
  c.(j-1) up.j
• c.(j1) ? c.j ? ?up.(j1)
• Bounce up-token at N
• c.N? c.(N-1) ? up.(N-1) ?? c.N
  c.(N-1)
• up.(N-1)
• Propagate down-token at j
• c.jc.(j1) ? ?up.(j1) ? up.j ?? ?up.j
• c.(j-1) c.j ? up.(j-1)
• Bounce down-token at 0
• c.0c.1 ? ?up.1 ?? c.0
  ?c.0
• ?up.1

• Propagate up-token at j
• ?t.j ?? ??t.j ?t.(j1)
• Bounce up-token at N
• ?t.N ?? ??t.N ?t.(N-1)
• Propagate down-token at j
• ?t.j ?? ?? t.j ?t.(j-1)
• Bounce down-token at 0
• ?t.0 ?? ?? t.0 ?t.1

19
Wrappers after the mapping

• Applying the mapping to W1, we get
• (?j j?N up.j ) ? c.(N-1)?c.N ?? c.N
  ?c.(N-1) ? up.(N-1)
• The guard already implies the statement, hence
  W1 is already implemented after the mapping
• Since (?t.j ? ?t.j ? false), W2 is also vacuously
  implemented after the mapping
• So, the mapped BTR is trivially stabilizing

20
BTR4 compressing the high atomicity actions

• Unfortunately, some of the actions in BTR are
  high atomicity, where j writes the state of j-1
  or j1 , e.g.
• Propagate down-token at j
• c.jc.(j1) ? ?up.(j1) ? up.j ?? ?up.j
• c.(j-1) c.j ?
  up.(j-1)
• To reduce the atomicity, we convergence refine
  these actions by omitting write accesses to both
  neighbors
• Propagate down-token at j
• c.jc.(j1) ? ?up.(j1) ? up.j ?? ?up.j
• // c.(j-1) c.j ?
  up.(j-1)

21
BTR4 is a convergence refinement of BTR
?up.1 c.11
up.2 c.21
c.01
c.31
?t.0
?t.2
?t.1
?t.0
?up.1 c.11
?up.2 c.21
c.31
c.01
?t.0

• Token at process 2 disappears after a propagate
  down-token action at process 2

• Token at process 2 disappears only after two
  steps

22
BTR4

• Propagate up-token at j
• c.j ? c.(j-1) //? up.(j-1) ? ?up.j ?? c.j
  c.(j-1) up.j
• // c.(j1) ? c.j ? ?up.(j1)
• Bounce up-token at N
• c.N? c.(N-1) //? up.(N-1) ?? c.N
  c.(N-1)
• // up.(N-1)
• Propagate down-token at j
• c.jc.(j1) ? ?up.(j1) ? up.j ?? ?up.j
• // c.(j-1) c.j ? up.(j-1)
• Bounce down-token at 0
• c.0c.1 ? ?up.1 ?? c.0
  ?c.0
• // ?up.1

23
BTR4 ? W1 ? W2 Dijkstras 4-state system

• Up-token actions
• c.j ? c.(j-1) ?? c.j c.(j-1) up.j
• c.N? c.(N-1) ?? c.N c.(N-1)
• Down-token actions
• c.jc.(j1) ? ?up.(j1) ? up.j ?? ?up.j
• c.0c.1 ? ?up.1 ?? c.0
  ?c.0

24
Concluding remarks

• One step in simplifying fault-tolerance
  implementation is to derive wrappers based not on
  the concrete code but on the abstract
  specification
• Resettable vector clocks PODC00
• Dependable home networking Aladdin IPDPS02
• We are developing tools and frameworks for
  mechanical, reusable synthesis of wrappers from
  abstract specifications
• The second step is to use transformers that
  refine fault-tolerance
• Everywhere-eventually refinements ICDSN01
• AP to APC compiler McGuire, Gouda
• Since most such transformers still depend on the
  semantics of the input, we are developing
  fault-tolerance preserving compilers that depend
  only on syntax

25
Compositionality enables wrapper-based design

• Wrapper-based design is desirable for a
  posteriori or dynamic addition of stabilization
• Compositionality implies that a wrapper W
  designed to add stabilization to A also adds
  stabilization to any convergence refinement C of
  A
• ? stabilization of C is achieved oblivious of
  implementation details of C
• Moreover, any convergence refinement W of W also
  makes C stabilizing
• implementation of W can be oblivious of
  implementation of A

26
Continuous maintenance of network services

• As one example, consider routing in sensor
  networks it is required to dynamically adapt the
  fault-tolerance mechanisms to new environments
• We have built a .NET framework for dynamic
  composition of fault-tolerance wrappers
• We are using the Austin Protocol Compiler Gouda,
  McGuire that yields C-code UDP socket based
  communication while preserving certain
  stabilization properties to get concrete wrappers
• e.g.,

ARouting
APC
CRouting