大家读完觉得有帮助记得关注和点赞摘要评估拥塞控制本质上是具有挑战性的因为性能取决于拥塞控制算法、传输栈、应用行为、测量过程和网络动态之间的相互作用。这一挑战随着最新协议引入速率调节、选择性丢失恢复、基于模型的控制以及近期的强化学习而不断增长。低地球轨道LEO卫星网络是一个尤其苛刻的环境快速变化的路径、切换、非拥塞性丢失、RTT变化和瞬时热点都会影响传输行为。本文报告了在LEO卫星拥塞控制的仿真和模拟中进行广泛评估活动所获得的经验教训。我们比较了多类拥塞控制算法包括Cubic、BBR变体、LEO特定协议和基于强化学习的控制在OMNeT/INET仿真和基于Mininet的模拟中使用可比实现并采用Linux传输栈。这为我们提供了一个难得的机会不仅可以检查协议性能还可以检查每种实验环境的方法论优势和局限性。我们的发现表明仿真对于星座规模探索、受控参数扫描和未来部署研究是不可或缺的但可能遗漏由生产传输栈机制如速率调节、SACK、RACK、内核计时和速率采样引起的行为。模拟暴露了这些实现相关效应并提供了必要的验证步骤但更难扩展且精确可重复性较低。我们将这些经验提炼为结合仿真和模拟的实用经验以获得可扩展、可重现且与部署相关的结果。一、引言拥塞控制CC的研究仍然是现代通信系统设计和运行的核心。随着应用对更高吞吐量、更低延迟和跨异构路径更鲁棒性能的需求传输协议如Cubic[12]、BBR[4]和新兴替代方案持续演进。评估这些协议本质上是困难的性能不仅取决于CC算法还取决于周围的传输栈、应用行为、测量过程和网络动态。随着最先进协议依赖速率调节、选择性丢失恢复、基于模型的估计和强化学习这些都对实现细节和实验方法论敏感这一困难正在增加。因此受控实验环境至关重要。仿真和模拟是两种主要方法。仿真以OMNeT[26]等离散事件框架为代表提供可扩展性、可重现性以及对拓扑、流量和协议内部结构的细粒度控制。模拟使用Mininet[23]等工具在受控网络条件下执行真实协议栈和应用暴露仿真中通常不存在的实现级效应。然而这些方法的相对优势和局限性很难孤立评估特别是当目标网络高度动态且被测协议依赖于复杂的传输栈行为时。低地球轨道LEO卫星网络为此比较提供了一个严苛且日益重要的环境。LEO路径经历频繁切换、路由变化、RTT变化、非拥塞性丢失和瞬时拥塞热点。这些动态挑战了传统的CC假设并推动了LEO感知协议如SaTCP[3]和LeoCC[20]的发展。近期工作包括我们在LEO卫星网络上关于CC的实验研究[22]表明这些动态在真实栈执行下可以显著改变协议行为。然而现有评估通常聚焦于仿真或模拟对如何将星座规模仿真和真实栈模拟结合用于LEO CC研究提供的指导有限。本文汇集了一套互补技术以实现LEO CC评估中仿真和模拟的直接比较。在仿真方面我们基于OMNeT/INET LEO星座建模[27]和扩展的TCP实现。在模拟方面我们使用基于Mininet的LEO路径模拟通过Linux传输栈执行CC协议。我们还纳入了RayNet我们的强化学习RLCC实验系统[11]。结合最先进协议包括Cubic、BBR变体、SaTCP、LeoCC和Orca这创建了一个跨越星座规模仿真、真实栈模拟和基于学习的控制的通用评估工作流。我们不是将仿真和模拟视为可互换的评估工具而是使用此工作流检查每个环境使什么可见以及每个环境抽象掉了什么。在广泛实验中我们识别了两种方法论一致的情况、它们分歧的情况以及解释差距的建模或实现细节。这些包括仿真器中缺失的TCP机制、建模LEO切换和路由的困难、指标收集的差异、重现Linux传输栈行为的挑战以及基于RL的CC引入的额外复杂性。结果是一套结合使用仿真和模拟的实用经验而非依赖任何一种方法的孤立使用。本文其余部分首先建立评估环境包括与本工作相关的LEO动态、协议类别和实验工具。然后我们描述用于获得可比结果的仿真和模拟方法然后从这些实验中呈现经验教训。最后我们给出关于如何结合仿真和模拟以实现可扩展且与部署相关的LEO CC评估的指导。二、评估背景本节通过解释哪些LEO动态、拥塞控制协议和实验工具在跨仿真和模拟比较结果时是重要的来识别我们评估背后的技术环境。我们首先识别使CC评估困难的LEO网络动态然后将这些动态与本文考虑的协议类别相关联基于丢失的、基于模型的、LEO感知的和基于学习的CC。这个框架暴露了三个具体要求。首先任何LEO CC评估都需要反映传输流所见行为的路径动态包括连接性、路由、延迟、容量和丢失的变化。其次CC评估需要传输栈机制这些机制在仿真框架中支持不均包括速率调节、SACK、RACK、交付速率估计和Linux风格丢失恢复。第三基于学习的CC增加了另一层复杂性评估环境必须以规模将观察、动作、奖励和时序暴露给外部学习系统。这些需求激励了本文尝试的方法论和评估综合跨越LEO评估组件包括我们的星座模型和基于Mininet的模拟、扩展的OMNeT/INET传输支持以及用于基于学习的CC实验的RayNet。我们从LEO环境开始因为其路径动态定义了评估问题。LEO卫星网络部署大型卫星星座卫星以约7.5公里/秒的速度快速移动高度远低于地球静止系统。这降低了传播延迟但创造了短可见窗口并使连接性高度动态。由此产生的覆盖和路径行为主要由轨道高度和倾角决定。例如第一个Starlink壳层运行在550公里高度和53°倾角。高倾角壳层将覆盖范围扩展到极地地区而低倾角壳层将容量集中在赤道附近。这些轨道特性需要在卫星、用户终端和地面基础设施之间频繁改变连接性[18, 2]。LEO卫星通信依赖于三个主要基础设施组件用户终端UT、地面站GS以及日益增加的星间链路ISL。UT提供最终用户连接而GS充当卫星星座与地面互联网之间的网关。GS可以使用多个相控阵天线同时维持与多颗卫星的连接[28]。UT通常更受限一次可能只维持一个活跃卫星连接。流量可以通过弯管BP转发路由即卫星在UT和GS之间中继数据包或通过启用ISL的路径即数据包在到达地面站之前通过多颗卫星转发。BP路径在较短距离上可以高效特别是当端点靠近相关卫星和网关时[13]。启用ISL的路径可以降低RTT并提高某些长距离连接的吞吐量[14]。图1说明了这种网络结构。图1LEO卫星网络结构示例这些架构特性产生了传输层挑战这正是本文的核心。由于卫星持续移动端到端路径可以通过切换、路由更新、ISL可用性变化或GS可达性变化而改变。由此产生的效应包括非拥塞性延迟变化和丢失、频繁切换中断以及瞬时拥塞热点。这些动态使CC评估复杂化因为传输协议可能将移动性引起的丢失或RTT变化解释为拥塞。它们也使实验环境的选择变得重要需要仿真来探索星座规模的路径动态而需要模拟来验证真实传输栈如何响应选定的LEO类事件。因此我们选择对网络反馈做出不同假设并对实验环境有不同要求的协议。Cubic代表基于丢失的控制其中数据包丢失被视为主要拥塞信号[12]。BBRv1和BBRv3代表基于模型的控制其中发送方估计瓶颈带宽和传播RTT并严重依赖速率调节、交付速率估计、ACK处理和丢失恢复[4, 6]。SaTCP和LeoCC是LEO感知的适应SaTCP通过使用预测的切换或路由更新事件来扩展Cubic以避免不必要的拥塞窗口缩减[3]而LeoCC建立在BBRv1上通过检测LEO重配置事件并在路径变化时刷新其带宽和RTT模型[20]。Orca代表基于学习的CC其行为不仅取决于传输栈机制还取决于观察和控制动作的时序和粒度[1]。基于学习的CC还引入了一个表II未捕获的额外工具需求模拟器必须以规模与外部学习框架交换观察、动作和奖励。RayNet通过将OMNeT仿真暴露为RL环境来解决这一需求[11]使基于RL的CC实验能够集成到相同的仿真工作流中。总之这些协议构成了暴露仿真-模拟差距的代表性集合。表I总结了这些协议以及它们所依赖的传输机制在常见仿真和模拟环境中的原生支持。第III节描述了我们为缩小这些差距而实现的扩展。表I扩展前仿真器和模拟中TCP变体和机制的可获得性仿真模拟OMNeT/INETns-3MininetTCP变体Cubic✗✓✓BBRv1✗✓✓BBRv3✗✗✓SaTCP✗✗✓LeoCC✗✗✓Orca✗✗✓TCP机制速率调节✗✓✓SACK✓✓✓RACK✗✗✓可用的LEO工具反映了同样的分裂如表II总结。星座模拟器可以探索大规模路径动态和未来部署但它们不执行生产传输栈。模拟器执行真实栈但更难扩展并且通常只重现选定的LEO路径。Hypatia和我们的LEO模型支持星座规模仿真使其适合探索拓扑演化、路由变化和地理上多样的路径动态[18, 27]。相比之下LeoEM和LeoReplayer提供选定或重放LEO路径动态的真实栈评估这对受控验证有价值但不适合任意星座范围的探索[3, 20]。StarryNet和Xeoverse面向更广泛的LEO模拟但受限于开放性或可扩展性约束[19, 17]。表II与本文相关的LEO评估工具工具类型开放范围真实栈我们的LEO模型[27]仿真✓星座✗Hypatia[18]仿真✓星座✗StarryNet[19]模拟部分有限✓Xeoverse[17]模拟✗星座✓LeoEM[3]模拟✓选定路径✓LeoReplayer[20]模拟✓轨迹重放✓表I和II共同突显了核心方法论问题没有单一环境提供所有所需属性。仿真提供规模、可控性和与LEO星座模型及RL训练的集成但常见模拟器TCP栈落后于生产系统。模拟提供真实的Linux传输行为包括速率调节、SACK、RACK和内核速率采样等机制但更难扩展且精确可重复性较低。本文其余部分考察这些环境如何结合以及即使在扩展模拟器以支持所需传输机制后差异仍然存在的地方。三、实验方法论为允许探索LEO卫星网络上CC的设计空间我们选择围绕我们在OMNeT[26]和INET框架[15]方面的现有专业知识构建仿真。这对CC研究非常典型因为仿真允许对拓扑、流量和协议内部结构的细粒度控制允许探索机制设计和参数空间。我们在OMNeT/INET中实现了Cubic[12]、BBRv1[4]、BBRv3[6]、SaTCP[3]、LeoCC[20]和Orca[1]。我们还通过精化SACK实现以更好地反映Linux内核对应版本并添加了对RACK丢失恢复机制的支持更新了INET的TCP栈[5]。RACK被我们评估中的所有协议使用反映了现代TCP变体中的常见实践。所有源代码已公开可用以支持可重现性和未来研究。¹我们的模拟环境使用Mininet构建所有网络节点在运行Ubuntu 22.04 LTS的单台主机上表示为Linux网络命名空间配备自定义启用BBRv3的内核。主机配备AMD Ryzen Threadripper PRO 7965WX 24核处理器和64 GB内存。我们使用LeoEM[3]来模拟真实的LEO卫星网络路径。LeoEM是一个轻量级、基于Mininet的模拟框架建模用户终端、地面站以及硬切换和软切换。我们通过配置Linux流量控制tc队列规则netem来模拟不同的基础RTT和非拥塞性丢失值带宽整形使用带有丢尾FIFO队列的tbf完成。框架和绘图源代码以及所有数据和个别实验可在网上获取²。我们将套接字缓冲区发送和接收设置为高值以防止瓶颈。III-A 指标收集在ns-3和OMNeT等离散事件网络仿真框架中仿真时间通过各自事件队列中调度的事件推进。因此每个变量可以在仿真时间中变化的精确时刻被观察。OMNeT通过显式的emit信号实现这一点该信号记录被追踪的变量而不会给仿真本身带来开销因为底层执行不是实时的。相反模拟没有等效机制。因此追踪模拟变量必须谨慎进行采样过于频繁可能扭曲测量而采样过于粗略可能隐藏对CC分析重要的短时间尺度行为。为平衡这些约束我们使用iPerf3生成流量它至少以100ms的间隔报告吞吐量/有效吞吐量。这种轮询粒度固有地隐藏了快速瞬态包括突发、突然窗口变化或快速重传。为解决此问题我们通过ss补充iPerf3与每套接字内核统计信息它暴露内部TCP状态并提供更细粒度的10ms报告值如平滑RTT和cwnd。仿真的灵活性允许我们通过以类似间隔发出追踪变量来匹配OMNeT中的ss间隔。四、经验教训图2BBRv3的增量TCP机制比较我们在仿真中的初始挑战是开发LEO卫星轨迹的准确表示[27]。这需要将卫星位置导入OMNeT之外的额外工作。大量工作用于确保卫星遵循真实的轨道传播并且这种运动被转化为影响传输层行为的网络事件。特别是模型必须表示UT操作、GS部署、星间连接性、链路更新、硬切换和端到端路由。这些机制中的每一个都会影响传输流所见路径。硬切换可能引入短时中断或数据包丢失路由更新可能改变传播延迟新的卫星-终端关联可能改变瓶颈链路全局路由决策决定这些变化是局部的还是影响完整端到端路径。这是构建仿真框架的核心困难因为许多这些行为难以直接验证。商业LEO运营商不暴露其路由、切换或终端关联机制的内部细节[3]。因此即使是详细的星座模拟器也必然包含建模假设。这既是优点也是缺点仿真允许我们探索未来部署和受控场景但产生的CC行为可能取决于在已部署系统中不可直接观察的假设。这激励了模拟的补充使用。LEO仿真框架最适合生成星座规模的路径动态包括路由变化、切换和地理相关的RTT变化。然后使用模拟在真实传输栈行为下重放选定的LEO类动态。以下结果不应被解读为声称任一LEO模型精确重现商业星座。相反它们显示了当星座规模建模和真实栈执行结合时结论如何变化。这种区别很重要因为商业LEO路由、切换和终端关联策略不可直接观察因此仿真和模拟都必然依赖于建模选择。这也是为什么星座规模仿真对于多流机制和跨更广泛星座出现的拥塞热点的未来工作仍然重要。图3响应性动态网络中的累积有效吞吐量分布IV-A 传输栈行为的保真度仿真框架的一个持续困难是它们的TCP栈不反映生产系统中可用的功能集。Linux内核提供了速率调节、选择性确认SACK[9]、近期确认RACK丢失检测[5]以及广泛的CC算法包括Cubic、BBR和BBRv3的成熟实现所有这些都在公共互联网上活跃部署。OMNeT的INET栈截至OMNeT 6.4.0和INET 4.6.0提供部分SACK支持但缺乏速率调节、RACK以及Cubic、BBR和BBRv3的原生实现[26, 15, 16]。ns-3截至版本3.45更接近生产TCP行为它支持速率调节并包括Cubic和BBR。然而它不提供RACK丢失检测或BBRv3因此当前丢失恢复行为和最新的基于模型的CC方案不能直接重现[25, 24]。这些差距在LEO网络中尤其重要其中重排序、短时中断和突然RTT变化可能使传输行为严重依赖于确认处理和丢失恢复。我们通过扩展OMNeT/INET TCP栈并将更改贡献回开源仓库来缩小这一差距。在INET现有SACK功能的基础上我们实现了SACK记分板行为、数据包速率调节、RACK丢失检测和前向确认FACK风格恢复[10, 8, 7, 21]。这些扩展提供了在OMNeT/INET中实现和评估更广泛CC模型所需的传输机制包括BBRv1、BBRv3、Cubic的速率调节变体以及LEO特定方案如SaTCP和LeoCC。模拟对于验证这些扩展至关重要。如果周围的TCP机制与生产栈行为不同仅匹配高层CC逻辑是不够的。因此我们使用基于Linux的模拟作为参考点以检查扩展的INET实现在受控LEO类动态下是否产生定性相似的行为。这一经验突显了一个更广泛的教训模拟器保真度需要追踪不仅新的CC算法还要追踪塑造其行为的支持TCP机制。为说明这些实现细节的影响我们使用一个单流保真度递进实验比较连续的OMNeT/INET BBRv3实现与基于Linux的模拟如图2所示。路径以100Mbps瓶颈、50ms RTT和1个带宽延迟积BDP队列开始。在15秒时瓶颈带宽加倍在30秒时恢复为100Mbps在35秒时RTT加倍在60秒时恢复为50ms在75秒时引入1%非拥塞性丢失率在90秒时移除丢失。我们比较模拟中的BBRv3与三种仿真变体仅SACK、SACK加速率调节、SACK加速率调节和RACK。仅使用SACK时模拟的BBRv3发送方无法调节流量而速率调节是BBR以估计瓶颈速率发送模型的基础。添加速率调节改善了与模拟的对应关系但一旦引入丢失模拟发送方仍然偏离。没有RACK丢失检测更紧密地与重复确认和SACK绑定而不是Linux实现中使用基于时间的丢失推断。在快速带宽和RTT变化以及非拥塞性丢失下BBRv3改变何时进入恢复、重传哪些数据包以及多快恢复其交付速率模型。因此添加RACK使模拟的拥塞窗口演化更接近模拟实现。即使启用了SACK、速率调节和RACK仿真和模拟轨迹也不完全匹配。这种残余差距反映了难以在离散事件模型中重现的实现细节包括ACK时序、发送缓冲区状态、定时器精度和BBR内部计算中的定点算术。因此该实验突显了模拟器保真度的核心困难现代拥塞控制取决于周围的传输机制与算法本身一样多。仿真可以变得更忠实但模拟仍然是测试这些改进是否在快速变化的LEO类路径条件下重现真实栈行为所必需的。我们在这个单流保真度递进之后进行一个更动态的响应性实验其中带宽、RTT和丢失同时变化且频率更高。这测试了机制级比较中观察到的一致性是否在更现实的LEO类路径动态下仍然成立。我们重复单流50次每15秒改变带宽和RTT如图3a所示在第二种配置中额外注入随机丢失如图3b所示。然后我们在仿真中重放相同的变化时间表允许直接比较两种环境如何在总共300秒内跟踪相同的快速变化条件。仿真中观察到的响应性在很大程度上与相应的模拟结果一致强化了我们实现的鲁棒性。在Orca的情况下响应性同样较差主要归因于状态选择和奖励公式。这种一致性在丢失配置中尤为重要其中模拟栈必须依赖新添加的SACK记分板和基于RACK的恢复逻辑而不仅仅是CC方案本身。由于丢失恢复是分歧的主要来源之一随机丢失下的密切对应表明这些机制现在与方案特别是BBR变体交互的方式在定性上与Linux参考实现一致。IV-B LEO条件下的公平性分析在确定扩展模拟器能够在单流LEO类动态下重现生产传输栈行为后我们接下来检查这是否延续到多流设置中。图4比较了两个在多个LEO路径上具有相同基础RTT的竞争流。在大多数方案中仿真和模拟保持了大致相似的公平性趋势Orca除外。Orca的差异可能由训练环境和RL实现的差异引起我们重新训练的Orca使用软演员-评论家而原始实现使用双延迟深度确定性策略梯度TD3[1]由于RayNet约束。我们在平均延迟膨胀方面看到类似趋势如图4(b)所示。LeoCC观察到的更高延迟膨胀反映了其对重配置时序的敏感性即使仿真和模拟实现切换持续时间的微小差异也能改变LeoCC保留或刷新其路径模型的时间长度。图4(a) 公平性(b) 延迟膨胀两个竞争流在各种模拟/仿真的LEO路径上经历相同基础RTT时的性能图5(a) 两个流经历相同RTT(b) 起始流基础RTT为20ms加入流基础RTT如X轴所示两个竞争流的有效吞吐量比率IV-C RTT不对称下的公平性分析LEO网络中的公平性研究需要比较遍历不同卫星路径的流例如位于不同地理区域因此经历不同RTT动态的发送方-接收方对。这在当前模拟框架中难以研究它们无法真实地以规模实例化完整星座和多个地理上不同的端点对。相反模拟器通常重现一个或少数几个受控路径剖面这限制了它们暴露从星座范围路径多样性中出现的RTT间公平性效应的能力。RTT间公平性是一个特别具有挑战性的情况传统CC方案通常表现不佳。迄今为止没有通用启发式方法被证明能可靠地保证跨异构RTT流的公平性。这种情况对BBRv1尤其具有挑战性因为经历更高RTT的流将保持更多在途数据包因为它观察到更大的BDP比经历更低RTT的流占用更多缓冲区。对于BBRv3其排水参数已被调整以增加其RTT间公平性[6]这也反映在仿真中其中BBRv3相比BBRv1实现了更高的有效吞吐量比率。另一方面Orca在仿真中的性能与模拟相当不同显示出更高的公平性就像前一节一样。更广泛地说这一结果强化了基于RL的CC比传统方案更难跨环境精确复现。当某些行为如本例中的公平性未明确包含在其状态或奖励公式中时尤其如此。IV-D 可重现性与可复制性仿真提供强大的可重现性。相同的种子在跨运行和主机环境中产生可重复的结果因为整个栈是在虚拟时间中推进的确定性模型。这对回归测试和隔离单一参数的影响是理想的但可重现性并不意味着可复制性。仿真可以精确重现相同的轨迹同时仍然无法复制生产实现。这对BBRv3尤其明显其行为取决于CC算法之外的实现细节。Linux速率样本由ACK时序、速率调节、发送缓冲区状态、套接字计费和丢失恢复塑造。这些假设不直接映射到离散事件模拟器。实现细节也很重要Linux BBR对多个速率和增益计算使用定点整数算术而模拟器实现通常使用浮点值或抽象事件时间测量。采样、舍入或更新时序中的微小差异可以累积为不同的速率调节速率、拥塞窗口更新和恢复决策。模拟保留了仿真抽象掉的实现行为因为它在真实硬件上以墙钟时间运行未修改的内核栈但该栈成为不受控时序噪声的来源。即使队列规则和速率调节以精细分辨率调度每个定时事件实际何时服务也随主机的状态而变化。因此相同配置产生不同的数据包到达、RTT样本和交付速率估计BBR相应地发散。可重复性是统计性的而非精确的我们重复每个配置多次并报告聚合指标及其方差而非任何单一轨迹。对于基于RL的CC可重现性取决于完整学习流水线而不仅仅是模拟器。当控制器、随机数生成器和执行路径都固定时确定性模拟器可以重放固定的学习控制器。然而重现通过训练获得的控制器是一个更强的要求。即使使用固定的随机种子训练也可能发散因为浮点运算、并行执行、硬件后端、库版本和更新顺序可能引入小的数值差异。这些差异可以略微改变观察、奖励、梯度或策略更新并可能在训练中累积为不同的学习控制器。因此仿真可以重现网络环境但重现学习到的控制器需要控制完整的训练过程。图6两个竞争流的聚合归一化网络有效吞吐量和归一化延迟IV-E 强化学习拥塞控制的评估基于学习的CC呈现出任一环境单独无法捕获的困难。RL方案需要大量且多样化的训练经验而仿真之所以有吸引力正是因为它廉价且超实时地提供这种规模。风险在于仿真也高估了鲁棒性因为训练和评估环境通常紧密对齐。因此在仿真中训练和在模拟下评估是自然的划分但只有在两者之间的主要差异得到控制之后。这里有两个这样的差异很重要。RL智能体倾向于在训练早期重视大的拥塞窗口。扩大拥塞窗口产生即时奖励并用过量数据包淹没路径。两种环境对此处理不同剩余量在仿真中膨胀事件队列和内存压力降低吞吐量并偶尔导致崩溃而在模拟中它仅仅将发送速率驱动到硬件限制。因此相同的策略行为在一个环境中表现为工具故障在另一个环境中表现为物理饱和。离散事件模拟器在每个智能体动作步骤期间停止仿真时间以两种方式扭曲评估。由于仿真时钟在推理期间不推进即使一个过大的慢模型也不会受到惩罚仿真使用真实计算夸大了其性能。暂停还意味着观察网络和对其采取行动之间零延迟。在真实栈上总是存在增量并隐式编码在其状态空间中这实质性地塑造了学习到的策略。在真实栈上部署的仿真训练模型的未来可能性中将首次在推理时遇到这种延迟对相对于其控制行为的同步性滞后的观察采取行动。为评估我们Orca实现的保真度我们在双流设置中评估其相对于Cubic的效率。这种比较很重要因为Orca不是全新的方案它建立在Cubic行为之上并使用学习策略调整其拥塞窗口决策。单流实验将提供有限的验证因为它不能显示这些调整在竞争流量下如何表现。因此我们考虑两个并发流其中正确性反映在聚合有效吞吐量和延迟中而非孤立的每流行为。我们在图6中绘制了100Mbps瓶颈带宽、20ms基础RTT和5 BDP缓冲区的聚合有效吞吐量和平均归一化延迟。在此场景中重新训练的模拟Orca在效率方面与模拟实现表现相似。Orca的奖励公式包括一个小延迟预算应允许其探索带宽。这表明实现捕捉了Orca奖励设计中预期的效率权衡其中允许策略容忍额外延迟以实现更高的聚合有效吞吐量。五、结论现代CC的评估特别是在LEO卫星网络等动态环境中不能再依赖单一方法论。准确、与部署相关的洞察仅在可扩展仿真、高保真传输建模和真实栈模拟在原则性工作流中结合时才出现。仿真对于规模、控制和设计空间探索至关重要而模拟对于真实性和验证至关重要捕获传输栈行为和实现产物。两种方法单独使用都不足够严格的拥塞控制评估需要两者的有意结合。特别是拥塞控制行为取决于支持TCP机制如速率调节、SACK、RACK、ACK时序与算法本身一样多。在仿真中缺失这些机制可能产生定性不正确行为。准确评估需要建模完整传输栈而不仅仅是CC逻辑。本工作的一个关键结果是如果仿真框架的结果要对CC研究保持有用它们必须追踪已部署的传输栈行为。即使高层CC算法正确实现缺乏对速率调节、SACK、RACK、ACK时序和速率采样等机制的支持也可能产生定性不正确行为。我们的经验表明LEO网络暴露了传统评估方法的弱点因为它们是方法论的压力测试。非拥塞性丢失、切换和RTT变异性打破了许多现有CC中的假设动态拓扑将小的建模不准确性放大为重大行为差异。因为LEO网络放大了仿真与现实之间的差异方法论严谨性变得至关重要。最后强化学习引入了新的方法论挑战。基于RL的CC方案如Orca改变了评估问题训练严重依赖于仿真规模和速度。学习到的策略对环境不匹配如时序、延迟动作和噪声敏感。仿真可能高估鲁棒性和性能强调测试和模拟的必要性。随着CC算法的演进研究社区需要混合工作流以保持仿真和模拟环境之间的保真度以便在大规模部署之前可以得出面向部署的结论。