# AccFlow: Defending against the Low-Rate TCP DoS Attack in Drones
## 5 Experimental Results
### Distributed Low-Rate TCP DoS Attack  
In this setup, we design three different simulation settings. In setting one, we have five legitimate TCP flows each with 1 Mbps transmission rate to simulate drone activities, such as Data Transfer and Telemetry and Remote Control Signals. In a real network, the attackers are able to launch different scales of distributed attacks by splitting their traffic into different numbers of synchronized subflows which refer to the individual streams of network traffic that are coordinated or synchronized by the attacker. By dividing their traffic into multiple subflows, attackers can make the attacks more challenging to detect and mitigate, as the traffic may appear more like legitimate network activity. In our simulations, we varied the number of synchronized subflows from 1 to 50 to replicate real-world attacks. (Note that we scale down the number of flows in order to accelerate the simulation. As you can see in our experiment results, the performance of AccFlow is not impacted by the scale of DDoS attacks.) The total aggregate rate of these synchronized attacking flows reached approximately 30 Mbps, which is three times the bandwidth of the bottleneck link. This setup effectively mimics attacks that surpass the network's capacity, resulting in network congestion and potential service disruptions. The attacking period \(P\) is 200 ms and the attacking duration \(D\) in one period is 67 ms to simulate the real attacks. In setting two, we use the same attacking traffic as that of setting one but we have nine legitimate TCP flows each with a different transmission rate, ranging from 0.3 Mpbs to 1.1 Mpbs. This setup mimics diverse drone activities, including real-time adaptive data transmission and adaptive flight planning. The reason we have both setting one and setting two is that TCP uses the max-min fairness [31], where the network first satisfies the flows with smaller demands (lower transmission rates) and then evenly distributes the bandwidth to  
Figure 7: Deployment of AccFlow. flows with larger demands if the network resources are limited. As a result, in a congested network, flows with smaller transmission rates can obtain their fair bandwidth shares more easily than flows with higher rates. Therefore, we need to consider both the two settings in our simulation. In the third setting, we test the effectiveness of AccFlow when attackers are varying their attacking rates from 20 Mbps to 60 Mbps which is more varied. Without loss of generality, we assume that attackers split their traffic into five attacking flows in this setting and we use the same legitimate TCP traffic as that of setting two. We summarize the three simulation settings in Table 1.  
The simulation results are illustrated in Figure 8. Figure 8a illustrates the results for setting one when five 1 Mbps legitimate TCP flows are traversing the network. Since the whole bandwidth of the bottleneck link is 10 Mbps, which is large enough to hold all the legitimate traffic, all the five flows should not experience any packet losses (in this paper, we only consider packet losses caused by network congestions). and achieve their ideal throughput when they are not attacked. As we can see in Figure 8a, AccFlow can effectively protect the legitimate flows from being attacked since the average throughput of the legitimate flows is close to the desired transmission rate. Furthermore, the performance of AccFlow does not degrade as the number of attacking flows increases. Figure 8b illustrates the simulation results for setting two. Note that we set up nine legitimate flows in this setting but we only plot the results for five of them in the figure for a concise presentation. With AccFlow, all nine legitimate flows are able to achieve their desired data rates even under large-scale attacks. In setting three, we vary the aggregate attacking rates from 20 Mbps to 60 Mbps. Again, we plot the simulation results for 5 legitimate flows in the figure.