FlowRefiner: A Robust Traffic Classification Framework against Label Noise

Thank you for your constructive feedback and thoughtful suggestions. We hope that our detailed responses below will address your concerns.

About Originality.

W1: The core technical ideas are direct applications or minor variations of well-established techniques in the label noise and traffic analysis literature

We respectfully clarify that FlowRefiner is not a 'direct application or minor variation' of existing methods, but rather the first work tackling label noise in general and complex traffic scenarios, a challenge that has not been addressed in previous literatures.

Q4: Could you more clearly distinguish your contributions from existing literature? What specific insights or components in FlowRefiner are novel beyond architectural substitutions?

Below, we further clarify our fundamental novelty and distinct contribution compared to prior works such as [1][2][3], in terms of insights, methodology, and differences:

About RAPIER [1] and ULDC [2].

W1.1: The "traffic semantics-driven noise detector" is conceptually identical to prior work ... like RAPIER [1] and ULDC [2]

The mentioned RAPIER and ULDC, which are already cited ([21,37]) and discussed in our Introduction (lines 44–51) and Related Work (lines 101–104).

Insights Beyond [1][2].

Specifically, previous methods (e.g., RAPIER, ULDC) solely rely on samples themself (density or distance) to determine "real label" with simplified assumptions:

• RAPIER requires clear density differences between normal and malicious traffic, binary relabeling samples in densest and sparsest regions accordingly.
• ULDC defines a single center for each class and considers distant samples as noisy, which assumes samples from different classes are obviously separable.

However, our core insight is that general traffic classification tasks are inherently more complex than these simplified assumptions. As illustrated in our manuscript (lines 156-159 and Figure 2):

• Same class samples often exhibit distinct semantics, e.g., MAIL traffic covers both large attachment transfers and quick, small email exchanges with behavior diversity.
• Different class samples may appear semantically similar, e.g., both FTP and p2p traffic transfer files and therefore produce highly similar behaviors.

Methodology Beyond [1][2].

Motivated by this critical insight, where real labels cannot be reliably determined by sample features alone, FlowRefiner introduces the following key novelties:

• Sematics extraction: we introduce pre-trained encoder to extract high-dimentional semantics, which can validly represent traffic behaviors. In contrast, RAPIER and ULDC use AE only to reduce the dimension of the feature for density or distance calculations.
• Noise detection: we innovatively utilize label distribution within semantic clusters to detect label noise, going beyond previous works that identify labels merely via sample distance or density.
• Noise correction: we further refine detected noisy flows according to the confidence of the predictor, which is fine-tuned by clean flows to correct detected noisy samples. In comparison, the 'confidence' of ULDC is simply defined by sample distance.

Differences from [3].

W1.2: Prior work has explored multi-granularity ... with the explicit motivation of improving robustness to noise and variations [3].

We clarify the irrelevance of [3] and FlowRefiner, as the definitions of both noise and granularity in [3] are completely different from ours**:

• Noise in [3] refers to packet loss, retransmission, and disorder in dynamic networks, which is irrelevant to our label noise issues.
• [3] defines spatial granule and temporal granule as neighborhood packets with similar packet size and interarrival time separately. In contrast, our cross-granularity describes the flow- and packet-level classifier.

As detailed above, we firmly believe these explicit distinctions clearly establish FlowRefiner’s fundamental novelty and significant practical contributions, distinctly differentiating it from prior works, e.g., [1],[2],[3].

Lack of Experimental Comparison.

W2: The paper seems to omit the most relevant baselines. The authors should have compared FlowRefiner against other end-to-end noisy label frameworks for traffic.

As stated in Section 4.1 and Appendix E, we included MCRe, an end-to-end malicious traffic label noise method, as the most relevant baseline. Additionally, ULDC claims itself as a data cleaning method instead of an end-to-end method.

Q3: If possible, could you please add related methods like RAPIER and ULDC as baselines?

• RAPIER cannot support multi-classification tasks methodologically, thus it is not applicable to our general evaluation.
• ULDC did not release their source code, but we compared MCRe[22], which is the follow-up work of the same authors that proposed ULDC, in Section 4. And the MCRe paper compared ULDC and achieved better performance.

Nevertheless, we further reproduced ULDC, and the results are as follows:

The results demonstrate that both MCRe and FlowRefiner outperform ULDC. ULDC can not handle label noise because its simple noise cleaning assumption cannot adapt to general scenarios.

Handling of Low-Confidence Samples.

W3.1 and Q2: Can you provide stronger theoretical or empirical justification for the choice that keeps the low-confidence samples? Have you compared this against simply removing or correcting such samples?

We further provide the F1 scores under different processes of low-confidence samples:

The results show that removing or correcting low-confidence samples consistently leads to worse performance. Since such samples are few and ambiguous, keeping their original labels has a limited negative impact but preserves diversity and boundary coverage that benefits model robustness.

Insufficient Detail.

W3.2 and Q1: Did you use a session-aware or time-based splitting strategy to avoid leakage? If not, could you re-evaluate your results with a more robust approach?

We perform strict session-aware splitting to avoid leakage, where each flow corresponds to one sample. Even in the evaluation of packet classification, we still ensure each packet is sampled from a unique flow. This strict setting of traffic splitting avoids potential data leakage with unexpected dependencies, and ensures a fair and robust evaluation of our method’s performance. We will clarify these details in the revision.

We appreciate the thoughtful review and the constructive feedback! We hope the following clarifications and experiments address your concerns.

About Pre-trained Encoder.

W1: The pre-trained encoders rely on existing techniques, with innovation focused on framework design rather than underlying representation learning.

We clarify that the pre-trained encoder extracts the semantics of the traffic from the raw data for FlowRefiner, which is first proposed as the unique insight for effectively detecting outlier labels as noise.

Besides, the point of our innovation is not in traffic representation learning. As stated in the introduction, our core contribution is the first robust framework to address the critical label noise issue in general traffic classification, a problem that is not handled by previous works.

About Parameters.

W2: Key parameters like clustering granularity and majority label counts require manual setting, with no mention of adaptive adjustment mechanisms, which may limit generalization to unknown datasets.

As stated in Appendix F, we use the same parameter settings across all datasets, demonstrating that our method achieves strong performance without extensive tuning. In addition, our parameter design incorporates moderate adaptivity. Specifically, the clustering granularity is used to scale the number of dataset classes, and together they determine the final cluster count. Thus, the clustering can better adapt to different datasets, reducing the need for manual adjustment.

Moreover, we are happy to further explore more automated hyperparameter tuning methods in future work.

About Random Sampling.

W3: Random sampling in packet-level classification may lose critical packet sequence information

We utilize random sampling to obtain varied packet samples from the same flow during training, reducing model overfitting to single samples under label noise. On the other hand, the critical packet sequence information is captured by the flow-level task with the same share-weighted classifier. This design enables our model to leverage both diverse local packet information and global flow-level context, achieving robust performance under label noise.

Time-sensitive Adaptability.

W3: the framework’s adaptability to time-sensitive traffic is not discussed.

Our two-level robust classifier addresses this need, providing both flow-level and packet-level heads and thus supporting different deployment requirements (e.g., time-sensitive traffic). In time-sensitive scenarios, the packet-level classification could be performed to avoid waiting for entire flows.

The packet classification ability is detailed in Appendix G. Under a 20% noise ratio, FlowRefiner achieves F1 scores above 80% on all datasets, while other packet-level baselines struggle to reach 60%. This demonstrates that our method can perform accurate and robust packet-level classification, making it suitable for time-sensitive traffic scenarios.

Computational Overhead.

W4: Computational overhead is not reported.

We reported the time and computational overhead in Limitations of Section 4.5. As stated, our framework currently takes 3 minutes on an RTX 3090 GPU with 2.79 GB of memory.

L2: FlowRefiner requires multiple data traversals and model updates, making edge device deployment difficult.

Note that 'multiple data traversals and model updates' are performed during the training stage. In the testing (deployment) stage, FlowRefiner operates identically to existing deep learning traffic methods, introducing no additional procedures or overhead at inference time.

Response to Questions.

Q1: Have other pre-training methods been considered for semantic extraction? How does it generalize to complex scenarios like encrypted traffic?

We further considered ET-BERT, an encrypted traffic pre-training method, as the encoder of our framework. And the evaluation on two classic encrypted traffic datasets is as follows:

These results demonstrate that our framework consistently improves robustness over the base ET-BERT, especially under high noise ratios, and generalizes well to encrypted traffic scenarios.

Q2.1: How are loss functions balanced between flow-level and packet-level tasks?

We do not introduce additional hyperparameters to balance the losses of the flow-level and packet-level tasks. Concretely, in each training epoch, we first perform flow-level classification and backpropagate its loss, and then conduct the packet-level task using the same encoder weights. This alternating process avoids manual loss weighting and lets the shared encoder learn features beneficial to both tasks.

Q2.2: Is there a risk of performance degradation due to task conflicts?

We are happy to clarify that flow- and packet-level tasks complement each other, rather than causing conflicts. As demonstrated in Table 4 of Section 4.4, we remove the packet-level classification branch (i.e., w/o cross-granularity robust classifier), which leads to lower performance across all datasets and noise ratios. This result highlights that the joint training of flow-level and packet-level tasks is mutually beneficial, without risk of performance degradation.

Q2.3: Can you provide more details on parameter sharing strategies?

We detailed the parameter sharing strategies in Appendix C, Figure 7. In the flow-level classifier, multiple parallel packet encoders process each individual packet from the flow; these encoders share the same weights. The encoded packet features are then aggregated to form the flow representation. This design enables the same parameter encoder could also handle packet data and perform packet-level classification.

Q3: Which network devices can FlowRefiner be deployed on? Can existing network devices’ computing resources support deployment, given that traffic classification often requires line-rate processing in many scenarios?

To further address efficiency and deployment concerns, we performed additional experiments under a variety of hardware settings, including GPU, CPU, and an edge-device simulation:

The edge device is simulated via a single-core CPU, 50% CPU quota, 1GB memory with swap disabled, and instruction set limited to AVX2. These results show that FlowRefiner can be flexibly deployed on a range of network devices, from high-performance GPUs to constrained edge devices.

Q4: Experiments assume uniform noise distribution, but real networks may have localized high noise. How robust is FlowRefiner against non-uniform noise distributions?

We introduce non-uniform (class-dependent) noise evaluation in lines 299-308 of Section 4.2. The details are shown in Appendix H, Table 6, Table 7. Results show that our method can achieve significant performance advantages over the baselines against non-uniform noise distributions.

Additionally, we also evaluate FlowRefiner under real-world non-uniform noise of CICIDS2017 in line 324-331, Section 4.3. The results demonstrate the ability of our method to handle real-world non-uniform noise.

About Limitations.

We appreciate your valuable suggestions. Future work will explore domain-adaptive pre-training techniques and more extreme class-dependent noise scenarios to enhance robustness further.

We sincerely appreciate your time and the positive feedback! We hope our responses below further clarify our work and address your concerns.

About Hyperparameters.

W1: ... thresholds rely on actual experiment datasets, which might affect the generalization among different scenarios.

We are happy to clarify that we apply the same hyperparameter settings across all datasets in evaluation. The consistent robustness demonstrates that our method achieves strong performance without extensive tuning, highlighting its generalizability among different scenarios.

In addition, our hyperparameter design also incorporates moderate adaptivity. Specifically, the clustering granularity parameter is used to scale with the number of classes in each dataset, and together they determine the final cluster count. This allows the clustering process to better adapt to varying dataset characteristics, further reducing the need for manual adjustment.

About Manual Noise.

W2: All datasets' noise come from manually twisting instead of naturally deterioration by time or locations, which makes the noise easier to detect.

We follow widely-adopted practices of symmetric manual noise in label-noise literature in our evaluation. The results show that current methods of traffic classification or label noise learning can hardly achieve good performance under such settings.

Additionally, we evaluated our method on the real-world noisy dataset CICIDS2017 in Sec 4.3, which naturally contains noisy labels according to previous studies [18,19]. As shown in Figure 3 (c), our method successfully identifies 84.61% of the noisy flows under real-world noise, and the accuracy of our noise detection is 81.92%. The results demonstrate the effectiveness of our method under real-world noise.

Response to Questions.

Q1: "Cross-platform dataset consists servral regions and two different operation systems, which make it naturally suitable for better noise setting (for example, India dataset has systematic noise from the perspective of China region data). Can such data setting be used in experiments to furtherly demonstrate the novelty of FLOWREFINER?"

Thank you for the insightful suggestion. However, the described cross-platform dataset scenario primarily reflects domain shifts rather than actual label noise, i.e., mislabeling within the same categories. Since the India and China datasets have different application categories, which are collected according to regional popularity, they cannot directly serve to evaluate under label noise scenarios. We will release our codes and further evaluate FlowRefiner on more scenarios in future work.

Q2: Authors introduced the influence of different settings for cluster number parameter n, majority label count m. However, it will be better to demonstrate the selection basis of noise correlation confidences.

We are happy to provide the detailed discussions about confidence thresholds. The influence to F1 scores of these thresholds on ISCXVPN dataset under different noise ratios is shown as follows.

• The optimal setting for the high confidence threshold is 0.90, which yields the best performance across all noise ratios. When the threshold is set too high (i.e., 0.95), the model becomes overly cautious, failing to relabel flows that could have been corrected, leading to a decline in performance. On the other hand, setting the threshold too low (i.e., 0.70-0.80) can lead to overcorrection by relabeling flows that are uncertain, thereby introducing more potential noise into the raw flows, especially under the high noise ratio.
• For the low confidence threshold, the optimal setting is 0.70. This setting ensures that the flows outside the clean set’s distribution are reintroduced with their original labels, preserving the diversity of the dataset without overwhelming it with potential noise.

Q3: Network traffic can be processed as sequence or images. Author considerd the traffic as images for MAE pretraining, will there be any difference when we consider such data as sequences like what happened in ET-BERT?

We process the traffic into sequences and replace the encoder of FlowRefiner with ET-BERT. The results are shown below:

These results indicate that FlowRefiner maintains strong robustness and significantly outperforms original ET-BERT across datasets and noise levels. Since sequence-based language models typically require significantly greater computational resources than image-based models, FlowRefiner processes traffic as images to remain more efficient and practical in real-world deployments.

Dear Reviewer MEnh,

Please help go through the rebuttal and participate in discussions with authors. Thank you!

Best regards, AC

Thank you for your time and careful review of our work! We hope our responses below address your concerns.

Sample Definition.

Q1: The definition of a dataset sample is unclear — does it refer to flows or packets?

Each dataset sample in our experiments corresponds to a network flow, which is defined by the standard 5-tuple (source IP, destination IP, source port, destination port, and protocol). This is consistent with common practice in network traffic classification literature (e.g., [30, 33]).

Additionally, in our Cross-Granularity Robust Classifier, each packet is sampled from an individual corresponding flow sample to perform pcaket-level classification task, which is detailed in Section 3.3. We will clarify these definitions in the revision for better reproducibility.

Noise Introducing Process.

Q2: How is label noise introduced in the experiments? Is it added by randomly selecting samples or based on a specific pattern?

We introduce label noise following established protocols in label noise learning, e.g., [22][23][24] in our manuscript. Our experiments involve symmetric noise, which is added by randomly selecting a specified percentage of samples (e.g., 20%, 40%, 60%) and uniformly flipping their labels to other classes.

Furthermore, we consider class-dependent noise based on traffic similarity patterns for evaluation in Section 4.2 and Appendix H. As detailed in Appendix H, we introduce class-dependent scenarios by assigning higher mislabeling probabilities between semantically similar classes of traffic.

Failure Cases.

Q3: Can the authors provide a more detailed qualitative analysis of failure cases, such as confusion between specific classes?

Thank you for your suggestion. We present a more detailed qualitative analysis of failure cases using the confusion matrices of ISCXVPN under different noise rates.

At a 20% noise rate, the most significant off-diagonal errors are observed between CHAT and VOIP, FTP and VOIP, and BROWSING and Streaming. These errors typically occur between semantically similar classes. For instance, both CHAT and VOIP are real-time communication applications with overlapping traffic patterns, making them challenging to distinguish, especially under label noise.

As the noise rate increases to 40% and 60%, we observe an increase in confusion among these related classes, particularly among CHAT, VOIP, and FTP. Despite the higher label noise, the main diagonal entries remain dominant, demonstrating the robustness of our method against label noise.

We will include the confusion matrix in the revision.

About Generalizability.

Q4: How well does it generalize across different domains? Does the encoder require dataset-specific fine-tuning or post-tuning, especially as traffic characteristics evolve over time?

In our framework, the pre-trained encoder used in the noise detector is frozen and does not require any dataset-specific fine-tuning or post-tuning. As stated and proved in recent advances (e.g., Ref [30, 32, 33]), well-designed pre-trained encoders can generalize across diverse traffic domains and downstream tasks. Our results on multiple datasets, including the real-world CICIDS dataset, further support this generalizability.

We agree that as network traffic characteristics evolve, continual adaptation is an important direction, and we plan to explore online adaptation and domain adaptation techniques in future work.

About Scalability.

Q5: How do the authors justify the scalability of the framework to real-world deployment?

Our evaluation follows the classic datasets commonly used in the field of traffic analysis [30][32][33], which contain only thousands of flows. However, to demonstrate real-world robustness and scalability, we conduct experiments (Section 4.3) on the CICIDS2017 dataset, which contains over 200,000 flows. Our framework maintains robust performance on this large-scale dataset, indicating its practical applicability for real-world deployment. We will highlight these large-scale results more clearly in the revised manuscript.

Q6: When stating that "the framework takes 3 minutes on a GPU," does this refer to training time, inference time, or the full pipeline duration

The “3 minutes on a GPU” refers to the average total runtime (176.28 seconds) of the full pipeline (including noise detector, label correction, and robust classification) across all four benchmark datasets, measured on a single NVIDIA RTX 3090 GPU. For clarity, we also provide the detailed runtime for each component on all datasets in the table below.

Dear Reviewer 72E3 ,

Please help go through the rebuttal and participate in discussions with authors. Thank you!

Best regards, AC