Gergely Pongrácz

Removing Roadblocks from SDN: OpenFlow Software Switch Performance on Intel DPDK

Software-Defined Networking (SDN) promises the vision of more flexible and manageable networks, but requires certain level of programmability in the data plane. Such a flexible, programmable data plane implementation is OpenFlow (OF) which these days is seen as primary model of SDN data plane. In this paper we focus on the limitations of OF in packet switching performance. We share some measurement results we collected using an OF 1.3 prototype based on Intels Data Plane Development Kit (DPDK) and we also describe some optimization ideas. While OF 1.0 can be implemented on high-speed Ethernet switch hardware it has certain disadvantages in the area of flexibility. On the other hand OF 1.3 offers good-enough flexibility, but the poor performance of OF 1.3 implementations seems to represent a roadblock to SDN adoption. In this paper we argue that contrast to the common view, the overhead of flexibility is relatively low. We also argue that the apparent difference between a programmable data plane and a state of the art layered data plane is not primarily due to flexibility itself, but because the lack of optimization in case of flexible implementations.

Cheap silicon: a myth or reality? picking the right data plane hardware for software defined networking

Software-Defined Networking (SDN) promises the vision of more flexible and manageable networks, but requires certain level of programmability in the data plane. Current industry insight holds that programmable network processors are of lower performance than their hard-coded counterparts, such as Ethernet chips. This represents a roadblock to SDN adoption. In this paper we argue that contrast to the common view, the overhead of programmability is relatively low. We also argue that the apparent difference between programmable and hard-coded chips today is not primarily due to programmability itself, but because the internal balance of programmable network processors is tuned to more complex use cases. These arguments are backed with calculations and real-life measurements.

Dataplane Specialization for High-performance OpenFlow Software Switching

OpenFlow is an amazingly expressive dataplane programming language, but this expressiveness comes at a severe performance price as switches must do excessive packet classification in the fast path. The prevalent OpenFlow software switch architecture is therefore built on flow caching, but this imposes intricate limitations on the workloads that can be supported efficiently and may even open the door to malicious cache overflow attacks. In this paper we argue that instead of enforcing the same universal flow cache semantics to all OpenFlow applications and optimize for the common case, a switch should rather automatically specialize its dataplane piecemeal with respect to the configured workload. We introduce ESwitch, a novel switch architecture that uses on-the-fly template-based code generation to compile any OpenFlow pipeline into efficient machine code, which can then be readily used as fast path. We present a proof-of-concept prototype and we demonstrate on illustrative use cases that ESwitch yields a simpler architecture, superior packet processing speed, improved latency and CPU scalability, and predictable performance. Our prototype can easily scale beyond 100 Gbps on a single Intel blade even with complex OpenFlow pipelines.

Compressing IP forwarding tables for fun and profit

About what is the smallest size we can compress an IP Forwarding Information Base (FIB) down to, while still guaranteeing fast lookup? Is there some notion of FIB entropy that could serve as a compressibility metric? As an initial step in answering these questions, we present a FIB data structure, called Multibit Burrows-Wheeler transform (MBW), that is fundamentally pointerless, can be built in linear time, guarantees theoretically optimal longest prefix match, and compresses to higher-order entropy. Measurements on a Linux prototype provide a first glimpse of the applicability of MBW.

MACSAD: Multi-Architecture Compiler System for Abstract Dataplanes (aka Partnering P4 with ODP)

Software Defined Networking (SDN) strives for deep programmable hardware and software dataplanes without giving up on performance. Domain Specific Languages (DSL) such as P4 seek to provide top-down high-level capabilities to define the datapath pipeline agnostic to the network platform and independent from any network protocols. At the crossroads, bottom-up industry efforts at the OpenDataPlane (ODP) initiative are pursuing open-source multiarchitecture APIs for dataplane programmability across various networking platforms. Towards P4 code reuse for various targets (portability), we propose MACSAD as a compiler system that brings together the higher-level P4 language and the abstract, target-independent ODP APIs. The demo showcases two P4 applications compiled into heterogeneous datapath platforms supporting ODP.

MACSAD: High performance dataplane applications on the move

Deep programmability of dataplane pipelines is one of the tenets of the evolving Software Defined Networking (SDN) paradigm. Despite recent efforts on high performance programmable devices, achieving fully programmability (protocol independent) of heterogeneous dataplane implementations still pose numerous challenges. The P4 language is emerging as a strong candidate top-down approach to describe a protocol independent datapath pipeline, agnostic to network platforms. Meanwhile, the OpenDataPlane (ODP) project follows an open-source, bottom-up approach seeking multi-architecture APIs to write platform independent dataplane applications. In this paper, we present Multi-Architecture Compiler System for Abstract Dataplanes (MACSAD) as an approach to converge P4 and ODP through a common compilation process delivering portability of dataplane applications without compromising target performance improvements. We validate our prototype implementation through experimental evaluation of L2 and L3 dataplane applications on different target platforms (×86, ×86+DPDK, ARM-SoC).

Cross-Platform Estimation of Network Function Performance

This work shows how the performance of a network function can be estimated with an error margin that is small enough to properly support orchestration of network functions virtualization (NFV) platforms. Being able to estimate the performance of a virtualized network function (VNF) on execution hardware of various types enables its optimal placement, while efficiently utilizing available resources. Network functions are modeled using a methodology focused on the identification of recurring execution patterns and aimed at providing a platform independent representation. By mapping the model on specific hardware, the performance of the network function can be estimated in terms of maximum throughput that the network function can achieve on the specific execution platform. The approach is such that once the basic modeling building blocks have been mapped, the estimate can be computed automatically. This work presents the model of an Ethernet switch and evaluates its accuracy by comparing the performance estimation it provides with experimental results.

Service aware adaptive DRX scheme

Discontinuous Reception (DRX) in Long Term Evolution (LTE) is used to reduce the energy consumption when there is no data transfer for a given user. Current DRX works on a per-UE basis but works with fixed DRX. That is, DRX does not take into account that different services and different terminals have different requirements on Quality of Experience (QoE). We propose an efficient adaptive DRX method that can provide battery saving without degrading QoE of the services. This method utilizes service and terminal knowledge provided by Deep Packet Inspection (DPI) mechanism and modifies the DRX settings adaptively on the fly. This unique work analyses anonymous traffic data from an operational mobile broadband network and emulates the effects of various DRX settings upon this live traffic data. Live traffic has larger variance in the timescale of DRX than it is assumed by models used in state-of-the-art DRX schemes. Thus the proposed method outperforms existing solutions and get closer to the theoretically ideal case.

Capturing the real influencing factors of traffic for accurate traffic identification

In this paper we introduce a novel framework for traffic identification that employs machine learning techniques focusing on the estimation of multiple traffic influencing factors. The effect of these factors is handled with the training of several machine learning models. We utilize the outcome of the multiple models via a recombination algorithm to achieve high overall true positive and true negative and low overall false positive and false negative classification ratio. The proposed method can improve the performance of every kind of machine learning based traffic identification engine making them capable of efficient operation in changing network environment i.e., when the probing node is trained and tested in different sites.

BB-Gen: A Packet Crafter for P4 Target Evaluation

With P4 gaining traction to define datapath pipelines along auto-generated control plane APIs, the protocol-independence and increased flexibility add non-trivial hazards when it comes to functional and in-depth performance evaluation. P4-dependent workload traces are needed along automated methods to populate the tables of the datapath under test accordingly. Without proper tools, manual efforts are required for tedious tasks such as creating appropriate PCAP traces, defining the distribution of field values, and inserting entries in the pipeline tables. To this end, we present BB-Gen, a packet crafter and table generator tool that given a P4 application and a corresponding user configuration results in packet and table traces to carry automated performance evaluation tasks. We demonstrate BB-Gen with P4 applications of increasing complexity (from L2 to VXLAN-based Data Center Gateway), using two different multi-architecture backend compilers (MACSAD, T4P4S) and different targets.