Detecting differentiated services code point values and packet length mismatch in internet protocol packet headers

Convolutional neural network (CNN)

CNNs are designed to handle big, complicated datasets, such as network traffic patterns that include DSCP–Packet Length combinations. This is challenging in the case of regular neural networks, as they need a lot of parameters. Unlike fully connected networks, CNNs are set up like the human visual cortex, where neurons have local receptive fields suited to find specific features in the input (Kattenborn et al., 2021). In this study, these characteristics relate to patterns in packet metadata, where DSCP values signify priority classes and Packet Lengths reflect transmission size behavior. The overlapping receptive fields cover the whole feature space. The lower layers find simpler correlations such as a certain DSCP value with a certain packet size, while the higher layers find more complicated QoS patterns (Mazhar et al., 2023).

Some layers in CNNs use filters, strides, and padding, as well as non-linear activation functions like rectified linear unit (ReLU). Filters, which are usually 3 × 3, are particularly important for finding specific DSCP–Packet Length connections. Strides control how big the filter’s steps are as it moves across the input, while padding ensures that the output dimensions match the input dimensions. Convolutional layers are strategically positioned adjacent to pooling layers, such as max pooling, to efficiently reduce the dimensionality of the processed feature maps while maintaining priority-size relationships (Kikkisetti et al., 2020). The network ends with standard fully connected layers that often use softmax activation for multiclass classification. Each class can be a valid or invalid DSCP–Packet Length pairing. This structured arrangement enables CNNs to progressively discern relationships from simple to complex, thereby improving their efficacy for classification tasks in both image and structured network data (Alzubaidi et al., 2021).

The last layers in CNNs are usually standard, fully connected layers. In situations where there are multiple classes, the last layer usually uses a softmax activation function. This architectural design skillfully incorporates hierarchical features, beginning with basic components like DSCP binary encoding and Packet Length ranges and advancing to more intricate traffic patterns. This quality makes CNNs exceptionally good at predicting packet priority and finding anomalies. Mathematically, the convolution operation in a CNN is written as:

(1) $$C_{\left(x,y\right)}^{\left(l,k\right)}=\sigma \sum _{t=0}^{f-1}\sum _{r=0}^{K_h-1}\sum _{c=0}^{K_w-1}{W}_{\left(r,c\right)}^{\left(k,t\right)}\cdot C_{\left(x+r,y+c\right)}^{\left(l-1,t\right)}+\mathrm{B}\mathrm{i}\mathrm{a}{\mathrm{s}}^{\left(k\right)}$$where $C_{\left(x,y\right)}^{\left(l,k\right)}$ is the output of the neuron at position $\left(x,y\right)$ in the k-th feature map of the l-th convolutional layer. $W_{\left(r,c\right)}^{\left(k,t\right)}$ is the weight of the filter at position $\left(r,c\right)$ for the k-th feature map and t-th input channel. $C_{\left(x+r,y+c\right)}^{\left(l-1,t\right)}$ is the input activation at position $\left(x+r,y+c\right)$ from the t-th input channel of the (I-1)-th layer. $\sigma$ is non-linear activation function $\mathrm{b}\mathrm{i}\mathrm{a}{\mathrm{s}}^{\left(k\right)}$ for the k-th feature map. f is the number of input channels. $K_h,K_w$ are the height and width of the filter (kernel), respectively.

The pooling operation, specifically max pooling, reduces the dimensionality of the feature maps while retaining the most critical patterns, such as the strongest DSCP–Packet Length relationships. For a pooling window of size $P_h\times P_w$it is expressed in Eq. (2):

(2) $$P_{\left(x,y\right)}^{\left(l,k\right)}=max\{\begin{array}{c}{P}_{h-1},P_{w-1}\\ r=0,c=0\end{array}{C}_{\left(x.s+r,y.s+c\right)}^{\left(l,k\right)}$$where $P_{\left(x,y\right)}^{\left(l,k\right)}$ is output of the pooling operation at position $\left(x,y\right)$ for the k-th feature map in the l-th layer. S is stride of the pooling operation. This step ensures that even when input packets vary greatly in length, only the most distinctive DSCP–Packet Length features are carried forward in the network. The fully connected, dense layer processes the flattened outputs from convolution and pooling stages. The direct output of the fully connected layer is computed as

(3) $$z_j=\sum _{i=1}^n{w}_{ji}\cdot a_i+b_j$$where $z_j$ is the pre-activation output of the j-th neuron in the fully connected layer, $w_{ji}$ is the weight connecting the i-th input to the j-th neuron, $a_i$ is the activation from the previous layer and $b_j$ is the bias term. In the DSCP–Packet Length classification context, each neuron activation represents the learned likelihood that a certain combination indicates either correct priority marking or a mismatch. For multiclass classification, the softmax activation function is applied to the output layer, ensuring that the predicted class probabilities sum to one:

(4) $$z_j={\displaystyle \frac{e^{z_j}}{{\sum }_{k=1}^K{e}^{z_k}}}$$where $z_j$ is the logits (pre-activation outputs) for class j and K is the total number of classes. In this study, each class corresponds to a specific DSCP–Packet Length category, allowing the model to distinguish between compliant and anomalous packet markings with high accuracy.

Long short-term memory (LSTM)

Recurrent neural networks (RNNs) are powerful architectures for processing sequential data such as audio samples, weather datasets, and network traffic flows (Kratzert et al., 2024). In QoS monitoring, the sequence of Differentiated Services Code Point (DSCP) values and Packet Length variations forms a temporal pattern that can be effectively modeled using a LSTM network. LSTM is a variant of RNN, which learns these sequences using gating mechanisms to preserve long-range dependencies. LSTM can process sequences over considerable time delays, repeatedly handling each time step until the sequence is completely modeled. This makes it ideal for correlating packet-level features, such as DSCP–Packet Length pairings over extended traffic flows (Wen & Li, 2023).

LSTM excels in learning sequential dependencies in network telemetry by capturing how DSCP assignments evolve alongside Packet Length distribution over time. The network processes successive samples, learning both immediate and delayed effects. It employs ‘cells’ or ‘memory blocks’ to store information from previous samples, enabling the detection of anomalies where packet priority does not align with expected Packet Length ranges. The gating mechanisms determine what information to retain, discard, or update (Sabzipour et al., 2023).

In practice, LSTM operation is simpler than its internal complexity suggests. Hidden unit activations persist across time steps, serving as contextual memory. For DSCP–Packet Length analysis, these activations represent encoded QoS-behavioral states that influence predictions at future steps. Weights are updated from the outputs of each sequence element, guiding the model in determining which temporal features—such as recurring mismatches between DSCP and length—should propagate forward or be discarded. This mechanism supports accurate classification and anomaly detection without loss of critical timing information (Qashoa & Lee, 2023).

At the input layer, for each time step tt, the traffic feature vector including DSCP code, Packet Length, and other metadata is fed into the LSTM cells. The cell states and outputs are updated using Eq. (5):

(5) $$ne{t}_k(t)=\sum _m{w}_{km}{y}^{m\left(t-1\right)}.$$

Here, mm represents the input dimension (e.g., DSCP code and normalized Packet Length) and $t-1$ is the previous time step. The net input $ne{t}_k$ (t) for neuron k is computed as the sum of the weighted outputs from the LSTM cells at $t-1$. Weights $w_{km}$ encode the learned importance of each feature over time, while $y^{m\left(t-1\right)}$ is the output from the m-th cell. The final cell output from the last memory block serves as the temporal sequence representation.

At the output layer, the model transforms this representation into predictions using Eq. (6):

(6) $$y^k\left(t\right)=f_k\left(ne{t}_k\left(t\right)\right).$$

Here, k is the output unit index, and $f_k$ is a logistic sigmoid activation function that compresses outputs to the range [0, 1]. In DSCP–Packet Length classification, this represents the predicted probability that a packet’s priority marking is consistent with its observed payload size. These equations describe the mathematical flow of information within LSTM cells, thus enabling them to capture complex temporal dependencies. By modeling DSCP evolution alongside Packet Length trends, the network learns both normal and anomalous QoS patterns, thus making LSTMs well-suited for predictive analysis and real-time DSCP integrity monitoring in modern IP networks (Venkatachalam et al., 2023).

Dataset

From 2005 to 2025, application usage trends have revealed significant shifts in digital behavior and technology adoption. Gmail has experienced rapid growth, surpassing 90% normalized usage by 2025 (Mileva, 2025), while Outlook has maintained steady enterprise relevance. Emerging after 2009, Weibo has risen swiftly within China’s web ecosystem. Skype peaked in the early 2010s but then declined with the rise of more attractive alternatives like FaceTime. BitTorrent achieved high usage levels in the early years but then declined due to the rise of streaming platforms. Traditional file transfer methods like FTP and SMB-1 declined sharply and were quickly replaced by SMB-2 and cloud storage. MySQL steadily increased in backend usage, reflecting the growth of data-driven web applications. In the field of gaming, World of Warcraft peaked during the early 2010s but has retained a core user base. These trends illustrate a clear movement toward secure, cloud-native, and mobile-optimized applications across all categories.

The USTC-TFC2016 master dataset’s Benign folder contains packet capture (pcap) files that show typical, non-malicious network traffic coming from a variety of services and applications. Each file provides labeled data useful for traffic analysis by simulating actual use of a specific protocol or application. Together, the files create a baseline of normal network behavior for various kinds of protocols. The first category is Web Traffic Related Applications, which includes Gmail, Outlook, and Weibo. Web-based email traffic is contained in the Gmail pcap file. Email traffic from clients is stored in the Outlook desktop-based email pcap file. Traffic information from the social media app is stored in the Weibo-1 to Weibo-4 pcap file. The second category is VoIP/Real-time application with Facetime and Skype. Here, the Facetime pcap file contains traffic data related to video and audio communications on Apple devices, while the Skype VoIP pcap file contains traffic data related to video and voice communication services. The third category is Peer-to-Peer Application with BitTorrent, which contains the BitTorrent pcap file with peer-to-peer traffic used for file sharing. Another content category is File Transfer/Storage Application Including FTP, SMB-1, SMB-2. The FTP pcap file contains data related to file transfer traffic, while the SMB-1 and SMB-2 pcap files contain the earlier and enhanced iterations of Windows file sharing to examine LAN-based file access patterns. The fourth category is Database/Backend Applications with MySQL, which contains the MySQL pcap file with database communication. The fifth and final content category is Gaming Application World of Warcraft with the World of Warcraft pcap file containing data associated with MMORPG game traffic. This variety of application-related transmission of data enables machine-learning and deep learning models to identify typical traffic patterns, thus facilitating an understanding of the traffic pattern within the same dataset.

Conceptualization

The conceptual framework for this research is presented further in Fig. 2. It illustrates the relationship between DSCP classes and corresponding Packet Length ranges, highlighting both matched and mismatched scenarios. Deep learning models, particularly CNN, LSTM, and CNN–LSTM, measure this mapping by learning spatial and temporal correlations between DSCP values and Packet Length distributions from labeled network traffic datasets. CNN layers detect characteristic feature patterns in packet metadata, such as DSCP encoding and length variations, while LSTM layers capture sequential dependencies across traffic flows. This enables accurate classification of whether a DSCP value correctly aligns with its expected packet size category.

The research conceptualized that EF DSCP class is intended for low-latency, low-jitter traffic like VoIP whose RTP frames are typically short and frequent (Abualhaj & Al-Khatib, 2022). Empirical work shows VoIP packets often have exceedingly small payloads, where the header overhead can even dominate, which matches EF’s real-time scheduling intent. Therefore, mapping EF to small, rapid packets reflects both QoS semantics and observed traffic morphology in modern deployments (Huang et al., 2021).

Another direction lies with interactive/streaming video streams (commonly associated with AF4x in operator baselines) with packet sizes that are larger than VoIP but generally below bulk-transfer near-MTU bursts, due to codec framing, buffering strategies, and adaptive bitrate behaviors (Woo et al., 2024). Contemporary surveys of video delivery and network classification characterize streaming flows as sustained, moderately sized packets at steady rates, consistent with an AF ‘assured’ class that prioritizes timeliness without the stringent EF guarantees (Afzal et al., 2023).

Similarly, best-effort traffic (CS0) typically carries bulk transfers (e.g., downloads, backups) which favor throughput and efficiency and thus trend toward large, near-MTU packets. Studies on packet aggregation and buffering reinforce that common Ethernet paths push payloads toward ≈1,500-byte frames for efficiency, aligning with the practice of leaving such flows in CS0, rather than assigning assured/expedited treatments. This CS0→large-packet mapping mirrors both QoS policy and packet-level behavior (Kuaban et al., 2021).

When packets are marked EF yet consistently appear as large, bulk-like frames, the DSCP marking conflicts with the traffic’s morphology. Recent work highlights DSCP manipulation/remarking risks and the limits of relying solely on DiffServ headers for classification. Detecting such anomalies (e.g., EF on bulk payloads) is crucial to prevent unfair priority grabs and to uphold QoS policy integrity in modern networks (Alarood, Ibrahim & Alsubaei, 2023).

Most suitable for deep leaning is EF (46) with small packets (60–200 bytes), AF 4x with medium packets (500–900 bytes), and CS0 with large packets (1,000–1,500 bytes). Mismatches like EF marked large packets are flagged as anomaly pattern and extracted. Through iterative training and validation, the models can optimize their ability to detect these deviations, ensuring QoS integrity and preventing priority misuse.

Dataset

The dataset employed for this study consists of packet capture (pcap) files from the USTC-TFC2016-master Benign dataset sourced from Kaggle, as referenced in Zhou et al. (2021). This illustrates various categories of network traffic, each with distinct QoS requirements pertinent to this study (refer to Fig. 3). The DSCP values in IP packet headers for each transmission enable routers and switches to prioritize traffic according to specific requirements. Thus, it is essential to know the relationship between application types and DSCP values in the raw dataset to construct intelligent models that can identify anomalies, optimize traffic, and enhance network security. Figure 3 illustrates the connections that demonstrate how “DSCP in Transmission” can be derived and correlated with packet length and other fields in the packet headers extracted from the dataset.

Typically, the dataset contains all the IP packet header fields. “Protocol & Port Number” helps identify the application or service, guiding DSCP marking at the sender/router level. “Packet Length, Inter-Arrival Time, and Flow Duration” characterize the nature of the traffic, whether bursty, persistent, or delay sensitive. The header field “VoIP and Gaming Demand Low Latency and Jitter” typically receives EF treatment, while “Web and P2P” is handled by default or assured forwarding, depending on service policy. “Database traffic” often maps to lower priority but reliable DSCP classes like class selector values. Table 1 shows an extract of the dataset contents.

The dataset above has 0x00 values in the DSCP of all the transmission sessions of the packet capture. Thus, it is possible to perform special and temporal analysis with DL, as 0x00 is the same as DSCP value 0, which is DF. This means that the original capture does not use any prioritization; all packets are marked as best-effort traffic. At this point, DL is used to train a model to learn ‘normal’ traffic without separating it by DSCP. In the case of DSCP diversity (e.g., in a live or modified dataset), this can now be used to find problems or expected priority mismatches. However, we cannot learn anything from DSCP variation when all the transmission is ‘best effort’ as it appears in this dataset. This means that we cannot find pure DSCP anomalies without outside information or simulation. Therefore, this research uses the current Benign dataset with 0x00 DSCP as a starting point and manually assigns expected DSCP to each app (see Table 2).

The assigned DSCP values for the chosen application in this study are based on standard QoS practices and the type of application. BitTorrent needs DSCP 8 (CS1) because it is a peer-to-peer (P2P) file-sharing application that sends a lot of traffic in the background. This kind of traffic does not need to occur right away and should not get in the way of more important flows. Class Selector 1 is used for low-priority or background traffic, which is also called “scavenger class”, which allows a DL model to learn how to find the mapping for use on real or changed traffic with different DSCP values to find problems or misuse.

Facetime DSCP 46 (EF) is deemed suitable because Facetime is a video and audio chat app that needs low latency, low jitter, and low packet loss. For voice and interactive videos, EF is the same as DSCP 46. This is particularly important to make sure that the data moves quickly through the network.

File Transfer Protocol moves a lot of data but does not have to be done right away, which is the basis of FTP DSCP 10 (AF11). Usually, it works better with a moderate level of delivery assurance. AF11 (Assured Forwarding, Class 1, Low Drop Precedence) gives file transfers a medium priority, which means they will be done reliably without too much priority.

Gmail DSCP 0 (CS0) because Gmail and other Webmail traffic is normal, best-effort traffic that does not require QoS differentiation. For best-effort delivery without any special handling, we use CS0 or DSCP 0.

MySQL DSCP 16 (CS2) is used because MySQL handles backend and database traffic required by frontend applications. It might need a medium priority to stay responsive but not in real time. CS2 (Class Selector 2) is a common tool for important business applications like databases and transactional systems.

In Outlook DSCP 0 (CS0) sending, receiving, and synchronizing email is not time-sensitive and can be treated as best-effort traffic. That means DSCP 0 (CS0) is the best choice.

For Skype, it is best to use DSCP 46 (EF) because Skype is used for VoIP and video calls similar to FaceTime, requiring low delay and jitter. EF (DSCP 46) ensures that there is as short delay as possible when users are waiting in line. This is especially important for voice and video streams.

World of Warcraft DSCP 46 (EF) is a good fit because such online games send and receive packets in real time and are affected by latency and jitter. It is not VoIP but it improves with EF treatment, which is more user-friendly.

Data cleaning

Publicly accessible datasets such as the USTC-TFC2016-master dataset frequently exhibit constraints such as extraneous features, superfluous headers, and absent values that fail to correspond with the designated research aims. This current research identified the suitable dataset before performing the following (see Fig. 4):

• Download the USTC-TFC2016-master Dataset

• Extract Benign PCAP Files

• Convert PCAP to CSV

• Remove the unnecessary headers field

• Keep DSCP + Packet Length Fields

• Inspect if there is any Missing Values

• Inspect if there is any outlier

• Final cleaned dataset for model training

The first task involves downloading the whole USTC-TFC2016-master dataset for this study and choosing only the Benign category folder containing application-specific pcap files (e.g., Gmail, Skype, BitTorrent) for analysis. In the Benign dataset, the captured transmission sessions do not involve any alteration of the packet header. Hence, there are pure transmissions within various applications, so that the interrelationships among the transmission parameters can be established.

The next task involves changing the pcap files into CSV format, so that they can work directly with the packet-level metadata (see Fig. 5).

This research is centered on DSCP–Packet Length matching for predicting packet priority, thus necessitating the removal of all non-essential columns to solely preserve the DSCP field and Packet Length field from the IPv4/IPv6 headers (Brownlee, 2020; Dhiraj, 2020; Lewinson, 2020). Cutting down the dataset to the most important QoS-related parameters is required for modeling from the entire features of the dataset (see Fig. 6). No outlier was detected, thus ensuring that only clean, representative traffic patterns were sent into the deep learning pipeline, which made the model more reliable in finding priority mismatches.

Performance metric

The performance metric employed in this research is the conventional confusion matrix, modified to suit the context of DSCP–Packet Length matching for predicting packet priority. This matrix sets up the following logic: True Positives (TP) show that the DSCP–Packet Length matches are found correctly according to the expected application priority mapping. False Positives (FP) show that a match is predicted when the DSCP–Packet Length pair should not have matched. True Negatives (TN) show that mismatches are found correctly when the DSCP value and packet length are not consistent with the expected traffic class. False Negatives (FN) show that a valid DSCP–Packet Length match is incorrectly classified as a mismatch. All relevant performance metrics can be calculated using these four parameters.

In this study, four fundamental metrics are chosen to assess the deep learning model’s capacity to identify DSCP–Packet Length compliance and anomalies: accuracy, precision, recall (sensitivity), and F1-score (harmonic mean of PPV and TPR). These are selected due to their established reliability in classification tasks (Diallo, Edalo & Awe, 2024). Accuracy (Acc), which shows how many of the DSCP–Packet Length match/mismatch predictions are right, is calculated using Eq. (7):

(7) $$Acc=\frac{TP+TN}{TP+TN+FP+FN}.$$

Here, TP is the number of correctly predicted DSCP–Packet Length matches, FP is the number of incorrect match predictions, TN is the number of correctly predicted mismatches, and FN is the number of missed correct matches (Li, 2024).

Precision, namely, measuring the proportion of correct DSCP–Packet Length matches among all predicted matches is computed using Eq. (8).

(8) $$Precision=\frac{TP}{TP+FP}.$$

Recall or representing the ability to identify all true DSCP–Packet Length matches is given by Eq. (9):

(9) $$Recall=\frac{TP}{TP+FN}.$$

Finally, the F1-score or balancing precision and recall for DSCP–Packet Length classification (Miao & Zhu, 2022; Zhu, 2024) is calculated by using Eq. (10):

(10) $$F1-score={\displaystyle \frac{TP}{TP+{\displaystyle \frac{1}{2}\left(FP+FN\right)}}.}$$

Experimental set up and procedure

All experiments for DSCP–Packet Length classification and mismatch detection were conducted using the Google Collaboratory cloud-based Jupyter Notebook environment (Magenta, 2020). The environment provided:

• Processor: Intel Xeon CPU (2 cores @ 2.30 GHz)

• Memory: 13 GB RAM

• Python Version: 3.6.9

• Keras Version: 2.4.3 (with TensorFlow 2.x backend)

• GPU/TPU: Optional use for accelerated training

• Libraries Used: NumPy, Pandas, Matplotlib, scikit-learn, TensorFlow/Keras

Colab’s accessibility, GPU support, and integration with Python scientific libraries made it suitable for processing packet metadata, including DSCP values and packet lengths, at scale.

The dataset preparation for the experiment originated from the USTC-TFC2016-master repository. The Benign folder pcap files were extracted, converted to CSV format, and stripped of unnecessary fields. Only the DSCP value and Packet Length fields, and derived labels (DSCP_Label, Length_Label) were retained. This ensured a focus on QoS compliance, detecting mismatches between expected and observed values.

Key preprocessing steps included:

• 1.

  Loading CSV files converted from pcap captures.

• 2.

  Feature Selection: Retaining only packet metadata (DSCP, Packet Length, Protocol).

• 3.

  Label Generation: Binary mismatch labels for DSCP and Packet Length.

• 4.

  Scaling: Applying StandardScaler to normalize numerical features.

• 5.

  Encoding: One-hot encoding categorical protocol values.

This research conducted experiments using the full feature set of the dataset, focusing on DSCP_Label and Length_Label as the primary classification targets. These binary labels captured the presence of mismatches between expected and observed DSCP values as well as discrepancies in packet lengths, thereby addressing critical QoS compliance issues in network traffic. The research experiments were performed using three deep learning architectures: CNN, LSTM, and hybrid CNN-LSTM model. The evaluation process followed two dataset split ratios: 70–10–20% for training, validation, and testing and 80–10–10% for training, validation, and testing.

All experiments were implemented using the Keras DL library with TensorFlow backend. Each model was defined using the Sequential API, and the input-output dimensions were derived from the preprocessed dataset. Based on binary classification, the model output was a single neuron with sigmoid activation, returning the probability that a given traffic record belonged to the mismatch class. The research trained each model for 10 epochs with a batch size of 64 samples that were fed to the network before updating the weights. After training, each model was evaluated on the test set, with performance metrics including accuracy, precision, recall, F1-score, AUC, and confusion matrix. First, the baseline experiment was executed without any feature selection beyond the preprocessing step. The dataset was scaled using StandardScaler, and categorical protocol fields were one-hot encoded. Training was performed for 10 epochs.

The input data of the CNN model received the processed input with N samples × F features. Features included packet metadata such as protocol, packet length, DSCP value, and derived binary mismatch labels. The first 1D CNN layer (128 filters, kernel size 2). Typically, the extraction of spatial patterns in packet metadata would yield the output shape of (features-1 × 128) neuron matrix. The second 1D CNN layer comprised 64 filters, with the output shape (features-2 × 64) neuron matrix. The max pooling layer contained the pool size of 2 and the output shape of a half of the previous dimension, thus reducing complexity and overfitting risk. Finally, the flatten layer flattened the pooled output into a 1D vector to feed into dense layers. The dense layer contained the fully connected layer for final feature integration, while the output layer contained 1 neuron with sigmoid activation to classify “Match” or “Mismatch”.

The LSTM model input data used the same feature set with CNN, but reshaped into samples, timesteps, and features to capture temporal dependencies in packet sequences. The LSTM layer contained 64 units intended to learn sequential dependencies from traffic patterns. The dense layer was a fully connected layer to integrate sequential outputs, while the output layer lay within the sigmoid activation for binary classification.

The CNN-LSTM model input data were the packet features reshaped to feed through the CNN layers for spatial extraction, followed by LSTM layers for temporal sequence learning. The CNN stage contained the first layer (128 filters, kernel size 2), while the second layer had 64 filters. The max pooling pool size was 2 to reduce dimensionality. At the LSTM stage, there were 64 units to capture sequential feature relationships. “Dense + Output” contained the fully connected layer, followed by the sigmoid output.

Training accuracy and loss states

The CNN accuracy and loss curve is presented in Fig. 10. The left side figure presenting the CNN model started with ~99.98% training accuracy and ~99.97% validation accuracy at epoch 1. At epoch 2, it already reached 100% accuracy, showing that it quickly learned DSCP and Length Label patterns. The training and validation accuracy lines remained close, meaning there was no significant overfitting, and the model generalized well to unseen data. The loss curve represented by the right figure indicated that the training loss dropped sharply from ~0.0023 to near 0.00005 at epoch 3. Validation loss followed a similar pattern reaching almost zero, indicating extraordinarily strong convergence. The minimal gap between training and validation loss confirmed stable learning without overfitting. CNN proved to be fast to converge and also stable, while the early high accuracy indicated that the features (DSCP & Length Label) were highly separable, thus facilitating classification.

The LSTM accuracy and loss curve is presented in Fig. 11. The curve started slightly lower than CNN (~99.95%) in training but reached ~99.99% validation accuracy at epoch 2. It showed small oscillations after epoch 4, especially in training accuracy common in LSTM due to sequence learning sensitivity. The loss curve started at ~0.017 in training loss and dropped below 0.0001 at epoch 3. Validation loss closely followed training loss but with small spikes (epochs 6–8), possibly due to sequence irregularities in certain batches. LSTM handles the sequence nature of packet flow, achieving slightly smoother validation performance than CNN in some cases, but it is slower in training and can have small fluctuations.

CNN-LSTM accuracy and loss is presented in Fig. 12, initially achieving ~99.96% but quickly reaching ~100%. The results showed more oscillations compared to CNN and LSTM, reflecting the combined model’s sensitivity to both spatial and temporal feature extraction. The loss curve started low (~0.001) and decreased to near-zero within the first 2–3 epochs. Slight fluctuations across epochs were visible, but validation loss remained consistently low, indicating that generalization was not compromised. CNN-LSTM balances feature extraction from packet-level (CNN) and sequence-level (LSTM) perspectives. While its accuracy was high, the slight instability in accuracy curves was due to the hybrid nature more parameters, which resulted in slightly more variance in training.

Performance realism adjustment

Initially, the results obtained were almost perfect. The model was directionally associated with memorizing the training data and achieving unrealistic scores on the test set and achieved high performance across most epochs. Therefore, the hyperparameter was adjusted by reducing the number of filters/neurons in some layers to lower model complexity. The new results (see Table 3) were still high, indicating outstanding detection performance, but they were now more plausible, more resistant to overfitting, and more acceptable in academic research, where an accuracy of ~99.9%, AUC ~99.98% are common. The CNN-LSTM hybrid model proved to be the most powerful and superior architecture in the current study. It demonstrated perfect classification accuracy, lowest validation loss, and balanced learning across both spatial and temporal domains. The fusion of convolutional and recurrent layers allowed it to learn complex and compound patterns in packet behavior essential for robust DSCP and length mismatch detection.

The CNN model demonstrated quick inference, simple architecture, and strong spatial pattern learning. In comparison, the LSTM model showed strong temporal awareness and effective detection of pattern shifts over time, whereas the CNN-LSTM model combined spatial and temporal learning most suitable for generalization and robustness, which is ideal for high-accuracy and deep packet inspection with behavioral insights. All three models proved to be highly effective in detecting DSCP and length mismatches in packet transmissions. However, CNN-LSTM stood out as the most balanced and powerful, showing exceptional generalization and learning capacity with practical metrics (Accuracy: 99.93%, AUC: 0.9998). While CNN was the fastest and most stable model and LSTM handled temporal sequences well, the CNN-LSTM hybrid model achieved the strongest generalization performance, though with slight training volatility. This tradeoff is acceptable for tasks like QoS anomaly detection, where precision and recall are critical.

The post-adjustment results maintained exceptional performance (>99.8% across all metrics) while being far more credible (see Table 4). This demonstrated that the models can not only memorize patterns but generalize effectively to unseen data.