Adaptive Indulgent Consensus

Abstract

Due to their fundamental role in the design of faulttolerant distributed systems, consensus protocols have been widely studied. In particular, design and performance issues of indulgent consensus is a research topic that has gained considerable attention. Most of these protocols are asymmetric in the sense that different participants can assume different roles during the execution of the protocol. Usually, there is a process that assumes a "special" role and the others cooperate with it to finish the computation. However, the asymmetric structure of indulgent consensus protocols has a performance pitfall, specially when processes and communication channels are subject to considerable variability in load. The problem is that such protocols use an a priori agreed process ordering to select the process to perform the "special" role. We advocate that adaptive indulgent consensus protocols can be constructed by the introduction of an adaptive process ordering module. In this sense, it is proposed a generic implementation for this module. Based on this generic module we provide implementations of both 3S-and Ω-based adaptive indulgent consensus protocols. Further, we investigate their performance by means of simulation and real experiments over a widely distributed system. The experimental results obtained show that the adaptive consensus protocols can outperform their non-adaptive counterparts in as much as 50%.

Latency-aware leader election

“…A local latency detector module periodically outputs an n-dimensional vector Li at each process i, where Li[j] represents the estimate of the round-trip time between process i and process j. In contrast to previous approaches [7], there is no global oracle that provides global latency information to every process, but every process gets only an estimate of the round-trip delays to its peers. However, since even after GST round-trip delays may change, the output of the latency detector has only limited accuracy.…”

“…The idea of taking link latencies into account for leader election has been considered in [9,7,8]. In [9], an adaptive consensus algorithm is given.…”

“…The initial coordinator is chosen to be a "fast" process based on measurements of the time each process takes to answer when it is a coordinator. In [7], the notion of "process order" is used to convey information about the link latencies. For a consensus algorithm based on 3S and the rotating coordinator paradigm, the idea is to use the process order (instead of the process id) for selecting the successive coordinators (which requires global agreement on the matrix of latencies).…”

Leader Election for Replicated Services Using Application Scores

“…Sampaio and Brasileiro [16] propose a configurable solution for id-based elections by using a process-ordering oracle. This additional component changes the a priori order of processes at run-time based on application metrics (but the authors only evaluate consensus latency).…”

“…After querying the oracle, servers share their scores, encapsulated in election messages, and try to elect the server with the highest score. POLE simply broadcasts scores and does not require reaching agreement on the ordering of servers before starting leader election, as required in the work of Sampaio and Brasileiro [16].…”