CCA Reimagined:
An Exploratory Study of Large Language Models for Congestion Control
arXiv:2604.03857v1 [cs.NI] 4 Apr 2026
Xiaoxuan Qin∗ Yufei Wang∗ Longfei Shangguan School of Information and Computing University of Pittsburgh, Pittsburgh, USA {xiq33, yuw384, longfei}@pitt.edu
Abstract
satellite links [17, 33], where link quality and bandwidth can fluctuate rapidly, making a fixed policy a poor fit. For instance, these handcrafted CCAs would misinterpret a transient RTT spike from wireless jitter as congestion and reduce CWND unnecessarily, hurting the throughput. Recently, advances in large language models (LLMs) have demonstrated surprising generalization capabilities [3, 19]. As these models scale, they often manifest emergent abilities, such as logical reasoning, planning, and adaptation, that were not even explicitly trained on [28]. Through in-context learning and few-shot prompting, they can rapidly adapt to new tasks and domains without retraining. Moreover, recent work [11] has demonstrated LLM’s planning capacity: integrating contextual signals and constraints to generate multistep action sequences that achieve goals under uncertainty and across heterogeneous environments. Congestion control shares similar characteristics, functioning as a sequential decision-making problem under dynamic network conditions [16]. This motivates us to investigate whether an LLM can serve as the decision rulemaker in this control loop, which directly proposes the next CWND to achieve low latency and high throughput in different network conditions. Our hypothesis is that the LLM’s capacity for complex, context-aware reasoning might enable it to move beyond static, handcrafted rules and instead dynamically adapt CWND decisions timely and effectively. Although the high-level idea of using LLM for congestion control is appealing, many open questions remain unanswered. For instance, what network information should be exposed to the model to enable effective CWND adjustments? To what extent can an LLM interpret such signals to achieve an improved throughput–latency tradeoff? Are techniques like in-context learning and prompt tuning, etc., adequate with minor modification? Or is a clean-slate design necessary? Can an LLM-based policy ensure fairness across multiple flows, a long-standing objective in transport layer? In this paper, we conduct an emulation-guided study to answer these open questions. We first derisk the design: under a static network with a single flow, can an LLM-based approach achieve latency–throughput tradeoffs comparable to, or even surpassing, those of existing congestion control al-
In this paper, we conduct an emulation-guided study to systematically investigate the feasibility of Large language model (LLM)-driven congestion control. The exploration is structured into two phases. The first phase derisks the whole capability where we isolate the role of LLM on a single yet crucial congestion avoidance phase so that we can safely examine when to invoke the LLM, what information to provide, and how to formulate LLM instructions. Based on the gained insights, we extend LLM’s role to multiple congestion control phase and propose a more generic LLM-based congestion control policy. Our evaluation on both static and dynamic network traces demonstrates that the LLM-based solution can reduce latency by up to 50% with only marginal throughput sacrifice (e.g., less than 0.3%) compared to traditional CCAs. Overall, our exploration study confirms the potential of LLMs for adaptive and general congestion control, demonstrating that when granted appropriate control freedom and paired with an effective triggering mechanism, LLM-based policies achieve significant performance gains, particularly under highly dynamic network conditions.
1
Introduction
TCP congestion control remains one of the most critical yet challenging aspects of the network transport layer design. At its core, congestion control is modeled as a goal-directed control loop that, at each sampling instant, the sender is required to choose the next Congestion Window (CWND) that best balances latency and throughput using only sendervisible network information. Despite multi-decades research [15, 5, 12, 13, 7, 6], existing congestion control algorithms (CCAs) all share a fundamental limitation: they rely on hardcoded, static rules for CWND adjustment [21, 4]. For instance, TCP Reno follows an additive-increase/multiplicative-decrease (AIMD) rule, while CUBIC employs a fixed cubic growth function. This rigidity leads to sub-optimal performance in modern, highly dynamic settings, such as 5G cellular networks [25, 31] and * These authors contributed equally as first authors.
1
gorithms? We start with granting the LLM limited freedom, allowing it to modify CWND during the congestion avoidance phase while adopting TCP-NewReno for initialization and packet loss handling (§4). This setup allows us to isolate the role of the LLM on a single yet crucial congestion avoidance phase, enabling us to examine three key questions: when to invoke the LLM (§4.1), what information to provide (§4.2), and how to formulate the LLM instructions (§4.3). Building on the insights gained from these explorations, we next extend our study to three dynamic network traces to evaluate the algorithm’s generalizability (§4.4). Our deepdive investigation (§4.5) on the delay, CWND, and queue size over time demonstrate this vanilla LLM-based policy, namely, TCP-LLM-L (where L stands for limited), can selfadaptively balance the RTT and throughput and achieve better performance than 11 baselines (including Bbr, Cubic, etc.), particularly on highly dynamic network conditions. In the meantime, we observe that the limited freedom granted to the LLM leads it to favor decreases or no-change actions on CWND control, rarely attempting increases, which caps its ability to fully exploit available bandwidth. This observation motivates us to generalize LLM-based control across multiple congestion control phases (§5). To achieve this goal, we propose to use ACK count as another crucial input to LLM (§5.1) and design an iterative prompt refinement policy to gradually optimize the LLM’s prompt (§5.2). We examine the performance of this new congestion control policy, namely, TCP-LLM-G (where G stands for generalized) in three real-world, dynamic network traces. We further unpack this TCP-LLM-G’s CWND control operations and compare against the baseline TCP-LLML (§5.3). The results show that the generalized action space together with the ACK-based trigger makes TCP-LLM-G more adaptable across diverse topologies, consistently balancing latency and throughput better than TCP-LLM-L. Moving beyond the one-to-one topology, we further explore multi-sender competing for a single link, with the goal of examining the fairness among these competitors in both homogeneous and hybrid network setups over all four realworld network traces (§6). Moreover, we use GPT-5 [23] to translate these LLM-guided congestion control policies into formalized algorithms (§7), with the goal of figuring out their difference with existing hard-coded CCAs, and further better understanding why they achieve better performance in lowlatency and high-throughput. Through this step-by-step, emulation-guided exploration, we systematically investigate the feasibility and challenges of leveraging large language models for network congestion control. Our findings not only reveal the potential of LLM in congestion control but also establish foundational principles for future research. Specifically, our key contributions and core takeaways from this exploration are as follows:
make decisions (even with zero-shot prompting) when provided with relevant historical context and instructions consistent with their pre-training. • Degree of control freedom: Maximizing an LLM’s generalization in congestion control requires granting it ample freedom in its decision-making space. • Triggering mechanism: An efficient triggering module is crucial. Latency-based triggers were too conservative, while ACK-based triggers offer better adaptability but depend heavily on threshold tuning. • Fairness: LLM-based congestion control achieves fairness among LLM flows, but is outcompeted by the aggressive CWND growth of conventional CCAs.
2
Related Work
We review related works in this section.
2.1
Learning-Based Congestion Control
Early works on machine learning for congestion control focused on automating the design of TCP algorithms to break free from fixed set of heuristic rules. A landmark example is Remy [29], which uses an offline model-based optimizer to synthesize a congestion control algorithm designed to network assumptions and performance objectives. PCC[7] and PCC Vivace[8] take a further step forward towards online learning-driven congestion control that can be adjusted in real time through utility-guided experiments. Their experiments demonstrated the potential of enabling real time adjustments in CCA through learning-based approaches. With advances in deep reinforcement learning (DRL), more recent works apply DRL to congestion control, viewing the CCA as an agent that observes network state and adjusts the sending rate or window for actions. Pioneer work Aurora [16] employs PPO (Proximal Policy Optimization) to train a neural network for sending rate control. Later on, several works [10, 27, 32, 9, 1] exploit different DRL techniques. These approaches achieve desirable throughput and latency under the conditions they are trained on, but because they are typically trained offline in simulated networks, they often fail to generalize to unseen environments, as pointed out in Mutant [24]. Mutant instead ensembles multiple existing congestion control algorithms. It continuously monitors their performance under current conditions and dynamically selects CCA rules, effectively “mutating” its behavior in real time. Building on Mutant’s philosophy of online adaptability, we investigate how LLMs’ generalization capacity can be used to create a CCA agent that dynamically balances throughput and latency under varied network scenarios without the restrictions of existing predefined CCA rules.
• LLM reasoning in CC: LLMs can effectively reason and 2
TCP-LLM Initialization
WAN Congestion Avoidance
Loss Event
LLM Control ?
TCP-BBR etc.
…
# of ACKs
Intervention Phase LLM Input
OR
Decrease CWND multiplicatively if…
CWND
Increase CWND additively if…
Throughput
…
…
An underutilization of the bandwidth…
# of retransmitted packets
General Instructions
Stats History
TCP-BBR etc.
Latency LLM
Trigger Module
Sender-view Network Statistics TCP-LLM
Features
Senders
Bottleneck Link
Receiver
Hybrid topology with sender nodes using TCPLLM and traditional TCP CCAs, connected through a single bottleneck link between routers to one receiver.
Figure 1: Overview of the design of TCP-LLM in a hybrid WAN topology, which is developed following main questions: (1) How much freedom should LLM be granted? (Sec 4 VS. Sec 5) Probed via abstraction of the congestion control problem into three phases and deploying LLM in different phases. (2a) When to invoke the LLM? (Sec 4.1, Sec 5.1) Addressed through building latency-based and ACK-based trigger module. (2b) What information does LLM need? (Sec 4.2, Sec 5.2) Explored by comprising three different components of general instructions, network statistics features, and statistics history.
2.2
Applying LLM to Networking Domain
A central methodological question then arises: how much freedom should the LLM be granted in this multi-state control loop? Blindly granting broad control across all protocol states risks instability and even violations of TCP invariants. These risks arise under partial observability (senderonly view), delayed and asynchronous feedback, and nonstationary cross-traffic that would make RTT/throughput signals drift and become ambiguous. For instance, by the time the LLM reacts to an observed loss, the congestion window it decided to shrink may no longer reflect the current state of the network, causing oscillations. Conversely, if the model is over-constrained, potential gains from LLM’s generalization ability may be forfeited and the problem might be reduced to a trivial policy. To further understand this trade-off, we organize our study around two guiding questions that together determine the LLM’s reasonable scope of intervention:
The problem-solving capability of LLMs has motivated their application to networking problems. NetLLM [30] was proposed as a framework to investigate how a single pre-trained LLM can be adapted to understand and handle diverse networking tasks, such as video streaming rate control. It’s SOTA performance across multiple tasks suggests that pretraining has embedded meaningful networking knowledge within these models. We view the problem of applying LLMs to new domains as a challenge of asking the right question in the right way. Motivated by this perspective, we conduct an exploratory study to investigate the requirements and design considerations for employing an LLM for congestion control that can break out the boxes of existing CCAs. We are not the first applying LLM to congestion control. There are several works [26, 14] have already took the first leap, but they have primarily focused either on allowing the LLM to select an existing CCA [26] or to augment the rules of a specific CCA [14]. We instead take a ground-up approach to study whether an LLM can serve directly as the controller and rule-maker, generating values to adjust sending rates instead of merely selecting or modifying an existing algorithm. We envision our exploration results and takeaways can spawn many new ideas on leveraging LLM for congestion control.
3
• Q-(a): When should the LLM be triggered? • Q-(b): What information does the LLM require to reason about CWND adjustment effectively? For question (a), triggering LLMs should balance the congestion control performance with practicality and cost. Triggering LLM too frequently is usually not practical: it incurs API call cost, and may cause asynchronous actions from observations due to model inference latency. What we need, therefore, are reliable signals that indicate a meaningful opportunity for intervention. In other words, the challenge becomes finding well-defined moments in the congestion control process where sender-visible feedback is strong enough to justify invoking the LLM model. We present the design in response to this challenge in §4.1 and §5.1, respectively. For question (b), we proceed by specifying what the LLM model can reliably observe at the sender in real-world deployments and how that information should be represented. We initially consider five candidate features: CWND, RTT, throughput, number of retransmitted packets, and network topology. We exclude topology because router-level conditions along the path cannot be directly observed or reliably
Defining Protocol States and LLM Intervention in Congestion Control
To precisely bound where the LLM may intervene, we follow existing CCAs and model congestion control as a discrete set of protocol states: initialization, congestion avoidance, and packet loss, with the latter defined by 3-duplicate ACKs or timeout signals [12]. * Each state carries a distinct control objective and risk profile for adjusting CWND. * Note that in most CCAs, there is a fourth phase: fast retransmit/fast recovery. In our study, we abstract this into a single packet loss phase, which covers both loss handling and recovery.
3
4.1 1000 Mbps 5 ms
10 Mbps
1000 Mbps 5 ms
10 ms
An essential design question is determining when to invoke the LLM to adjust CWND. This requires a trigger module that continuously monitors network conditions and decides whether an adjustment should be applied. In conventional loss-based congestion control algorithms such as TCPNewReno, congestion is detected through packet loss signals. However, these signals are inherently delayed, as the receipt of 3-duplicate ACKs indicates that congestion has already occurred. To enable earlier intervention, we adopt a latency-based approach inspired by existing delay-sensitive congestion control schemes (e.g., Bbr [6]), which treat RTT growth as an early indicator of congestion rather than waiting for loss. Specifically, we monitor the latency of the most recently sent segment, and if it exceeds a predefined threshold, we trigger the LLM to adjust CWND. Choosing an appropriate threshold for congestion detection is inherently a critical challenge. Rather than relying on arbitrary, hand-tuned values that may not generalize across different network conditions, we adopt a more adaptive approach. We first run a short simulation using standard TCPNewReno and record the latency at the moment when the first packet loss occurs (for example, in the one-to-one static topology it is 160ms), using it as an estimate of the latency level associated with true congestion. One thing to note is that this estimation can be rerun if the network condition is detected drastically changed. To set the final triggering threshold, we scale this baseline latency by a factor α (where α < 1), allowing the system to detect congestion proactively before losses occur. We conduct an ablation study on the choice of α and its influence on performance in §B.1. In essence, the choice of α serves merely as a tradeoff parameter between cost and performance, rather than a requirement for the system’s correctness. In our experiment, we chose α = 70% for better performance with limited cost. To ensure that the impact of an LLM-triggered adjustment is accurately reflected in subsequent network statistics, we introduce an additional timing constraint. Since changes to CWND require time to propagate through the network and influence measured metrics, invoking the LLM immediately after an adjustment risks basing decisions on outdated or transient observations. To mitigate this effect, we enforce a waiting period of two seconds between consecutive LLM activations. Consequently, the LLM is triggered only when the observed latency exceeds a threshold and at least two seconds have elapsed since the most recent intervention.
Bottleneck Link Sender
Receiver Queue
Queue
100pkcs
100pkcs
Figure 2: The topology used in LLM exploration.
maintained at the sender side. This yields a compact, senderonly feature set: CWND as the primary control variable; RTT and its short-term trend as proxies for latency; throughput and its trend as indicators of bandwidth utilization; and the recent count of retransmissions as a direct signal of loss. We discuss the specific use of these features in §4.2 and §5.2. Based on the above analysis, we plan a staged approach to derisk the use of LLM in congestion control. We first constrain the LLM’s intervention to the congestion avoidance state (§4), where adjustments are incremental and the risks of destabilizing the flow are relatively contained. This allows us to evaluate whether the model can meaningfully achieve on-par or improvement over static policies in balancing latency and throughput without jeopardizing correctness. We then extend its scope to other states (§5). This incremental roadmap allows us to assess trade-offs systematically and establish guardrails before granting the LLM broader control.
4
When to Invoke the LLM?
De-risking with Boundaries: LLM in Congestion Avoidance
We begin by granting the LLM limited freedom, allowing it to modify CWND only during the congestion avoidance phase. We start with the congestion avoidance phase because it is not only the longest and most frequently encountered phase in a congestion control run, but also the phase that offers the greatest flexibility for LLM intervention. To explore the LLM-based control for congestion avoidance, we implement a two-node network topology interconnected with two routes using NS-3† , as shown in Fig. 2. This controlled setup enables us to isolate and directly observe the effects of our design choices. For the initialization and loss phases, we directly employ the mechanisms of TCP-NewReno. In addition, during the congestion avoidance phase, if LLM is decided not to be triggered upon receiving an ACK, we also employ the mechanisms of TCP-NewReno. We choose to build upon TCP-NewReno because it is both widely adopted and analytically simple. Its AIMD rules produce straightforward, easily recognizable patterns in traces, which allows us to isolate the role of the LLM without interference from more complex behaviors such as Bbr’s probing. To prevent the system from reverting to the initialization phase when the LLM generates a new CWND, we enforce the condition that the resulting SSTHRESH is equal to the updated CWND. We use GPT-4o-mini [22] as the LLM.
4.2
What to Tell the LLM?
To leverage the pretrained knowledge of the LLM for congestion control, we should determine what information should be provided to enable meaningful adjustments to CWND. Following the standard structure of LLM prompting, the input consists of two components: general instruc-
† https://www.nsnam.org/releases/ns-3-43/
4
RTT (ms) Type Few-shot? Avg. Std. (a) Instruction Scheme / Few-shot Math 125.94 1.15 Natural 92.83 3.54 Natural + 113.21 2.02 (b) History Length H experiment H =1 110.57 5.78 H =2 95.99 4.49 H =3 95.30 3.18 H =4 92.83 3.54
Math Prompt Scheme System Prompt: You are an expert congestion controller in wide area networks. Inputs: {Inputs Math Symbols: last_cwnd := c_{t-1} ...}. Update rules (produce next_CWND = c_{t+1}, next_SSThreshold = s_{t+1}): (1) Congestion: If rt > rt−1 and Tt ̸> Tt−1 , choose a multiplicative decrease factor β ∈ (0.5, 1), and set ct+1 = max(⌊β · ct ⌋, MSS)...
Throughput (Mbps) Avg. Std. 9.99 9.99 10.00
0.00 0.00 0.00
9.99 9.99 9.99 9.99
0.00 0.00 0.00 0.00
Table 1: A sketch of math prompt. Table 3: Performance results: (a) Instruction scheme and zero-shot vs. fewshot, and (b) History length H experiment. Notice that because the LLM was run with zero temperature (deterministic outputs), under a restricted action space, and in a stable-bandwidth network environment, the variability across repeated runs was negligible. Consequently, the reported standard deviations round to 0.00 when shown to two decimal places.
Natural Prompt Scheme System Prompt: You are an expert congestion controller in wide area networks. Based on the following input parameters: {Input Explanations: last_cwnd: The previous congestion window size...}. Modify
The guiding rules direct the LLM to first assess whether congestion is present. If congestion is detected, the LLM is instructed to reduce CWND; otherwise, it may either increase CWND when bandwidth appears underutilized or leave it unchanged when performance is satisfactory. The performance comparison of these prompt designs is presented in part (a) in Tab. 3. We observe that the Math scheme leads the LLM to closely emulate TCP-NewReno’s behavior, strictly adjusting CWND according to the formulas, and thereby resulting in performance similar to TCP-NewReno. This indicates that the intervention does not leverage the LLM’s generalization ability, and is therefore not meaningful, given that triggering the LLM incurs higher cost than directly using TCP-NewReno. In contrast, the Natural scheme yields improved performance, which we attribute to its closer alignment with the LLM’s pretraining data. Since the word-based instructions avoid explicit numerical constraints, they leave greater flexibility for the LLM to adjust CWND more effectively. During this process, we observe that the LLM occasionally outputs adjustments of less than one segment, which are not meaningful; therefore, we add explicit rules instructing the model to generate only valid values that comply with TCPsafe guardrails. We include the final prompts in Appendix Tab. 4. Furthermore, to provide sufficient context for detecting trends in network dynamics, we extend the input with multiple rounds of historical statistics. For example, a history length of 3 includes the statistics from the 3 most recent segments. From part (b) in Tab. 3, we observe that as we increase the length of the history, the average latency of the system reduces, which is indicating that a longer history might help the LLM gain a better understanding of the network condition.
cwnd and ssthreshold according to the following rules: 1. Decrease cwnd multiplicatively if there might be a congestion. 2. Increase cwnd additively if there might be underutilization of the bandwidth... Table 2: A sketch of natural prompt.
tions, fixed across all queries, and input features, which vary with current network conditions. This separation ensures consistent guidance while enabling responsiveness to network dynamics. We first specify generalized instructions that define congestion and set the dual objectives of maximizing throughput and minimizing latency. These instructions remain fixed during feature selection, where we identify the most informative network statistics. Once the relevant features are chosen, the instructions are refined to align with them, ensuring the LLM’s guidance is both targeted and effective. Specifically, we conduct stepwise feature selection by providing the LLM with the latest statistics of the four features: CWND, RTT, throughput, number of retransmitted packets. We find that the number of retransmitted packets does not appear to be a critical feature in this setup because the latencybased trigger module, which operates preemptively to mitigate congestion and to reduce the likelihood of packet loss. After securing the final three features, we turn to refining the general instructions to further improve throughput and reduce latency. We experiment with alternative ways of formulating the rules for CWND adjustment under different network conditions, as shown in Tab. 1 and Tab. 2, which illustrates both formulations: • Math, where the changes are expressed using mathematical formulas following AIMD.
4.3
• Natural, where they are described in natural language without specifying the exact amount of adjustment.
How to Instruct the LLM?
Zero-Shot or Few-Shot? We next investigate whether the in-context learning ability of the LLM can be leveraged to 5
Be tte r
(a) Static
(b) Dynamic - Longisland
(c) Dynamic – 7Train
(d) Dynamic – QTrain
Figure 3: Performance comparison of classic CCAs and TCP-LLM limited design (TCP-LLM-L, §4) and TCP-LLM general design (TCP-LLM-G, §5) on four different links: Static, Dynamic-Longisland, Dynamic-7Train, and Dynamic-QTrain.
improve performance by incorporating few-shot examples into the prompt. To obtain reference examples, we ran the TCP-NewReno simulation pipeline, and because we were not able to identify the gold few-shot example, we randomly chose one instance of CWND adjustments. A performance comparison between the zero-shot and few-shot schemes is presented in Part (a) in Tab. 3. Contrary to our expectation, the inclusion of few-shot example results in relatively degraded performance. Closer inspection reveals that, under the few-shot scheme, the LLM tends to directly reproduce values similar to the provided example rather than inferring new adjustments based on the current input. By contrast, the zero-shot setup allows the LLM greater flexibility to adapt its outputs to varying conditions. We therefore adopt the zeroshot setup for the remainder of our probing experiments.
4.4
where congestion signals are inferred primarily from packet drops; (ii) Delay-sensitive control, e.g., YeAH [2], Illinois [18], which emphasizes RTT trends as early indicators of congestion while still accounting for loss; and (iii) modelbased pacing, e.g., Bbr [6], which departs from traditional AIMD heuristics by explicitly estimating bottleneck bandwidth and delay. In this experiment, we set the trigger threshold to 112ms, which is α = 70% for an estimation of 160ms ran in the static topology. We set the history length to 4. Results analysis. As shown in Fig. 3, across both static and dynamic network conditions, TCP-LLM-L generally achieves the most balanced trade-off between throughput and latency. While Bbr attains notably lower RTTs, it does so at the expense of substantially reduced throughput compared to other CCAs. In contrast, algorithms such as Cubic and WestwoodPlus sustain relatively higher throughput but incur significantly higher latency. In comparison, TCP-LLM-L delivers near-maximum throughput while maintaining latency that is markedly lower than most loss-based schemes. For example, in the static trace shown in Fig. 3(a), TCPLLM-L achieves an average throughput of 9.99 Mbps on a 10 Mbps link, similar to loss-based CCAs such as NewReno and Cubic, despite not employing their more aggressive window growth strategies. Yet, it does so with remarkably lower latency, between 17% and 30% less than these standard CCAs, while incurring only a modest 9% increase compared to Bbr, which is known for its latency-oriented design. The advantage becomes even more pronounced in the Longisland trace, TCP-LLM-L reduces latency by approximately 45%–70% relative to most rule-based CCAs, while sustaining throughput that is nearly indistinguishable from theirs. This balance demonstrates that TCP-LLM-L avoids the extremes of underutilization and excessive queueing, yielding competitive performance across diverse links. For traces such as 7Train and QTrain shown in Fig. 3(c) and Fig. 3(d) respectively, which exhibit gradual increases or frequent and abrupt fluctuations, TCP-LLM-L demonstrates less pronounced advantages compared to the Static and LongIsland cases. This is because window growth in TCPLLM-L relies primarily on the underlying TCP-NewReno process; the LLM itself contributes little to proactive band-
Does the System Generalize Across Diverse Network Conditions?
Emulation Setups. We extend our experimental setup to dynamic links, emulating realistic network bandwidth fluctuations to check whether LLM can generalize. We achieve this by using three distinct traces, namely, Longisland, QTrain, and 7Train, from the NYU Metropolitan Mobile Bandwidth Trace dataset [20] to our one-to-one topology. • Longisland, characterized by a single spike of high bandwidth amid predominantly low bandwidth. • QTrain, featuring frequent and abrupt fluctuations. • 7Train, showing an overall increasing trend with relatively small variations. Each trace simulates bandwidth variations every five seconds over 120-second dynamic network simulations. We particularly focus on wireless traces as they inherently exhibit a high degree of variability and unpredictability, posing a significant challenge for congestion control. We compared the LLM-based congestion control policy, TCP-LLM-L, which operates only during congestion avoidance, against a broad set of representative CCAs. We include (i) loss-based probing, e.g., NewReno [12], Cubic [13], 6
(a) Static (b) Dynamic - Longisland (c) Dynamic – 7Train (d) Dynamic – QTrain Figure 4: Snapshots of TCP-LLM-L (§4), TCP-LLM-G (§5), NewReno, and Bbr: Row 1: Bandwidth changes of the bottleneck link over time. Row 2: RTT comparison over time. Row 3: CWND comparison over time. Row 4: Bottleneck link router queue size distribution for all 120s.
width probing, and its latency-triggered design emphasizes delay reduction rather than fully exploiting available capacity. For instance, in the 7Train scenario, TCP-LLM-L reduces latency by at least 5% compared to most rule-based CCAs, while incurring only a marginal throughput loss of about 1.2%. However, it incurs roughly 20% higher latency than Bbr, while still delivering about 2% higher throughput, increasing from 8.00 Mbps to 8.13 Mbps on a link with an average capacity of around 8.20 Mbps. As a result, TCPLLM-L still performs reasonably well in these dynamic scenarios, though its benefits are not as prominent as in the Static and LongIsland traces.
4.5
for a low bandwidth of 2Mbps, so it sends too much packets before the bandwidth rises, incurring large increases in RTT to around 4500ms at 25 seconds. As the spike disappears at 50 seconds, NewReno does not adapt to the lower bandwidth and continue assigning high CWND value, causing the highest latency of 1420ms. However, we observe that Bbr and TCP-LLM-L are more conservative in their CWND increases and are able to adapt to both the abrupt increase and the abrupt decrease timely, achieving a lower latency of around 100ms starting from 50 seconds onward. In addition, we note that Bbr attempts to probe the network periodically after 50 seconds, then drops CWND to only 4 MSS after failed probes, causing it to lose throughput compared to TCP-LLM-L, which safely operates with lower CWND values around 20MSS. From the queue size distribution plot in row 4, we can see that Bbr and TCP-LLM-L clearly has a higher fraction of low queue size than NewReno, which further demonstrate their latency advantages. 7Train. We then turn to the 7Train trace in Fig. 4(c), in which TCP-LLM-L shows the most evident advantage of latency in the first 40 seconds. We observe in the first 40 seconds, when the network bandwidth is very limited at 1 or 2Mbps, all CCAs except for Bbr attempt to lower CWND to adapt to the bandwidth from their high initialization of 150MSS, whereas Bbr starts with a low CWND. TCP-LLML decreases CWND while NewReno still increases throughout these 40 seconds, thus TCP-LLM-L achieves lower latency than NewReno. Bbr again sacrifices throughput for lower latency. This is shown in the queue size distribution plot in row 4, the bottleneck queue for Bbr is empty of 1% of the timestamps, indicating an underutilization of bandwidth. When the bandwidth gradually increases starting at 60 seconds, all CCAs adapt well to this slow change. QTrain. Finally, we evaluate each CCA’s performance under the highly abrupt bandwidth fluctuations characteristic of the QTrain trace, as depicted in Fig. 4(d). Unfortunately,
Deep-Dive Investigation: Unpacking LLM Congestion Control Strategies
To gain deeper insight into how the LLM behaves under varying conditions, we plot LLM’s control over time. The goal is to examine whether the model can promptly adapt its decisions in response to abrupt bandwidth shifts at a closer scale, besides comparing the average performance metrics. Static. As shown in Fig. 4(a), we begin with the static network condition where the link bandwidth is consistent over time. We observe that Bbr achieves significantly lower RTT, below 89ms for most of the time, yet sacrificing throughput to the large extend as exhibited in Fig. 3(a), whereas TCPNewReno maintain relatively high CWND values to saturate bandwidth, which in turn leads to higher average latency of 126ms. TCP-LLM-L maintains a CWND similar to Bbr by consistently reducing CWND when needed, thereby achieving both lower latency and higher throughput. Longisland. Next, we analyze the reason behind TCP-LLML’s advantage in average latency and throughput in the Longisland trace in Fig. 4(b), which has one significant spike from 2Mbps to 10Mbps around 20–50 seconds. Starting from 20 seconds, NewReno rapidly adapts to the increase in bandwidth. But the pre-increase CWND of 90MSS was too high 7
(a) Static
(b) Dynamic - Longisland
(c) Dynamic – 7Train
(d) Dynamic – QTrain
Figure 5: LLM behavior in TCP-LLM-L(§4) over 4 topologies: (a) Static, (b) Dynamic-Longisland, (c) Dynamic-7Train, and (d) Dynamic-QTrain.
in this particular scenario, TCP-LLM-L does not exhibit the same performance advantage observed in the other three traces. Most CCAs, excluding Bbr, demonstrate similar performance trends, with none showing a direct adherence to the rapid bandwidth fluctuations. Our analysis of snapshots across the four topologies reveals that, in QTrain, the LLM is not triggered as frequently, leading TCP-LLM-L to rely more heavily on its default NewReno behavior and consequently diminishing its expected advantages. This observation motivates us to revisit the latency-based triggering module. We notice that the bandwidth in the initial segment of the QTrain trace (0 to 45 seconds) is approximately twice the 10 Mbps bandwidth characteristic of our static trace. This significant divergence in available bandwidth lead to an underestimation of network latency by the static-case derived model, and thus preventing the TCPLLM-L from reaching its pre-determined latency threshold and thereby delaying its intervention. This lack of action by the LLM explains the vanishing advantage.
4.6
control phases and within the triggering module (§5). Takeaway. Restricting LLM intervention to congestion avoidance provides a safe entry point, reducing latency while preserving throughput. Moreover, natural-language prompts outperform math-based ones, aligning with LLM pretraining. Latency-based triggers and history length shape the trade-off: lower thresholds cut latency at some cost to throughput, while longer history improves stability. However, limited freedom makes the LLM favor decreases or nochange, rarely increasing, which caps bandwidth use.
5
Generalized Design: LLM Across Multiple Congestion Control Phases
In this setup, we allow the LLM to adjust CWND during both congestion avoidance and upon 3-duplicate ACKs events, giving it more latitude to react to mild loss. Note that in this design, we do not include a separate fast retransmit/fast recovery phase; instead, we let the LLM directly adjust the CWND in response to loss events. Our core hypothesis is that this enhanced freedom will allow the LLM to better leverage its generalization ability to quickly restore stable throughput and effectively mitigate starvation when flows compete.
Conclusion Remarks
The experiment results are promising so far – they demonstrate LLM can self-adaptively balance the RTT and throughput, particularly on highly dynamic network conditions. However, we also observe a behavioral bias: despite being provided with general instructions for increase, decrease, and unchange, the LLM consistently opted for decrease or unchange actions across all four topologies, as illustrated in Fig. 5. We attribute this limited range of actions (decrease or unchange) to the constrained operational freedom granted to the LLM: since it is only triggered when latency is high during the congestion avoidance, the presented network statistics almost invariably indicate congestion. Consequently, the LLM predominantly chooses to reduce or retain the CWND, even though the prompt explicitly allows for increases. Furthermore, the LLM’s decrease actions are stricktly uniform, consistently reducing the congestion window (CWND) by exactly 50%. We attribute this consistent reduction, a percentage not defined in the explicit instructions, to an inherited bias from its pretraining on classical congestion control algorithms or networking textbooks. These observations motivate us to grant LLM greater autonomy, both in its engagement across various congestion
We retain standard TCP behavior for initialization and timeouts. The rationale is that, at flow start, the sender lacks a meaningful RTT or throughput baseline leaving the LLM without sufficient input to infer a reasonable CWND. In contrast, TCP’s ACK-clocked exponential probing of initialization safely discovers usable bandwidth and establishes the context necessary for subsequent decisions. During a TCP retransmission timeout (RTO), ACKs are absent and the cause of loss is ambiguous, it is thus unclear whether the timeout arises from excessive sending or from a failing link. Unlike a 3-duplicate ACKs, which indicates partial delivery and thus provides more diagnostic information, an RTO offers little guidance. In this case, resetting CWND to one MSS with exponential backoff remains the conservative and well-validated response for preserving stability and fairness; therefore, we retain this behavior in RTO and only incorporate the LLM for 3-duplicate ACKs events. 8
5.1
How to Generalize the Triggering Mechanism Across Multiple Phases?
however, packet loss naturally occurs, and the number of retransmitted packets becomes an essential observable. Adding this feature allows the model to better capture congestion events and distinguish them from benign delay variations, thereby enhancing its awareness of network dynamics.
The original latency-based trigger module (§4.1) tends to invoke the LLM prematurely before actual loss, so the LLM repeatedly observed pre-congestion snapshots, usually flat throughput with slight RTT upticks, where the safe response was to hold or decrease the window. This behavior is discussed in details in section (§4.6). We seek to design a triggering module that enables a more comprehensive action space for the LLM, allowing it to increase, decrease, or maintain CWND under more informative network conditions. Our initial thought is to periodically trigger the LLM as opposed to adaptively triggering based on latency. We then realize that a fixed time-based cadence would behave inconsistently across links with widely differing link capacities because the same wall-clock interval can span vastly different amounts of delivered data on slow versus fast paths. This would result in oversampling on low-rate links, where frequent triggers add little new information. Hence the LLM can hardly make effective CWND adjustment. On the contrary, it leads to undersampling on high-rate links, where infrequent triggers would not catch fast link dynamics. To this end, we propose to use the ACK count as the triggering parameter and invoke the LLM whenever the number of ACKs reaches a threshold. The threshold is computed using a procedure similar to that of TCP-LLM-L’s trigger module. Specifically, we first run TCP-NewReno on the target topology for 10 seconds and record the total number of ACKs received by the sender. We then round this number to the nearest thousand (for example, in the one-to-one static topology, 7909 ACKs is rounded to 8000 ACKs) and multiply it by a tunable factor β to obtain the final threshold. As with the estimation-based calculation (§4.1), this threshold can be recomputed if the network conditions are detected changed significantly. By adapting to links of different rates, this ACK-based periodic triggering enables the LLM to operate under a broader range of network conditions and provides greater flexibility in adjusting CWND. Since the generalized ACK-based trigger module does not require the CCA to induce a loss event in order to compute a specific latency, it is natural to ask whether a different CCA can be used for the estimation. After completing the design of the LLM input, we examine this question through an ablation study on the choice of CCA used in the estimation and on the factor β (§B.2). To achieve balancing responsiveness with practicality, we adopt β = 0.1, corresponding to an ACK threshold of 800, as the default configuration in our subsequent experiments.
5.2
The degree of freedom grants to the LLM also shapes how we design prompts. When the LLM is constrained to operate only during congestion avoidance, as in TCP-LLM-L, handcrafted rules are required to guide each adjustment. In contrast, when we broaden the model’s scope of intervention, we must rely on more generalized principles because excessive micromanagement risks would overwhelm the model with contradictory directives, while well-structured highlevel guidelines give it the flexibility to adapt to diverse network conditions. Therefore we propose to encode high-level adjustment principles that anchor the LLM in basic TCP protocol semantics while leaving room for autonomous reasoning, enabling the LLM to leverage its pretrained knowledge rather than merely mimic predefined rules. We organize the prompt as a progression from core reasoning to generalization and fairness, so that each layer motivates the next and collectively bounds the LLM’s actions. We term this new LLM-based congestion control policy TCPLLM-G, where G stands for generalization. Due to page limitation, we put the entire prompt to Appendix Tab. 5 while sketching how we design this prompt below. First, we ground the model in basic AIMD intuition (R1–R4), which defines how congestion and bandwidth underutilization are manifested in the input network statistics and specifies their appropriate handling. This establishes the fundamental control logic. Second, to improve the throughput–latency balance (R5), the model should aim to lower queueing without sacrificing goodput. Third, we impose protocol-safe bounds (R6–R8), an MSS floor and a prohibition on single-step collapses, to prevent unstable or noncompliant outputs. Fourth, we add explicit loss handling (R9): retransmissions serve as a direct congestion signal. Fifth, to cope with dynamic bandwidth shifts, the LLM should probe by increasing CWND(R10) but keep this increase only when throughput improves promptly; otherwise, we revert, avoiding optimistic overshoot. Finally, to promote long-term fairness (R11–R12), the LLM should temper window growth to avoid crowding out competing flows, and it includes a catchup mechanism that quickly restores a starved flow to a minimal healthy window to prevent persistent starvation.
Rethinking the LLM Prompting
Taken together, this progression gives the LLM meaningful freedom to reason while anchoring its decisions in TCP-safe bounds and measurable performance signals. We term this LLM-based TCP congestion control across multiple congestion control phases as TCP-LLM-G.
Recall that our initial LLM-input design omits retransmission count because the latency-based trigger prevents actual loss events from surfacing. With the ACK-based trigger, 9
(a) Static
(b) Dynamic - Longisland
(c) Dynamic – 7Train
(d) Dynamic – QTrain
Figure 6: LLM behavior in TCP-LLM-G(§5) over 120s for 4 topologies: (a) Static, (b) Dynamic-Longisland, (c) Dynamic-7Train, and (d) Dynamic-QTrain.
5.3
LLM Behavior Analysis: Generalized Design vs. Limited Design
ms. This represents a rare case where our design achieves even lower latency than Bbr, while also improving throughput from 17.60 Mbps to 17.91 Mbps on a link with an average capacity of about 18 Mbps. Even outside these best-case runs, the average RTT remains modest at 73.58 ms, showing that the design avoids excessive delay while consistently enhancing throughput, reflecting its adaptability to rapidly changing conditions and its robustness relative to baselines.
A central question is whether the TCP-LLM-G design provides tangible benefits over TCP-LLM-L in diverse network conditions. To answer this question, we compare these two algorithms both in terms of performance-wise experiment validation and through finer-grained behavior analysis. The following subsections present these results in detail: first by examining their overall performance across topologies, and then by analyzing their CWND control behaviors in response to abrupt bandwidth shifts. 5.3.1
5.3.2
TCP-LLM-G’s Fine-grained Behavior Analysis
We further analyze TCP-LLM-G’s control behavior on each traces. From Fig. 6, a clear behavior is its ability to take the action of increase, which confirms that our tuned prompt effectively expanded the LLM’s operational freedom. Static. We observe that the TCP-LLM-G finds a balance point of 76MSS for CWND after four triggers and remains unchanged thereafter in Fig. 4(a). Notably, Bbr also operates at this value when not probing, suggesting that TCP-LLM-G can interpret the static network condition. Longisland. Turning to the LongIsland trace in Fig. 4(b), where TCP-LLM-L previously showed an advantage, we find that when bandwidth rises abruptly at 20 seconds, TCPLLM-G starts pushing the CWND upward for better bandwidth utilization. The specific moderate increases are shown in Fig. 6(b), and they enable TCP-LLM-G to quickly adapt when bandwidth drops sharply at 50 seconds. After that, TCP-LLM-G steadily reduces CWND to 20MSS and stays there. This behavior produced a sharply peaked queue size distribution in row 4 of Fig. 4(a), with a higher concentration at smaller queue sizes, achieving higher throughput while maintaining latency comparable to TCP-LLM-L. 7Train. Next, Fig.4(c) shows that when bandwidth ramps up at 60 seconds, TCP-LLM-G also increases CWND to match its observations (Fig.6(c)). Compared to TCP-LLM-L, where all increases come from the background TCP-NewReno, TCP-LLM-G’s increases are more conservative. In TCPLLM-L, the aggressive increases from TCP-NewReno often cause the LLM to respond by decreasing CWND too sharply when triggered (e.g. at 75, 88 seconds), resulting in lower latency but also lower throughput than TCP-LLM-G. QTrain. Finally, we switch to the QTrain trace in Fig. 4(d) and Fig. 6(d). Recall that in TCP-LLM-L, the infrequent triggering of the LLM causes it to revert to basic TCP-NewReno
Congestion Control Performance
As shown in Fig. 3, TCP-LLM-G achieves a more favorable trade-off between RTT and throughput compared to TCPLLM-L. In the highly dynamic QTrain trace, TCP-LLM-G lowers latency by about 12–15% relative to TCP-LLM-L without hurting the throughput (17. 81 Mbps for TCP-LLML vs. 17.89 Mbps for TCP-LLM-G) on a link with an average capacity of about 18 Mbps. This is because unlike TCPLLM-L which restricts CWND adjustments mainly to nochange or decrease, the generalized design allows the LLM to explore a broader action space. CWND adjustments are permitted not only during congestion avoidance but also in response to loss events, enabling the LLM to propose both conservative and aggressive strategies when appropriate. Comparing these two approaches’ performance across different network conditions (Fig. 3(a)–(d)), we find that both approaches exhibit nearly identical performance in the static network trace, suggesting that the additional flexibility does not introduce unnecessary variance under stable conditions. In dynamic environments, TCP-LLM-G demonstrates clear advantages. Specifically, in the Longisland trace, throughput improves from 2.83 Mbps to 2.89 Mbps on a link with an average capacity of about 2.9 Mbps, while RTT increases by only 2%. This shows that TCP-LLM-G can exploit available bandwidth with little penalty in delay and thereby deliver a superior throughput–latency balance. In the more volatile Qtrain trace, where TCP-LLM-L previously struggled, TCP-LLM-G instead markedly improves both throughput and RTT. Across repeated trials, TCP-LLMG occasionally outperforms Bbr in terms of delay: in roughly 30% of runs, RTT is reduced from 71.49 ms to around 65.99 10
TCP-LLM-L
TCP-LLM-G 1a
2c
2b 1c 2a 1b
(a) Static
(b) Dynamic - Longisland
(c) Dynamic - 7Train1
(d) Dynamic - QTrain
Figure 7: Throughput fairness snapshots over 120 s across four topologies: (a) Static, (b) Dynamic-Longisland, (c) Dynamic-7Train, and (d) DynamicQTrain for NewReno, WestwoodPlus, Cubic, Bbr, and our TCP-LLM generalized setup.
and fail to gain advantage over the baselines. In contrast, TCP-LLM-G can recognize the high bandwidth through frequent triggers and increases CWND reasonably to fully utilize the capacity. When the bandwidth drops quickly between 40 seconds and 65 seconds, TCP-LLM-G promptly decreases CWND to respond. During the bandwidth spike from 65 seconds to 85 seconds, we observe an increase at 65 seconds and a decrease at 85 seconds, closely tracking the spike. After 85 seconds, the LLM again increases CWND to match the increasing bandwidth. These timely responses enable TCP-LLM-G to achieve lower latency and higher throughput compared to TCP-LLM-L. This is also demonstrated in row 4 of Fig. 4(d), where TCP-LLM-G is the only CCA that has its main peak around 20 to 40 packets. Overall, these analyses show that the generalized action space with the ACK-based trigger makes TCP-LLM-G more adaptable across diverse topologies, consistently balancing latency and throughput better than TCP-LLM-L. Takeaway. Allowing the LLM to act during both congestion avoidance and loss events addresses the limited increases seen in the constrained design. Adding retransmission counts improves visibility into true losses, while an ACK-based trigger exposes broader dynamics than latency alone. These changes let the LLM adapt quickly to fluctuating traces, improving the throughput–latency trade-off, while preserving stability in static conditions.
6.1
All-LLM Setups
6
We next examine fairness in a hybrid setting where nodes employ different CCAs. From our earlier observations, the LLM in TCP-LLM-L consistently produces only nonincreasing actions. When competing with a TCP-NewReno flow, which continually increases its CWND until encountering three duplicate ACKs, TCP-LLM-L backs off and is eventually dominated by the NewReno node. Moreover, the deep-dive analyses in Fig. 4 reveal that among the four baseline CCAs we considered, Bbr is the only one without an
Fig. 7 illustrates the per-flow throughput over time. Under TCP-LLM-L, we observe high short-term variability with no clear convergence: flows repeatedly overshoot, trigger losses, and then sharply reduce their CWND. This oscillatory pattern reflects the inherited NewReno-like behavior of the limited design, where aggressive additive increase and multiplicative decrease dominate the dynamics. As a result, individual flows temporarily diverge substantially from one another, even though the long-term averages remain close. In contrast, the generalized design TCP-LLM-G shows a different trajectory. At the beginning of the trace (labeled Points 1 in Fig. 7), the system is still in its startup phase. Because the LLM has not yet accumulated sufficient information about networks, the flows compete unevenly and the allocations appear unstable. As the transmission progresses, however, the model observes more congestion signals and throughput trends, enabling it to refine its decisions. So, by the later stage of the trace (labeled Points 2 in Fig. 7), the flows converge toward nearly identical throughput, and the allocation stabilizes. This progression indicates that, when granted greater flexibility, the LLM can leverage its generalization ability to learn from the evolving feedback, mitigate oscillations, and guide the system toward a balanced state.
6.2
Fairness in Multi-Sender Settings
We further explore whether LLM can achieve fairness. To this end, we construct a multi-sender–to–one-receiver topology to analyze the third metric: fairness. We categorize the fairness experiments into two settings: All-LLM, where all three senders employ our LLM-based system for congestion control, and Hybrid, where one sender uses a traditional, widely adopted TCP congestion control algorithm while the remaining two use our system. 11
Hybrid Setups
(1a) Longisland original prompt
(1b) Longisland aggressive prompt
(2b) QTrain aggressive prompt
(2a) QTrain original prompt
across the three flows to increase from 88.80 ms to 89.54 ms in the QTrain trace, while the difference is minimal in the Longisland trace. Takeway. In the all-LLM setting, both TCP-LLM-L and TCPLLM-G achieve fairness across flows, though TCP-LLM-G converges more smoothly while TCP-LLM-L remains unstable. In hybrid settings, however, the LLM often yields to traditional CCAs due to its less aggressive competition for bandwidth. Adding prompts for stronger increases can restore fairness but at the expense of higher RTT, highlighting a trade-off between equal sharing and latency.
7
Model Interpretability
We further translate LLM’s congestion control policies into formalized algorithms to better understand their behaviors. Specifically, we record sender-side statistics (CWND, RTT, throughput, and retransmissions) together with the LLM’s responses at every intervention point during the QTrain simulations. These logs are then provided back to GPT-5[23], which is asked to summarize the observed behavior and distill it into a rule-based congestion control algorithm. A full set of GPT-5’s generated rules are included in Appendix D. The analysis shows that these control policies converges on a three-rule heuristic: (1) immediate window reduction upon detecting retransmissions, with heavier cuts for persistent or multiple losses; (2) cautious, periodic probing of bandwidth when RTT and throughput appear stable, matching the additive increases we saw in the log; and (3) holding CWND constant when signals are ambiguous, which reflects the plateau behavior in the traces. These generated rules align closely with the actual action patterns exhibited by TCP-LLM in the QTrain, suggesting the model’s decisions are more likely to be interpretable as structured heuristics rather than arbitrary responses. Compared to existing CCAs, the LLM-based solution differs in both bandwidth exploration and congestion handling. • In congestion avoidance, unlike NewReno or Cubic that continuously increase CWND until loss signals force a reduction, the LLM only increases CWND after stability is confirmed, gating its probing on the absence of retransmissions, stable RTT, and non-decreasing throughput. This makes probing slower but safer, reducing oscillations in volatile conditions. • For loss handling, unlike Reno and Cubic which always apply a fixed multiplicative decrease, the LLM applies a twostep reduction: a mild cut for small losses and a deeper cut for persistent or heavy losses. Finally, in contrast to Bbr, which aggressively and continuously probes based on its bandwidth–delay model, the LLM remains signal-driven and conservative: it holds CWND steady when conditions are ambiguous, cutting back only on confirmed loss and increasing only under stability. Taken together, the LLM-generated congestion control policies can be seen as a cautious middle ground: less aggres-
Figure 8: Throughput fairness snapshots over 120s after aggressive prompt.
aggressive increase trend. We therefore focus on the fairness between Bbr and TCP-LLM-G to gain deeper insight. The ‘Hybrid’ reveals a clear trend: Bbr consistently dominates across all topologies. The TCP-LLM-G flows are relegated to a particularly small share of bandwidth in the Longisland and QTrain topologies as shown in Fig. 8(1a)-(1b). To understand the underlying mechanism, we examine the four network statistics features provided to the LLM from the sender’s perspective. We observe that RTT, throughput, and retransmissions exhibit nearly identical patterns under two distinct scenarios: (a) when the available bandwidth decreases, and (b) when a new node joins the network and begins consuming bandwidth. From the LLM’s point of view the statistics are: RTT is increasing, throughput is decreasing, and there could be retransmitted packets or not, based on how aggressive the new node is and how large the bandwidth drop is. This similarity makes it difficult for the LLM to distinguish which scenario it is encountering. In particular, if it takes a conservative stance and decreases CWND whenever these congestion-like statistics appear, its bandwidth share will inevitably be consumed by more aggressive competitors. This explains why the All-LLM case exhibits greater fairness than the Hybrid case. Conversely, if the LLM attempts to be aggressive and increases CWND whenever it perceives its utilization as too low, it sacrifices its latency advantage in normal conditions. To better demonstrate this trade-off, we modify the prompt to instruct the LLM to spike the CWND to probe the network when it considers the current flow to be suppressed by other nodes. We then observe that the average bandwidth utilization of the TCP-LLM-G nodes is much more fair in both the Longisland trace, changing from (9.10%, 39.10%, 48.10%) to (20.50%, 38.30%, 37.70%), and the QTrain trace, changing from (21.50%, 11.20%, 66.20%) to (26.90%, 21.90%, 50.20%). A detailed comparisons are shown in Fig. 8, and we can see that the bandwidth utilization for the three nodes are more reasonable after changing the prompt. However, this aggressive change in the prompt causes the average RTT 12
References
sive in growth than Reno, Cubic, and Bbr, but more nuanced in loss handling and more context-aware in its decision logic.
8
[1] Soheil Abbasloo, Chen-Yu Yen, and H. Jonathan Chao. Classic meets modern: a pragmatic learning-based congestion control for the internet. In Proceedings of the ACM SIGCOMM 2020 Conference, SIGCOMM ’20, page 632–647, New York, NY, USA, 2020. Association for Computing Machinery.
Conclusion
Our exploratory study with TCP-LLM shows that LLMs can be applied to congestion control in a way that moves beyond fixed rules and adapts to diverse network conditions. While simulations across static and dynamic topologies suggest that TCP-LLM achieves a more favorable throughput–latency trade-off than classic CCAs and offers preliminary insights into fairness, these findings remain early-stage. Important challenges such as computational overhead, stability of LLM decisions, and practical deployment in realworld WAN environments, should be addressed before such approaches can be widely adopted. Looking ahead, we see opportunities in combining LLM reasoning with lightweight traditional control, refining prompts or fine-tuning for efficiency, and extending evaluations to real testbeds.
[2] Andrea Baiocchi, Angelo P. Castellani, and Francesco Vacirca. Yeah-tcp: Yet another highspeed tcp. In Proceedings of the 5th International Workshop on Protocols for FAST Longâ-Distance Networks (PFLDnet), pages 37–42, 2007. [3] Leonardo Berti, Flavio Giorgi, and Gjergji Kasneci. Emergent abilities in large language models: A survey, 2025. [4] Kaoutar Boussaoud, Abdeslam En-Nouaary, and Meryeme Ayache. Adaptive congestion detection and traffic control in software-defined networks via datadriven multi-agent reinforcement learning. Computers, 14(6), 2025. [5] L.S. Brakmo and L.L. Peterson. Tcp vegas: end to end congestion avoidance on a global internet. IEEE Journal on Selected Areas in Communications, 13(8):1465– 1480, 1995. [6] Neal Cardwell, Yuchung Cheng, C Stephen Gunn, Soheil Hassas Yeganeh, and Van Jacobson. Bbr: Congestion-based congestion control. Communications of the ACM, 60(2):58–66, 2017. [7] Mo Dong, Qingxi Li, Doron Zarchy, P Brighten Godfrey, and Michael Schapira. {PCC}: Re-architecting congestion control for consistent high performance. In 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15), pages 395–408, 2015. [8] Mo Dong, Tong Meng, Doron Zarchy, Engin Arslan, Yossi Gilad, Brighten Godfrey, and Michael Schapira. {PCC} vivace:{Online-Learning} congestion control. In 15th USENIX symposium on networked systems design and implementation (NSDI 18), pages 343–356, 2018. [9] Salma Emara, Baochun Li, and Yanjiao Chen. Eagle: Refining congestion control by learning from the experts. In IEEE INFOCOM 2020-IEEE Conference on Computer Communications, pages 676–685. IEEE, 2020. [10] Joyce Fang, Martin Ellis, Bin Li, Siyao Liu, Yasaman Hosseinkashi, Michael Revow, Albert Sadovnikov, 13
Ziyuan Liu, Peng Cheng, Sachin Ashok, David Zhao, Ross Cutler, Yan Lu, and Johannes Gehrke. Reinforcement learning for bandwidth estimation and congestion control in real-time communications. In Workshop on Machine Learning for Systems (ML for Systems) at NeurIPS 2019, 2019. Workshop paper.
[19] Andrea Matarazzo and Riccardo Torlone. A survey on large language models with some insights on their capabilities and limitations, 2025. [20] Lifan Mei, Runchen Hu, Houwei Cao, Yong Liu, Zifan Han, Feng Li, and Jin Li. Realtime mobile bandwidth prediction using lstm neural network and bayesian fusion. Computer Networks, 182:107515, 2020.
[11] Dayuan Fu, Jianzhao Huang, Siyuan Lu, Guanting Dong, Yejie Wang, Keqing He, and Weiran Xu. PreAct: Prediction enhances agent’s planning ability. In Owen Rambow, Leo Wanner, Marianna Apidianaki, Hend AlKhalifa, Barbara Di Eugenio, and Steven Schockaert, editors, Proceedings of the 31st International Conference on Computational Linguistics, pages 1–16, Abu Dhabi, UAE, January 2025. Association for Computational Linguistics.
[21] Ayush Mishra, Lakshay Rastogi, Raj Joshi, and Ben Leong. Keeping an eye on congestion control in the wild with nebby. In Proceedings of the ACM SIGCOMM 2024 Conference, ACM SIGCOMM ’24, page 136–150, New York, NY, USA, 2024. Association for Computing Machinery. [22] OpenAI. Gpt-4o system card, 2024.
[12] Andrei Gurtov, Tom Henderson, and Sally Floyd. The NewReno Modification to TCP’s Fast Recovery Algorithm. RFC 3782, April 2004.
[23] OpenAI. Gpt-5 system card. Technical Report August 13, 2025, OpenAI, August 2025. [24] Lorenzo Pappone, Alessio Sacco, and Flavio Esposito. Mutant: Learning congestion control from existing protocols via online reinforcement learning. In 22nd USENIX Symposium on Networked Systems Design and Implementation (NSDI 25), pages 1507–1522, 2025.
[13] Sangtae Ha, Injong Rhee, and Lisong Xu. Cubic: a new tcp-friendly high-speed tcp variant. SIGOPS Oper. Syst. Rev., 42(5):64–74, July 2008. [14] Zhiyuan He, Aashish Gottipati, Lili Qiu, Yuqing Yang, and Francis Y. Yan. Congestion control system optimization with large language models, 2025.
[25] Ujjayant Prakash and Anand M Baswade. Tcpcubiwood: Enhanced cubic congestion control for mmwave and future networks. In 2025 17th International Conference on COMmunication Systems and NETworks (COMSNETS), pages 614–622. IEEE, 2025.
[15] V. Jacobson. Congestion avoidance and control. In Symposium Proceedings on Communications Architectures and Protocols, SIGCOMM ’88, page 314–329, New York, NY, USA, 1988. Association for Computing Machinery.
[26] Shyam Kumar Shrestha, Shiva Raj Pokhrel, and Jonathan Kua. Adapting large language models for improving tcp fairness over wifi. arXiv preprint arXiv:2412.18200, 2024.
[16] Nathan Jay, Noga H. Rotman, P. Brighten Godfrey, Michael Schapira, and Aviv Tamar. A deep reinforcement learning perspective on internet congestion control. In Proceedings of the 36th International Conference on Machine Learning (ICML 2019), volume 97 of Proceedings of Machine Learning Research, pages 5390–5399, 2019.
[27] Viswanath Sivakumar, Tim Rocktäsch el, Alexander H. Miller, Heinrich Küttler, Nantas Nardelli, Mike Rabbat, Joelle Pineau, and Sebastian Riedel. Mvfst-rl: An asynchronous rl framework for congestion control with delayed actions. In Workshop on Machine Learning for Systems (ML for Systems), NeurIPS 2019, 2019. Workshop paper.
[17] Zeqi Lai, Zonglun Li, Qian Wu, Hewu Li, Jihao Li, Xin Xie, Yuanjie Li, Jun Liu, and Jianping Wu. Leocc: Making internet congestion control robust to leo satellite dynamics. In Proceedings of the ACM SIGCOMM 2025 Conference, pages 129–146, 2025.
[28] Karthik Valmeekam, Matthew Marquez, Sarath Sreedharan, and Subbarao Kambhampati. On the planning abilities of large language models - a critical investigation. In A. Oh, T. Naumann, A. Globerson, K. Saenko, M. Hardt, and S. Levine, editors, Advances in Neural Information Processing Systems, volume 36, pages 75993–76005. Curran Associates, Inc., 2023.
[18] Shao Liu, Tamer Başar, and R. Srikant. Tcp-illinois: A loss- and delay-based congestion control algorithm for high-speed networks. Performance Evaluation, 65(6):417–440, 2008. Innovative Performance Evaluation Methodologies and Tools: Selected Papers from ValueTools 2006.
[29] Keith Winstein and Hari Balakrishnan. Tcp ex machina: computer-generated congestion control. In 14
Proceedings of the ACM SIGCOMM 2013 Conference on SIGCOMM, SIGCOMM ’13, page 123–134, New York, NY, USA, 2013. Association for Computing Machinery. [30] Duo Wu, Xianda Wang, Yaqi Qiao, Zhi Wang, Junchen Jiang, Shuguang Cui, and Fangxin Wang. Netllm: Adapting large language models for networking. In Proceedings of the ACM SIGCOMM 2024 Conference, pages 661–678, 2024. [31] Yaxiong Xie, Fan Yi, and Kyle Jamieson. Pbe-cc: Congestion control via endpoint-centric, physical-layer bandwidth measurements. In Proceedings of the Annual conference of the ACM Special Interest Group on Data Communication on the applications, technologies, architectures, and protocols for computer communication, pages 451–464, 2020. [32] Zhiyuan Xu, Jian Tang, Chengxiang Yin, Yanzhi Wang, and Guoliang Xue. Experience-driven congestion control: When multi-path tcp meets deep reinforcement learning. IEEE Journal on Selected Areas in Communications, 37(6):1325–1336, 2019. [33] Ding Zhao, Xinyu Zhang, and Myungjin Lee. Satpipe: Deterministic tcp adaptation for highly dynamic leo satellite networks. In IEEE INFOCOM 2025-IEEE Conference on Computer Communications, pages 1– 10. IEEE, 2025.
15
A
Prompts
In this section, we present all three types of prompts we used in our experiments. TCP-LLM-L Prompt System Prompt: You are an expert congestion controller in wide area networks. Based on the following input parameters: 1. last_cwnd: The previous congestion window size. 2. current_cwnd: The current size of the congestion window. 3. ssthreshold: The slow start threshold. 4. last_rtt: The previous round-trip time of second-to-last segment. 5. current_rtt: The current round-trip time of last segment. 6. current_throughput: The current throughput observed (in Mbps) during the latest sampling interval. 7. last_throughput: The throughput observed (in Mbps) during the previous sampling interval. Explanation of the history fields: - CWNDs (most recent first): A list of recently recorded congestion window sizes (in bytes). Each value corresponds to the cwnd measured at a discrete time step, with the most recent measurement appearing first. - RTTs (most recent first): A list of recently recorded round-trip times (in seconds). Each value is the measured latency for a packet to travel from sender to receiver and back again, with the most recent measurement first. - Throughput values (most recent first): A list of recently recorded throughput measurements (in Mbps). Each value represents the data transfer rate observed during a sampling interval, listed from the newest to the oldest measurement. Modify cwnd and ssthreshold according to the following rules: 1. If current_rtt is higher than last_rtt (indicating rising latency) and current_throughput shows no significant improvement over or is equal to or lower than last_throughput (indicating congestion and buffer buildup), reduce cwnd multiplicatively, but limit the reduction to no more than 50% of the current_cwnd. 2. If current_cwnd is stable or slightly lower than last_cwnd, and current_rtt remains stable at a low level (or shows a decreasing trend) while current_throughput is increasing compared to last_throughput, increase cwnd additively(e.g., cwnd += 1448), as it’s likely that the network can handle more traffic. 3. Do not allow cwnd to fall below 1448 bytes, which is one segment size. In addition, prevent any single adjustment from causing cwnd to drop abruptly to 1448. 4. Limit the rate of change in cwnd to avoid oscillations (e.g., no more than ±50% per adjustment). 5. Do not increase cwnd if current_rtt is rising rapidly and current_throughput is not showing signigficantly improvment compared to last_throughput. 6. Upon detecting congestion (e.g., packet loss or a RTT increase), dynamically set the ssthreshold as a proportion of the current cwnd: - In severe congestion (when current_throughput is stagnant), set ssthreshold to the current cwnd. - In favorable conditions (when current_throughput is increasing), allow ssthreshold to reach up to 1.5 (or 1.25) times the current cwnd. Use a smoothing mechanism to ensure gradual transitions in ssthreshold. 7. If, after cwnd has been reduced, current_throughput remains stagnant (i.e., shows no significant improvement) and current_rtt shows little decline or same compared to last_rtt (indicating persistent buffering), further reduce cwnd multiplicatively (using the same method as in Rule 1) until a measurable drop in RTT is achieved. Suggest the optimal congestion control parameters for the next step in the json format with only values without any explanation. You should generate the following parameters: "next_CWND" "next_SSThreshold" Table 4: Prompt utilized in TCP-LLM baseline design.
16
TCP-LLM-G Prompt System Prompt: You are an expert congestion controller in wide area networks. Based on the following input parameters: 1. last_cwnd: CWND measured at the previous interval (bytes). 2. current_cwnd: CWND measured at the current interval (bytes). 3. ssthreshold: Current slow start threshold (bytes). 4. last_rtt: RTT observed in the previous interval (seconds). 5. current_rtt: RTT observed in the current interval (seconds). 6. last_throughput: Throughput in the previous interval (Mbps). 7. current_throughput: Throughput in the current interval (Mbps). 8. current_retransmit_packet: Number of retransmitted packets in the current interval. 9. history_cwnd: List of the last N CWND measurements (bytes), most recent first. 10. history_rtt: List of the last N RTT measurements (s), most recent first. 11. history_throughput: List of the last N throughput values (Mbps), most recent first. 12. history_retransmit_packet: List of the last N retransmit packet counts, most recent first. Define adjustments to cwnd and ssthreshold according to these principles: 1. Decrease cwnd multiplicatively if there might be a congestion. 2. Increase cwnd additively if there might be underutilization of the bandwidth. 3. A congestion might be happening if you see current_rtt is higher than the most recent value of history_rtt, while current_throughput or history_throughput is not in an increasing trend or it is even in a decreasing trend. 4. A underutilization of the bandwidth might be happening if you see current_cwnd and history_cwnd are decreasing and current_throughput and history_throughput are decreasing while a decreasing trend in current_rtt or history_rtt. 5. If current_rtt or history_rtt remain elevated compared to recent baselines, and current_throughput or history_throughput are flat or degrading (not showing meaningful improvement), treat this as queue buildup. Immediately decrease cwnd by a noticeable fraction of its current size to lower RTT and stabilize throughput. 6. Do not allow cwnd to fall below 1448 bytes, which is one segment size. 7. Avoid any single adjustment from causing cwnd to drop abruptly to 1448. 8. Upon detecting congestion (e.g., packet retransmit or a RTT increase), set ssthreshold to the new cwnd value you suggested. 9. Ideally, we want the current retransmit packet to be 0. If the current retransmit packet is higher than 0, you should immediately reduce cwnd multiplicatively by a large fraction of its current size. 10. When you believe this is a dynamic network not a static network, conduct this rule when rule 9 is not satisfied and rule 5 is not satisfied. If current_cwnd and history_cwnd keep stable or increasing while history_throughput is in an increasing trend and current_throughput is significantly improved, and the trend of current_rtt and history_rtt are in a decreasing trend, immediately increase cwnd additively by a substantial fraction of its current size that reflects the scale of throughput improvement, keep the increase only if throughput immediately improves, otherwise revert. 11. If you observe your cwnd is not decreasing while RTT is increasing, treat this as a sign that there are other nodes in the network. Try to maintain fairness across all senders. Do not back off too much. 12. If you observe your current_cwnd and history_cwnd remain less than the inital cwnd 14480, 10 segments, an extremely low level, you should immediately recover the cwnd to at least 14480(10 segments) aggresively to catch up with others and maintain fairness, ignore the current_retransmit_packet. Suggest the optimal congestion control parameters for the next step in the json format with only values without any explanation. You should generate the following parameters: "next_CWND" "next_SSThreshold" Table 5: Prompt utilized in TCP-LLM generalized design.
17
TCP-LLM-G Prompt with an Additional Aggressive Rule System Prompt: You are an expert congestion controller in wide area networks. Based on the following input parameters: 1. last_cwnd: CWND measured at the previous interval (bytes). 2. current_cwnd: CWND measured at the current interval (bytes). 3. ssthreshold: Current slow start threshold (bytes). 4. last_rtt: RTT observed in the previous interval (seconds). 5. current_rtt: RTT observed in the current interval (seconds). 6. last_throughput: Throughput in the previous interval (Mbps). 7. current_throughput: Throughput in the current interval (Mbps). 8. current_retransmit_packet: Number of retransmitted packets in the current interval. 9. history_cwnd: List of the last N CWND measurements (bytes), most recent first. 10. history_rtt: List of the last N RTT measurements (s), most recent first. 11. history_throughput: List of the last N throughput values (Mbps), most recent first. 12. history_retransmit_packet: List of the last N retransmit packet counts, most recent first. Define adjustments to cwnd and ssthreshold according to these principles: 1. Decrease cwnd multiplicatively if there might be a congestion. 2. Increase cwnd additively if there might be underutilization of the bandwidth. 3. A congestion might be happening if you see current_rtt is higher than the most recent value of history_rtt, while current_throughput or history_throughput is not in an increasing trend or it is even in a decreasing trend. 4. A underutilization of the bandwidth might be happening if you see current_cwnd and history_cwnd are decreasing and current_throughput and history_throughput are decreasing while a decreasing trend in current_rtt or history_rtt. 5. If current_rtt or history_rtt remain elevated compared to recent baselines, and current_throughput or history_throughput are flat or degrading (not showing meaningful improvement), treat this as queue buildup. Immediately decrease cwnd by a noticeable fraction of its current size to lower RTT and stabilize throughput. 6. Do not allow cwnd to fall below 1448 bytes, which is one segment size. 7. Avoid any single adjustment from causing cwnd to drop abruptly to 1448. 8. Upon detecting congestion (e.g., packet retransmit or a RTT increase), set ssthreshold to the new cwnd value you suggested. 9. Ideally, we want the current retransmit packet to be 0. If the current retransmit packet is higher than 0, you should immediately reduce cwnd multiplicatively by a large fraction of its current size. 10. When you believe this is a dynamic network not a static network, conduct this rule when rule 9 is not satisfied and rule 5 is not satisfied. If current_cwnd and history_cwnd keep stable or increasing while history_throughput is in an increasing trend and current_throughput is significantly improved, and the trend of current_rtt and history_rtt are in a decreasing trend, immediately increase cwnd additively by a substantial fraction of its current size that reflects the scale of throughput improvement, keep the increase only if throughput immediately improves, otherwise revert. 11. If you observe your cwnd is not decreasing while RTT is increasing, treat this as a sign that there are other nodes in the network. Try to maintain fairness across all senders. Do not back off too much. 12. If you observe your current_cwnd and history_cwnd remain less than the inital cwnd 14480, 10 segments, an extremely low level, you should immediately recover the cwnd to at least 14480(10 segments) aggresively to catch up with others and maintain fairness, ignore the current_retransmit_packet. 13. If you think the current throughput is low and current cwnd is low. Try to spike up like Bbr to probe the bandwidth. Suggest the optimal congestion control parameters for the next step in the json format with only values without any explanation. You should generate the following parameters: "next_CWND" "next_SSThreshold" Table 6: TCP-LLM-G Prompt with an Additional Aggressive Rule
18
B
Trigger Threshold Ablation Study
α 50% 60% 70% 80%
RTT (ms)
Thr. (Mbps)
Avg.
Std.
Avg.
Std.
75.62 99.55 92.83 115.40
7.18 7.24 3.54 3.43
9.98 9.99 9.99 9.99
0.00 0.00 0.00 0.00
the trigger would become too sparse, potentially missing important network dynamics. As reported in Table 8, our ablation results demonstrate that the choice of β has only a marginal impact on the overall performance of TCP-LLM-G. The main consideration, therefore, lies in balancing responsiveness with practicality. To achieve this balance, we adopt β = 0.1, corresponding to an ACK threshold of 800, as the default configuration in our subsequent experiments.
C
Fairness
Table 7: Trigger threshold α ablation.
Node
B.1
α in latency-based trigger model
Our current design relies on a pre-defined threshold, the natural question raises is whether the system performance is sensitive to this threshold. We conduct experiments on the choice of this threshold α ranging from 50% to 90% and test the RTT and throughput in each settings. The results are shown in Tab. 7. We observe a clear tradeoff driven by the trigger threshold α. Lower thresholds (e.g., 50%) invoke the LLM more aggressively, which helps keep latency low but slightly sacrifices throughput due to frequent adjustments that interrupt stable growth. Conversely, higher thresholds (e.g., 80%) reduce responsiveness between decisions, which increases throughput stability but at the cost of building longer queues, leading to higher latency. The intermediate setting of α = 70% achieves the best balance. It avoids excessive oscillations while still reacting quickly enough to prevent significant queue buildup, thereby sustaining nearmaximal throughput with improved RTT performance. It is worth noticing that for all thresholds, our method has a lower latency than the baseline TCP-NewReno.
β 0.05 0.1 0.15 0.2
RTT (ms)
Thr. (Mbps)
Avg.
Std.
Avg.
Std.
97.72 91.32 91.39 92.74
8.80 0.16 0.35 2.43
9.98 9.99 9.99 9.99
0.00 0.00 0.00 0.00
Static
LongIsland
7Train
QTrain
35.60% 29.60% 33.20% 98.40%
28.60% 32.30% 31.70% 92.60%
33.20% 27.60% 33.30% 94.10%
31.30% 33.80% 33.10% 98.20%
TCP-LLM-G - ALL LLM Node 0 LLM 26.10% Node 1 LLM 36.10% Node 2 LLM 37.30% SUM 99.50%
33.40% 35.00% 27.60% 96.00%
33.00% 29.30% 33.90% 96.20%
42.30% 27.30% 28.70% 98.30%
TCP-LLM-G - Hybrid Node 0 LLM 24.10% Node 1 LLM 27.20% Node 2 Bbr 48.00% SUM 99.30%
9.10% 39.10% 48.10% 96.30%
14.80% 20.70% 60.50% 96.00%
21.50% 11.20% 66.20% 99.00%
Table 9: Fairness comparison: Bandwidth utilization of different nodes.
To evaluate fairness in the all-LLM setting, we compute the bandwidth utilization of each flow at one-second granularity and then average these values over the entire 120 s trace. This produces an average bandwidth utilization per flow, as summarized in Table 9. The results show that both TCP-LLML and TCP-LLM-G exhibit relatively balanced allocations: across all four topologies, the per-flow averages differ by less than 5%. This indicates that on long timescales, our LLMbased schemes maintain a high degree of fairness.
Table 8: Trigger threshold β ablation.
B.2
CCA
TCP-LLM-L Node 0 LLM Node 1 LLM Node 2 LLM SUM
β in ACK-based trigger model
We select the range of β between 0.05 and 0.2 based on preliminary experiments with TCP-NewReno, where roughly 8,000 ACKs are received within 10 seconds in the static trace. The rationale is straightforward: if β is set too small, the ACK-based trigger would invoke the LLM excessively, incurring unnecessary overhead and cost; if β is set too large, 19
D
LLM generated algorithm and explanation
case, reduce CWND moderately (e.g., by 10%), allowing queues to drain before further probing. This prevents latency inflation even in the absence of packet loss.
Algorithm 1 LLM-Inspired Congestion Control (from QTrain run)
Rule 3 — Stability-Gated Probing. Every Tprobe (≈ 1.5–2 s), if no retransmissions are observed, the RTT change is small (|dRT T | ≤ εrtt , about 2–3 ms), and throughput is stable or increasing (dT P ≥ 0), increase CWND by ∆ (about +1–3 MSS in normalized units). This mirrors the cautious, stepwise increases observed after stability (e.g., 121632 → 122632 → · · · ).
1: Params: βheavy =0.5, βmild =0.75, γcong =0.9, ∆, Tprobe ,
+ , Rheavy , wait=2s εrtt , εrtt 2: if loss_triggered ( retxt > 0 ) then 3: ▷ 1) Loss handling: Two-step multiplicative cut. 4: if retxt ≥ Rheavy or LOSS high then 5: cwnd ← max(⌊βheavy ·cwnd⌋, 1·MSS) 6: else 7: cwnd ← max(⌊βmild ·cwnd⌋, 1·MSS) 8: end if 9: ssthresh ← cwnd 10: arm_wait_timer(2s) + 11: else if congestion_gate ( retxt =0 and dRT T ≥ εrtt ) then 12: ▷ 2) Congestion Handling: Small cut (≈ 10%). 13: cwnd ← max(⌊γcong ·cwnd⌋, 1·MSS) 14: ssthresh ← cwnd 15: arm_wait_timer(2s) 16: else if probe_triggered ( time_since_last_action ≥ Tprobe ) 17: and 18: stability_gate ( retxt =0 and |dRT T | ≤ εrtt ) and 19: throughput_gate ( dT P ≥ 0 ) then 20: ▷ 3) Probing bandwidth: Conservative additive. 21: cwnd ← cwnd + ∆ 22: ssthresh ← cwnd 23: arm_wait_timer(2s) 24: else ▷ 4) Keep hold: Rising RTT/ambiguous signals. 25: cwnd ← cwnd 26: end if
Rule 4 — Holding. If neither loss nor probe conditions apply, hold CWND. This corresponds to plateaus where throughput recovers and RTT stabilizes without overshoot. Suggested defaults by scenario. Static/low-variance: Tprobe = 2 s, ∆ = 1 MSS, εrtt = 2 ms. Moderate variability: Tprobe = 1.5 s, ∆ = 2 MSS, εrtt = 3 ms. Highly fluctuating (QTrain-like): Tprobe = 1–1.5 s, ∆ = 2–3 MSS, εrtt = 4–5 ms, Rheavy = 3. Long-RTT (satellite): Tprobe = 3–4 s, ∆ = 1 MSS, εrtt = 10 ms.
LOSS # of retransmitted packet ≧ 3
Cut CWND by 30% - 50%
START
Initialization
HOLD
Wait for 2 seconds
READY
Cut CWND by 10% Increase CWND by 1 - 3 MSS
RTT
Throughput
RTT Throughput
Rule Explanations (for Alg. 1) PROBE
Rule 1 — Loss Handling. (1) If retransmissions > 0, reduce CWND immediately. (2) For heavy loss (e.g., ≥ 3 retransmits or persistent EWMA loss), cut by 50% (βheavy = 0.5); for mild loss (1–2 retransmits), cut by 25% (βmild = 0.75). (3) Reset ssthresh to the new cwnd to avoid re-entering slow start. This matches the sharp two-step reductions observed in the log (e.g., 322k → 242k → 121k).
CONG
Figure 9: A finite state machine graph of the key decisions and actions of the LLM generated algorithm.
Rule 2 — Congestion Handling. If RTT consistently increases beyond a small threshold (|dRT T | > εrtt ) without retransmissions, interpret this as early congestion from queue buildup. In this
20
Aspect
LLM-Inspired CC
Bbr
Reno
Congestion Handling
• Finite-state heuristic • Adaptive loss cut, conditioned probing, conservative hold • Finer congestion handling - Small cwnd reductions around 10%
• Model-based • Estimates bottleneck bw + min RTT
• Loss-based • AIMD
Loss Handling
• Two-step cut: 25% (mild), 50% (heavy) • Reset ssthresh • 2s cooldown
• Loss does not directly cut cwnd • Driven by pacing gain cycle
• Halve cwnd on loss • Reset ssthresh, fast recovery
Probing / Growth
• Add +∆ MSS only if stable – No retransmits, stable RTT, ↑ or steady throughput
• Periodic gain cycling – (+25%, −25%) over 8 RTTs
• +1 MSS per RTT in CA
RTT Sensitivity
• Explicit RTT gate: |dRT T | ≤ ε
• Maintains min RTT filter • Probes regardless of queues
• Ignores RTT growth • Reacts only to loss
State Machine
• START • HOLD, READY • LOSS, CONG, PROBE
• Startup, Drain • ProbeBW, ProbeRTT
• SS, CA, FR/FRR, RTO
Timers
• 2s wait after any action
• Probe pacing per RTT • ProbeRTT every ∼200ms
• None
Delay / Throughput Tradeoff
• Conservative • Avoids probing if RTT rising
• Aggressive probing • May inflate queues
• Queues grow until drop
Table 10: Comparison of LLM-Inspired CC with Bbr and Reno.
E
Comparison between LLM generated CC, Bbr and Reno
In this part, we highlight the differences between the LLMgenerated congestion control algorithm and two widely used traditional CCAs, namely Bbr and Reno. To make the comparison clear, we examine seven key aspects that capture their underlying design philosophies and operational behaviors, including principles, loss handling, probing strategy, RTT sensitivity, state machine, timer usage, and delay/throughput trade-offs. The structured comparison in Tab. 10 illustrates how the LLM-inspired approach departs from conventional loss-based and model-based schemes, emphasizing its gated probing and adaptive loss response.
21