Optimistic Virtual Synchrony Jeremy Sussman - IBM T.J.Watson Idit Keidar – MIT LCS Keith Marzullo – UCSD CS Dept.

2 Optimistic Virtual Synchrony Overview of Talk Group Communication Services (GCS) –Group Membership and Reliable Group Multicast and why some properties force processes to block Optimistic Virtual Synchrony (OVS) –Concept –Evaluation Related Work Conclusions

3 Optimistic Virtual Synchrony Group Communication Systems (1) Group Membership –Processes organized into groups –Particular memberships stamped as views In partitionable system, views can be concurrent Views provide a form of Concurrent Common Knowledge about system p1p1 time p2p2 p3p3 V1 {p 1, p 2, p 3 } V2 {p 1, p 2 } V5 {p 1, p 2, p 3 } V3 {p 3 }

4 Optimistic Virtual Synchrony Reliable Multicast –Messages sent to group –Same View Delivery If p 1 delivers m while in v 1 and p 2 delivers m, then p 2 delivers m in v 1 –Sending View Delivery If p 1 sends a message m while in v 1, then m is delivered in v 1 Group Communication Systems (2) p1p1 time p2p2 p3p3 V1 {p 1, p 2, p 3 } V2 {p 1, p 2 }

5 Optimistic Virtual Synchrony Assume that message delivery takes d Let processes send a message every t < d When can a new view be installed… –without violating Sending View Delivery? –without dropping messages? Why Properties Imply Blocking p1p1 time p2p2 p3p3 V1 {p 1, p 2, p 3 }

6 Optimistic Virtual Synchrony Observations Many problems are caused by stale views –Processes block when a view is stale –A sending process cannot know if the view will be stale before a message is delivered –For many applications, a message delivered in a stale view is useless Many applications do not require exact semantics of Sending View Delivery –State transfer not required for splitting –Leader election not required for joins

7 Optimistic Virtual Synchrony OVS: The Idea Inform processes of stale views –Give an “educated guess” of subsequent view (called the optimistic view) Allow processes to send optimistic messages that will be delivered in subsequent view –But deliver or drop message based on some predicate that the application provides

8 Optimistic Virtual Synchrony OVS Implementation Sender side: –All messages sent in a view that has become stale are sent optimistically Enhanced by a MessageCondition predicate Receiver side: –Store in a queue all optimistic messages received before a view change –On new view, deliver all optimistic messages for which the MessageCondition is true If more optimistic messages are received, treat them as if they were at the end of the queue

9 Optimistic Virtual Synchrony Message Conditions Separation of mechanism and policy –Provided by the application –Expressed as a predicate over the previous view, subsequent view, and optimistic view Examples: –Leader election ( leader in subsequent_view) –Need for state transfer (previous_view subset subsequent_view)

10 Optimistic Virtual Synchrony Evaluation of OVS Implementation of OVS on top of Transis –Comparison to a blocking system and to one that does not provide Sending View Delivery –Measurement of overhead of OVS Examination of applications that can benefit from the OVS semantics –(see proceedings)

11 Optimistic Virtual Synchrony Message Lifecycle Pre-send Pre-delivery Message Transmission Time Pre-send~ 90 microseconds Wire-time~1000 microseconds Pre-delivery~ 40 microseconds Total~1130 microseconds p1p1 time server p2p2

12 Optimistic Virtual Synchrony OVS Overhead Time in Microseconds Regular messages Optimistic messages with retransmission Optimistic messages with retransmission Sender side Receiver side Processing Time, pre-delivery

13 Optimistic Virtual Synchrony OVS Performance Benefits Average Time to Deliver Messages After View Change Time in Microseconds Messages delivered

14 Optimistic Virtual Synchrony Related Work Optimistic Atomic Broadcast [Pedone, Schiper] +Uses optimism for total order +Complementary to our approach Non-blocking light-weight groups [Amir et al; Dolev, Malki] +Scales well +Provides fast view delivery –Does not provide Sending View Delivery Property –Often allows messages to span more than one view (problematic for state transfer, other applications) Weak Virtual Synchrony [Friedman, van Renesse] +Eliminates blocking +Optimized for membership translation –Does not provide same level of policy/mechanism split –May require extra views to be delivered by system

15 Optimistic Virtual Synchrony Conclusions Optimistic Virtually Synchrony –Uses a very simple form of optimism Receiving processes never need to rollback from optimistic messages Sending process informed of dropped messages –Provides applications with useful properties Policy/Mechanism split on delivery semantics –From Sending View Delivery to all messages being delivered in subsequent view –Has low overhead

16 Optimistic Virtual Synchrony Common Properties of GCSs Virtual Synchrony –If p 1 and p 2 are both in v 1 and v 2 and p 1 delivered a message m in v 1, then p 2 delivered m in v 1 Guaranteed Self-Delivery –If p 1 sends a message m, then p 1 will eventually deliver m or crash Sending View Delivery –If p 1 sends a message m while in v 1, then m is delivered in v 1