## 6 Results
### Understanding Your Data  
There are some aspects of the data that are worth mentioning: the flow dependence and its effects, the effect of direction of the flow, and the padding of small packets.  
In order to study the impact of flow dependence, we trained the same model with two different datasets. First, we trained the model with just a random split over the packets, as shown in Figure 9. Using a validation set of random packets, we managed to observe that both the training and validation curves overlap, showing an accuracy above 90%. On a first view, this would mean that the model is not overfitting, and the performance is optimal.  
On the other hand, when training and validating the system with independent flows, the performance changed drastically. While the accuracy in training was about 90%, independent flows in the validation set showed that the real number was closer to 65%. That is, the model is not learning to generalize the specific per-class characteristics of the packets, but is learning fixed patterns that are related to the particular flows or servers involved. This overfitting due to data leakage renders the model incapable of handling real-life situations where all data might be coming from systems not present in the training data.  
Second, we analyzed the difference depending on the direction of the flow. Figure 10 shows the Grad-CAM relevance for the class FTP depending on the direction. Both lines show the relevance of each byte of the packet, denoted by its position, when processed by the CNN, showing differences in uplink (client to server) and downlink (server to client) for FTP traffic. Due to the asymmetry of the roles of the client and server in this case, uplink relevance is focused on the first bytes of the packets, where requests should be the most relevant part, while downlink relevance is more relevant in higher bytes. This makes clear that bidirectional flows should not be mixed, since they can have different and confusing behaviors if considered together.  
Third, we studied the impact of padding, that is, filling with extra data when the packet does not reach the desired size of 1024. This can be performed in two ways: (1) using random padding, i.e., adding random bytes at the end of the packet; or (2) using zero padding, i.e., adding 0 bytes to fill the rest of the packet. Although both options might be reasonable, they hide the attribute of the size. If we use the first option, we are considering that the size of the packet is not an important attribute, and we are hiding that information to add data to maintain the entropy as they were encrypted. In contrast, the second option exposes the end of the packet, since models should be able to notice the position of a final position of zeros.  
In this case, we believe that packet size is an important attribute that can intuitively help identify traffic classes, since we expect that larger packets should belong to data  
\begin{table}
\begin{tabular}{c c c c} \hline \hline  & **Precision** & **Recall** & **F-Score** \\ \hline
1D-CNN & 0.845 & 0.86 & 0.852 \\
2D-CNN & 0.734 & 0.71 & 0.721 \\ \hline \hline \end{tabular}
\end{table}
Table 3: Global metrics of the proposed models.  
Figure 9: Training and validation of the base model with dependent and independent flows.  
transfers and smaller packets should belong to other delay-sensitive services. Therefore, we only considered zero padding, as shown in Figure 1; the bottom of the 2D images is filled with black pixels.