Comparative analysis of active queue management algorithms: RED, ARED, Gentle RED

Full Text

1. Introduction The continuous growth of Internet traffic, driven by the development of cloud computing, video streaming, and 5G/6G networks, imposes increasingly stringent requirements on congestion management mechanisms in network nodes. The traditional approach-tail-drop, in which packets are discarded only when the buffer is completely full-leads to global synchronization of TCP flows, sharp oscillations of throughput, and the bufferbloat effect [1]. The bufferbloat problem-systematic buffer overflow in routers causing end-to-end delay growth by orders of magnitude-has been identified as one of the key threats to quality of service [2]. Active Queue Management (AQM) algorithms, recommended by IETF in RFC 2309 [3], solve this problem by preemptive dropping or marking of packets before buffer overflow [4]. The RED (Random Early Detection) family of algorithms remains the most widely deployed class of AQM mechanisms [5]: RED is implemented in all major network operating systems (Cisco IOS, Linux tc, FreeBSD ALTQ), and its variants-ARED and Gentle RED-are shipped as standard modules in the ns-3 simulator and the Linux kernel. Despite the emergence of new algorithms (CoDel [6], PIE [7]), the choice of a specific RED variant for specific operating conditions still requires experimental justification, since analytical models do not account for all aspects of interaction with heterogeneous TCP traffic. © 2026 A. M. Palagashvili, A. M. Ermolayeva, T. R. Velieva This work is licensed under a Creative Commons “Attribution-NonCommercial 4.0 International” license. 1. Literature review The RED algorithm was proposed by Floyd and Jacobson in 1993 [8], building on the foundational work on congestion avoidance [9], and became the first practical AQM mechanism. The authors demonstrated that probabilistic early dropping of packets based on the exponentially weighted moving average (EWMA) of queue length avoids global synchronization of TCP flows and reduces average buffer delay compared to tail-drop. Practical deployment of RED revealed its main drawback-high sensitivity to parameter tuning. Christiansen et al. [10] showed that RED performance significantly depends on the ratio of minTh, maxTh, and maxP, with optimal values changing as the number of flows and load level change. To overcome this limitation, Floyd et al. [11] proposed ARED (Adaptive RED), in which the maxP parameter automatically adapts to the current load based on the deviation of the average queue from the target range. In parallel, Floyd [12] proposed the Gentle RED modification, which eliminates the sharp transition of drop probability from maxP to 1 at q̄ = maxTh. Gentle RED introduces an additional linear zone [maxTh, 2 ⋅ maxTh), in which the probability smoothly increases to unity, reducing TCP flow synchronization and decreasing delay variance during short-term bursts. An alternative to packet dropping is Explicit Congestion Notification (ECN) [13], which marks rather than drops packets, though its interaction with RED-family algorithms is outside the scope of this work. A significant contribution to mathematical modeling of TCP and RED interaction was made by Anna Vladislavovna Korolkova [14], who constructed a mathematical model of the traffic transmission process with dynamic flow intensity regulated by a RED-type algorithm. In her work, using the apparatus of stochastic differential equations with a Poisson process, an autonomous system of three ordinary differential equations was formalized for the first time, describing the joint dynamics of TCP window size, instantaneous queue length, and EWMA average. A method was proposed for determining the region of self-oscillation occurrence, and qualitative analysis of the model was performed using RED, GRED, DSRED, and ARED algorithms in the NS-2 simulator. The development of this direction was continued by Tatyana Refatovna Velieva [15], who investigated nonlinear phenomena and boundaries of the self-oscillation region in continuous-discrete dynamical models. The key contribution of this work was the adaptation of the Krylov-Bogolyubov method and harmonic linearization method to the continuous-discrete TCP/RED model, which made it possible to analytically determine the amplitude-frequency characteristics of self-oscillations and the boundaries of their occurrence region in the parameter space. Among alternative approaches to AQM, the BLUE algorithm [16], which controls drop probability based on loss events and link idle events, the SRED algorithm [17], which stabilizes queue behavior through zombie list-based flow identification, and the family of control-theory-based algorithms- the PI controller of Hollot et al. [18] and its development PIE [7]-should be noted. The fluid-based analytical framework of Misra et al. [19] provided theoretical foundations for understanding TCP/AQM interaction dynamics. The CoDel algorithm [6] uses a fundamentally different approach, tracking the sojourn time of a packet in the queue instead of queue length. Thus, despite extensive research on individual aspects of the RED family algorithms-both analytical (stability, self-oscillations) and experimental-a systematic three-way comparison of RED, ARED, and Gentle RED under strictly identical conditions with an extended set of metrics (including temporal drop structure and zone distribution of the queue) is insufficiently represented in the literature. 2. Research objectives The goal of this work is to conduct a comparative analysis of three algorithms from the RED family (RED, ARED, Gentle RED) under conditions of sustained congestion of a network node and to identify quantitative differences in buffer management dynamics, throughput stability, and the nature of congestion signals. To achieve this goal, the following tasks are set: 1. Implement a simulation model of a network with dumbbell topology in the ns-3 environment with the ability to switch the AQM algorithm while maintaining other conditions. 2. Conduct a series of experiments with identical queue parameters and load for each of the three algorithms. 3. Compare algorithms by a set of metrics: mean and tail queue length, coefficient of variation of throughput, number and temporal structure of packet drops. 4. Formulate practical recommendations for AQM algorithm selection depending on the priority requirements of the scenario. 3. Scientific novelty The scientific novelty of this work consists of the following: 1. Unlike the works of Floyd and Jacobson [8], Floyd [11, 12], and Christiansen et al. [10], where each algorithm was analyzed in isolation or in pairwise comparison with tail-drop, this work conducts a systematic three-way comparison of RED, ARED, and Gentle RED under strictly identical conditions (unified topology, identical thresholds, identical load profile), which eliminates the influence of methodological differences on results. 2. Unlike the analytical approach of Korolkova [14], who studied self-oscillation modes using ODE systems, and Velieva [15], who applied the harmonic linearization method to determine stability boundaries, this work proposes an extended set of experimental evaluation metrics, including zone distribution of EWMA average operating time and temporal structure of drops (median interval, clustering), which allows characterizing not only static indicators but also the dynamics of control actions in the simulation model. 3. Unlike the works of Hollot et al. [18] and Feng et al. [16], focused on comparing RED with fundamentally different AQM approaches (PI controller, BLUE), this work focuses on intra-family comparison of RED variants and for the first time quantitatively describes the fundamental trade-off between throughput predictability (RED, CV = 18.7%), drop minimization (ARED, -19%), and buffer delay minimization (Gentle RED, average queue 6.40 pkt). 4. RED family algorithms Active queue management algorithms begin dropping or marking packets preemptively-before the buffer overflows-based on average queue length statistics. TCP connections receive congestion signals earlier and reduce their sending rate more smoothly, preventing collapse. 1. RED (Random Early Detection) RED is the base AQM algorithm proposed by Floyd and Jacobson in 1993 [8]. The algorithm computes the exponentially weighted moving average of queue length (EWMA) and makes drop decisions based on it. Average queue update on each arriving packet: q̄ = (1 - wq) q̄ + wq q, where q is the instantaneous queue length, wq ∈ (0, 1) is the filter weight. Drop probability is determined by three zones: p(q̄) = ⎧0, ⎪ maxP ⋅ ⎨ ⎪ ⎩1, q̄ - minTh maxTh - minTh q̄ < minTh , minTh ≤ q̄ < maxTh q̄ ≥ maxTh The hard forced drop above maxTh ensures fast reaction but synchronizes TCP flows and creates sawtooth queue oscillations. 2. ARED (Adaptive RED) ARED extends RED with an adaptive mechanism [11]: the maxP parameter is periodically recomputed every Tinterval depending on the deviation of the average queue from the target range: ⎧⎪maxP + , maxP = q̄ > minTh + maxTh 2 ⎩ ⎨⎪maxP - , q̄ < minTh + maxTh 2 where and are increment and decrement coefficients ( > ). The value of maxP is bounded within an admissible range. This allows the algorithm to adapt to changing load without manual tuning; however, the adaptation introduces additional inertia and may lead to wide queue oscillations. 3. Gentle RED Gentle RED [12] modifies RED behavior in the zone above maxTh: instead of immediate forced drop, the algorithm continues the probabilistic approach up to 2 ⋅ maxTh: ⎧0, ⎪ q̄ < minTh ̄ - Th ⎪ q min maxP ⋅ , min ≤ q̄ < max ⎪ p(q̄) = ⎨ maxTh - minTh Th Th q̄ - maxTh ⎪maxP + (1 - maxP) ⋅ ⎪ ⎪ ⎩1, maxTh , maxTh ≤ q̄ < 2 maxTh q̄ ≥ 2 maxTh In the zone [maxTh, 2 ⋅maxTh) the probability linearly grows from maxP to 1, and forced drop occurs only at q̄ ≥ 2 ⋅ maxTh. This softens the reaction to short-term bursts, reduces TCP flow synchronization, and decreases the average queue length-at the cost of somewhat greater throughput variability. 2. Methods 1. Simulation environment 1. Discrete-event network simulation The study of network protocols and congestion control mechanisms can be conducted using three principal methodologies: analytical modeling, physical experimentation on real hardware, and simulation. Analytical models (such as the fluid models of TCP/RED interaction used by Korolkova [14] and Velieva [15]) provide closed-form insights into system stability but require significant simplifying assumptions that limit their applicability to complex multi-flow scenarios. Physical testbeds provide maximum realism but suffer from poor reproducibility, high cost, and limited scalability. Simu- lation-and specifically discrete-event simulation (DES)-occupies the middle ground: it models the behavior of each individual packet traversing the network at a chosen level of abstraction while maintaining full control over experimental conditions. In discrete-event simulation, the simulator does not advance time in fixed increments. Instead, it maintains a priority queue of future events (packet arrivals, timer expirations, state transitions), each tagged with its scheduled virtual time. The simulation engine processes events in chronological order: it dequeues the earliest event, advances the simulation clock to that event’s time, executes the associated callback (which may schedule new events), and repeats. Between events, no computation occurs-the simulation clock “jumps” directly to the next event. This event-driven approach provides several critical properties for network research: § Exact reproducibility. Given identical initial conditions, random seeds, and parameters, the simulation produces bitwise-identical results on any platform-a prerequisite for controlled comparative studies. § Arbitrary instrumentation. Any internal state variable (instantaneous queue length, EWMA average, TCP congestion window, drop probability) can be sampled at any point in simulated time without introducing probe traffic or measurement overhead that would perturb the system. § Time compression. A 60-second simulation of a network with dozens of nodes completes in seconds of wall-clock time, enabling systematic parameter sweeps that would require days on physical hardware. § Perfect isolation. Unlike emulation or physical experiments, simulation results are unaffected by host OS scheduling jitter, hardware variability, or background traffic. 2. The ns-3 simulator For conducting the experiments in this work, the discrete-event network simulator ns-3 (Network Simulator 3) version 3.41 was used [20]. ns-3 is an open-source simulation platform designed for research and education in the field of computer networks. It is developed and maintained by an international consortium of universities and research laboratories, distributed under the GNU GPLv2 license, and has been cited in thousands of peer-reviewed publications since its first release in 2008. ns-3 is implemented entirely in C++ with optional Python bindings for scripting convenience. The simulator is organized into a set of modules, each implementing a specific protocol layer or network technology: § internet-IPv4/IPv6 stacks, TCP (NewReno, Cubic, BBR), UDP, ARP, routing; § traffic-control-queue disciplines including RedQueueDisc (RED, ARED, Gentle RED), CoDel, PIE, FQ-CoDel; § point-to-point, csma, wifi, lte-link-layer and physical-layer models; § applications-traffic generators (BulkSend, OnOff, PacketSink) and application-layer protocols. The RedQueueDisc module, used in this work, implements all three algorithms of the RED family within a single class controlled by configuration attributes: ARED (boolean flag enabling adaptive maxP), Gentle (boolean flag enabling the gentle mode with extended probability zone), and standard threshold parameters (MinTh, MaxTh, MaxSize, QW). This unified implementation guarantees that algorithm comparison is not confounded by differences in code quality, timer resolution, or packet processing paths. Key reasons for choosing ns-3 in this work: § Protocol fidelity. The TCP implementation in ns-3 models the full state machine (slow start, congestion avoidance, fast retransmit, fast recovery) with segment-level granularity, matching the behavior of real kernel stacks. § Native AQM support. All three RED variants are available as standard modules with validated implementations referenced in the ns-3 documentation and regression test suite. § Scalability. Simulating tens of nodes and hundreds of flows is feasible on a single workstation; the event-driven core consumes memory proportional to the number of active events, not simulated time. § Tracing framework. ns-3 provides a hierarchical tracing system that allows attaching callbacks to any state change (enqueue, dequeue, drop, congestion window update) without modifying simulator source code. § Active development. ns-3 receives regular releases (3-4 per year), maintains backwards compatibility of simulation APIs, and has extensive documentation including a tutorial, manual, and model library reference. Architectural comparison of ns-2 and ns-3 Table 1 Aspect ns-2 ns-3 Language C++ core + OTcl scripting C++ throughout (Python optional) Architecture Split object model (C++/OTcl) Unified object model IP model Abstract addressing Real IP stack (BSD-like) Packet format Simulated headers Serialized byte buffers Emulation Limited Real-time scheduler, tap bridges Maintenance Frozen (last release 2011) Active (latest release 2024) Validation Community scripts Regression test suite per module 3. Comparison with ns-2 and other simulation tools ns-2 (Network Simulator 2) is the predecessor of ns-3 and was the dominant network simulation tool from the mid-1990s through the 2000s. While ns-3 inherits the research mission of ns-2, it is a complete rewrite with a fundamentally different architecture. Table 1 summarizes the key differences. The split-object architecture of ns-2 required researchers to maintain parallel class hierarchies in C++ and OTcl, leading to steep learning curves and frequent synchronization bugs between the two layers. ns-3 eliminates this duality: simulation scripts are written in the same C++ (or Python) that implements the models. Furthermore, ns-2 used abstract 32-bit node addresses and simplified packet headers, while ns-3 models real IPv4/IPv6 headers with proper checksums and fragmentation-enabling direct validation against packet captures from physical networks. A critical practical consideration is that ns-2 has not received official updates since 2011 and its RED implementation lacks the ARED adaptive mechanism as a standard module. In ns-3, all three algorithms are maintained, tested, and documented within the traffic-control module. Other simulation and emulation environments: § OMNeT++ [21] is a modular discrete-event simulation framework. Network protocols are provided by the separate INET library. OMNeT++ uses NED (Network Description) language for topology specification and has a graphical IDE. While powerful, it requires learning an additional domain- specific language and the INET RED implementation is less extensively validated than ns-3’s. § GNS3 and Mininet are network emulators rather than simulators: they run real protocol implementations (Linux kernel network stack, actual router firmware images) in virtualized or containerized environments. Emulators provide maximum protocol realism but sacrifice reproducibility (results depend on host CPU scheduling, memory pressure, and I/O latency) and scalability (each node requires real OS resources). § OPNET Modeler (now Riverbed Modeler) is a commercial discrete-event simulator with a graphical drag-and-drop interface, widely used in industry for network planning. Its proprietary license and closed-source nature limit its use in academic reproducibility contexts. Table 2 provides a summary comparison of simulation tools across dimensions relevant to this work. 4. Installation and setup ns-3 is distributed as source code and can be built on Linux (Ubuntu, Fedora, CentOS) and macOS. The build system requires a C++17-compatible compiler (GCC ≥ 9 or Clang ≥ 11), CMake ≥ 3.13, and Python 3. The minimal installation procedure is: git clone https://gitlab.com/nsnam/ns-3-dev.git ns-3.41 cd ns-3.41 Comparison of network simulation/emulation environments Table 2 Property ns-3 ns-2 OMNeT++ Mininet OPNET Type DES DES DES Emulation DES License GPLv2 GPLv2 Academic/Comm. BSD Commercial RED family support Full Partial INET Kernel Yes Reproducibility Exact Exact Exact Approximate Exact Active development Yes No Yes Yes Yes ./ns3 configure --enable-examples --enable-tests ./ns3 build The ./ns3 configure step detects available optional dependencies (GTK for visualization, SQLite for statistics, MPI for distributed simulation) and generates the build system. The ./ns3 build step compiles all enabled modules into shared libraries. After building, simulation scripts are placed in the scratch/ directory and executed via: ./ns3 run "scratch/<script-name> [--command-line-arguments]" For this work, a dedicated subdirectory scratch/red-experiments/ was created containing the simulation source code, configuration files, and analysis scripts. 2. Experimental topology The experiment uses a dumbbell topology: multiple senders are connected to a common router through fast links, and the router is connected to a single receiver through a narrow bottleneck link with limited bandwidth. The narrow link is the only possible congestion point, and the AQM queue discipline is installed on its outgoing interface. Sender 0 --\ Sender 1 --| Sender 2 --| 1 Mbit/s 2 Mbit/s ... |----------> [Router] ----------> Receiver Sender 8 --| delay 2 ms delay 10 ms Sender 9 --/ ^ AQM queue (RED / ARED / Gentle) Each of the ten senders establishes one TCP connection (using TCP CUBIC [22]) with the receiver and continuously transmits data (BulkSend). The total incoming load on the router potentially reaches 10 × 1 Mbit/s = 10 Mbit/s, which is 5 times the bottleneck link capacity. This ensures sustained congestion and allows evaluation of AQM algorithm behavior under real buffer saturation conditions. Topology parameters are listed in Table 3. 3. AQM configuration All three algorithms are launched with identical threshold parameters (Table 4). 4. Instrumentation The discrete-event network simulator ns-3 version 3.41 was used. Simulation scripts are placed in the scratch/ directory. For this experiment, a subdirectory was created with the following structure: Topology and simulation parameters Parameter Value Description nSenders 10 Number of TCP senders fastRate 1 Mbit/s Sender → router link speed (delay 2 ms) bottleneckRate 2 Mbit/s Bottleneck link speed (router → receiver) bottleneckDelay 10 ms Bottleneck link delay simTime 60.0 Simulation duration (s) Transport TCP BulkSend Segment size 512 bytes Table 3 Unified threshold parameters for RED, ARED, and Gentle RED Table 4 Parameter Value Description minTh 5 packets Lower average queue threshold-no drops below maxTh 10 packets Upper threshold; above it RED/ARED drop all packets MaxSize 100 packets Hard buffer limit ns-3.41/ +-- scratch/ +-- red-experiments/ +-- red.cc +-- configs/ | +-- red.txt | +-- ared.txt | +-- gentle.txt +-- analysis/ +-- vis.py +-- ... Configuration files specify the AQM type and queue parameters. Example configs/red.txt: aqmType=red minTh=5 maxTh=10 MaxSize=100 Analogous files for ARED (aqmType=ared) and Gentle RED (aqmType=gentle) differ only in the aqmType field value. Simulations were launched with: ./ns3 run "scratch/red-experiments/red.cc ↪ --config=configs/<algorithm>.txt" Upon completion of each simulation, three CSV files were generated: § <algorithm>_queue.csv-queue length sampled every 100 ms; § <algorithm>_drops.csv-timestamps of each packet drop; § <algorithm>_throughput.csv-throughput sampled every 100 ms. For plotting, the script vis.py with moving average smoothing (window of 30 samples) was used: // 1. Create network nodes NodeContainer senders(10), router(1), receiver(1); // 2. Configure access links (sender -> router) PointToPointHelper accessLink; accessLink.SetRate("1Mbps"); accessLink.SetDelay("2ms"); for (int i = 0; i < 10; i++) accessLink.Install(senders[i], router); // 3. Configure bottleneck link (router -> receiver) PointToPointHelper bottleneck; bottleneck.SetRate("2Mbps"); bottleneck.SetDelay("10ms"); bottleneck.Install(router, receiver); // 4. Install IP stack on all nodes InternetStackHelper stack; stack.InstallAll(); // 5. Install AQM queue discipline on bottleneck TrafficControlHelper tch; tch.SetRootQueueDisc("ns3::RedQueueDisc", "MinTh", DoubleValue(5), "MaxTh", DoubleValue(10), "MaxSize", QueueSizeValue("100p"), "ARED", BooleanValue(aredFlag), "Gentle", BooleanValue(gentleFlag)); tch.Install(bottleneckDevice); Listing 1: Topology construction and AQM installation (pseudocode) python vis.py --algorithms red ared gentle --window 30 5. Simulation script structure To illustrate the experimental setup, Listings 1-3 present simplified pseudocode of the main simulation stages. Listing 1 demonstrates the key step distinguishing the three experiments: the ARED and Gen- tle boolean flags passed to RedQueueDisc. When both are false, standard RED is used; setting ARED=true enables adaptive maxP; setting Gentle=true enables the extended probability zone. All other parameters (thresholds, topology, traffic pattern) remain identical across runs. Listing 2 shows the traffic generation pattern: ten BulkSend applications, each sending an unlimited stream of 512-byte segments over TCP, creating sustained congestion at the bottleneck. Listing 3 illustrates the instrumentation approach: ns-3’s tracing framework allows attaching callbacks to queue state changes and scheduling periodic sampling without modifying the protocol implementation code. The three output CSV files are produced by these callbacks. 3. Results The experiment consisted of three sequential simulations-one for each algorithm. Each algorithm was launched with identical queue parameters (Table 4) for 60 seconds (the first second is warm-up, excluded from analysis). // 6. Install TCP BulkSend on each sender BulkSendHelper bulkSend("ns3::TcpSocketFactory", InetSocketAddress(receiverAddr, port)); bulkSend.SetAttribute("SendSize", UintegerValue(512)); bulkSend.SetAttribute("MaxBytes", UintegerValue(0)); // unlimited ApplicationContainer senderApps; for (int i = 0; i < 10; i++) senderApps.Add(bulkSend.Install(senders[i])); // 7. Install PacketSink on receiver PacketSinkHelper sink("ns3::TcpSocketFactory", InetSocketAddress(Ipv4Address::GetAny(), port)); sink.Install(receiver); // 8. Schedule start/stop senderApps.Start(Seconds(0.0)); senderApps.Stop(Seconds(60.0)); Listing 2: Traffic generation setup (pseudocode) Algorithm evaluation metrics Table 5 Metric Data source What it characterizes Mean and median queue length *_queue.csv Average buffer delay p90 / p99 queue length *_queue.csv Tail delays Fraction of time with empty queue *_queue.csv Link underutilization Mean throughput *_throughput.csv Link utilization Coefficient of variation (CV) *_throughput.csv Flow stability Total drop count *_drops.csv Load on TCP congestion mechanism Median inter-drop interval *_drops.csv Nature of control signals 1. Queue dynamics Figure 1 shows the queue length dynamics for the three algorithms over the entire simulation time. Two phases are clearly distinguishable on the plot. Slow-start phase (t = 0-4 s). All TCP connections simultaneously enter slow-start and saturate the buffer within seconds. The queue for all algorithms reaches peak values: ARED-up to 100 packets, RED and Gentle RED-up to 84 packets. This burst is identical for all three, since the AQM algorithm has not yet accumulated sufficient statistics to react. Steady-state regime (t > 5 s). After the initial burst dissipates, the algorithms diverge in behavior. RED (blue curve) maintains the queue in the range of 5-26 packets with relatively regular oscillations. The curve rarely touches zero (empty queue only 13.4% of time): the forced drop at m_qAvg >= maxTh reacts quickly and keeps the queue “in check”, but at the cost of constant pressure on TCP flows. ARED (orange curve) demonstrates the largest oscillation amplitude and the most chaotic pattern. Periodically the queue grows to 30-35 packets in steady state and sharply collapses to zero. This is a consequence of maxP adaptation: the algorithm alternately “releases” and “tightens” the drop // 9. Queue length sampling (every 100 ms) void SampleQueue(Ptr<QueueDisc> qdisc, ofstream& out) { double t = Simulator::Now().GetSeconds(); uint32_t qLen = qdisc->GetCurrentSize().GetValue(); out << t << "," << qLen << "\n"; } ScheduleEvery(Seconds(0.1), &SampleQueue, redQueue, queueFile); // 10. Drop event tracing void OnDrop(ofstream& out, Ptr<const QueueDiscItem> item) { out << Simulator::Now().GetSeconds() << "\n"; } redQueue->TraceConnectWithoutContext("Drop", MakeBoundCallback(&OnDrop, dropFile)); // 11. Throughput sampling (every 100 ms) void SampleThroughput(Ptr<PacketSink> sink, ofstream& out, uint64_t& prevBytes) { uint64_t curr = sink->GetTotalRx(); double tput = (curr - prevBytes) * 8.0 / 0.1; // bits/s out << Simulator::Now().GetSeconds() << "," << tput << "\n"; prevBytes = curr; } ScheduleEvery(Seconds(0.1), &SampleThroughput, sink, tputFile, prevBytes); // 12. Run simulation Simulator::Stop(Seconds(60.0)); Simulator::Run(); Simulator::Destroy(); Listing 3: Trace callbacks for metric collection (pseudocode) Queue length statistics in steady-state regime Table 6 Algorithm Mean (pkt) Std. dev. Median p90 p99 Empty (%) RED 7.74 7.45 6 18 26 13.4% ARED 9.57 11.94 4 25 49 22.3% Gentle 6.40 8.86 1 19 34 26.6% probability, producing wide irregular cycles. p99 = 49 packets-the highest value among the three algorithms. Gentle RED (green curve) returns to zero most frequently (26.6% of time the queue is empty, median = 1 packet). The smooth probabilistic function in the zone [maxTh, 2*maxTh] allows TCP flows to desynchronize their windows, leading to deeper but shorter queue “dips”. Steady-state queue statistics are presented in Table 6. The time distribution across EWMA average q̄ operating zones is shown in Table 7. RED spends 34.1% of time in the forced drop zone (m_qAvg >= maxTh), explaining its high average queue. ARED spends 19.7% of time in the q̄ ≥ 2 ⋅ maxTh zone where all packets are dropped-hence its Figure 1. Queue length dynamics for RED, ARED, and Gentle RED Fraction of time in each queue management zone Table 7 Algorithm q̄ < minTh [minTh, maxTh) [maxTh, 2maxTh) q̄ ≥ 2maxTh RED 46.0% 19.8% 29.3% 4.8% ARED 52.6% 8.0% 19.6% 19.7% Gentle 60.8% 11.8% 19.8% 7.7% anomalously high p99. Gentle RED most frequently stays below minTh (60.8%) and least frequently enters the hard drop zone (7.7%). 2. Throughput The throughput plot (Figure 2) is constructed with moving average smoothing (window of 30 samples), thus displaying data starting from t ≈ 29 s. The Y-axis is intentionally compressed to the range 1.74-1.86 Mbit/s, allowing examination of differences invisible on the full scale. All three algorithms stably maintain throughput near 1.80-1.81 Mbit/s (∼90% of the nominal 2 Mbit/s link capacity). This means that the choice of AQM algorithm at these parameters does not affect bandwidth utilization: all three mechanisms equally effectively “fill” the link. The characteristic peak around t = 33 s (all curves reach ∼1.86 Mbit/s) represents synchronous recovery of TCP flows after the initial wave of drops: congestion windows simultaneously begin growing, creating a short-term excess flow. Despite identical means, RED demonstrates the lowest variability (CV = 18.7%) [23]: hard synchronous drops keep all TCP flows in step, making throughput predictable. Gentle RED has the highest CV (24.7%)-asynchronous window management creates more “ripple”, although the mean does not suffer. Figure 2. Throughput comparison: RED, ARED, and Gentle RED Throughput statistics (CV-coefficient of variation) Table 8 Algorithm Mean (Mbit/s) Std. dev. Min. Max. CV RED 1.8047 0.3380 0.533 3.621 18.7% ARED 1.8039 0.3950 0.553 3.293 21.9% Gentle 1.7998 0.4444 0.352 3.654 24.7% 3. Packet drops The plot (Figure 3) presents drop moments as a scatter diagram: each point is one dropped packet. Three horizontal bands correspond to the three algorithms. RED (bottom band, blue)-the densest and most continuous band: points fill virtually the entire simulation time, with only rare small gaps. RED actively drops in 47 out of 58 seconds with a median inter-drop interval of only 2.3 ms. The forced drop at m_qAvg >= maxTh creates a continuous stream of dropped packets each time the average queue exceeds the threshold. ARED (middle band, orange)-clearly visible drop clusters separated by noticeable pauses. The algorithm is active in 33 out of 58 seconds. The maxP adaptation periodically reduces drop probability to zero, giving flows a “break”. However, when drops occur, their density within a cluster is high (maximum burst-276 drops per second). Gentle RED (top band, green)-the most pronounced cluster structure with the longest pauses between clusters. The algorithm is active in only 27 out of 58 seconds. Within each cluster, drops are dense (maximum burst-305/s), but between them-extended “quiet” intervals. Drop statistics summary is presented in Table 9. RED generates 19-21% more drops than the competitors. The median inter-drop interval for RED (2.3 ms) is 4-5 times smaller than for ARED and Gentle-RED practically continuously drops packets during congestion periods, while ARED and Gentle operate in “pulses”. Figure 3. Packet drop moments for each algorithm Packet drop statistics Table 9 Algorithm Total drops Rate (drops/s) Median interval Active seconds Max. burst RED 1240 21.34 2.3 ms 47 321 ARED 1003 17.11 11.3 ms 33 276 Gentle 1026 17.75 9.1 ms 27 305 4. Discussion The final comparison of algorithms across all key metrics is presented in Table 10. RED provides the most predictable and stable throughput (CV = 18.7%) but achieves this at the cost of the highest number of drops (1240) and the highest average queue. The continuous nature of drops synchronizes TCP flows, creating rigid, “quantized” congestion management dynamics. ARED minimizes the number of drops (1003, -19% vs. RED) and least frequently disturbs flows. However, maxP adaptation creates significant queue instability (std. = 11.94, p99 = 49 packets) with periods of excessive buffer growth-potentially undesirable from a delay perspective. Gentle RED achieves the lowest average queue (6.40 packets) and the highest fraction of empty buffer (26.6%). The number of drops is comparable to ARED (1026), but they are distributed in the most compact pulses with long pauses between them. The cost is the highest throughput variability (CV = 24.7%) due to TCP flow desynchronization. 5. Conclusion The conducted experiment showed that all three AQM algorithms-RED, ARED, and Gentle RED- provide practically the same average throughput (∼1.80 Mbit/s, ∼90% of link capacity), but fundamentally differ in the nature of buffer management and the load on the TCP congestion control mechanism. Summary comparison of RED, ARED, and Gentle RED algorithms Table 10 Metric RED ARED Gentle RED Mean throughput 1.8047 Mbit/s 1.8039 Mbit/s 1.7998 Mbit/s Throughput CV 18.7% 21.9% 24.7% Mean queue 7.74 pkt 9.57 pkt 6.40 pkt Queue std. dev. 7.45 11.94 8.86 p99 queue 26 pkt 49 pkt 34 pkt Empty queue (%) 13.4% 22.3% 26.6% Total drops 1240 1003 1026 Drop pattern continuous clustered pulsed Median inter-drop interval 2.3 ms 11.3 ms 9.1 ms The key difference lies in the trade-off between predictability and aggressiveness of queue management. RED acts most aggressively: forced drop upon exceeding maxTh keeps the queue “in check” (mean 7.74 packets) and ensures minimum throughput variability (CV = 18.7%), but at the cost of the highest number of drops (1240) and continuous pressure on TCP flows. ARED, conversely, sacrifices queue stability for reduced drops: maxP adaptation decreases drops by 19% compared to RED, but produces wide oscillations (std. = 11.94, p99 = 49 packets), unacceptable for delay-sensitive applications. Gentle RED occupies an intermediate position, achieving the lowest average queue (6.40 packets) due to a smoother drop function that desynchronizes TCP flows and reduces buffer occupancy-but increasing throughput variability (CV = 24.7%). The obtained results confirm that AQM algorithm selection is determined by specific scenario requirements: there is no single “best” solution-each algorithm is optimal for its target metric. Application recommendations: o When minimum buffer delay is priority-Gentle RED (lowest average queue 6.40 pkt). o When minimum drop count is priority-ARED (19% fewer drops than RED). o When predictable throughput is priority-RED (lowest CV 18.7%). 6. Code availability The simulation source code and analysis scripts are publicly available at: https://github.com/fibersel/ dcm-paper.

About the authors

Abuli M. Palagashvili

RUDN University

Email: 1042250185@rudn.ru
ORCID iD: 0009-0007-7009-7038

PhD Student of Department of Department of Probability Theory and Cyber Security of RUDN University

6 Miklukho-Maklaya St, Moscow, 117198, Russian Federation

Anna M. Ermolayeva

RUDN University

Email: ermolaeva-am@rudn.ru
ORCID iD: 0000-0001-6107-6461

Assistent Professor of Department of Probability Theory and Cyber Security of RUDN University

6 Miklukho-Maklaya St, Moscow, 117198, Russian Federation

Tatyana R. Velieva

RUDN University

Author for correspondence.
Email: velieva-tr@rudn.ru
ORCID iD: 0000-0003-4466-8531

Candidate of Physical and Mathematical Sciences, Associate Professor of Department of Probability Theory and Cyber Security of RUDN University

6 Miklukho-Maklaya St, Moscow, 117198, Russian Federation

References

Supplementary files