Performance Analysis of the novel Virtually Synchronous Group Communication Service

1. Performance Analysis of the novel Virtually Synchronous Group Communication Service … VS GCS

2. Group Communication -- Useful “Building Block” • Group Abstraction • processes interact in a group • dynamic: fail/join/partition/merge • Group Multicast • enforces certain ordering and reliability • Group Membership • tells each process who it is connected to: current “view” • Virtual Synchrony • integrates Group Multicast and Group Membership • synchronizes message and view deliveries

3. Example: Group Communication

4. Virtual Synchrony • Synchronization of Messages and Views: • Before delivering new view v to its client, process has to synchronize with others • Powerful abstraction for replication • Semantics: VS [Birman, Joseph 87], EVS, SVS Processes that transition together through same views, deliver same sets of messages.

5. Example: Virtual Synchrony VS algorithm executes: r learns it missed m and delivers m

6. Performance Challenges in WANs • Clients care how fast the GCS delivers new views after a network event (NE) occurs • After NE: MBRSHP forms view, VS synchronizes NE View Delivered VS Algorithm View Formation • Existing systems (were designed for LANs): • Both MBRSHP and VS several rounds of msg exchange • Once begin, unable to respond to NEs -- “obsolete views” • They are inappropriate for WANs, which typically have • high and unpredictable message latency, • frequent connectivity changes

7. Novel Algorithm for Virtual Synchrony[Keidar, Khazan 00] • Single message exchange among procs of new view • In parallel to MBRSHP forming the new view • No obsolete views -- reacts to membership changes NE View Delivered VS Algorithm View Formation • Scalable architecture: MBRSHP is decoupled from VS • Formal modeling: specs, algs, safety & liveness proofs • Can work with novel MBRSHP service[Keidar, et al 00] • View delivery in one message exchangein almost all cases

8. Challenges of Formal Performance Analysis • The GCS system is a composition of building blocks • Multicast service, Membership service, VS end-points • Clients care about performance of the whole system • How fast after a network event new views are delivered • But our design focuses on the novel VS algorithm • Reduces the number of communication rounds to one, which are in parallel with MBRSHP forming new view • How can analyze improvement due to novel VS? • If MBRSHP and MCAST services are only specified • How to compare performance with existing GCSs? • If existing GCSs blend MBRSHP and VS together

9. Performance Analysis: The Plan • Analyze the VS layer only • in terms of its inputs • and timing assumptions • State reasonable performanceproperties of MBRSHP and MCAST • Compose  with  to yield conditional Corollaries • “Provided  holds, the whole system performs like this…” • Next step: Compare  with existing VS GCSs

10.  Analysis of the VS layer • Assume component C stabilizes after some time on: • MBRSHP delivers same views to VS end-points of C Let Tmax[MBRSHP.start] and Tmax[MBRSHP.view] be last events • MCAST provides reliable and timely communication Let  be message latency • Liveness proof establishes that VS delivers views • Upper-bound the times when VS outputs views • In terms of the times when MBRSHP outputs occur • Conditional on timing assumptions (local speed: ) Tmax[MBRSHP.start] +  + x +  Tmax[MBRSHP.view] Tmax[VS.view]  max

11. Illustration One msg latency  + x Tmax[VS.view] view VS Algorithm NE last start start view first last last MBRSHP algorithm Tmax[MBRSHP.start] Tmax[MBRSHP.view]

12.  Bounds on MBRSHP NE Reasonable bounds on the times of MBRSHP events Tmin[MBRSHP.start] Tmax[MBRSHP.start] Tmax[MBRSHP.view] start start view One all-to-all msg latency ~One msg latency  ~One msg latency  first last last MBRSHP algorithm These bounds correspond to Fast-Path of [Keidar, et al 00] observed empirically in almost all cases

13.  Compose MBRSHP and VS bounds One msg latency  + x Bounds on the whole system, conditional on MBRSHP view VS Algorithm NE Tmax[VS.view] Tmin[MBRSHP.start] Tmax[MBRSHP.start] Tmax[MBRSHP.view] last start start view One all-to-all msg latency ~One msg latency  ~One msg latency  first last last MBRSHP algorithm

14.  Next Step: Comparison with existing GCSs • Existing VS algorithms all use similar ideas • Pre-agree on common identifiers. Deliver obsolete views • Formulate a high-level description of existing algs • Requires looking at inherent costs (e.g., all-to-all latency) • Analyze under the same scenarios and conditions • Express performance advantages due to: • Faster VS algorithm that doesn’t pre-agree on common ids • Not wasting time on obsolete views