A mechanism for TCP-aware Active Queue Management in packet-forwarding devices

1

A mechanism for TCP-aware Active Queue Management in packet-forwarding devices

arXiv:2610.24621v1 [cs.NI] 17 Oct 2026

Swarnarup Bhunia∗ , Somit Gond∗ , Vayun Goel, Sreelakshmi Manjunath† and Padmanabhan Rajan School of Computing and Electrical Engineering, Indian Institute of Technology Mandi, HP, India {swarnarupbhunia2003, somitgond2}@gmail.com, {sreelakshmi, padman}@iitmandi.ac.in

Abstract—The deployment of Active Queue Management (AQM) policies is known to be a promising solution to bufferbloat, the problem of persistently-full large buffers in Internet routers. However, most AQMs involve tunable parameters, and some require awareness of the characteristics of the transport-layer protocol implemented at the end systems, thereby rendering their deployment infeasible. We consider one such AQM—a threshold-based queue policy which requires the packet-dropping threshold to be co-designed with relevant TCP parameters. We propose a mechanism that detects network congestion, estimates the congestion window evolution in the end hosts, estimates the required TCP parameter, and produces an optimal value of the packet-dropping threshold. Arguments based on analysis of the TCP fluid model are presented to substantiate the proposed mechanism. A simulation-based performance evaluation reveals the effectiveness of the proposed mechanism, compared to some widely implemented queue policies, in terms of various user- and system-oriented metrics. The proposed mechanism is particularly well-suited for implementation in Software Defined Networks (SDN) where the algorithms can run in the SDN controller and the packet-dropping threshold can be implemented in the dataplane switches through open interfaces. Index Terms—Bufferbloat, Active Queue Management, Latency, Congestion Control

I. I NTRODUCTION Oversized buffers in packet-forwarding devices, such as routers and switches, are known to cause large queues that lead to increased latency across the Internet [1]. This phenomenon, termed bufferbloat [2], is attributed to the use of the simple DropTail policy in these queues and is known to be the cause of congestion collapse in the nascent stages of the Internet [3], [4]. The use of effective Active Queue Management (AQM) strategies has been identified as a solution [2], [5], [6]. Although numerous AQM policies have been proposed; see the survey in [7], most of them require precise parameter tuning, making them difficult to deploy in edge or core routers. Consequently, AQMs are not actively deployed in today’s networks. This prompted the Internet Engineering Task Force to update the recommendations for the selection and deployment of AQMs, see RFC 7567 [8]. The most important, arguably, of these recommendations was that an AQM must be able to self-tune its parameters on the basis of operational conditions. ∗ Equal contribution † Corresponding author A part of this work appears as Bhunia, Swarnarup, et al., “A mechanism for TCP-aware adaptive management of queues in Internet routers.” in Proceedings of the 18th International Conference on COMmunication Systems and NETworks (COMSNETS). IEEE, 2026.

In the recent past, machine learning (ML) approaches have been adopted for AQM design, leading to AQMs which can self-tune their parameters. For a detailed survey, see [9]. Most of these AQMs, for example, LearnQueue [10], RLECN [11], PET [12] etc., use reinforcement learning to tune buffer size or packet-marking thresholds. Implementation of such AQMs requires large amounts of training data and their operation incurs significant computational overhead [9]. Moreover, the self correcting mechanisms inherent to reinforcement learning may cause instabilities in the network leading to increased jitter and unfairness. Consequently, one cannot definitively conclude that these ML-based AQMs can be deployed in real-world networks or that they outperform traditional ones [9], [13]. Parallelly, the emergence of Software Defined Network (SDN) architectures has enabled the implementation of the control plane of the network layer in remote servers. With this, queue-management decisions at packet-forwarding devices can now rely on algorithms implemented in remote servers, thereby leveraging their computational capabilities. In particular, the SDN controller can implement algorithms that enable selftuning of AQM policies deployed in SDN switches. However, despite this capability, existing research on AQM for SDNs has largely focused on developing enhancements of classical AQM schemes that are amenable to implementation in programmable SDN switches. For example, P4-CoDel [14] is based on CoDel, iRED [15] on Random Early Detection (RED), and PI2 [16] is an enhancement of the Proportional Integral (PI) queue policy. Although implementable, these enhanced AQMs carry the demerits of the underlying core techniques. For instance, iRED uses an exponential weighted moving average (EWMA) of the queue size to make packet-dropping decisions [15], similar to the original RED policy, which is known to make networks prone to instability and their operation highly sensitive to the choice of EWMA parameters and packet-dropping thresholds [17]. Consequently, practical deployment of AQMs remains challenging. Studies reveal that to effectively deploy most AQMs, their parameters and packet-dropping/marking thresholds need to be tuned in accordance with TCP parameters, inherent to the congestion control algorithm in the transport layer of the end hosts, which are unknown to the router/switch deploying the AQM [18]–[21]. Leveraging this, we develop a mechanism that can learn the congestion-control behaviour of the transport protocol implemented in the end hosts and make optimal packetdropping decisions at the routers/switches, thereby enabling

2

an AQM to self-tune its parameters for prevalent operational conditions. In this paper, we focus on a recently proposed threshold-based queue policy [19], [20], which requires that its packet-dropping threshold be co-designed with relevant TCP parameters. We outline a mechanism that estimates the congestion window maintained by the end hosts and estimates the required TCP parameter(s) from the estimated congestion window, and then computes the packet-dropping threshold based on the estimate. The so-computed threshold is used to activate the AQM once the router/switch experiences congestion. The proposed mechanism uses (i) a simple supervised learning technique to estimate the congestion window, and (ii) fundamental principles of TCP congestion control to estimate the relevant parameters. The use of supervised learning lowers the training requirement, compared to other reinforcement-learning-based AQMs which typically require rigorous training and precise tuning. Furthermore, our approach is grounded in mathematical understanding of the underlying TCP-AQM feedback system, which confirms that maintaining control-theoretic stability of the feedback system guarantees improved network performance. Therefore, the proposed algorithms promise stable operation of the network at an operating point that ensures improved performance. The performance of the proposed mechanism is evaluated using a simulation-based study conducted on ns3 [22]. It is compared with the widely used DropTail policy and the Adaptive RED (ARED) policy which is currently implemented—although not deployed—in most IP routers and SDN switches. The mechanism, supported by analytical arguments and inferences from the simulations, leads to TCPaware queue management for low-latency operation of packetforwarding devices. It is particularly well suited to SDN architectures where all the computations required for the learning-based decision making are performed in the SDN control server and the decisions are installed in the switches through P4 programming [23]. This makes the algorithms implementable in current light-weight SDN switches. The key contributions of this paper are as follows.

II. P RELIMINARIES Consider a single bottleneck link shared by N long-lived TCP flows. Treating the evolution of the congestion window maintained by a sending host as a Poisson counter driven stochastic differential equation yields a fluid model for the evolution of the expectation of the congestion window [24]. When the Poisson processes pertaining to the N end hosts are assumed to be independent and identically distributed, the aforementioned fluid model captures the average congestion window size of the N TCP flows [24]. Denote this average congestion window at time t as w(t). Suppose that the end hosts deploy a TCP variant that follows Additive Increase Multiplicative Decrease (AIMD) congestion control, where it increases the sending window
by a general additive increase (AI) function, say i w(t) , per acknowledgement received
and reduces it by a multiplicative decrease (MD) d w(t) per packet drop, the fluid model for the evolution of the average congestion window w(t) is updated as [25]  


w(t − τ ) ẇ(t) = i w(t) 1 − p(t − τ ) − d w(t) p(t − τ ) , τ (1) where p(t) represents the packet-drop probability and τ is the average round-trip time (RTT) of the TCP flows. In the treatment of TCP fluid models, it is assumed that packets are dropped, if at all, only at the bottleneck link. Now, consider the multiplicative decrease component alone. The decrease function can be written as d(w) = βw(t), where β ∈ (0, 1) is the MD parameter. In particular, when a packet is lost, the average congestion window is updated as [19], [25] w(t + 1) = (1 − β)w(t).

(2)

Note that, the congestion window update inherently depends on the packet-drop probability as TCP infers network congestion using the acknowledgement received; this probability depends on the packet-dropping decisions made by the AQM in a packet-forwarding device such as a router/switch. The threshold-based queue policy proposed in [19], [20] makes binary packet-dropping decisions as ( if q(t) ≥ qth , drop packet else, enqueue

(i) An algorithm for congestion detection through observations of queue size at a packet-forwarding device. (ii) Application of a simple supervised-learning technique to estimate the congestion window maintained at the end hosts from sequence numbers from the IP datagram payload. (iii) Methodology for estimating a representative TCP parame- where q(t) is the size of the queue, in the router/switch ter from the estimated congestion window traces supported preceding the bottleneck link, at time t and qth is a tunable parameter of the queue policy that serves as a packet-dropping by relevant mathematical derivations. (iv) An algorithm for computing the packet-dropping threshold, threshold. When the packet-drop probability p(t) is modelled using the estimated TCP parameter in conjunction with based on the binary decisions made by the threshold-based an established control-theoretic result, for stable operation queue policy, we obtain a closed-loop fluid model for a set of TCP flows feeding into a bottleneck link managed by this queue of the network with improved network performance. (v) Simulation-based performance evaluation with relevant policy. A control-theoretic analysis of the fluid model reveals topologies, traffic compositions and metrics, and compari- that the threshold-based queue policy can maintain network stability and decongest the bottleneck link, while ensuring son with relevant baseline policies. reduced queueing delays, when qth is tuned according to the The rest of the paper is organised as follows. The preliminaries sufficient condition [19] and the problem formulation are presented in Section II.  ∗ qth w ∗ Section III outlines the proposed mechanism, and Section IV qth β w ≤ π/2. (3) C̃τ presents the simulations and results. We conclude in Section V.

3

Here, w∗ is the steady-state average congestion window of the TCP flows, which is the fixed point of the fluid model (1) obtained using ẇ(t) = 0 [19]. Further, C̃ is the per-flow capacity of the bottleneck link. To implement the threshold-based queue policy and reap its benefits, a router/switch must be able to compute the packet-dropping threshold qth that satisfies condition (3). This computation requires knowledge of τ , w∗ and β, assuming that the capacity of the output link C̃ is known to the router. Using ACK-clocking methods, the router can estimate the average RTT of the TCP flows, τ . In order to estimate w∗ , the router/switch needs to estimate the evolution of the congestion window maintained by the end hosts. Further, the estimated congestion windows of the hosts can be used to estimate the parameter β through equation (2). Recall that the aforementioned TCP fluid model and the analysis rely on the assumption that all hosts use the same AIMD-based congestion control algorithm in the default parameter settings. Despite this similarity, the empirical average of the congestion windows of TCP flows sharing a bottleneck link does not strictly follow equation (2); a more elaborate discussion on this is deferred to Section III-C. In such a scenario, one must estimate a representative β parameter that governs the multiplicative decrease in the average congestion window. With this estimate at hand, inequality (3) can be used to compute a value of the threshold qth required to deploy the threshold-based policy.

Proposed Mechanism Queue size, q(t)

(A) Congestion detection Algorithm 1

Inputs from switch

Congestion?

Yes

(B) Congestion (C) β estimation window wi (t), i ∈ [1, N ] estimation (D) Threshold Random forest qth computation regressor Algorithm 2

IP Adds Port nos.

qth

(a) Schematic representation of the proposed mechanism. SDN control server Implements (A, B, C, D) Queue size IP Adds. Port nos. Ingress

Threshold qth

Switch

Pkts

Forward Buffer

(b) Implementation framework for the proposed mechanism.

A. Problem formulation Fig. 1: Pictorial representation showing the proposed mechaDeploying the threshold-based queue policy in a packetnism and its implementation. forwarding device boils down to implementing algorithms for the following. (i) Detect congestion at the router/switch by observing the shown in Fig. 1a, and the possible implementation is depicted queue size. in Fig. 1b. (ii) Estimate the congestion window evolution for all end hosts sharing the bottleneck link. (iii) Estimate the multiplicative decrease parameter β that A. Congestion detection It is well known that congestion causes synchronisation governs the decrease in the average congestion window of TCP flows across hosts sharing a link, and results in after packet loss in the event of congestion. (iv) Compute an appropriate value of the packet-dropping pronounced deterministic oscillations in the queue size [26]– threshold qth which decongests the router/switch and [28]. Building on this premise, we use queue size oscillations as an indicator of incipient congestion. Such oscillations can maintains low queueing delays. For developing the underlying algorithms for the mechanism, be detected and distinguished from other variations in the we assume that all the end systems use AIMD-based congestion queue size by computing the autocorrelation of the queue control and all the flows are long-lived, i.e., flows pertaining to size data. Oscillations in the queue size with relatively higher FTP applications that last long enough to drive the system into a amplitude and lower frequency, which indicate the onset of steady state. This simplistic choice of traffic composition aligns congestion, cause the autocorrelation of the queue size to have with the assumptions of the fluid models employed in the study lesser number of zero crossings. This relationship is illustrated of TCP-AQM feedback systems and ensures the applicability in Fig. 2, where we plotted the queue size at the router of the analytical result (3). Once we develop the required observed through packet-level simulations of a single-bottleneck algorithms, we systematically deviate from the assumptions and link of 100 Mbps capacity serving N = 60 TCP hosts. The evaluate their performance in more evolved network topologies conventional DropTail policy is used for queue management. and realistic traffic mixes through simulations. We now outline We used the TCP NewReno variant and simulated two regimes, one where the TCP flows have a small average RTT of 10 the required algorithms. ms, and another where the average RTT is 200 ms. A large III. P ROPOSED M ECHANISM bandwidth-delay product, or in particular large RTTs, is known The proposed mechanism is divided into four parts, each to cause congestion in networks that use DropTail [28]; indeed, of which is described below. The interplay between these is we see queue size oscillations in this case with large amplitude

4

Algorithm 1 Congestion detection

Queue size (pkts)

B

Queue size (pkts)

B

0

100

0

200

100

Time (s)

Time (s) 0.5 Autocorrelation

Autocorrelation

0.5

0

−0.5

200

0

2447 Index

(a) RTT = 10 ms

0

−0.5

Input: q(t), T , mz ▷ Input, Parameters tcurr ← 0, f lag ← 0, temp = ϕ, while 1 do tnxt ← tcurr + T wait until tnxt qs ← q[tcurr : tnxt ] ar ← normalized autocorrelation(qs ) z ← zero crossings(ar) if z < mz then temp ← temp ∪ 1 ▷ Append 1 to temp else temp ← temp ∪ 0 ▷ Append 0 to temp end if n ← length(temp) n X if n > 2 and temp[i] = 3 then i=n−2

0

2447 Index

(b) RTT = 200 ms

Fig. 2: Plots showing queue size vs time (top panel) and autocorrelation of the queue size (bottom panel), for small and large RTT regime. Here, B is the size of buffer. Large RTT implies a large bandwidth-delay product regime, where congestion is known to occur. Observe that the queue size exhibits pronounced oscillations in this case. When the queue size oscillates excessively, its autocorrelation has lesser zero crossings.

f lag ← 1 end if tcurr ← tnxt Output: f lag f lag ← 0 end while

▷ Check if z < mz in 3T ▷ Congestion detected

▷ Reset f lag

True Positive Rate

In Algorithm 1, mz is the zero-crossing threshold used to determine the presence of congestion. The value of mz is decided by the operating point of the algorithm; i.e. the relative cost of missing the presence of congestion, versus the cost of falsely declaring congestion when there is actually none. Assuming that the cost of false alarms are negligible, the operating point should be selected to minimize misses. When the number of zero crossings in a time duration of T and low frequency as shown in Fig. 2(b). We computed the is less than mz , then the algorithm concludes that the link is autocorrelation of the queue size, considering all possible lags. congested. We observed that the autocorrelation exhibits a lesser number The parameter T represents a time duration for checking the of zero crossings for the large RTT case. Therefore, observing queue size traces for deterministic oscillations. Although the the number of zero crossings of the autocorrelation of the choice of T is left to the implementation and may vary across queue size can help detect congestion. Algorithm 1 outlines routers, it is important to note that T must be at least a few congestion detection using this mechanism. multiples of RTT. This is because it takes at least a few RTTs for TCP hosts to infer congestion in the network and react to 1 packet loss by reducing their congestion window. Setting T to a large value, say a few seconds, would ensure that the router detects congestion successfully. However, this may result in a delay in detecting congestion, which may impact network performance. Towards understanding the influence of the parameter T on 0.5 the ability of Algorithm 1 to accurately detect congestion, we T = 5s examined the Receiver Operating Characteristic (ROC) curve T = 10s of the detector. For this we conducted 100 simulations, of the T = 15s aforementioned single-bottleneck link, of which 50 were of a T = 20s congested scenario while the remaining did not have congestion. 0 Taking it as ground truth we compared our congestion detection 0 0.2 0.4 0.6 0.8 1 approach with a range of thresholds mz , for various values of False Positive Rate the time duration T . Using this, we plotted the ROC curve Fig. 3: ROC plots showing variation of T and mz to visualize the results. The results are presented in Fig. 3. It

can be seen that most values of T give similar true positive rates (close to 100%.) To reduce latency, we thus choose to implement Algorithm 1 with T = 5 seconds. B. Congestion window estimation

Congestion window (pkts)

5

100

100 Estimated Actual

50

50

Absolute error (pkts)

Whilst detecting congestion, it is also crucial to maintain an accurate estimate of the congestion window of each TCP flow at the router which upon detection of congestion, can help 0 0 calculate the required parameters to eventually estimate the 200 300 200 300 optimal packet-dropping threshold qth to resolve congestion. This can be achieved by (1) sniffing the sequence number and 100 100 related fields from the IP datagram payload at the router and then (2) utilising an intelligent algorithm which can estimate the corresponding congestion window size maintained at the TCP sender’s end for that corresponding TCP flow. Our congestion 50 50 window estimation methodology involves sniffing the following header fields: the source and destination IP addresses and port numbers, TCP sequence number, acknowledgement number, and the packet size. The four tuple of the IP addresses and 0 0 port numbers help uniquely identify the TCP flow and these 200 300 200 300 sniffed header fields along with the time of packet arrival can Time (s) be cached and stored as a time series data per TCP flow. The congestion window size estimation is made using a random Fig. 4: Plots showing the estimated congestion window evoluforest regressor. The time series data is preprocessed to create tion juxtaposed against the actual, for two arbitrarily chosen the following input features namely direction (whether from hosts. The common legend for the comparison plots is placed source to destination or vice versa), sequence number difference, in the top-right plot alone. acknowledgment number difference, time difference (current value minus the previous value), packet size and duplicate in themselves do not capture the PNbehaviour of the average ACK count. A window size of 10 packets is considered, i.e. congestion window w(t) = ( i=1 wi (t))/N whose fixedinput features of the 9 previous packets along with the currently point value w∗ appears in inequality (3). The size of the received input packet features are concatenated and fed into the congestion window wi (t) of each source i is influenced by model as input which in turn estimates the congestion window its AI function i(w). An aggressive source with a higher size at that time instant. These estimates are cached for future increase parameter will have a larger congestion window while estimations in the auto-regressive manner as explained. a conservatively increasing source will have a smaller window. The implementation from scikit-learn’s To that end, each source contributes differently to the average RandomForestRegressor model initialized with congestion window w(t) as seen by the packet-forwarding 100 estimators is used. Training data is generated using ns-3 device. Therefore, the required estimate, that of a parameter for each simulation topology considered in the study, the that governs the decrease in w(t), is not a straight-forward details of which are deferred to Section IV. More that 0.8 average of the parameters βi . million training examples were used to train the model. Let us define a loss event as one in which the average congestion window is reduced by a fraction due to reduction in C. Parameter estimation the congestion windows of a subset of TCP sources. Suppose With the congestion window estimates at hand, we now need that there are k such loss events. Let se be the subset of TCP to estimate the multiplicative decrease parameter that governs sources which reduced their congestion window in eth loss the decrease in the average congestion window from these event, where e ∈ {1, 2, · · · , k}. estimates. We propose a mathematical model for the required estimation. The correctness of the model is established through Proposition 1. At each loss event e ∈ {1, 2, · · · , k}, consider the congestion window averaged over all TCP flows i ∈ se , the propositions presented below. When the congestion-control algorithm in TCP source host denoted as we (t). The decrease in we (t) is governed by i infers packet loss, its congestion window wi is reduced as w (t + 1) = (1 − β )w (t), (5) e

wi (t + 1) = (1 − βi )wi (t),

(4)

where βi is the MD parameter of the host i. From the estimated congestion window of a host i, obtained using the random forest regressor, the SDN controller can use wi (t) and wi (t + 1) to compute βi using equation (4). Although this can be done to obtain the MD parameter of each source, these parameters

e

e

where the parameter βe is a weighted average of the decrease parameters of all the individual TCP sources i ∈ se , and is given by X −1 X βe = βi wi (t) wi (t) . (6) i∈se

i∈se

6

Proof. Averaging equation (4) over all i ∈ se yields an equation for the evolution of the congestion window we (t), equating which with equation (5) yields the above expression for βe . Note that during each loss event there may be TCP sources that do not reduce their congestion window, i.e., for each e ∈ {1, 2, · · · , k} ∃ i ∈ / se . Therefore, βe obtained for a particular loss event e cannot be used as an estimate of the parameter that governs the multiplicative decrease in the average congestion window w(t). To model the impact of these TCP sources, one may look at the evolution of the average of we (t), across loss events. This is analogous to the PNtime average of the average congestion window w(t) = ( i=1 wi (t))/N with the set of indices in the summation being non-uniform across time. The TCP fluid model relies on ergodicity of the stochastic process that governs the congestion window evolution [24], [28]; hence we invoke the property of the time average of the process being equal to the ensemble average. The following proposition uses this property to derive the required estimate. Proposition 2. At a congested bottleneck link, the multiplicative decrease in the average congestion window w(t) is governed by a parameter β̂ given by β̂ =

k X X

βi wi (t)

e=1 i∈se

k X X

−1 wi (t) .

(7)

e=1 i∈se

Proof. When the link is congested, the average congestion window can be approximated as k

w(t) =

1X we (t). k e=1

(8)

From equation (2), the required estimate β̂ is given by β̂ = 1 −

w(t + 1) , w(t)

which upon substituting (8) and (5) yields β̂ =

k X

k X −1 βe we (t) we (t) .

e=1

e=1

(9)

As most of the TCP flows would be synchronised due to congestion, one may assume that N − |se | << N ∀ e ∈ {1, 2, · · · , k}, where | · | represents set cardinality. This leads to the approximation |se | ≈ N ∀ e ∈ {1, 2, · · · , k}. Now, substituting (5) and (6) in equation (9) yields equation (7). Observe that the estimate β̂ given by equation (7) is a weighted average of the multiplicative decrease parameter of the individual TCP sources, i.e., βi . Here, each weight is dependent on the summation of the individual congestion window across all loss events. For a congested link, the estimate given by equation (7) can be replaced with a computationally lighter one, as outlined in the proposition below. Proposition 3. The estimate β̂ given by equation (7) can be replaced by β̂ =

N N X −1 X βi m i mi , i=1

i=1

where mi is the number of times a TCP source i infers packet loss and reduces its congestion window. Proof. Equation (7) can be rewritten as β̂ =

k X N X

k X N −1 X βi wi (t)I(i, e) wi (t)I(i, e) ,

e=1 i=1

e=1 i=1

where ( 1, I(i, e) = 0,

if i ∈ se otherwise.

Rearranging the summations in equation (11) yields β̂ =

N X i=1

βi

k X

wi (t) I(i, e)

e=1

N X k X −1 wi (t) I(i, e) ,

(12)

i=1 e=1

When the link is congested, a TCP source experiences a packet loss when its sending rate reaches its share of the bottleneck bandwidth. In other words, this happens when the congestion window of the flow has reached its share of the bandwidth-delay product. It is possible that in a single loss event, a given flow may get a smaller share of the bandwidth compared to another. This implies that the first flow may have a smaller congestion window than the second. However, when we observe a given TCP flow i over a period of time and note that it experiences mi loss events, the summation of the congestion window across all loss events would be approximately to mi C̃τ. To that end, Pequal k we may use the approximation e=1 wi (t) I(i, e) ≈ mi C̃τ. Applying this approximation to equation (12) yields the revised estimate given by equation (10). The estimate given by equation (7) requires the SDN controller to maintain records of the congestion window size of all the flows, along with the information of when each flow inferred a packet loss and reduced the congestion window. Meanwhile, the estimate given by equation (10) requires the router to track only the number of times that a TCP flow reduced the size of its congestion window. The latter appears to require less memory and less computation time. However, either of the two equations, (7) or (10), may be used to compute the estimate β̂. D. Computation of packet-dropping threshold With the estimate β̂ at hand, we may now compute the packet-dropping threshold qth using inequality (3). Note that this condition also requires w∗ , C̃ and τ . Among these, C̃ is the per-flow capacity of the output link of the packet-forwarding device, which is known to the SDN controller, and the average RTT of the flows τ can be observed by the SDN controller using ack-clocking. Suppose that post congestion detection, the estimate β̂ is obtained at a time instant t, the steady-state average congestion window w∗ is calculated from the estimated congestion window traces wi (·) over a duration T as w∗ =

(10)

(11)

t N 1 X X wi (l), TN i=1 l=t−T

where T is the time duration parameter used in Section III-A.

7

Given that qth is always a positive integer and that it is Algorithm 2 Computation of packet-dropping threshold always less than the buffer size of the router B; the required Input: β̂, w∗ , C̃, τ, B value of qth can be obtained by brute force in linear time. qth ← 10 We begin by computing the function on the left-hand side κ ← 0.9 of inequality (3) using an initial value of qth , taken as 10; ▷ Initialization of f and then recompute this function by incrementing qth until if w∗ ≥ C̃τ then ▷ Checks for excessive buffering inequality (3) is satisfied. These details, along with some checks, f ← qth β̂ C̃τ κqth +1 are presented in Algorithm 2. else  w∗ qth The algorithm uses one parameter κ which serves as an upper f ← qth β̂ w∗ bound for the ratio of the average congestion window to the C̃τ end if share of bandwidth-delay product of each flow. The physical interpretation of the parameter κ emerges from the congestionwhile f ≥ π/2 & qth < B do ▷ Runs when (3) is not true control behaviour of AIMD-based TCP itself. Under such qth ← qth + 1 congestion control, the congestion window increases additively if w∗ ≥ C̃τ then ▷ Checks for excessive buffering until a loss is detected, and is reduced by a multiplicative f ← qth β̂ C̃τ κqth +1 factor thereafter. It is well known that the peak value of the else  w∗ qth congestion window of a source would ideally be equal to its f ← qth β̂ w∗ share of the bandwidth-delay product. However, when packetC̃τ end if forwarding devices use large buffers, often equal to multiples of end while the bandwidth-delay product as seen in current devices, packets return qth ▷ Outputs qth and exits are not dropped adequately; and the congestion window of an end host increases beyond its share of the bandwidth-delay product leading to excessive buffering. This can be checked by the condition w∗ ≥ C̃τ . When an AQM is to be deployed in evaluating its performance. In contrast, the parking-lot topology such a scenario, the packet-dropping threshold must account violates these assumptions and allows us to assess the proposed for such excessive buffering and drop packets in a manner that mechanism in a setting where the fluid model may not apply. Single-bottleneck dumbbell: We consider N = 60 pairs it serves as adequate feedback for the end hosts to reduce their congestion window. Therefore, when excessive buffering has of sending and receiving hosts, connected through a singleoccurred we use the parameter κ < 1 in place of the ratio bottleneck link. The link has a capacity of 100 Mbps, and is w∗ /(C̃τ ), which is > 1, in the function on the left-hand side served by two routers R1, R2 on either side. Although we use of inequality (3). This leads to a threshold qth which would the term “router” for the nodes at either ends of the link, these drop packets aggressively and bring down the w∗ appropriately nodes do not perform any routing, they simply forward packets so as to reduce queueing delay. Here, we choose κ = 0.9 on the output port leading to a single available path for each heuristically. In general, small values of κ would further limit TCP flow. These nodes may represent any packet-forwarding the congestion window of the end hosts, which may in turn device. Each host is connected to the respective router through a dedicated access link of 2 Mbps capacity. When the access affect the throughput observed by the host. links are fully utilized, the incoming traffic at the router on the sending end is 20% more than the service capacity of the link, IV. P ERFORMANCE E VALUATION creating congestion. The segment size is fixed as 1500 bytes. We now conduct packet-level simulations on ns-3 [22], The buffer size B at the router is fixed as the bandwidth-delay version 3.36.1, to evaluate the performance of the thresholdproduct. For the given bandwidth and a round-trip time of 250 based queue policy, with the threshold qth tuned using the ms, which is generally used for buffer sizing [28], we obtain mechanism proposed in Section III. We consider two network the buffer size as 2084 pkts. topologies and two traffic compositions in each topology. Parking-lot: This topology has two bottleneck links of 100 Simulations are designed with appropriately chosen factors and Mbps capacity in series, with three routers R1, R2 and R3 the performance is benchmarked against two queue policies serving them. We consider 90 pairs of sending and receiving implemented in today’s switches. These details are presented hosts. Of the 90 sending hosts, 60 are connected to R1 and in the following subsections. The entire codebase is available 30 are connected to R2. Similarly, of the 90 receiving hosts, at [29]. 60 are connected to R3 and 30 are connected to R2. Out of the 60 hosts connected to R1, 30 hosts send traffic targetted A. Network topology for 30 hosts connected to R2, and the remaining send traffic We consider two topologies: the single-bottleneck dumbbell to 30 hosts connected to R3. Further, the 30 sending hosts topology, which is a generic setup for AQM evaluation [30], connected to R2 send traffic to 30 of the 60 receiving hosts and the more-evolved parking-lot topology, which is used connected to R3. Consequently, the first bottleneck link is in many congestion-control studies [31]–[33]. The single- shared by 60 sending hosts, and traffic pertaining to 30 of bottleneck topology is consistent with the assumptions of them gets diverted at R2, while 30 new hosts are added, along the fluid model (2), which forms the mathematical basis of the network path, at R2. Each bottleneck link is thus shared the proposed mechanism, and is therefore well suited for by 60 sender-receiver pairs. All hosts are connected to their

respective routers through a dedicated 2 Mbps access link. A schematic representation of the topology is presented in Fig. 5. 1

1

2

Parameter estimate β̂

S

D

2

.. .

BL

R1

.. .

R2

60

(a) Single-bottleneck dumbbell. Traffic flows between sourcedestination pair across the bottleneck link. S3 2

3

...

29

30

S1

1

1

2

2

.. .

30

BL 1

R1

R2

BL 2

R3

. S2..

D2

.. .

30

.. . D3 D1

59 1 60

2

3

...

59 29

0.8 0.6 0.4 0.2 0 150

60

1

1

30 60

(b) Parking-lot. Traffic flows from S1 to D1, S2 to D2 and from S3 to D3, each set has 30 hosts. Each of the bottleneck links, BL1 and BL2, carries traffic between 60 sending-receiving host pairs.

Fig. 5: Schematic representation of the two topologies used in simulation. Each access link has a capacity of 2 Mbps, and each bottleneck link is of 100 Mbps.

200 250 RTT (ms)

300

Computed threshold qth (pkts)

8

50 40 30 20 10 150

200 250 RTT (ms)

300

obtained using actual cwnd obtained using predicted cwnd

Fig. 6: A comparison of the estimated parameter β̂ and the computed packet-dropping threshold qth when using the congestion window predicted by the Random Forest regressor with those obtained using the actual congestion windows maintained by the source hosts. The common legend is placed below the plots. Observe that the two curves for qth remain close throughout the range of RTT considered. UDP flows start at a time instant ∼ U[0, 5] s. Meanwhile, the short-lived TCP flows start at a time instant chosen from an exponential distribution with a mean 0.1 s, and is bounded above by 1 s. The duration of each short-lived flow is chosen in a similar way. The time gap between consecutive short-lived flows from a given host is chosen randomly from U[0.1, 10] s. The short-lived flows are also configured using the BulkSendApplication with the start and stops configured using random numbers chosen as described above. Appropriate PacketSink applications are used in all the receiving hosts. All the packets have a size of 1500 Bytes.

B. Traffic composition For each topology, we considered two traffic compositions. C. Threshold policy with proposed mechanism For queue management, at R1 in the single-bottleneck Similar to the choice of topologies, we choose one traffic composition that aligns with the assumptions of the fluid toplogy and R1 and R2 in the parking-lot topology, we used the model, and one that serves as a systematic deviation from these threshold-based policy along with the four components of the proposed mechanism: congestion detection, congestion window assumptions and is hence closer to the real-world scenario. Homogeneous traffic: All 60 sending nodes run FTP applica- prediction, parameter estimation, and threshold computation, tions, leading to long-lived TCP flows. For long lived TCP flows implemented as separate functions emulating the SDN control BulkSendApplication was installed at each sending host, server (see Fig. 1b). For congestion detection, we used and a PacketSink was installed at each receiving host. The Algorithm 1. For this, the parameter mz was set as 5, and the applications are started at the beginning of each simulation at time window T was fixed as 5 s, a few multiples of the largest a time instant chosen randomly from U[0, 5] s. Once started, a RTT used in the simulations. As observed through the ROC long-lived flow remains throughout the simulation time. All plots presented in Section III-A, Algorithm 1 detects congestion successfully for these, and regardless of these, values. The the packets have a size of 1500 Bytes. Heterogeneous traffic: In this case, 70% of the sources congestion window estimation runs in parallel and uses the run FTP applications over long-lived TCP flows, 20% of sequence numbers of the packets along with the IP addresses them run UDP, while 10% of the sending hosts run HTTP and port numbers of the sender-receiver pairs to estimate the applications that generate short-lived TCP flows. For long-lived required wi (t) waveforms for all the sending hosts. Once TCP flows BulkSendApplication was used, as before. congestion is detected, these wi (t) waveforms are fed into beta For UDP flows, the OnOffApplication was installed at estimation function, which estimates the multiplicative decrease each sending host with OffTime attribute set to 0, and the parameter using equation (10). The resultant estimate β̂, along UdpSocketFactory was used to ensure that the transport- with (i) w∗ obtained from the wi (t) waveforms for all hosts, layer protocol used is UDP. The long-lived TCP flows and (ii) the average RTT estimated using the sequence numbers,

9

1.8 1.6 1.4 1.2

150

200 250 RTT (ms)

1.8 1.6 1.4 1.2

300

100 Link Utilization (%)

2 Goodput (Mbps)

Throughput (Mbps)

2

150

200 250 RTT (ms)

80

40

300

Our AQM DropTail ARED

60

150

200 250 RTT (ms)

300

1.5 1 0.5 0

150

200 250 RTT (ms)

300

Packet Loss (%)

Queuing Delay (ms)

2

Flow Completion Time (s)

(a) Performance in terms higher-is-better metrics: throughput, goodput and link utilisation.

600

500

400

150

200 250 RTT (ms)

300

4

2

0

150

200 250 RTT (ms)

300

(b) Performance in terms of lower-is-better metrics: queueing delay, flow completion time and packet loss percentage.

Fig. 7: Single-bottleneck dumbbell, heterogeneous traffic. Plots showing the performance of the threshold-based queue policy, with the packet-dropping threshold tuned using the proposed mechanism, benchmarked against the DropTail and ARED policies. The legend placed in the top-right plot applies to all the plots.

and (iii) the capacity of the outgoing link, is fed to Algorithm 2 which returns the packet-dropping threshold qth . This threshold is then used to make packet-dropping decisions at the router, thereby deploying the AQM. A schematic representation of the implementation is shown in Fig. 1a.

RTTs regardless of network conditions. Given that operating regimes with large RTTs are known to exhibit congestion in networks carrying TCP flows [27], [28], we vary RTT in the range [150, 300] ms. In order to avoid RTT-induced synchronization among hosts, in each simulation with a fixed RTT of τ ∈ [150, 300] ms, the RTT for each sender-receiver pair is chosen randomly as T ∼ U[τ − 5, τ + 5] ms. To fix D. Benchmarking, variable factors and metrics We benchmark the performance of the threshold-based policy the required RTT, each access link is configured with a onewith the proposed mechanism against two policies that are way delay of T /4, which results in a mean RTT of τ across implemented in today’s routers/switches. The first one is the flows. Two AIMD-based TCP variants, namely LinuxReno simple DropTail policy which simply drops packets once the and NewReno are considered. We consider six performance metrics: (i) throughput, (ii) buffer is full. Secondly, we consider the Adaptive Random Early Detection (ARED) which is implemented in most Linux-based goodput, (iii) link utilisation, (iv) packet-loss percentage, (v) packet-forwarding devices. For the ARED implementation, we queueing delay, and (vi) flow-completion time. Of these, the used the parameters minQth = 50 pkts, maxQth = 100 pkts first three are higher-is-better metrics, and the remaining are which are comparable with the qth computed for the threshold- lower-is-better. The choice of metrics is consistent with the based policy. Although numerous other AQMs are proposed in recommendations in RFC 7928 [30] for evaluation of AQMs. For recording all metrics, each simulation is run until the literature, both classical as well as ML-aided, we choose these two for a comparative study given their implementation all clients have transmitted 100 MB Data. Among these status. If an AQM is to be deployed in live-networks, it must metrics, throughput and goodput were recorded at the receiving outperform those that are already implemented and are hence hosts. Here, throughput considers all packet transfers while goodput measures the rate of transfer of useful packets, i.e., closest to deployment. Along with varying the topology and traffic composition, retransmissions do not contribute to goodput. Note that these as described above, we also consider two variable factors: the two are user-oriented metrics. Link utilisation, queueing delay, round-trip time, and the TCP variant. Round-trip time is a and packet loss were recorded at the bottleneck link. These crucial factor as it is an uncontrollable network parameter; in serve as system-oriented metrics. Flow completion time is that, longer paths with large propagation delay could cause large defined as the time required to complete the transfer of a file

10

of a fixed size, and is often regarded as the most important user-oriented metric. For this, we fix a file size of 100 MB at the FTP application of each host and run the simulation until the last flow was completed.

our AQM is agnostic to the RTT, even in operating regimes with large RTTs. This is due to the fact that the qth is tuned according to condition (3) which guarantees network stability regardless of the RTT. In contrast, the goodput achieved by ARED suffers as RTT increases. Similar observations hold for the case of flow completion time, which is a lower-isE. Results and discussion better metric as opposed to the former two. Our AQM has a Firstly, to verify the efficiency of the proposed congestion marginally higher mean flow completion time as compared to window estimation using the Random Forest regressor, we DropTail, with the standard deviation of the two indicating simulated the two succeeding components, i.e. β estimation that the observed flow completion time for a give flow is and qth computation, under two settings: (i) using the ac- likely to be similar for the two policies. Meanwhile, the flow tual congestion window (cwnd) traces obtained using the completion time of ARED is larger than that of our AQM, CongestionWindow trace source of the socket at each TCP and shows a substantial increase as RTT increases. For the source, (ii) using the congestion window waveform estimated parking-lot topology, the three policies show similar relative by the Random Forest. Here, the first setting serves as a baseline performance. Additionally, for this topology, the standard to compare the second setting with. The parameter estimate β̂ deviation of throughput and goodput of ARED is much larger and the computed packet-dropping threshold qth obtained for than that of our AQM and DropTail. This indicates that the the two cases are plotted in Fig. 6. From these, we observe hosts would experience pronounced throughput fluctuations that using the congestion window estimates produced by the during the life of a connection. Likewise, a large standard Random Forest, as prescribed by the proposed mechanism, does deviation in flow completion time indicates a large variation not cause any significant deviation in the threshold qth across in the time taken by hosts to complete the file transfer, and the range of RTT considered. Notably, the curves get closer hence is reflective of unfair network behaviour. as the RTT increases, indicating that the window estimation is System-oriented performance: From the plots showing the particularly effective in the large RTT regime which is prone link utilisation, it can be observed that DropTail guarantees a to performance degradation in general. marginally better utilisation of the link than our AQM, with Next, we evaluate the performance of the proposed method the gap being less for the parking-lot topology. ARED lacks using the required metrics in the RTT range considered. In each in this aspect, with the utilisation reducing as RTT increases. simulation, throughput, goodput and packet loss are recorded Though this is seen in both topologies, it is more pronounced at the receiving hosts using FlowMonitor. Link utilisation in the parking-lot topology. This is because DropTail does not and queueing delay are recorded at the router preceding the take any action towards congestion mitigation, it simply drops bottleneck link, through the appropriate calculations on the packets once the buffer is full. In doing so, it keeps the buffer readouts of the PointToPointNetDevice/PhyTx and full most of the time, thereby never starving the link, and hence the RootQueueDiscList/∗/PacketsInQueue trace ensuring a higher utilisation. On the other hand, our AQM and source, respectively. From the traces obtained for each simula- ARED are meant to drop packets in a manner that congestion tion, the first few seconds of data corresponding to transient is alleviated. By dropping packets appropriately, they ensure behaviour are discarded and mean and standard deviation of that the queue size remains small, which could sometimes each metric are computed from the remaining data. lead to loss of link utilisation. This is indeed reflected in For flow completion time, the time required for the 100 the queueing delay and packet loss measurements. One can MB transfer is recorded for each flow, and the mean and observe that our AQM and ARED ensure a much smaller standard deviation across flows is computed. The results for queueing delay compared to DropTail. Although our AQM has the single bottleneck dumbbell topology with the LinuxReno a higher queueing delay than ARED, it can be observed that TCP variant used in heterogeneous traffic composition, for the this delay does not reflect in the flow completion time. The whole range of RTT are presented in Fig. 7. For the same observations regarding queueing delay are consistent across the setting, the results obtained with the parking-lot topology are two topologies. From the packet loss percentage, it is seen that presented in Fig. 8. In all these plots, we used the dot-whisker in the single bottleneck dumbbell topology, DropTail drops the representation, where the dot denotes the mean and the upper least number of packets while ARED drops the most, our AQM and lower whiskers are used to indicate the range of values that lies between the two. For large RTTs, the fraction of packets are within one standard deviation from the mean. We skip the dropped by our AQM is very similar to that of DropTail, which results obtained for homogeneous traffic, and TCP NewReno indicates that our AQM is able to maintain substantially less as they qualitatively appear similar to the ones presented. We queueing delay while dropping just marginally more packets. In now discuss our observations. the parking-lot topology, we see that our AQM exhibits a lower User-oriented performance: In the single bottleneck network, packet loss compared to DropTail, with the reduction being the mean throughput and goodput offered by our AQM more evident for large RTTs. ARED shows a larger packet loss implementation is seen to be marginally below that of DropTail, for small RTTs, and nearly converges to that of our AQM as and better than that of ARED. Notably, the throughput and RTT increases. Arguably, our AQM ensures better packet loss goodput remain constant across RTT in the case of our AQM, than DropTail in networks where links appear in tandem. These and ARED exhibits a reduction in throughput and goodput results show that our AQM drop packets optimally, signalling as RTT increases. In particular, the goodput performance of congestion to the TCP hosts who in turn respond by reducing

11

1.6 1.4 1.2 150

200 250 RTT (ms)

1.8 1.6 1.4 1.2 150

300

200 250 RTT (ms)

300

100

Utilization (BL 2) (%)

1.8

Utilization (BL 1) (%)

2 Goodput (Mbps)

Throughput (Mbps)

2

80 60 40 150

200 250 RTT (ms)

300

100 80 60 40 150

Our AQM DropTail ARED 200 250 RTT (ms)

300

200 250 RTT (ms)

300

1 0.5 0 150

200 250 RTT (ms)

300

1.5 1 0.5 0 150

200 250 RTT (ms)

300

2 Packet Loss (%)

1.5

2

Flow Completion Time (s)

2

Queuing Delay (R2) (ms)

Queuing Delay (R1) (ms)

(a) Performance in terms higher-is-better metrics: throughput, goodput and link utilisation.

600

500

400 150

200 250 RTT (ms)

300

1.5 1 0.5 0 150

(b) Performance in terms of lower-is-better metrics: queueing delay, flow completion time and packet loss percentage.

Fig. 8: Parking-lot, heterogeneous traffic. Plots showing the performance of the threshold-based queue policy, with the packet-dropping threshold tuned using the proposed mechanism, benchmarked against the DropTail and ARED policies. The common legend is placed in the top-right plot alone.

their sending rates. This is the reason why the threshold-based policy implemented using the proposed mechanism is able to guarantee a performance similar to DropTail in terms of most metrics, while substantially outperforming DropTail in queueing delay. V. C ONCLUSIONS Most Active Queue Management (AQM) strategies aimed at alleviating network congestion have tunable parameters that need to be co-designed with parameters of the transport protocols, such as TCP, implemented in the end hosts. Toward facilitating the deployment of such AQMs, we examined the possibility of estimating TCP parameters through packet traces accessible to the router and co-designing AQM parameters with these. In particular, we considered a threshold-based queue policy which requires the packet-dropping threshold to be codesigned with TCP parameters. This work outlines a mechanism that detects network congestion, predicts the evolution of the congestion window at end hosts, estimates the required TCP parameter, and produces a value of the packet-dropping threshold. Appropriate algorithms are outlined for congestion detection and threshold computation. The mechanism used to estimate the TCP parameter is supported by arguments based on existing results from the analysis of TCP fluid models. We conducted packet-level simulations to evaluate the performance of the threshold-based policy deployed as per the proposed mechanism. The results show that our implementation

of the AQM performs equivalent to DropTail in terms of some metrics, and particularly outperforms it in terms of the queueing delay. It is also seen to be better than ARED, which is implemented in most Linux-based routers today, in terms of most performance metrics. Although the proposed mechanism is grounded in mathematical models that account for AIMD behaviour of TCP alone, our simulations reveal that it performs well in networks carrying unresponsive UDP flows and bursty short-lived TCP flows as well. The proposed mechanism appears to be a promising solution towards TCPaware queue management through appropriate deployment of AQMs to alleviate congestion in packet-forwarding devices. It is particularly suited for SDN architectures, which provide the flexibility of control- and data-plane separation. A. Future work This work relies on results from analysis of a TCP fluid model that captures the behaviour of the AIMD congestion control algorithm. However, the proposed mechanism only needs to estimate the multiplicative decrease parameter, regardless of those that govern the additive increase. This raises the question of whether the proposed mechanism would work for traffic comprising TCP flows that employ a congestion control algorithm that decreases the congestion window multiplicatively upon detecting congestion, but increases it using a different approach. For example, CUBIC (default in Linux OS), increases its congestion window in a non-linear manner, but reduces it

12

multiplicatively in the event of congestion. It is desirable to explore whether the proposed mechanism would work for such TCP flows. Further, it is desirable to evaluate the performance of the proposed mechanism in switches that support Explicit Congestion Notification (ECN), this would also pave the way for examining its performance with TCP variants that rely on ECN marks, instead of packet drops, for congestion feedback. R EFERENCES [1] A. McFillin, “Bufferbloat may be solved, but it’s not over yet,” accessed July 2025. [Online]. Available: https://blog.apnic.net/2020/01/ 22/bufferbloat-may-be-solved-but-its-not-over-yet/ [2] J. Gettys and K. Nichols, “Bufferbloat: dark buffers in the internet,” Communications of the ACM, vol. 55, no. 1, pp. 57–65, 2012. [3] M. Allman, “Comments on bufferbloat,” ACM SIGCOMM Computer Communication Review, vol. 43, no. 1, pp. 30–37, 2012. [4] V. G. Cerf, “Bufferbloat and other Internet challenges,” IEEE Internet Computing, vol. 18, no. 5, pp. 80–80, 2014. [5] K. Nichols and V. Jacobson, “Controlling queue delay,” Communications of the ACM, vol. 55, no. 7, pp. 42–50, 2012. [6] P. Harrison, “Buffer-bloated router? How to prevent it and improve performance,” Communications of the ACM, vol. 66, no. 6, pp. 73–77, 2023. [7] R. Adams, “Active queue management: A survey,” IEEE Communications Surveys & Tutorials, vol. 15, no. 3, pp. 1425–1476, 2012. [8] F. Baker and G. Fairhurst, “IETF recommendations regarding active queue management,” Tech. Rep., 2015. [9] M. P. Toopchinezhad and M. Ahmadi, “Machine learning approaches for active queue management: A survey, taxonomy, and future directions,” Computer Networks, p. 111174, 2025. [10] N. Bouacida and B. Shihada, “Practical and dynamic buffer sizing using LearnQueue,” IEEE Transactions on Mobile Computing, vol. 18, no. 8, pp. 1885–1897, 2018. [11] E.-S. Jung, H. S. Kim et al., “RLECN—A learning based dynamic threshold control of ECN,” ICT Express, vol. 9, no. 6, pp. 1007–1012, 2023. [12] K. Cheng, T. Wang, X. Du, S. Du, and H. Cai, “PET: Multi-agent independent PPO-based automatic ECN tuning for high-speed data center networks,” arXiv preprint arXiv:2405.11956, 2024. [13] H. Jiang, Q. Li, Y. Jiang, G. Shen, R. Sinnott, C. Tian, and M. Xu, “When machine learning meets congestion control: A survey and comparison,” Computer Networks, vol. 192, p. 108033, 2021. [14] R. Kundel, J. Blendin, T. Viernickel, B. Koldehofe, and R. Steinmetz, “P4-Codel: Active queue management in programmable data planes,” in 2018 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN). IEEE, 2018, pp. 1–4. [15] L. C. De Almeida, P. D. Maciel, R. Pasquini, C. Papagianni, and F. L. Verdi, “iRED: A disaggregated P4-AQM fully implemented in programmable data plane hardware,” IEEE Transactions on Networking, 2026. [16] K. De Schepper, O. Bondarenko, I.-J. Tsang, and B. Briscoe, “PI2: A linearized AQM for both classic and scalable TCP,” in Proceedings of the 12th International on Conference on emerging Networking EXperiments and Technologies, 2016, pp. 105–119.

[17] R. J. La, “Instability of a tandem network and its propagation under RED,” IEEE Transactions on Automatic Control, vol. 49, no. 6, pp. 1006–1011, 2004. [18] C. V. Hollot, V. Misra, D. Towsley, and W. Gong, “Analysis and design of controllers for AQM routers supporting TCP flows,” IEEE Transactions on Automatic Control, vol. 47, no. 6, pp. 945–959, 2002. [19] S. Manjunath and G. Raina, “Stability and performance of compound TCP with a proportional integral queue policy,” IEEE Transactions on Control Systems Technology, vol. 27, no. 5, pp. 2139–2155, 2018. [20] ——, “Compound TCP with Random Early Detection (RED): stability, bifurcation and performance analyses,” arXiv preprint arXiv:1907.06302, 2019. [21] G. Raina, S. Manjunath, S. Prasad, and K. Giridhar, “Stability and performance analysis of compound TCP with REM and drop-tail queue management,” IEEE/ACM Transactions on Networking, vol. 24, no. 4, pp. 1961–1974, 2015. [22] G. F. Riley and T. R. Henderson, “The NS-3 network simulator,” in Modeling and tools for network simulation. Springer, 2010, pp. 15–34. [23] P. Bosshart, D. Daly, G. Gibb, M. Izzard, N. McKeown, J. Rexford, C. Schlesinger, D. Talayco, A. Vahdat, G. Varghese et al., “P4: Programming protocol-independent packet processors,” ACM SIGCOMM Computer Communication Review, vol. 44, no. 3, pp. 87–95, 2014. [24] V. Misra, W.-B. Gong, and D. Towsley, “Fluid-based analysis of a network of AQM routers supporting TCP flows with an application to red,” in Proceedings of the conference on Applications, Technologies, Architectures, and Protocols for Computer Communication, 2000, pp. 151–160. [25] G. Raina, D. Towsley, and D. Wischik, “Part II: Control theory for buffer sizing,” ACM SIGCOMM Computer Communication Review, vol. 35, no. 3, pp. 79–82, 2005. [26] H. Han, C. V. Hollot, D. Towsley, and Y. Chait, “Synchronization of TCP flows in networks with small droptail buffers,” in Proceedings of the 44th IEEE Conference on Decision and Control. IEEE, 2005, pp. 6762–6767. [27] D. Ghosh, K. Jagannathan, and G. Raina, “Right buffer sizing matters: Some dynamical and statistical studies on compound TCP,” Performance Evaluation, vol. 139, p. 102095, 2020. [28] G. Raina and D. Wischik, “Buffer sizes for large multiplexers: TCP queueing theory and instability analysis,” in Next Generation Internet Networks, 2005. IEEE, 2005, pp. 173–180. [29] S. Gond, “Repository name: MTP,” https://github.com/somitgond/mtp, 2026. [30] N. Kuhn, P. Natarajan, N. Khademi et al., “Characterization Guidelines for Active Queue Management (AQM),” IETF, Tech. Rep. RFC 7928, Jul. 2016. [Online]. Available: https://www.rfc-editor.org/info/rfc7928 [31] D. Katabi, M. Handley, and C. Rohrs, “Congestion control for high bandwidth-delay product networks,” in Proceedings of the 2002 conference on Applications, technologies, architectures, and protocols for computer communications, 2002, pp. 89–102. [32] Z. Wan, J. Zhang, S. Cheng, Y. Chen, T. Pan, P. Lin, and T. Huang, “ACC: addressing performance limitations in datacenters with atomic congestion control,” in IEEE INFOCOM 2025-IEEE Conference on Computer Communications. IEEE, 2025, pp. 1–10. [33] S. Fathalli, E. N. Weyulu, D. Zeynali, B. Chandrasekaran, and A. Feldmann, “Network-assisted congestion feedback,” IEEE Transactions on Network and Service Management, vol. 23, pp. 1797–1815, 2025.

Related documents

• A mechanism for TCP-aware Active Queue Management in packet-forwarding devices#1389567
• Queue-Theoretic Admission Control for Multi-Tenant GPU Clusters#414075
• The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol#158817
• Investigating Cybersecurity Issues in Active Traffic Management Systems#1091985
• Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks#209083