## 4 Discussion  
### Related Works  
A Denial of Service (DoS) attack is addressed as a severe issue for SDN. Although there have also been DoS attacks in traditional networks, the centralized control feature makes SDN more vulnerable to DoS attacks. Despite the simplicity of a DoS attack, it can cause critical problems like buffer saturation, flow table overflow, congestion of the control data plane channel, and controller saturation [15]. This paper concentrates on a flow table overflow attack since this attack can be easily launched by an attacker. Because of the seriousness of a DoS attack, various countermeasures to mitigate the table overflow attack have been proposed. The authors of [16] proposed a scheme that detects an attacker and limits the attack rate using a token bucket. The scheme considers a complicated topology and an attack case where the attacker uses a victim as a middle hop. In the scheme, a controller predicts a potential target of the attack after a switch registration phase. It derives virtual graphs that are composed of a switch and paths that use the switch as a middle hop from the network topology. If the degree of the virtual graph is bigger than one, the switch of that virtual graph is treated as a potential target. Then it monitors the potential target using three predefined traffic features. If the attack is detected, the controller creates a token bucket. Then every time a switch that is connected with an attacker host tries to use a victim as a middle hop, the controller removes a token in the bucket. In the case of [9], when an attack occurs, it diverts attack traffic to adjacent switches of a victim. Ref. [8] calculates per-flow scores according to some predefined features. Then the eviction process is performed in the order of importance. Ref. [4] takes a similar method to [14]. It first filters forged packets, and then it assigns importance to flow rules according to some predefined features. Then it makes a victim switch to drop or rate-limit malicious flow for a period. Ref. [8] relies on the OpenFlow eviction mechanism. Since the eviction mechanism starts to work when a flow table is full, this could be less effective. Ref. [4], however, resolved this problem by defining a countermeasure according to flow importance. But, it requires additional configuration depending on network environments. Our work was inspired by some research utilizing dynamic timeouts [5; 6; 7; 17]. Timeout, a basic component of OpenFlow, determines when a flow entry should be removed in a flow table. Most SDN controllers use a static value for a default timeout. Instead of the static timeout, their basic approach is to secure the flow table storage by shortening the timeout of attack flows. [PERSON] et al. proposed an AHTM that optimizes hard timeout using the mathematically analyzed truncated times and blocking probability [17]. The Intelligent Timeout Master in [5] and a scheme in [7] add a cache module in the controller. They cache a flow rule with a timestamp and its timeout value after the flow rule expires. Then if the same flow triggers a packet in an event, the controller assigns a new timeout value using the information in the cache. Unlike other pieces of research mentioned above, [6] uses both hard timeout and idle timeout, but not simultaneously. In the case that a flow is too short or does not have sufficient history, or the flow table is almost overflowed, the controller assigns a hard timeout to the flow. Otherwise, it assigns an idle timeout. The existing studies using the dynamic timeout use either the hard timeout or the idle timeout. The hard timeout is set to reduce unnecessary control traffic by maintaining \begin{table}
\begin{tabular}{c l l l l} \hline \hline  & **Environment 1** & **Environment 2** & **Environment 3** & **Environment 4** \\ \hline Bandwidth & RX: 302 KiB/s & RX: 184 KiB/s & RX: 190 KiB/s & RX: 451 KiB/s \\ consumption & TX: 344 KiB/s & TX: 320 KiB/s & TX: 328 KiB/s & TX: 189 KiB/s \\ \hline \hline \end{tabular}
\end{table}