## 2 Materials and Methods
### Proposed Scheme
#### 2.2.2 System Design Details
By the count operation of the 2D counting bloom filter, the statistics module also updates the historical record of the expired flow, i.e., how many packets of the flow have come so far. * Timeout Calculation Module  
When a flow rule is installed, the timeout calculation module decides both a hard timeout and idle timeout based on AFD and the statistics from the 2D counting bloom filter. It gets the record of the flow, i.e., how many packets of the flow have come so far, by the query operation of the 2D counting bloom filter. The timeouts are calculated as (2), (3)  
\[TO_{hard}=AFD+\lceil\log_{2}packet\_count\rceil, \tag{2}\]  
\[TO_{idle}=\left\lceil\log_{2}\frac{packet\_count}{AFD}\right\rceil \tag{3}\]  
where \(TO_{hard}\) and \(TO_{idle}\) are the hard and idle timeouts, respectively. In the timeout calculation, the trust level of a flow is assumed to be proportional to the logarithmic scale of the packet_count. Consider an example that flow1 and flow2 have 1 packet and 31 packets, and flow3 and flow4 have 220 packets and 250 packets in the record, respectively. For now, because there is only one packet in flow1, we cannot rule out the suspicion that flow1 is from an attacker. On the other side, we could believe flow2 is not from an attacker because  
Figure 6: (**a**) Statistic Module takes Flow_removed messages to update AFD and 2D counting bloom filter. (**b**) Timeout Calculation Moduletakes Packet_in messages to get history information from 2D counting bloom filter. 31 packets have come so far and there has not been under attack. In this context, flow3 and flow4 can be considered safe since both of them already have more than two hundred packets. The packet count difference between flow1 and flow2 is 30, which is the same as the difference between flow3 and flow4. However, the trust level differences are not the same. While flow2 can be considered much more trustable than flow1, flow4 is not that much more trustable than flow3 because both flow3 and flow4 have already a sufficient number of packets. Therefore, it is reasonable that the logarithmically scaled packet count is added to AFD. Since AFD is zero at the initial state of the network, we cannot calculate timeouts from (2) and (3). Therefore, the predefined values are assigned to the hard and idle timeout. Once AFD is updated, the timeout calculation module starts to calculate timeouts from (2) and (3). According to (2), the baseline of the hard timeout is set to AFD. This gives a short hard timeout to a new (untrustable) flow. For example, if an attacker sends attack packets to a switch, the average flow duration of the network will be decreased. In this case, the hard timeout of a reliable flow could be shortened as well. To prevent this situation, the timeout calculation module determines a hard timeout by adding additional seconds to the AFD. The extra seconds logarithmically increase in proportion to the corresponding packet count. A hard timeout that will be assigned to both new normal and malicious flows is only AFD because both of them have no record. In a normal situation, AFD is not too short. If an attack occurs, the number of attack packets increases and AFD decreases gradually. Therefore, the shorter hard timeout will be set to all the flows. However, the normal flows will get a longer hard timeout due to the additional seconds as the number of incoming packets goes up. On the other hand, the attack flows with the short hard timeout will expire and be removed shortly. After the hard timeout calculation, the timeout calculation module calculates and assigns an idle timeout to detect long packet intervals within the calculated hard timeout. The idle timeout calculation follows (3), which increases in proportion to a packet count and is inversely proportional to the average flow duration. In other words, a longer idle timeout is assigned to a flow with more historical records. shows the workflow of the timeout calculation module.