# A Performance Evaluation for Software Defined Networks with P4
## 5 Results and Analysis of Tier 1--Single Type of Traffic Run
### Case Study 1--ICMP  
The ICMP traffic for the configuration given in Table 1 commenced at the same time. At the client end, Wireshark collected 1000 ICMP packets. Following the completion of the transfer, the average throughput for each connection was recorded. Figure 3 presents the ICMP throughput for _SDN+OvS_ networking and _SDN+P4_ networking, over the three topologies given in Figure 1. For multi-path and grid topologies, the _SDN+P4_ networking has maintained a steady stream of ICMP traffic with a constant throughput of approximately 6300 bps until the end of transmission (see the red line in Figure 3a,b). The _SDN+OvS_ emulation recorded recurring drops in throughput from approximately 6300 bps to 4800 bps (see the blue lines in Figure 3a,b). The same patterns occurred in Figure 3c, the transit-stub network model, with values of approximately 7800 bps for _SDN+P4_ and recurring drops in throughout to approximately 6200 bps for _SDN+OvS_. We accumulated results over ten executions of the experiments to inspect the average values for throughput. However, in Figure 3c, the throughput has registered an aperiodic drop for _SDN+OvS_ as shown by the blue lines. This could be due to one of the two following factors, processing requirements or congestion. When faced with processing requirements or congestion, SDN networks tend to face performance degradation and cause packet loss. The same has also been observed by [PERSON] et al. [66]. We investigated the throughput drop for the _SDN+OvS_ experiments. Figure 4 shows the throughput drops at 12 s and 292 s (Figure 4a,b) together with the Wireshark captures Figure 4c,d at those times for multi-path topology. Out of the two controller states, reactive and proactive, the reactive state was chosen to avoid misconfigurations during the installation of FlowRules when using the Reactive Forwarding application in the ONOS controller. Given that the controller was in a reactive state, PACKET_IN and PACKET_OUT control messages played a crucial role in maintaining ARP/IP address mapping information [67]. The drop in throughput for _SDN+OvS_ resulted from the ARP and LLDP packets, (observed in Figure 4c,d), being routed towards the slow path of the OvS, detouring from the caching layer. A detour occurs when the OvS sends a PACKET_IN message to the SDN controller to resolve the headers. Until a response arrives as a form of PACKET_OUT from the SDN controller, the packet will remain in the switch buffer. Deviating from the caching layer or fast path can create an overhead [68] in the network which leads to a deterioration in performance. Combining _SDN+P4_ has also been instrumental in the work presented by [PERSON] et al. [28], where the P4 architecture has shown a reduced processing overhead. Research by [PERSON] et al. [13], [PERSON] et al. [69], and [PERSON] et al. [70] have established that ARP messages can create a bottleneck in the network due to high volume and frequency [71, 72, 73]. Therefore, deviating from a fast path in the OvS architecture can create a substantial overhead in the network. Processing requirements from the CPU towards the ARP/LLDP packets can also affect the processing of application centric packets, ultimately resulting in a poor quality of service. Since each emulated host represents a networked host with Ubuntu 18.04, the default ARP update time is 60 s. Hence, a periodic ARP update will  
In the _SDN+P4_ experiments, the P4 switch processed headers in parallel, thus, the LLDP and ARP packets did not interfere with ICMP packets in the pipeline. The _SDN+P4_ environment, therefore, did not experience a throughput drop (as shown by the red line in Figure 3). Due to parallel processing for headers and packets, the bmv2 switch was able to process packets faster, reducing delay in the core network. Given the periodic nature of the ARP packets (60 s by default), the exponential growth associated with a higher number of connected devices and ARP storms caused by network outages, a bottleneck may occur if the packets are not processed faster.