Optimistic Virtual Synchrony Jeremy Sussman IBM T J

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

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 Optimistic Virtual Synchrony 2

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

Group Communication Systems (2) p 1 p 2 time V 1 {p 1, p 2, p 3} p 3 • 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 V 2 {p 1, p 2} Optimistic Virtual Synchrony • If p 1 sends a message m while in v 1, then m is delivered in v 1 4

Why Properties Imply Blocking p 1 p 2 time V 1 {p 1, p 2, p 3} p 3 • 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? Optimistic Virtual Synchrony 5

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 Optimistic Virtual Synchrony 6

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 Optimistic Virtual Synchrony 7

OVS Implementation • Sender side: – All messages sent in a view that has become stale are sent optimistically • Enhanced by a Message. Condition 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 Message. Condition is true • If more optimistic messages are received, treat them as if they were at the end of the queue Optimistic Virtual Synchrony 8

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) Optimistic Virtual Synchrony 9

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) Optimistic Virtual Synchrony 10

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

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

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

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 Optimistic Virtual Synchrony 14

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 Optimistic Virtual Synchrony 15