AI 中文总结
本文以低轨卫星网络拥塞控制算法为研究对象，对比 OMNeT++/INET 模拟与 Mininet 仿真的差异，指出二者各有优劣，需结合使用以获取可靠的部署相关结果。
AI 中文摘要
评估拥塞控制本质上具有挑战性，因为性能取决于拥塞控制算法、传输栈、应用行为、测量过程和网络动态之间的交互。随着最先进的协议引入了 pacing（ pacing 即 pacing 发送，指按固定速率发送数据）、选择性丢失恢复、基于模型的控制以及最近的强化学习，这一挑战日益加剧。低轨（LEO）卫星网络是一个要求极高的场景：快速变化的路径、切换、非拥塞丢失、RTT（往返时间）变化以及瞬态热点都会影响传输行为。本文报告了针对 LEO 卫星拥塞控制，在模拟和仿真两种环境下开展的广泛评估活动中获得的经验教训。我们使用 OMNeT++/INET 模拟和基于 Mininet 的仿真（采用 Linux 传输栈）中具有可比性的实现，对比了多类拥塞控制算法，包括 Cubic、BBR 变体、LEO 专用协议以及基于强化学习的控制。这为我们提供了难得的机会，不仅可以研究协议性能，还能考察每种实验环境的方法学优势与局限性。研究结果表明，模拟对于星座规模探索、受控参数扫描以及未来部署研究不可或缺，但可能会遗漏 pacing、SACK（选择性确认）、RACK（重传确认）、内核定时和速率采样等生产传输栈机制导致的行为。仿真会暴露这些依赖实现的效应，提供必要的验证步骤，但更难扩展且精确可重复性较低。我们将这些经验提炼为结合模拟与仿真的实用方法，以获得可扩展、可复现且与部署相关的结果。
英文摘要
Evaluating congestion control is inherently challenging because performance depends on the interaction between the congestion-control algorithm, transport stack, application behaviour, measurement process, and network dynamics. This challenge is growing as state-of-the-art protocols incorporate pacing, selective loss recovery, model-based control, and, more recently, reinforcement learning. Low Earth Orbit (LEO) satellite networks are a particularly demanding setting: rapidly changing paths, handovers, non-congestive loss, RTT variation, and transient hotspots all affect transport behaviour. This paper reports the lessons learned from an extensive evaluation campaign across both simulation and emulation for LEO satellite congestion control. We compare multiple classes of congestion-control algorithms, including Cubic, BBR variants, LEO-specific protocols, and reinforcement-learning-based control, using comparable implementations across OMNeT++/INET simulation and Mininet-based emulation with the Linux transport stack. This gives us a rare opportunity to examine not only protocol performance, but also the methodological strengths and limitations of each experimental environment. Our findings show that simulation is indispensable for constellation-scale exploration, controlled parameter sweeps, and future deployment studies, but can miss behaviours caused by production transport-stack mechanisms such as pacing, SACK, RACK, kernel timing, and rate sampling. Emulation exposes these implementation-dependent effects and provides a necessary validation step, but is harder to scale and less exactly repeatable. We distil these experiences into practical lessons for combining simulation and emulation to obtain results that are scalable, reproducible, and deployment-relevant.
Comments8 pages. MASCOTS 2026
