1. Anh Nguyen

2.  The emergence of continuous consistency model (CCM)  Conit-based CCM  What is it?  Policies  Examples  Discussion Break…  The composability of consistency conditions  Discussion  Summary 2

3.  Understand the ideas of CCM, and Conit-based CCM  Examples ▪ Identify conits, parameters  Understand the general meaning of the framework of the composability of consistency conditions  What is it?  What is it for?  Basic consistency conditions 3

4.  The availability of services  The exponential increase in access to Web services  Network failures  0.1% improvement in availability ≈ 8 hours of additional uptime/year ≈ $1 million in additional revenue  Replication is a key approach 4

5.  Despite being a really promising solution to improve the availabality of services, it also brings about many new issues  Inconsistency among replicas  Ex: distributed database 5

6. Strict consistency models  Synchronise accesses to a subset of replicas to achieve a uniform view of write orderings  One-copy serializability  Impose performance overhead  Limit system availability  Keep the system consistent Well-known tradeoffs between consistency and availability 6 Optimistic consistency models  Allow multiple updates to take place simultaneously at defferent replicas  Resolve conflicts: reconciliation algorithms (Ficus)  Improve performance  Improve system availability  Unbounded rate of conflicting updates can quickly leave the system in a ”delusional” state

7.  Designers have been forced to choose from either consistency guarantees (strict consistency models) or none at all (optimistic consistency models)  Different applications have different requirements about consistency (the level of consistency)  Bulletin board vs Airline reservation system  An application may need different levels of consistency during its runtime or under certain circumstances  A dynamic web page tracking the score of a football game → Continuous consistency models: enable services to describe and to specify different levels of consistency in between traditional strong and optimistic consistency 7

8.  Haifeng Yu and Amin Vahdat introduced the concept of a conit (consistency unit)  The conit-based CCM  allows a broad range of replicated services to conveniently and quantitatively express their consistency requirements  applicable to a wide range of applications (generality)  able to efficiently enforce target consistency levels (practicality) 8

9.  A conit is a logical consistency unit  The space of consistency is parameterized by the following metrics  Numerial error: the total weight of writes on a conit not seen by a replica  Order error: the number of writes that have not established their commit order at any one replica  Staleness: a real-time bound on the delay of write propagation among replicas 9

10.  An example: a replicated bulletin board service where users may post/retrieve news messages to/from any replica  Conit: number of all news messages  Numerial error: the total number of messages posted system- wide but not seen locally  Order error: the number of out of order messages on a given replica (messages seen locally but not committed)  Staleness: the delay of messages 10

11.  An exercise  Airline Reservation System  A replicated e-commerce service that accepts inquiries and purchase orders on a catalog  Each server maintains a full replica of the flight information database and accepts user reservatinos and inquiries about seat availability  Conit  represents for the number of available seats  At a state of the system  Committed value of the number of available seats: 300  At a replica:  the number of available seats is 350  The number of seats currently booked by users (not committed yet): 100  Numerial error:  Order error:  Staleness 11 50 100

12. 12

13.  The continuity of conit-based CCM  (numerical error, order error, staleness)  Strict consistency models: (0,0,0)  Optimistic consistency models: (∞, ∞, ∞)  Real values for the parameters achieve the continuity  The level of service consistency is adjusted flexibly by changing (numerical error, order error, staleness)  Each replica can have its own independent consistency level for a conit. This allows the system to route client requests to replicas with appropriate consistency bounds on a per-request basis  In the airline reservation system, requests from ”preferred” clients may be directed to a replica that maintains higher consistency levels (reducing the probability of an inconsistent access) 13

14.  AffectConit(): how each write affects the return value of a conit F. The system can then infer the return value of F by summing all accumulated numerical weights  DependonConit(): declare the required consistency level on each access 14

15.  Continuous consistency programming  Crystallise high-level application consistency semantics. ”what does 90% consistency mean?”  Conit, numerical error, order error, staleness  AffectConit()  DependonConit()  TACT: A middleware layer 15

16.  Can conit-based CCM model the consistency of all (most) services?  Difficulties  The number of conits changes rapidly?  Adaptability  Haifeng Yu, Amin Vahdat, ”The Costs and Limits of Availability for Replicated Services”, ACM Trans. Comput. Syst. 24(1): 70-113 (2006) 16

17. 17

18.  DependonConit(): declare the required consistency level on each access  Another approach to express different levels of consistency  Defines basic consistency conditions  A formal framework that enables composing a collection of consistency conditions into a more restrictive one  Proves that a given implementation of a high level condition is correct  Can be used to devise flexible, composable implementation of consistency conditions 18

19.  Definitions and conventions  Client processes: p1, p2, …, pn  An operation: op (read, write)  An invocation event: inv(op)  A corresponding response event: resp(op)  A history (H): a sequence of invocation and response events  A sequential history: each invocation event is immediately followed by the matching response event  A serialization (S) of a history H: a sequential history containing all the operations of H  A sequential history H to be legal if the value returned by each read operation r in H is the same as the value written by the last write operation that accesses the same object before r in H 19

20.  Composability framework  Consistency condition (consistency): a set of restrictions on allowed histories (level of consistency)  Eventual Propagation: every write operation by any process must be seen by all other processes  Strong consistency conditions  require the existence of some special legal serialization of the history  All processes view the operations in the same logical order  Weaker conditions  only require the existence of one special serialization for each process  Each process views the operations in a different logical order  A history preserves a consistency condition by requiring the existence of a serialization set that obeys certain ordering restrictions 20

21.  Basic consistency conditions  Read Your Writes (for a local history)  for every two operations write and read in the local history  If write precedes read, the return value of read is the value updated by write  FIFO of Reads (for a local history)  for every two operation read1 and read2 in the local history  If read1 precedes read2, the return value of read2 is ”newer” or equal to the return value read1 21

22.  Basic consistency conditions  FIFO of Writes (for a local history)  For every two operations write1 and write2 in the local history  If write1 precedes write2, the object is updated by write1 and then write2  Reads Before Writes (for a local history)  For every two operations read and write in the local history  If read precedes write, the return value of read is the value not updated by write 22

23.  Basic consistency conditions  Local Causality (for a local history)  For every three operations write1, read, and write2 in which read and write2 are in the local history (write1 is not)  If the return value of read is a result written by write1 and read precedes write2, the object is updated by write1 and then write2  Total order 23

24.  An example of useful compositions  Any history that is consistent with respect to Total Order and Reads Before Writes is also consistent with respect to Local Causality  An application  There are several simple clients and a few supervisor clients. Each simple client reads and writes to different objects than the other simple clients. Supervisors can read all objects  Simple clients: FIFO of Writes and Read Your Writes  Supervisors: FIFO of Reads 24

25.  In an deal system  Each basic condition will be implemented as a layer of code  When a given application needs a specific high- level consistency condition, it could simply pick the layers that implement the collection of basic conditions from which the high-level condition is composed of 25

26.  Difficulties?  Implementation compositions of conditions  In compile time?  On-the-fly?  Does a complete set of basic consistency conditions to generate any consistency condition exist? 26

27.  Conit-based CCM  The composability of consistency conditions  Adaptability and Dependability 27

28.  Section 7.5.1 in TvS  "Design and Evaluation of a Conit-based Continuous Consistency Model for Replicated Services." ACM Transactions on Computer Systems, by Yu and Vahdat  "On the composability of consistency conditions“ Information Processing Letters by Friedman, vitenberg, and Chockler  ”The Costs and Limits of Availability for Replicated Services”, ACM Trans. Comput. Syst. 24(1): 70-113 (2006), by Haifeng Yu, Amin Vahdat 28