Digest · Transport and congestion control · read after Chapter 6
導讀 · 傳輸層與壅塞控制 · 第 6 章後閱讀
SaTCP: Link-Layer Informed TCP Adaptation for Highly Dynamic LEO Satellite NetworksSaTCP：以鏈路層資訊調適 TCP，面向高度動態的 LEO 衛星網路
This digest explains how predicted handover windows let SaTCP retain its congestion window. It also examines the resulting throughput gain and the loss of fairness toward a competing CUBIC flow.讀完後，你能說明一個被告知下一次換手何時發生的傳送端，如何略過換手原本會觸發的視窗縮減、為什麼這讓模擬的 CUBIC 流從 34.3 Mbps 升到 138.1 Mbps，以及為什麼同一個機制會餓死共享鏈路的原版 CUBIC 流。
Main result
主要結果
SaTCP uses predicted handovers to retain CUBIC’s congestion window during disruption. Emulated throughput improves, while a competing unmodified flow loses much of its share.
SaTCP 依預測換手，在擾動期間保留 CUBIC 壅塞視窗，模擬吞吐量因而提高，共用鏈路的原版流則失去大部分份額。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | SaTCP is the first LEO-aware congestion controller. |
| Latency comparison | 90% · 0.6 s · 2 · 0.1 s | The terminal and nearby ground station predict handovers from public orbit data, then inform the host. About 90% of report-timing errors fall within ±0.6 s. The host’s CUBIC sender suspends window reductions for 2·Terr + RTOmin + 0.1 s around the predicted handover. It treats the associated RTT surge and loss burst as handover effects [67, §V-B–V-D]. |
| Capacity and rate | 1 · 72×22 · 550 km · 150 Mb/s · 15 · 1,000 · 34.3 · 138.1 · 4.03 · 136.7 · 91.7–92.1% | LeoEM models Starlink Shell 1 with Mininet. The setup uses 72×22 satellites at 550 km, +Grid links, and a 150 Mb/s link cap. It applies a 15-second handoff interval and a 1,000-packet queue. On the San Diego–New York bent-pipe path, throughput rose from CUBIC’s 34.3 Mbps to SaTCP’s 138.1 Mbps. This 4.03× gain approached BBR’s 136.7 Mbps. SaTCP prevented 91.7–92.1% of undesired window reductions [67, §VI-B, Table I]. |
| Cost assumptions | 8.4 | The longest inhibition window reduced a competing CUBIC flow to 8.4 Mbps, which shows the fairness cost in this emulated evaluation [67, Table II]. |
| Evidence and scope | Qualitative scope | When LeoCC's authors later ran SaTCP on live Starlink with their own reconfiguration detector, it behaved much like CUBIC [74, §6.2]. |
| 證據與範圍 | 定性範圍 | SaTCP 是第一個 LEO 感知的壅塞控制器。 |
| 延遲比較 | 90% · 0.6 s · 2 · 0.1 s | 用戶終端與附近的地面站利用公開軌道資料預測衛星換手，約 90% 的回報時間誤差落在 ±0.6 s 之內，再通知使用者的主機，主機上的 CUBIC 傳送端於是在預測時刻附近暫停視窗縮減 2·Terr + RTOmin + 0.1 s，使換手造成的 RTT 暴增與遺失突發被視為換手效應[67, §V-B–V-D]。 |
| 容量與速率 | 1 · 550 km · 72×22 · 150 Mb/s · 15 · 1,000 · 34.3 · 138.1 · 4.03 · 136.7 · 91.7–92.1% | 在作者以 Mininet 打造、模擬 Starlink Shell 1（550 km 的 72×22、+Grid、150 Mb/s 鏈路上限、15 秒換手間隔、1,000 封包佇列）的 LeoEM 上，聖地牙哥到紐約的彎管流從 CUBIC 的 34.3 Mbps 升到 SaTCP 的 138.1 Mbps，4.03 倍的增益與 BBR 的 136.7 Mbps 相當，並且防止了 91.7–92.1% 的誤觸發縮減[67, §VI-B, Table I]。 |
| 證據與範圍 | 8.4 | 代價是公平性，因為在最長的抑制窗口下 SaTCP 把競爭的 CUBIC 流壓到 8.4 Mbps[67, Table II]，而整個評估都是模擬。 |
| 證據與範圍 | 定性範圍 | 後來 LeoCC 的作者以自己的重組偵測器驅動 SaTCP 在實際 Starlink 上執行時，它的表現與 CUBIC 相近[74, §6.2]。 |
1. Where this paper sits1. 這篇論文的位置
SaTCP turns measurements of unused capacity into a sender-side mechanism. Its LeoEM path emulator later supports independent transport comparisons.
SaTCP 將剩餘容量的量測轉化為傳送端機制，其 LeoEM 路徑模擬平台後來也支援獨立的傳輸比較。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Latency comparison | 2022 · 1.56% | The 2022 measurements showed spare capacity under Starlink’s transport protocols. Kassem et al. reported BBR throughput near half of UDP capacity. Michel et al. measured 1.56% loss under load. Hypatia simulations also showed that loss and delay can give misleading congestion signals in a moving network. |
| Orbital configuration | Qualitative scope | SaTCP is the first paper to turn that diagnosis into a sender-side fix. It does so in the most direct way possible by predicting the disturbance from orbit geometry and telling the sender to ignore it. |
| Evidence and scope | 15 · 6 | LeoEM became a test platform for later work. Mazilu et al. used it to compare CUBIC, SaTCP, BBRv3, and LeoCC. Within the supplied fact base, LeoEM alone models the 15-second handoff interval from Starlink’s filings, as Chapter 6 describes. |
| Evidence and scope | 57 | Part C item 57). |
| Evidence and scope | Qualitative scope | The paper therefore sits at the hinge between the measurement era and the mechanism era of LEO transport research. |
| 證據與範圍 | 2022 · 1.56% | 到 2022 年，量測論文已經顯示 Starlink 的傳送端會留下剩餘容量，Kassem 等人回報 BBR 只達 UDP 容量的一半左右，Michel 等人在負載下量到 1.56% 的遺失，而 Hypatia 早已在模擬中論證遺失與延遲在移動網路上都是糟糕的壅塞訊號。 |
| 證據與範圍 | 定性範圍 | SaTCP 是第一篇把這個診斷變成傳送端修正的論文，而且採取最直接的做法，從軌道幾何預測擾動並告訴傳送端忽略它。 |
| 證據與範圍 | 15 · 6 | 它的第二項貢獻比第一項更長壽，因為為了評估 SaTCP 而寫的 LeoEM 模擬平台成了事實上的開放測試床，Mazilu 等人後來正是在它上面把 CUBIC、SaTCP、BBRv3 與 LeoCC 正面比較，而且它至今仍是事實庫中唯一模擬 Starlink 申請文件所描述的 15 秒換手間隔的平台（事實庫第 6 章。 |
| 證據與範圍 | 57 | Part C 第 57 項）。 |
| 證據與範圍 | 定性範圍 | 這篇論文因此坐落在 LEO 傳輸研究從量測時代轉向機制時代的樞紐上。 |
2. The problem, measured2. 問題，用量測說話
Hard handovers interrupt access, while intermediate handovers alter routes and can discard in-flight packets. CUBIC’s recovery time determines how strongly repeated disruptions reduce throughput.
硬換手會中斷接入，中間換手則改變路由，可能丟失在途封包。CUBIC 的恢復時間決定了反覆擾動對吞吐量的影響。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Latency comparison | Qualitative scope | The paper examines how TCP treats handover events. TCP interprets the associated RTT surge and loss as congestion [67, §I]. |
| Evidence and scope | Qualitative scope | The authors quantify the damage in two ways. |
| Evidence and scope | 139 · 300 · 28.8 | A rooftop terminal in San Diego received a CUBIC download from an AWS server in Oregon. Its speed test reported 139 Mbps. The 300-second transfer averaged 28.8 Mbps. |
| Evidence and scope | Qualitative scope | with throughput falling at each uptime dip that marks a handover [67, §III-C, Fig. 1] |
| Capacity and rate | 22.9% · 150 Mb/s · 30.0% | In LeoEM’s bent-pipe tests, CUBIC used 22.9% of the 150 Mb/s link on San Diego–New York. It used 30.0% on Seattle–New York [67, §VI-B, Table I]. |
| Evidence and scope | 6 | The mechanism is the familiar one from Chapter 6. |
| Latency comparison | 1.5 | A hard end handover disconnects the old ingress satellite before the terminal attaches to the next. The interruption lasts about 1.5 RTTold + 1.5 RTTnew. |
| Evidence and scope | Qualitative scope | while an intermediate (soft) handover at a gateway moves traffic to a new route and can still lose packets on the dismantled old one |
| Evidence and scope | 15 | and in both cases CUBIC cuts its window and needs many RTTs to climb back, only to meet the next handover 15 seconds later [67, §III-B, §IV]. |
| Capacity and rate | 138.9 · 92.6% | On the short San Diego–Seattle path the problem largely disappears, with CUBIC already at 138.9 Mbps or 92.6% of the link. This occurs because a path with fewer links breaks rarely enough for the window to regain full rate before the next disruption [67, §VI-B, Table I]. |
| 延遲比較 | 定性範圍 | 論文開頭就指出 TCP 缺少衛星換手資訊，會把隨之而來的 RTT 暴增與遺失誤讀為壅塞的徵兆[67, §I]。 |
| 證據與範圍 | 定性範圍 | 作者以兩種方式量化損害。 |
| 證據與範圍 | 139 · 300 · 28.8 | 在聖地牙哥一棟大樓屋頂上的真實 Starlink 天線，接收來自俄勒岡 AWS 伺服器的 CUBIC 下載，天線的速度測試回報 139 Mbps，而 300 秒的傳輸平均只有 28.8 Mbps，吞吐量在每個代表換手的連線中斷處下跌[67, §III-C, Fig. 1]。 |
| 容量與速率 | 150 Mb/s · 22.9% · 30.0% | 在 LeoEM 模擬的長距彎管路徑上，CUBIC 在聖地牙哥到紐約只達 150 Mb/s 鏈路的 22.9%，西雅圖到紐約則是 30.0%[67, §VI-B, Table I]。 |
| 證據與範圍 | 6 | 機制正是第 6 章熟悉的那一個。 |
| 延遲比較 | 1.5 | 末端（硬）換手讓終端先離開入口衛星再連上下一顆，使鏈路中斷約 1.5 個到舊衛星的 RTT 再加 1.5 個到新衛星的 RTT。 |
| 證據與範圍 | 定性範圍 | 中間（軟）換手則在閘道把流量移到新路由，被拆除的舊路由上仍可能遺失封包。 |
| 延遲比較 | 15 | 兩種情況下 CUBIC 都會縮減視窗，然後需要許多個 RTT 才能爬回來，卻在 15 秒後又遇到下一次換手[67, §III-B, §IV]。 |
| 證據與範圍 | 138.9 · 92.6% | 在聖地牙哥到西雅圖的短路徑上問題幾乎消失，CUBIC 已達 138.9 Mbps 即鏈路的 92.6%，因為鏈路較少的路徑斷鏈夠少，視窗能在下一次中斷前回到滿速[67, §VI-B, Table I]。 |
3. The design3. 設計
Terminals and ground infrastructure predict disruptions and report them to the host. A kernel flag temporarily changes CUBIC’s response to loss and timeout, then restores its default behavior.
終端與地面設施預測擾動並回報主機，核心旗標暫時改變 CUBIC 對遺失及逾時的反應，再恢復預設行為。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | SaTCP uses standard CUBIC outside a predicted handover window. It relies on predictable satellite positions and event times derived from those positions. Prediction error determines the window margin [67, §V-A]. |
| Evidence and scope | Qualitative scope | The user terminal |
| Evidence and scope | Qualitative scope | which takes part in its own end handovers, reports each one to the user's host at t − LUT |
| Evidence and scope | Qualitative scope | while the nearby ground station |
| Evidence and scope | Qualitative scope | The ground-station service caches satellite positions and receives the host’s TCP destinations. It reports intermediate handovers at t − LGS − Terr. LUT and LGS represent terminal-to-host and ground-station-to-host latency. The TT&C system supplies the prediction-error margin Terr [67, §V-C, Fig. 6]. |
| Dataset and workload | 1,605 · 90% · 0.6 s | Public TLE sets refresh every three hours. The authors predicted 1,605 satellite positions three hours ahead from one snapshot. About 90% of report-timing errors fell within ±0.6 s. They treat this result as an upper error bound because operator TT&C data have greater precision [67, §V-B, Fig. 4]. |
| Evidence and scope | Qualitative scope | When a report arrives, a relay program on the host sets a flag in the kernel over netlink |
| Reliability and accuracy | Qualitative scope | The Linux CUBIC sender makes two changes. After loss, it reduces CUBIC’s K to one ninth of its previous value. |
| Evidence and scope | Qualitative scope | so the reduction is skipped while keeping the window below the terminal's ingress queue |
| Evidence and scope | Qualitative scope | and a retransmission timeout retains the window [67, §V-D, Alg. 1]. |
| Reliability and accuracy | 2 · 0.1 s | The inhibition period is 2·Terr + RTOmin + 0.1 s. It covers timing error in either direction, the sender’s loss reaction time RTOmin, and a 0.1 s buffer [67, §V-B–V-C, Fig. 5]. |
| Evidence and scope | Qualitative scope | The sender resumes standard TCP behavior after the window. Deployment keeps the existing forwarding path. It requires terminal software, ground-station and TT&C services, and a host operating-system patch [67, §V-A, §V-C]. |
| 證據與範圍 | 定性範圍 | SaTCP 除了在預測的換手窗口內之外，完全保留 CUBIC，並建立在 LEO 網路的兩項性質上：衛星位置可預測但仍有預測誤差，而擾動事件發生的時刻可以由位置算出[67, §V-A]。 |
| 證據與範圍 | 定性範圍 | 用戶終端親自參與自己的末端換手，於是在 t − LUT 時刻向使用者主機回報。 |
| 證據與範圍 | 定性範圍 | 附近的地面站快取星座位置，並得知主機上 TCP 連線的目的地，於是在 t − LGS − Terr 回報這些路徑上的中間換手，其中 LUT 與 LGS 是終端與地面站到主機的延遲，Terr 是由 TT&C 系統算出的預測誤差邊界[67, §V-C, Fig. 6]。 |
| 資料集與工作負載 | 定性範圍 | 預測來自每三小時更新一次的公開 TLE。 |
| 資料集與工作負載 | 1,605 · 90% · 0.6 s | 以一份 TLE 快照預測 1,605 顆衛星三小時後的位置時，約 90% 的回報時間誤差落在 ±0.6 s 內，作者把它視為上限，因為營運商的 TT&C 擁有更精細的軌道資料[67, §V-B, Fig. 4]。 |
| 證據與範圍 | 定性範圍 | 回報抵達時，主機上的轉送程式經由 netlink 在核心中設定旗標，Linux CUBIC 傳送端有兩處改變：遇到遺失時，CUBIC 的 K 被縮為原值的九分之一，一般 CUBIC 則會歸零，使縮減被略過同時將視窗維持在終端的入口佇列。 |
| 證據與範圍 | 定性範圍 | 重傳逾時也會保留視窗[67, §V-D, Alg. 1]。 |
| 證據與範圍 | 2 · 0.1 s | 抑制持續 2·Terr + RTOmin + 0.1 s，涵蓋最多早或晚 Terr 的回報、傳送端對遺失做出反應所需的時間（以 RTOmin 代表），以及 0.1 s 的緩衝[67, §V-B–V-C, Fig. 5]。 |
| 證據與範圍 | 定性範圍 | 窗口結束後傳送端回到預設的 TCP 行為，因此這個設計沿用現有網路轉送路徑，並需要終端的軟體更新、地面站與 TT&C 的輔助服務，以及主機作業系統的修補[67, §V-A, §V-C]。 |
Original figure note原始圖說出處
Drawn for this primer from Cao & Zhang, INFOCOM 2023 (conference paper), §III-B, §V-B–V-D, Figs. 4–5 and Table I.4. Evaluation setup4. 實驗設定
LeoEM precomputes a route and updates Mininet link properties along it. The experiment controls handover timing, link caps and queue size to isolate transport dynamics.
LeoEM 預先計算路徑，再更新沿途 Mininet 鏈路性質。實驗控制換手時序、鏈路上限與佇列大小，以觀察傳輸動態。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | Every result is emulation on LeoEM |
| Evidence and scope | Qualitative scope | LeoEM construction has three stages. It calculates satellite positions over one orbital period. It then calculates routes at each sample time, using ground-station bent pipes or ISLs. |
| Path-emulator implementation | Qualitative scope | Mininet switching nodes represent satellites, ground stations, and terminals. Their link properties follow the precomputed routes, which allows execution on a commodity laptop [67, §IV, §VI-A]. |
| Orbital configuration | 1 · 2019 · 72 · 22 · 550 km · 53° · 580 km | The model uses Starlink Shell 1 from SpaceX’s 2019 filing: 72 planes with 22 satellites each, at 550 km and 53°. Coverage radius is 580 km. Each satellite has four +Grid laser links. Routing uses shortest paths, and ground-station locations come from a live Starlink coverage map [67, §III-C, §IV, §VI-A]. |
| Evidence and scope | 15 | Terminals refresh their ingress satellite every 15 seconds, which the paper attributes to Starlink's FCC filing, by picking the nearest satellite. |
| Latency comparison | 1.5 | An end handover interrupts the link for 1.5 RTT to each of the old and new ingress satellites. Route comparisons identify intermediate handovers. LeoEM switches the affected interfaces off and on to reproduce these events [67, §IV]. |
| Capacity and rate | 150 Mb/s · 100–200 Mb/s · 1,000 · 5 · 260 ms | The tc configuration caps each link at 150 Mb/s, within Starlink’s advertised 100–200 Mb/s range. It keeps the default 1,000-packet queue. A 5 KB iPerf payload gives about 260 ms of buffering. In this setup, path dismantlement causes loss while the queue absorbs traffic [67, §VI-A]. |
| Evidence and scope | 20.04 · 5.4 · 143 · 0 · 0.3 · 0.5 · 1 s · 0.2 s · 0.9 · 1.3 · 2.3 s | Hosts run Ubuntu 20.04 and kernel 5.4.143. Timing errors follow the measured distribution. Terr values are 0, 0.3, 0.5, and 1 s, with RTOmin fixed at 0.2 s. These settings give freeze windows of 0.3, 0.9, 1.3, and 2.3 s. Each test covers one orbital period [67, §VI-A–B]. |
| Evidence and scope | Qualitative scope | The six city pairs are San Diego–New York, Seattle–New York, San Diego–Seattle, San Diego–Shanghai, New York–London, and Seattle–Buenos Aires. All pairs use ISLs. The first three also use bent pipes. CUBIC and BBR provide the baselines, and fairness tests use two simultaneous flows [67, §VI-A–B, Tables I–II]. |
| Evidence and scope | 7 | LeoEM emulates one precomputed path at a time, within Chapter 7’s path-emulator category. StarryNet emulates a constellation. LeoEM’s smaller scope supports laptop execution and later congestion-control studies. |
| 證據與範圍 | 定性範圍 | 所有結果都是在 LeoEM 上的模擬，論文分三個階段建構它：先產生一個殼層中每顆衛星在一個軌道週期內的位置，再在每個取樣時刻以經由地面站的彎管跳躍或 ISL 計算來源到目的地的路由，最後把衛星、地面站與終端實例化為 Mininet 交換節點，依預先算好的路由更新鏈路性質，全部在一台普通筆電上執行[67, §IV, §VI-A]。 |
| 軌道配置 | 2019 · 1 · 550 km · 53° · 72 · 22 · 580 km | 星座是 SpaceX 2019 年申請文件中的 Starlink Shell 1，即 550 km、53° 的 72 個軌道面各 22 顆衛星、覆蓋半徑 580 km，每顆衛星有四條 +Grid 雷射鏈路，採用傳統最短路徑路由，地面站位置取自即時的 Starlink 覆蓋地圖[67, §III-C, §IV, §VI-A]。 |
| 證據與範圍 | 15 | 終端每 15 秒選擇最近的衛星更新入口衛星，論文把這個間隔歸於 Starlink 的 FCC 申請文件。 |
| 延遲比較 | 1.5 | 末端換手會拆除鏈路 1.5 個到舊入口衛星的 RTT 加 1.5 個到新衛星的 RTT，而比較相鄰時刻路由所找出的中間換手，則以關閉再開啟受影響節點的網路介面來產生[67, §IV]。 |
| 容量與速率 | 150 Mb/s · 100–200 Mb/s · 1,000 · 5 · 260 ms | 所有模擬鏈路都以 tc 限制在 150 Mb/s 以對應 Starlink 宣稱的 100–200 Mb/s，並保留 tc 預設的 1,000 封包佇列，配合 5 KB 的 iPerf 酬載可緩衝約 260 ms，使遺失來自路徑拆除，佇列仍有餘裕[67, §VI-A]。 |
| 證據與範圍 | 20.04 · 5.4 · 143 · 0 · 0.3 · 0.5 · 1 s · 0.2 s · 0.9 · 1.3 · 2.3 s | 測試主機執行 Ubuntu 20.04、核心 5.4.143，回報時間誤差依量得的誤差分布隨機注入，Terr 設為 0、0.3、0.5 與 1 s，RTOmin 固定為 0.2 s，得到 0.3、0.9、1.3 與 2.3 s 的凍結窗口，每次執行涵蓋一整個軌道週期[67, §VI-A–B]。 |
| 證據與範圍 | 定性範圍 | 測試了六組城市：聖地牙哥–紐約、西雅圖–紐約、聖地牙哥–西雅圖、聖地牙哥–上海、紐約–倫敦與西雅圖–布宜諾斯艾利斯，全部走 ISL，前三組也走彎管。 |
| 證據與範圍 | 定性範圍 | 基準只有 CUBIC 與 BBR，公平性研究一次跑兩條流[67, §VI-A–B, Tables I–II]。 |
| 證據與範圍 | 7 | 由於 LeoEM 一次只模擬一條預先算好的路徑，它是第 7 章意義下的路徑模擬器，StarryNet 則是星座模擬器，這正是它輕到能在筆電上跑、也因此吸引後續壅塞控制研究的原因。 |
| Question | 問題 | Formula | 公式 | Result | 結果 |
|---|---|---|---|---|---|
| How long does a full 1,000-packet LeoEM queue take to drain at the 150 Mb/s cap with the paper's 5 KB iPerf payloads?以論文的 5 KB iPerf 酬載計，滿載的 1,000 封包 LeoEM 佇列在 150 Mb/s 上限下要多久排空？ | \( t = \dfrac{1{,}000 \times 5{,}000 \times 8}{150 \times 10^{6}} \) | ≈ 267 ms Calculated with Section VI-A’s 1,000-packet queue, 5 KB payload, and 150 Mb/s rate. Taking 5 KB as 5,000 bytes gives about 260 ms buffering. This duration exceeds the modeled handover outages and agrees with the paper’s statement.計算值。1,000 封包佇列、5 KB 酬載（以 5,000 位元組計）與 150 Mb/s 取自 §VI-A，與論文所說交換節點可緩衝達 260 ms、遠長於任何換手中斷的說法一致。 |
5. What was measured5. 量到了什麼
| Claim宣稱 | Setup and caveat設定與附註 |
|---|---|
| San Diego–New York bent-pipe throughput: CUBIC gives 34.3 Mbps, while BBR gives 136.7 Mbps, a 3.98× ratio. Across four inhibition settings, SaTCP gives 59.8, 123.4, 138.1, and 139.4 Mbps. The paper highlights a 4.03× gain [67, Table I].聖地牙哥–紐約彎管：CUBIC 34.3 Mbps、BBR 136.7 Mbps（3.98 倍）、SaTCP 在四種抑制窗口設定下 59.8 / 123.4 / 138.1 / 139.4 Mbps，最佳 4.03 倍[67, Table I] | LeoEM, 150 Mb/s cap, 15-s hard handovers. Longer windows give more throughput and less fairnessLeoEM，150 Mb/s 上限，15 秒硬換手。窗口越長吞吐量越高、公平性越差 |
| Seattle–New York: CUBIC 45.1, BBR 137.6 (3.05×), SaTCP 135.0 Mbps (2.99×). San Diego–Seattle CUBIC already 138.9 Mbps (92.6%)西雅圖–紐約：CUBIC 45.1、BBR 137.6（3.05 倍）、SaTCP 135.0 Mbps（2.99 倍）。聖地牙哥–西雅圖 CUBIC 已達 138.9 Mbps（92.6%） | Gain depends on path RTT. Short paths recover between handovers on their own增益取決於路徑 RTT。短路徑自己就能在兩次換手之間恢復 |
| ISL path New York–London: CUBIC 128.5, BBR 131.0, SaTCP 140.4 Mbps (1.09×). SaTCP 2.34× BBR and 1.22× CUBIC during transient periods [67, §VI-B]ISL 路徑紐約–倫敦：CUBIC 128.5、BBR 131.0、SaTCP 140.4 Mbps（1.09 倍）。過渡期 SaTCP 為 BBR 的 2.34 倍、CUBIC 的 1.22 倍[67, §VI-B] | +Grid 4-ISL topology at 150 Mb/s per link, an emulator setting. CUBIC already >135 Mbps on ISL paths+Grid 四 ISL 拓樸、每鏈路 150 Mb/s，其定位是模擬輸入。ISL 路徑上 CUBIC 已 >135 Mbps |
| 91.7% (SD–NY) and 92.1% (SEA–NY) of undesired cwnd reductions prevented [67, §VI-B]防止了 91.7%（SD–NY）與 92.1%（SEA–NY）的誤觸發 cwnd 縮減[67, §VI-B] | Counted against emulator ground truth of handover times以模擬器的換手時刻真值計數 |
| Fairness: two SaTCP flows 47.9/50.0 Mbps at 0.3 s and 68.2/70.1 at 2.3 s. SaTCP vs CUBIC 111.9 vs 17.2 Mbps at 0.9 s and 131.3 vs 8.4 Mbps at 2.3 s [67, Table II]公平性：兩條 SaTCP 流在 0.3 s 設定下 47.9/50.0 Mbps、2.3 s 下 68.2/70.1。SaTCP 對 CUBIC 在 0.9 s 下 111.9 對 17.2 Mbps、2.3 s 下 131.3 對 8.4 Mbps[67, Table II] | Two flows on SD–NY bent pipe only. The authors call CUBIC's 8.4 Mbps decent because CUBIC alone reaches only 34.3 Mbps on this path, yet SaTCP still takes most of the link僅在 SD–NY 彎管上跑兩條流。作者認為 CUBIC 的 8.4 Mbps 尚可，因為 CUBIC 單獨在此路徑上也只有 34.3 Mbps，但 SaTCP 仍佔走鏈路的大部分 |
| Independent LeoEM evaluation on Seattle–New York gives normalized goodput of 94.4 for SaTCP and 49.0 for CUBIC. Delay inflation is 2.30× for SaTCP and 2.14× for CUBIC. Both show RTT unfairness, with a goodput ratio near 0.5 preprint.獨立 LeoEM 評估：西雅圖–紐約 SaTCP 正規化 goodput 94.4 對 CUBIC 49.0，延遲膨脹 2.30 倍對 CUBIC 的 2.14 倍，RTT 公平性較低、goodput 比約 0.5 preprint | Mazilu et al., arXiv 2510.25498, 1,650 experiments. Confirms the throughput gain and adds a delay costMazilu 等人，arXiv 2510.25498，1,650 次實驗。證實吞吐量增益並揭示延遲代價 |
| Live Starlink, with SaTCP driven by LeoCC's reconfiguration detector: SaTCP performs similarly to CUBIC and stays at low throughput on every tested path [74, §6.2, Figs. 10–11]實際 Starlink，以 LeoCC 的重組偵測器驅動 SaTCP：SaTCP 的表現與 CUBIC 相近，在每條測試路徑上吞吐量都低[74, §6.2, Figs. 10–11] | Lai et al., SIGCOMM 2025. Random loss between handovers still triggers reductions, and the TLE-based predictions of the original design were awaiting access on real StarlinkLai 等人，SIGCOMM 2025。換手之間的隨機遺失仍會觸發縮減，而原設計以 TLE 為基礎的預測在真實 Starlink 上取得仍待完成 |
6. Limits and open questions6. 範圍與待解問題
- Emulated evaluation and a fixed constellation model. Live observations comprise the motivating 300-second CUBIC download and a 200-second San Diego–Ohio RTT trace [67, §III-C, §VI-A, Figs. 1, 7]. The conclusion proposes routing with less frequent updates as future work [67, §VII]. Later, LeoCC authors tested SaTCP on three live Starlink terminals with their own reconfiguration detector. SaTCP performed similarly to CUBIC because random loss within each interval still reduced its window [74, §6.1–6.2]. LeoEM models four +Grid ISLs per satellite in the 72×22 filing. Actual Starlink satellites have three laser terminals, with topology details held by the operator (factbase Part C, items 13 and 55). Laser acquisition and setup delay remain outside the model (item 56).僅有模擬，且星座是凍結的。除了作為動機的 300 秒 CUBIC 下載與一段從聖地牙哥到俄亥俄的 200 秒 RTT 軌跡之外，實際 Starlink 上的測試仍待完成[67, §III-C, §VI-A, Figs. 1, 7]，結論把更新頻率較低的路由策略，實地測試則待完成列為下一步[67, §VII]。後來 LeoCC 的作者在三台實際 Starlink 終端上執行 SaTCP，用自己的重組偵測器驅動其凍結邏輯，結果它的表現與 CUBIC 相近，因為每個區間內的隨機遺失仍會觸發縮減[74, §6.1–6.2]。LeoEM 假設 72×22 申請文件下每顆衛星有四個 +Grid ISL，而目前的 Starlink 衛星配備三個雷射終端、拓樸待公開（事實庫 Part C 第 13、55 項），雷射擷取與建鏈延遲列於模擬範圍之外（第 56 項）。
- The 150 Mb/s cap is an emulator link-cap setting. It is a tc setting applied to every link including ISLs. Thus, the ISL-path results describe dynamics rather than capacity, in line with factbase Part C item 60 on simulator link rates. The absolute Mbps figures require separate interpretation from measured Starlink throughput.150 Mb/s 上限是模擬輸入。它是套在包含 ISL 在內每條鏈路上的 tc 設定，因此 ISL 路徑的結果描述了所設容量下的動態，呼應事實庫 Part C 第 60 項對模擬器鏈路速率的提醒。絕對 Mbps 數字應以動態模型結果解讀，實測 Starlink 吞吐量另行比較。
- Two baselines and two flows. The study compares CUBIC and BBR, with two flows in its fairness tests. At the 2.3 s setting, the competing CUBIC flow falls to 8.4 Mbps. This result establishes a fairness problem within that configuration. Garcia et al.’s later shared-queue measurements motivate broader tests of competing traffic.兩個基準、兩條流。只比較了 CUBIC 與 BBR，公平性只用兩條流測試，因此在 2.3 s 設定下把 CUBIC 餓到 8.4 Mbps，只是共享下行佇列中傷害的下限，而 Garcia 等人後來發現這個佇列採用共享 FIFO 排程。
- Coordination across operator systems. The terminal, ground station, TT&C system, and host kernel exchange timing messages. Public TLE predictions refresh every three hours [67, §V-B–V-C]. LeoCC later used 10 ms ICMP probes from the user’s device to the point of presence. This approach places detection on the user’s device and retains a local software requirement [74, §4.1.1, §5.1].它需要基礎設施供應者掌控的基礎設施。終端、地面站、TT&C 系統與主機核心都必須參與並交換時間訊息，而預測依賴每三小時更新的公開 TLE[67, §V-B–V-C]。LeoCC 後來以使用者裝置每 10 ms 向網路接入點送出的 ICMP 探測取代這一串環節，把終端與地面站移出迴路，但仍需要使用者端的軟體[74, §4.1.1, §5.1]。
- The emulator is generous to SaTCP. Reports are generated from the emulator's own handover times with only the TLE-derived timing error added. The 150 Mb/s cap with a queue of about 260 ms is chosen so that loss comes from handovers rather than queue overflow [67, §VI-A]. Real Starlink adds random loss of 0.5–6% inside each interval, which is where LeoCC's live test found SaTCP falling back to CUBIC-like throughput [74, §2.1, §6.2].模擬平台對 SaTCP 有利。回報是由模擬器自己的換手時刻產生，只加上由 TLE 推得的時間誤差，而 150 Mb/s 上限與約 260 ms 的佇列是刻意選來讓換手成為遺失來源，同時保留佇列容量餘裕[67, §VI-A]。實際 Starlink 在每個區間內還有 0.5–6% 的隨機遺失，LeoCC 的實地測試正是在這裡發現 SaTCP 退回類似 CUBIC 的吞吐量[74, §2.1, §6.2]。
- Independent evaluation adds a delay cost. Mazilu et al. reproduce SaTCP’s throughput gain on LeoEM. They report single-flow delay inflation of 2.30× for SaTCP and 2.14× for CUBIC, with RTT unfairness in both protocols. These preprint results extend the original evaluation’s two metrics.獨立評估揭示延遲代價。Mazilu 等人在 LeoEM 上重現了吞吐量增益，卻量到 SaTCP 單流延遲膨脹 2.30 倍、CUBIC 2.14 倍，且兩者都對 RTT 公平性較低 preprint，這是原先兩項指標評估之外的發現。
7. How it connects7. 與其他內容的關聯
- Section 6.3: reconfiguration-aware congestion control, where the 34.3 → 138.1 Mbps result and the freeze-window timeline are introduced.第 6.3 節：重組感知的壅塞控制，34.3 → 138.1 Mbps 的結果與凍結窗口時間線在此引入。
- Section 6.4: fairness and the cost of being clever, built on Table II.第 6.4 節：公平性與聰明的代價，建立在 Table II 之上。
- Section 6.1 and Section 6.6: what the sender sees, and the open question of transport across ISLs that LeoEM's 150 Mb/s +Grid leaves open.第 6.1 節與第 6.6 節：傳送端看到什麼，以及 LeoEM 的 150 Mb/s +Grid 之外仍待研究的跨 ISL 傳輸問題。
- Section 3.5: the 15-second schedule that LeoEM bakes in, and Section 3.4 for the measured baseline it tries to improve on. Section 7.4 places LeoEM among the emulators.第 3.5 節：LeoEM 內建的 15 秒排程，以及第 3.4 節它想改善的實測基線。第 7.4 節把 LeoEM 放進模擬平台的版圖。
- Related digests connect these results: Kassem et al. describes spare capacity, while Lai et al. [56] and LeoCC examine detection on the user’s device. Garcia et al. studies the live queue. Hypatia explains how loss and delay can mislead congestion control in simulation.同組導讀：Kassem 等人談剩餘容量的症狀，Lai 等人[56]與 LeoCC 談由裝置端執行、在使用者裝置上的偵測，Garcia 等人談真實的佇列，Hypatia 則給出遺失與延遲會誤導的模擬論證。
Key numbers關鍵數字
| Number | 數字 | Meaning (setup) | 意義（設定） |
|---|---|---|---|
| 34.3 → 138.1 Mbps | CUBIC → SaTCP, San Diego–New York bent pipe on LeoEM, 4.03×. BBR 136.7 Mbps [67, Table I] | CUBIC → SaTCP，LeoEM 上聖地牙哥–紐約彎管，4.03 倍。BBR 136.7 Mbps[67, Table I] | |
| 1.74× / 3.60× / 4.03× / 4.06× | SaTCP over CUBIC on SD–NY bent pipe with 0.3 / 0.9 / 1.3 / 2.3 s freeze windows [67, Table I] | SD–NY 彎管上 SaTCP 相對 CUBIC，凍結窗口 0.3 / 0.9 / 1.3 / 2.3 s[67, Table I] | |
| 22.9% / 30.0% | CUBIC utilisation of the 150 Mb/s link on SD–NY / SEA–NY [67, Table I] | CUBIC 在 SD–NY / SEA–NY 對 150 Mb/s 鏈路的利用率[67, Table I] | |
| 139 vs 28.8 Mbps | Real Starlink in San Diego, download from AWS Oregon: speed test vs 300-s CUBIC average [67, §III-C, Fig. 1] | 聖地牙哥真實 Starlink、自 AWS 俄勒岡下載：速度測試對 300 秒 CUBIC 平均[67, §III-C, Fig. 1] | |
| ±0.6 s | Bound containing ~90% of TLE handover-prediction errors, 1,605 satellites [67, Fig. 4] | 涵蓋約 90% TLE 換手預測誤差的界限，1,605 顆衛星[67, Fig. 4] | |
| 2·Terr + RTOmin + 0.1 s | Inhibition window during which CUBIC reductions are skipped (K cut to K/9) [67, §V-C–V-D] | 略過 CUBIC 縮減（K 縮為 K/9）的抑制窗口[67, §V-C–V-D] | |
| 91.7% / 92.1% | Undesired cwnd reductions prevented, SD–NY / SEA–NY [67, §VI-B] | 防止的誤觸發 cwnd 縮減，SD–NY / SEA–NY[67, §VI-B] | |
| 131.3 vs 8.4 Mbps | SaTCP vs competing CUBIC at the 2.3 s window setting [67, Table II] | 2.3 s 窗口設定下 SaTCP 對競爭 CUBIC[67, Table II] | |
| 72×22 · 150 Mb/s · 15 s · 1,000 pkts | LeoEM: Shell 1 geometry, link cap, handoff interval, per-link tc queue [67, §IV, §VI-A] | LeoEM：Shell 1 幾何、鏈路上限、換手間隔、每鏈路佇列[67, §IV, §VI-A] | |
| 94.4 / 49.0 | Mazilu et al. normalized goodput, SaTCP / CUBIC, SEA→NY on LeoEM preprint | Mazilu 等人的正規化 goodput，SaTCP / CUBIC，LeoEM 上 SEA→NY preprint |