## 3 Initial Data Processing: Avoiding Model Bias  
The very first task we have to solve when working with AI is data preprocessing. Our main goal is to extract features adapted to network packet classification and build models with useful and standardized information. It is also essential to manage the bias in our data, so that the predictions are not only realistic but also accurate and fair. This section details how data preprocessing was handled and the processes, decisions, and developments that were made to ensure, to the best of our ability, that the model is capable of classifying traffic in a real network, avoiding overfitting or model bias. The dataset used in this paper is the experimentation dataset ISCXVPN2016 [33], composed of 25 GBytes of captured data traffic divided into 152 capture files. It is grouped in 42 labels, depending on the application. For our study, we group these labels into general categories representing traffic classes [35], such as Video (Vimeo, Facebook Video, and YouTube), Chat (Facebook Chat, Skype or ICQ), Web E-mail (GMail), File Transfer (FTP), or Audio (Skype). We make this decision because there is no need to look at the Over-The-Top (OTT) service provider to apply fair QoS policies. As a multiclass classification problem, always choosing the same class in a balanced-class situation would yield an average accuracy of \(\frac{1}{\pi\text{ of classes}}\). According to the current literature, some systems reach values close to 90% in class averages [25; 27; 36]. However, one of the main problems detected is that these papers do not make clear the experimental protocol, e.g., how they split the training and test packets. In the case of network traffic, it is especially important to split them correctly to avoid undesired biases. For example, performing a temporal split on a traffic capture of 100 packets would mean that we take the first 70 for training and the last 30 for testing. In that case, we might be training the model on recognizing the start of the connection phase but not the closing part. Thus, the model will exhibit strong biases in a real environment. Then, will this problem be solved if the training and test data are taken randomly? Not necessarily. By using random packets, you are probably using packets from the same flows or sessions in the training and test, causing data leakage. If part of the test information leaks into the training set, the model does not learn to generalize but to detect those related packets by identifiers such as IP addresses, port numbers, or domain names. This is not a realistic case, as it encourages the neural network to learn particular literals of our dataset instead of general conditions. Even if IP addresses and ports are discarded, there might be information in the data that identifies the flow, such as session identifiers or encryption algorithms and keys. In order to give the full context on how to avoid these issues, an overview of the whole process will be made from the time the traffic trace is obtained until it is classified by the neural network. The first step we will perform is to filter from each traffic capture those packets that do not contain payload of the application, for example ACKs, DNS, and other protocols. This is performed to prevent the neural network from training with packets that can be classified by well-known ports in a real application or with DPI techniques. Then, we extract from each traffic capture the individual packets and convert them to binary files. In this step, we also discard Ethernet, IP, and TCP headers, since they do not contain payload from the application, and we want to avoid training with data that depend on the network conditions of the capture. We can take advantage of this process to group the packets by flows by using the quintuple (source IP, destination IP, source port, destination port, transport protocol). This does not mean that statistics are extracted, simply that the packets in the same flow are labeled.