Latency-aware leader election

Abstract

Experimental studies have shown that electing a leader based on measurements of the underlying communication network can be beneficial. We use this approach to study the problem of electing a leader that is eventually not only correct (as captured by the Ω failure detector abstraction), but also optimal with respect to the transmission delays to its peers. We give the definitions of this problem and a suitable model, thus allowing us to make an analytical analysis of the problem, which is in contrast to previous work on that topic.

Leader Election for Replicated Services Using Application Scores

“…The results show that our request latency metrics can in some cases significantly diverge from consensus latency, which is the metric optimized by leader election algorithms such as the one of Santos et al [17]. Depending on the particular setting, selecting an appropriate scoring function can elect leaders that provide up to 50% lower request latencies than arbitrarily elected leaders, while recovery-oriented oracles can elect leaders that provide minimal recovery times.…”

“…To solve consensus, it is necessary and sufficient to elect a leader [5,7]. The problem of leader election has been broadly investigated from many viewpoints, from minimizing the synchrony and reliability requirements imposed on links [2,15], to optimizing the Quality of Service of failure detection [8], to electing the leader that can minimize the latency of solving consensus [17]. The ZooKeeper atomic broadcast protocol (Zab) implements a variant of the atomic broadcast primitive called primary order atomic broadcast [13].…”

“…Santos et al [17] presented a rotating leader election that finds an optimal leader after a series of intermediate elections. In systems like ZooKeeper, this solution can be very costly because each reelection incurs additional recovery costs, even when servers have the same history, e.g., snapshot reading, connection establishment, and the first phase of the consensus protocol.…”

“…In some deployments, most clients are in one data center and electing a leader in the data center where most client requests arrive minimizes the request latency observed by clients. For some applications, such an optimization can be even more important than optimizing recovery time, as previously done by ZooKeeper, or the time required to terminate consensus, as with existing leader election algorithms such as the latency-aware algorithm of Santos et al [17].…”

Improving Wide-Area Replication Performance through Informed Leader Election and Overlay Construction

“…Instead of using their algorithm, we decided to modify a simpler algorithm: the rotating leader election as described by Aguilera et al [1]. The same algorithm has already been modified to elect an optimal leader by Nuno et al [12]. Nevertheless, their algorithm exclusively focus on latency minimization providing no configurability.…”