LeoCC: Making Internet Congestion Control Robust to LEO Satellite Dynamics

The recent renaissance of low Earth orbit (LEO) satellite networks expands the boundaries of global Internet access, but also introduces substantial new challenges for existing end-to-end congestion control algorithms (CCAs). The rapid and continuous movement of LEO satellites leads to infrastructure-level dynamics, resulting in frequent, LEO-dynamics-induced changes in link capacity, delay, and packet loss rate, which can further mislead the rate control in existing CCAs and cause self-limited performance.

This paper presents LeoCC, a novel CCA that addresses the above challenges and is robust to LEO satellite dynamics. The core idea behind LeoCC lies in a critical characteristic of emerging LEO networks called “connection reconfiguration”, which implicitly reflects satellite path changes and is strongly correlated to network variations. Specifically, LeoCC employs a suite of new techniques to: (i) efficiently detect reconfiguration on the endpoint; (ii) apply a reconfiguration-aware model to characterize and estimate network conditions accurately; and (iii) precisely regulate the sending rate. We implement LeoCC in Linux kernel and evaluate its performance through extensive experiments conducted in both real LEO networks and a controlled lab environment. The results show that LeoCC can achieve the best throughput-delay balance under various LEO network conditions as compared to other existing CCAs: it achieves 85∼494% higher throughput than Cubic, Copa, BBRv3, and accomplishes 44∼56% lower delay than BBRv1 and VIVACE.

近期低地球轨道（LEO）卫星网络的复兴扩展了全球互联网接入的边界，但同时也为现有的端到端拥塞控制算法（CCAs）带来了巨大的新挑战。LEO卫星的快速持续移动导致了基础设施层面的动态性，从而引起由LEO动态特性导致的链路容量、延迟和丢包率的频繁变化，这会进一步误导现有拥塞控制算法中的速率控制，并导致其性能受限。

本文提出了一种名为 LeoCC 的新型拥塞控制算法，该算法旨在应对上述挑战并对LEO卫星的动态特性具有鲁棒性。LeoCC的核心思想在于一个新兴LEO网络的关键特性，即“连接重构”（connection reconfiguration），该特性含蓄地反映了卫星路径的变化，并与网络状况的变动强相关。具体而言，LeoCC采用了一套新技术来实现：(i) 在终端上高效地检测连接重构；(ii) 应用一种感知重构的模型来准确地描述和估计网络状况；以及 (iii) 精确地调节发送速率。

我们在Linux内核中实现了LeoCC，并通过在真实LEO网络和受控实验室环境中进行的大量实验来评估其性能。结果表明，与其他现有的拥塞控制算法相比，LeoCC在各种LEO网络条件下都能实现最佳的吞吐量-延迟平衡：其吞吐量比Cubic、Copa、BBRv3高出85%～494%，而延迟比BBRv1和VIVACE低44%～56%。

TL; DR

我们发现 reconfig 信息可以影响路径的变化, 而它可以被提前预知

因此, 我们可以:

1. 在终端上提前预测 reconfig
2. 用一个模型来感知 reconfig 变化的含义
3. 端侧: 根据上述信息进行精确地调节

Introduction

Low-earth-orbit (LEO) satellite networks (LEO networks for short) are evolving rapidly in recent years, thanks to the fast deployment of mega-constellations such as Starlink [8], OneWeb [9] and Amazon Kuiper [4]. Emerging LEO networks aim to provide broadband coverage and low-latency access ubiquitously, and are carrying an increasing amount of Internet traffic [13]. For example, SpaceX’s Starlink, the largest operational LEO network today, has connected more than five million users with Internet access in nearly 100 countries, spanning all seven continents as of Jan 2025 [17].

One key characteristic differentiating LEO networks with other conventional terrestrial networks is that: a portion of the network infrastructure (i.e., LEO satellite switches/routers) is moving at a high velocity related to the earth’s surface. Hence, for an Internet path through LEO networks, a sub-set of its intermediate nodes and links continuously change over time. Such unique LEO satellite dynamics, not only result in rapidly varying link capacity, but also involve frequent delay variations (e.g., caused by path fluctuations) and high packet loss rate (e.g., caused by space-ground handovers and lossy satellite channels), imposing substantial challenges on existing Internet congestion control algorithms (CCAs).

近年来，得益于Starlink [8]、OneWeb [9] 和亚马逊Kuiper [4] 等巨型星座的快速部署，低地球轨道（LEO）卫星网络（简称LEO网络）正在迅速发展。新兴的LEO网络旨在提供无处不在的宽带覆盖和低延迟接入，并承载着日益增长的互联网流量 [13]。例如，作为当今最大的在轨运行LEO网络，SpaceX的Starlink截至2025年1月已为近100个国家、遍布七大洲的超过五百万用户提供了互联网接入服务 [17]。

LEO网络区别于其他传统地面网络的一个 关键特征 是：其部分网络基础设施（即LEO卫星交换机/路由器）相对于地球表面高速移动。因此，对于一条经过LEO网络的互联网路径而言，其一部分中间节点和链路会随时间不断变化。

这种独特的LEO卫星动态特性，不仅导致链路容量的快速变化，还带来了频繁的延迟波动（例如，由路径抖动引起）和高丢包率（例如，由星地切换和有损卫星信道引起），给现有的互联网拥塞控制算法（CCAs）带来了巨大挑战。

Fundamentally, every CCA relies on certain network assumptions, and the CCA performance is highly dependent on the accuracy of these assumptions in real-world network environments [70]. However, the impact of LEO dynamics on networks breaks the underlying assumptions of existing CCAs. Specifically, classic lossbased (e.g., Cubic [43]) and delay-based (e.g., Vegas [33], Copa [29]) CCAs assume that increased packet loss rate and delay indicate network congestion. But in LEO networks these “congestion signals” are likely caused by LEO-dynamics-induced factors such as frequent satellite handovers and path changes. Model-based CCAs (e.g., BBR [16, 35]) estimate the bottleneck based on the assumption that the maximum bandwidth and minimum RTT observed by the sender during a past period represent the network path’s bottleneck capacity and propagation RTT. However, this assumption becomes inaccurate in LEO networks since the link capacity and propagation RTT could drastically change over time. Recent learning-based CCAs like VIVACE [37] apply learning theory to rate control. They also carry assumptions that loss and RTT gradient can serve as useful congestion signals, but they are unable to discriminate LEOdynamics-induced packet loss and RTT increase in LEO networks. Consequently, as we identified in several real Starlink vantage points, existing CCAs either overreact to LEO-dynamics-induced network variations, suffering from self-constrained performance, or overestimate link capacity, creating high queuing delay.

从根本上说，每一种拥塞控制算法都依赖于特定的网络假设，而算法的性能高度依赖于这些假设在真实网络环境中的准确性 [70]。然而，LEO的动态特性对网络造成的影响打破了现有拥塞控制算法的底层假设。

具体来说，经典的基于丢包（如Cubic [43]）和基于延迟（如Vegas [33]、Copa [29]）的拥塞控制算法假定丢包率和延迟的增加预示着网络拥塞。但在LEO网络中，这些“拥塞信号”很可能是由LEO动态特性引发的因素（如频繁的卫星切换和路径变化）造成的。

基于模型的拥塞控制算法（如BBR [16, 35]）则基于这样的假设来估计瓶颈：即发送方在过去一段时间内观测到的最大带宽和最小RTT分别代表了网络路径的瓶颈容量和传播RTT。然而，在LEO网络中，由于链路容量和传播RTT会随时间剧烈变化，这一假设不再准确。

近期的基于学习的拥塞控制算法（如VIVACE [37]）将学习理论应用于速率控制。它们也假设丢包和RTT梯度可作为有效的拥塞信号，但它们无法区分由LEO动态特性引发的丢包和RTT增长。

因此，正如我们在多个真实的Starlink观测点所发现的， 现有的拥塞控制算法要么对LEO动态性引发的网络变化反应过度，从而导致性能自我受限；要么高估链路容量，从而产生巨大的排队延迟。

为什么现有的CCAs不行

CC高度依赖于网络假设, 现有的假设完全对不上LEO的特性

导致要么过度敏感，要么过度慵懒…

To tackle these challenges, we present LeoCC (LEO Network Congestion Control), a novel congestion control algorithm designed to remain robust under the highly dynamic conditions of LEO networks LeoCC can maintain high throughput and low latency in LEO networks, and does not require any modification on the network or applications. In addition, LeoCC can automatically adapt to bottleneck shifting in LEO and non-LEO links. Central to LeoCC’s improvement is that LeoCC leverages a crucial feature in today’s LEO networks called “connection reconfiguration”, based on which satellite operators dynamically schedule LEO satellite connections to enable seamless space-ground communication. While implicit, reconfiguration has a strong correlation with the drastic variations perceived by endpoints, and thus is a useful indicator for discriminating LEO-dynamics-induced network variations and accurately modeling LEO bottlenecks. Specifically, LeoCC adopts a reconfiguration-aware network estimator to promptly detect both periodic and aperiodic reconfiguration and accurately estimate network conditions. Furthermore, LeoCC incorporates a robust rate controller that dynamically adjusts to consecutive reconfiguration intervals, quickly regulating the sending rate to accommodate drastic capacity changes while maintaining low delay.

为应对这些挑战，我们提出了 LeoCC（LEO Network Congestion Control），一种新颖的拥塞控制算法，其设计旨在LEO网络的高度动态条件下保持鲁棒性。LeoCC能够在LEO网络中同时保持高吞吐量和低延迟，且无需对网络或应用程序进行任何修改。此外，LeoCC能自动适应瓶颈在LEO链路与非LEO链路之间的切换。LeoCC性能提升的核心在于它利用了当今LEO网络中的一个关键特性，即“连接重构”（connection reconfiguration），卫星运营商基于此特性动态调度LEO卫星连接，以实现无缝的星地通信。尽管连接重构是隐式的，但它与终端所感知的剧烈网络变化具有强相关性，因此是区分LEO动态引发的网络变化并准确建模LEO瓶颈的有效指标。

具体来说，LeoCC采用了一种感知重构的网络评估器，以迅速检测周期性和非周期性的重构，并准确估计网络状况。此外，LeoCC集成了一个鲁棒的速率控制器，该控制器能根据连续的重构间隔进行动态调整，从而快速调节发送速率以适应剧烈的容量变化，同时保持低延迟。

Collectively, this paper makes the following key contributions:

• Based on real Starlink vantage points across different geographical locations, we uncover the performance issues facing existing Internet CCAs in LEO networks and identify the root causes.

• We present LeoCC, a novel CCA that is robust to drastic LEO network variations. We implement LeoCC in the Linux kernel without requiring modifications to the network or application.

• To build reproducible LEO network environments and evaluate LeoCC, we implement LeoReplayer, an accurate record-and-replay tool for LEO networks. We use LeoReplayer to record a large-scale LEO network dataset containing more than 4.8K traces that can accurately reflect real LEO network conditions.

• We conduct extensive evaluations for LeoCC and other existing CCAs in both real LEO networks and our in-lab trace-driven testbed. Extensive results demonstrate that LeoCC can push the Pareto frontier and achieve the best throughput-delay balance in LEO networks as compared to other existing CCAs: it achieves 85∼494% higher throughput than Cubic, Copa and BBRv3, and accomplishes 44∼56% lower delay than BBRv1 and VIVACE.

We have released the source code of LeoCC, the record-and-replay tool LeoReplayer and our anonymous LEO network traces 1 . We hope our efforts can facilitate future CCA research in emerging LEO networks. This paper does not raise any ethical issues.

总的来说，本文做出以下几点关键贡献：

• 基于不同地理位置的真实Starlink观测点，我们揭示了现有互联网拥塞控制算法在LEO网络中面临的性能问题，并识别了其根本原因
• 我们提出了LeoCC，一种对LEO网络剧烈变化具有鲁棒性的新型拥塞控制算法。我们在Linux内核中实现了LeoCC，无需修改网络或应用程序
• 为了构建可复现的LEO网络环境并评估LeoCC，我们实现了一款精确的LEO网络录制与回放工具LeoReplayer。我们使用LeoReplayer录制了一个大规模的LEO网络数据集，其中包含超过4800条可准确反映真实LEO网络状况的轨迹（trace）
• 我们在真实LEO网络和我们实验室内的轨迹驱动测试平台上，对LeoCC及其他现有拥塞控制算法进行了广泛评估。大量结果表明，与其他现有算法相比，LeoCC能够推动帕累托前沿（Pareto frontier），在LEO网络中实现最佳的吞吐量-延迟平衡：其吞吐量比Cubic、Copa和BBRv3高85%～494%，延迟比BBRv1和VIVACE低44%～56%

我们已经开源了LeoCC的源代码、录制回放工具LeoReplayer以及我们的匿名化LEO网络轨迹数据。我们希望我们的工作能促进未来在新兴LEO网络领域的拥塞控制算法研究。本文不涉及任何伦理问题。

Background and Motivation

We begin by providing a brief background on LEO networks and highlighting the new challenges faced by existing Internet CCAs.

我们首先简要介绍低地球轨道（LEO）网络的背景，并着重指出当前互联网拥塞控制算法（CCA）所面临的新挑战。

2.1 Demystifying LEO Satellite Networks

Internet path with LEO satellite links. Figure 1 depicts an architecture commonly used by today’s operational LEO networks (e.g., Starlink and OneWeb). To access the Internet, a satellite user needs to purchase and deploy a dedicated satellite terminal which connects the user device (e.g., a laptop) to LEO satellites. Data packets from the user are forwarded to LEO satellites via the satellite terminal, then to a ground station (GS), to a Point-of-Presence (PoP) and finally to the terrestrial Internet (and vice versa). Note that the length of the satellite segment depends on the user location and space routing mechanism. If a user is close to an available GS, traffic between the user and the corresponding GS can be exchanged via the well-known “bent-pipe” routing (i.e., transparent forwarding). Otherwise, for users in remote areas far away from available GSes, an LEO network can leverage multi-hop inter-satellite links (ISLs) to route user traffic to the GS (and then to the Internet). In practice, as Elon Musk said [11], currently Starlink only uses ISLs if the satellite cannot see the user terminal and GS simultaneously.

包含低轨卫星链路的互联网路径: 图1展示了当今在轨运行的LEO网络（如Starlink和OneWeb）普遍采用的一种架构。为了接入互联网，卫星用户需要购买并部署一个专用的卫星终端，该终端将用户设备（如笔记本电脑）连接至LEO卫星。来自用户的数据包通过卫星终端被转发至LEO卫星，然后传输到地面站（GS），再到一个接入点（PoP），最终进入地面互联网（反之亦然）。值得注意的是，卫星链路段的长度取决于用户位置和空间路由机制。如果用户靠近一个可用的地面站，用户与相应地面站之间的流量可以通过众所周知的“弯管”（bent-pipe）路由（即透明转发）进行交换。反之，对于远离可用地面站的偏远地区用户，LEO网络可以利用多跳星间链路（ISL）将用户流量路由至地面站（再到互联网）。在实践中，正如埃隆·马斯克所说[11]，目前Starlink仅在卫星无法同时看到用户终端和地面站的情况下才使用星间链路。

The impact of LEO dynamics on network performance. Unlike traditional geostationary orbit (GEO) satellites (e.g., ViaSat [25]), LEO satellites operate at a lower orbital altitude (e.g., ≤2000km), reducing propagation delay but introducing network instability because LEO satellites move at a high velocity related to the earth surface (e.g., ∼7.8 km/s). Such LEO dynamics between satellites and users/GSes inevitably cause frequent satellite handovers, path changes between users and GSes, as well as radio frame rescheduling [39, 40], which can significantly affect the network performance.

低轨动态性对网络性能的影响: 与传统的地球静止轨道（GEO）卫星（如ViaSat [25]）不同，LEO卫星运行在更低的轨道高度（如≤2000公里），这降低了传播延迟，但也引入了网络不稳定性，因为LEO卫星相对于地球表面以极高速度移动（如约7.8公里/秒）。卫星与用户/地面站之间的这种低轨动态性不可避免地导致频繁的卫星切换、用户与地面站之间的路径变化以及无线帧的重新调度[39, 40]，这些都可能显著影响网络性能。

Figure 2 illustrates the drastic network variations observed from three Starlink terminals deployed in different locations around the world. For each terminal, we first use the traceroute [24] and GeoIP [15] tools to identify the location of its corresponding PoP, and open a cloud server near the PoP as another endpoint. To measure the maximum link capacity, we follow [53] and use iperf3 to saturate the satellite link by generating heavy UDP traffic between the terminal and the server. In addition, we generate light ICMP pings to measure the time-varying base RTT and packet loss rate. As shown in Figure 2, on all these terminals in the live Starlink network, we can observe that end-to-end connections through Starlink experience drastic network variations over time: (i) the maximum link capacity can drastically fluctuate between 10Mbps and 70Mbps in tens of seconds; (ii) RTTs and even the minimum RTTs can drastically change over time under the LEO dynamics. We also find that LEO links are susceptible to packet loss. The endpoints perceive random loss rates ranging from 0.5% to 6% within a 1-second window, even when the link is not fully utilized.

图2展示了从部署在全球不同位置的三个Starlink终端上观察到的剧烈网络变化。对于每个终端，我们首先使用traceroute [24]和GeoIP [15]工具来确定其相应PoP的位置，并在该PoP附近开设一个云服务器作为另一个端点。为测量最大链路容量，我们遵循[53]的方法，使用iperf3生成大量UDP流量来使卫星链路饱和。此外，我们生成轻量ICMP ping包来测量时变的基准RTT和丢包率。如图2所示，在所有这些真实Starlink网络中的终端上，我们都可以观察到，通过Starlink的端到端连接会经历随时间变化的剧烈网络波动：

(i) 最大链路容量可在数十秒内在10Mbps和70Mbps之间剧烈波动

(ii) 在低轨动态性影响下，RTT甚至最小RTT都可能随时间发生剧烈变化

我们还发现LEO链路易于发生丢包。即使在链路未被完全利用的情况下，端点也会在1秒的窗口内感知到0.5%到6%不等的随机丢包率

2.2 Existing CCAs Fail to Balance Delay and Throughput in LEO Networks

Ideally, congestion control algorithms (CCAs) are expected to work on an operating point where the network maximizes its throughput while minimizing delay. We run various well-known CCAs in the live Starlink and examine how existing CCAs balance the throughput and delay in LEO networks. Figure 3 shows the results from a Starlink terminal in Madrid to a cloud server in Barcelona. Because the real network conditions in live Starlink drastically change over time, we run more than fifty tests for each CCA and each test lasts for more than two minutes in the off-peak hours during Jan 2025 under clean sky conditions to obtain the statistic results. Specifically, we plot the 95%tile/average RTT and the average throughput achieved by each CCA. We also show the averaged base RTT (measured by light ping flows) and the averaged maximum link capacity (measured by heavy UDP flows saturating the link) which reflect the basic network characteristics, plotted as vertical and horizontal dashed lines in Figure 3. Based on our measurements, we observe that existing CCAs fail to effectively balance delay and throughput in real LEO networks: they either suffer from limited throughput and cannot fully utilize the link capacity (e.g., Cubic, Vegas, BBRv3 and Copa), or they overload the link and cause high queuing delay (e.g., BBRv1, Proteus and VIVACE).

理想情况下，拥塞控制算法（CCA）应工作在一个能使网络吞吐量最大化同时延迟最小化的工作点上。我们在真实的Starlink网络中运行了多种知名的CCA，并检验了现有CCA在LEO网络中如何平衡吞吐量与延迟。

图3展示了从位于马德里的一个Starlink终端到巴塞罗那的一个云服务器的测试结果。由于真实Starlink网络中的网络条件随时间剧烈变化，我们在2025年1月的晴朗天气下的非高峰时段，为每种CCA运行了超过五十次测试，每次测试持续两分钟以上，以获得统计结果。

具体来说，我们绘制了每种CCA实现的第95百分位的RTT、平均RTT以及平均吞吐量。我们还展示了平均基准RTT（通过轻量ping流量测量）和平均最大链路容量（通过饱和链路的大量UDP流量测量），它们反映了基础网络特性，并在图3中以垂直和水平虚线标出。

根据我们的测量，我们观察到现有CCA未能在真实LEO网络中有效平衡延迟与吞吐量：它们要么吞吐量受限，无法充分利用链路容量（如Cubic, Vegas, BBRv3和Copa），要么使链路过载并导致高排队延迟（如BBRv1, Proteus和VIVACE）。

2.3 Root Cause: Existing CCAs are Not Robust to LEO Network Variations

Our further investigation reveals the root causes as follows.

根本原因：现有拥塞控制算法对低轨网络变化不具备鲁棒性

tldr

1. 现有机制把丢包作为 congestion 信号. 但在LEO中并非如此，很大程度上pkt loss来自于 dynamic. 造成误判
2. 现有机制把 RTT等静态网络标识 作为 congestion 信号. 在LEO中肯定不行
3. 现有机制基于 learning 来调整 sending rate. 在LEO中, 由于高度动态性, learning 很难收敛

我们的进一步调查揭示了其根本原因如下。

Loss and delay increases can not accurately reflect congestion in LEO networks. Many existing CCAs assume that packet loss or delay increase is a direct result of network congestion. However, in real LEO networks like Starlink, endpoints frequently experience packet loss and increased delay caused by LEO dynamics (not by congestion), which undermines this assumption. Figure 4 (left) plots the time-varying performance achieved by Cubic and Copa on a replayed Starlink network trace (how we accurately record and replay Starlink traces will be described in §5.2). Because Cubic is unable to distinguish between congestion-induced and LEO-dynamicsinduced packet losses, it frequently and mistakenly considers the network is congested and shrinks the congestion window conservatively, causing self-limited throughput. Copa [29] is a recent delay-based CCA which converges its sending rate based on the queuing delay estimation 𝑑 𝑞 = 𝑠𝑡𝑎𝑛𝑑𝑖𝑛 𝑔 𝑅𝑇𝑇 − 𝑚𝑖𝑛𝑅𝑇𝑇, where 𝑠𝑡𝑎𝑛𝑑𝑖𝑛 𝑔 𝑅𝑇𝑇 and 𝑚𝑖𝑛𝑅𝑇𝑇 are the minimum RTT observed over a short and long period respectively. We find that as the RTT of LEO networks fluctuates frequently and drastically, Copa usually overestimates 𝑑 𝑞 (e.g., when 𝑠𝑡𝑎𝑛𝑑𝑖𝑛 𝑔 𝑅𝑇𝑇 suddenly increases due to LEO path change but 𝑚𝑖𝑛𝑅𝑇𝑇 still underestimates the actual delay), resulting in severe throughput degradation.

丢包和延迟增加无法准确反映低轨网络中的拥塞

许多现有CCA假设丢包或延迟增加是网络拥塞的直接结果。然而，在像Starlink这样的真实LEO网络中，端点频繁经历由低轨动态性（而非拥塞）引起的丢包和延迟增加，这破坏了这一基本假设。

图4（左）绘制了Cubic和Copa在一个重放的Starlink网络轨迹上的时变性能（我们如何精确记录和重放Starlink轨迹将在§5.2中描述）。由于Cubic无法区分拥塞引发的丢包和由低轨动态性引发的丢包，它会频繁地错误判断网络发生拥塞，并保守地收缩其拥塞窗口，导致自我限制的吞吐量。Copa [29]是近期一种基于延迟的CCA，它根据排队延迟估算值 dq​=standingRTT−minRTT 来收敛其发送速率，其中 standingRTT 和 minRTT 分别是在短时间和长时间内观测到的最小RTT。我们发现，由于LEO网络的RTT频繁且剧烈地波动，Copa通常会高估dq​（例如，当standingRTT因LEO路径变化而突然增加，但minRTT仍低估了实际延迟时），从而导致严重的吞吐量下降。

Precisely modeling time-varying LEO bottleneck is challenging. BBR [35] is a model-based CCA proposed by Google. The underlying principle of BBR is that it characterizes a network path by its bottleneck bandwidth (bBW) and propagation RTT (pRTT), and adjusts the sending rate accordingly. BBR operates under the assumption that the highest throughput and lowest RTT observed over a past period estimate bBW and pRTT. However, this assumption becomes inaccurate in LEO networks due to the rapidly changing link capacity and base RTT. Additionally, the latest version 3 of BBR [16] includes a new feature that reduces the sending rate in response to packet loss. Given the inaccurate network model in LEO networks, BBRv3 is not robust over satellite links with rapidly varying network conditions and random packet loss, failing to maintain high link utilization as illustrated in Figure 4 (middle).

精确建模时变的低轨瓶颈具有挑战性

BBR [35]是谷歌提出的一种基于模型的CCA。BBR的基本原理是通过其瓶颈带宽（bBW）和传播往返时间（pRTT）来表征网络路径，并据此调整发送速率。BBR的假设是，在过去一段时间内观察到的最高吞吐量和最低RTT可以分别估算出bBW和pRTT。

然而，在LEO网络中，由于链路容量和基准RTT的快速变化，这一假设变得不准确。

此外，BBR的最新版本3 [16]包含一个新特性，即在发生丢包时降低发送速率。鉴于在LEO网络中网络模型的不准确性，BBRv3在网络条件快速变化和存在随机丢包的卫星链路上不具备鲁棒性，未能像图4（中）所示那样保持高链路利用率。

Learning-based rate control struggles to converge under LEO dynamics. Recent works like VIVACE [37] and Proteus [59] adopt online learning to find the best mapping from the observed network conditions to certain sending rates that optimize a pre-defined utility. However, due to the LEO dynamics, the best mapping could rapidly change over time, and it is quite challenging for existing learning-based CCAs to converge the appropriate sending rate on time. Taking VIVACE as an example, Figure 4 (right) illustrates that under LEO network conditions, VIVACE: (i) under-utilizes the network when the link capacity drastically increases or when the base RTT suddenly increases; and (ii) overuses the link when the capacity drops abruptly, resulting in high queuing delay.

基于学习的速率控制在低轨动态下难以收敛

近期的工作如VIVACE [37]和Proteus [59]采用在线学习方法，以找到从观测到的网络状态到能够优化预定义效用的特定发送速率之间的最佳映射。

然而，由于低轨动态性，这个最佳映射可能随时间迅速改变，现有基于学习的CCA很难及时收敛到合适的发送速率。

以VIVACE为例，图4（右）说明了在LEO网络条件下，VIVACE：(i) 在链路容量急剧增加或基准RTT突然增加时，网络利用率不足；(ii) 在容量骤降时，过度使用链路，导致高排队延迟。

Collectively, our real-world measurements reveal that the massive network variations caused by LEO dynamics rather than congestion break the fundamental assumptions behind existing CCAs, preventing them from achieving the best balance between throughput and delay as they did in conventional terrestrial networks. This motivates us to explore a new CCA robust to LEO dynamics.

综上所述，我们在真实世界中的测量揭示了，由低轨动态性（而非拥塞）引起的大规模网络变化，打破了现有CCA背后的基本假设，使它们无法像在传统地面网络中那样，实现吞吐量与延迟之间的最佳平衡。这激励我们去探索一种对低轨动态性具有鲁棒性的新型CCA。

Key Idea Behind LeoCC

We present LeoCC, a novel CCA that is robust to LEO dynamics and can achieve the best balance between throughput and delay, outperforming other conventional CCAs under LEO network conditions. The key idea behind LeoCC is to exploit a unique feature in emerging LEO networks called “connection reconfiguration” to discriminate LEO-dynamics-induced performance changes and build an accurate LEO network model to characterize time-varying bottleneck link, based on which LeoCC precisely regulates the sending rate to fit the drastic network variations. Before delving into the design details, we introduce the key idea behind LeoCC.

我们提出LeoCC，一种对低轨（LEO）动态性具有鲁棒性的新型拥塞控制算法（CCA），它能够在低轨网络条件下实现吞吐量与延迟之间的最佳平衡，性能优于其他传统CCA。LeoCC的核心思想是利用新兴低轨网络中一个称为 “连接重构(重配置信息)” 的独特特性，来区分由低轨动态性引起的性能变化，并构建一个精确的低轨网络模型以刻画时变的瓶颈链路。基于该模型，LeoCC能够精确调节其发送速率以适应剧烈的网络变化。在深入探讨设计细节之前，我们首先介绍LeoCC的核心思想。

LEO connection reconfiguration. To deal with LEO dynamics, satellite operators typically employ a connection reconfiguration mechanism to schedule, manage, and update connections between satellites and ground entities (e.g., terminals and GSes). For example, according to the official document published by SpaceX [7], Starlink plans its LEO connections on 15-second intervals. This pattern has been confirmed by several recent measurements [46, 52, 61, 75] from different vantage points around the world. Similarly, other recent efforts reported that the reconfiguration interval in OneWeb is about 11 seconds [12, 32]. Note that periodic reconfiguration may trigger satellite-terminal handovers but is not equivalent to them. As revealed in [46], for a Starlink terminal, periodic reconfiguration does not necessarily result in a change of the connected satellite. In addition, LEO connection reconfiguration can also be aperiodic [52], e.g., Starlink may reconfigure the satellite-terminal connection and reallocate a new satellite to the terminal immediately, if the terminal suffers from poor signal strength or is obstructed.

LEO连接重构

为了应对低轨动态性，卫星运营商通常采用一种连接重构机制来调度、管理和更新卫星与地面实体（如终端和地面站）之间的连接。例如，根据SpaceX发布的官方文件[7]， Starlink以15秒为间隔规划其LEO连接 。这一模式已由近期来自全球不同观测点的多项测量[46, 52, 61, 75]所证实。类似地，其他近期的研究工作报道OneWeb中的重构间隔约为11秒[12, 32]。值得注意的是， 周期性重构可能触发卫星-终端切换，但并不等同于切换 。正如[46]所揭示的，对于一个Starlink终端，周期性重构不一定会导致所连接卫星的变更。此外，LEO连接重构也可以是非周期性的[52]，例如，当终端信号强度差或受到遮挡时，Starlink可能会立即重构卫星-终端连接并为终端重新分配一颗新卫星。

reconfiguration

1. 周期性重构: 可能触发 terminal-sat 切换 (不绝对, 但是概率很大)
   1. starlink: 15s
   2. oneweb: 11s
2. 非周期性重构:可能触发 terminal-sat 切换

Implicit correlation between reconfiguration and network variations. LEO reconfiguration has a strong correlation with network performance. On the one hand, it may update the radio frame allocation of satellites which further changes the physical layer transmission rate of satellite links [40]. On the other hand, reconfiguration can cause path changes, involving RTT fluctuation and packet loss, since it may update the satellite allocated to the terminal or the ground station behind the allocated satellite [46]. Figure 5 depicts a concrete example plotting the implicit correlation between reconfiguration and network variations measured on the Starlink vantage points introduced in §2.1 (the methods for detecting reconfiguration will be illustrated in §4.1). On the one hand, we observe that the time-varying link capacity and raw RTT can be approximately fitted as a “step function” divided by consecutive “reconfiguration intervals”. When entering a new interval, because a reconfiguration may change the network path and cause radio rescheduling, the available capacity and minimum RTT may suddenly “jump” to a new state independent with the previous interval. On the other hand, inside an interval, the capacity variations are relatively mild and smooth. The minimum RTT remains basically unchanged, but the raw RTT can fluctuate within a certain range, forming several “RTT bands”. This is likely because, although the network path does not change during the interval but the performance is still affected by “noises” in satellite channels, e.g., time-varying signal strength and radio frame reallocation 2 .

重构与网络变化之间的隐性关联

LEO连接重构与网络性能有很强的相关性。一方面，它可能会更新卫星的无线帧分配，进而改变卫星链路的物理层传输速率[40]。另一方面，重构可能导致路径变更，从而引发RTT波动和丢包，因为它可能会更新分配给终端的卫星或该卫星所连接的地面站[46]。

图5描绘了一个具体示例，展示了在我们于§2.1中介绍的Starlink观测点上测量到的重构与网络变化之间的隐性关联（检测重构的方法将在§4.1中说明）。我们观察到，时变的链路容量和原始RTT可以近似地拟合为一个由连续的“重构间隔”划分的“阶跃函数”:

当进入一个新的间隔时，由于重构可能改变网络路径并引起无线电重新调度，可用容量和最小RTT可能会突然“跳变”到一个与前一间隔无关的新状态。

另一方面，在单个间隔内部，容量变化相对平缓和顺滑。最小RTT基本保持不变，但原始RTT可在一定范围内波动，形成了几个 RTT区间（RTT bands）

这很可能是因为，尽管网络路径在间隔内没有改变，但性能仍然受到卫星信道中“噪声”的影响，例如时变的信号强度和无线帧的重新分配。

Reconfiguration-aware network model and rate control. Effective congestion control requires appropriate assumptions and models that can accurately reflect real network conditions [70]. A robust CCA for LEO networks should incorporate a network model capable of precisely characterizing the conditions of practical LEO environments. Building on the insights above, LeoCC uses reconfiguration as an indicator to filter out massive LEO-dynamicsinduced performance changes in LEO networks and introduces a novel reconfiguration-aware network model. This model enables more precise LEO network estimation and sending rate regulation under dynamic LEO conditions, rather than relying solely on traditional congestion signals such as packet loss, RTT, or one-way delay. Furthermore, LeoCC does not require modifications to intermediate network nodes to obtain explicit congestion information. Considering the difficulty of modifying satellite routers in current LEO networks, an end-to-end CCA offers better practicality.

重构感知的网络模型与速率控制

有效的拥塞控制需要能够准确反映真实网络条件的适当假设和模型[70]。一个适用于LEO网络的鲁棒CCA，应当包含一个能够精确刻画实际LEO环境状况的网络模型。基于以上洞察， LeoCC利用重构作为指示器，来滤除低轨网络中由低轨动态性引起的大量性能变化 ，并引入了一种新颖的重构感知的网络模型。

该模型能够 在动态的LEO条件下实现更精确的网络估计和发送速率调节，而不是仅仅依赖于丢包、RTT或单向延迟等传统拥塞信号 。此外，LeoCC无需修改中间网络节点来获取显式的拥塞信息。考虑到当前LEO网络中修改卫星路由器的困难，端到端的CCA具有更好的实用性。

Figure 6 plots LeoCC’s design overview, which combines three core building blocks. First, LeoCC’s reconfiguration-aware network model accurately detects the timing of every reconfiguration with millisecond precision. On each ACK, LeoCC judiciously combines the estimated delivery rate, RTT, and time since the last reconfiguration to filter out stale measurement samples and precisely track network changes. Second, LeoCC features a robust rate controller that employs a reconfiguration-aware state machine to dynamically adjust to consecutive reconfiguration intervals and fine-tune the sending rate, ensuring high throughput while limiting queuing delay during transmission. Finally, LeoCC adopts a network adapter to locate the bottleneck and deal with possible bottleneck shifts.

图6描绘了LeoCC的设计概览，它结合了三个核心构建模块。首先，LeoCC的重构感知网络模型能够以毫秒级精度准确检测每次重构的发生时间。对于每个ACK，LeoCC巧妙地结合了估计的交付速率、RTT以及自上次重构以来的时间，以滤除过时的测量样本，并精确跟踪网络变化。其次，LeoCC采用了一个鲁棒的速率控制器，该控制器使用一个重构感知的状态机来动态适应连续的重构间隔，并微调发送速率，从而在传输过程中确保高吞吐量并限制排队延迟。最后，LeoCC采用了一个网络适配器来定位瓶颈并处理可能的瓶颈转移。

LeoCC Core Design

In this section, we elaborate on the design details of LeoCC.

4.1 Reconfiguration-aware Network Model

4.1.1 Timely detection of reconfiguration events.

While the official SpaceX document [7] has confirmed the existence of LEO reconfiguration, the Starlink terminal does not provide any programmable interface for directly obtaining the concrete time when a reconfiguration exactly happens. The network community has several recent works that try to uncover when reconfiguration actually occurs in practice. On the one hand, it has been confirmed that Starlink's periodic reconfiguration occurs synchronously around the world at the 12th, 27th, and 57th seconds of every minute [46, 52, 61, 75]. This time periodicity also exists at our vantage points. On the other hand, for an aperiodic reconfiguration which triggers a satellite-handover, we can identify its occurrence by using the satellite-grpc-tools [23] to extract the obstruction maps from the satellite terminal, which are 2-dimensional images plotting the trajectory of satellites allocated to the terminal recently. The obstruction map is updated in seconds and we can identify whether an aperiodic reconfiguration occurs by comparing the trajectory of connected satellite in two sequential obstruction maps. This is how we plot the reconfiguration ground truth in Figure 5.

However, detecting reconfiguration events at second-level granularity is inadequate for precise congestion control, which necessitates fine-grained rate adaptation on the millisecond level. For example, when the grpc-based approach detects a reconfiguration, the actual reconfiguration has already occurred at least one second ago. Hence, LeoCC exploits a new method to detect reconfiguration on time, based on an important insight we obtained from real Starlink terminals at different locations: when a reconfiguration occurs, whether it is periodic or aperiodic, from an endpoint's view, a short network outage lasting for about 45~120ms can be observed at the network layer. The short outage caused by reconfiguration temporarily disrupts data transmission and delays ACK reception. Therefore, LeoCC detects reconfiguration on endpoints by monitoring outliers of the end-perceived response intervals (RIs).

RI-based reconfiguration detection. Recall the architecture plotted in Figure 1, packets from the satellite terminal are forwarded to a PoP behind GS via LEO links. The PoP has at least one accessible IP address for the user device, which can be identified by the traceroute tool and this address remains highly stable in practice. At runtime, LeoCC maintains a light probing flow from the user device behind satellite terminal to the closest accessible IP address of the PoP to continuously probe the RI between the terminal and the PoP. Concretely, LeoCC generates ICMP packets at a fixed interval of 10 ms to ping the PoP, and calculates RIs as the time difference between two consecutive ICMP responses. Figure 7 plots the RIs measured from different locations in the Starlink network, where the \(\times\) icons represent all observed response intervals on the endpoint and the vertical bands mark the time when the reconfiguration is detected in seconds (i.e., the ground truth). RI=0 indicates that some ICMP responses are received at the same time. Because of the short outage, ICMP pings may be lost or delayed during a reconfiguration, and LEO reconfiguration will cause RI outliers, which can be identified by a threshold \(\Delta outage\) (about 45ms in our vantage points, plotted as horizontal solid lines in Figure 7). Therefore, if \(\Delta R\) denote the latest RI observed on the endpoint. If \(\Delta R > \Delta outage\), then LeoCC considers a reconfiguration has occurred.

Why not use RTT spikes for detection? Note that a reconfiguration may also cause RTT spikes between the terminal and PoP. LeoCC uses RI instead of the RTT spikes to detect reconfiguration because we find that in a few cases, reconfiguration can cause all ICMP ping packets to be lost during the short outage (e.g., see Figure 26c in Appendix A). In such cases, the endpoint can not observe RTT spikes, but can still detect RI outliers.

Reducing probing overhead. A reconfiguration can affect all transport-layer connections on the same user device. To reduce the probing overhead, LeoCC maintains only a single probing flow between each user device and its corresponding PoP, rather than establishing a dedicated probing flow for every individual LeoCC connection. The reconfiguration detection results of this probing procedure are shared across all LeoCC flows running on the same user device. Note that the probing traffic generated by LeoCC is confined to the LEO access segment between the user device and the PoP, and does not traverse the full end-to-end path from the sender to the receiver. This design choice can effectively detect reconfigurations between the terminal and the PoP, without introducing high probing overhead to the user device and the Internet.

4.1.1 及时的重构事件检测

尽管SpaceX的官方文件[7]已证实LEO网络重构的存在，但Starlink终端并未提供任何可编程接口来直接获取重构发生的具体时间。网络研究界近期已有多项工作尝试揭示重构在实践中究竟何时发生。

一方面，研究证实Starlink的 周期性重构 在全球范围内同步发生于每分钟的第12、27和57秒[46, 52, 61, 75]。这种时间周期性在我们的观测点也同样存在。

另一方面，对于触发卫星切换的非周期性重构，我们可以通过使用satellite-grpc-tools[23]工具从卫星终端提取“遮挡图”（obstruction maps）来识别其发生。

遮挡图是绘制了近期分配给终端的卫星轨迹的二维图像。该图以秒为单位更新，通过比较两个连续遮挡图中连接卫星的轨迹，我们便可以确定是否发生了非周期性重构。这正是我们在图5中绘制重构基准事实（ground truth）的方法。

然而，秒级粒度的重构事件检测对于精确的拥塞控制而言是不够的，因为它需要毫秒级的细粒度速率自适应。例如，当基于gRPC的方法检测到一次重构时，实际的重构事件至少已在1秒前发生。

因此，LeoCC利用一种新方法来及时检测重构，该方法基于我们从不同地点的真实Starlink终端获得的一个重要洞察：当重构发生时（无论是周期性的还是非周期性的），从端点的角度看，网络层上可以观察到一次持续约 45~120毫秒的短暂网络中断。由重构引起的短暂中断会临时打断数据传输并延迟ACK的接收。因此，LeoCC通过监测端点感知的 响应间隔（Response Intervals, RIs） 的异常值来检测重构。

TODO

为什么是 一次持续约 45~120ms 的短暂网络中断

基于RI的重构检测。 回顾图1所示的架构，来自卫星终端的数据包经由LEO链路转发至地面站（GS）后的接入点（PoP）。PoP至少有一个用户设备可访问的IP地址，该地址可通过traceroute工具识别，并在实践中保持高度稳定。在运行时，LeoCC在卫星终端后的用户设备与最近的可访问PoP IP地址之间维持一个轻量的探测流，以持续探测终端与PoP之间的RI。具体来说，LeoCC以10毫秒的固定间隔生成ICMP包来ping PoP，并 将两次连续ICMP响应之间的时间差计算为RI。

图7绘制了从Starlink网络中不同位置测得的RI，其中 \(\times\) 图标代表端点上所有观察到的响应间隔，垂直带则标记了以秒为单位检测到重构的时间（即基准事实）。RI=0表示某些ICMP响应是同时收到的。由于短暂中断，ICMP ping包在重构期间可能会丢失或延迟，LEO重构将导致RI出现异常值，这可以通过一个阈值 \(\Delta outage\) （在我们的观测点约为45毫秒，如图7中水平实线所示）来识别。因此，若用 \(\Delta R\) 表示端点上观察到的最新RI，当 \(\Delta R > \Delta outage\) 时，LeoCC则认为发生了一次重构。

为何不使用RTT尖峰进行检测？ 需要注意的是，重构也可能导致终端和PoP之间的RTT出现尖峰。LeoCC使用RI而非RTT尖峰来检测重构，是因为我们发现在少数情况下，重构可能导致所有ICMP ping包在短暂中断期间丢失（例如，参见附录A中的图26c）。在这种情况下，端点无法观察到RTT尖峰，但仍然可以检测到RI的异常值。

重要: 对比 RI 和 RTT

"无法观察到RTT尖峰" 很好理解, 因为携带信息的icmp返回包直接loss了

但是为什么 "仍然可以检测到RI的异常值"?

对比RTT和RI的定义:

1. RTT (往返时间): 计算的是 “单个请求” 到 “其对应响应” 的时间差

   • 公式: \(RTT_n = ReplyTime_n - RequestTime_n\)
   • 如果第n个包的Reply丢失了, \(RTT_n\) 这个值就不存在

2. RI (响应间隔): 计算的是 “上一个成功响应” 到 “下一个成功响应” 的时间差

   • 公式: \(RI = CurrentReplyTime - PreviousReplyTime\)
   • 这个计算不关心中间有多少个请求失败了。它只关心成功返回的包之间隔了多久

这里给两个例子，直观体现一下RI比RTT的优越性 (假设系统每10ms发送一个ICMP ping包，正常的RTT是30ms):

场景一：网络正常

T=0ms:  发送Ping 1
T=10ms: 发送Ping 2
T=20ms: 发送Ping 3
T=30ms: 收到Ping 1的响应 (PreviousReplyTime = 30ms)
T=40ms: 收到Ping 2的响应 (CurrentReplyTime = 40ms)
    计算RI: 40ms - 30ms = 10ms。这个值是正常的
T=50ms: 收到Ping 3的响应 (CurrentReplyTime = 50ms)
    计算RI: 50ms - 40ms = 10ms。这个值也是正常的

正常情况下，RI的值约等于ping的发送间隔（10ms）

场景二：发生120ms的网络中断，所有包的响应都丢失

T=0ms: 发送Ping 1
T=10ms: 发送Ping 2

...

T=30ms: 收到Ping 1的响应。这是中断前最后一个成功的响应 (PreviousReplyTime = 30ms)
T=40ms: 没有收到Ping 2的响应 (丢失)
T=50ms: 没有收到Ping 3的响应 (丢失)

... (中间发送的Ping 4到Ping 13的响应全部丢失) ...

T=140ms: 发送Ping 15 (此时网络已恢复)
T=170ms: 收到Ping 15的响应。这是中断后第一个成功的响应 (CurrentReplyTime = 170ms)

------
计算RI: 170ms - 30ms = 140ms
这个140ms的RI值远大于正常的10ms，因此它是一个巨大的异常值。这个异常值直接反映了网络中断的持续时间

(1) RTT尖峰的“盲点”：RTT依赖于每一次ping的成功返回

当返回包持续丢失时，RTT数据流会中断，系统“什么也看不到”，因此无法形成“尖峰”

(2) RI异常值的“优势”：RI衡量的是成功事件之间的时间间隔

正是因为中间有大量的包丢失了，才导致了两个成功响应之间的时间间隔被急剧拉长，从而产生了一个可以被轻松检测到的巨大异常值

减少探测开销。 一次重构会影响同一用户设备上的所有传输层连接。为了减少探测开销，LeoCC在每个用户设备与其对应的PoP之间只维持一个探测流，而不是为每个独立的LeoCC连接建立专用的探测流。该探测过程的重构检测结果由运行在同一用户设备上的所有LeoCC流共享。值得注意的是，LeoCC生成的探测流量仅限于用户设备和PoP之间的LEO接入段，并不会遍历从发送方到接收方的完整端到端路径。这种设计选择可以有效地检测终端与PoP之间的重构，而不会给用户设备和互联网带来高昂的探测开销。

TODO

"为了减少探测开销，LeoCC在每个用户设备与其对应的PoP之间只维持一个探测流，而不是为每个独立的LeoCC连接建立专用的探测流"

一个用户会发送很多条LEOCC流, 应该咋安排“probe flow”呢?

4.1.2 Dynamic network model.

From an endpoint's perspective, an arbitrarily complex network path can be logically modeled as a single link with the same bottleneck bandwidth (\(bBW\)) and base RTT (\(bRTT\)). Since \(bBW\) and \(bRTT\) are crucial for congestion control, existing CCAs typically estimate them based on measurement from a historical time window. For instance, BBR estimates \(bBW\) by using the maximum delivery rate observed over a recent time window [35], while Copa estimates \(bRTT\) as the minimum RTT measured within a recent observation window [29]. These estimations are generally accurate in terrestrial networks, where end-to-end paths remain relatively stable. However, LEO dynamics presents a different challenge. In a network path with dynamic LEO links, where both \(bBW\) and \(bRTT\) change rapidly, relying on stale measurements over a time window to estimate current network conditions may result in inaccurate predictions and rate control.

LeoCC adopts a new reconfiguration-aware dynamic network model to characterize LEO network conditions more accurately. When estimating \(bBW\) and \(bRTT\), LeoCC discards measurements prior to the latest reconfiguration to prevent misleading network estimations. In particular, LeoCC considers a path with dynamic LEO satellite links as a sequence of discrete base network conditions \(\{(bBW^R, bRTT^R), (bBW^{R+1}, bRTT^{R+1}), ...\}\), where \((bBW^R, bRTT^R)\) is the bottleneck bandwidth and base RTT after reconfiguration R. In other words, a reconfiguration \(R\) changes the network condition from \((bRTT^{R-1}, bBW^{R-1})\) to \((bRTT^R, bBW^R)\), and LeoCC models a dynamic network path in the moment \(T\) by:

\(bBW(T) = bBW^R + noise_{BW}(T),\) \(bRTT(T) = bRTT^R + noise_{RTT}(T),\) (1)

where \(R\) is the latest reconfiguration before \(T\), \(noise_{RTT}(T)\) and \(noise_{BW}(T)\) indicate RTT/bandwidth noises in LEO links. Figure 8 plots an intuitive example illustrating how the reconfiguration-aware model characterizes a dynamic LEO network path in practice. As LEO satellites move, physically, packets are forwarded by different satellite paths over time. Logically, from an end-to-end view such path changes can be considered as that the bottleneck bandwidth and base RTT of the path suddenly switches to a new discrete condition, driven by LEO reconfigurations.

4.1.2 动态网络模型

从端点的角度来看，一个任意复杂的网络路径可以在逻辑上被建模为具有相同 瓶颈带宽（\(bBW\)） 和 基础RTT（\(bRTT\)） 的单一链路。由于 \(bBW\) 和 \(bRTT\) 对拥塞控制至关重要，现有的CCA通常基于历史时间窗口的测量来估计它们。例如，BBR通过使用近期时间窗口内观察到的最大交付速率来估计 \(bBW\) [35]，而Copa则将在近期观测窗口内测得的最小RTT作为 \(bRTT\) 的估计值[29]。这些估计在端到端路径相对稳定的地面网络中通常是准确的。然而，LEO的动态性带来了不同的挑战。在一个具有动态LEO链路的网络路径中，\(bBW\) 和 \(bRTT\) 都会快速变化，依赖于一个时间窗口内的陈旧测量数据来估计当前网络状况可能会导致不准确的预测和速率控制。

LeoCC采用一种新的 重构感知的动态网络模型 来更准确地刻画LEO网络状况。在估计 \(bBW\) 和 \(bRTT\) 时，LeoCC会丢弃最近一次重构之前的测量数据，以防止误导性的网络估计。具体而言，LeoCC将具有动态LEO卫星链路的路径视为一系列 离散的基础网络状况序列 \(\{(bBW^R, bRTT^R), (bBW^{R+1}, bRTT^{R+1}), ...\}\)，其中 \((bBW^R, bRTT^R)\) 是重构R发生后的瓶颈带宽和基础RTT。换言之，一次重构 \(R\) 将网络状况从 \((bRTT^{R-1}, bBW^{R-1})\) 变为 \((bRTT^R, bBW^R)\)，LeoCC通过以下公式在时刻 \(T\) 对动态网络路径进行建模：

\(bBW(T) = bBW^R + noise_{BW}(T),\)

\(bRTT(T) = bRTT^R + noise_{RTT}(T),\) (1)

其中 \(R\) 是 \(T\) 时刻之前最近的一次重构，\(noise_{RTT}(T)\) 和 \(noise_{BW}(T)\) 表示LEO链路中的RTT/带宽噪声。图8绘制了一个直观的例子，说明了重构感知模型如何在实践中刻画动态的LEO网络路径。随着LEO卫星的移动，物理上，数据包会随时间通过不同的卫星路径转发。逻辑上，从端到端的视角来看，这种路径变化可以被视为路径的瓶颈带宽和基础RTT在LEO重构的驱动下突然切换到一个新的离散状态。

4.2 Robust Rate Controller

LeoCC's rate controller adopts two new probing states to: (i) probe and estimate current network conditions; and (ii) accordingly calculate the target and regulate the sending rates. Figure 9 plots the probing state and state transition of LeoCC. Concretely, when a new LeoCC flow is created, like other existing CCAs, LeoCC quickly approaches the sending rate via a startup state. When LeoCC has approached the maximum link capacity, it transitions to a Dynamic Cruise state, where it adaptively adjusts the sending rate within the current reconfiguration interval. Upon detecting a reconfiguration event, LeoCC transitions into the Reconfiguration Adaptation state to rapidly converge to an appropriate sending rate for the new network conditions. After the Reconfiguration Adaptation state, LeoCC returns back to the Dynamic Cruise state.

LeoCC的速率控制器采用两种新的探测状态来：

(i) 探测和估计当前网络状况

(ii) 并据此计算目标速率并调节发送速率

图9绘制了LeoCC的探测状态和状态转移。具体来说:

1. 当一个新的LeoCC流被创建时，与其他现有拥塞控制算法（CCA）类似，LeoCC通过一个 启动（startup）状态 快速接近发送速率

2. 当LeoCC已接近最大链路容量时，它会转换到 动态巡航（Dynamic Cruise）状态，在此状态下，它在当前重构间隔内自适应地调整发送速率

3. 一旦检测到重构事件，LeoCC会转换到 重构适应（Reconfiguration Adaptation）状态，以快速收敛到适应新网络条件的发送速率
4. 在重构适应状态之后，LeoCC返回到 动态巡航状态

4.2.1 Dynamic cruise.

In this state, LeoCC dynamically adjusts to the network conditions between two consecutive reconfigurations. Although no path changes occur during a reconfiguration interval, bRTT and bBW may exhibit significant noise. LeoCC estimates the time-varying bottleneck bandwidth (\(bBW(T)\)) and base RTT (\(bRTT(T)\)), and then regulates the sending rate as follows.

\(bBW(T)\) estimation. At any moment \(T\) during the Dynamic Cruise state, LeoCC involves two parallel \(bBW\) estimators:

\(bBW_a(T) = \text{Max}(dRate_t), bBW_m(T) = \text{Kal}(dRate_t),\)

\(\forall t \in [\max(T - W_{BW}, t^{last}_{Rcf}), T],\) (2)

where \(bBW_a(T)\) is an aggressive estimator and \(bBW_m(T)\) is a moderate estimator. \(W_{BW}\) is a time window and \(t^{last}_{Rcf}\) is the moment when the latest reconfiguration was detected. \(dRate_t\) is the delivery rate estimated by TCP [18] at \(t\). To filter out the noises in \(dRate_t\) samples, \(bBW_a(T)\) aggressively uses a max filter (\(\text{Max}(\cdot)\)), whereas \(bBW_m(T)\) uses a Kalman filter (\(\text{Kal}(\cdot)\)) [49] which is more sensitive to bandwidth variations. Concretely, LeoCC uses all \(dRate_t\) samples over \(W_{BW}\) to estimate bBW if no reconfiguration occurs during \(W_{BW}\) (i.e., \(t^{last}_{Rcf} \le T - W_{BW}\)). Otherwise, if the latest reconfiguration was detected during \(W_{BW}\), the estimator selectively discards expired \(dRate_t\) samples in the previous reconfiguration interval and only uses samples after \(t^{last}_{Rcf}\) for bBW estimation.

\(brTT(T)\) estimation. In LEO networks, even when the path remains unchanged, RTTs can exhibit significant jitter, and the base RTTs perceived by the endpoints may form multiple "RTT bands" as shown in Figure 5b. Therefore, LEOCC maintains a bRTT range rather than just a single value like min RTT. The lower and upper bounds of this range, denoted as \(bRTT_l\) and \(bRTT_h\) respectively, are estimated as follows:

\(bRTT_h(T) = \max(\text{MPF}(RTT_t)),\)

\(bRTT_l(T) = \min(\text{MPF}(RTT_t)), \forall t \in [\max(T-W_{RT}, t^{last}_{Rcf}), T],\) (3)

where \(W_{RT}\) is a time window and \(t^{last}_{Rcf}\) is the moment when the latest reconfiguration was detected. MPF is a middle-pass filter used to remove RTT noises, based on the observation in Figure 5b that when the LEO link is underutilized, most raw RTT samples are concentrated in some discrete RTT bands, and the maximum and minimum values of these bands determine the jitter range of bRTT. MPF runs over a time window since the last reconfiguration. In addition to the RTT range, LEOCC estimates the latest RTT as \(bRTT_{latest}(T)\) using a Kalman filter over the time window, i.e., \(bRTT_{latest}(T) = \text{Kal}(RTT_t), \forall t \in [\max(T-W_{RT}, t^{last}_{Rcf}), T]\).

Target rate calculation. Based on the above estimations, LEOCC calculates the target rate at T as:

\(rate_{target} = \begin{cases} bBW_m, & \text{if } bRTT_{latest} \ge bRTT_h + \Delta_{RTT}, \\ bBW_a, & \text{otherwise}. \end{cases}\) (4)

The underlying logic of LEOCC's rate control can be summarized as follows. Due to the LEO dynamics, the base RTT inevitably fluctuates in a certain range during a reconfiguration interval, and the minimum RTT keeps stable. If \(bRTT_{latest}\) oscillates in the range of \([bRTT_l, bRTT_h]\), LEOCC runs in an aggressive mode to make full use of the current link capacity. If \(bRTT_{latest}\) exceeds the upper limit of the oscillation range (e.g., much higher than \(bRTT_h\)), LEOCC considers that congestion has occurred in the network and switches to a moderate mode to avoid high queuing delays. Concretely, if LEOCC observes that the \(bRTT_{latest}\) has left the range of \([bRTT_l, bRTT_h]\) and is higher than \(bBW_h\) by a threshold \(\Delta_{RTT}\), then LEOCC considers that the current network is likely to be congested and a more moderate bandwidth estimate \(bBW_m\) should be used as the current target rate. Otherwise, LEOCC uses \(bBW_a\) as the current target rate to achieve high link utilization.

Sending rate decision. Based on the target rate calculation, LEOCC then decides the concrete sending rate. To fit the time-varying link capacity, LEOCC periodically generates bursts and drains them to adapt to network variations. Inspired by BBR's burst generation, LEOCC incorporates a burst coefficient (\(bco\)), a drain coefficient (\(dco\)), and a cycle length (\(cycle_{len}\)), with each cycle spanning several RTTs. During the first and second RTT of each cycle, LEOCC sets the sending rate to \(bco \times rate_{target}\) and \(dco \times rate_{target}\), respectively. In the remaining RTTs of the cycle, the sending rate is set to \(rate_{target}\). Currently, if \(bRTT_{latest} \le bRTT_h + \Delta_{RTT}\), LEOCC sets \(bco\) and \(dco\) to 1.25 and 0.75. Otherwise, LEOCC slightly decreases \(bco\) to create smaller bursts in case of potential network congestion.

4.2.1 动态巡航

在此状态下，LeoCC动态地适应两次连续重构之间的网络状况。尽管在重构间隔内没有路径变化，但基础往返时间（bRTT）和瓶颈带宽（bBW）可能会表现出显著的噪声。LeoCC估计时变的瓶颈带宽（\(bBW(T)\)）和基础RTT（\(bRTT(T)\)），然后按如下方式调节发送速率。

\(bBW(T)\) 估计

在动态巡航状态的任意时刻 \(T\)，LeoCC涉及两个并行的 \(bBW\) 估计器：

\(bBW_a(T) = \text{Max}(dRate_t), bBW_m(T) = \text{Kal}(dRate_t),\) \(\forall t \in [\max(T - W_{BW}, t^{last}_{Rcf}), T],\) (2)

其中 \(bBW_a(T)\) 是一个激进估计器，\(bBW_m(T)\) 是一个平缓估计器。\(W_{BW}\) 是一个时间窗口，\(t^{last}_{Rcf}\) 是最近一次重构被检测到的时刻。\(dRate_t\) 是在时刻 \(t\) 由TCP [18]估计的交付速率。为了滤除 \(dRate_t\) 样本中的噪声，\(bBW_a(T)\) 激进地使用最大值滤波器（\(\text{Max}(\cdot)\)），而 \(bBW_m(T)\) 使用对带宽变化更敏感的卡尔曼滤波器（\(\text{Kal}(\cdot)\)）[49]。

具体来说，如果在 \(W_{BW}\) 期间没有发生重构（即 \(t^{last}_{Rcf} \le T - W_{BW}\)），LeoCC使用 \(W_{BW}\) 内的所有 \(dRate_t\) 样本来估计bBW。否则，如果在 \(W_{BW}\) 期间检测到最近一次重构，估计器会选择性地丢弃前一个重构间隔内过期的 \(dRate_t\) 样本，并仅使用 \(t^{last}_{Rcf}\) 之后的样本进行bBW估计。

\(brTT(T)\) 估计

在低地球轨道（LEO）网络中，即使路径保持不变，RTT也可能表现出显著的抖动，端点感知到的基础RTT可能会形成多个“RTT区间”（RTT bands），如图5b所示。因此，LeoCC维持一个bRTT范围，而不是像最小RTT那样的单个值。该范围的下界和上界分别表示为 \(bRTT_l\) 和 \(bRTT_h\)，估计如下：

\(bRTT_h(T) = \max(\text{MPF}(RTT_t)),\) \(bRTT_l(T) = \min(\text{MPF}(RTT_t)), \forall t \in [\max(T-W_{RT}, t^{last}_{Rcf}), T],\) (3)

其中 \(W_{RT}\) 是一个时间窗口，\(t^{last}_{Rcf}\) 是最近一次重构被检测到的时刻。MPF是一个中通滤波器，用于去除RTT噪声，其依据是图5b中的观察：当LEO链路未被充分利用时，大多数原始RTT样本集中在一些离散的RTT区间内，这些区间的最大值和最小值决定了bRTT的抖动范围。MPF在一个自上次重构以来的时间窗口上运行。除了RTT范围，LeoCC还使用卡尔曼滤波器在一个时间窗口上估计最新的RTT，即 \(bRTT_{latest}(T) = \text{Kal}(RTT_t), \forall t \in [\max(T-W_{RT}, t^{last}_{Rcf}), T]\)。

目标速率计算

基于上述估计，LeoCC在时刻T计算目标速率如下：

\(rate_{target} = \begin{cases} bBW_m, & \text{若 } bRTT_{latest} \ge bRTT_h + \Delta_{RTT}, \\ bBW_a, & \text{其他情况}. \end{cases}\) (4)

LeoCC速率控制的内在逻辑可概括如下 📝:

由于LEO的动态性，基础RTT在一个重构间隔内不可避免地在一定范围内波动，而最小RTT保持稳定。

如果 \(bRTT_{latest}\) 在 \([bRTT_l, bRTT_h]\) 范围内振荡，LeoCC将以激进模式运行，以充分利用当前链路容量。

如果 \(bRTT_{latest}\) 超出振荡范围的上限（例如，远高于 \(bRTT_h\)），LeoCC认为网络中已发生拥塞，并切换到平缓模式以避免高排队延迟。

具体来说，如果LeoCC观察到 \(bRTT_{latest}\) 已离开 \([bRTT_l, bRTT_h]\) 范围，并且比 \(bRTT_h\) 高出一个阈值 \(\Delta_{RTT}\)，那么LeoCC认为当前网络很可能发生拥塞，应使用更平缓的带宽估计 \(bBW_m\) 作为当前目标速率。否则，LeoCC使用 \(bBW_a\) 作为当前目标速率以实现高链路利用率。

发送速率决策

基于目标速率的计算，LeoCC决定具体的发送速率。为了适应时变的链路容量，LeoCC周期性地生成突发流量并将其排出，以适应网络变化。受BBR突发生成的启发，LeoCC引入了突发系数（\(bco\)）、引流系数（\(dco\)）和周期长度（\(cycle_{len}\)），每个周期跨越数个RTT。在每个周期的第一和第二个RTT期间，LeoCC分别将发送速率设置为 \(bco \times rate_{target}\) 和 \(dco \times rate_{target}\)。在周期的剩余RTT中，发送速率设置为 \(rate_{target}\)。当前，如果 \(bRTT_{latest} \le bRTT_h + \Delta_{RTT}\)，LeoCC将 \(bco\) 和 \(dco\) 设置为1.25和0.75。否则，LeoCC会略微降低 \(bco\) 以在潜在的网络拥塞情况下创建较小的突发。

4.2.2 Reconfiguration adaptation.

Once a reconfiguration is detected, the available bottleneck link capacity may change abruptly and it is expected that LeoCC can promptly and accurately adapt its sending rate to the new bottleneck bandwidth. Since the new bottleneck bandwidth is difficult to predict, a straightforward approach would be to reset the congestion control back to slow start. However, this can lead to underutilization of bandwidth after reconfiguration. Instead, LeoCC adopts a more smooth rate adjustment mechanism as follows. LeoCC transits to the Reconfiguration Adaptation state, during which two operations are performed to reset the current operating point. First, LeoCC limits inflight packets to \(0.5 \times bBW_m \times bRTT_l\) to drain as many packets as possible that are accumulated in the network and saves the current \(rate^*_{target}\). Second, based on the RTT samples collected during this period, LeoCC updates \(bRTT_h\) and \(bRTT_l\) immediately. Then LeoCC sets the current \(bBW_a = bBW_m = rate^*_{target}\) and transits to the Dynamic Cruise state after probing the new bandwidth.

4.2.2 重构适应

一旦检测到重构，可用的瓶颈链路容量可能会突然改变，我们期望LeoCC能够迅速而准确地使其发送速率适应新的瓶颈带宽。由于新的瓶颈带宽难以预测，一种直接的方法是将拥塞控制重置回慢启动。然而，这可能导致重构后的带宽利用不足。因此，LeoCC采用了一种更平滑的速率调整机制。LeoCC转换到重构适应状态，在此期间执行两个操作来重置当前工作点。

首先，LeoCC将在途（inflight）数据包限制在 \(0.5 \times bBW_m \times bRTT_l\) 以尽可能地排空网络中累积的数据包，并保存当前的 \(rate^*_{target}\)。

其次，基于此期间收集的RTT样本，LeoCC立即更新 \(bRTT_h\) 和 \(bRTT_l\)。然后，LeoCC将当前的 \(bBW_a = bBW_m = rate^*_{target}\)，并在探测到新带宽后转换到动态巡航状态。

4.3 Dealing with Bottleneck Shifting

As LEO link capacity rapidly changes, the bottleneck of a network path containing LEO links may dynamically shift between a satellite and a non-satellite link in practice. LeoCC incorporates an adaptation mechanism to detect whether the current bottleneck is in the LEO satellite segment or not, and deal with bottleneck shifting.

随着LEO链路容量的快速变化，包含LEO链路的网络路径的瓶颈在实践中可能会在卫星链路和非卫星链路之间动态转移。LeoCC集成了一个自适应机制来检测当前瓶颈是否在LEO卫星段，并处理瓶颈转移问题。

Bottleneck discrimination. Inspired by existing bottleneck identification techniques [36], LeoCC uses a delay-based method to probe the RTT of different segments of the entire network path and estimate the location of the current bottleneck. Recall the LEO network architecture in Figure 1, the delay of the non-satellite terrestrial segment can be approximately estimated by \(RTT_{non-sat} = RTT_{e2e} - RTT_{term-PoP}\), where \(RTT_{term-PoP}\) refers to the RTT between the terminal and PoP, and \(RTT_{e2e}\) refers to end-to-end RTT. In practice, \(RTT_{e2e}\) can be estimated by \(bRTT_{latest}\) introduced in §4.2.1 while \(RTT_{term-PoP}\) can be measured by the ICMP probe described in §4.1.1. If a \(RTT_{non-sat}\) spike is observed, LeoCC considers that the current bottleneck is located in the terrestrial segment.

瓶颈判别

受现有瓶颈识别技术[36]的启发，LeoCC使用一种基于延迟的方法来探测整个网络路径不同段的往返时间（RTT），并估计当前瓶颈的位置。回顾图1中的低地球轨道（LEO）网络架构，非卫星的地面段延迟可以通过公式 \(RTT_{non-sat} = RTT_{e2e} - RTT_{term-PoP}\) 近似估算。其中，\(RTT_{term-PoP}\) 指的是终端与接入点（PoP）之间的RTT，\(RTT_{e2e}\) 指的是端到端RTT。在实践中，\(RTT_{e2e}\) 可由§4.2.1中介绍的 \(bRTT_{latest}\) 估计，而 \(RTT_{term-PoP}\) 可通过§4.1.1中描述的ICMP探测来测量。如果观察到 \(RTT_{non-sat}\) 出现尖峰，LeoCC则认为当前瓶颈位于地面段。

Bottleneck adaptation. When a non-satellite link is the bottleneck, due to the existence of reconfiguration-induced short outage, the network conditions can still be formulated as a sequence of reconfiguration-driven state changes, but the bandwidth of the network path in the new state does not change. Hence, when the bandwidth is not limited by an LEO link, LeoCC skips the Reconfiguration Adaptation stage to fully utilize the link.

瓶颈适应

当瓶颈为非卫星链路时，由于存在由重构引发的短暂中断，网络状况仍可被表述为一系列由重构驱动的状态变化，但新状态下网络路径的带宽不会改变。因此，当带宽不受LEO链路限制时，LeoCC会跳过 重构适应（Reconfiguration Adaptation） 阶段以充分利用链路。

LeoCC Implementation

5.1 Linux Kernel Implementation

We implement LeoCC in Linux as a kernel module using the pluggable TCP APIs. LeoCC can be easily integrated and deployed into Linux-based networked systems by loading it as a kernel module. LeoCC can also be extended to work with other emerging transport layer protocols such as QUIC. We empirically configure the key parameters in LeoCC, as these settings consistently yield robust performance across both real-world experiments and trace-driven simulations. In particular, the RI threshold used to detect reconfiguration is set to \(\\Delta\_{outage}\) = 45ms based on our empirical results across different vantage points in the real Starlink network environment. The concrete setting of other parameters of LeoCC, including \(W\_{BW}\), \(W\_{RT}\), \(bRTT\_l\) and \(\\Delta\_{RTT}\) etc., can be found in our open code repository: https://github.com/SpaceNetLab/LeoCC .

我们在 Linux 中使用可插拔的 TCP API 将 LeoCC 实现为一个内核模块。通过加载该内核模块，LeoCC 可以轻松地集成并部署到基于 Linux 的网络系统中。LeoCC 也可以扩展以支持其他新兴的传输层协议，例如 QUIC。我们根据经验配置了 LeoCC 中的关键参数，因为这些设置在真实世界的实验和基于轨迹的仿真中都能持续产生鲁棒的性能。特别地，基于我们在真实 Starlink 网络环境中不同观测点的经验结果，用于检测重构的响应间隔（RI）阈值被设置为 \(\Delta_{outage}\) = 45ms。LeoCC 的其他参数的具体设置，包括 \(W_{BW}\)、\(W_{RT}\)、\(bRTT_l\) 和 \(\Delta_{RTT}\) 等，可以在我们的开源代码库中找到：https://github.com/SpaceNetLab/LeoCC。

Note that reconfiguration events are probed by user devices behind the satellite terminal. If the probing device is a LeoCC sender, the reconfiguration information is directly fed into the rate control. If the probing device is a LeoCC receiver (e.g., application data goes from a normal server to a satellite user), LeoCC uses eBPF [14] to embed the reconfiguration information into the Options field [1] of TCP ACK headers, which are then transmitted back to the sender and incorporated into its rate control decisions.

值得注意的是，重构事件是由卫星终端后的用户设备探测的:

1. 如果探测设备是 LeoCC 的发送方，重构信息会直接送入速率控制器
2. 如果探测设备是 LeoCC 的接收方（例如，应用数据从普通服务器流向卫星用户），LeoCC 会使用 eBPF [14] 将重构信息嵌入到 TCP ACK 头部的选项字段 [1] 中，然后传回给发送方，并融入其速率控制决策中

eBPF

eBPF 的全称是 Extended Berkeley Packet Filter

一个最流行且贴切的比喻是：eBPF 之于 Linux 内核，就像 JavaScript 之于 Web 浏览器。

• JavaScript 允许你在浏览器中运行自定义的、经过安全沙箱隔离的小程序，来动态地、可编程地改变网页的行为，而无需修改浏览器的源代码
• eBPF 允许你在 Linux 内核中运行自定义的、经过安全沙箱隔离的小程序，来动态地、可编程地改变内核的行为，而无需修改内核源代码或加载有风险的内核模块

TL; DR: eBPF 是一种可以 在操作系统内核中安全、高效地执行自定义代码的技术

5.2 LEOPLAYER: A Record-and-Replay Tool

The live Starlink network is a real but uncontrollable environment with unpredictable, time-varying network performance. To comprehensively evaluate LeoCC, in addition to the blackbox Starlink, we still need a controlled white-box experiment environment for in-depth performance evaluation and analysis. However, previous experimentation tools such as LEO network emulators (e.g., LeoEM [34] and StarryNet [51]) are unable to precisely record and reproduce real packet-level behaviors. Mahimahi [62] is a record-and-replay tool originally designed for HTTP, and is widely used by the academia for general network traffic. Unfortunately, Mahimahi mainly focuses on recording and replaying the time-varying network capacity, but fully reproducing LEO network conditions requires to simultaneously record and replay all the maximum capacity, base RTT, and base loss rate of the path. This is quite challenging for existing recorders like Mahimahi since the maximum capacity and base RTT/loss rate are hard to be simultaneously measured in practice: to measure the maximum capacity, the recorder needs to saturate the link (create congestion), while to obtain the base RTT it has to under-utilize the link simultaneously (avoid congestion).

Hence, we implement a record-and-replay tool called LEOREPLAYER to accurately reproduce highly-dynamic LEO network conditions. Specifically, LEOREPLAYER leverages an important insight that currently Starlink adopts a separate queue management on its access bottleneck links for ICMP and TCP/UDP traffic, and bandwidth competition between TCP and UDP flows does not affect ICMP traffic (evidences are shown in Appendix B). LEOREPLAYER records the real dynamic network conditions between the terminal and the server by issuing two concurrent flows: one heavy UDP flow saturating the link to record the time-varying maximum capacity, together with one light ICMP ping flow to record the base RTT and loss rate. LEOREPLAYER then extracts the base network conditions and precisely reproduce time-varying network conditions.

真实的 Starlink 网络是一个真实但不可控的环境，其网络性能具有不可预测的时变性。为了全面评估 LeoCC，除了在黑盒的 Starlink 环境中测试，我们还需要一个可控的白盒实验环境来进行深入的性能评估和分析。然而，以往的实验工具，如低地球轨道（LEO）网络仿真器（例如 LeoEM [34] 和 StarryNet [51]），无法精确地记录和复现实时的包级行为。Mahimahi [62] 是一款最初为 HTTP 设计的记录与回放工具，在学术界被广泛用于通用网络流量测试。不幸的是，Mahimahi 主要关注记录和回放时变的网络容量，但完全复现 LEO 网络条件需要同时记录和回放路径上的最大容量、基础往返时间（RTT）和基础丢包率。这对于像 Mahimahi 这样的现有记录工具来说是相当具有挑战性的，因为最大容量和基础 RTT/丢包率在实践中很难同时测量：要测量最大容量，记录器需要使链路饱和（制造拥塞），而要获得基础 RTT，它需要同时使链路利用不足（避免拥塞）。

因此，我们实现了一个名为 LEOREPLAYER 的记录与回放工具，以精确复现高度动态的 LEO 网络条件。具体来说，LEOREPLAYER 利用了一个重要的洞察：目前的 Starlink 在其接入瓶颈链路上对 ICMP 和 TCP/UDP 流量采用独立的队列管理， TCP 和 UDP 流之间的带宽竞争不会影响 ICMP 流量（证据见附录B）。

LEOREPLAYER 通过发出两个并发流来记录终端和服务器之间的真实动态网络状况：一个重度的 UDP 流使链路饱和以记录时变的最大容量，同时一个轻量的 ICMP ping 流来记录基础 RTT 和丢包率。然后，LEOREPLAYER 提取这些基础网络状况，并精确地复现时变的网络条件。

Appendix B: Evidences for Separate Queue Management

We introduce the insight we obtained in the operational Starlink network, which guide the design of our accurate record-and-replay tool LeoReplayer for LEO networks.

我们在此介绍在实际运行的Starlink网络中获得的洞察，这些洞察指导我们为低地球轨道（LEO）网络设计了一款精确的记录与回放工具——LeoReplayer。

Observation (i): concurrent TCP, UDP, and ICMP ping traffic achieves similar base RTTs and packet loss rates. Based on a terminal in Madrid and a nearby Oracle server, we run three terminal-to-server ping flows simultaneously based on TCP, UDP and ICMP respectively. We use the Linux ping tool to send one ICMP packet every 10ms, and use iRTT [5] to send one UDP ping packet every 10ms. According to the official Starlink manual, we set the terminal to bypass mode [19] to bypass the Starlink’ home router and eliminate its potential influence. For TCP ping test, we modified the Linux TCP to bypass congestion control and constantly send one TCP packet every 10ms. Figure 27a plots the ping RTTs and loss rates of different protocols. We observe that the RTTs and loss rates across different protocols remain low and nearly identical over time, suggesting that traffic from various protocols traverses the same path in the Starlink network.

观察 (i)：并发的TCP、UDP和ICMP ping流量获得相似的基础RTT和丢包率:

我们基于位于马德里的一个终端和附近的一台Oracle服务器，同时运行了三个分别基于TCP、UDP和ICMP的终端到服务器的ping流。我们使用Linux的ping工具每10毫秒发送一个ICMP包，并使用iRTT [5]工具每10毫秒发送一个UDP ping包。

根据Starlink的官方手册，我们将终端设置为旁路模式（bypass mode）[19]以绕过Starlink的家用路由器，消除其潜在影响。对于TCP ping测试，我们修改了Linux TCP协议栈以绕过拥塞控制，并使其每10毫秒恒定发送一个TCP包。

图27a绘制了不同协议的ping RTT和丢包率。我们观察到，不同协议的RTT和丢包率随时间推移保持在较低水平且几乎完全相同，这表明来自不同协议的流量在Starlink网络中遍历的是同一路径。

Observation (ii): bandwidth competition between TCP and UDP flows does not affect ICMP traffic. Further, we measure the RTTs achieved by different protocols when TCP and UDP flows are competing for bandwidth. We run three concurrent flows to compete for the bottleneck bandwidth: a ping flow generated by the Linux ping which sends one ICMP packet every 10ms, together with a 30Mbps UDP flow and a BBRv1 TCP flow. As plotted in Figure 27b, we observe that as the UDP and TCP flows compete for bandwidth on the bottleneck link, their RTTs and packet loss rates significantly increase, but the concurrent ICMP ping flow still achieves low RTT and loss rate. In particular, due to the bandwidth competition, the BBRv1 TCP flow experiences 3∼8% loss rate and the constant UDP flow suffers from ≥50% loss rate. But the concurrent ICMP ping flow still achieves low RTT and loss rate (≤2%) similar to that in Figure 27a. We repeated this experiment dozens of times at different hours and at different vantage points and got the same observation, suggesting that Starlink may adopt a separate queue management on its access bottleneck links for ICMP and TCP/UDP traffic.

These two observations above inspire the design of our LeoReplayer, which utilizes two concurrent flows to capture time-varying network conditions: one heavy UDP flow to saturate the link and measure maximum capacity, alongside an independent ICMP light flow to assess base RTT and packet loss. We use LeoReplayer to record network variations in real LEO networks and then replay the traces to support fully controlled trace-driven simulation.

观察 (ii)：TCP和UDP流之间的带宽竞争不影响ICMP流量:

接下来，我们测量了当TCP和UDP流竞争带宽时，不同协议所获得的RTT。我们运行三个并发流来竞争瓶颈带宽：一个由Linux ping工具生成的、每10毫秒发送一个ICMP包的ping流，以及一个30Mbps的UDP流和一个BBRv1 TCP流。如图27b所示，我们观察到，当UDP和TCP流在瓶颈链路上竞争带宽时，它们的RTT和丢包率显著增加，但并发的ICMP ping流仍然能获得较低的RTT和丢包率。特别地，由于带宽竞争，BBRv1 TCP流经历了3%至8%的丢包率，恒定速率的UDP流则遭受了高达50%以上的丢包率。但并发的ICMP ping流仍然获得了与图27a中相似的低RTT和低丢包率（≤2%）。

我们在不同时间、不同观测点重复了数十次该实验，并得到相同的观察结果，这表明 Starlink可能在其接入瓶颈链路上对ICMP和TCP/UDP流量采用了独立的队列管理机制。

Evaluation

In this section, we evaluate the performance of LeoCC in various locations in the live Starlink and compare LeoCC with other existing CCAs. We also evaluate LeoCC in a trace-driven, controlled environment to assess its performance in details and analyze the impact of different parameter settings.

在本章节中，我们在真实的Starlink网络中的多个地点评估了LeoCC的性能，并将其与其他现有的拥塞控制算法（CCA）进行了比较。我们还在一个由轨迹驱动的可控环境中评估了LeoCC，以详细评估其性能并分析不同参数设置的影响。

6.1 Experiment Setup

CCAs to compare. We compare LeoCC to a number of existing Internet CCAs including: TCP Reno, Cubic [43], Vegas [33], BBRv1 [35], BBRv3 [16], VIVACE [37], Proteus [59], Copa [29], Verus [85], Sage [84] and SaTCP [34]. Specifically, for these CCAs that have already been implemented in Linux kernel (e.g., Cubic, Vegas, BBR and LeoCC), we load their TCP kernel modules and use iperf3 to generate flows. For other CCAs, we use their open-source implementations provided by the original authors for comparison. SaTCP [34] is a recent link-layer-informed CCA. It leverages linklayer information and freezes the congestion window (cwnd) when detecting satellite handovers. However, in current LEO networks like Starlink, there is no explicit method for directly obtaining handover information. The released code of SaTCP [10] does not describe how to acquire such information in real Starlink, and its original evaluation [34] relies on emulation with the assumption that handovers are detectable. To conduct comparative experiments, we integrate SaTCP with our reconfiguration detector (§4.1.1), which supplies the necessary signals to drive SaTCP’s control logic.

对比的拥塞控制算法

我们将LeoCC与一系列现有的互联网CCA进行比较，包括：TCP Reno、Cubic [43]、Vegas [33]、BBRv1 [35]、BBRv3 [16]、VIVACE [37]、Proteus [59]、Copa [29]、Verus [85]、Sage [84] 和 SaTCP [34]。具体来说，对于那些已在Linux内核中实现的CCA（如Cubic、Vegas、BBR和LeoCC），我们加载其TCP内核模块并使用iperf3生成流量。对于其他CCA，我们使用原作者提供的开源实现进行比较。SaTCP [34] 是一种近期的链路层感知CCA。它利用链路层信息，在检测到卫星切换时冻结拥塞窗口（cwnd）。然而，在当前像Starlink这样的LEO网络中，没有直接获取切换信息的显式方法。SaTCP的开源代码[10]并未描述如何在真实的Starlink中获取此类信息，其原始评估[34]依赖于仿真，并假设切换是可检测的。为了进行对比实验，我们将SaTCP与我们的重构检测器（§4.1.1）相集成，由后者提供必要的信号来驱动SaTCP的控制逻辑。

Live LEO network testbed. We build a geo-distributed testbed to evaluate LeoCC and other CCAs in real LEO network environments. The testbed includes three Starlink terminals located in Madrid, New Jersey, and Cebu, and four Oracle Cloud servers deployed in Barcelona, Frankfurt, Chicago, and Singapore. This testbed enables us to establish end-to-end connections and generate flows between any two of these endpoints in the testbed to evaluate the end-to-end throughput and delay under realistic operating conditions.

真实LEO网络测试平台

我们构建了一个地理上分布的测试平台，以在真实的LEO网络环境中评估LeoCC和其他CCA。该平台包括位于马德里、新泽西和宿务的三个Starlink终端，以及部署在巴塞罗那、法兰克福、芝加哥和新加坡的四台Oracle云服务器 ☁️。该测试平台使我们能够在任意两个端点之间建立端到端连接并生成流量，以在真实的运行条件下评估端到端的吞吐量和延迟。

Trace-driven reproducible testbed. To assess the performance details of different CCAs in a controlled environment, we use the LeoReplayer tool to record LEO network traces in the live testbed, and then replay them in our lab environment. This trace-driven, reproducible environment allows us to conduct controlled experiments for different CCAs with exactly the same parameter configuration and evaluate some aspects that are not available in the live testbed, such as queuing delay, link utilization and AQM strategies.

轨迹驱动的可复现测试平台

为了在受控环境中评估不同CCA的性能细节，我们使用 LeoReplayer 工具在真实测试平台中记录LEO网络轨迹，然后在我们的实验室环境中进行回放。这个由轨迹驱动的可复现环境允许我们以完全相同的参数配置对不同的CCA进行受控实验，并评估一些在真实测试平台上无法获得的指标，例如排队延迟、链路利用率和AQM（主动队列管理）策略。

6.2 ~ 6.7

tldr

Related Work

We briefly discuss previous efforts closely related to LeoCC.

End-to-end congestion control. Internet congestion control has been one of the most active areas of computer networks [16, 26, 29, 31, 33, 35, 37, 38, 43, 48, 53, 56, 59, 72, 76, 83–85]. In the early 2000s, many works [6, 27, 28, 71, 79, 87] studied TCP enhancement over satellite paths, but these solutions were designed for GEO satellite networks without frequent connection reconfiguration. Recent efforts have studied CCAs specially for rapidly varying networks such as WiFi/cellular networks [34, 54, 55, 57, 66, 80–82]. Among these previous efforts, CQIC [57], CLAW [81], piStream [80] and PBC-CC [82] rely on cellular/WiFi-specific PHY-layer information which is not available in current LEO networks. Verus [85] and ExLL [66], originally designed for unpredictable cellular networks, are essentially delay-based CCAs and they assume that increased delay indicates network congestion. However, the drastic LEO network variations break their fundamental assumptions.

端到端拥塞控制

互联网拥塞控制一直是计算机网络领域最活跃的研究方向之一 [16, 26, 29, 31, 33, 35, 37, 38, 43, 48, 53, 56, 59, 72, 76, 83–85]。在21世纪初，许多工作 [6, 27, 28, 71, 79, 87] 研究了卫星路径上的TCP增强技术，但这些解决方案是为没有频繁连接重构的地球静止轨道（GEO）卫星网络设计的。近期的研究则专注于为快速变化的网络（如WiFi/蜂窝网络）设计专门的拥塞控制算法（CCA）[34, 54, 55, 57, 66, 80–82]。在这些先前的研究中，CQIC [57]、CLAW [81]、piStream [80] 和 PBC-CC [82] 依赖于特定于蜂窝/WiFi网络的物理层（PHY-layer）信息，而这些信息在当前的低地球轨道（LEO）网络中是不可用的。Verus [85] 和 ExLL [66] 最初是为不可预测的蜂窝网络设计的，它们本质上是基于延迟的CCA，并假设延迟增加即表示网络拥塞。然而，LEO网络的剧烈变化打破了它们的这一基本假设。

Explicit congestion control. Another thread of existing works propose to use explicit congestion signal from the network to improve CCA performance. For example, BMCC [67, 68] introduces explicit control to insert ECN bits in the intermediate nodes with congestion. ABC [42] is an explicit congestion control protocol for network paths with time-varying wireless links. ABC requires modifications on the access point (e.g., a WiFi router or LTE base station). Since the access points of emerging LEO networks, i.e., access satellites, are hard to modify in practice (at least for now), it is difficult to directly apply ABC in practical LEO networks. Measuring LEO satellite networks. The rapid development of recent LEO networks has stimulated a range of measurement studies

显式拥塞控制

另一类现有工作提出使用来自网络的显式拥塞信号来提升CCA性能。例如，BMCC [67, 68] 引入了显式控制， 在发生拥塞的中间节点中插入ECN（显式拥塞通知）位 。ABC [42] 是一种为具有时变无线链路的网络路径设计的显式拥塞控制协议。ABC 要求对接入点（如WiFi路由器或LTE基站）进行修改。由于新兴LEO网络的接入点，即接入卫星，在实践中难以修改（至少目前如此），因此很难将ABC直接应用于实际的LEO网络

Measuring LEO satellite networks. The rapid development of recent LEO networks has stimulated a range of measurement studies to reveal the architecture [45, 64, 69, 75], physical-layer characteristic [40, 45], network performance [41, 44, 46, 50, 58, 60, 61, 77, 78, 86], and the impact on social medias [73, 74] of LEO networks. Authors of [30] conducted a preliminary measurement study on classic TCP congestion control in Starlink network, but they did not examine emerging CCAs like Copa and VIVACE. These pioneering measurement efforts complement our work. Standing on the shoulder of prior measurement works, this paper goes one step further: we conduct a comprehensive analysis on five kinds of representative CCAs, reveal the impacts of different kinds reconfigurations, and uncover insights which enable CCA improvement and accurate record-and-replay for various LEO network conditions.

LEO卫星网络测量

近期LEO网络的快速发展激发了一系列测量研究，以揭示LEO网络的架构 [45, 64, 69, 75]、物理层特性 [40, 45]、网络性能 [41, 44, 46, 50, 58, 60, 61, 77, 78, 86] 及其对社交媒体的影响 [73, 74]。文献 [30] 的作者对Starlink网络中的经典TCP拥塞控制进行了初步的测量研究，但他们没有检验如Copa和VIVACE等新兴的CCA。这些开创性的测量工作为我们的研究提供了补充。站在先前测量工作的肩膀上，本文更进一步：我们对五种代表性的CCA进行了全面的分析，揭示了不同类型重构的影响，并发现了能够改进CCA设计以及实现对各种LEO网络状况进行精确记录与回放的新洞察。

Discussion and Concluding Remark

In this paper, we identify, analyze and address the inefficiency issue of today’s Internet CCAs in LEO networks. We propose LeoCC, a robust CCA for LEO networks with high LEO dynamics. LeoCC utilizes connection reconfiguration information to enhance network estimation and rate control, enabling prompt and accurate adaptation to drastic LEO network variations. Extensive evaluations conducted in both live Starlink network and our trace-driven, controlled lab environment demonstrate that LeoCC pushes the Pareto frontier formed by existing CCAs and can achieve the best through-delay balance under various network conditions.

在本文中，我们识别、分析并解决了当今互联网拥塞控制算法（CCA）在低地球轨道（LEO）网络中的低效问题。我们提出了 LeoCC，一种针对具有高度动态性的LEO网络的鲁棒CCA 🛰️。LeoCC 利用 连接重构信息 来增强网络估计和速率控制，从而能够迅速而精确地适应剧烈的LEO网络变化。我们在真实的Starlink网络以及由轨迹驱动的可控实验室环境中进行了广泛的评估，结果表明，LeoCC 推动了由现有CCA构成的帕累托前沿，并能在各种网络条件下实现最佳的 吞吐量-延迟均衡。

As LEO networks continue to evolve rapidly and satellite Internet access remains limited in many areas currently, this paper inevitably faces certain limitations. Most experiments and analyses in this paper were conducted based on Starlink. The live testbed is currently built on three vantage points across three continents only. Our experiments primarily focus on residential satellite terminals. In future work, we will evaluate LeoCC across a broader range of LEO networks and under more varied and challenging conditions. Due to the page constraints, a more comprehensive discussion and detailed elaboration on future work are included in the Appendix E. Finally, we hope the release of LeoCC and LeoReplayer will facilitate future research on congestion control in LEO networks.

鉴于LEO网络仍在持续快速演进，且卫星互联网接入目前在许多地区仍然有限，本文不可避免地存在一定的局限性。文中的大部分实验和分析是基于Starlink进行的。我们的真实测试平台目前仅建立在三大洲的三个观测点上。此外，我们的实验主要集中于住宅卫星终端。在未来的工作中，我们将在更广泛的LEO网络中，以及在更多样化和更具挑战性的条件下评估LeoCC。由于页面限制，关于未来工作的更全面讨论和详细阐述已包含在附录E中。最后，我们希望 LeoCC 和 LeoReplayer 的开源 能够促进未来在LEO网络拥塞控制领域的研究。