Chapter 6 of 13 · Part II · The research

第 6 章（共 13 章）· 第二部 · 研究現況

Transport and congestion control over a moving network移動網路上的傳輸層與壅塞控制

This chapter explains how scheduled changes, drop-front queues and packet reordering mislead TCP congestion control on Starlink. You will calculate window and delay costs, interpret SaTCP, HotNets 2024 and LeoCC under their evaluation conditions, and examine RDMA’s assumptions for laser ISLs.本章說明排程變化、前端丟棄佇列與封包重排如何誤導 Starlink 上的 TCP 壅塞控制。你會計算視窗與延遲的代價，依評估條件解讀 SaTCP、HotNets 2024 與 LeoCC，並檢視 RDMA 在雷射星間鏈路上面臨的假設調整。

≈ 34 min · 2 panels · 8-question quiz≈ 34 分鐘 · 2 個面板 · 8 題測驗Jump to the quiz ↓跳到測驗 ↓

Before you start

開始之前

This chapter builds on Chapters 2 and 3 . The transport layer sees symptoms of the ground link. Chapter 3 supplies the relevant mechanisms: periodic reconfiguration, handover, bufferbloat and the drop-front queue. The final section also uses the propagation delay from Chapter 2.

本章建立在第 2 章與第 3 章之上。傳輸層看得到的只有地面鏈路的症狀，所以第 3 章的 15 秒重新配置週期、換手、緩衝膨脹與前端丟棄佇列是本章的詞彙，最後一節還會用到第 2 章的傳播延遲。

Reconfiguration interval重新配置週期3 Handover換手3 Bufferbloat緩衝膨脹3 Drop-front queue前端丟棄佇列3 Bent pipe彎管路徑3 Propagation delay傳播延遲2

New terms in this chapter (6)本章新名詞（6）

Each link opens the term’s first definition.

每個名詞都在它第一次出現的段落中定義，點連結可跳過去。

Congestion control壅塞控制 The sender-side algorithm that sets how much data may be in flight from the signals the network returns. 傳送端根據網路回傳的訊號決定可以有多少資料在途中的演算法。
Congestion window (cwnd)壅塞視窗（cwnd） The sender's limit on unacknowledged bytes, so that throughput is at most cwnd divided by the RTT. 傳送端對仍待確認位元組的上限，因此吞吐量最多是 cwnd 除以 RTT。
CUBICCUBIC The loss-driven Linux default that cuts the window on loss and regrows it along a cubic curve. 以遺失為訊號的 Linux 預設演算法，遺失時縮小視窗，再沿三次曲線回升。
BBRBBR A model-based controller that paces to an estimated bottleneck bandwidth and minimum RTT instead of reacting to loss.依瓶頸頻寬與最小 RTT 的估計模型調整送出速率的控制器。
Reconfiguration-aware congestion control感知重新配置的壅塞控制 A controller that learns, predicts or infers the satellite network's scheduled changes and discounts the loss and delay signals they produce. 能得知、預測或推斷衛星網路排程變動，並對其產生的遺失與延遲訊號打折扣的控制器。
Path emulator路徑模擬平台 A testbed that replays one pre-computed satellite path, with its delay, capacity and handover schedule, under a real operating-system network stack. 在真實作業系統網路堆疊下，重現一條預先算好的衛星路徑及其延遲、容量與換手排程的測試平台。

6.1What the sender sees: loss, RTT swings and the 15-second step傳送端看到什麼：遺失、RTT 擺盪與 15 秒階梯

Recall

回顧

Section 3.4 lists measured Starlink values by study. Section 3.5 describes fifteen-second latency regimes at :12, :27, :42 and :57. Each period begins with a spike about 74 ms above its mean, lasting within the first 140 ms.

第 3.4 節按研究逐一列出了 Starlink 的實測數字，第 3.5 節則說明延遲狀態每 15 秒在每分鐘的第 12、27、42、57 秒切換，每個週期開頭 140 ms 內有一個高出週期平均約 74 ms 的尖峰。

A transport protocol observes acknowledgement timing and gaps, then uses them to infer network conditions. Rules designed for wired networks can misread a satellite network that reconfigures on a timer. Congestion control adjusts the sender’s congestion window, or cwnd, which limits outstanding bytes and bounds throughput by cwnd divided by RTT. Linux’s default CUBIC treats loss as queue overflow, reduces its window, and regrows it along a cubic curve.

That curve changes from concave to convex around the previous loss point. BBR estimates bottleneck bandwidth and minimum RTT, then paces to that model, treating moderate loss as noise. Both associate loss and delay with queues partly filled by the sender, an assumption that satellite reconfiguration can violate.

傳輸層從確認封包的時序與缺口推估網路狀態。有線網路的解讀規則遇到按時重配的衛星網路時，可能產生誤判。壅塞控制調整傳送端的壅塞視窗 cwnd，限制待確認位元組，使吞吐量上限等於 cwnd 除以 RTT。Linux 預設的 CUBIC 把遺失視為佇列溢位，先縮窗，再沿三次曲線回升，曲線以先前遺失的視窗大小為中心由凹轉凸。BBR 則估計瓶頸頻寬與最小 RTT，按模型調整送出節奏，把中等程度的遺失當作雜訊。兩者都把遺失、延遲連結到傳送端參與填滿的佇列，衛星重新配置卻可能破壞這個假設。

Early measurements established that Starlink’s loss bursts and loaded delay differ from wired control paths. Controller comparisons require the original traffic pattern and capacity measurement beside the result.

早期量測顯示 Starlink 的遺失爆發與負載延遲與有線對照各有特徵。控制器比較需連同原始流量模式與容量量測解讀。

Measured loss, delay and controller baselines
#	Reported values and conditions
1	Michel, Trevisan, Giordano and Bonaventure measured a Belgian dish for five months with QUIC over CUBIC.
2	HTTP/3 bulk-transfer loss was 1.56% downstream and 1.96% upstream, falling to 0.40% and 0.45% for light messages.
3	An Amsterdam wired control lost only 10 of over 5.8 million packets, placing the main loss inside the satellite network ^{[48, §3.2, Tab. 2]}.
4	Across 244,008 loss events, median duration was 49 µs and the 99th percentile 7.5 ms.
5	Idle RTT medians of 46–52 ms rose under download to 95, 175 and 210 ms at the median, 95th and 99th percentiles ^{[48, §3.1, Fig. 4]}.
6	Kassem, Raman, Perino and Sastry supplied the congestion-control comparison often attributed to Michel.
7	On Raspberry Pi nodes behind Starlink dishes, BBR beat CUBIC, Reno, Veno and Vegas.
8	It achieved about half the UDP-measured capacity, against over 90% on campus Wi-Fi ^{[46, Fig. 8]}.
9	Loss bursts reached 50% and coincided with the serving satellite leaving sight ^[46].
10	Mohan et al. observed download RTT inflation of two to four times, reaching roughly 400–500 ms ^{[49, Fig. 8]}.
11	This is the sender-side effect of Chapter 3’s bufferbloat.

實測遺失、延遲與控制器基線
#	數值、條件與證據
1	2022 年的量測論文定下了之後每一篇機制論文所攻擊的基線。
2	Michel、Trevisan、Giordano 與 Bonaventure 在比利時用一台天線跑了五個月、以 CUBIC 上的 QUIC 進行測試，發現 HTTP/3 大量傳輸下的封包遺失率為下行 1.56%、上行 1.96%，在輕量訊息流量下降到 0.40% 與 0.45%，而通往阿姆斯特丹的有線對照路徑在超過 580 萬個封包中只遺失 10 個，這把遺失定位在衛星網路內部此處與後續網際網路分開^{[48, §3.2, Tab. 2]}。
3	同一份研究數出 244,008 次遺失事件，其中位數持續時間為 49 µs，但第 99 百分位達 7.5 ms，並記錄到閒置時的來回時間中位數為 46–52 ms，在下載負載下中位數、第 95 與第 99 百分位依序升到 95、175 與 210 ms^{[48, §3.1, Fig. 4]}。
4	常被誤記在 Michel 名下的壅塞控制比較其實來自 Kassem、Raman、Perino 與 Sastry：在 Starlink 天線後方的 Raspberry Pi 節點上，BBR 勝過 CUBIC、Reno、Veno 與 Vegas，卻只達到同一條鏈路上 UDP 探測所量得容量的大約一半，而在校園 Wi-Fi 上能超過 90%^{[46, Fig. 8]}，他們觀察到的遺失成群出現、最高達 50%，且與服務衛星離開視線的時刻重合^[46]。
5	Mohan 等人補上了全球視角：下載期間來回時間膨脹兩到四倍、達到約 400–500 ms^{[49, Fig. 8]}，這就是從傳送端看到的第 3 章緩衝膨脹。

Hypatia demonstrated that path changes can distort congestion signals even at zero congestion. Kassing, Bhattacherjee, Águas, Saethre and Singla ran NewReno on a 72×22 simulated Starlink shell with 10 Mbit/s links and 100-packet queues. A route shortening of about 16 ms let later packets overtake earlier packets. Duplicate acknowledgements then halved the window while every packet still arrived ^{[6, §4.2]}.

TCP Vegas interpreted a path-change delay rise as queue growth and kept its rate low for the remaining run ^{[6, Fig. 5]}. Thus both loss and delay can mislead LEO congestion control. The calculation below shows why 16 ms permits enough reordering to trigger this response.

Hypatia 顯示，即使壅塞量為零，路徑變化仍會扭曲控制訊號。Kassing、Bhattacherjee、Águas、Saethre 與 Singla 在 72×22 模擬殼層上，以 10 Mbit/s 鏈路與 100 封包佇列執行 NewReno。路徑縮短約 16 ms 後，後送封包先到，重複確認使視窗減半，而封包仍全數送達 ^{[6, §4.2]}。TCP Vegas 則把換路造成的延遲上升視為佇列成長，在後續執行期間持續壓低速率 ^{[6, Fig. 5]}。遺失與延遲因此都可能誤導 LEO 壅塞控制，下方計算說明為何 16 ms 已足以觸發重排反應。

Question問題	Calculation算式	Result結果
How many packets does a 16 ms shortening let overtake at 10 Mbit/s?在 10 Mbit/s 下，16 ms 的縮短能讓多少封包超車？	\(\dfrac{10\times10^{6}\times 0.016}{1{,}500\times 8}\)	13.3computed, 16 ms and 10 Mbit/s from Hypatia §4.2, Fig. 4c, 1,500 B packets assumed, ≥3 overtaking packets already trigger three duplicate ACKs計算值，16 ms 與 10 Mbit/s 取自 Hypatia §4.2、Fig. 4c，假設封包 1,500 B，只要 3 個封包超車就足以產生三個重複確認
Window needed to fill the path at a 48 ms RTTRTT 48 ms 時填滿路徑所需的視窗	\(\dfrac{10\times10^{6}\times 0.048}{12{,}000}\)	40 packets個封包computed, 48 ms is the Manila–Dalian maximum in Hypatia Fig. 3計算值，48 ms 是 Hypatia Fig. 3 中馬尼拉–大連的最大值
Time for NewReno to regrow from 20 to 40 packets at one packet per RTTNewReno 以每 RTT 一個封包從 20 回到 40 個封包所需時間	\((40-20)\times 0.048\,\text{s}\)	0.96 scomputed, congestion-avoidance growth of one segment per RTT計算值，壅塞避免階段每 RTT 成長一個區段
Fraction of time spent recovering if one such halving happens per path change若每次路徑變更都砍半一次，花在恢復的時間比例	\(\dfrac{0.96\,\text{s}}{200\,\text{s}/4}\)	≈ 2%Computed from Hypatia Fig. 8: four median path changes per 200 s. The recovery estimate is far below Fig. 10’s 31% underuse time. Additional mechanisms contribute to that underuse.依 Hypatia Fig. 8 每 200 s 中位四次換路計算，恢復估計遠低於 Fig. 10 的 31% 閒置時間，因此仍有其他機制。

Starlink’s scheduled boundaries change both latency and available capacity. The size and timing of those changes explain why a controller’s recent samples can quickly become stale.

Starlink 的排程邊界同時改變延遲與可用容量，變化幅度與時序說明控制器的近期樣本為何會迅速過時。

Reconfiguration timing and measured capacity changes
#	Reported values and conditions
1	Hypatia’s 2020 model preceded measurements of Starlink’s clocked reconfiguration.
2	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.
3	A terminal’s capacity varied from 10 to 65 Mbps within three minutes ^{[56, §3.1, Fig. 2]}.
4	In month-long traces, over 80% of :12/:27/:42/:57 reconfigurations changed adjacent-second capacity by over 10 Mbps.
5	About 20% changed it by at least 40 Mbps, while 90% of changes elsewhere stayed below 5 Mbps ^{[56, §4, Fig. 7]}.
6	Of nine controllers, Copa reached about 20% utilization, or 6.84 Mbps, and BBRv3 stayed below 65% on lossy links ^{[56, §3.3, Fig. 4]}.
7	Casparsen et al. used 500 Hz one-way probes to resolve the boundary.
8	They found a mean spike about 74 ms above the period mean within the first 140 ms. A further rise occurs in the final 75 ms ^{[57, Fig. 3]} preprint.
9	Figure 6.1 combines these observations, and Table 6.1 retains each study’s setup because its conditions determine the meaning of its numbers.

重新配置時序與實測容量變化
#	數值、條件與證據
1	2020 年 Hypatia 模型之後，實測進一步揭露 Starlink 依時鐘進行重新配置。
2	Lai 等人在紐澤西與馬德里量得上行／下行容量約 32/187 與 30/357 Mbps，RTT 為 59 與 27 ms，單一終端容量在三分鐘內於 10–65 Mbps 間變化 ^{[56, §3.1, Fig. 2]}。
3	一個月軌跡中，:12/:27/:42/:57 的全域重配有超過 80% 使相鄰秒容量改變逾 10 Mbps，約 20% 達至少 40 Mbps，其他時刻約 90% 的變化小於 5 Mbps ^{[56, §4, Fig. 7]}。
4	九種控制器中，Copa 利用率約 20%、吞吐量 6.84 Mbps，BBRv3 在有遺失的鏈路上低於 65% ^{[56, §3.3, Fig. 4]}。
5	Casparsen 等人以 500 Hz 單向探測解析邊界，量得週期開頭 140 ms 內平均高出週期均值約 74 ms 的尖峰，最後 75 ms 另有一次上升 ^{[57, Fig. 3]} 預印本。
6	圖 6.1 綜合這些觀察，表 6.1 則保留各研究的設定，讓數值與它們的適用條件相連。

Figure 6.1. One minute as the sender experiences it. The upper trace is the idle bent-pipe RTT with its boundary spikes, the lower trace the capacity of one terminal stepping at each boundary. The measured values include the RTT baseline near 40 ms, boundary seconds, spike height and capacity range. The levels within that range are illustrative.圖 6.1。傳送端所經歷的一分鐘。上方曲線是閒置彎管路徑的 RTT 及其邊界尖峰，下方曲線是單一終端在每個邊界處階梯式變化的容量。約 40 ms 的 RTT 基線、邊界秒數、尖峰高度與容量範圍都是實測值，範圍內的具體階層是繪製的。Sources來源: ^{[13, Fig. 2]} ^{[57, Fig. 3]} ^{[56, Figs. 2, 7]} ^{[49, Fig. 12]}

Original figure note原始圖說出處

Drawn for this primer from Tanveer et al., CoNEXT 2023 Companion, Fig. 2, Casparsen et al., arXiv 2601.08439, Fig. 3, Lai et al., HotNets 2024, Figs. 2 and 7, Mohan et al., WWW 2024, Fig. 12.

Study研究	Setup設定	Transport symptom傳輸層症狀	Number數字
^[6] (Hypatia)^[6] （Hypatia）	ns-3 simulation, 72×22, 10 Mbit/s links, 100-packet queuesns-3 模擬、72×22、10 Mbit/s 鏈路、100 封包佇列	Reordering after a path shortening halves NewReno's window at zero packet loss, Vegas collapses after a latency rise路徑縮短後的重排在零遺失下把 NewReno 視窗砍半，Vegas 在延遲上升後崩潰	~16 ms shortening (Fig. 4c)約 16 ms 的縮短（Fig. 4c）
^[48]^[48]	One dish, Belgium, 5 months, QUIC/CUBIC一台天線、比利時、5 個月、QUIC/CUBIC	Loss inside Starlink, RTT inflation under loadStarlink 內部的遺失，負載下的 RTT 膨脹	1.56/1.96% bulk, 0.40% light, 95/175/210 ms (Table 2, Fig. 3)大量傳輸 1.56/1.96%、輕量 0.40%，95/175/210 ms（Table 2, Fig. 3）
^[46]^[46]	3 Pi nodes, 18 users, ~6 months3 個 Pi 節點、18 位使用者、約 6 個月	BBR best but far below UDP capacity, clustered loss burstsBBR 最佳但遠低於 UDP 容量，成群的遺失爆發	≈ ½ of UDP capacity, bursts to 50% (Figs. 6c, 7, 8)約 UDP 容量的一半，爆發達 50%（Figs. 6c, 7, 8）
^[49]^[49]	19.2 M M-Lab samples, 98 Atlas probes, 2 dishes1,920 萬筆 M-Lab 樣本、98 個 Atlas 探針、2 台天線	Bufferbloat, boundaries aligned across continents even with one satellite in view緩衝膨脹，邊界跨洲對齊，即使視野中只有一顆衛星	RTT 2–4× to 400–500 ms (Fig. 8), §6.2, Fig. 16RTT 膨脹 2–4 倍至 400–500 ms（Fig. 8），§6.2, Fig. 16
^[13]^[13]	Obstruction maps and latency at several vantage points多個觀測點的遮蔽圖與延遲	Latency regime shifts every 15 s延遲狀態每 15 秒切換	seconds 12, 27, 42, 57 (Fig. 2)第 12、27、42、57 秒（Fig. 2）
^[57]^[57]	500 Hz one-way probing, co-located endpoints500 Hz 單向探測、同址端點	Spike at the start of every period每個週期開頭的尖峰	~74 ms above mean in the first 140 ms (Fig. 3) preprint開頭 140 ms 內高出平均約 74 ms（Fig. 3）預印本
^[56]^[56]	Terminals in New Jersey and Madrid, nine CCAs紐澤西與馬德里的終端、九種 CCA	Capacity steps at boundaries, conservative CCAs starve邊界處的容量階梯，保守的 CCA 利用率偏低	10–65 Mbps swings, Copa 20%, BBRv3 <65% (Figs. 2, 4, 7)10–65 Mbps 擺盪，Copa 20%、BBRv3 <65%（Figs. 2, 4, 7）
^[45]^[45]	>10 M hardware-timestamped probes, 2 sites超過 1,000 萬個硬體時間戳探測、2 個站點	Single packet-count-limited drop-front queue, shared queueing, AQM absent單一以封包數為限的前端丟棄佇列，共享佇列、AQM 缺席	1,400–1,600 packets (§7)1,400–1,600 個封包（§7）

Table 6.1. Measured transport symptoms by study. The first row is a simulation result and is kept because it predicted the mechanism before any dish was measured.

表 6.1。各研究實測的傳輸層症狀。第一列是模擬結果，保留它是因為它在任何天線被量測之前就預測了這個機制。

6.2The queue: drop-front, 1,400–1,600 packets, shared queueing那個佇列：前端丟棄、1,400–1,600 個封包、採共享佇列

Recall

回顧

Section 3.4 introduces two- to fourfold bufferbloat and a 1,400–1,600-packet drop-front queue. Here we examine how that queue affects congestion control.

第 3.4 節介紹了 2–4 倍的緩衝膨脹與 1,400–1,600 個封包的前端丟棄佇列，這裡要檢視同一個佇列對壅塞控制器做了什麼。

The measured queue evicts its oldest packet at overflow, so loss timing differs from drop-tail behavior. Competition and delay plateaus also reveal the queue’s shared, length-driven character.

實測佇列在溢位時逐出最老封包，使遺失時序與尾端丟棄各有特徵。流量競爭與延遲平台也揭露共享、長度驅動的特性。

Downlink queue: probe setup and inferred behavior
#	Reported values and conditions
1	The bottleneck queue determines what a loss-based sender learns.
2	Garcia, Sundberg and Brunstrom used over ten million hardware-timestamped UDP probes in 120 burst patterns.
3	They measured a second-generation dish in Karlstad and checked a second site in Málaga ^{[45, §3–7]}.
4	The inferred bottleneck is one queue limited to about 1,400–1,600 packets, or approximately 2.25 MB with full-size packets.
5	At overflow it evicts the oldest packet and accepts the newcomer.
6	A packet-level drop-front simulation reproduced the observed delay pattern more closely than equal-size drop-tail.
7	At 1,500 packets and 124 Mbps, mean delays were 85 ms and 122 ms respectively ^{[45, §6, Figs. 3–4]}.
8	Ten competing CUBIC and ten BBRv1 flows gave BBRv1 more than a max-min-fair share, indicating a shared queue ^{[45, §4, Fig. 2]}.
9	Delay plateaus varied by 30–60 ms with queue length, supporting a length-driven queue over CoDel-style delay targeting ^{[45, §7]}.
10	Loss positions matched access in one of every three 1.33 ms frames.
11	The authors connect this to scheduling while leaving the queue’s physical location open.

下行佇列的探測設定與推得行為
#	數值、條件與證據
1	瓶頸佇列決定遺失式傳送端能讀到什麼訊號。
2	Garcia、Sundberg 與 Brunstrom 以超過一千萬個硬體時間戳 UDP 探測組成 120 種爆發模式，量測 Karlstad 第二代天線，再用馬拉加站點核對 ^{[45, §3–7]}。
3	推得的瓶頸是以封包數設限的單一佇列，通常容納 1,400–1,600 個，滿尺寸時約 2.25 MB。
4	溢位時逐出最老封包、接納新封包的前端丟棄，比同大小尾端丟棄更能重現延遲模式。
5	在 1,500 封包、124 Mbps 下，兩者平均延遲各為 85 ms 與 122 ms ^{[45, §6, Figs. 3–4]}。
6	十條 CUBIC 與十條 BBRv1 競爭時，BBRv1 超過最大最小公平份額，顯示它們共用佇列 ^{[45, §4, Fig. 2]}。
7	延遲平台隨佇列長度變化 30–60 ms，支持長度驅動的佇列解釋，與 CoDel 的延遲目標有所區隔 ^{[45, §7]}。
8	遺失位置符合每三個 1.33 ms 訊框取得一次存取的模式，將佇列連至排程，但實體位置仍待確定。

Earlier drop-front loss signals may reduce standing queues and utilization. The measurement, company statement and transit-network ECN behavior each concern their own point along the path.

前端丟棄較早的遺失訊號可能降低常駐佇列與利用率，量測、公司聲明及地面轉運 ECN 行為則各描述路徑上的特定環節。

Queue interpretation, company claims and ECN scope
#	Reported values and conditions
1	The authors present the congestion-control effect as a possible mechanism.
2	Evicting the oldest packet delivers a loss signal earlier than rejecting a newly arrived packet.
3	A loss-based sender may therefore reduce sooner, maintain a smaller standing queue, leave capacity idle, and synchronize reductions with competitors ^{[45, §6, §9]}.
4	This could help explain CUBIC’s low utilization in Table 6.1.
5	A full 1,500-packet queue at 124 Mbps holds 145 ms, while surviving drop-front packets wait less because older packets leave through eviction.
6	SpaceX credits fq_codel and buffer resizing for reducing US peak-hour median latency from 48.5 to 33 ms in March 2024.
7	This is a company statement (Starlink latency statement) company.
8	Karlstad’s 2025 measurements describe a particular downlink queue with shared, length-driven behavior.
9	The accounts can concern separate queues along the path, so their source tags matter.
10	ECN markings were cleared in Karlstad’s Twelve99 transit network but preserved end to end at Málaga ^{[45, App. B]}.
14	L4S behavior can therefore differ because of terrestrial transit.

佇列解讀、公司聲明與 ECN 範圍
#	數值、條件與證據
1	作者把壅塞控制的影響視為可能機制。
2	逐出最老封包會比拒收新封包更早送出遺失訊號，傳送端因此可能更早縮窗、維持較淺佇列、閒置部分容量，或與競爭流同步減速 ^{[45, §6, §9]}。
3	這可能解釋表 6.1 中 CUBIC 利用率偏低的現象。
4	滿載的 1,500 封包佇列在 124 Mbps 下容納 145 ms，但存活封包因前方舊封包被逐出，等待時間更短。
5	SpaceX 則把 2024 年 3 月美國尖峰中位延遲從 48.5 降至 33 ms 歸因於 fq_codel 與緩衝區調整（Starlink 延遲聲明）公司。
6	Karlstad 的 2025 年量測描述特定下行佇列的共享、長度驅動行為，兩者可能對應路徑中的各佇列，須連同來源標籤解讀。
7	ECN 標記在 Karlstad 的 Twelve99 轉運網路中被清除，在馬拉加則端到端保留 ^{[45, App. B]}，因此 L4S 行為也會受到地面轉運影響。

Question問題	Calculation算式	Result結果
Delay of a full 1,400-packet queue drained at 124 Mbps以 124 Mbps 排空的滿載 1,400 封包佇列的延遲	\(\dfrac{1{,}400\times 1{,}500\times 8}{124\times10^{6}}\)	135 mscomputed, queue size and drain rate from Garcia et al. §6–7, 1,500 B packets計算值，佇列大小與排空速率取自 Garcia et al. §6–7，封包 1,500 B
Same for 1,500 packets1,500 個封包時	\(\dfrac{1{,}500\times 12{,}000}{124\times10^{6}}\)	145 mscomputed, compare Garcia's measured means of 85 ms (drop-front) and 122 ms (drop-tail) under their burst patterns計算值，對照 Garcia 在其爆發模式下量得的平均 85 ms（前端丟棄）與 122 ms（尾端丟棄）
Same for 1,600 packets1,600 個封包時	\(\dfrac{1{,}600\times 12{,}000}{124\times10^{6}}\)	155 mscomputed計算值
Bytes held by 1,500 full-size packets1,500 個滿尺寸封包所佔的位元組	\(1{,}500\times 1{,}500\,\text{B}\)	2.25 MBcomputed, the queue is packet-limited, so small packets hold far fewer bytes計算值，佇列以封包數為限，所以小封包所佔位元組少得多
Delay of Hypatia's 100-packet queue at 10 Mbit/s, for comparison對照：Hypatia 的 100 封包佇列在 10 Mbit/s 下的延遲	\(\dfrac{100\times 12{,}000}{10\times10^{6}}\)	120 mscomputed, queue and rate from Kassing et al. §4.2計算值，佇列與速率取自 Kassing et al. §4.2

Panel 6.1面板 6.1

Drop-front vs drop-tail queue前端丟棄 vs 尾端丟棄佇列

Offered load (of 124 Mbps)提供負載（相對 124 Mbps）

Queue size佇列大小

Discipline丟棄規則

Arrivals到達模式

Mean queueing delay

平均佇列延遲

95th percentile

第 95 百分位

Loss rate

遺失率

Full-queue delay

滿載佇列延遲

This queue model compares drop disciplines under identical seeded arrivals. Its reference measurements use a separate arrival process.

Conditions and reported evidence
#	Evidence record
1	This discrete-time model uses Garcia et al.’s parameters.
2	Each slot serves one 1,500-byte packet at 124 Mbps, with Poisson arrivals at the selected load.
3	Burst mode alternates one second at twice that load with one second of zero arrivals.
4	A fixed random seed gives both disciplines identical arrivals over a 3.9 s run from an empty queue.
5	The 85 ms and 122 ms reference means come from Garcia’s 120 burst patterns on a 1,500-packet queue, a separate arrival process.
6	Scheduler frames, rate adaptation and sender reactions lie outside this model.

此佇列模型讓各丟棄規則使用相同的固定種子到達序列。參考量測採用另一種到達過程，條件列於表中。

條件、數值與證據
#	條件與結果
1	本離散時間模型採 Garcia 等人的參數，每個時槽以 124 Mbps 服務一個 1,500 位元組封包，到達量依所選負載採 Poisson 過程。
2	爆發模式交替一秒兩倍負載與一秒零到達，固定亂數種子讓兩種丟棄規則看到相同到達序列。
3	模型從空佇列開始執行 3.9 秒。
4	85 ms 與 122 ms 參考線來自 Garcia 對 1,500 封包佇列的 120 種爆發實測，屬另一種到達過程。
5	排程訊框、速率調整與傳送端反應位於本模型範圍之外。

Stop and think停下來想一想

At 80% load both disciplines give identical results. At 120%, delay differs by tens of milliseconds while loss rate stays constant. Explain how the eviction rule changes delivered-packet delay while preserving drop count. Which queue alerts a CUBIC sender sooner?

80% 負載時，兩種規則給出相同結果。120% 負載時，延遲相差數十毫秒，遺失率仍相同。請用逐出規則解釋，為何丟棄總數相同而送達封包的等待時間改變，再指出哪種佇列會更早提醒 CUBIC 傳送端。

6.3Reconfiguration-aware congestion control: SaTCP, HotNets 2024 patches, LeoCC感知重新配置的壅塞控制：SaTCP、HotNets 2024 修補與 LeoCC

Recall

回顧

Chapter 3 describes Starlink’s fifteen-second global scheduling period, with boundaries at :12, :27, :42 and :57. At mid-latitudes, at least 89% of handovers fall within one second of a boundary ( Section 3.5 ).

第 3 章的重新配置週期是 Starlink 全域排程器的 15 秒週期，邊界落在每分鐘的第 12、27、42、57 秒，在中緯度地區，至少 89% 的天線換手落在邊界前後一秒之內（第 3.5 節）。

Reconfiguration-aware congestion control discounts loss and delay samples associated with scheduled satellite changes, so window reductions respond to congestion. The three designs differ in their source of event information. SaTCP receives predicted handovers from components at the terminal and ground station. The HotNets 2024 patches read dish diagnostics. LeoCC detects gaps in responses to a 10 ms ICMP probe from the user’s device to the PoP, making detection entirely end-host based.

感知重新配置的控制器會降低排程變化所產生之遺失與延遲樣本的權重，讓縮窗主要回應壅塞。三種設計各有事件來源：SaTCP 由終端與地面站元件預測換手並通知傳送端，HotNets 2024 修補讀取天線診斷，而 LeoCC 在使用者裝置上以每 10 ms 送往 PoP 的 ICMP 回應空隙偵測事件，完全由端點運作。

Cao and Zhang built SaTCP on CUBIC with handover predictions from public orbital elements. About 90% of prediction errors across 1,605 satellites fell within ±0.6 s ^{[67, Fig. 4]}. Around each prediction, the sender suspends reductions for \(2T_{err} + RTO_{min} + 0.1\,\text{s}\). Here \(T_{err}\) bounds prediction error, and \(RTO_{min}\) is the minimum retransmission timeout.

A timeout within that period also skips the usual reset to one packet ^{[67, §V-C–V-D]}. Outside it, SaTCP uses ordinary CUBIC behavior. Its gain therefore depends on the share of CUBIC losses caused by handovers. Figure 6.2 shows why the error band requires a freeze window wider than the outage.

Cao 與 Zhang 把 SaTCP 建在 CUBIC 之上，並以由公開軌道根數算出的換手預測驅動它，在 1,605 顆衛星上約有 90% 的預測誤差落在 ±0.6 s 以內^{[67, Fig. 4]}。因此傳送端在預測時刻前後的一段抑制期 \(2T_{err} + RTO_{min} + 0.1\,\text{s}\) 內暫停一切視窗縮小，其中 \(T_{err}\) 是預測誤差的界限、\(RTO_{min}\) 是最小重傳逾時，而抑制期內發生的逾時會略過平常把視窗重設為一個封包的動作^{[67, §V-C–V-D]}。在抑制期之外，SaTCP 的行為與 CUBIC 完全相同，這讓它原則上可以部署，也意味著它在任一路徑上的增益等於該路徑上 CUBIC 遺失中屬於換手遺失的比例。圖 6.2 畫出單一邊界附近的機制，以及迫使視窗必須比它要覆蓋的中斷更寬的誤差帶。

Figure 6.2. The freeze window around one predicted handover. The window opens before the predicted instant to cover early predictions. It closes after that instant plus a retransmission timeout, covering timeouts caused by the outage. The ±0.6 s error band and the window formula are from SaTCP, the window's end point and the window traces are drawn schematically.圖 6.2。一次預測換手前後的凍結視窗。因為預測可能偏早，視窗在預測時刻之前就打開，它在預測時刻加上一個重傳逾時之後才關閉，好讓中斷造成的逾時也被略過。±0.6 s 誤差帶與視窗公式取自 SaTCP，視窗終點與兩條視窗曲線是示意繪製。Sources來源: ^{[67, §V-B–V-C, Figs. 4–5]}

Original figure note原始圖說出處

Drawn for this primer from Cao & Zhang, INFOCOM 2023, §V-B–V-C and Figs. 4–5.

SaTCP suppresses window reductions around predicted handovers. Its gain is largest where handover loss strongly limits CUBIC, and smaller where the baseline already fills the modeled path.

SaTCP 在預測換手附近抑制縮窗。當換手遺失強烈限制 CUBIC 時增益最大，基線原已充分利用模型路徑時則較小。

SaTCP: emulator setup and baseline-dependent gains
#	Reported values and conditions
1	SaTCP’s authors evaluated it on their LeoEM path emulator, which replays precomputed satellite delay, capacity and handovers through a real operating-system network stack.
2	A single laptop runs Mininet and Linux traffic control.
3	The model uses Starlink Shell 1 at 550 km and 53°, with 72 planes of 22 satellites and +Grid ISLs.
4	Each link has a 150 Mb/s cap and 1,000-packet queue.
5	Fifteen-second hard handovers interrupt old and new ingress links for 1.5 RTT ^{[67, §III-B, §IV, §VI-A]}.
6	On the San Diego–New York bent pipe, CUBIC reached 34.3 Mbps, BBR 136.7 Mbps, and 1.3 s SaTCP 138.1 Mbps.
7	SaTCP’s 4.03× gain over CUBIC nearly matches BBR and prevents 91.7% of undesired window reductions ^{[67, Table I, §VI-B]}.
8	Gains fell to 1.74× at 0.3 s and 3.60× at 0.9 s.
9	CUBIC already reached 138.9 Mbps on San Diego–Seattle and 128.5 Mbps on the New York–London ISL path, where SaTCP added 9% (Table I).

SaTCP 的平台設定與基線增益
#	數值、條件與證據
1	評估在 LeoEM 上進行，它由同一批作者打造，之後成了這個子領域共用的測試平台。
2	LeoEM 是一種路徑模擬平台，也就是在真實作業系統網路堆疊上，重現一條預先算好的衛星路徑及其延遲、容量與換手排程的測試平台，在這裡用的是單台筆電上的 Mininet 與 Linux 流量控制，Starlink 第一殼層以 550 km、53° 的 72 個軌道面 × 22 顆衛星建模，採用 +Grid 星間鏈路，每條鏈路限速 150 Mb/s、佇列 1,000 個封包，換手以 15 秒為週期，硬換手會使通往舊與新入口衛星的鏈路各中斷 1.5 個 RTT^{[67, §III-B, §IV, §VI-A]}。
3	在聖地牙哥–紐約的彎管路徑上，CUBIC 達到 34.3 Mbps、BBR 136.7 Mbps，而 1.3 s 設定的 SaTCP 達到 138.1 Mbps，比 CUBIC 高 4.03 倍、與 BBR 幾乎相同，並阻止了 91.7% 多餘的視窗縮小^{[67, Table I, §VI-B]}。
4	增益隨視窗縮短而下降，在 0.3 s 時為 1.74 倍、0.9 s 時為 3.60 倍，在 CUBIC 本來就健康的路徑上增益則消失，例如聖地牙哥–西雅圖的 138.9 Mbps，或是經由 ISL 的紐約–倫敦路徑，CUBIC 已達 128.5 Mbps，SaTCP 只多出 9%（Table I）。

The terminal-based patches discard path estimates from before a reconfiguration. Their replay results show separate throughput and latency effects, subject to the event detector’s sampling granularity.

終端修補在重配後捨棄舊路徑估計，重播顯示吞吐量與延遲各自的變化，其範圍受偵測粒度影響。

HotNets patches: replay settings and results
#	Reported values and conditions
1	Lai et al.’s HotNets 2024 design detects events at the terminal.
2	It places global events at established boundary seconds and detects local events from dish obstruction maps read through gRPC every second ^{[56, §4]}.
3	Two prototypes discard samples from before each event because the new satellite requires fresh path estimates.
4	A Kalman-filter BBRv1 variant reduced mean RTT from 60.30 to 42.11 ms and 95th-percentile RTT from 97.95 to 78.30 ms.
5	Throughput changed from 27.96 to 26.24 Mbps.
6	Copa discarded old RTT samples over about 20 RTTs, raising throughput from 6.84 to 11.93 Mbps while RTT remained near 34.5 ms ^{[56, §5, Tab. 1]}.
7	Both results use extended-Mahimahi trace replay.
8	The authors note that one-second detection may be too coarse (§7).

HotNets 修補的重播設定與結果
#	數值、條件與證據
1	Lai 等人的 HotNets 2024 設計在終端偵測事件。
2	全域重配採已知邊界秒數，局部事件則從每秒經 gRPC 讀取的遮蔽圖變化辨識 ^{[56, §4]}。
3	兩個原型在事件後捨棄舊樣本，為新衛星重新估計路徑。
4	Kalman 濾波的 BBRv1 把平均 RTT 從 60.30 降至 42.11 ms，第 95 百分位從 97.95 降至 78.30 ms，吞吐量從 27.96 變成 26.24 Mbps。
5	Copa 在約 20 RTT 視窗內捨棄舊 RTT，吞吐量從 6.84 升至 11.93 Mbps，RTT 維持約 34.5 ms ^{[56, §5, Tab. 1]}。
6	兩項結果均來自擴充 Mahimahi 的軌跡重播，作者也指出一秒粒度可能過粗（§7）。

LeoCC infers access interruptions from end-host probes and refreshes its path model after each event. It combines steady-period bandwidth estimation with a temporary inflight cap at the boundary.

LeoCC 由端點探測推斷存取中斷，事件後更新路徑模型，並結合穩定區間的頻寬估計與邊界的暫時在途上限。

LeoCC: event detection and adaptation
#	Reported values and conditions
1	The group’s SIGCOMM 2025 system, LeoCC, detects reconfigurations on the user’s device.
2	Each event interrupts access for about 45–120 ms.
3	ICMP probes every 10 ms to the nearest Starlink PoP address expose a response gap followed by bunched replies.
4	A response interval above 45 ms marks an event ^{[74, §4.1.1, Fig. 7]}.
5	LeoCC then estimates bottleneck bandwidth and a base-RTT band from subsequent samples.
6	Between boundaries it combines a maximum bandwidth filter with a Kalman estimate.
7	At each boundary, it caps inflight data at half the estimated bandwidth-delay product, then resumes its saved target rate ^{[74, §4.1.2–4.2, Fig. 9]}.
8	A Linux module passes detection to a remote sender through a receiver ACK TCP option.
9	Evaluation used three live terminals and LeoReplayer, which records capacity with saturating UDP and base RTT and loss with light ICMP ^{[74, §5, §6.1]}.

LeoCC 的事件偵測與調適
#	數值、條件與證據
1	LeoCC 是同一團隊在 SIGCOMM 2025 的論文，它改在使用者自己的裝置上偵測重新配置，擺脫了對天線的依賴。
2	每次重新配置都會讓接取鏈路中斷約 45–120 ms，因此每 10 ms 向 Starlink 網路接入點最近位址送出的輕量 ICMP 探測，會看到回應先停止、再成串抵達，只要回應間隔超過 45 ms 就標記為一次事件^{[74, §4.1.1, Fig. 7]}。
3	控制器隨後只用該事件之後的樣本估計瓶頸頻寬與一個基礎 RTT 帶，在兩個邊界之間以最大值濾波與 Kalman 濾波兩種頻寬估計巡航，並在每個邊界把在途資料限制在估計頻寬延遲乘積的一半，再從保存的目標速率恢復^{[74, §4.1.2–4.2, Fig. 9]}。
4	它以 Linux 核心模組執行，透過接收端 ACK 的 TCP 選項把偵測結果帶給遠端傳送端，並在三台實際 Starlink 終端上以及用 LeoReplayer 重播進行評估，LeoReplayer 以飽和 UDP 記錄容量、以輕量 ICMP 記錄基礎 RTT 與遺失^{[74, §5, §6.1]}。

LeoCC’s headline range combines comparisons against controllers with separate utilization and delay behavior. Each ratio therefore needs its named baseline and live or replay setting.

LeoCC 的摘要範圍整合了各種利用率與延遲表現的控制器比較，因此每個比值都需連同基線與實測或重播環境。

LeoCC: results with their comparison baselines
#	Reported values and conditions
1	On the Madrid→Barcelona uplink, LeoCC throughput exceeded BBRv3 by 85%, CUBIC by 253%, and Copa by 494%.
2	One-way delay fell 44% against BBRv1 and 56% against VIVACE ^{[74, §6.2, Fig. 10a]}.
3	Each gain requires its baseline: Copa reached only 20% utilization in the HotNets study, so its ratio reflects substantial baseline conservatism.
4	The authors attribute BBRv3’s lower utilization to its response to lossy LEO links ^{[74, §2.3, §6.2]}.
5	In replay, LeoCC averaged 95.2% utilization, near BBRv1’s 95.8%, while keeping a smaller queue after capacity reductions ^{[74, §6.3, Fig. 13]}.

LeoCC 的結果與對照基線
#	數值、條件與證據
1	在馬德里→巴塞隆納上行路徑上，LeoCC 的吞吐量比 BBRv3 高 85%、比 CUBIC 高 253%、比 Copa 高 494%，單向延遲比 BBRv1 低 44%、比 VIVACE 低 56%，這正是其摘要引用的兩個範圍^{[74, §6.2, Fig. 10a]}。
2	讀這個範圍時要記得它的基線：Copa 正是 HotNets 論文中利用率只有 20% 的控制器，所以範圍上端主要量的是 Copa 有多保守，而 85% 是相對 BBRv3 的增益，作者認為 BBRv3 對遺失的反應正是它在多遺失的 LEO 鏈路上容量利用率偏低的原因^{[74, §2.3, §6.2]}。
3	在重播中，LeoCC 的平均鏈路利用率達 95.2%，接近 BBRv1 的 95.8%，而在重新配置後容量下降時，它的佇列比 BBRv1 小^{[74, §6.3, Fig. 13]}。

The independent LeoEM evaluation places the event-aware designs much closer to a modern model-based baseline. Its conditions help distinguish baseline weakness from additional event-awareness gains.

獨立 LeoEM 評估中，感知事件設計與現代模型式基線更接近，其條件可協助區分基線弱點與事件感知的額外增益。

Independent controller comparison
#	Reported values and conditions
1	Mazilu, Valentine, Wakeman and Parisis provide an independent preprint comparison on LeoEM.
2	They ran CUBIC, SaTCP, BBRv3, LeoCC, PCC-Vivace and Astraea with fifteen-second changes and 45–120 ms gaps ^[75] preprint.
3	Seattle–New York normalized goodput was CUBIC 49.0, SaTCP 94.4, BBRv3 90.2, LeoCC 93.5 and Astraea 65.7.
4	With BBRv3 as baseline, the additional gain is a few points.
5	SaTCP’s original large ratio used CUBIC, while LeoCC’s 85% BBRv3 gain used a live uplink.
6	LeoCC itself found a smaller downlink gap, where lower interval loss reduces BBRv3’s penalty ^{[74, §6.2, Fig. 10b]}.
7	The independent study measured delay inflation of 2.14× for CUBIC and 2.30× for SaTCP.
8	BBRv3 required about 12 s to adapt to a sharp RTT rise.
9	Table 6.2 keeps the emulator, path and baseline beside each result.

獨立控制器比較
#	數值、條件與證據
1	Mazilu、Valentine、Wakeman 與 Parisis 的獨立預印本，在 LeoEM 上比較 CUBIC、SaTCP、BBRv3、LeoCC、PCC-Vivace 與 Astraea，採十五秒週期及 45–120 ms 空窗 ^[75] 預印本。
2	西雅圖–紐約正規化有效吞吐量為 CUBIC 49.0、SaTCP 94.4、BBRv3 90.2、LeoCC 93.5、Astraea 65.7。
3	以 BBRv3 作基線，額外增益只有幾個點。
4	SaTCP 原本的大倍數以 CUBIC 作基線，LeoCC 的 85% BBRv3 增益則來自實際上行鏈路。
5	LeoCC 自己的下行實驗中，區間內遺失較低，BBRv3 懲罰較小，差距也較窄 ^{[74, §6.2, Fig. 10b]}。
6	獨立研究另量得 CUBIC 與 SaTCP 單流延遲膨脹為 2.14 與 2.30 倍，BBRv3 需約 12 s 適應 RTT 急升。
7	表 6.2 將平台、路徑與基線保留在結果旁邊。

Question問題	Calculation算式	Result結果
SaTCP's gain over CUBIC, San Diego–New YorkSaTCP 相對 CUBIC 的增益（聖地牙哥–紐約）	\(138.1 / 34.3\)	4.03×computed, both throughputs from Cao & Zhang Table I (LeoEM)計算值，兩個吞吐量取自 Cao & Zhang Table I（LeoEM）
CUBIC's utilization of the 150 Mb/s emulated linkCUBIC 對 150 Mb/s 模擬鏈路的利用率	\(34.3 / 150\)	22.9%computed, link cap from Cao & Zhang §VI-A計算值，鏈路上限取自 Cao & Zhang §VI-A
Share of each 15 s period inside a 1.3 s freeze window1.3 s 凍結視窗佔每個 15 s 週期的比例	\(1.3 / 15\)	8.7%computed, the sender is CUBIC for the other 91%計算值，其餘 91% 的時間傳送端就是 CUBIC
Copa patch, throughput changeCopa 修補的吞吐量變化	\(11.93 / 6.84 - 1\)	+74.4%computed, ^{[56, Tab. 1]} (trace replay)計算值，^{[56, Tab. 1]}（軌跡重播）
BBRv1 patch, average RTT changeBBRv1 修補的平均 RTT 變化	\(42.11 / 60.30 - 1\)	−30.2%computed, same table計算值，同一表
LeoCC over BBRv3 in the independent study獨立研究中 LeoCC 相對 BBRv3	\(93.5 / 90.2 - 1\)	+3.7%computed, Mazilu et al. Fig. 1a reports SEA→NY on LeoEM. LeoCC measured an 85% gain over BBRv3 on a live Madrid→Barcelona uplink (Lai et al., SIGCOMM 2025, Fig. 10a).計算值，Mazilu et al. Fig. 1a，LeoEM 上的 SEA→NY，對照 LeoCC 論文在實際馬德里→巴塞隆納上行路徑上量得相對 BBRv3 的 85%（Lai et al., SIGCOMM 2025, Fig. 10a）

Design設計	Where the event comes from事件從哪裡得知	Evaluation setting評估環境	Baselines基線	Headline result主要結果
SaTCP ^[67]SaTCP^[67]	TLE prediction at terminal and ground station, signalled to the sender終端與地面站以 TLE 預測，再通知傳送端	LeoEM emulation, 150 Mb/s links, 15 s handoffsLeoEM 模擬，150 Mb/s 鏈路，15 秒換手	CUBIC, BBRCUBIC、BBR	34.3 → 138.1 Mbps (4.03×) SD–NY聖地牙哥–紐約 34.3 → 138.1 Mbps（4.03 倍）
Lai et al. patches ^[56]Lai 等人的修補^[56]	Known seconds plus dish gRPC obstruction map, 1 s granularity已知秒數加上天線 gRPC 遮蔽圖，1 秒粒度	Mahimahi replay of New Jersey and Madrid traces以 Mahimahi 重播紐澤西與馬德里的軌跡	Original Copa, BBRv1原版的 Copa、BBRv1	Copa +74.4%, BBRv1 RTT −30.2%Copa +74.4%，BBRv1 RTT −30.2%
LeoCC ^{[74, §6.1–6.2]}LeoCC^{[74, §6.1–6.2]}	10 ms ICMP probe from the user's device to the PoP, response interval above 45 ms使用者裝置每 10 ms 向 PoP 送出 ICMP 探測，回應間隔超過 45 ms	Three live Starlink terminals plus LeoReplayer traces三台實際 Starlink 終端加上 LeoReplayer 軌跡	Eleven, including CUBIC, Copa, BBRv1, BBRv3, VIVACE and SaTCP十一種，包括 CUBIC、Copa、BBRv1、BBRv3、VIVACE 與 SaTCP	Madrid→Barcelona uplink: +85% vs BBRv3, +253% vs CUBIC, +494% vs Copa, delay −44% vs BBRv1, −56% vs VIVACE馬德里→巴塞隆納上行：相對 BBRv3 +85%、CUBIC +253%、Copa +494%，延遲相對 BBRv1 −44%、VIVACE −56%
Mazilu et al. (independent) preprintMazilu 等人（獨立評估）預印本	Runs each design as published依原發表方式執行各設計	LeoEM, 15 s interval, 45–120 ms gapsLeoEM，15 秒週期，45–120 ms 空窗	All six against each other六者互相比較	CUBIC 49.0, SaTCP 94.4, BBRv3 90.2, LeoCC 93.5CUBIC 49.0、SaTCP 94.4、BBRv3 90.2、LeoCC 93.5

Table 6.2. Reconfiguration-aware designs and their validation environments. All rows describe research evaluations, with deployment at scale still awaiting published evidence.

表 6.2。感知重新配置的設計與驗證環境，各列皆屬研究評估，大規模部署仍待公開證據。

Panel 6.2面板 6.2

Reconfiguration-aware sender感知重新配置的傳送端

Freeze window凍結視窗

Bottleneck buffer瓶頸緩衝區

Capacity trace容量軌跡

Loss-driven sender

以遺失驅動的傳送端

Freeze-window sender

凍結視窗傳送端

Ratio (SaTCP paper: 4.03×)

比值（SaTCP 論文：4.03 倍）

Boundaries masked

被遮蔽的邊界

Mean queueing delay

平均佇列延遲

The fluid model follows one flow across scheduled capacity changes and outages. Its timing and path parameters are listed below.

Conditions and reported evidence
#	Evidence record
1	This fluid model follows one flow for one minute.
2	Capacity stays constant within fifteen-second periods and changes at :12/:27/:42/:57 to seeded levels between 10 and 65 Mbps ^{[56, Fig. 2]}.
3	A 100 ms outage at each boundary clears the queue and causes a loss burst, within Mazilu et al.’s 45–120 ms range.
4	Base RTT is 59 ms, following Lai et al.’s New Jersey terminal.

Both senders share the same loss response, with freeze windows covering predicted boundaries. The model’s recovery and prediction assumptions are listed below.

Conditions and reported evidence
#	Evidence record
1	On loss, the sender halves at most once per RTT and follows a cubic recovery curve with the model’s chosen 0.4 packets/s³ growth constant.
2	The freeze-window sender shares this behavior except during predicted-boundary windows, where it ignores loss.
3	Prediction-error standard deviation is 0.36 s, putting 90% within ±0.6 s as in SaTCP’s Fig. 4.
4	Slow start, timeouts, competing flows and reordering lie outside this model.
5	Its ratio describes this fluid experiment, while SaTCP’s 4.03× describes packet-level emulation.

此流體模型追蹤一條流在排程容量變化與中斷下的反應。表中整理共同規則、凍結視窗及預測誤差假設。

條件、數值與證據
#	條件與結果
1	本流體模型追蹤單一流的一分鐘。
2	容量在十五秒週期內固定，於 :12/:27/:42/:57 變成 10–65 Mbps 的固定種子亂數值 ^{[56, Fig. 2]}。
3	每個邊界中斷 100 ms，位於文獻的 45–120 ms 範圍內 ^[75]，並清空佇列、產生成群遺失。
4	基礎 RTT 依紐澤西終端設為 59 ms。
5	遺失式傳送端每 RTT 最多縮半一次，再依本模型選定的 0.4 封包/s³ 常數沿三次曲線回升。
6	凍結視窗傳送端採相同規則，但在預測邊界視窗內忽略遺失。
7	預測誤差標準差 0.36 s，使 90% 落在 ±0.6 s，對應 SaTCP Fig. 4。
8	慢啟動、逾時、競爭流與重排均在模型範圍之外，所以比值描述本流體實驗，SaTCP 的 4.03 倍則描述封包模擬。

Stop and think停下來想一想

Freeze windows below about 0.5 s rarely help. Above about 2 s, throughput plateaus while queueing delay keeps rising. Explain these results using prediction error and the sender’s treatment of congestion losses inside a long window. Then explain the extra cost of a 1,500-packet buffer.

凍結視窗短於約 0.5 s 時效益很小，超過約 2 s 後吞吐量趨於平臺，佇列延遲卻持續上升。請從預測誤差與視窗內壅塞遺失的處理方式解釋兩端現象，再說明 1,500 封包緩衝區的額外代價。

6.4Fairness and the cost of being clever公平性與聰明的代價

A sender that holds its rate through a boundary can take capacity released by a competing sender. The shared queue makes this coexistence cost visible to users of the same dish.

在邊界維持速率的傳送端可占用競爭者釋出的容量，共享佇列則把這項共存代價傳給同一天線的使用者。

SaTCP coexistence and fairness
#	Reported values and conditions
1	Holding rate through a loss event shifts capacity toward the flow that holds it.
2	Two SaTCP flows share fairly: 47.9 and 50.0 Mbps at 0.3 s inhibition, then 68.2 and 70.1 Mbps at 2.3 s.
3	Beside CUBIC, SaTCP takes 111.9 versus 17.2 Mbps at 0.9 s, and 131.3 versus 8.4 Mbps at 2.3 s ^{[67, Table II]}.
4	As Panel 6.2 illustrates, CUBIC halves at boundaries while SaTCP fills the released capacity.
5	Section 6.2’s shared bottleneck queue lets this difference reach users sharing a dish.
6	Per-flow fair queueing would limit the imbalance.

SaTCP 共存與公平性
#	數值、條件與證據
1	遇到遺失仍維持速率，會讓容量流向維持速率的那條流。
2	兩條 SaTCP 流分享得相近：0.3 s 抑制期為 47.9 與 50.0 Mbps，2.3 s 為 68.2 與 70.1 Mbps。
3	與 CUBIC 共存時，0.9 s 下變成 111.9 對 17.2 Mbps，2.3 s 下為 131.3 對 8.4 Mbps ^{[67, Table II]}。
4	如面板 6.2 所示，CUBIC 在邊界減半，SaTCP 則填入釋出的容量。
5	第 6.2 節的共享瓶頸佇列會把差距傳給共用天線的使用者，逐流公平佇列則可限制這種失衡。

LeoCC’s repeated capacity startup can increase retransmissions. Its live fairness test and independent emulator comparison measure separate controllers and workloads, so both require their evaluation scope.

LeoCC 反覆啟動容量探測可能提高重傳。實際公平性測試與獨立平台比較各有控制器與負載，須保留各自範圍。

LeoCC retransmission and fairness evidence
#	Reported values and conditions
1	LeoCC’s observed cost is retransmission.
2	At each reconfiguration, its released implementation restarts BBR with a window near half the bandwidth-delay product, probing capacity four times per minute.
3	Mazilu et al. measured the highest retransmission rate among tested controllers and attributed it to startup overshoot ^[75] preprint.
4	Another preprint also criticizes repeated startup and 10 ms ICMP probing ^[76] preprint.
5	LeoCC estimates probe overhead at about 51 kbps per terminal including headers ^{[74, §6.6]}.
6	Its live four-flow test at RTTs of 20, 48, 85 and 145 ms reported similar throughput ^{[74, §6.4, Fig. 16]}.
7	The independent study instead found about 0.5 goodput ratios for CUBIC and SaTCP flows with unequal RTTs ^[75].
8	These results describe separate controllers, traces and costs.
9	Figure 6.3 records each design’s signal and validation environment.

LeoCC 重傳與公平性證據
#	數值、條件與證據
1	LeoCC 的可觀察代價是重傳。
2	每次重配後，釋出實作以約半個頻寬延遲乘積的視窗重啟 BBR，每分鐘重探容量四次。
3	Mazilu 等人量到它在受測控制器中重傳率最高，並歸因於啟動過衝 ^[75] 預印本。
4	另一預印本也批評反覆啟動與 10 ms ICMP 探測 ^[76] 預印本，LeoCC 自估含標頭約需每終端 51 kbps ^{[74, §6.6]}。
5	其 RTT 為 20、48、85、145 ms 的四條實際流有相近吞吐量 ^{[74, §6.4, Fig. 16]}，獨立研究則報告各異 RTT 的 CUBIC、SaTCP 流有效吞吐量比約 0.5 ^[75]。
6	這些結果對應各自的平台、軌跡、控制器與成本，圖 6.3 逐一標出訊號與驗證環境。

Figure 6.3. The congestion-control family tree as it reaches LEO. SaTCP modifies CUBIC, while the HotNets 2024 patches modify Copa and BBRv1. LeoCC uses released code derived from a BBRv3 kernel. It inherits the HotNets method of discarding samples collected before reconfiguration. Each LEO-aware box carries the signal it depends on and the only setting in which it has been validated.圖 6.3。延伸到 LEO 的壅塞控制家族樹。SaTCP 修改 CUBIC，HotNets 2024 的修補修改 Copa 與 BBRv1，LeoCC 的釋出程式碼衍生自 BBRv3 核心，它繼承了 HotNets 丟棄重新配置前樣本的想法。每個感知 LEO 的方框都標出它所依賴的訊號，以及它唯一被驗證過的環境。Sources來源: ^[67] ^[56] ^[74] ^[75]

Original figure note原始圖說出處

Drawn for this primer from Cao & Zhang, INFOCOM 2023, Lai et al., HotNets 2024, Lai et al., SIGCOMM 2025 (full paper, code release), Mazilu et al., arXiv 2510.25498.

Deployment requires specific components. SaTCP needs a patched user OS, terminal and ground-station cooperation, and public orbital elements refreshed every three hours ^{[67, §V-B]}. The HotNets patches require dish gRPC access inside the subscriber network. LeoCC runs a probe behind the dish and exists as a kernel module tested on three residential terminals ^{[74, §5.1, §6.1]}.

Other validation uses emulation or replay, and published evidence for deployment at scale remains open. An IETF individual draft proposed a network-to-endpoint “Path Phase Boundary” signal, then expired (draft-lai-ccwg-lsncc-01) expired draft. Current Starlink traffic consequently uses the standard controllers examined in Section 6.1.

部署需要特定元件。SaTCP 需要修補使用者作業系統，並由終端、地面站配合，公開軌道根數每三小時更新 ^{[67, §V-B]}。HotNets 修補需要訂戶網路內的天線 gRPC 存取。LeoCC 在天線後方執行探測，現有證據來自在三台住宅終端測試的核心模組 ^{[74, §5.1, §6.1]}。其他驗證使用模擬或軌跡重播，大規模部署的公開證據仍待建立。IETF 個人草案曾提議網路向端點傳送「路徑階段邊界」訊號，後來到期（draft-lai-ccwg-lsncc-01）過期草案。因此現行 Starlink 流量仍由第 6.1 節檢視的標準控制器承載。

6.5Applications: video, gaming, conferencing應用層：影音、遊戲與視訊會議

Applications absorb some loss through redundancy while retaining the effects of path delay and uplink asymmetry. Their measurements connect transport behavior to user-visible latency and quality.

應用以冗餘吸收部分遺失，同時仍受路徑延遲與上下行差距影響。量測把傳輸行為連結到使用者可感受的延遲與品質。

Application measurements: conferencing, games and web
#	Reported values and conditions
1	Applications add their own adaptation above congestion control.
2	Mohan et al. compared Zoom over Starlink and terrestrial lines.
3	Uplink one-way delay was 52 ± 14 versus 27 ± 7 ms, and downlink 35 ± 11 versus 32 ± 7 ms.
4	Forward error correction rose from 2 ± 2 to 146 ± 99 kbps, while both paths maintained about 27 frames per second ^{[49, §5, Fig. 10]}.
5	This redundant data lets the receiver rebuild lost packets immediately, exchanging bandwidth for resilience to loss bursts.
6	Uplink–downlink differences also match Chapter 3’s 10:1 capacity asymmetry.
7	Cloud-gaming delay was 167 ms on Starlink, 134 ms wired and 166 ms cellular, with 1080p maintained 99.45% of the time ^{[49, Tab. 1]}.
8	Round-trip-sensitive web browsing loaded pages in a median 2.12 s, against 1.24 s wired and 10.91 s over geostationary satellite ^{[48, Fig. 6]}.

應用量測：會議、遊戲與網頁
#	數值、條件與證據
1	應用層位於壅塞控制器之上，並加入自己的調適機制，所以它們能顯示網路的哪些行為穿過了底下每一層而仍然存在。
2	Mohan 等人比較 Starlink 與地面 Zoom、雲端遊戲。Zoom 上行為 52 ± 14 對 27 ± 7 ms，下行相近，為 35 ± 11 對 32 ± 7 ms。前向更正為 146 ± 99 對 2 ± 2 kbps，兩者皆約每秒 27 幀^{[49, §5, Fig. 10]}。
3	前向錯誤更正用冗餘資料立即重建遺失封包，以頻寬回應遺失爆發。從 2 升至 146 kbps 的成本，也與第 3 章 10:1 上下行容量差距相連。
4	雲端遊戲的遊戲延遲呈現同樣的模式，Starlink 上為 167 ms，有線為 134 ms、行動網路為 166 ms，而串流有 99.45% 的時間維持在 1080p^{[49, Tab. 1]}，網頁瀏覽主要受往返次數影響，載入中位數為 2.12 s，有線 1.24 s、地球同步 10.91 s^{[48, Fig. 6]}。

GCC often interprets the boundary delay spike as queue growth. Partial recovery within each period reduces time at the target bitrate, with site differences linked to path and handover behavior.

GCC 常把邊界延遲尖峰解讀為佇列成長，週期內的部分恢復減少達標時間，各站差異則與路徑、換手行為相連。

Teams and GCC: site-specific measurements
#	Reported values and conditions
1	Fries, Matezki, Bose and Mohan studied Microsoft Teams and instrumented WebRTC Google Congestion Control, GCC. Their sites were Germany, the Netherlands, Norway and Antarctica’s McMurdo Station ^[51].
2	GCC follows the lower of simultaneous loss-based and delay-based estimates.
3	On Starlink, the delay estimate controlled 96.4–99.6% of the time.
4	Reconfiguration or handover coincided with delay-overuse transitions in 100% of German, 97.4% of Dutch, 91.0% of Norwegian and 60.7% of McMurdo cases ^{[51, §4.2]}.
5	After reconfiguration, Teams’ target fell about 0.8 Mbps within 1–2 s against a 2.5 Mbps uplink cap at 720p.
6	Recovery remained partial over the next 10 s.
7	Reconfiguration accounted for 46.3% of below-target time at McMurdo, 32.0% in Norway and about 5% at the central-European sites ^{[51, §4.1]}.
8	Like Hypatia’s Vegas, GCC can interpret a boundary spike as queue growth.
9	McMurdo uses ISLs to Sydney and has 30.7% of handovers away from boundaries, suggesting behavior that differs from bent pipes.

Teams 與 GCC 的各站量測
#	數值、條件與證據
1	最鮮明的應用層結果來自 Fries、Matezki、Bose 與 Mohan 的視訊會議研究，他們在德國、荷蘭、挪威以及南極麥克默多站，驅動原版的 Microsoft Teams 與一份加了量測點的 Google 壅塞控制（GCC，WebRTC 的控制器）^[51]。
2	GCC 並行執行一個以遺失為訊號與一個以延遲為訊號的估計器，取兩者中較低的值，在 Starlink 上，延遲估計器有 96.4–99.6% 的時間掌控估計值，而進入延遲過載的轉換中，德國 100%、荷蘭 97.4%、挪威 91.0%、麥克默多 60.7% 與重新配置或換手同時發生^{[51, §4.2]}。
3	每次重新配置之後，Teams 的位元率目標都在 1–2 s 內下降約 0.8 Mbps（720p 時上行上限為 2.5 Mbps），且在其後 10 s 內只部分回復，因此在麥克默多有 46.3%、挪威有 32.0% 的低於目標時間可歸因於重新配置，在兩個中歐站點則約 5%^{[51, §4.1]}。
4	這呼應 Hypatia 的 Vegas 機制：延遲式控制器把邊界尖峰視為佇列成長，十秒後仍只部分恢復，使十五秒週期的全速時間縮短。
5	麥克默多經 ISL 連至雪梨 PoP，30.7% 換手落在邊界之外，提供雷射路徑與彎管行為差異的線索。

6.6Transport across ISLs: evidence and open questions跨越 ISL 的傳輸層：證據與待解問題

Recall

回顧

Vacuum propagation takes 3.336 µs per kilometer ( propagation delay ). Tabulated next-generation lasers need 2–30 s to acquire a new partner ( Section 2.4 ).

光在真空中每公里需 3.336 µs（傳播延遲），而在表列的下一代系統中，雷射終端需要 2–30 s 才能捕獲新的對象（第 2.4 節）。

The chapter’s transport measurements chiefly concern satellite access, while congestion control with an ISL bottleneck remains outside their direct measurement scope. Public details of laser rate, topology and scheduling are limited (Section 4.3). Studies infer ISL use from latency, as at McMurdo, and emulator results retain their assumed link behavior. LeoEM uses 150 Mb/s ISLs and reports CUBIC above 135 Mbps on some paths. Its New York–London example gives 128.5 Mbps, with SaTCP adding 9% ^{[67, Table I]}. These values describe modeled links with zero setup time and fading, so real-laser transport requires separate validation.

本章傳輸量測主要針對衛星存取，以 ISL 作瓶頸的壅塞控制仍待直接量測。雷射速率、拓樸與排程的公開細節有限（第 4.3 節），研究通常像麥克默多案例一樣從延遲推論 ISL，模擬結果則繼承其鏈路假設。LeoEM 採 150 Mb/s ISL，部分路徑的 CUBIC 超過 135 Mbps，而紐約–倫敦例子為 128.5 Mbps，SaTCP 增加 9% ^{[67, Table I]}。這些值描述建立與衰落成本設為零的模型，真實雷射傳輸仍需另行驗證。

AI training fabrics use RDMA and priority flow control to move memory and manage rare losses. Published cluster examples give their operating scale.

Conditions and reported evidence
#	Evidence record
1	AI training uses a different transport model.
2	RDMA over Converged Ethernet moves memory directly between hosts, while priority flow control pauses upstream ports before buffer overflow.
3	The resulting lossless fabric tunes recovery for rare losses, as Chapter 7 of the companion AI Training Network Primer explains.
4	Meta’s Llama 3 cluster provides 400 Gbps per GPU, with pipeline- and data-parallel multi-hop delays up to tens of microseconds ^{[77, §3.3]} preprint.
5	Alibaba’s HPN reports NIC-to-ToR failures of 0.057% per month, one to two monthly training crashes, and 5,000–60,000 daily link flaps ^{[65, §2.3, Tab. 1]}.

AI 訓練網路以 RoCE 與優先權流控搬移記憶體，並針對罕見遺失調校恢復。表中整理相關叢集的量測與設定。

條件、數值與證據
#	條件與結果
1	AI 訓練後端採 RoCE，網卡直接在主機間搬記憶體，優先權流控在溢位前暫停上游埠。
2	此無損架構針對罕見遺失調校恢復，詳見姊妹教材 AI 訓練網路入門在其第 7 章（傳輸層）中詳細說明這一點。
3	參考數字是：在 Meta 的 Llama 3 叢集中每顆 GPU 400 Gbps，管線平行與資料平行流量經過多跳路徑、延遲最高達數十微秒^{[77, §3.3]}預印本，在阿里巴巴的 HPN 中，網路卡到 ToR 的鏈路每月故障率為 0.057%，每月有一到兩次訓練工作崩潰，每天有 5,000–60,000 次鏈路抖動^{[65, §2.3, Tab. 1]}。

Laser acquisition introduces outages far longer than propagation delay. Predicted link-state changes may help orbital training reroute collectives before disruption, while terrestrial lossless assumptions require explicit evaluation.

雷射擷取造成遠長於傳播的中斷，預測鏈路狀態可能協助在軌訓練事先改道，地面無損假設則需要明確評估。

Laser-link outage regime and training implications
#	Reported values and conditions
1	Laser links have another failure regime.
2	Next-generation terminals need 2–30 s to acquire partners ^{[33, Tab. 1]}.
3	SpaceX reports about 266,000 daily acquisitions and 99% uptime company.
4	SpaceMoE assumes independent ISL survival probability 0.95 per topology snapshot ^{[78, §II]} preprint.
6	Its 5% per-snapshot loss figure is about two orders above HPN’s monthly rate even before reconciling time units.
7	A lossless fabric facing a seconds-long outage can pause and stall a collective, or drop traffic and recover.
8	The calculation below gives each acquisition second’s cost at terrestrial GPU rates.
9	Across a 2 km formation, propagation is about 6.7 µs, below terrestrial multi-hop delays of tens of microseconds, as Section 10.5 discusses.
10	Like Starlink handovers, geometric laser acquisitions can be predicted.
11	Orbital training transport may therefore use advance link-state information to route collectives around outages, a question related to SaTCP’s event awareness.

雷射斷鏈型態與訓練影響
#	數值、條件與證據
1	雷射鏈路有另一種故障型態。
2	下一代終端擷取新夥伴需 2–30 s ^{[33, Tab. 1]}，SpaceX 報告每天約 266,000 次擷取、可用率 99% 公司。
3	SpaceMoE 假設各 ISL 在每個拓樸快照中獨立以 0.95 機率存活 ^{[78, §II]} 預印本，每快照 5% 遺失的數字約比 HPN 月故障率高兩個數量級，而時間單位仍需對齊。
4	採無損設計的網路面對數秒斷鏈，可暫停並讓集合通訊等待，或丟棄後恢復。
5	下方計算表列出地面 GPU 速率下每秒擷取的代價。
6	光跨越 2 km 編隊約需 6.7 µs，低於地面多跳的數十微秒，第 10.5 節會比較兩者。
7	雷射擷取和 Starlink 換手都可由幾何預測，因此在軌訓練可研究如何預先取得鏈路狀態，讓集合通訊繞過中斷，呼應 SaTCP 的事件感知。

Question問題	Calculation算式	Result結果
One-way light time across a 2 km formation光穿越 2 km 編隊的單向時間	\(2\,\text{km}\times 3.336\,\mu\text{s/km}\)	6.7 µscomputed, vacuum delay from Chapter 2計算值，真空延遲取自第 2 章
Bandwidth-delay product at 400 Gbps over that round trip以 400 Gbps 跨越該來回時間的頻寬延遲乘積	\(\dfrac{400\times10^{9}\times 13.3\times10^{-6}}{8}\)	667 kBcomputed, 400 Gbps per GPU from Llama 3 §3.3計算值，每顆 GPU 400 Gbps 取自 Llama 3 §3.3
Data deferred by a 400 Gbps port during a 2 s acquisition2 s 擷取期間，400 Gbps 連接埠延後傳送的資料量	\(\dfrac{400\times10^{9}\times 2}{8}\)	100 GBcomputed, 2 s lower end from Chaudhry & Yanikomeroglu Table 1計算值，2 s 下限取自 Chaudhry & Yanikomeroglu Table 1
Same for a 30 s acquisition30 s 捕獲時	\(\dfrac{400\times10^{9}\times 30}{8}\)	1.5 TBcomputed, upper end of the same table計算值，同一表的上限
SpaceMoE's loss per snapshot against HPN's failures per monthSpaceMoE 每快照遺失率對 HPN 每月故障率	\(5\% / 0.057\%\)	≈ 88×computed, a lower bound on the gap, because a snapshot is far shorter than a month計算值，這是差距的下限，因為一個快照遠短於一個月

Chapter summary

本章摘要

Starlink congestion control can misread path reordering, scheduled changes and drop-front queue behavior. In Hypatia, reordering halved NewReno’s window while every packet arrived. Reconfiguration bursts and capacity steps can leave CUBIC and BBR near half the UDP-measured capacity. The shared 1,400–1,600-packet drop-front queue gives 85 ms mean delay, against 122 ms for equal-size drop-tail.

Event-aware designs learn timing from the network, dish or endpoint. Their reported gains depend on the comparator and experiment.

Conditions and reported evidence
#	Evidence record
1	Event-aware designs learn timing from the network, dish ^[56], or end-host probes.
2	SaTCP rises from 34.3 to 138.1 Mbps in LeoEM, while live-uplink LeoCC gains 85% over BBRv3 and 253% over CUBIC.
3	An independent emulator comparison places SaTCP, BBRv3 and LeoCC near 90–94 against CUBIC’s 49.
4	SaTCP can reduce a CUBIC neighbor to 8.4 Mbps, and LeoCC has the highest measured retransmission rate in that comparison.
5	Their deployment evidence remains at research scale.

Zoom’s delay and error-correction costs rise, while Teams cuts roughly 0.8 Mbps at boundaries. Real-ISL transport needs direct measurement, especially for seconds-long acquisition events that challenge lossless training fabrics.

路徑重排、重配與前端丟棄會改變壅塞控制訊號。表中整理各模型、比較基準與應用結果，並保留部署範圍。

條件、數值與證據
#	條件與結果
1	Starlink 壅塞控制可能誤判路徑重排、排程變化與前端丟棄佇列的訊號。
2	Hypatia 中，重排在封包全數送達時讓 NewReno 視窗減半。
3	重配的遺失與容量階梯可能讓 CUBIC、BBR 只達 UDP 所量容量的一半。
4	共享的 1,400–1,600 封包前端丟棄佇列平均延遲為 85 ms，同大小尾端丟棄為 122 ms。
5	感知事件的設計從網路、天線 ^[56] 或端點探測取得時序。
6	SaTCP 在 LeoEM 從 34.3 升至 138.1 Mbps，實際上行 LeoCC 比 BBRv3 高 85%、CUBIC 高 253%。
7	獨立平台比較中，SaTCP、BBRv3、LeoCC 約為 90–94，CUBIC 為 49。
8	SaTCP 可把競爭 CUBIC 壓至 8.4 Mbps，LeoCC 在該比較重傳最多，部署證據則仍為研究規模。
9	Zoom 的延遲與錯誤更正成本上升，Teams 在邊界減少約 0.8 Mbps，真實 ISL 傳輸尤其需要針對數秒擷取事件作直接量測，以評估它對無損訓練網路的影響。

Where these ideas go next

這些概念接下來用在哪裡

Chapter 7 examines LeoEM, Mahimahi replay, Hypatia and constellation emulators for their treatment of scheduling, drop-front queues and lasers. Those assumptions define the reach of Table 6.2’s results. Chapter 10 compares the lossless training fabric with constellation conditions.

第 7 章打開本章所依賴的測試平台，包括 LeoEM、以 Mahimahi 為基礎的重播、Hypatia 與各種星座模擬平台，並追問它們之中到底有哪些模擬了 15 秒排程、前端丟棄佇列與雷射鏈路，這決定了表 6.2 中任何結果能推廣到多遠。第 10 章則回到第 6.6 節，把無損的訓練網路與星座所能提供的條件相對照。

Papers behind this chapter本章所依據的論文

IMC 2022A Browser-side View of Starlink Connectivity WWW 2024A Multifaceted Look at Starlink Performance INFOCOM 2023SaTCP: Link-Layer Informed TCP Adaptation for Highly Dynamic LEO Satellite Networks HotNets 2024Mind the Misleading Effects of LEO Mobility on End-to-End Congestion Control SIGCOMM 2025LeoCC: Making Internet Congestion Control Robust to LEO Satellite Dynamics IMC 2026Characterizing the Configuration of Starlink Queuing IMC 2026Looking at Stars: Analyzing Real-Time Video Conferencing over Starlink

6.1What the sender sees: loss, RTT swings and the 15-second step傳送端看到什麼：遺失、RTT 擺盪與 15 秒階梯

6.2The queue: drop-front, 1,400–1,600 packets, shared queueing那個佇列：前端丟棄、1,400–1,600 個封包、採共享佇列

Drop-front vs drop-tail queue前端丟棄 vs 尾端丟棄佇列

6.3Reconfiguration-aware congestion control: SaTCP, HotNets 2024 patches, LeoCC感知重新配置的壅塞控制：SaTCP、HotNets 2024 修補與 LeoCC

Reconfiguration-aware sender感知重新配置的傳送端

6.4Fairness and the cost of being clever公平性與聰明的代價

6.5Applications: video, gaming, conferencing應用層：影音、遊戲與視訊會議

6.6Transport across ISLs: evidence and open questions跨越 ISL 的傳輸層：證據與待解問題

Papers behind this chapter本章所依據的論文

Check your understanding檢驗你的理解