Balancing on the edge
Transport affinity without network state

 Abstract
Content delivery networks and edge peering facilities
have unique operating constraints which require novel
approaches to load balancing. Contrary to traditional,
centralized datacenter networks, physical space is heavily
constrained. This limitation drives both the need for
greater efficiency, maximizing the ability to absorb denial
of service attacks and flash crowds at the edge, and
seamless failover, minimizing the impact of maintenance
on service availability.
This paper introduces Faild, a distributed load balancer
which runs on commodity hardware and achieves
graceful failover without relying on network state, providing
a cost-effective and scalable alternative to existing
proposals. Faild allows any individual component
of the edge network to be removed from service without
breaking existing connections, a property which has
proved instrumental in sustaining the growth of a large
global edge network over the past four years. As a consequence
of this operational experience, we further document
unexpected protocol interactions stemming from
misconfigured devices in the wild which have significant
ramifications for transport protocol design.

 P4 is a language for programming the data plane of network devices [1]. The P4 language is developed by p4.org which is joining ONF and Linux Foundation [2]. This API provides a way to program P4 capable devices through DPDK. The purpose of this API is to enable P4 compilers [3] to generate high performance DPDK code out of P4 programs. The main advantage of this approach is that P4 enablement of network devices can be done through DPDK in a unified way: 1. This API serves as the interface between the P4 compiler front-end (target independent) and the P4 compiler backe-ends (target specific). 2. Device vendors develop their device drivers as part of DPDK by implementing this API. The device driver is agostic of being called by the P4 front-end. The device driver serves as the P4 compiler taget specific back-end. 3. The P4 compiler front-end is target independent. The amount of C code it generates is minimized by calling this API directly for every P4 feature as opposed to vendor-specific free-style C code generation. This API introduces a pipeline device (PDEV) by using a similar approach to the existing ethdev and eventdev DPDK device-like APIs implemented by the DPDK Poll Mode Drivers (PMDs). Main features: 1. Discovery of built-in pipeline devices and their capabilities. 2. Creation of new pipelines out of input ports, output ports, tables and actions. 3. Registration of packet protocol header and meta-data fields. 4. Action definition for input ports, output ports and tables. 5. Pipeline run-time API for table population, statistics read, etc. This API targets P4 capable devices such as NICs, FPGAs, NPUs, ASICs, etc, as well as CPUs. Let’s remember that the first P in P4 stands for Programmable, and the CPUs are arguably the most programmable devices. The implementation for the CPU SW target is expected to use the DPDK Packet Framework libraries such as librte_pipeline, librte_port, librte_table with some expected but moderate API and implementation adjustments.