## 5 Evaluation  
This section explains the performance evaluation of the flow entry replacement schemes. We set up the SDN environment with 4 servers and 80 destinations like Figure 8 by employing Mininet emulator [24]. The source served as video servers and web servers while the destination served as clients. We used the ONOS controller [19] as the SDN controller. The number of flows was 320. The numbers of the video and web flows were 160 and 160, respectively. The sizes of flow table of switches were varied with 96, 128 and 160 entries. We also evaluated the performance of the FIFO, LFU and LRU schemes to compare with the performance of the SFF scheme. There are two types of flow: web and video. The web flow generated 50 packets and waited for 10 s. The video flow periodically generated a packet per 200 milliseconds. We generated packets for 300 s using the Ostinato packet generator [25]. Source IP and MAC addresses, destination IP and MAC addresses of the packet were used as matching field to see if the packet received by the switch matches the flow entry in the flow table. The flag information to check the flow characteristics as well as the period information to check the matching period of the flow entry was used. Each data set was forwarded via a packet replay tool known as tcpreplay [26]. The optimal value of the weighting parameter \(\alpha\) may vary depending on the network and traffic conditions. In the proposed scheme, the long flow is determined based on the inter-arrival times of packets of the flow. However, the inter-arrival times between packets in a long flow vary because of the packet jitter. So, we need a smoothing factor \(\alpha\) to flexibly wait for the next packet of the long flow. The weighting parameter \(\alpha\) determines the margin time to wait for the next packet. If it is small, the only regular flows, of which packets are arrived very periodically, are maintained as the long flows and get a priority to stay long at the flow table. However, we cannot allow the network jitter occurring in some long flows. If \(\alpha\) is big, a long flow can wait longer than the expected time for the next packet. But, the flow irregularly generating packets can be also maintained as the long flow. Therefore, we need to set the weighting parameter \(\alpha\)  
Figure 8: Topology configuration for evaluation. Figure 7: An example of updating the flow table using the SFF scheme. appropriately. If not, the proposed method chooses the improper flow entries for the flow replacement so that its performance goes down due to high flow entry miss rate. The significance of appropriate \(\alpha\) is depending on the actual traffic pattern in the deployed network. Before fixing the target network, we cannot exactly determine how much the performance is degraded when the inappropriate \(\alpha\) is used. However, in our experimental network deployment, the inappropriate \(\alpha\) has shown about 19% performance degradation at the worst case. We found that the best value of the weighting parameter is 5.0 in our experimental environment. Figure 9 shows the flow miss rate and ratio of delayed packets when the flow table size of each switch is 128 entries. The flow miss rate is the ratio of the number of incoming packet not to find a matched flow entry over the number of total packets. If the flow miss rate is high, the flow entry replacement occurs frequently. The message exchange overhead between the controller and switches using the OpenFlow protocol increase so that the SDN controller overhead increase when the flow miss rate is high. The ratio of delayed packets is the number of packets experiencing delay due to flow miss over the total number of the delivered packets. A delayed packet arrives late at the destination and may not be used in proper time due to jitter. The network jitter may degrade the quality of service and can be large when the ratio of delayed packets is high. So, we have to reduce the ratio of delayed packets as much as possible.