Mind the Misleading Effects of LEO Mobility on End-to-End Congestion Control小心 LEO 移動性對端到端壅塞控制的誤導效應

ACM HotNets 2024Lai, Li, Wu, Li, Liu, Liu, Xie, Li, Liu (Tsinghua University) · paper論文 peer-reviewed (workshop)

This digest explains how scheduled capacity changes cause congestion-control overshoot or underuse. It then examines event-aware sample resets in reproducible trace replay.本導讀說明排程容量變化如何造成壅塞控制過衝或低利用率，再檢視可重現軌跡重播中的感知事件樣本重設。

≈ 7 min · 5-question quiz≈ 7 分鐘 · 5 題測驗Chapter 6 ↗第 6 章 ↗Jump to the quiz ↓跳到測驗 ↓

If you read nothing else

只讀這一段也可以

Scheduled path changes can make both aggressive and conservative controllers misread their recent samples. Resetting estimates at an event provides a targeted response.

排程路徑變化會使積極與保守控制器誤讀近期樣本，在事件時重設估計提供針對性處理。

Live diagnosis and replay outcomes
#	Reported values and conditions
1	Lai et al. measured New Jersey and Madrid terminals at about 32/187 and 30/357 Mbps up/down, with RTTs of 59 and 27 ms.
2	One three-minute capacity trace ranges from 10 to 65 Mbps ^{[56, §3.1]}.
3	Each of nine controllers receives over thirty two-minute live tests.
4	Verus, VIVACE and BBRv1 overshoot, while CUBIC, Vegas, BBRv3, Sprout and Copa underuse capacity.
5	Copa averages 20% utilization and 6.84 Mbps, and BBRv3 stays below 65% on lossy paths ^{[56, §3.2–3.3]}.
6	Across a month, over 80% of :12/:27/:42/:57 events change capacity over 10 Mbps, about 20% at least 40 Mbps.
7	Outside those times, 90% of changes stay under 5 Mbps ^{[56, §4, Fig. 7]}.
8	In Mahimahi replay, event-aware BBRv1 reduces mean RTT from 60.30 to 42.11 ms, and Copa raises throughput from 6.84 to 11.93 Mbps ^{[56, Tab. 1]}.
9	Prototype evidence concerns replayed Starlink bent-pipe traces.

實際診斷與重播結果
#	數值、條件與證據
1	Lai 等人在新澤西、馬德里量得約 32/187、30/357 Mbps 上下行，RTT 為 59、27 ms，單一三分鐘容量軌跡介於 10–65 Mbps ^{[56, §3.1]}。
2	九種控制器各跑逾三十次兩分鐘實測，Verus、VIVACE、BBRv1 過衝，CUBIC、Vegas、BBRv3、Sprout、Copa 則利用偏低。
3	Copa 平均利用 20%、吞吐 6.84 Mbps，BBRv3 在有遺失路徑低於 65% ^{[56, §3.2–3.3]}。
4	一個月內，:12/:27/:42/:57 事件逾 80% 使容量變逾 10 Mbps，約 20% 至少 40 Mbps，其他時刻 90% 低於 5 Mbps ^{[56, §4, Fig. 7]}。
5	Mahimahi 重播的感知 BBRv1 把平均 RTT 從 60.30 降至 42.11 ms，Copa 吞吐從 6.84 升至 11.93 Mbps ^{[56, Tab. 1]}，原型證據適用於重播 Starlink 彎管軌跡。

1. Where this paper sits1. 這篇論文的位置

The paper connects unused-capacity measurements with the group’s LeoCC kernel controller, published at SIGCOMM 2025. Tanveer et al. established fifteen-second latency boundaries ^[13], and Mohan et al. observed them with one visible satellite ^[49]. Lai et al. examine the transport consequences across controller families and show benefits from event timing. SaTCP reaches a related conclusion for predicted handovers in emulation. This study instead uses measured global reconfiguration, later described as a “Path Phase Boundary” in draft-lai-ccwg-lsncc (fact base Chapter 6).

本文連結低利用率量測與團隊在 SIGCOMM 2025 發表的 LeoCC 核心控制器。Tanveer 等人建立十五秒延遲邊界 ^[13]，Mohan 等人在單一可見衛星下也觀察到 ^[49]。Lai 等人研究各控制器家族的傳輸後果，並展示事件時序的效益。SaTCP 在預測換手模擬中得到相關結論，本文則採實測全域重配，後來由 draft-lai-ccwg-lsncc 稱為「路徑相位邊界」（事實庫第 6 章）。

2. The problem, measured2. 問題，用量測說話

The measurements connect large capacity steps to known reconfiguration boundaries. Controller behavior then depends on how stale estimates influence sending after a step.

量測把大容量階躍連到已知重配邊界，控制器行為則取決於過時估計如何影響階躍後傳送。

Measurement setup and controller behavior
#	Reported values and conditions
1	Two terminals probe Oracle servers just beyond the gateway, keeping terrestrial paths short. iperf3 UDP measures capacity, tcpdump loss, and 5 ms pings RTT [56, §3].
2	New Jersey averages 32/187 Mbps and 59 ms, Madrid 30/357 Mbps and 27 ms. ^{[56, §3]}
3	A three-minute trace spans 10–65 Mbps.
4	Controllers each receive over thirty two-minute tests in comparable off-peak weather windows.
5	Peak-chasing Verus, VIVACE and BBRv1 amplify RTT after capacity drops.
6	CUBIC, Vegas, BBRv3, Sprout and Copa stay conservative, with Copa at 20%, 6.84 Mbps, and lossy-path BBRv3 below 65% ^{[56, §3.2–3.3, Figs. 3–5]}.
7	Global boundaries at :12/:27/:42/:57 account for most large changes.
8	Across a month, over 80% exceed 10 Mbps and about 20% reach 40 Mbps between adjacent seconds.
9	Local events come from one-second gRPC obstruction-map changes ^{[56, Fig. 7]}.

量測設定與控制器行為
#	數值、條件與證據
1	兩終端探測閘道後方 Oracle 伺服器，縮短地面路徑，以 iperf3 UDP 量容量、tcpdump 記遺失、5 ms ping 量 RTT ^{[56, §3]}。
2	新澤西平均 32/187 Mbps、59 ms，馬德里為 30/357 Mbps、27 ms，三分鐘軌跡為 10–65 Mbps。
3	各控制器在可比離峰與天氣時段跑逾三十次兩分鐘測試。
4	追逐峰值的 Verus、VIVACE、BBRv1 在容量下降後放大 RTT，其他所列控制器較保守，Copa 為 20%、6.84 Mbps，BBRv3 有遺失時低於 65% ^{[56, §3.2–3.3, Figs. 3–5]}。
5	:12/:27/:42/:57 全域邊界解釋多數大變化，一個月中逾 80% 超過 10 Mbps、約 20% 在相鄰秒達 40 Mbps，局部事件則來自每秒 gRPC 遮蔽圖變化 ^{[56, Fig. 7]}。

3. The design3. 設計

Both prototypes refresh their path model after reconfiguration. Their terminal-side detection is adequate for the experiment, with finer and remotely usable feedback needed for deployment.

兩原型都在重配後更新路徑模型，終端側偵測支援實驗，部署則需更細緻、可回傳遠端的回饋。

Event-aware sample-reset design
#	Reported values and conditions
1	The proposed design uses reconfiguration timing to separate scheduled path changes from congestion ^{[56, §5]}.
2	BBRv1 combines Kalman-filtered bandwidth and RTT estimates with a reset of pre-event samples.
3	This removes the previous phase’s peak from the current path model.
4	Copa similarly resets old RTT samples and uses about twenty RTTs to establish its new queueing-delay target ^{[56, §5]}.
5	Global events use the clock, and local events use one-second gRPC maps.
6	The authors regard that granularity as coarse for production.
7	LeoCC later replaces it with end-host 10 ms ICMP probing, detecting response gaps above 45 ms within tens of milliseconds.

感知事件的樣本重設設計
#	數值、條件與證據
1	設計利用重配時序區分排程路徑變化與壅塞。
2	BBRv1 結合 Kalman 頻寬、RTT 估計，並重設事件前樣本，使舊相位峰值離開目前路徑模型。
3	Copa 也重設舊 RTT，以約二十 RTT 建立新佇列延遲目標 ^{[56, §5]}。
4	全域事件用時鐘，局部用每秒 gRPC 地圖，作者認為正式部署需要更細粒度。
5	後續 LeoCC 改採端點每 10 ms ICMP，從超過 45 ms 回應空隙在數十毫秒內偵測。

Figure A. Scheduled capacity changes produce two controller responses. Peak-chasing models fill queues after a drop, while loss- and delay-sensitive designs remain conservative. Samples from the previous path phase can mislead both, motivating a sample reset at reconfiguration.圖 A。排程容量變化產生兩類反應：追峰模型在容量下降後填滿佇列，遺失、延遲敏感設計則維持保守。舊路徑相位樣本都可能造成誤判，因此在重配時重設樣本。Sources來源: ^{[56, §3, §5, Tab. 1]}

Original figure note原始圖說出處

Drawn for this primer from Lai et al., HotNets 2024, §3–§5, Figs. 2a, 3–5, 7 and Table 1 (step heights schematic).

4. Evaluation setup4. 實驗設定

Live tests diagnose the problem, while recorded replay compares prototype responses under matched conditions. These two evidence layers support separate claims.

實測診斷問題，錄製重播則在相同條件比較原型，兩層證據各支持相應主張。

Evaluation layers and trace scope
#	Reported values and conditions
1	Live diagnosis uses two Starlink terminals and bent-pipe paths to servers behind the gateway.
2	OneWeb and identified ISL paths lie outside the observed sample ^{[56, §3]}.
3	Prototype evaluation extends Mahimahi with recorded capacity traces, giving patched and original controllers identical conditions ^{[56, §5]}.
4	The observed fifteen-second structure enters through traces, with a separate constellation model unnecessary.
5	Each algorithm has over thirty two-minute live tests under similar off-peak and weather conditions.
6	Reconfiguration statistics use a month of capacity data.

評估層次與軌跡範圍
#	數值、條件與證據
1	實際診斷採兩台 Starlink 終端，經彎管至閘道後伺服器，OneWeb 與已辨識 ISL 路徑在樣本之外 ^{[56, §3]}。
2	原型以錄製容量擴展 Mahimahi，使修補與原版面對相同條件 ^{[56, §5]}。
3	十五秒結構由實測軌跡帶入，可直接研究端到端行為。
4	每演算法在相似離峰、天氣時段有逾三十次兩分鐘實測，重配統計採一個月容量資料。

5. What was measured5. 量到了什麼

Claim宣稱	Setup and caveat設定與附註
New Jersey capacity is ≈ 32/187 Mbps up/down, with 59 ms RTT. Madrid gives ≈ 30/357 Mbps and 27 ms RTT. One trace varies from 10–65 Mbps within three minutes ^{[56, §3.1]}容量約 32/187 Mbps 上/下行、RTT 59 ms（新澤西），約 30/357 Mbps、27 ms（馬德里），一段軌跡三分鐘內在 10–65 Mbps 間擺盪^{[56, §3.1]}	Live iperf3 UDP provides the trace. The 10–65 Mbps range concerns one interval, while campaign averages have broader scope. Trace direction requires clarification.實際 iperf3 UDP 提供軌跡，10–65 Mbps 描述單一區間，全程平均有較廣範圍，軌跡方向則需釐清。
Verus, VIVACE and BBRv1 overshoot and amplify RTT. CUBIC, Vegas, BBRv3, Sprout and Copa under-use capacity. Copa reaches ≈ 20% utilisation and 6.84 Mbps. BBRv3 stays below 65% on lossy links ^{[56, §3.2–3.3]}Verus、VIVACE、BBRv1 過度衝高並放大 RTT，CUBIC、Vegas、BBRv3、Sprout、Copa 利用率偏低，Copa 利用率約 20%、6.84 Mbps，BBRv3 在有遺失鏈路上 < 65%^{[56, §3.2–3.3]}	>30 two-minute live tests per CCA, only Copa and BBRv3 get numeric values in the text每種 CCA >30 次兩分鐘實地測試，文中只有 Copa 與 BBRv3 有數值
Global reconfigurations at :12/:27/:42/:57, >80% change capacity by >10 Mbps, ~20% by ≥40 Mbps, ~90% of out-of-window changes < 5 Mbps ^{[56, §4, Fig. 7]}全域重組在 :12/:27/:42/:57，>80% 使容量變化 >10 Mbps、約 20% ≥40 Mbps，窗口外約 90% 的變化 < 5 Mbps^{[56, §4, Fig. 7]}	One month of data, local reconfigurations detected from gRPC obstruction maps at 1-s granularity一個月資料，局部重組以 1 秒粒度從 gRPC 遮蔽圖偵測
Reconfiguration-aware BBRv1: throughput 27.96 → 26.24 Mbps, average RTT 60.30 → 42.11 ms (−30.2%), p95 97.95 → 78.30 ms (−20.1%) ^{[56, Tab. 1]}重組感知的 BBRv1：吞吐量 27.96 → 26.24 Mbps，平均 RTT 60.30 → 42.11 ms（−30.2%），p95 97.95 → 78.30 ms（−20.1%）^{[56, Tab. 1]}	Mahimahi trace replay, a small throughput loss buys the RTT gainMahimahi 軌跡重播，以少許吞吐量換取 RTT 改善
Reconfiguration-aware Copa: 6.84 → 11.93 Mbps (+74.4%) at RTT 34.30 → 34.54 ms ^{[56, Tab. 1]}重組感知的 Copa：6.84 → 11.93 Mbps（+74.4%）、RTT 34.30 → 34.54 ms^{[56, Tab. 1]}	Replay improves part of Copa’s utilization penalty, with throughput still well below the link’s campaign average.重播改善 Copa 部分利用率代價，吞吐仍遠低於鏈路全程平均。

6. Limits and open questions6. 限制與待解的問題

Both prototypes are evaluated in Mahimahi replay. The −30.2% RTT and +74.4% throughput results therefore describe two algorithms under recorded conditions, with live deployment requiring further evaluation ^{[56, §5, §7]}.兩個原型均在 Mahimahi 重播評估，因此 −30.2% RTT、+74.4% 吞吐量描述兩演算法的錄製條件，實際部署仍需進一步評估 ^{[56, §5, §7]}。
Local detection depends on one-second dish gRPC maps, while global detection uses the boundary clock. Remote senders require event feedback from a terminal-side component. LeoCC later supplies this through end-host probes and TCP ACK options.局部偵測依賴每秒天線 gRPC 地圖，全域依邊界時鐘，遠端傳送端需要終端側元件回報事件。後續 LeoCC 以端點探測與 TCP ACK 選項提供這項回饋。
The 10–65 Mbps range describes one three-minute trace, while 187 and 357 Mbps describe campaign download averages. Further source detail is required to connect them. Live per-controller numeric reporting covers Copa and BBRv3, with a full numeric comparison and misclassification counts left open.10–65 Mbps 描述單一三分鐘軌跡，187、357 Mbps 則是全程下載平均，兩者連結需要更多來源細節。實際逐控制器數值涵蓋 Copa、BBRv3，完整比較與誤判次數仍待提供。
Evidence covers Starlink bent pipes at two northern mid-latitude sites. ISL-routed and polar users, such as McMurdo, require separate measurements of scheduling and capacity variation.證據涵蓋北半球中緯度兩站的 Starlink 彎管，ISL 路由與麥克默多等極區使用者，需要各自的排程及容量變化量測。
The interval is attributed to SpaceX’s FCC petition and earlier measurements. Its generating algorithm, alongside scheduler and queue details, remains undisclosed (fact base Part D, item 13 and Chapter 3).間隔歸因於 SpaceX FCC 請願書與早期量測，其產生演算法與排程、佇列細節仍待公開（事實庫 Part D，第 13 項及第 3 章）。

7. How it connects7. 與其他內容的關聯

Section 6.1: the 10–65 Mbps capacity swings and the schematic RTT/capacity trace over a minute.第 6.1 節：10–65 Mbps 的容量擺盪，以及一分鐘內 RTT/容量軌跡的示意。
Section 6.3: the Copa +74.4% and BBRv1 −30.2% patches as the second of three reconfiguration-aware designs.第 6.3 節：Copa +74.4% 與 BBRv1 −30.2% 的修補，是三種重組感知設計中的第二種。
Section 6.4: deployment requirements and evidence at research scale.第 6.4 節：部署需求與研究規模證據。
Section 3.5: the :12/:27/:42/:57 schedule, and Section 3.4 for the measured RTT and throughput baselines these terminals match.第 3.5 節：:12/:27/:42/:57 的排程，以及第 3.4 節這些終端所吻合的實測 RTT 與吞吐量基線。
Related pages: LeoCC moves detection to a millisecond-scale probe on the user’s device. SaTCP predicts handovers in emulation. Tanveer et al. first reports periodic regimes, and Kassem et al. measures unused capacity. Fries et al. studies application effects, while Mohan et al. supplies global measurements.同組導讀：LeoCC 是把偵測移到使用者裝置上毫秒級探測的後繼者，SaTCP 是在模擬中預測換手的前身，Tanveer 等人最早報告 15 秒區段，Kassem 等人最早量得閒置容量，Fries 等人從應用層看同樣的邊界，Mohan 等人則是全球量測。

Key numbers關鍵數字

Number	數字	Meaning (setup)
10–65 Mbps	Maximum link capacity swing within three minutes in one live trace ^{[56, §3.1]}	一段實地軌跡中三分鐘內最大鏈路容量的擺盪^{[56, §3.1]}
32/187 · 30/357 Mbps	Average up/down capacity, New Jersey · Madrid, RTT 59 and 27 ms ^{[56, §3.1]}	平均上/下行容量，新澤西 · 馬德里，RTT 59 與 27 ms^{[56, §3.1]}
9 CCAs	Reno, CUBIC, Vegas, Copa, BBRv1, BBRv3, PCC-VIVACE, Sprout, Verus, >30 two-minute live tests each ^{[56, §3]}	Reno、CUBIC、Vegas、Copa、BBRv1、BBRv3、PCC-VIVACE、Sprout、Verus，每種 >30 次兩分鐘實地測試^{[56, §3]}
≈ 20% / 6.84 Mbps	Copa utilisation and average throughput on live Starlink ^{[56, §3.3, Fig. 4]}	Copa 在實際 Starlink 上的利用率與平均吞吐量^{[56, §3.3, Fig. 4]}
< 65%	BBRv3 utilisation under lossy links ^{[56, §3.3]}	BBRv3 在有遺失鏈路下的利用率^{[56, §3.3]}
:12 / :27 / :42 / :57	Seconds of each minute at which global reconfigurations occur ^{[56, §4]}	每分鐘發生全域重組的秒數^{[56, §4]}
>80% · ~20% · ~90%	Reconfigurations changing capacity by >10 Mbps · by ≥40 Mbps · out-of-window changes below 5 Mbps, one month ^{[56, Fig. 7]}	使容量變化 >10 Mbps 的重組 · ≥40 Mbps 的重組 · 窗口外低於 5 Mbps 的變化，一個月^{[56, Fig. 7]}
60.30 → 42.11 ms	Reconfiguration-aware BBRv1 average RTT (−30.2%), p95 97.95 → 78.30 ms, Mahimahi replay ^{[56, Tab. 1]}	重組感知 BBRv1 的平均 RTT（−30.2%），p95 97.95 → 78.30 ms，Mahimahi 重播^{[56, Tab. 1]}
6.84 → 11.93 Mbps	Reconfiguration-aware Copa throughput (+74.4%), RTT 34.30 → 34.54 ms, replay ^{[56, Tab. 1]}	重組感知 Copa 的吞吐量（+74.4%），RTT 34.30 → 34.54 ms，重播^{[56, Tab. 1]}