1 / 15

Optimistic Virtual Synchrony

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

maryam-ryan
Download Presentation

Optimistic Virtual Synchrony

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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. time Group Communication Systems (1) p1 p2 p3 • 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 V1 {p1, p2, p3} V2 {p1, p2} V3 {p3} V5 {p1, p2, p3}

  4. time Group Communication Systems (2) p1 p2 p3 • Reliable Multicast • Messages sent to group • Same View Delivery • If p1 delivers m while in v1 and p2 delivers m,then p2 delivers m in v1 • Sending View Delivery • If p1 sends a message m while in v1,then m is delivered in v1 V1 {p1, p2, p3} V2 {p1, p2}

  5. time Why Properties Imply Blocking p1 p2 p3 • 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? V1 {p1, p2, p3}

  6. 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. 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. 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. 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. 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. time Message Lifecycle p1 p2 server server Message Transmission Time Pre-send Pre-delivery Pre-delivery Pre-send ~ 90 microseconds Wire-time ~1000 microseconds Pre-delivery ~ 40 microseconds ------------------------------------- Total ~1130 microseconds

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

  13. OVS Performance Benefits Average Time to Deliver Messages After View Change Time in Microseconds Messages delivered

  14. 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. 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 toall messages being delivered in subsequent view • Has low overhead

More Related