Experiment description
The aim of FB5G is to test, validate and assess in the 5GinFIRE testbed the performance of FlowBlaze, a novel stateful programmable dataplane engine that can simplify network functions (NF) design and implementation, while providing high performance packet forwarding, and support for future hardware offloading to SmartNICs. FlowBlaze is an abstraction that can be implemented in an efficient DPDK accelerated software engine, conceived to rapidly design and deploy complex network functions hiding the complexity of software optimizations associated to the development of network functions.
The Network Functions tested in this experiment comprise: (i) QoS enforcement using a programmable per-flow token bucket; (ii) server private cluster load balancing; (iii) mobile edge cloud traffic offloading with dynamic GTP-U tunneling.
Load Balancer. In this use case, we implement a load balancer function that assigns TCP connections to a set of web servers in a private LAN, in a round-robin fashion. Directing traffic to a given web server is as easy as configuring a static NAT rule. Nonetheless, the complexity of the use case is in the necessity of keeping track of two different states. A global state is used to store a counter value that is checked for each new flow received by the switch and it is used to enforce the round robin selection. The second one is a per-flow state that binds each established flow to one of the available destination servers and assure the forwarding consistency. That is, the destination web server is selected when the first connection’s packet is received, and all the remaining packets for that flow should be forwarded to that same web server.
Traffic Policer. This use case implements a single rate token bucket with burst size B and token rate 1/Q, where Q is the token inter arrival time. Since in the current FlowBlaze architecture the update functions are performed after the condition verification, we cannot update the number of tokens in the bucket based on packet arrival time before evaluating the condition (token availability) for packet forwarding. For this reason, we have implemented an alternative approximated algorithm based on a sliding time window. For each flow, a time window W = (Tmin − Tmax) of length BQ is maintained to represent the availability times of the tokens in the bucket. At each packet arrival, if arrival time Tnow is within W, at least one token is available and the bucket is not full, so we shift W by Q to the right and forward packet. If the arrival time is after Tmax (Case 2), the bucket is full, so packet is forwarded and W is moved to the right to reflect that B−1 tokens are now available (Tmin = Tnow−(B−1)∗Q and Tmax = Tnow+Q). Finally, if the packet is received before Tmin (Case 3), no token is available, therefore W is left unchanged and the packet is dropped. Upon receipt of the first flow packet, we make a state transition in which we initialize the two registers: Tmin = Tnow − (B − 1) ∗ Q and Tmax = Tnow +Q (initialization with full bucket).
Traffic Offloading Function. The proposed application is set into the context of a generic mobile metro network, in particular it handles the traffic between User Equipment (UE) and Service Gateway (SGW). The FlowBlaze stateful switch, which is running the application, can dynamically offload the traffic between UE and SGW redirecting it to a node closer to the user known as Mobile Edge Computing (MEC) cloud. The main issue for this solution is that the traffic in the core mobile network is usually encapsulated and in most deployments the encapsulation protocol is the GPRS Tunneling Protocol (GTP). GTP identifies a UE flow in a field of 32 bits named Tunnel Endpoint IDentifier (TEID) and in the mobile core network this field has a different value for each direction of the tunnel: UE to SGW and SGW to UE. This feature results in a challenging situation in which a middlebox in between UE and SGW cannot know a priori the return identifier (the tunnel from SGW to UE) associated to a connection initiated by a user. To overcome this issue, the proposed application generates an ICMP echo request directed to a generic node in the core for each new connection seen. When the reply is received, the FlowBlaze node can recognize the back and forth association of the specific UE connection. Once the connection state is stored, the application can dynamically decide to export some user traffic to the MEC, based on programmed policies, e.g. a given destination port or IP address. Moreover, FlowBlaze can perform NAT functionalities as required by the MEC networking configuration.
Experimentation and Results
The topology used to run the experiments comprises a host with three virtual machines and one hardware switch:
- The FlowBlaze VNF is the one in which the FlowBlaze instance runs the Network Functions, subject of these experiments. It has two connection points to the external network with different VLAN IDs, to emulate a point-to-point connection with the other two VNFs;
- DPDK host 1 and DPDK host 2 VNFs are the two hosts that receive and generate traffic, logically connected point-to-point with the two ports of the FlowBlaze VNF;
- HW L2 switch is an external hardware switch operating at layer 2 and actually forwarding traffic between nodes.
Mean values for the measured throughput (in terms of packets per second), in the three use cases.
The three pictures show the mean values of the measured data rates in terms of packets per second and with varying the number of flows. Moreover, each graph shows three different bars for each tested packet size (64, 512 and 1024 bytes). The numerical results of the Traffic Policer application are comparable to the ones obtained with the Load Balancing experiment. It is worth nothing that in the pps scale the blue line (packets size of 1024 bytes) is limited to 1.2 Mpps; this is due to the saturation of the link, since 1.2 Mpps corresponds to 10Gbps for a packet size of 1024 bytes. For what concerns the TOF, as expected, the packet processing speed is slightly worse with respect to the previous two experiments because of the much higher complexity of the Network Function. Anyway, the results are very similar to varying the number of flows, which confirms the scalability of our solution.
Conclusion
The goal of the FB5G project was to deploy and test three network function implementations on top of the FlowBlaze SW implementation, whose latest version is built on top of the DPDK framework. We performed several optimizations in the software that enabled improvements in packet processing speed. With respect to our previous implementation of FlowBlaze, based on raw Linux sockets, we achieved around 100x improvement for what concerns the packets per second metric.
We found that the main performance limitation of our implementation is in the construction of some software modules, one above all is the hash table implementation. In the future, the main challenge would be to increase the packet processing speed by investigating on hardware NIC offloading. For example, the Intel® Ethernet Flow Director, present in many today’s NICs, would enable to perform our hash table operations directly into the NIC.
A fundamental output of this project has been the plug-and-play image we created containing our FlowBlaze open source programmable software switch and the descriptors to replicate the experiments. We hope this would result in an easier way for the networking community to test and use our product.
