Parking packet payload with P4

Abstract

Network Function (NF) deployments suffer from poor link goodput, because popular NFs such as firewalls process only packet headers while receiving and transmitting complete packets. As a result, unnecessary packet payloads needlessly consume link bandwidth. We introduce PayloadPark, which improves goodput by temporarily parking packet payloads in the stateful memory of dataplane programmable switches. PayloadPark forwards only packet headers to NF servers, thereby saving bandwidth between the switch and the NF server. PayloadPark is a transparent in-network optimization that complements existing approaches for optimizing NF performance on end-hosts. We prototyped PayloadPark on a Barefoot Tofino ASIC using the P4 language. Our prototype, when deployed on a top-of-rack switch, can service up to 8 NF servers using less than 40% of the on-chip memory resources. The prototype improves goodput by 10-26% for a Firewall → N AT NF chain and reduces PCIe bandwidth load by 2-58%. With workloads that have datacenter network traffic characteristics, PayloadPark provides a 13% goodput gain with a Firewall → N AT → LB NF chain, without latency penalty. In this scenario, we can further increase the goodput gain to 28% by using packet recirculation. CCS CONCEPTS • Networks → Programmable networks; Middle boxes / network appliances.

NFSlicer: Data Movement Optimization for Shallow Network Functions

“…This section first evaluates NFSlicer's achieved latency reduction for a range of shallow NFs ( §VI-A). We then demonstrate the sensitivity of latency improvement to the fraction of packet payload sliced ( §VI-B) and packet arrival rate ( §VI-C), and compare NFSlicer to a switch-based packet slicing approach like PayloadPark [15]. Finally, we perform an extensive microarchitectural analysis to pinpoint the source of latency overhead for large packets, shedding light on the origins of NFSlicer's achieved latency improvements ( §VI-D).…”

“…On the packet's egress, NFSlicer uses the embedded token to retrieve the packet's corresponding payload and splices it to the processed header, before transmitting the reconstructed packet on the wire. As pointed out in §I, the design of NFSlicer's mechanism is similar to Goswami et al's PayloadPark [15], with the following key differences: (i) NFSlicer targets a NICbased implementation rather than a switch-based implementation that has to conform to fundamental limitations associated with RMT (Reconfigurable Match Table) pipelines; and (ii) instead of partial payload slicing to improve network link goodput, NFSlicer enables entire payload slicing to eliminate data movement bottlenecks between the NIC and the server.…”

“…The basic idea of payload slicing for shallow NFs was recently introduced by Goswami et al's PayloadPark [15]. Although NFSlicer's design bears strong similarity with Pay-loadPark, our contributions are distinct.…”

The benefits of general-purpose on-NIC memory

“…Header-data split. Previous work proposed storing NF packet payload on network switch memory [47]. Storing payload on nicmem is preferable because the NIC: (1) has more memory per host; (2) requires no coordination with switches on dropped packets; (3) allows for CPU offloading (e.g., checksum), which is impossible with switch parking; and (4) simplifies debugging as compared to switches.…”

A survey on stateful data plane in software defined networks

“…Some operations can not be easily implemented in stateful data plane. One typical example is applications that require modifying packet payload, e.g., intrusion detection application that needs to analyze information in payload [32].…”