## 3 Initial Data Processing: Avoiding Model Bias
### From Packets to Images  
As explained above, we start with the processing of the protocol headers. As shown in Figure 2, a typical network packet includes ETH, IP, TCP, and UDP headers containing information specific to the network conditions at the time of packet capture. In our model, we propose discarding these headers to isolate the payload, thereby retaining only the \"Application Data\" bytes. This task is performed using a data preprocessing step performed using Tshark, available in the GitHub repository link attached to this paper ([[https://github.com/elbisbe/XAI_DL_NetworkPacketClassification](https://github.com/elbisbe/XAI_DL_NetworkPacketClassification)]([https://github.com/elbisbe/XAI_DL_NetworkPacketClassification](https://github.com/elbisbe/XAI_DL_NetworkPacketClassification)) accessed on 14 March 2023). The process is summarized in the paper, but it is a simple filter. These headers should be discarded for several reasons. The first one is that, due to the number of servers in a cloud platform, they do not necessarily provide reliable information on the user's application data (e.g., different Google services share the same IP addresses) [37]. Therefore, a traffic classification would not be correctly made according to the applications. The second reason is that they can easily generate false positives in the neural network model prediction, since it could learn to differentiate an application by using a specific IP address, a specific port, or even unrelated TCP parameters such as the window size. Additionally, this is not necessary in the neural network model, as a known port system would more efficiently leverage port information and avoid overfitting. In addition, other TCP parameters such as the ACK or SYN sequence numbers would not necessarily be used to classify traffic. Once the packet headers are filtered, the payload binary data have to be transformed into an image or another data structure that accepts a convolutional neural network as input. To transform the data into images, we use each byte of information in the packet as a pixel  
Figure 1: Payload images of the packets in two different Chat flows. and represent that value as a grayscale value, i.e., 0 is a black pixel and 255 is a white pixel. This process helps to normalize the dataset and can help in detecting patterns in the image representation of the packets. However, images tend to have fixed sizes, whereas network packets can vary in size: from minimal sizes of 40 bytes to the maximum of the MTU (usually 1500 bytes), even for each class (E-mail, Chat, Video, etc.). Thus, we need all sequences and images to have a fixed size because CNN libraries usually need a fixed input size. When a packet does not reach the size to be transformed as an image, missing data should be filled in. Two solutions are proposed: the first is to fill in the rest of the packet with zeros (zero padding); the second is to fill it in with random values (random padding) [12]. We used the first alternative, as the intention of the model is to only alter the packets that need to be able to be fed into the model, based on input perturbation techniques. Given the different packet sizes, filling with random values would introduce an undesirable noise in the model. In fact, we confirmed that this random padding produced worse performance than zero padding. Packets without payload data (e.g., TCP SYN or ACK segments) were taken out of the dataset, as they would be pitch-black images. This packet-to-image process can be performed for grayscale one-dimensional (1D) or one-dimensional (2D) structures [38], although in other studies, so-called three-dimensional (3D) architectures have also been considered [28]. By 3D images, they mean images with RGB color gamut, not grayscale. This choice of the number of dimensions may affect the performance, both in terms of the accuracy of the model and in terms of the throughput of the system.