Huynh Tu Dang

NetPaxos: consensus at network speed

This paper explores the possibility of implementing the widely deployed Paxos consensus protocol in network devices. We present two different approaches: (i) a detailed design description for implementing the full Paxos logic in SDN switches, which identifies a sufficient set of required OpenFlow extensions; and (ii) an alternative, optimistic protocol which can be implemented without changes to the OpenFlow API, but relies on assumptions about how the network orders messages. Although neither of these protocols can be fully implemented without changes to the underlying switch firmware, we argue that such changes are feasible in existing hardware. Moreover, we present an evaluation that suggests that moving Paxos logic into the network would yield significant performance benefits for distributed applications.

Paxos Made Switch-y

The Paxos protocol is the foundation for building many fault-tolerant distributed systems and services. This paper posits that there are significant performance benefits to be gained by implementing Paxos logic in network devices. Until recently, the notion of a switch-based implementation of Paxos would be a daydream. However, new flexible hardware is on the horizon that will provide customizable packet processing pipelines needed to implement Paxos. While this new hardware is still not readily available, several vendors and consortia have made the programming languages that target these devices public. This paper describes an implementation of Paxos in one of those languages, P4. Implementing Paxos provides a critical use case for P4, and will help drive the requirements for data plane languages in general. In the long term, we imagine that consensus could someday be offered as a network service, just as point-to-point communication is provided today.

Higher SLA satisfaction in datacenters with continuous VM placement constraints

In a virtualized datacenter, the Service Level Agreement for an application restricts the Virtual Machines (VMs) placement. An algorithm is in charge of maintaining a placement compatible with the stated constraints. Conventionally, when a placement algorithm computes a schedule of actions to re-arrange the VMs, the constraints ignore the intermediate states of the datacenter to only restrict the resulting placement. This situation may lead to temporary violations of the constraints. In this paper, we discuss the causes of these violations. We then advocate for continuous placement constraints to restrict also the actions schedule. We discuss why their development requires more attention and how the extensible placement algorithm BtrPlace can address this issue.

P4FPGA: A Rapid Prototyping Framework for P4

This paper presents P4FPGA, a new tool for developing and evaluating data plane applications. P4FPGA is an open-source compiler and runtime. The compiler extends the P4.org reference compiler with a custom backend that generates FPGA code. P4FPGA supports different architecture configurations, depending on the needs of the particular application. We have benchmarked several representative P4 programs, and our experiments show that code generated by P4FPGA runs at line-rate at all packet sizes with latencies comparable to commercial ASICs. By combining high-level programming abstractions offered by P4 with a flexible and powerful hardware target, P4FPGA allows developers to rapidly prototype and deploy new data plane applications.

Whippersnapper: A P4 Language Benchmark Suite

As P4 and its associated compilers move beyond relative immaturity, there is a need for common evaluation criteria. In this paper, we propose Whippersnapper, a set of benchmarks for P4. Rather than simply selecting a set of representative data-plane programs, the benchmark is designed from first principles, identifying and exploring key features and metrics. We believe the benchmark will not only provide a vehicle for comparing implementations and designs, but will also generate discussion within the larger community about the requirements for data-plane languages.

Gotthard: Network Support for Transaction Processing

Introduction. Network latency has a significant impact on the performance of transactional storage systems. To reduce latency, systems typically rely on a cache to service readrequests closer to the client. However, caches are not effective for write-heavy workloads, which have to be processed by the storage system in order to maintain serializability. This poster presents Gotthard, a system that implements a new technique, called optimistic abort, which reduces network latency for high-contention workloads. Gotthard leverages recent advances in network data plane programmability to execute transaction processing logic directly in network devices. A switch running Gotthard examines network traffic to observe and log transaction requests. If Gotthard suspects that a transaction is likely to be aborted at the store, it aborts the transaction early by re-writing the packet header, and routing the packets back to the client. Gotthard significantly reduces the overall latency and improves the throughput for high-contention workloads. Background. As network hardware becomes increasingly programmable [4, 3], several recent systems have demonstrated the benefits of tighter integration between the network and distributed applications that run atop. These benefits include reduced application complexity [9], improved application performance [6, 11], better network utilization [10], and more responsive traffic engineering [8]. Gotthard leverages the programmable network substrate to improve performance for high-contention workloads. Gotthard is written P4 [3], allowing the switch to execute transaction processing logic. P4 provides high-level abstractions for network functionality: packets are processed by a sequence of tables; tables match header fields, and perform actions that forward, drop, or modify packets. Moreover, P4 allows for stateful operations that can read and write to memory cells called registers.