## 5 Results  
In order to verify the efficacy of our design, we analyze the USTC16 dataset in two different scenarios. First, we examine a scenario in which the model is both trained and tested on all attacks, resembling the methods used in literature (Section 2). This allows us to compare our results to those of prior works directly. The second scenario consists of training the model using malicious flows from all but one category, and then testing on the remaining one, mimicking a 'zero-day' attack by treating the tested malicious category as a novel attack. This analysis has not been presented in prior literature referencing this dataset. However, it reflects an especially difficult case for the model to detect malicious traffic in live analysis, demonstrating its potential for real-world applications. Our first analysis scenario consists of feeding a random sample of 6000 flows from each category into the model, using 90% of flows for training and 10% for testing. When using either one or two packets per flow, our model achieves greater than 99.95% testing balanced accuracy after ten epochs of training. We then create a zero-day attack scenario in which the model encounters a new type of malicious traffic by only training on nine of the malicious categories, and testing on the remaining category separately. Our model performs extremely well (>99.5% balanced accuracy) using only one packet per flow against all malware categories except one (Nsis-ay). When using two packets per flow it performs better against Nsis-ay while also performing slightly worse against Htbot. All other categories are identified with nearly 100% recall and precision in either the 1-packet or 2-packet cases. These data are shown in Table 3. The balanced accuracy values are also shown in Figure 2.  
In order to analyze the throughput of our model, we identify the training and testing times in each scenario of USTC analysis and calculate the flows processed per second while running experiments on the hardware described in Section 4. On average, for the one-packet case, training processes 2029 flows per second (fps) and testing 2258 fps. In the two packet scenario, training processes 1600 fps and testing 2286 fps. \begin{table}
\begin{tabular}{l c c} \hline \hline \multicolumn{3}{c}{**Analysis Sample Selection**} \\ \hline
**Dataset(s)** & **Training Samples per Category** & **Testing Samples per Category** \\ \hline USTC16 & 4800 & 1200 \\ UTSA21 & 3000 & 250 \\ CIC17 & 2000 & 150 \\ CIC+USTC & 1500 & 150 \\ CIC+UTSA & 2000 & 150 \\ USTC+UTSA & 2000 & 200 \\ CIC+USTC+UTSA & 1500 & 150 \\ \hline \hline \end{tabular}
\end{table} 
Table 2: The number of training and testing samples taken from each category in each dataset during each separate instance of analysis. Because the benign category of CIC17 contains mixed traffic, we take more from that benign category in all analyses. Specifically, we take 15,000 benign CIC17 samples for training, and 1500 for testing. Additionally, because of the imbalance in the number of benign and malicious categories in the UTSA21 dataset, we take twice as many benign samples for its individual analysis. This suggests that only training time is significantly affected by image size; the difference in testing time is not statistically significant. Since image size is directly based on how many bytes of a packet and packets per flow are analyzed, this implies that once a model is trained, there is no significant detriment to model throughput when using the full two packets suggested by prior research. We then analyzed each of the three previously mentioned datasets alone and in tandem with each other, the results of which are summarized in Table 4. Analysis of only the USTC16 or UTSA21 datasets alone or combined with each other yields extremely high accuracy, but analyses including the CIC17 dataset show poorer detection rates and higher false positive and negative rates. However, analysis of two packets per flow performs better than one packet per flow in each of these cases.