LeoCC: Making Internet Congestion Control Robust to LEO Satellite DynamicsLeoCC：讓網際網路壅塞控制在 LEO 衛星動態下保持穩健
LeoCC detects reconfiguration from gaps in PoP probe replies and rebuilds its network model using fresh samples. Compare its live measurements with independent LeoEM results.LeoCC 從 PoP 探測回應的空隙辨識重組，再以新樣本重建網路模型。導讀比較實際 Starlink 量測與獨立 LeoEM 評估，說明各項增益的基準及適用範圍。
LeoCC turns the HotNets 2024 diagnosis of misleading reconfiguration signals into a Linux kernel module that works with existing Starlink infrastructure. ICMP probes to the PoP detect response gaps, after which the controller estimates bandwidth and base RTT from fresh samples [74, §4]. Live tests show throughput and delay gains over several controllers, with baseline-specific values collected in the result tables [74, §6.2, Fig. 10a]. An independent LeoEM evaluation places its goodput near SaTCP and BBRv3, while finding higher retransmissions and a gap in inter-RTT fairness reproduction preprint.
LeoCC 將 HotNets 對重組訊號誤導控制器的診斷，實作為可搭配既有 Starlink 基礎設施的 Linux 核心模組。送往 PoP 的 ICMP 探測辨識回應空隙，控制器再以事件後的新樣本估計頻寬與基礎 RTT[74, §4]。實際測試顯示相對多種控制器的吞吐量及延遲增益，結果表按基準列出數值[74, §6.2, Fig. 10a]。獨立 LeoEM 評估中，其 goodput 接近 SaTCP 與 BBRv3，同時呈現較高重傳，以及跨 RTT 公平性重現上的落差 preprint。
1. Where this paper sits1. 這篇論文的位置
LeoCC follows SaTCP [67] and the HotNets patches in Chapter 6's reconfiguration-aware designs, and appeared at SIGCOMM 2025. All treat scheduled changes as a major disturbance, but detect them at separate locations. SaTCP uses orbital elements with terminal and ground-station cooperation, the HotNets prototypes use gRPC maps and clocks, and LeoCC probes the PoP. The paper argues that the dish lacks a reconfiguration-reporting interface and second-level gRPC detection arrives late [74, §4.1.1]. For a remote sender, an eBPF program behind the dish inserts detection results into TCP ACK options [74, §5.1]. Thus both directions require user-side software, while the dish, satellites and Internet path retain their existing configuration.
第 6 章的感知重組設計依序涵蓋 SaTCP[67]、HotNets 修補及發表於 SIGCOMM 2025 的 LeoCC。三者皆將排程變動視為主要擾動，偵測位置則各有差異。SaTCP 由終端與地面站合作使用軌道根數，HotNets 原型採 gRPC 遮蔽圖與時鐘，LeoCC 則探測 PoP。論文指出天線缺少重組回報介面，秒級 gRPC 偵測也較晚到達[74, §4.1.1]。傳送端位於遠端伺服器時，終端後方主機透過 eBPF 將偵測結果寫入 TCP ACK 選項[74, §5.1]。因此雙向傳輸都需要使用者端軟體，天線、衛星與網際網路路徑則維持既有配置。
2. The problem, measured2. 問題，用量測說話
Measurements from the three Starlink sites show rapidly changing capacity, shifting minimum RTT and random loss even below full utilization [74, §2.1, Fig. 2]. Off-peak comparisons find CUBIC, Vegas, BBRv3 and Copa underusing capacity, while BBRv1, Proteus and VIVACE build queues [74, §2.2, Fig. 3]. Within a reconfiguration interval, capacity and base RTT vary mildly, with observed RTTs forming discrete bands [74, §3, Fig. 5]. Scheduled boundaries and signal-triggered changes move the path between states, with a separate reported interval for OneWeb [74, §3, §4.1.1].
三個 Starlink 觀測點顯示容量快速變動、最小 RTT 漂移，以及利用率仍有餘裕時的隨機遺失[74, §2.1, Fig. 2]。離峰比較中，CUBIC、Vegas、BBRv3 與 Copa 的容量利用偏低，BBRv1、Proteus 與 VIVACE 則累積佇列[74, §2.2, Fig. 3]。重組區間內的容量與基礎 RTT 變化較小，實測 RTT 聚集為離散帶狀[74, §3, Fig. 5]。排程邊界與訊號觸發事件使路徑切換狀態，論文也另列 OneWeb 的重組週期[74, §3, §4.1.1]。
| Item項目 | Value數值 | Conditions and interpretation條件與解讀 |
|---|---|---|
| Capacity and loss容量與遺失 | 10–70 Mbps, 0.5–6% | Saturating UDP capacity changes within tens of seconds. Random loss occurs in one-second windows below full utilization.飽和 UDP 容量在數十秒內變動，利用率仍有餘裕時，一秒窗口內也會出現隨機遺失。 |
| Live test repetition實際測試重複次數 | >50/controller, >2 min/test | Madrid–Barcelona, off-peak January 2025.2025 年 1 月離峰的馬德里–巴塞隆納路徑。 |
| Scheduled times排程時點 | 15 s: :12, :27, :42, :57 | Starlink also changes aperiodically on obstruction or weak signal. OneWeb interval cited as about 11 s.Starlink 也因遮蔽或弱訊號觸發額外重組，引用的 OneWeb 間隔約為 11 秒。 |
| gRPC detection laggRPC 偵測落後 | ≥1 s | Paper motivation for host-side probing.論文採主機端探測的理由。 |
| Pacing gains節奏增益 | 1.25, 0.75 | BBR-style gain cycling in Dynamic Cruise.Dynamic Cruise 採 BBR 式增益循環。 |
| Wired comparison有線比較 | 1 Gbps, 25 / 85 ms RTT | Inter-cloud paths reach BBR-level throughput with adaptation disabled.雲端間路徑關閉重組調適後，達到 BBR 同級吞吐量。 |
| Observation sites觀測地點 | 3 terminals / 4 servers | Madrid, New Jersey, Cebu. Oracle servers: Barcelona, Frankfurt, Chicago, Singapore.終端位於馬德里、紐澤西、宿霧。Oracle 伺服器位於巴塞隆納、法蘭克福、芝加哥、新加坡。 |
| Distribution display分布呈現 | 25th–75th / 10th–90th | Boxes and whiskers for average throughput and one-way delay.平均吞吐量與單向延遲的方框及誤差線百分位。 |
| Trace dataset軌跡資料集 | ≈4.8K, ≈200/pair/direction, ≈120 s | Both directions for each terminal–server pair.每個終端與伺服器配對的雙向軌跡。 |
| Baseline controllers基準控制器 | 11 | Reno, CUBIC, Vegas, BBRv1, BBRv3, VIVACE, Proteus, Copa, Verus, Sage, SaTCP.Reno、CUBIC、Vegas、BBRv1、BBRv3、VIVACE、Proteus、Copa、Verus、Sage、SaTCP。 |
| Independent paths獨立研究路徑 | 1,650 experiments | London, San Diego, Seattle, New York, Shanghai, covering bent-pipe and ISL paths.倫敦、聖地牙哥、西雅圖、紐約、上海，涵蓋彎管與 ISL 路徑。 |
| Independent baselines獨立研究基準 | 6 controllers | CUBIC, SaTCP, BBRv3, LeoCC, PCC-Vivace, Astraea.CUBIC、SaTCP、BBRv3、LeoCC、PCC-Vivace、Astraea。 |
| LeoEM topologyLeoEM 拓樸 | 72×22, 4 +Grid ISLs, 150 Mb/s/link | Idealized laser setup, compared with the actual three-terminal confidential topology.理想化雷射建立時間，與實際三終端保密拓樸各有適用範圍。 |
| Earlier Copa utilization較早的 Copa 利用率 | ≈20% | The same group measured this about one year earlier.同一團隊約一年前的量測。 |
3. The design3. 設計
LeoCC combines detection, a network model and a rate controller [74, §3, Fig. 6]. The detector sends periodic ICMP probes to the closest reachable PoP and identifies reconfiguration when consecutive reply intervals exceed Δoutage [74, §4.1.1, Fig. 7]. Reply gaps remain visible even when every probe during an outage is lost, and one flow serves all connections on a device [74, §4.1.1, App. A]. The model assigns bandwidth and base RTT to each interval and discards samples from earlier states.
It maintains aggressive maximum-filter and moderate Kalman-filter bandwidth estimates, plus an RTT band [bRTTl, bRTTh] from a middle-pass filter [74, §4.1.2, §4.2.1]. After Startup, Dynamic Cruise uses the aggressive estimate while filtered RTT stays within the band. When RTT exceeds the upper edge by ΔRTT, it uses the moderate estimate, with BBR-style pacing gains. Reconfiguration Adaptation drains the queue with an inflight cap of 0.5·bBWm·bRTTl, refreshes the band and resumes the saved target rate [74, §4.2, Fig. 9].
A check subtracts terminal-to-PoP RTT from end-to-end RTT to identify terrestrial bottlenecks, which bypass this adaptation [74, §4.3]. The paper leaves its BBR base version unspecified. The code identifies BBRv3, and independent readers describe STARTUP re-entry at half the bandwidth-delay product preprint. That interpretation corresponds to the paper's 0.5·bBW·bRTT cap.
On wired paths, LeoCC disables reconfiguration adaptation and reaches BBR-level throughput using BBR-like control [74, §6.7, Figs. 24–25].
LeoCC 結合偵測器、網路模型與速率控制器[74, §3, Fig. 6]。偵測器定期探測最近可達的 PoP，當相鄰回應間隔超過 Δoutage 時判定重組[74, §4.1.1, Fig. 7]。即使中斷期間的探測全部遺失，回應空隙仍可辨識，而且單一探測流可供裝置上所有連線共用[74, §4.1.1, App. A]。模型為每個區間配置頻寬與基礎 RTT，丟棄較早狀態的樣本，同時保留最大值濾波的積極估計、Kalman 濾波的溫和估計，以及中通濾波得到的 RTT 帶 [bRTTl, bRTTh][74, §4.1.2, §4.2.1]。Startup 之後進入 Dynamic Cruise，濾波 RTT 位於帶內時採積極估計，超過上緣 ΔRTT 後則採溫和估計，並循環使用 BBR 式節奏增益。重組調適以 0.5·bBWm·bRTTl 限制在途量以排空佇列，再更新 RTT 帶並恢復保存的目標速率[74, §4.2, Fig. 9]。端到端 RTT 減去終端至 PoP RTT 的檢查可辨識地面瓶頸，此時略過調適[74, §4.3]。論文對 BBR 基礎版本的說明仍待補充，程式碼則標示源自 BBRv3，獨立研究將實作解讀為以約半個頻寬延遲乘積重新進入 STARTUP preprint，對應論文的 0.5·bBW·bRTT 上限。有線路徑會關閉重組調適，採類似 BBR 的控制並達到同級吞吐量[74, §6.7, Figs. 24–25]。
Original figure note原始圖說出處
Drawn for this primer from Lai et al., SIGCOMM 2025, §4.1–4.2 and Fig. 7. The probe timeline is schematic, and Mazilu et al., arXiv 2510.25498, Fig. 1a (preprint).4. Evaluation setup4. 實驗設定
The evaluation combines live Starlink tests and trace replay, reporting throughput and one-way delay distributions [74, §6.1–6.2, Fig. 10]. Eleven baseline controllers include SaTCP, which uses LeoCC's detector because its released code needs an external source of live handover times [74, §6.1]. LeoReplayer records capacity with saturating UDP and base RTT and loss with light ICMP, relying on separate protocol queues [74, §5.2, App. B]. The paper presents its recorder and player as a new tool, while the release describes a Mahimahi extension.
The recorded dataset covers terminal–server pairs in both directions [74, §6.3]. These are bent-pipe access paths, so their reconfiguration timing is observed in traces. Mazilu et al.'s independent study uses LeoEM over both bent-pipe and ISL paths preprint. Its parameters follow SaTCP's filed shell, +Grid links, link-rate cap and idealized setup, which define the scope of its topology results.
評估結合實際 Starlink 測試與軌跡重播，以分布呈現吞吐量及單向延遲[74, §6.1–6.2, Fig. 10]。十一種基準控制器包含 SaTCP，作者為它接上 LeoCC 偵測器，以提供釋出程式碼所需的實際換手時點[74, §6.1]。LeoReplayer 用飽和 UDP 記錄容量，以輕量 ICMP 記錄基礎 RTT 與遺失，前提是兩者使用獨立協定佇列[74, §5.2, App. B]。論文將錄製重播器介紹為新工具，程式碼則描述為 Mahimahi 延伸，資料集涵蓋雙向的終端與伺服器配對[74, §6.3]。這些皆為彎管存取路徑，重組時間取自軌跡觀察。Mazilu 等人的獨立研究以 LeoEM 評估彎管與 ISL 路徑 preprint，其範圍由承襲 SaTCP 的申報殼層、+Grid、速率上限及理想化建立時間界定。
5. What was measured5. 量到了什麼
| Claim宣稱 | Setup and caveat設定與附註 |
|---|---|
| Madrid→Barcelona uplink, live: throughput +85% over BBRv3, +253% over CUBIC, +494% over Copa, and 2.8× Sage [74, §6.2, Fig. 10a]馬德里→巴塞隆納上行，實際網路：吞吐量比 BBRv3 高 85%、比 CUBIC 高 253%、比 Copa 高 494%，為 Sage 的 2.8 倍[74, §6.2, Fig. 10a] | These baseline-specific ratios all come from one live uplink. Figures 10b and 10c also place LeoCC beyond the downlink and dish-to-dish Pareto frontiers.這些按基準計算的比值均來自同一條實際上行路徑。Fig. 10b 的下行與 Fig. 10c 的馬德里–紐澤西終端間路徑，也顯示 LeoCC 超越其柏拉圖前緣。 |
| One-way delay −44% against BBRv1, −56% against VIVACE and −38% against Proteus, with higher throughput than VIVACE and Proteus [74, §6.2, Fig. 10a]單向延遲比 BBRv1 低 44%、比 VIVACE 低 56%、比 Proteus 低 38%，吞吐量也高於 VIVACE 與 Proteus[74, §6.2, Fig. 10a] | The delay range compares controllers that overfill queues. CUBIC, BBRv3 and Copa maintain low delay through lower capacity utilization.延遲範圍比較的是會累積佇列的控制器，CUBIC、BBRv3 與 Copa 則透過較低的容量利用率維持低延遲。 |
| Path base RTTs of 52, 77 and 104 ms (Cebu→Singapore, Madrid→Frankfurt, New Jersey→Barcelona): LeoCC stays outside the Pareto frontier on all three [74, §6.2, Fig. 11]基礎 RTT 為 52、77 與 104 ms 的路徑（宿霧→新加坡、馬德里→法蘭克福、紐澤西→巴塞隆納）：LeoCC 在三條路徑上都位於柏拉圖前緣之外[74, §6.2, Fig. 11] | Live. CUBIC, SaTCP, Vegas and Copa stay at low throughput on every path實際網路。CUBIC、SaTCP、Vegas 與 Copa 在每條路徑上吞吐量都低 |
| Average link utilization in replay: LeoCC 95.2%, BBRv1 95.8%, VIVACE 81.5%, Verus 70.5% [74, §6.3, Fig. 13]重播中的平均鏈路利用率：LeoCC 95.2%、BBRv1 95.8%、VIVACE 81.5%、Verus 70.5%[74, §6.3, Fig. 13] | LeoReplayer traces. BBRv1 matches the utilization only by building a larger queue, especially when capacity drops after a reconfigurationLeoReplayer 軌跡。BBRv1 只是靠堆出更大的佇列才達到相同利用率，在重組後容量下降時尤其明顯 |
| Four staggered LeoCC flows give Jain's index 0.99–1. Four flows at 20/48/85/145 ms reach similar throughput. Two LeoCC and two BBRv1 flows give 0.98–0.99 [74, §6.4, Figs. 15–17]公平性：四條錯開啟動的 LeoCC 流使 Jain 指數維持在 0.99–1，RTT 為 20/48/85/145 ms 的四條流得到相近吞吐量，兩條 LeoCC 與兩條 BBRv1 並行時為 0.98–0.99[74, §6.4, Figs. 15–17] | Madrid terminal. Coexistence with Reno, CUBIC, BBRv3 and Copa is described qualitatively, as those flows remain self-limited even when run alone.馬德里終端。與 Reno、CUBIC、BBRv3 及 Copa 的共存採定性描述，因為這些流單獨執行時也會自我設限。 |
| A 6-byte probe every 10 ms gives about 51 kbps with headers, or 0.13% of a 36 Mbps uplink. CPU use stays at 0.8–2.2% [74, §6.6, Fig. 21]開銷：每 10 ms 一個 6 位元組的探測酬載，連同標頭每台終端約 51 kbps，佔 36 Mbps 平均上行的 0.13%，增加並行流時 CPU 使用率維持在 0.8–2.2%[74, §6.6, Fig. 21] | One probe flow per terminal regardless of the number of LeoCC flows每台終端共用一條探測流，流數增加時也維持此配置 |
| DASH video over replayed traces: bitrate +56–120% over Vegas and CUBIC and +14–27% over BBRv3. Stall rate −56–88% and −16–40% respectively [74, §6.7, Fig. 22]在重播軌跡上的 DASH 影片：位元率比 Vegas 與 CUBIC 高 56–120%、比 BBRv3 高 14–27%。停頓率依序降低 56–88% 與 16–40%[74, §6.7, Fig. 22] | Madrid→Barcelona and New Jersey→Chicago traces. Only Linux kernel controllers compared馬德里→巴塞隆納與紐澤西→芝加哥軌跡。只比較 Linux 核心內的控制器 |
| Normalized goodput SEA→NY: CUBIC 49.0, SaTCP 94.4, BBRv3 90.2, LeoCC 93.5, Astraea 65.7 [75] preprintSEA→NY 正規化 goodput：CUBIC 49.0、SaTCP 94.4、BBRv3 90.2、LeoCC 93.5、Astraea 65.7[75]preprint | LeoEM emulation across 1,650 runs. LeoCC goodput falls between SaTCP and BBRv3.LeoEM 的 1,650 次模擬中，LeoCC 的結果位於 SaTCP 與 BBRv3 之間 |
| LeoCC restarts STARTUP after every reconfiguration and has the highest retransmission rate of the set. BBRv3 takes ~12 s to adapt to a sharp RTT rise [75] preprintLeoCC 在每次重組後重啟 STARTUP，重傳率是該組中最高。BBRv3 需約 12 s 適應 RTT 急升[75]preprint | The paper reports faster convergence than a slow-start reset (Figs. 18–19). Retransmission counts require the independent evidence, where OrbCC also identifies repeated startups. preprint論文顯示調適比重設慢啟動收斂更快（Figs. 18–19），重傳次數則需參照獨立證據，OrbCC 也指出反覆啟動現象。preprint |
| The original and LeoEM studies differ on inter-RTT fairness. CUBIC and SaTCP show roughly 0.5 goodput ratios [75] preprint原研究與 LeoEM 對跨 RTT 公平性的結果有差異，CUBIC 與 SaTCP 的 goodput 比約為 0.5[75]preprint | The paper's test used four live flows at 20–145 ms RTT from one terminal (Fig. 16), while Mazilu et al. emulate LeoEM paths論文的測試是從同一終端發出、RTT 為 20–145 ms 的四條實際流（Fig. 16），Mazilu 等人則是模擬 LeoEM 路徑 |
6. Limits and open questions6. 限制與待研究的問題
- Live evidence covers residential terminals in one constellation. The authors identify mobile, aviation and maritime terminals, other constellations and more observation sites as future work [74, §8, App. E]. Detection thresholds and other parameters were tuned empirically at the measured sites [74, §5.1, Fig. 20].實際證據涵蓋單一星座的住宅終端。作者將移動、航空與海事終端、其他星座及更多觀測點列為後續研究[74, §8, App. E]。偵測門檻與其他參數均在這些觀測點上依經驗調整[74, §5.1, Fig. 20]。
- Headline gains depend on the baseline. The result table separates each controller comparison on the same live uplink. Against a modern model-based controller, use the BBRv3 result, while delay comparisons use queue-building controllers [74, §6.2].主要增益取決於基準。結果表逐一列出同一實際上行路徑上的控制器比較。相對現代模型式控制器時，應採 BBRv3 的結果，延遲比較則以會累積佇列的控制器為基準[74, §6.2]。
- Detection depends on measured Starlink behavior. It assumes stable ICMP access to a PoP and visible response gaps. LeoReplayer also assumes separate ICMP and TCP/UDP queues, based on an appendix awaiting peer review [74, §4.1.1, §6.5, App. B]. Operator changes to ICMP treatment could affect both.偵測依賴實測的 Starlink 行為。它假設 ICMP 可穩定探測 PoP，且回應間隔能呈現中斷。LeoReplayer 另假設 ICMP 與 TCP/UDP 各有佇列，依據來自同儕審查狀態待確認的附錄[74, §4.1.1, §6.5, App. B]。營運商調整 ICMP 處理方式時，兩者都可能受影響。
- Repeated adaptation raises retransmission costs. Independent studies identify high retransmissions and repeated startup phases, while OrbCC also questions probing overhead preprint. The original paper reports probe and CPU costs. Retransmission comparisons rely on the independent evaluations.反覆調適會增加重傳成本。獨立研究指出較高重傳與反覆啟動，OrbCC 也質疑探測開銷 preprint。原論文報告探測與 CPU 成本，重傳比較則需參照獨立評估。
- Fairness and deployment need broader evidence. LeoEM and the original live-flow study report different inter-RTT fairness outcomes. Published deployment evidence remains limited to the authors' testbed. The related Path Phase Boundary proposal is an expired individual IETF draft (fact base Chapter 6).公平性與部署需要更廣證據。LeoEM 與原始實際流研究的跨 RTT 公平性結果互有差異，公開部署證據仍限於作者測試床。相關「路徑相位邊界」提案是一份已過期的 IETF 個人草案（事實庫第 6 章）。
- The evaluations have separate path scopes. LeoCC traces cover bent-pipe user access. Independent ISL results use LeoEM's legacy +Grid assumptions and idealized setup. Applying them to Starlink's actual terminal count and confidential topology needs further evaluation (fact base Part C, items 13, 55, 56, 60).各項評估的路徑範圍需區分。LeoCC 軌跡涵蓋彎管使用者存取，獨立 ISL 結果採 LeoEM 的較早 +Grid 假設及理想化建立時間。套用至 Starlink 實際終端數與保密拓樸時，仍需額外評估（事實庫 Part C 第 13、55、56、60 項）。
7. How it connects7. 與其他內容的關聯
- Section 6.3: the third reconfiguration-aware design, with the 85–494% range and the Mazilu goodput comparison.第 6.3 節：第三個重組感知設計，含 85–494% 範圍與 Mazilu 的 goodput 比較。
- Section 6.4: repeated-startup costs, fairness questions and the limited deployment evidence for LEO-aware controllers.第 6.4 節：反覆啟動成本、公平性問題，以及 LEO 感知控制器部署證據的範圍。
- Section 6.1: the capacity swings LeoCC detects, and Section 6.6 for what remains unknown about transport across ISLs.第 6.1 節：LeoCC 所偵測的容量擺盪，以及第 6.6 節關於跨 ISL 傳輸仍待確認的部分。
- Section 3.5: the 15-second schedule whose boundaries the PoP probe detects. Section 7.4 for LeoEM and trace replay as evaluation tools.第 3.5 節：PoP 探測所偵測的 15 秒排程邊界。第 7.4 節談 LeoEM 與軌跡重播作為評估工具。
- Sibling digests: Lai et al. [56] gives live diagnostic evidence. SaTCP supplies the ground-assisted design and LeoEM. Kassem et al. identifies idle capacity. Garcia et al. examines the front-drop queue.同組導讀：Lai 等人[56]提供診斷與實際 Starlink 資料，SaTCP介紹地面協助方案及 LeoEM，Kassem 等人辨識最初的閒置容量現象，Garcia 等人分析傳送端模型面對的前端丟棄佇列。
Key numbers關鍵數字
| Number | 數字 | Meaning (setup) | 意義（設定） |
|---|---|---|---|
| 85 / 253 / 494% | Throughput gain over BBRv3 / CUBIC / Copa, live Madrid→Barcelona uplink [74, §6.2, Fig. 10a] | 相對 BBRv3 / CUBIC / Copa 的吞吐量增益，實際馬德里→巴塞隆納上行[74, §6.2, Fig. 10a] | |
| 44 / 56% | One-way delay reduction against BBRv1 / VIVACE on the same path [74, §6.2, Fig. 10a] | 同一路徑上相對 BBRv1 / VIVACE 的單向延遲降幅[74, §6.2, Fig. 10a] | |
| 10 ms · 45 ms | ICMP probe period and response-interval threshold for declaring a reconfiguration [74, §4.1.1, §5.1] | ICMP 探測週期，以及判定重組的回應間隔門檻[74, §4.1.1, §5.1] | |
| 45–120 ms | Network-layer outage observed at each periodic or aperiodic reconfiguration [74, §4.1.1] | 每次定期或事件觸發重組所觀察到的網路層中斷[74, §4.1.1] | |
| 3 · 4 · ~4.8K | Starlink terminals (Madrid, New Jersey, Cebu), cloud servers, and recorded ~120-s traces [74, §6.1, §6.3] | Starlink 終端（馬德里、紐澤西、宿霧）、雲端伺服器，以及錄得的約 120 秒軌跡數[74, §6.1, §6.3] | |
| 95.2% | LeoCC link utilization in replay, against BBRv1 95.8%, VIVACE 81.5%, Verus 70.5% [74, §6.3] | 重播中 LeoCC 的鏈路利用率，對照 BBRv1 95.8%、VIVACE 81.5%、Verus 70.5%[74, §6.3] | |
| 0.99–1 / 0.98–0.99 | Jain's index for four LeoCC flows / two LeoCC plus two BBRv1 flows [74, §6.4] | 四條 LeoCC 流 / 兩條 LeoCC 加兩條 BBRv1 流的 Jain 指數[74, §6.4] | |
| ≈51 kbps · 0.13% | Probing overhead per terminal and its share of a 36 Mbps uplink [74, §6.6] | 每台終端的探測開銷及其佔 36 Mbps 上行的比例[74, §6.6] | |
| 8 × 600 | Starlink trace directories × traces per directory shipped with the code for LeoReplayer | 隨程式碼附給 LeoReplayer 的 Starlink 軌跡目錄數 × 每目錄軌跡數 | |
| 49.0 / 94.4 / 90.2 / 93.5 / 65.7 | Mazilu et al. normalized goodput SEA→NY: CUBIC / SaTCP / BBRv3 / LeoCC / Astraea, LeoEM [75] preprint | Mazilu 等人 SEA→NY 正規化 goodput：CUBIC / SaTCP / BBRv3 / LeoCC / Astraea，LeoEM[75]preprint | |
| 1,650 | LeoEM experiments in the Mazilu et al. study. 15-s change interval, 45–120 ms reconfiguration gaps preprint | Mazilu 等人研究中的 LeoEM 實驗次數。15 秒變化間隔、45–120 ms 重組間隙 preprint | |
| 2.14× / 2.30× | Single-flow delay inflation, CUBIC / SaTCP, on LeoEM [75] preprint | LeoEM 上的單流延遲膨脹，CUBIC / SaTCP[75]preprint | |
| ~12 s | Time BBRv3 needed to adapt to a sharp RTT rise on LeoEM [75] preprint | BBRv3 在 LeoEM 上適應 RTT 急升所需時間[75]preprint | |
| ~½ BDP | Window at which LeoCC re-enters STARTUP after each reconfiguration [75] preprint | LeoCC 每次重組後重新進入 STARTUP 的視窗[75]preprint |