Paper: CClinguist: An Expert-Free Framework for Future-Compatible Congestion Control Algorithm Identification
Authors: Jiahui Li, Han Qi, Ruyi Yao, Jialin Wei, Ruoshi Sun, Zixuan Chen, Sen Liu, Yang Xu
Presenter: Zhang Liu, Xiamen University
Guest of Honor: Jiahui Li, Fudan University
Q: What is the practical value of identifying which congestion control algorithm a remote flow is using?
A: One important use case is helping operators understand which CCAs are actually deployed in the network, including proprietary or previously unknown algorithms. Cloud providers can then reason about how external flows interact with their own network and choose appropriate policies or configurations. As the number and diversity of CCAs grow, automated identification becomes increasingly useful.
Q: Who is the main user of a CCA-identification system such as CC Linguist?
A: A major target user is the cloud provider. A cloud operator controls the configuration inside its own infrastructure but may not know which congestion-control behavior is being used by remote endpoints across the WAN. Identifying those external CCAs gives the operator more information for configuring and managing its own network.
Q: Can the profile-tree approach scale if the CCA library grows from roughly 15 algorithms to 100 or more?
A: The current profile set is sufficient for the CCAs evaluated in the paper, but a much larger library would require additional candidate profiles. The idea is that CC Linguist can use the expanded profile space to construct a deeper or broader profile tree automatically. In the worst case, if many CCAs behave very similarly, the tree could become substantially deeper. In the experiments reported here, however, a small tree depth was usually enough.
Q: How would the training cost change as the number of CCAs and candidate profiles increases?
A: The worst case can become expensive when many algorithms are difficult to distinguish, because the profile tree may need more levels. In typical cases, the growth should be more moderate. The system also uses incremental training rather than retraining everything from scratch, which reduces the cost of adding new CCAs.
Q: Does BQDF contain enough information to distinguish all CCAs, especially similar or learning-based algorithms?**
A: BQDF captures useful behavioral information, but no single feature should be assumed to distinguish every possible CCA. Some ECN-based algorithms already exhibit similar behavior. Additional signals such as delay, throughput, or loss may help in difficult cases. The broader challenge is that there may not be one universal feature that cleanly separates every current and future congestion-control design.
Q: Why is an automated system necessary if experts can manually tune profiles for relatively stable CCAs?
A: Manual tuning is manageable when the library contains only a few algorithms, but it becomes difficult even at the scale of tens of CCAs. Experts may need to inspect behavior repeatedly and try many profiles before finding one that separates similar algorithms reliably. Automation therefore becomes increasingly important as the CCA space grows.
Q: What happens when CC Linguist cannot accurately distinguish two very similar CCAs?
A: The experiments show that some closely related algorithms, such as PCC variants, are harder to separate. More data and better profiles may improve accuracy, but there is no guarantee that every pair can always be distinguished. Traditional manual inspection is not necessarily an effective fallback because the same behavioral similarity that confuses the classifier can also make expert discrimination difficult. In such cases, the system should at least indicate that the candidate algorithms are highly similar rather than pretending the result is certain.
Q: Is CC Linguist implemented in the kernel, as a user-space library, or as an application-layer system?**
A: The main classifier runs in user space on the receiver side. Traffic-control mechanisms and eBPF are used to obtain or manipulate the network signals needed for the profiles, and the resulting measurements are exposed to the user-space classifier. The deployment is therefore a combination of user-space classification and lower-level measurement or traffic-control support.
Q: Is eBPF sufficient for all of the measurements required by CC Linguist?
A: It is sufficient for the scenarios evaluated in the paper, together with traffic-control tools. For example, the system uses lower-level mechanisms to create bottleneck conditions or manipulate ECN-related behavior where necessary. However, future CCAs or non-TCP transports may require additional measurement tools beyond eBPF.
Q: How would the system need to change for RDMA-based congestion control?
A: The current design mainly targets TCP-style Internet congestion control. RDMA uses a different stack and may expose different control and measurement points, so the same tooling cannot simply be assumed to work. Extending CC Linguist to RDMA would probably require new measurement mechanisms, potentially using programmable network devices. The speaker did not claim to already have a concrete solution for this case.
Q: What is the detection overhead in a large-scale deployment?
A: A single detection takes on the order of tens of seconds in the reported setup. If many servers must be measured, the total work naturally increases. For Internet-scale measurement, the proposed way to scale is to distribute multiple CC Linguist instances rather than relying on one detector.
Q: What future congestion-control directions do you find interesting?
A: One direction is to move beyond a fixed set of handcrafted CCAs and learn a more general model from existing algorithms, then adapt or fine-tune it for different network scenarios. This would treat existing CCAs as knowledge that can be reused rather than designing every new algorithm independently.
Q: Did you try using large language models to generate congestion-control algorithms?
A: Yes, but the experiments suggested that papers alone do not contain enough implementation detail for an LLM to reproduce a high-quality CCA reliably. Important behavior is often encoded in raw experimental data or implementation details that are absent from the paper. In this setting, the raw data appeared to be more informative than simply asking an LLM to read the paper and generate the algorithm.
Q: Why did you choose a Transformer rather than a smaller specialized sequence model?
A: The CCA fingerprints are long time-series sequences, so the Transformer was a natural model for capturing long-range structure. We also tried LSTM/RNN-style models, but their performance degraded on long sequences. Based on those experiments, the Transformer performed better for this task.
Q: Which part of the research was the most challenging?
A: The hardest part was discovering that direct passive observation was not enough. We initially tried to communicate with the sender, collect its natural traffic behavior, and classify the CCA directly, but the accuracy was poor. That led us to realize that an actively constructed profile is crucial — and that one profile is still not sufficient. This insight eventually motivated the profile-tree design.
Q: Does encryption such as QUIC or TLS 1.3 prevent CC Linguist from working?
A: Not necessarily, because CC Linguist does not need to inspect application payloads. Its classification relies primarily on traffic behavior such as sending rate and queuing characteristics. The appendix includes a limited QUIC experiment, but it does not comprehensively evaluate multiple different QUIC CCAs. Extending the system to a wider range of QUIC congestion-control algorithms may require additional tooling beyond the current eBPF-based setup.
Q: What advice would you give to a new graduate student interested in this area?
A: First, learn the classical CCA-identification literature, traffic classifiers, and the behavior of traditional congestion-control algorithms. Then reproduce and deploy existing open-source systems such as CC Linguist and run experiments yourself. Once you understand both the algorithms and the measurement pipeline, it becomes much easier to find new limitations and research directions.