GSOC2025AqmEvaluation

Main Page - Roadmap - Summer Projects - Project Ideas - Developer FAQ - Tools - Related Projects

HOWTOs - Installation - Troubleshooting - User FAQ - Samples - Models - Education - Contributed Code - Papers

Back to GSoC 2025 projects

Project Overview

• Project Name: Upgrade the AQM Evaluation Suite for ns-3
• Student: David Lin
• Mentors: Mohit P. Tahiliani, Aniket Singh and Tom Henderson
• Google Page: LINK
• Project Proposal: LINK
• Project Goals: The AQM Evaluation Suite is an automated framework based on RFC 7928 that simplifies simulation setup, topology creation, traffic generation, execution, and results visualization of AQM algorithms in ns-3. Originally developed in 2017 and maintained until 2019, the suite now needs an upgrade to: (1) Migrate its build system from waf to CMake (2) Integrate support for state-of-the-art AQM algorithms and enhanced ECN functionalities (3) Update simulation examples to reflect modern traffic control models (4) Package and publish the suite on the ns-3 App Store
• Repository: LINK
• About Me: I'm a CS undergrad student at the University of Toronto. I've been deeply passionate about computer network and systems in general, it's my honour to work with such a wonderful community like ns-3!

Milestones

• CMake Migration
  • Migrate the AQM Evaluation Suite’s build system from Waf to CMake

• TCP & ECN Enhancements
  • Upgrading the configuration defaults, including replacing TCP BIC with TCP Cubic in the evaluation suite. ECN support will be added by incorporating new tests and scenarios that utilize ECN signaling and feedback mechanisms. If other configuration defaults require updating, those changes will also be made.

• Upgrade AQM Algorithms
  • Support newer AQM algorithms. Parameter configurations will be added following RFC 7928 guidelines, and new scenarios will be implemented to demonstrate modern traffic control use cases.

• Packaging
  • The module will be prepared for submission to the ns-3 App Store or into the mainline, including compliance with metadata and technical requirements.

Weekly Updates

• Community Bonding Period (May 8-31, 2025)
  • Migrated the existing AQM Evaluation Suite codebase from GitHub to the new GitLab repository for centralized development.
  • Conducted an in-depth analysis of the original AQM Evaluation Suite paper. Extracted key highlights and formulated a structured list of action items to align with recent advancements in ns-3.
  • The original aqm-eval-suite was based on ns-3.30, and during the migration process, I identified an issue in the AggressiveSender scenario starting from ns-3.41, where aggressive TCP variants (BIC, HighSpeed, YeAH) no longer matched prior results (for more detailed comparisons, please see #6). Comparing with the examples from tcp-cubit, I discovered enabling pacing through Config::SetDefault("ns3::TcpSocketState::EnablePacing", BooleanValue(true)); restores expected behaviour and notably, NewReno remains unaffected.

• Week 1 (June 1-7, 2025)

• • ns-3 has transitioned from Waf to CMake as the primary build system, but the AQM evaluation suite still uses Waf configuration. I've migrated the existing build system from Waf to CMake for compatibility with latest version of ns-3 (Changes). Ensured successful compilation across supported platforms and passed all tests.
  • The original paper for AQM Evaluation Suite uses TCP BIC for the aggressive sender as TCP CUBIC wasn't implemented in ns-3; However, TCP CUBIC is now supported in ns-3. I've added support for TCP CUBIC in the AQM Evaluation Suite and replaced TCP BIC with TCP CUBIC for default aggressive congestion control in the examples. This addressed the limitation of the paper and aligns with the requirements from RFC 7928;
  • The original paper for AQM Evaluation Suite states "TCP NewReno is the default congestion control in ns-3" but latest ns-3 uses CUBIC as default. I've investigated and validated (#4) that TCP NewReno is indeed explicitly configured to eliminate surprises due to version upgrades as latest ns-3 uses CUBIC as default.

• Week 2 (June 8-14, 2025)
  • The original paper for AQM Evaluation Suite had the limitation that ECN support was under development, whereas now ns-3 has ECN support available. I've evaluated ECN support for AQM algorithms as outlined in RFC 7928 §4.5, and I've implemented the changes such that ECN was activated both at the queue level (e.g., for RED) and at the TCP sender level, based on ns-3 documentation and examples. For supported scenarios, ECN can be enabled through the --ecn=true flag. Results confirm that ECN configurations are taking effect, as the queue delay v.s. good-put shows that the algorithms that support ECN have values more concentrated around the mean, resulting in a smaller ellipsoid. This indicates a reduction in variance and a tighter Gaussian distribution, with the data clustering more closely around the center, which is the effect of ECN. Pfifo remains identical as the algorithm doesn't support ECN. For the comparisons, please see !4.

• Week 3 (June 15-21, 2025)
  • Originally, the AQM Evaluation Suite saves each run under the aqm-eval-output folder, and each run will be overwritten by the subsequent runs. I've redesigned the behaviour so that each run will be saved separately, each run will create the aqm-eval-output/{timestamp} folder, and will also have a run_config.json file to record the configuration of each run.
  • After the paper has been published, there were additional AQM algorithms that are implemented in ns-3, they are ns3::CobaltQueueDisc, ns3::FqCobaltQueueDisc, ns3::FqCoDelQueueDisc, ns3::FqPieQueueDisc, ns3::TbfQueueDisc. The new AQM algorithms that support ECN has also been enabled.

• Week 4 (June 22-28, 2025)

Resources

• AQM Evaluation Suite [Paper] [Implementation]
• RFC 7928
• Traffic Control Model in ns-3