## 4 Example
### Detection Algorithm  
There are mainly two advantages of the proposed DDoS detection approach. Firstly, it can characterize the DDoS attack more accurately through the defined three typical variables P\({}_{1}\), P\({}_{2}\) and P\({}_{3}\). Secondly, it can leverage the central control functionality and the event definition strategy of FlexMonitor to maintain and collect the flow information for DDoS detection, which reduces the complexity of DDoS detection to a great extent. Assume T denotes a monitoring period and the proposed approach will compute the three variables P\({}_{1}\), P\({}_{2}\) and P\({}_{3}\) at the end of each monitoring period. The pseudo-code of the proposed approach is shown in Algorithm 1. Lines 1-7 describe the first phase of the proposed approach and Lines 8-16 describe the second phase of the proposed approach. In the first phase, the controller computes the change rate of the variable P\({}_{1}\) according to the real-time active flow list in the controller. In SDN, when a new flow arrives, the switch will send the corresponding PacketIn packet to the controller and when a flow is no longer active, the switch will send the corresponding FlowRemoved packet to the controller. Therefore, the active flow list can be timely maintained by the controller. If the change rate of the variable P\({}_{1}\) for a server or service is greater than the value \(\alpha\), the corresponding server would be added into the suspected attacked server set. To make further identification, the controller needs to collect some related status and statistics information from the network. For each suspected attacked server or service, the controller often pointedly chooses the corresponding nearest edge switches to make the related status and statistics collection. By this way, the controller can avoid incurring too much monitoring overhead during the monitoring. In the second phase, the controller computes the change rate of the variable P\({}_{2}\) and P\({}_{3}\) for each suspected attacked server or service. Based on FlexMonitor, the approach can adopt two monitoring methods to collect the network status and statistics information: deploying the network event triggers and using customized flow statistics collection algorithm. By combining these two monitoring methods, it can efficiently obtain the required information for computing the change rate of the variable P\({}_{2}\) and P\({}_{3}\). Regarding the network event trigger, the proposed approach defines a specific threshold and its corresponding multiples as the triggering condition and defines the byte statistics of the traffic which is sent to and originated from the suspected attacked server as the basic monitoring data. When the byte statistics of the targeted traffic reaches the triggering condition, the switch would send a triggering message including the corresponding byte statistics to the controller. In this way, the byte statistics information can be collected at low cost. Regarding another monitoring way, it is used to overcome the shortage of the network event trigger in the flow statistics collection. For the suspected attacked servers the total byte statistics of which do not exceed the defined threshold, deploying network event triggers cannot collect its corresponding byte statistics. In this case, the proposed approach uses customized flow statistics collection algorithm to pointedly poll the byte statistics at the end of each monitoring period. If the change rates of P\({}_{2}\) and P\({}_{3}\) for the suspected attacked server or service are greater than the values \(\beta\) and \(\gamma\), respectively, it is determined that the corresponding server or service is attacked by DDoS. Figure 6: The monitoring request for byte statistics of related flows in DDoS attack detection. Assume n denotes the number of the destinations in the network, which is equals to the size of the array Des_List, and m denotes the active flows in the network, which is equals to the size of the array ActiveFlow_List.