hovercraft: achieving scalability and fault-tolerance for

HovercRaft: Achieving Scalability and Fault-tolerancefor microsecond-scale Datacenter Services

Marios KogiasEPFL, Switzerland

Edouard BugnionEPFL, Switzerland

AbstractCloud platform services must simultaneously be scalable,meet low tail latency service-level objectives, and be resilientto a combination of software, hardware, and network fail-ures. Replication plays a fundamental role in meeting boththe scalability and the fault-tolerance requirement, but issubject to opposing requirements: (1) scalability is typicallyachieved by relaxing consistency; (2) fault-tolerance is typ-ically achieved through the consistent replication of statemachines. Adding nodes to a system can therefore either in-crease performance at the expense of consistency, or increaseresiliency at the expense of performance.

We propose HovercRaft, a new approach by which addingnodes increases both the resilience and the performance ofgeneral-purpose state-machine replication. We achieve thisthrough an extension of the Raft protocol that carefully elim-inates CPU and I/O bottlenecks and load balances requests.Our implementation uses state-of-the-art kernel-bypass

techniques, datacenter transport protocols, and in-networkprogrammability to deliver up to 1 million operations/secondfor clusters of up to 9 nodes, linear speedup over unreplicatedconfiguration for selected workloads, and a 4× speedup forthe YCSBE-E benchmark running on Redis over an unrepli-cated deployment.

ACM Reference Format:Marios Kogias and Edouard Bugnion. 2020. HovercRaft: AchievingScalability and Fault-tolerance for microsecond-scale DatacenterServices. In Fifteenth European Conference on Computer Systems(EuroSys ’20), April 27–30, 2020, Heraklion, Greece. ACM, New York,NY, USA, 17 pages. https://doi.org/10.1145/3342195.3387545

1 IntroductionWarehouse-scale datacenters operate at an impressive de-gree of availability and information consistency despite con-stant component failures at all layers of the network, hard-ware and software stacks [8], constrained by the well-knowntheoretical tradeoffs between consistency, availability, and

Permission to make digital or hard copies of part or all of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contactthe owner/author(s).EuroSys ’20, April 27–30, 2020, Heraklion, Greece© 2020 Copyright held by the owner/author(s).ACM ISBN 978-1-4503-6882-7/20/04.https://doi.org/10.1145/3342195.3387545

partition-tolerance [12]. This is the result of the careful de-composition of modern applications into components thateach exhibit well-defined consistency, scalability, and avail-ability guarantees. Each component is further configured tomatch specific service-level objectives, often expressed interms of tail latency [26, 27].

Replication plays a key role in achieving these goals acrossthe entire spectrum of tradeoffs. First, scalability is com-monly achieved by managing replicas with relaxed consis-tency and ordering requirements [12, 27]. This is commonlydeployed as a combination of caching layers, data replication,and data sharding [27]. Second, replication is also the foun-dation for fault-tolerance, whether achieved through fault-tolerant hardware and process pairs [41] or more commonlyin datacenters through distributed consensus protocols ofthe Paxos and Raft families [51, 60–63, 76, 77]. Such proto-cols ensure fault-tolerance through state machine replication(SMR) [91], in which a distributed system with n nodes canoffer both safety and liveness guarantees in the presence ofup to f node failures as long as n ≥ 2 × f + 1 (under somenetwork assumptions [36]).

Scalability and fault-tolerance are classically opposed, eventhough both rely on the same design principle of replication.Adding nodes can improve scalability with relaxed consis-tency and can lead to very large deployments within andacross datacenters (e.g., content delivery networks). On theflip side, adding nodes to a consensus system can improvefault tolerance but harm performance. In practice, most de-ployments of SMR are limited to small cluster sizes, e.g.,three or five replicas [14, 20, 46] as deployments of SMRwith more than a handful of nodes reduce performance andare considered too expensive [10, 46].Figure 1a shows the leader node bottlenecks for a classic

SMR deployment using Raft: (1) the leader acts as the RPCserver for all clients; (2) the leader must communicate indi-vidually with each follower to replicate messages and ensuretheir ordering. Figure 1a also illustrates that a user-definedapplication that operates on the state machine must be mod-ified to accept messages delivered by Raft (rather than use amore conventional RPC API transport).

In this work we focus on stateful datacenter applicationsthat require fault-tolerance, low-latency, and scalability. Weask two main questions: (1) Can we build fault-tolerant ser-vices in an application-agnostic, reusable manner, i.e., take anexisting application (with deterministic behavior) and have

https://doi.org/10.1145/3342195.3387545

https://doi.org/10.1145/3342195.3387545

EuroSys ’20, April 27–30, 2020, Heraklion, Greece Marios Kogias and Edouard Bugnion

Clients

RPCF

F

L

proxy

Raft msg

(inc req)

(a) Scalability bottlenecks of Raft.

L

F

F

R2P2

Reply

R2P2

Request

Raft msg

(meta only)

Clients

(b) HovercRaft, with optional in-network acceleration using a P4 ASIC.

Figure 1. Eliminating bottlenecks of SRM. Illustration on a 3-node cluster.

it transparently utilize a SMR protocol? (2) Can we take ad-vantage of the replication present for fault-tolerance to alsoimprove the performance of the application?Figure 1b illustrates the key contributions of our system,

HovercRaft, and its optional extension (HovercRaft++). Weanswer the first question primarily by integrating the Raftprotocol [77] directly within R2P2 [58], a transport protocolspecifically designed for in-network policy enforcement overremote procedure calls (RPC) inside a datacenter.We answer the second question by first extending Raft

to separate request replication from ordering and using IPmulticast and in-network accelerators (e.g., a P4 ASIC) toconvert leader-to-multipoint interactions into point-to-pointinteractions. These enhancements reduce the performancedegradation associated with larger clusters. We complete theanswer to the second question by using R2P2’s fundamentalmechanism for in-network operations, which allows thedestination IP address of an RPC request (as set by the client)to differ from the source IP of the reply. This allows the loadbalancing of client replies, as well as of the execution of read-only, totally-ordered requests. These changes reduce the I/Oand CPU bottlenecks and allow HovercRaft to deliver evensuperior performance to an unreplicated (and therefore notfault-tolerant) deployment of the same application.

We make the following contributions:

• We integrate Raft [77], a widely used consensus algo-rithm, with R2P2 [58], a transport protocol specifically de-signed for datacenter RPCs, to offer fault-tolerance transpar-ently to applications.• We propose HovercRaft, a set of Raft protocol extensionsthat leverage the built-in features of R2P2 to systematicallyeliminate I/O and CPU bottlenecks associated with SMR,without changing the core of the algorithm, thus its livenessand safety guarantees.• We further take advantage of in-network acceleratorsnow commonly found in datacenter switches to statelessly

offload low-level message processing, thus eliminating scal-ability bottlenecks due to cluster size.

Our implementation of Raft relies on kernel-bypass todeliver up to 1M ordered operations per second in a seriesof microbenchmarks on a 3-node cluster, which correspondsto a 4× improvement over the state-of-the-art [31, 66, 85].Our implementation of HovercRaft++ delivers 1M orderedoperations for clusters of up to 9 nodes. The careful elimina-tion of CPU and IO bottlenecks allows almost linear speedupover the unreplicated configuration for selected workloads.Our evaluation of Redis running YCSB-E shows that Hover-cRaft can deliver up to 142k YCSB-E operations per secondon a 7-node cluster in ≤ 500µs at the 99th percentile, a 4×performance increase over the unreplicated case.

The HovercRaft codebase is opensource and can be foundat https://github.com/epfl-dcsl/hovercraft. The restof the paper is structured as follows: after the necessarymotivation and background (§2), we present the design ofHovercRaft (§3), and its optional extension using in-networkaccelerators (§4). We then identify the common properties ofRaft and HovercRaft, as well as their subtle differences (§5).Finally, we describe our implementation of HovercRaft (§6)and evaluate it using representative applications and work-loads (§7). We describe the related work (§9) and conclude(§10).

2 Motivation2.1 Replication for Fault-ToleranceSMR systems such as Chubby [14], Zookeeper [46], andetcd [33] manage the hard, centralized state at the coreof large-scale distributed services, e.g., Kubernetes [18] andRamCloud [81] use Raft/etcd for state management; AzureStorage [16], Borg and Omega [13], Ceph [96], and GFS [38]all have a built-in Paxos implementation to manage storagemetadata and cluster state. Because of their complexity, SMRsystems traditionally implement simple abstractions, such

HovercRaft: Achieving Scalability and Fault-tolerance for microsecond-scale Datacenter Services EuroSys ’20, April 27–30, 2020, Heraklion, Greece

as a key-value store or a hierarchical namespace, exposed toclients via a protocol proxy (e.g., http).

Complex and stateful applications, such as databases, typ-ically depend on application-specific solutions. For example,they replicate state via cluster configurations (e.g., active-passive database pairs) that can suffer from split-brain sce-narios or require manual intervention in case of failures [4].These stateful applications come with critical performanceadvantages as they reduce communication roundtrips andenable complex, atomic, transactional operations on state.

The separation of concerns between stateless applicationsand stateful services exposing simple abstractions comeswith extra cost and complexity, due to the marshalling ofRPCs, multiple roundtrips due to abstraction mismatches,and added network latency [1]. Approaches such as Splin-ter [59] and Redis user-defined modules [89] help bridgethe gap through application-specific abstractions and richersemantics, making a harder case for fault-tolerance, though.As we will show, we advocate for transport protocols

specifically designed for RPCs with integrated SMR function-ality to support applications with rich abstractions.

2.1.1 StateMachine Replication. At the core of all fault-tolerant systems is a variant of a consensus algorithm that isused to implement distributed state-machine replication [91].State machine replication guarantees linearizability, namelyall replicas receive and apply the updates to the statemachinein the same order. Consequently, all replicas in the samegroup behave as a single machine. This field has been thesubject of extensive academic and industrial research bothfrom a theoretical [36, 60, 91] and systems [14, 46, 62, 77]point of view.Most consensus algorithms can be split into two phases:

the leader-election phase, where the participating nodes voteto elect a leader node; and the normal operation. Once aleader is elected, the leader is in charge of selecting one ofthe client requests to be executed and notifies the rest ofthe nodes about its choice. Once the majority of nodes areaware of this choice, the leader can commit and announcethe committed decision, and the request can be executed.Although the terminology (e.g., acceptors and learners

in Paxos vs. followers in Raft) and the specific semanticschange across different implementations, the key point isthat consensus algorithms generally operate in a 2-roundtripcommunication scheme. In the first round-trip the leaderannounces the intention to execute an operation, and in thesecond it announces that the operation is committed, giventhe necessary majority.For the rest of the paper we will focus on Raft [77] and

use Raft terminology. Raft is a consensus algorithm thatdepends on a strong leader and exposes the abstraction of areplicated log. The leader receives client requests, puts themin its log, thus guaranteeing a total order, and replicates thoseto the follower through an append_entries request. The

Client

Leader

Follower 1

Follower 2

Figure 2. Basic communication pattern to execute a clientrequest in a fault-tolerant group of 3 servers. Solid arrowsrefer to messages from and to the client based on the service-specific API, while dotted arrows refer to SMR messages.

followers append them to their logs and notify the leader.Then, the leader can execute the operation and reply to theclient. The above interaction is summarized in Figure 2. Theleader notifies the followers for its committed log index inthe next communication round. The choice of Raft is crucialfor HovercRaft’s design (§3).

2.1.2 SMR Bottlenecks. We now focus on the normalcase of operation and we identify bottlenecks that mightarise based on the interactions between the clients and thefault-tolerant group of servers, as well as the consensus com-munication pattern inside the fault-tolerant group specifi-cally in the case of Raft.

Leader IO bottleneck for request replication:The leaderis in charge of replicating requests to the followers. Oncethose requests start increasing in size or the number of fol-lowers increases, the transmission bandwidth of the leader’sNIC will become the bottleneck, thus limiting throughput.

Leader IO bottleneck for client replies: The leader mustalso reply to all clients. Depending on the reply sizes, theleader transmission bandwidth can again become a bottle-neck, especially in combination with the replication traffic.

Leader CPU bottleneck for running requests: Since theleader is expected to reply to the client, it must run all clientrequests, even read-only ones. However, this can lead to aCPU bottleneck in the leader if the read-only operationsare expensive. This, for example, can be the case in systemssupporting mixed OLTP and OLAP workloads [88].

Leader packet processing rate: The leader must send re-quests and receive replies from the majority of the followersin order to make forward progress. Increasing quorum sizesincreases the packet processing requirements at the leader.This can both limit the throughput of committed client re-quests if the IOPS becomes a bottleneck, and increase latencybefore hitting the IOPS bottleneck.

2.2 Replication for ScalabilityData replication, either in the form of caching or load bal-ancing between replicated servers, is used to improve thelatency and throughput of data accesses. Replication, though,


improves scalability by trading off either availability or con-sistency, as the CAP theorem suggests [12, 27]. In such repli-cated systems, concurrent accesses and component failureslead to anomalies that must be handled either at the applica-tion layer or by the end-user herself [27].

Replication is therefore the fundamental mechanism usedto offer either scalability or fault-tolerance, but not bothat the same time. Replication for scalability requires com-promises in the consistency model and can at best offerhigh-availability [3].

2.3 Low-latency intra-datacenter interactionsThe core of datacenter communications relies on short µs-scale RPCs [2, 37, 58, 71]. In current datacenters, using stan-dard networking hardware technologies, any two computerscan communicate in ≤ 10µs at the hardware level betweenany two NIC. Such time budget includes the latencies associ-ated with PCI, DMA, copper transmission, optical transmis-sion, and multiple hops through cut-through switches.Recent advances in system software eliminate most soft-

ware overheads by bypassing the traditional networkingstacks. These technologies include kernel-bypass develop-ment kits [29], user-level networking stacks [49, 68, 78],stacks that bypass the POSIX layer [44], protected data-planes [9, 84, 87], and microkernel-based approaches [56, 69].Such stacks support either standard networking protocolssuch as TCP or UDP, protocols specifically designed to accel-erate datacenter RPC interactions [42, 58], or leverage RDMAto directly access and manipulate data [30, 69, 70, 81].

Such proximity fundamentally changes assumptions aboutthe cost of sending messages from applications (clients) tothe nodes of a replicated system, as well as between the nodesthemselves. Approaches such as [58] show that increasingthe number of round-trips can lead to better tail-latency dueto better scheduling.At the same time, the introduction of new non-volatile

memory technologies [79] reduces the access latencies, in-creases throughput [48], and eliminates the traditional bot-tleneck associated with persistent storage, especially whencombined with low-latency networking [28, 97]. In partic-ular, the combination opens up new opportunities for SMRapplications previously presumed to be storage-bound.

3 DesignOur goal is to provide a systematic and application-agnosticway of building fault-tolerant, µs-scale, datacenter services,with similar or better performance to the unreplicated ones.We achieve this by integrating the consensus directly withinthe RPC layer (§3.1) and through a set of extensions to theRaft consensus protocol that do not modify the core algo-rithm, but only go after its CPU and IO bottlenecks. We call

Transport

RPC

App

SMR

Transport

RPC

SRM

Logic

Transport

RPC

App

SMR

(a) Existing Proposals (b) HovercRaft

Figure 3.HovercRaft proposal in terms of layering comparedto existing approaches.

the Raft version with the performance extensions Hover-cRaft. Figure 1b summarizes our design, and in the rest ofthe section we analyze each design choice.

3.1 SMR-aware RPC layerClients interact with stateful servers through RPCs to changeor query the internal server state, making RPCs the natu-ral place to implement a systematic, application-agnosticmechanism for fault-tolerance. In a standard design of afault-tolerant service, clients interact with the nodes of acluster through a standard RPC library that is oblivious toSMR. For example, etcd uses gRPC [42] for this interaction.This protocol layering requires the SMR leader, which re-ceives the initial client RPC, to decode it, re-encode it withinthe SMR protocol for insertion into the consensus log, andfinally forward it to the followers. The selection of the end-point for the client RPC can be done via a stateless loadbalancer which hides the internal IP addresses of the clusterbut does not improve performance since all client requestshave to go through the leader, e.g., the etcd gateway [34].We advocate, instead, to incorporate consensus directly

within an RPC library or a transport protocol, which hasRPC semantics (e.g., gRPC [42] or R2P2 [58]) and to providefault-tolerance at the RPC granularity. Specifically, the SMRlayer becomes part of the RPC layer which forwards RPCrequests to the application layer only after those requestshave been totally ordered and committed by the leader. Doingso can transform any existing RPC service with deterministicbehavior into a fault-tolerant one with no code modifications.

We chose to workwith R2P2 [58] and incorporate Raft [77]within the RPC processing logic. We chose R2P2 as it is atransport protocol specifically designed for datacenter RPCsthat targets in-network policy enforcement and decouplesthe initial request target from the replier. This design choicein R2P2 is crucial for RPC-level load balancing implementedat its core.Figure 3 describes the proposed design in terms of lay-

ering. Unlike previous approaches that incorporate SRMlibraries at the application layer, HovercRaft incorporatesSMR within the same transport protocol that also exposesrequest-response pair semantics, making the solution appli-cation agnostic.Our choice of Raft, instead of a Paxos variant, is driven

by Raft’s strong leader, and the in-order commit mechanism.


In the original Paxos algorithm [60] there can be a differentleader in each consensus round, thus limiting the potentialfor optimization due to centralized choice. Unlike Paxos, Raftis a consensus algorithm that depends on a strong leader incharge of ordering and replicating client requests across allfollowers, with a global view of all the nodes participatingin the fault-tolerant group. Our goal is to take advantage ofthe global cluster view at the Raft leader in conjunction withR2P2’s load balancing capabilities to go after the SMR bottle-necks. Although the above requirement is also satisfied byMulti-Paxos [61], Raft’s in-order commit logic significantlysimplifies the design of in-network acceleration for Hover-cRaft. We specifically target scalability bottlenecks, and wenote that our design does not improve upon Raft’s two net-work roundtrip approach, unlike 1-roundtrip proposals [66].

3.2 Separating RPC Replication from OrderingThe first Raft bottleneck of §2.1.2 is the leader IO transmis-sion bottleneck due to request replication. With n nodes inthe cluster, a mean RPC request size of Sr eq , and a link ca-pacity of C , Raft cannot serve more than C/((n − 1) ∗ Sr eq)requests per second.HovercRaft achieves fixed-cost SMR independent of the

RPC request size. We solve the bottleneck by separatingreplication from ordering and leverage IP multicast to repli-cate the requests to all nodes. Instead of targeting a specificserver, clients inside the datacenter send requests to a mul-ticast group that includes the leader and the followers, or amiddlebox that is in charge of assigning the correct multicastIP. All nodes in the group receive client requests withoutthe leader having to send them individually to each of thefollower nodes.Obviously, IP-multicast does not guarantee ordering or

delivery. As with Raft, the leader decides the order of clientrequests. R2P2 provides a way to uniquely identify an RPCbased on a 3-tuple (req_id, src_port, src_ip) and HovercRaftrelies on this metadata built into the protocol. Upon recep-tion of an RPC request, the leader immediately adds it to itslog, while followers insert the RPC into a set of unorderedrequests. The leader then communicates fixed-size requestmetadata to the followers. Followers retrieve the RPC re-quests from the unordered set based on the request metadataand add them in their log. Therefore, in the common case,when no packet loss occurs, the leader is only in charge ofordering requests and not data replication.

3.3 Load balancing repliesThe second bottleneck mentioned in §2.1.2 refers to the costof replying to clients from the leader. We observe that re-plying to the client can be load balanced between the leaderand the followers as long as the followers keep up withthe request execution. By doing so, the I/O bottleneck dueto client replies could expand from C/Sr eply RPS to almostn ∗ C/Sreply RPS, where C is again the link capacity and

term: 2

replier: 2

type: RW

data:

term: 2

replier: 1

type: RW

data:

term: 2

replier: 0

type: R

data:

term: 2

replier: ?

type: RW

data:

Commit IdxApplied Idx Announced Idx

Log Idx

Figure 4. A view of the leader log. Each log entry includesthe term, the designated replier, a pointer to the client re-quest, and whether it is read-only. The replier is set only forthe entries up until the announced_idx.

Sr eply is the reply size. For example, a server with a 10GNIC can serve up to approximately 400k requests per second,when the replies are 2 MTUs (we assume an MTU of 1500bytes). Load balancing those replies among 3 replicas canimprove application throughput by 3×. It also reduces theleader CPU load due to network protocol processing.

The leader can decide which node replies to the client forwhich request, given its global view of the cluster. Accordingto the semantics of the vanilla Raft algorithm, a leader sendsan append_entries message to the followers that includesthe client requests and the leader commit index, so thatfollowers can update their own commit index. There is noexplicit commit message per log entry. As a result, the leaderhas to designate the replier when announcing the requestorder to the followers, and not after committing them.HovercRaft extends the information stored in the Raft

log with a replier field. The leader sets the replier fieldimmutably for each entry before sending the particular entryto any follower for the first time. When a log entry is latercommitted, each Raft node can run the RPC, but only the onewith the matching replier identifier replies to the client. Forthis, we use a built-in feature of R2P2 that allows the sourceIP address of the RPC reply to differ from the destination IPaddress of the request.The load balancing of replies creates a window of uncer-

tainty between the append_entries request that communi-cates the designated replier, and the commit point, duringwhich the designated replier can fail, and as a result the clientwill not receive a reply. Note that introducing this windowdoes not affect the correctness of the SMR algorithm, as itis consistent with Raft’s semantics that do not guaranteeexactly-once execution, and can lead to missed replies. Notealso that clients may receive their replies in a different orderthan in the log; this is not, however, different than Raft.

3.4 Bounded QueuesWe rely on another design idea introduced in R2P2, boundedqueues, to minimize the potential visible impact of a partic-ular node failure to clients to at most B lost replies. R2P2’sJoin-Bounded-Shortest-Queue was designed as a load balanc-ing policy to mitigate tail latency across stateless servers [58].


Join-Bounded-Shortest-Queue splits queueing between alarge centralized queue and distributed bounded queues, oneper server. The rational behind this policy is to delay del-egating requests to a specific server queue in anticipationof better scheduling, approaching the performance of theoptimal single queue. HovercRaft delays the reply node as-signment to bound the number of lost replies in the case ofnode failure.Specifically, HovercRaft caps the quantity of announced

entries from the leader’s log relatively to the applied index,thus bounding the amount of assigned but not applied op-erations. Figure 4 describes the different indices on the log:(1) the leader inserts entries at log_idx, the head of the logwithout determining yet which node will send the reply;(2) the leader selects the node in charge of replying to theclient and updates the announced_idx accordingly; (3) thecommit_idx represents the point upon which consensus hasbeen reached; (4) the applied_idx represents the point uponwhich operations have been applied to the state machine.Each follower also has its own set of applied_idx, commit_-idx, and log_idx indices on its local log. Announced_idx isrelevant only for the leader. Followers communicate theirapplied_idx to the leader as part of the append_entriesreply.For every node there is a bounded queue of reply assign-

ments to that node between its applied_idx and the leader’sannounced_idx. The leader respects the invariant of thebounded queue at node selection time, i.e., when moving an-nounce_idx: nodes with too many operations left to applyare not eligible for receiving additional work. This obviouslyincludes the case when the node has failed and its applied_-idx does not progress. Thus, choosing nodes based on thebounded queues minimizes the risk of selecting a failed nodeand eventually losing client replies.We note that respecting the bounded queue invariant

never affects liveness. When no node is eligible for desig-nated replier, the leader simply waits either for the applica-tion in the leader node to make progress and selects itself asa replier, or an append_entries reply from a follower thatwill make this follower eligible to reply.

3.5 Load balancing Read-only OperationsThe third bottleneck of §2.1.2 is the leader CPU bottleneck.We observe that many RPCs only query the state machinebut do not modify it. Such read-only requests still need tobe placed in the Raft log and ordered to guarantee strongconsistency, but do not need to be executed by all nodes. Theload balancing design of §3.3 therefore naturally extendsto the CPU for read-only operations, and can increase theglobal CPU capacity of the system. Clients tag their requestsas read-only as part of the metadata of the R2P2 RPC. Thisinformation is also kept in the Raft log and propagated to thefollowers (see Figure 4). It follows that all requests remain

totally ordered by Raft, but only the designated replier nodeexecutes a read-only query.Read leases [40], which are an alternative solution for

read-only requests, were initially proposed for Paxos [17]and also used in Chubby [14] and Spanner [20]. In this ap-proach, read-only operations run on the leader without run-ning consensus for them. However, this increases the CPUload and traffic on the leader. Megastore [5] grants leases toevery replica for different read operations, but requires com-municating with every replica to perform a write request.Quorum leases [73] also load balance read-only requestsamong different nodes, but assume an application-specificway of detecting read-write dependencies and do not matchour application agnostic requirements. Finally, there is alsothe choice of not ordering read operations, acknowledgingthe risk of returning stale replies [32]

3.6 Join-Bounded-Shortest-QueueBounded queues are necessary to limit the lost client repliesup to the queue bound, but can also help improve the end-to-end request latency, especially in cases where read-onlyrequests have high service time variability. Once the leaderdecides to announce more log entries, identifies the eligiblefollowers, and has to select which follower will reply to theclient. One option is random choice among eligible nodes.Another one is to leverage R2P2’s Join-Bounded ShortestQueue (JBSQ) policy [58].

In HovercRaft, the leader maintains the queue depth of re-quests to be executed on each node. This counter is increasedevery time the leader assigns a request and decrementedwhen followers reply to the leader. The JBSQ policy loadbalances the requests based on the known queue depths, asthis is known to improve tail-latency compared to a randomselection [58], by choosing the shortest among the boundedqueues. The queue of a follower that is assigned to run a longread-only request will fill up while the node is busy servingthe request and that will prevent the leader from assigningmore work to that node. Preferring the other less loadednodes is expected to improve the tail-latency in cases ofhigh service-time variability, compared to the naive randomassignment policy.

3.7 Communication in HovercRaftFigure 5a summarizes the logic and the communication pat-tern described in the above design. A client sends requests toa pre-defined multicast group. Requests get replicated to allnodes based on multicast functionality existing in commod-ity switches. The leader orders requests and sends append_-entries with request metadata to followers, identifying therequest type (read-only or read-write) and delegating clientreplies; in this particular case follower 1 will reply. The fol-lowers reply to the leader and the leader commits the request.At the next append_entries request the followers are no-tified about the leader’s current commit index, execute the


Client

Switch

Leader

Follower 1

Follower 2

(a) HovercRaft

Client

Switch

NetAgg

Leader

Follower 1

Follower 2

(b) HovercRaft++

Figure 5. The communication patterns in our design resulting from separating replication from ordering and using in-networkfan-in/fan-out. Solid arrows refer to application requests and replies. Dotted arrows refer to SMR messages.

client request, and follower 1 replies to the client. The abovecommunication pattern increases latency in the unloadedcase (2.5 RTTs), but can lead to significant throughput bene-fits.

4 HovercRaft++The last bottleneck of § 2.1.2 is the packet processing over-head at the leader that becomes worse as the number offollowers increases. The leader has to send append_entriesrequests to each follower independently and receive repliesfor each request. Communication delays inside the datacen-ter, though, are short and usually predictable, so it is likelythat all followers make progress at the same pace. Based onthat observation, we tackle the packet processing bottleneckusing in-network programmability. Specifically, we designand implement an in-network aggregator, based on a P4-enabled programmable switch, that will handle the fan-outand fan-in of the append_entries requests and replies. Thisin-network accelerator should be viewed as part of the leader.A P4 switch runs the aggregation logic at line rate. So, weoffload some of the leader’s packet processing duties, thusreducing the leader’s CPU pressure, on a hardware appliancespecifically designed for packet IO. Our goal is to achievefixed-cost SMR in the non-failure case independently of thenumber of followers for small cluster sizes.

Figure 5b describes our proposed design. Similarly, to Hov-ercRaft’s communication pattern (Figure 5a), a client sends arequest to themulticast group and this request gets replicatedto all nodes. However, in the case of in-network acceleration(HovercRaft++), the leader, instead of communicating witheach individual follower, sends only one append_entriesrequest to the network aggregator. This request includes themetadata to implement the aforementioned load balancinglogic. The network aggregator then forwards this request tothe equivalent multicast group excluding the leader. The fol-lowers reply back to the aggregator and the aggregator keepstrack of the per-follower replies, without forwarding them

MSGs\System Raft HovercRaft HovercRaft++Rx msgs 1+(N-1) 1+(N-1) 1+1Tx msgs (N-1)+1 (N-1) + 1/N 1+1/N

Table 1. Comparison of Rx and Tx message overheads forthe leader in Raft, HovercRaft, and HovercRaft++ for thenon-failure case. N is the number of nodes.

to the leader. Once the majority of the followers have suc-cessfully replied, the aggregator multicasts an AGG_COMMITto all the nodes in the group, announcing the new commitindex. Based on that message, the delegate follower (follower1) replies back to the client.

Table 1 summarizes the communication complexity at theleader in Tx and Rx messages for the different approachesfor a cluster with N nodes (N-1 followers and a leader). Inthe case of Raft, the leader receives the client request, sendsN-1 append_entries requests to the followers, receives N-1append_entries replies, and sends the reply to the client.In the case of HovercRaft, the leader receives the client re-quest, sends N-1 append_entries requests (smaller than inthe previous case) to the followers, receives N-1 append_en-tries replies, and approximately sends only 1/N replies tothe client because of replies load balancing. Finally, in thecase of HovercRaft++, the leader receives the client request,sends only one append_entries request to the aggregatorthat multicasts it to the followers, the aggregator collects thequorum and sends one append_entries reply to the leader.Similarly with the previous case, the leader approximatelysends only 1/N replies to the client.

5 HovercRaft vs RaftHovercRaft does not modify the core of the Raft algorithmbut instead goes after its bottlenecks and implements opti-mizations to bypass them. Those optimizations are only ineffect in the non-failure mode of operation. HovercRaft fallsback to vanilla Raft whenever a failure, e.g., failed leader, isdetected. As a result, HovercRaft provides exactly the same


linearizability guarantees as Raft. It assumes the same failuremode, and guarantees safety and liveness with 2f + 1 nodes,where up to f nodes can fail.

Raft’s correctness depends heavily on the strong leaderand its election process. HovercRaft’s modifications to theRaft logic only affect the normal operation after a leader iselected. As a result, the correctness of the leader election isnot challenged.

The rest of this session discusses the modifications intro-duced by HovercRaft, how they affect the consensus logic,and how HovercRaft handles failures.

Separating replication and ordering: In HovercRaft, allnodes receive client requests through the multicast groupand the leader is in charge of ordering. Client requests areplaced in the Raft log as they are received only in the leader.Followers keep those requests in a list of un-ordered requestswaiting for an append_entries request.

Followers index unordered requests based on R2P2 unique3-tuple (req_id, src_ip, src_port). Clients are responsible toensure the uniqueness of the metadata identifiers. This isnot a problem in practice given the large R2P2 metadatanamespace. The leader can also include a hash of the requestbody to avoid cases of metadata collision. Therefore, there isa unique mapping between metadata in the append_entriesmessage and the requests in the followers unordered list.HovercRaft does not assume reliable multicast [45, 83].

Consequently, there might be cases in which client requestsdo not reach all the nodes. Followers detect such cases whenprocessing an append_entriesmessage and do not find theequivalent client request in their unordered set. We intro-duced a new recovery_request message type. Followersuse this request to ask for a missing client request from theleader or any other follower that might have potentially re-ceived it. Once a follower retrieves a missing request, it addsit to the unordered set, waiting for the next append_entriesrequest from the leader to order it properly.

The inverse case, in which the followers received a clientrequest but the leader did not, does not require changes tothe algorithm. The followers periodically garbage collectclient requests in their unordered set that linger, based on aspecific timeout. Early garbage collection does not affect thecorrectness of the algorithm and will unnecessarily triggerthe recover mechanism described above.

Bounded Queues: Bounding the amount of committed butunapplied requests does not affect the number of lost clientrequests in case of a leader failure. Followers have also re-ceived the client requests already placed in the failed leaderlog, but not yet announced. When a leader fails, the newleader will remove the received client requests from its un-ordered set, add them to its log in some order and startsending append_entries announcing their order.

Load Balancing Client Replies: Raft does not guaranteeexactly-once RPC semantics but instead only at-most-onceRPC semantics [92]. It only guarantees linearizability of op-erations, leaving the client outside the algorithmic logic.Consequently, the client reply can be lost or the leader cancrash after committing a log entry and before replying tothe client. Guaranteeing exactly-once RPC semantics is out-side the scope of Raft and projects like RIFL [64] solve theproblem of implementing exactly-once semantics on top ofinfrastructures providing at-most-once RPC semantics.

HovercRaft’s ability to load balance replies introduces thiswindow of uncertainty between the point of replier choiceby the leader and the actual client reply. This is consistentwith Raft’s at-most-once RPC semantics, does not affect cor-rectness, and should be considered equivalent to the casesof missing replies in vanilla Raft.

Load Balancing Read-Only Operations: Read-only oper-ations do not modify the state machine but still need to beordered to guarantee strong consistency. It is safe to exe-cute them only in the designated replier, only after theyhave been committed. The application (client-side or server-side) is responsible to correctly identify which operationsare read-only, as to avoid a catastrophic inconsistency.

In-networkAggregation:The aggregator should be viewedas part of the leader that undertakes leader tasks in the non-failure case. In HovercRaft++, followers reply to the aggre-gator only when append_entries requests succeed. Whenan append_entries fails, e.g., due to wrong previous entry,followers talk directly to the leader, bypassing the aggregator.When the leader receives a failure reply for an append_en-tries request, it uses point-to-point communication withthis follower until it recovers. In the meantime, this followerreceives the multicast append_entries requests from theaggregator and keeps them in order to identify when to stopthe recovery process with the leader, and continuewith usingthe messages from the aggregator instead.If the in-network aggregator fails, the followers stop re-

ceiving requests from the leader. This will trigger a newelection process, in which the aggregator does not partici-pate. Once a new leader is elected based on the vanilla Raftelection process, the new leader has to identify whether touse the in-network aggregator or not. The leader switchesto HovercRaft++ once it has confirmed the liveness of thein-network aggregator. The state in the aggregator is flushedafter every new leader election.Model-checking the correctness of HovercRaft++ using

TLA+ [93] is left for future work.

6 ImplementationWe implemented HovercRaft and HovercRaft++ based onthe open-source version of R2P2 [39], and a production-grade, open-source implementation of Raft [15], which is


thoroughly tested for correctness, and used in Intel’s dis-tributed object store [25]. We built the network aggregatorin P414 and ran it in a Tofino ASIC [7].To guarantee timely replies, we dedicate a thread to net-

work processing and a thread to run the application logic.The networking thread is in charge of receiving client re-quests and running the R2P2 and consensus logic. The ap-plication thread is in charge of running the application andreplying to the client if necessary. In our implementationon top of DPDK [29], we configure 1 RX queue for the net-working thread and 2 TX queues, one for each thread. Thenetworking thread polls the RX queue, while the applicationthread polls for changes in the commit_idx and applies thenewly committed entries.

6.1 R2P2 protocol extensionsWe extended R2P2 to integrate consensus in its RPC process-ing logic. R2P2’s RPC-tailored semantics and its RPC-awaredesign choice are a perfect fit to achieve our goal.The R2P2 header includes two relevant fields for our im-

plementation. The first one is the POLICY field, initially usedto define load balancing policies. We extended the seman-tics of this field with two new policies. Clients use thosefields to tag requests that must be totally ordered for strongconsistency. Specifically, requests that read and modify thestate machine should be marked with REPLICATED_REQ, andrequests that only read with REPLICATED_REQ_R. Markingrequests that require strong consistency allow servers in thefault-tolerance group to serve also other requests that arenot replicated, with the probability of stale data, similarlyto etcd [33]. Those non-replicated requests can also be loadbalanced based on the techniques described in [58].

The second relevant field is the message type. Given thatRaft itself depends on RPCs, Raft RPCs are also on top of R2P2.We added two more message types, one for Raft requests andone for Raft responses, as to separate them from the clientones since they have to be handled by the consensus logic inR2P2. These fields are also used by the network aggregatorto specially handle Raft requests and replies.

6.2 Raft extensionsWe added minimal modifications to the Raft implementationinitially for high throughput and low-latency and then tosupport HovercRaft. Specifically, we switched from the peri-odic application of the log, to eager application the momentthe entries are committed. Then, we extended the log entrywith two new fields to include the replier identifier and theentry’s type (read-only/read-write). Finally, without modify-ing the Raft code, we extended the append_entries reply toinclude the applied index, necessary for the bounded queues(§3.4) and load balancing.

6.3 Multicast Flow Control and RecoveryRaft and HovercRaft differ noticeably in one particular area.In vanilla Raft, the leader is the only one receiving client re-quests and is in charge of both ordering and replicating them;it is the only bottleneck in the system. Therefore, droppingclient requests at the leader is a form of implicit flow con-trol. HovercRaft, however, leverages multicasting to replicateclient requests, which implies that, under high load, differentrequests will be dropped for the leader and the followers.

As a consequence, HovercRaft has to implement flow con-trol to guarantee forward progress under high load or burstsof load that lead to dropped multicast client messages. Oneway of dealing with the problem is to let the leader andthe followers drop requests independently under high load,and rely on the recovery mechanism to create back-pressure.However, this would lead to poor performance.Instead, we leverage the R2P2’s FEEDBACK mechanism,

that is designed to be repurposed according to the applicationneeds, to limit the number of outstanding client requestsin the system. For example, the R2P2 request router usedFEEDBACKmessages to implement the JBSQ scheduling policy.HovercRaft and HovercRaft++ use FEEDBACK messages toimplement a coarse-grained flow control mechanism formulticast traffic.Specifically, instead of letting clients send requests to

a multicast IP, we use a middlebox, e.g., a programmableswitch, that counts the number of requests in the system andswitches the destination IP to the multicast IP of the fault-tolerance group. Every time a node sends back a reply to theclient, it also sends a FEEDBACK message to the flow-controlmiddlebox, to decrement the counter of requests. When thenumber of requests in the system reaches a certain thresh-old, instead of multicasting, the middlebox sends a NACKback to the client for every new client request arriving, thuspreventing throughput collapse in the system.

6.4 Aggregator implementationOur in-network aggregator is implemented as part of a Tofinoprogrammable switch, but it is an IP connected device thatcan be placed anywhere inside the data center. The aggre-gator maintains only soft state that is flushed on every newleader election.The aggregator needs to keep per-follower state and the

current commit index. For this purpose, we use P4 registersthat can be read and modified in the dataplane. For each nodethe aggregator keeps its current log index and the numberof completed requests necessary for load balancing. Thecurrent log index information in the aggregator is effectivelythe match index kept in the Raft leader, thus the aggregatorshould be seen as an extension of the leader and not as astandalone entity. Our implementation uses two P4 registersfor each follower, and each follower is handled in a differentTofino pipeline stage.


EgressIngress

Packet

Classifier

multicast

ae_req

update/check

match_1

update

commit

update/read

completed_1

update/read

completed_Ndrop/fwd

update/check

match_N. . . . . .

check

log_idx

set

pending

check

pending

send

vote_reply

ae_r

eq

ae_rep

check

termreset

vote_req

Figure 6. The in-network aggregator pipeline handling append_entries requests and replies

Figure 6 illustrates our implementation with the Tofino’singress and egress pipelines. When receiving append_en-tries requests, the aggregator only has to forward the packetwith a modified destination IP address set to the appropriatemulticast group. That multicast group includes all nodes ex-cept for the sender. The aggregator keeps track of the currentterm. Receiving an append_entries request with a higherterm will lead to the aggregator flushing its internal state.Processing append_entries replies is more challenging

since the aggregator needs to decide whether the log shouldbe committed up until a certain point and multicast theAGG_COMMITmessage to all the nodes. The AGG_COMMITmes-sage should include the committed index and the numberof completed requests per node. To achieve this in one passthrough the dataplane, we keep the match_idx registers inthe ingress pipeline and the completed_count registers inthe egress pipeline. When an append_entries reply arrivesat the aggregator, the aggregator updates the match index ofthe sender node, counts the number of nodes that have re-ceived up until this log index to determine whether it shouldcommit or not, and sets its decision in per packet metadata.All replies go through egress processing, to at least updatethe register holding the completed requests. If the aggrega-tor decides in ingress that the commit index is increased, itcompiles an AGG_COMMIT reply that includes the completedrequests of the followers and multicasts it to all nodes. Oth-erwise, it drops the reply in egress.There are cases where the leader announces up to the

same log index, which is already committed, in its append_-entries request. This might happen either because thereare no new client requests, or because a message betweenthe aggregator and the leader was lost. In this case, the ag-gregator needs to forward the request to the followers toprevent a new leader election and send an AGG_COMMIT foran already committed log index. If the aggregator detects thesame log index as in a previous append_entries request, itkeeps track of it, and sends an AGG_COMMIT for the next ap-pend_entries reply it receives, even if the commit index isnot increased. (check_log_idx, set_pending and check_-pending stages)

The aggregator does not participate in the leader election,but it should be able to notify the new leader that it is up andready to serve requests. Thus, the new leader, after beingelected, contacts the aggregator sending a vote_request

message. If the aggregator is up, it replies with a vote_-reply. Note that this vote_reply does not count for theleader election.Finally, Figure 6 illustrates the logic split between the

ingress and egress pipelines required to meet the timing re-striction of the ASIC: each stage of the pipeline can accessonly one register. With the Tofino v1 ASIC , HovercRaft++can accommodate up to 9 nodes, with full line-rate process-ing, and without requiring any packet recirculation.

7 EvaluationWe evaluate HovercRaft and HovercRaft++ with the pri-mary goal of showing the benefits of load balancing andin-network aggregation for datacenter SMR.Our infrastructure is a of a mix of Xeon E5-2637 @ 3.5

GHz with 8 cores (16 hyperthreads), and Xeon E5-2650 @2.6 GHz with 16 cores (32 hyperthreads), connected by aQuanta/Cumulus 48x10GbE switch with a Broadcom Tri-dent+ ASIC. All machines are configured with Intel x52010GbE NICs (82599EB chipset).

All experiments use the Lancet open-source load genera-tor, which generates an open-loop Poisson arrival process,relies on hardware timestamping for accurate RPC mea-surements, and reports accurately the 99th percentile taillatency [57]. Lancet supports R2P2.

Our experiments compare four different system setups, allon top of DPDK:(1) the unreplicated service (UnRep) is not fault-tolerant

as the state-machine is not replicated. Clients interact withthat single server using R2P2. This setup is expected to havethe lowest latency, but it is not fault-tolerant.

(2) Our port of the vanilla Raft algorithm [15] on R2P2 andDPDK (VanillaRaft), which directly integrates the SMRlayer within the RPC layer. This setup incorporates our de-sign contributions from §3.1, but no protocol contributions.

(3) HovercRaft (HovercRaft), which incorporates protocolextensions to separate request replication from ordering(§3.2), and the ability to load-balance replies (§3.3) and read-only operations (§3.5).(4) HovercRaft++ (HovercRaft++), which leverages in-

network aggregation to offload protocol processing (§4).This last configuration leverages, in addition to the hard-ware above, a Barefoot Tofino ASIC that runs within anEdgecore Wedge100BF-32X accelerator connected to the


0 200 400 600 800 1000

kRPS

0

200

400

99th

Late

ncy (

us)

VanillaRaft

HovercRaft

HovercRaft++

UnRep

Figure 7. Tail latency vs. throughput for a fixed service timeS = 1µs workload with 24-byte requests and 8-byte replieson N=3 node cluster.

Quanta switch via a 40Gbps link. We use the same Bare-foot switch as a flow-control middlebox.

We use a combination of synthetic micro-benchmarks anda real-world application. Synthetic microbenchmarks dependon a synthetic service with configurable CPU service execu-tion time, request, and reply sizes. Requests to this servicecan be either read-only or read-write. This methodology isused to determine protocol overheads in the presence ofknown upper bounds in terms of either CPU or I/O, andtherefore to exercise the bottlenecks independently. For ex-ample, we run most experiments with a service time S = 1µs,which obviously limits the throughput to ≤ 1000KRPS . Sim-ilarly, we run some experiments with 6KB replies, whichlimits throughput to ∼≤ 200KRPS per 10GbE link.

The evaluation answers the following questions and quan-tifies the benefits of our design decisions:

1. what is the overhead of turning an RPC service intoa fault-tolerant one with SMR implemented directlywithin the RPC layer in a 3-node cluster? (§7.1)

2. how is HovercRaft’s and HovercRaft++’s performanceaffected by the client request size? (§7.1)

3. how do HovercRaft and HovercRaft++ scale with anincreased number of nodes? (§7.2)

4. how does HovercRaft load balance replies and optimizeread-only operations? (§7.3)

5. how does HovercRaft behave in the presence of fail-ures? (§7.4)

6. how well does HovercRaft perform in practice with aproduction-grade application (Redis) and an industry-standard benchmark (YCSB-E)? (§7.5)

7.1 One million SMR operations per secondWe first characterize all four setups on a 3-node cluster us-ing a microbenchmark with a tiny service time (S = 1µs),minimum request size (24B) and minimum reply size (8B).There are no read-only operations to be load balanced. Forthis baseline experiment, we also explicitly disable the loadbalancing of client replies offered by HovercRaft, as to focuson protocol overheads.

Figure 7 shows the latency versus throughput curve for thefour setups. We observe that there is a latency offset between

VanillaRaft HovercRaft HovercRaft++ UnRep

64 512

Request Size (bytes)

0

500

1000

Max k

RP

S u

nd

er

SLO

Figure 8. Achieved throughput under a 500µs SLO for afixed service time service workload with S = 1µs, 8-bytereplies and different request sizes.

VanillaRaft HovercRaft HovercRaft++

N=3 N=5 N=7 N=9

Cluster Size

0

500

1000

Max k

RP

S u

nde

r S

LO

Figure 9. Achieved throughput under a 500µs SLO for aworkload with fixed service time of S = 1µs, 24-byte requestsand 8-byte replies for different cluster sizes.

the fault-tolerant configurations and the unreplicated casethat comes from the extra round-trip required to achieveconsensus. Nevertheless, that offset remains small and neverexceeds 68µs, even for throughputs as high as 950KRPS .Also, note that our experiment infrastructure depends onrather old hardware. Newer hardware, such as in [54], isexpected to reduce this offset.Figure 7 also shows that all four setups achieve close

to the maximum possible throughput (1M RPS) under the500µs SLO. This is a significant result as it outperformsother software-based, state-of-the-art approaches that ei-ther depend on kernel networking, such as NOPaxos [66](by a factor of 4×), implement consensus inside the kernel,such as Kernel Paxos [31] (by a factor of 5×), or depend onRDMA [85] (by a factor of 4×). The difference is explained byour kernel-bypassed DPDK-based implementation and theleaner RPC protocol (R2P2) with its direct Raft integration.

Figure 8 adjusts the first experiment by setting the requestsize to 64B and 512B (compared to 24B in the first experi-ment) and reports the achieved client throughput in requestsper second under the 500µs SLO. We observe that Hover-cRaft and HovercRaft++ are unaffected by the request sizeas they rely on multicast for request replication. However,the VanillaRaft configuration is sensitive to request size,with the throughput under SLO reduced by 2% and 48% for64B and 512B sized-requests, respectively, vs 24B requestsfor the baseline experiment.


7.2 Scaling Cluster Sizes Without RegretWe now scale the cluster size to 5, 7, and 9 nodes i.e., clustersthat can tolerate 2, 3, and 4 failures, for the same experimentas the baseline in §7.1.

Figure 9 shows the achieved throughput under the 500µsSLO. In the 3-node cluster the three configurations are equiv-alent. The differences become obvious with larger clusters,with VanillaRaftmost severely affected (−43% for 9 nodes).HovercRaft is unaffected up to 5 nodes, but shows a reduc-tion with 7 and 9 nodes as the leader has to communicateindependently with every follower. HovercRaft++ benefitsfrom in-network aggregation and its performance is inde-pendent of the cluster size: the communication overheadat the leader is always the same for any number of nodes,since the replication and aggregation are performed at theP4 switch, which operates at line rate.

7.3 Scaling to Improve PerformanceIn the previous experiments, we showed how HovercRaft++outperforms the other configurations even without consid-ering its load balancing benefits. We now enable the loadbalancing mechanism of HovercRaft with bounded queuesof up to 128 pending requests and increase the reply size to6KB; all other parameters remain the same as the baseline.All SMR operations execute on all nodes.

Figure 10 plots the latency as a function of the achievedthroughput for the unreplicated case and HovercRaft++ with3 and 5 nodes. As expected, the unreplicated setup hits anIO-bottlenecked at ∼200KRPS , which corresponds to a fullyutilized 10G link. Running on 3 and 5 nodes, increases thecapacity of the system by almost 3× and 5×, since it is anIO-bottlenecked workload and all followers reply to clients.

We now study specifically the CPU load balancing mech-anisms in our design. The purpose of this experiment is tostudy the impact of service time variability and schedulingdisciplines on performance. For this, we assume that 75% ofoperations are read-only. We use the baseline configurationfor request and reply sizes (which is free of I/O bottlenecks),and increase the CPU service time to an average of S = 10µs.We switch from the fixed service time distribution to a bi-modal distribution, in which 10% of the requests are 10xlonger than the rest. Based on these parameters, the unrepli-cated service is expected to reach close to 100k RPS, whileHovercRaft++ on a 3-node cluster will be close to 200k RPSif perfect load balancing is achieved.

Figure 11 shows the 99th percentile tail-latency as a func-tion of the achieved throughput for the unreplicated andreplicated cases. For HovercRaft++, we consider two loadbalancing policies, RANDOM and JBSQ, with bounded queuesof 32, due to the longer service time. We observe that loadbalancing the read-only operations increases the CPU capac-ity of the system for a 57% throughput improvement under

UnRep N=3 N=5

0 100 200 300 400 500 600 700

kRPS

0

200

400

99-t

h late

ncy (

us)

Figure 10. Latency versus throughput for S = 1µs fixedservice time, 24-byte requests, and 6kB replies for differentcluster sizes.

HovercRaft++ JBSQ HovercRaft++ RAND UnRep

25 50 75 100 125 150 175 200

kRPS

0

200

400

99th

Late

ncy (

us)

Figure 11. Latency versus throughput for a S = 10µs servicetime with bimodal distribution on a 3-node cluster. Requestsare 24-bytes, replies are 8-bytes, and 75% of operations areread-only.

the 500µs SLO. Also, the benefit of JBSQ over RANDOM be-comes obvious. JBSQ allows HovercRaft++ to deliver lowerlatency, and therefore higher throughput under SLO, sinceit load balances read-only requests better by avoiding over-loaded followers. We expect the gap between the 2 curves toincrease with the number of nodes in the cluster given themore opportunities for careful load balancing.

7.4 Loadbalancing in the presence of failuresHovercRaft and HovercRaft++ enable pushing the achievedthroughput load beyond the capacity of a single node byleveraging the existing redundancy. In the presence of fail-ures, though, the capacity of the fault-tolerant system re-duces. In such cases, HovercRaft and HovercRaft++ shouldmanage the failure and gracefully degrade their performance.In the next experiment we study how HovercRaft++ be-

haves when the leader fails. We use the same setup as inthe previous experiment with the bimodal distribution ofS̄ = 10µs and 75% read-only operations. Note that the capac-ity of the system with this request mix is 200k RPS with 3nodes, but drops to 160k RPS with 2 nodes. We load the sys-tem with a fixed load of 165 kRPS which is below maximumcapacity for the 3-node case, but above the maximum capac-ity for the 2-node setup. We configure flow control to allowup to 1000 client requests in the system. We measure the


0 20 40 60 80 100

Time(s)

155

160

165

170

175

kR

PS

0

5

10

99-t

h late

ncy (

ms)

Figure 12. 99-th percentile latency and throughput as afunction of time in the presence of failures a leader failurefor a HovercRaft++ 3-node cluster and a bimodal distributionof S̄ = 10µs with 75% read-only operations.

latency and throughput every second. At some point in timewe kill the leader and we study how the system behaves.

Figure 12 plots the 99-th percentile latency and through-put as a function of time. We observe that before the leaderfailure the system serves 165k RPS under low latency. Whenthe leader fails, one of the followers takes over and the sys-tem operates with 2 nodes. Because of bounded queues thenew leader does not assign work to old leader. Throughputdrops to the system capacity of 160k RPS. The flow controlmechanism drops approximately 5k RPS maintaining thenumber of requests in the system below 1000, leading toincreased latency, but avoiding collapse.

7.5 YCSB-E on RedisFinally, we evaluate our design on a real-world applicationthat requires generic SMR functionality for fault-tolerance.We run Redis [89] with the YCSB-E [19] workload.

YCSB-E is a cloud workload that consists of SCAN andINSERT operations, in a 95:5 ratio, modelling threaded con-versations. It assumes 1kB records, with 10 fields of 100 byteseach. INSERT requests add a new record and they have to beordered since they are parts of a conversation. SCAN requestsquery the last posts in a conversation, and they also need tobe ordered for correctness, but they are read-only operations,thus they can be load balanced. We set the maximum numberof elements to be returned in a SCAN request to 10.

Redis is an in-memory data store that supports basic data-structures and operations on them, such as lists, hashmaps,and sets. We chose Redis because it can be easily extendedthrough user-defined modules [90]. Through Redis modules,users can define their own operations that manipulate Redisdata-structures. We leverage the feature to implement theSCAN and INSERT operations of YCSB-E as single Redis op-erations that are guaranteed to execute within an isolatedtransaction. Given the support for arbitrary SMR operations,turning Redis to fault-tolerant requires an application agnos-tic approach similar to HovercRaft and HovercRaft++.We ported Redis to use R2P2 instead of TCP for client

operations. Beyond this protocol change, running the fault-tolerant version of Redis via VanillaRaft, HovercRaft, or

UnRep N=3 N=5 N=7

0 20 40 60 80 100 120 140 160

kRPS

0

200

400

99-t

h late

ncy (

us)

Figure 13. Latency vs throughput for YCSB-E(95% SCAN5% INSERT) on Redis with our custom module to supportYCSBE-E operations.

HovercRaft++ required no code modifications, showing thebenefits of transport layer support for SMR.Figure 13 plots the 99th percentile latency as a function

of the achieved throughput for the unreplicated case andthe cluster configurations for HovercRaft++ with 3, 5, and 7nodes. YCSB-E on Redis is a CPU-bound. read-mostly work-load.We observe that SMR has only a verymoderate negativeimpact on tail latency at low loads (up to 10KRPS), but thatHovercRaft++’s ability to leverage data replication presentin SMR substantially increases the achieved throughput un-der the 500µs SLO. In the 7-node cluster, Redis can execute142k YCSB-E operations per second under SLO, while guar-anteeing full state machine replication and ordering of alloperations, for a speedup of 4× over the unreplicated case.This speedup of 4× is consistent with the upper bound pre-dicted by Amdahl’s law given the relative cost of SCAN andINSERT, and the fact that only SCANs can be load balanced.

8 Discussion

Programmable Switches andConsistency:HovercRaft++is not the first system to leverage programmable switches forstate machine replication. However, the use of programmableswitches in HovercRaft++ differs when compared to the pre-vious work, and we believe our proposal could be used inother distributed systems mechanisms, such as byzantinefault tolerance and primary backup.We split the proposals of using programmable switches

in SMR in three main categories. The first category includessystems that use P4 switches as sequencers. NOPaxos [66]and Harmonia [100] take advantage of in-network computeto assign sequence numbers to client requests under verylow latency and high throughput. Despite its simplicity, onedrawback in this approach is handling switch failures. Aftera sequencer failure, the new sequencer has to make sure thatit respects the request order from the previous sequencer.Thus, these systems depend on a second fault-tolerant groupat the level of the network controller that maintains an epochnumber, that increases at every sequencer failure, and is usedto bootstrap the new sequencer.


The second category includes systems that fully offloadthe implementation of an SMR algorithm on a programmableswitch. For example, Paxos made switch-y [22] runs a Paxoscoordinator and acceptor inside the P4 dataplane. Althoughsuch proposals can significantly improve performance, theysuffer from the P4 dataplane limitations, such using fixed-size small values.

HovercRaft++ partially offloads leader duties to the pro-grammable switch by using it as a very efficient packet pro-cessor. The programmable switch deals with Raft’s fan-outand the fan-in communication patterns, while maintainingonly soft state. If a switch fails, a new switch can take overstarting from an empty state, thus bypassing the problemsin the first category. Also, using a software-based leader run-ning in a server offers a lot of flexibility to the system, unlikethe proposals from the second category.

HovercRaft and High Speed Networks: HovercRaft andHovercRaft++ go after both IO and CPU bottlenecks in SRM.Although the IO bottlenecks might become less importantwith the advent of faster networks, e.g., 40G and 100G, theread-only operation load balancing and in-network fan-out/fan-in management employed in HovercRaft++ focus only onCPU bottlenecks and remain relevant despite bandwidthabundance. Especially, HovercRaft++will becomemuchmorebeneficial in those high speed networks since it offloadspacket IO to the programmable switch and exposes a fixedoverhead to the leader independent of the cluster size.

9 Related work

SMR: Consensus and state machine replication have beenwidely studied both from a theoretic [51, 60–63, 76, 77], anda systems point of view. Systems such as Spanner [20], Zoo-keeper [46], Chubby [14], etcd [33] depend on those algo-rithms and are widely deployed serving millions of users.Researchers have optimized consensus systems to offer SMRin aWAN environment [67, 72], inside the datacenter [66, 86],implemented within the kernel [31], using RDMA fabrics [85,95], or on top of FPGAs [47]. Similar to NOPaxos [66] andSpeculative Paxos [86], HovercRaft focuses on fault toleranceinside the datacenter assuming lossy Ethernet fabrics (ratherthan RDMA). Despite leaderless approaches such as Men-cious [67] and EPaxos [72] deal with leader bottlenecks, theylack a global cluster view, unlike HovercRaft, thus reducingthe load balancing potentials.

Scaling read-only operations: Read leases [40] proposedto optimize for read-only operations in SMR and have beenused either in the form of master leases in Spanner [20], andChubby [14], or in the form of read quorums [73]. Thoseapproaches either overload the leader or assume application-specific knowledge. HovercRaft implements load balanc-ing of linearizable, read-only operations in an application-agnostic manner.

µs-scale computing: Exposing the hardware potential ofµs-scale interactions within a datacenter to applications re-quires a new approach. This approach includes datacenter-specific operating systems [9, 53, 80, 84, 87, 98], user-levelnetworking stacks [49, 54, 56], and transport protocols [58,71]. HovercRaft builds on the R2P2 paradigm of pushingsupport for RPC to the transport layer [58] by extending itto offer fault-tolerance.

Networking protocol design and implementation: Theseparation of request data and metadata for ordering isalso used in previous systems [6, 11, 35, 52]. UDP has beenproposed to increase scalability of datacenter RPCs [75].Bounded batching has been proposed to increase through-put [9] and reduce tail latency [58]. In-network programma-bility and programmable switches have been used for fault-tolerance, for sequencing in NOPaxos [66], to accelerateVertical Paxos in NetChain [50], or implementing the en-tire Paxos algorithm [22, 24, 94]. Such approaches either donot assume switch failures, or rely on another fault-tolerantgroup for state management. HovercRaft incorporates theseideas into the domain of SMR, and only stores soft-state inthe network, which is recreated at every leader election.

Alternative fault-tolerance models: Fault-tolerance canbe offered at the system call layer (Crane [21]), at the level ofmemory operations [23], in transactional databases [65, 74,99], key-value stores [82], or for multi-threaded applications(Rex [43] and Eve [55]). HovercRaft provides fault-toleranceat the RPC layer in an application-agnostic manner and with-out code modifications.

10 ConclusionWe showed that replication can simultaneously improveboth fault-tolerance and performance. Through the carefulimplementation of HovercRaft using modern kernel-bypasstechniques and appropriate datacenter transport protocols,we first show that SMR is suitable for µs-scale computing,delivering 1 million ordered operations per second. Throughthe additional use of multicast, in-network accelerators, andload balancing, we tackle SMR’s CPU and I/O bottlenecksand enable the deployment of fault-tolerant applications inan application-agnostic manner.

11 AcknowledgementsWe would like to thank the anonymous PC and shadow-PCreviewers, our shepherd Marco Canini, and Jim Larus, fortheir valuable feedback on the paper. We would like to thankAntoine Albertelli for his initial work on the topic. This workis part of the Microsoft Swiss JRC TTL-MSR project. MariosKogias is supported by an IBM PhD Fellowship.


References[1] Atul Adya, Robert Grandl, Daniel Myers, and Henry Qin. Fast key-

value stores: An idea whose time has come and gone. In Proceedingsof The 17thWorkshop on Hot Topics in Operating Systems (HotOS-XVII),pages 113–119, 2019.

[2] Mohammad Alizadeh, Shuang Yang, Milad Sharif, Sachin Katti, NickMcKeown, Balaji Prabhakar, and Scott Shenker. pFabric: minimalnear-optimal datacenter transport. In Proceedings of the ACM SIG-COMM 2013 Conference, pages 435–446, 2013.

[3] Peter Bailis, Aaron Davidson, Alan Fekete, Ali Ghodsi, Joseph M.Hellerstein, and Ion Stoica. Highly Available Transactions: Virtuesand Limitations. PVLDB, 7(3):181–192, 2013.

[4] Peter Bailis and Kyle Kingsbury. The network is reliable. Commun.ACM, 57(9):48–55, 2014.

[5] Jason Baker, Chris Bond, James C. Corbett, J. J. Furman, Andrey Khor-lin, James Larson, Jean-Michel Leon, Yawei Li, Alexander Lloyd, andVadim Yushprakh. Megastore: Providing Scalable, Highly AvailableStorage for Interactive Services. In Proceedings of the 5th Biennial Con-ference on Innovative Data Systems Research (CIDR), pages 223–234,2011.

[6] Mahesh Balakrishnan, Ken Birman, and Amar Phanishayee. PLATO:Predictive Latency-Aware Total Ordering. In Proceedings of the 25thIEEE Symposium on Reliable Distributed Systems (SRDS), pages 175–188, 2006.

[7] Barefoot Networks. Tofino product brief. https://barefootnetworks.com/products/brief-tofino/, 2018.

[8] Luiz André Barroso, Jimmy Clidaras, and Urs Hölzle. The Datacenteras a Computer: An Introduction to the Design of Warehouse-Scale Ma-chines, Second Edition. Synthesis Lectures on Computer Architecture.Morgan & Claypool Publishers, 2013.

[9] Adam Belay, George Prekas, Mia Primorac, Ana Klimovic, SamuelGrossman, Christos Kozyrakis, and Edouard Bugnion. The IX Oper-ating System: Combining Low Latency, High Throughput, and Effi-ciency in a Protected Dataplane. ACMTrans. Comput. Syst., 34(4):11:1–11:39, 2017.

[10] Carlos Eduardo Benevides Bezerra, Le Long Hoang, and FernandoPedone. Strong Consistency at Scale. IEEE Data Eng. Bull., 39(1):93–103, 2016.

[11] Kenneth P. Birman, André Schiper, and Pat Stephenson. LightweigtCausal and Atomic Group Multicast. ACM Trans. Comput. Syst.,9(3):272–314, 1991.

[12] Eric A. Brewer. Pushing the CAP: Strategies for Consistency andAvailability. IEEE Computer, 45(2):23–29, 2012.

[13] Brendan Burns, Brian Grant, David Oppenheimer, Eric A. Brewer,and John Wilkes. Borg, Omega, and Kubernetes. Commun. ACM,59(5):50–57, 2016.

[14] Michael Burrows. The Chubby Lock Service for Loosely-CoupledDistributed Systems. In Proceedings of the 7th Symposium onOperatingSystem Design and Implementation (OSDI), pages 335–350, 2006.

[15] C implementation of raft. https://github.com/willemt/raft.[16] Brad Calder, Ju Wang, Aaron Ogus, Niranjan Nilakantan, Arild

Skjolsvold, Sam McKelvie, Yikang Xu, Shashwat Srivastav, JieshengWu, Huseyin Simitci, Jaidev Haridas, Chakravarthy Uddaraju, HemalKhatri, Andrew Edwards, Vaman Bedekar, Shane Mainali, Rafay Ab-basi, Arpit Agarwal, Mian Fahim ul Haq, Muhammad Ikram ul Haq,Deepali Bhardwaj, Sowmya Dayanand, Anitha Adusumilli, MarvinMcNett, Sriram Sankaran, Kavitha Manivannan, and Leonidas Rigas.Windows Azure Storage: a highly available cloud storage servicewith strong consistency. In Proceedings of the 23rd ACM Symposiumon Operating Systems Principles (SOSP), pages 143–157, 2011.

[17] Tushar Deepak Chandra, Robert Griesemer, and Joshua Redstone.Paxos made live: an engineering perspective. In Proceedings of the26th Annual ACM Symposium on Principles of Distributed Computing(PODC), pages 398–407, 2007.

[18] Chia-Chen Chang, Shun-Ren Yang, En-Hau Yeh, Phone Lin, and Jeu-Yih Jeng. A Kubernetes-Based Monitoring Platform for DynamicCloud Resource Provisioning. In Proceedings of the 2017 IEEE GlobalCommunications Conference (GLOBECOM), pages 1–6, 2017.

[19] Brian F. Cooper, Adam Silberstein, Erwin Tam, Raghu Ramakrishnan,and Russell Sears. Benchmarking cloud serving systemswith YCSB. InProceedings of the 2010 ACM Symposium on Cloud Computing (SOCC),pages 143–154, 2010.

[20] James C. Corbett, Jeffrey Dean, Michael Epstein, Andrew Fikes,Christopher Frost, J. J. Furman, Sanjay Ghemawat, Andrey Gubarev,Christopher Heiser, Peter Hochschild, Wilson C. Hsieh, SebastianKanthak, Eugene Kogan, Hongyi Li, Alexander Lloyd, Sergey Mel-nik, David Mwaura, David Nagle, Sean Quinlan, Rajesh Rao, LindsayRolig, Yasushi Saito, Michal Szymaniak, Christopher Taylor, RuthWang, and Dale Woodford. Spanner: Google’s Globally DistributedDatabase. ACM Trans. Comput. Syst., 31(3):8:1–8:22, 2013.

[21] Heming Cui, Rui Gu, Cheng Liu, Tianyu Chen, and Junfeng Yang.Paxos made transparent. In Proceedings of the 25th ACM Symposiumon Operating Systems Principles (SOSP), pages 105–120, 2015.

[22] Huynh Tu Dang, Marco Canini, Fernando Pedone, and Robert Soulé.Paxos Made Switch-y. Computer Communication Review, 46(2):18–24,2016.

[23] Huynh TuDang, JacoHofmann, Yang Liu,Marjan Radi, Dejan Vucinic,Robert Soulé, and Fernando Pedone. Consensus for Non-volatile MainMemory. In Proceedings of the 26th IEEE International Conference onNetwork Protocols (ICNP), pages 406–411, 2018.

[24] Huynh Tu Dang, Daniele Sciascia, Marco Canini, Fernando Pedone,and Robert Soulé. NetPaxos: consensus at network speed. In Pro-ceedings of the Symposium on SDN Research (SOSR), pages 5:1–5:7,2015.

[25] Daos object store. https://github.com/daos-stack.[26] Jeffrey Dean and Luiz André Barroso. The tail at scale. Commun.

ACM, 56(2):74–80, 2013.[27] Giuseppe DeCandia, Deniz Hastorun, Madan Jampani, Gunavardhan

Kakulapati, Avinash Lakshman, Alex Pilchin, Swaminathan Sivasub-ramanian, Peter Vosshall, and Werner Vogels. Dynamo: amazon’shighly available key-value store. In Proceedings of the 21st ACMSymposium on Operating Systems Principles (SOSP), pages 205–220,2007.

[28] Jaeyoung Do, Sudipta Sengupta, and Steven Swanson. Programmablesolid-state storage in future cloud datacenters. Commun. ACM,62(6):54–62, 2019.

[29] Data plane development kit. http://www.dpdk.org/.[30] Aleksandar Dragojevic, Dushyanth Narayanan, Miguel Castro, and

Orion Hodson. FaRM: Fast Remote Memory. In Proceedings of the11th Symposium on Networked Systems Design and Implementation(NSDI), pages 401–414, 2014.

[31] Emanuele Giuseppe Esposito, Paulo R. Coelho, and Fernando Pedone.Kernel Paxos. In Proceedings of the 37th IEEE Symposium on ReliableDistributed Systems (SRDS), pages 231–240, 2018.

[32] etcd ordering guarantees. https://github.com/etcd-io/etcd/blob/master/Documentation/learning/api_guarantees.md.

[33] etcd: Distributed reliable key-value store for the most critical dataof a distributed system. https://github.com/etcd-io/etcd.

[34] etcd Documentation Guide: What is etcd gateway?https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/gateway.md.

[35] Pascal Felber and André Schiper. Optimistic Active Replication. InProceedings of the 21st IEEE International Conference on DistributedComputing Systems (ICDCS), pages 333–341, 2001.

[36] Michael J. Fischer, Nancy A. Lynch, and Mike Paterson. Impossibilityof Distributed Consensus with One Faulty Process. J. ACM, 32(2):374–382, 1985.

https://barefootnetworks.com/products/brief-tofino/

https://barefootnetworks.com/products/brief-tofino/

https://github.com/willemt/raft

https://github.com/daos-stack

http://www.dpdk.org/

https://github.com/etcd-io/etcd/blob/master/Documentation/learning/api_guarantees.md

https://github.com/etcd-io/etcd/blob/master/Documentation/learning/api_guarantees.md

https://github.com/etcd-io/etcd

https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/gateway.md

https://github.com/etcd-io/etcd/blob/master/Documentation/op-guide/gateway.md


[37] Peter Xiang Gao, Akshay Narayan, Gautam Kumar, Rachit Agarwal,Sylvia Ratnasamy, and Scott Shenker. pHost: distributed near-optimaldatacenter transport over commodity network fabric. In Proceedingsof the 2015 ACM Conference on Emerging Networking Experiments andTechnology (CoNEXT), pages 1:1–1:12, 2015.

[38] Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. The Googlefile system. In Proceedings of the 19th ACM Symposium on OperatingSystems Principles (SOSP), pages 29–43, 2003.

[39] R2p2 source code. https://github.com/epfl-dcsl/r2p2.[40] Cary G. Gray and David R. Cheriton. Leases: An Efficient Fault-

Tolerant Mechanism for Distributed File Cache Consistency. In Pro-ceedings of the 12th ACM Symposium on Operating Systems Principles(SOSP), pages 202–210, 1989.

[41] Jim Gray. Fault Tolerance in Tandem Systems. In Proceedings of the1985 International Workshop on High-Performance Transaction Systems(HTPS), 1985.

[42] gRPC. http://www.grpc.io/.[43] Zhenyu Guo, Chuntao Hong, Mao Yang, Dong Zhou, Lidong Zhou,

and Li Zhuang. Rex: replication at the speed of multi-core. In Pro-ceedings of the 2014 EuroSys Conference, pages 11:1–11:14, 2014.

[44] Sangjin Han, Scott Marshall, Byung-Gon Chun, and Sylvia Ratnasamy.MegaPipe: A New Programming Interface for Scalable Network I/O.In Proceedings of the 10th Symposium on Operating System Design andImplementation (OSDI), pages 135–148, 2012.

[45] Hugh W. Holbrook, Sandeep K. Singhal, and David R. Cheriton. Log-Based Receiver-Reliable Multicast for Distributed Interactive Simu-lation. In Proceedings of the ACM SIGCOMM 1995 Conference, pages328–341, 1995.

[46] Patrick Hunt, Mahadev Konar, Flavio Paiva Junqueira, and BenjaminReed. ZooKeeper: Wait-free Coordination for Internet-scale Systems.In Proceedings of the 2010 USENIX Annual Technical Conference (ATC),2010.

[47] Zsolt István, David Sidler, Gustavo Alonso, and Marko Vukolic. Con-sensus in a Box: Inexpensive Coordination in Hardware. In Pro-ceedings of the 13th Symposium on Networked Systems Design andImplementation (NSDI), pages 425–438, 2016.

[48] Joseph Izraelevitz, Jian Yang, Lu Zhang, Juno Kim, Xiao Liu, Amir-saman Memaripour, Yun Joon Soh, Zixuan Wang, Yi Xu, Subra-manya R. Dulloor, Jishen Zhao, and Steven Swanson. Basic Per-formance Measurements of the Intel Optane DC Persistent MemoryModule. CoRR, abs/1903.05714, 2019.

[49] Eunyoung Jeong, Shinae Woo, Muhammad Asim Jamshed, HaewonJeong, Sunghwan Ihm, Dongsu Han, and KyoungSoo Park. mTCP:a Highly Scalable User-level TCP Stack for Multicore Systems. InProceedings of the 11th Symposium on Networked Systems Design andImplementation (NSDI), pages 489–502, 2014.

[50] Xin Jin, Xiaozhou Li, Haoyu Zhang, Nate Foster, Jeongkeun Lee,Robert Soulé, Changhoon Kim, and Ion Stoica. NetChain: Scale-FreeSub-RTT Coordination. In Proceedings of the 15th Symposium onNetworked Systems Design and Implementation (NSDI), pages 35–49,2018.

[51] Flavio Paiva Junqueira, Benjamin C. Reed, and Marco Serafini. Zab:High-performance broadcast for primary-backup systems. In Pro-ceedings of the 41st Annual IEEE/IFIP International Conference on De-pendable Systems and Networks (DSN), pages 245–256, 2011.

[52] M. Frans Kaashoek and Andrew S. Tanenbaum. Group communi-cation in the Amoeba distributed operating system. In Proceedingsof the 11th IEEE International Conference on Distributed ComputingSystems (ICDCS), pages 222–230, 1991.

[53] Kostis Kaffes, Timothy Chong, Jack Tigar Humphries, Adam Be-lay, David Mazières, and Christos Kozyrakis. Shinjuku: PreemptiveScheduling for µsecond-scale Tail Latency. In Proceedings of the 16thSymposium on Networked Systems Design and Implementation (NSDI),pages 345–360, 2019.

[54] Anuj Kalia, Michael Kaminsky, and David Andersen. DatacenterRPCs can be General and Fast. In Proceedings of the 16th Symposiumon Networked Systems Design and Implementation (NSDI), pages 1–16,2019.

[55] Manos Kapritsos, YangWang, Vivien Quéma, Allen Clement, LorenzoAlvisi, and Mike Dahlin. All about Eve: Execute-Verify Replicationfor Multi-Core Servers. In Proceedings of the 10th Symposium onOperating System Design and Implementation (OSDI), pages 237–250,2012.

[56] Antoine Kaufmann, Tim Stamler, Simon Peter, Naveen Kr. Sharma,Arvind Krishnamurthy, and Thomas E. Anderson. TAS: TCP Acceler-ation as an OS Service. In Proceedings of the 2019 EuroSys Conference,pages 24:1–24:16, 2019.

[57] Marios Kogias, Stephen Mallon, and Edouard Bugnion. Lancet: Aself-correcting Latency Measuring Tool. In Proceedings of the 2019USENIX Annual Technical Conference (ATC), pages 881–896, 2019.

[58] Marios Kogias, George Prekas, Adrien Ghosn, Jonas Fietz, andEdouard Bugnion. R2P2: Making RPCs first-class datacenter citi-zens. In Proceedings of the 2019 USENIX Annual Technical Conference(ATC), pages 863–880, 2019.

[59] Chinmay Kulkarni, Sara Moore, Mazhar Naqvi, Tian Zhang, RobertRicci, and Ryan Stutsman. Splinter: Bare-Metal Extensions for Multi-Tenant Low-Latency Storage. In Proceedings of the 13th Symposium onOperating System Design and Implementation (OSDI), pages 627–643,2018.

[60] Leslie Lamport. The Part-Time Parliament. ACM Trans. Comput. Syst.,16(2):133–169, 1998.

[61] Leslie Lamport. Paxos made simple. ACM SIGACT News (DistributedComputing Column) 32, 4 (Whole Number 121, December 2001), pages51–58, December 2001.

[62] Leslie Lamport. Fast Paxos. Distributed Computing, 19(2):79–103,2006.

[63] Leslie Lamport, Dahlia Malkhi, and Lidong Zhou. Vertical paxos andprimary-backup replication. In Proceedings of the 28th Annual ACMSymposium on Principles of Distributed Computing (PODC), pages312–313, 2009.

[64] Collin Lee, Seo Jin Park, Ankita Kejriwal, Satoshi Matsushita, andJohn K. Ousterhout. Implementing linearizability at large scale andlow latency. In Proceedings of the 25th ACM Symposium on OperatingSystems Principles (SOSP), pages 71–86, 2015.

[65] Jialin Li, Ellis Michael, and Dan R. K. Ports. Eris: Coordination-FreeConsistent Transactions Using In-Network Concurrency Control.In Proceedings of the 26th ACM Symposium on Operating SystemsPrinciples (SOSP), pages 104–120, 2017.

[66] Jialin Li, Ellis Michael, Naveen Kr. Sharma, Adriana Szekeres, and DanR. K. Ports. Just Say NO to Paxos Overhead: Replacing Consensuswith Network Ordering. In Proceedings of the 12th Symposium onOperating System Design and Implementation (OSDI), pages 467–483,2016.

[67] Yanhua Mao, Flavio Paiva Junqueira, and Keith Marzullo. Mencius:Building Efficient Replicated State Machine for WANs. In Proceedingsof the 8th Symposium on Operating System Design and Implementation(OSDI), pages 369–384, 2008.

[68] Ilias Marinos, Robert N. M. Watson, and Mark Handley. Networkstack specialization for performance. In Proceedings of the ACMSIGCOMM 2014 Conference, pages 175–186, 2014.

[69] Michael Marty, Marc de Kruijf, Jacob Adriaens, Christopher Alfeld,Sean Bauer, Carlo Contavalli, Michael Dalton, Nandita Dukkipati,William C. Evans, Steve Gribble, Nicholas Kidd, Roman Kokonov,Gautam Kumar, Carl Mauer, Emily Musick, Lena Olson, Erik Rubow,Michael Ryan, Kevin Springborn, Paul Turner, Valas Valancius,Xi Wang, and Amin Vahdat. Snap: a Microkernel Approach to HostNetworking. In Proceedings of the 27th ACM Symposium on OperatingSystems Principles (SOSP), 2019.

https://github.com/epfl-dcsl/r2p2

http://www.grpc.io/


[70] Christopher Mitchell, Yifeng Geng, and Jinyang Li. Using One-SidedRDMA Reads to Build a Fast, CPU-Efficient Key-Value Store. InProceedings of the 2013 USENIX Annual Technical Conference (ATC),pages 103–114, 2013.

[71] Behnam Montazeri, Yilong Li, Mohammad Alizadeh, and John K.Ousterhout. Homa: a receiver-driven low-latency transport protocolusing network priorities. In Proceedings of the ACM SIGCOMM 2018Conference, pages 221–235, 2018.

[72] Iulian Moraru, David G. Andersen, and Michael Kaminsky. Thereis more consensus in Egalitarian parliaments. In Proceedings of the24th ACM Symposium on Operating Systems Principles (SOSP), pages358–372, 2013.

[73] Iulian Moraru, David G. Andersen, and Michael Kaminsky. PaxosQuorum Leases: Fast ReadsWithout SacrificingWrites. In Proceedingsof the 2014 ACM Symposium on Cloud Computing (SOCC), pages 22:1–22:13, 2014.

[74] ShuaiMu, Lamont Nelson,Wyatt Lloyd, and Jinyang Li. ConsolidatingConcurrency Control and Consensus for Commits under Conflicts.In Proceedings of the 12th Symposium on Operating System Design andImplementation (OSDI), pages 517–532, 2016.

[75] Rajesh Nishtala, Hans Fugal, Steven Grimm, Marc Kwiatkowski, Her-man Lee, Harry C. Li, RyanMcElroy, Mike Paleczny, Daniel Peek, PaulSaab, David Stafford, Tony Tung, and Venkateshwaran Venkatara-mani. Scaling Memcache at Facebook. In Proceedings of the 10thSymposium on Networked Systems Design and Implementation (NSDI),pages 385–398, 2013.

[76] Brian M. Oki and Barbara Liskov. Viewstamped Replication: A Gen-eral Primary Copy. In Proceedings of the 7th Annual ACM Symposiumon Principles of Distributed Computing (PODC), pages 8–17, 1988.

[77] Diego Ongaro and John K. Ousterhout. In Search of an Understand-able Consensus Algorithm. In Proceedings of the 2014 USENIX AnnualTechnical Conference (ATC), pages 305–319, 2014.

[78] Open OnLoad. http://www.openonload.org/.[79] Intel optane. https://www.intel.com/content/www/us/en/

architecture-and-technology/intel-optane-technology.html.[80] Amy Ousterhout, Joshua Fried, Jonathan Behrens, Adam Belay, and

Hari Balakrishnan. Shenango: Achieving High CPU Efficiency forLatency-sensitive Datacenter Workloads. In Proceedings of the 16thSymposium on Networked Systems Design and Implementation (NSDI),pages 361–378, 2019.

[81] John K. Ousterhout, Arjun Gopalan, Ashish Gupta, Ankita Kejriwal,Collin Lee, Behnam Montazeri, Diego Ongaro, Seo Jin Park, HenryQin, Mendel Rosenblum, Stephen M. Rumble, Ryan Stutsman, andStephen Yang. The RAMCloud Storage System. ACM Trans. Comput.Syst., 33(3):7:1–7:55, 2015.

[82] Seo Jin Park and John K. Ousterhout. Exploiting Commutativity ForPractical Fast Replication. In Proceedings of the 16th Symposium onNetworked Systems Design and Implementation (NSDI), pages 47–64,2019.

[83] Sanjoy Paul, Krishan K. Sabnani, John C.-H. Lin, and Supratik Bhat-tacharyya. Reliable Multicast Transport Protocol (RMTP). IEEEJournal on Selected Areas in Communications, 15(3):407–421, 1997.

[84] Simon Peter, Jialin Li, Irene Zhang, Dan R. K. Ports, Doug Woos,Arvind Krishnamurthy, Thomas E. Anderson, and Timothy Roscoe.Arrakis: The Operating System Is the Control Plane. ACM Trans.Comput. Syst., 33(4):11:1–11:30, 2016.

[85] Marius Poke and Torsten Hoefler. DARE: High-Performance StateMachine Replication on RDMA Networks. In Proceedings of the 24thInternational Symposium on High-Performance Parallel and DistributedComputing (HPDC), pages 107–118, 2015.

[86] Dan R. K. Ports, Jialin Li, Vincent Liu, Naveen Kr. Sharma, and ArvindKrishnamurthy. Designing Distributed Systems Using ApproximateSynchrony in Data Center Networks. In Proceedings of the 12thSymposium on Networked Systems Design and Implementation (NSDI),

pages 43–57, 2015.[87] George Prekas, Marios Kogias, and Edouard Bugnion. ZygOS: Achiev-

ing Low Tail Latency for Microsecond-scale Networked Tasks. InProceedings of the 26th ACM Symposium on Operating Systems Princi-ples (SOSP), pages 325–341, 2017.

[88] Iraklis Psaroudakis, Tobias Scheuer, Norman May, and Anastasia Ail-amaki. Task Scheduling for Highly Concurrent Analytical and Trans-actional Main-Memory Workloads. In Proceedings of the InternationalWorkshop on Accelerating Analytics and Data Management SystemsUsing Modern Processor and Storage Architectures (ADMS@VLDB),pages 36–45, 2013.

[89] Redis. https://redis.io/.[90] Redis modules. https://redis.io/topics/modules-intro.[91] Fred B. Schneider. Implementing Fault-Tolerant Services Using the

State Machine Approach: A Tutorial. ACM Comput. Surv., 22(4):299–319, 1990.

[92] B. H. Tay and Akkihebbal L. Ananda. A Survey of Remote ProcedureCalls. Operating Systems Review, 24(3):68–79, 1990.

[93] The tla+ homepage. https://lamport.azurewebsites.net/tla/tla.html.[94] Yuta Tokusashi, Huynh Tu Dang, Fernando Pedone, Robert Soulé, and

Noa Zilberman. The Case For In-Network Computing On Demand.In Proceedings of the 2019 EuroSys Conference, pages 21:1–21:16, 2019.

[95] Cheng Wang, Jianyu Jiang, Xusheng Chen, Ning Yi, and Heming Cui.APUS: fast and scalable paxos on RDMA. In Proceedings of the 2017ACM Symposium on Cloud Computing (SOCC), pages 94–107, 2017.

[96] Sage A. Weil, Scott A. Brandt, Ethan L. Miller, Darrell D. E. Long, andCarlos Maltzahn. Ceph: A Scalable, High-Performance DistributedFile System. In Proceedings of the 7th Symposium on Operating SystemDesign and Implementation (OSDI), pages 307–320, 2006.

[97] Jian Yang, Joseph Izraelevitz, and Steven Swanson. Orion: A Dis-tributed File System for Non-Volatile Main Memory and RDMA-Capable Networks. In Proceedings of the 17th USENIX Conference onFile and Storage Technologie (FAST), pages 221–234, 2019.

[98] Irene Zhang, Jing Liu, Amanda Austin, Michael Lowell Roberts, andAnirudh Badam. I’m Not Dead Yet!: The Role of the Operating Systemin a Kernel-Bypass Era. In Proceedings of The 17th Workshop on HotTopics in Operating Systems (HotOS-XVII), pages 73–80, 2019.

[99] Irene Zhang, Naveen Kr. Sharma, Adriana Szekeres, Arvind Krishna-murthy, and Dan R. K. Ports. Building consistent transactions withinconsistent replication. In Proceedings of the 25th ACM Symposiumon Operating Systems Principles (SOSP), pages 263–278, 2015.

[100] Hang Zhu, Zhihao Bai, Jialin Li, Ellis Michael, Dan R. K. Ports, IonStoica, and Xin Jin. Harmonia: Near-Linear Scalability for ReplicatedStorage with In-Network Conflict Detection. PVLDB, 13(3):376–389,2019.

http://www.openonload.org/

https://www.intel.com/content/www/us/en/architecture-and-technology/intel-optane-technology.html

https://www.intel.com/content/www/us/en/architecture-and-technology/intel-optane-technology.html

https://redis.io/

https://redis.io/topics/modules-intro

https://lamport.azurewebsites.net/tla/tla.html

hovercraft: achieving scalability and fault-tolerance for

Documents