Digest · Transport and congestion control · read after Chapter 6
導讀 · 傳輸層與壅塞控制 · 第 6 章後閱讀
Characterizing the Configuration of Starlink Queuing刻畫 Starlink 排隊機制的組態
This digest explains how timed probes identify Starlink’s shared drop-front downlink queue. It shows why discarding the oldest packet reduces delivered-packet delay and gives loss-based senders an earlier congestion signal.讀完後，你能說明超過一千萬個硬體時間戳探測封包如何揭露 Starlink 下行瓶頸是一個約 1,400–1,600 封包、採前端丟棄與共享 FIFO 排程，CoDel 類控制器則在推論模型之外的單一佇列，以及為什麼丟前端佇列能降低延遲，卻提早把壅塞訊號交給基於遺失的傳送端。
Main result
主要結果
Timed UDP probes reveal a shared drop-front queue at Starlink’s downlink bottleneck. Discarding the oldest packet lowers delivered-packet delay and advances the loss signal.
定時 UDP 探測揭露 Starlink 下行瓶頸的共用丟前端佇列，丟棄最舊封包會降低送達封包延遲，並提早傳出遺失訊號。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 325,000 · 120 · 30 · 2 · 2025 · 1 | Garcia, Sundberg and Brunstrom send about 325,000 UDP probes across 120 patterns, repeated 30 times, for over ten million probes. Intel X550 hardware timestamps measure delivery to Karlstad's Gen-2 terminal in May 2025, with an October Málaga check. A 1-µs queue model fits per-packet delays [45, §3, §5–6]. |
| Evidence and scope | 1,400–1,600 | The downlink has one user queue, sized at about 1,400–1,600 packets. It discards the oldest packets, shares capacity among flows unevenly and lacks observed CoDel-like control [45, §4–7]. |
| Latency comparison | 1,500 · 124 · 85 ms · 122 ms | For the same 1,500-packet queue drained at 124 Mbps, drop-front gives a mean delay of 85 ms where drop-tail would give 122 ms |
| Latency comparison | Qualitative scope | so the configuration trades loss placement for latency |
| Reliability and accuracy | Qualitative scope | Discarding the oldest packets gives a loss-based sender such as CUBIC an earlier signal than tail-drop behavior. |
| Evidence and scope | Qualitative scope | which the authors offer as a candidate explanation for the chronic CUBIC under-utilisation of earlier studies while leaving causality open [45, §6, §9]. |
| Evidence and scope | 2026 | The paper is accepted to IMC 2026 and was read from the arXiv preprint, so section numbers refer to that version. |
| 證據與範圍 | 2025 · 5 · 325,000 · 120 · 30 · 10 · 1 µs | Garcia、Sundberg 與 Brunstrom 從一台配備 Intel X550 硬體時間戳的伺服器，在 2025 年 5 月向卡爾斯塔德的一台第二代 Starlink 終端發送約 325,000 個 UDP 探測封包，涵蓋 120 種突發模式、每種重複 30 次，總計超過一千萬個探測，並在 2025 年 10 月於馬拉加設置檢核站點，再用一個 1 µs 時槽的佇列模擬器去擬合逐封包的單向延遲[45, §3, §5–6]。 |
| 證據與範圍 | 1,400–1,600 | 結果顯示下行瓶頸是每位使用者一個佇列，以封包數設定容量上限、約 1,400–1,600 個封包，採丟前端，採共用佇列排程，CoDel 類主動佇列管理列於模型之外[45, §4–7]。 |
| 證據與範圍 | 124 · 1,500 · 85 ms · 122 ms | 對同樣以 124 Mbps 排空的 1,500 封包佇列，丟前端的平均延遲是 85 ms，丟尾端則會是 122 ms，所以這個組態是用遺失的位置換取延遲。 |
| 證據與範圍 | 定性範圍 | 而由於被丟的是最舊的封包，像 CUBIC 這種基於遺失的傳送端會比在丟尾端佇列後方更早收到訊號，作者將此作為早期研究中 CUBIC 長期低利用率的候選解釋，因果關係則待驗證[45, §6, §9]。 |
| 證據與範圍 | 2026 | 這篇論文已被 IMC 2026 接受，本導讀讀的是 arXiv 預印本，章節編號依該版本。 |
1. Where this paper sits1. 這篇論文的位置
Earlier transport studies measured poor utilization and built reconfiguration-aware senders. This paper examines the queue mechanism that those senders encounter.
先前傳輸研究量到利用率偏低，也設計了重組感知傳送端，本篇則檢視這些傳送端所面對的佇列機制。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 2025 | By 2025 the transport literature on Starlink had a diagnosis and two cures while the bottleneck queue remained undescribed. |
| Latency comparison | 2–4 · 400–500 ms | Kassem et al. Had measured BBR at half of UDP capacity, Mohan et al. Had documented bufferbloat that inflated RTT 2–4× to 400–500 ms under load |
| Latency comparison | 2024 · 15 | SaTCP, HotNets patches and LeoCC target 15-second changes while leaving bottleneck discipline unspecified. LeoCC's appendix tests its throughput–delay trade across FIFO, head-drop, PIE and CoDel [74, App. C]. |
| Evidence and scope | Qualitative scope | This paper fills the gap at the link itself. |
| Capacity and rate | 1.33 ms · 373.3 · 430.5 · 2026 | Earlier Karlstad work inferred 1.33 ms frames and rates of 373.3 and 430.5 Mbps from bursts [43]. This study extends that method to queue discipline. |
| Reliability and accuracy | 2022 · 35 | Front drops create loss clusters when arrivals exceed drain, offering another explanation for events Kassem et al. attributed to handover in 2022. The fact base distinguishes reconfiguration, handover and front-drop behavior (Part C item 35). |
| Evidence and scope | 6 · 6.2 | For Chapter 6 it is the paper behind Section 6.2 and the drop-front panel. |
| 證據與範圍 | 2025 | 到 2025 年，關於 Starlink 的傳輸層文獻已有診斷與兩種解方，瓶頸佇列的描述則待補充。 |
| 延遲比較 | 2–4 · 400–500 ms · 2024 · 15 | Kassem 等人量到 BBR 只達 UDP 容量的一半，Mohan 等人記錄了負載下 RTT 膨脹 2–4 倍到 400–500 ms 的緩衝膨脹，而 SaTCP、HotNets 2024 修補與 LeoCC 都圍繞 15 秒重組設計，瓶頸佇列規則則待確認，LeoCC 的附錄也只做到證明其吞吐量與延遲的平衡在模擬的 FIFO、前端丟棄、PIE 與 CoDel 佇列下都能維持[74, App. C]。 |
| 證據與範圍 | 定性範圍 | 這篇論文把鏈路本身的缺口補上。 |
| 證據與範圍 | 1.33 ms · 373.3 · 430.5 · 2026 | 同一個卡爾斯塔德團隊早先已從突發統計推斷出 1.33 ms 的幀時序與 373.3、430.5 Mbps 的實體速率[43]，IMC 2026 的研究則把這個方法從速率延伸到排隊機制。 |
| 證據與範圍 | 2022 · 35 | 它的結果也重新框架了 Kassem 等人在 2022 年歸因於換手的遺失叢，因為只要到達率短暫超過排空率，丟前端佇列就會在佇列前端產生成叢的遺失，這正是事實庫把排程重組、天線換手與丟前端佇列列為三個被早期研究混淆現象的原因（事實庫 Part C 第 35 項）。 |
| 證據與範圍 | 6 · 6.2 | 對第 6 章而言，它是第 6.2 節與丟前端面板背後的論文。 |
2. The problem, measured2. 問題，用量測說話
Controlled bursts expose capacity, sharing and delay plateaus. The observed packet sequence supports a common packet-count queue with drop-front behavior.
受控突發揭露容量、共享與延遲高原，觀察到的封包序列支持以封包數為限、採丟前端行為的共用佇列。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | The measurement is a probing campaign designed to make the queue reveal itself. |
| Latency comparison | 120 · 12 ms | A nanoping-based generator varies UDP bursts across 120 patterns. Intel X550 hardware timestamps give microsecond-resolution one-way delays, with about 12 ms outside Starlink [45, §3]. |
| Latency comparison | 1,000 · 48 · 96 · 6,000 · 500 · 87 ms · 55% | Bursts up to 1,000 packets and steady 48/96 Mbps sends have near-zero loss, indicating at least 96 Mbps available capacity. A 6,000-packet burst at 500 Mbps averages 87 ms one-way delay and 55% loss [45, §5, Fig. 1]. |
| Evidence and scope | Qualitative scope | Ten CUBIC flows compete with ten BBRv1 flows. BBRv1 later takes much more capacity, supporting a shared user queue with uneven allocation [45, §4, Fig. 2]. |
| Latency comparison | 30 · 60 ms | Delay plateaus vary from about 30 to 60 ms. Their drops follow queue length rather than a fixed delay bound, weakening a CoDel-like interpretation [45, §7]. |
| Capacity and rate | 33 · 218 | Fitted drain rates span 33–218 Mbps. Some bursts suggest load adaptation, with systematic confirmation still pending [45, §5, §8, Fig. 6]. |
| 證據與範圍 | 定性範圍 | 這項量測是一場為了讓佇列自我顯露而設計的探測活動。 |
| 證據與範圍 | 120 · 12 ms | 以 nanoping 為基礎的「nanoprobe」產生器發送 UDP 突發，速率與長度在 120 種突發類型間變化，每個封包在傳送端的 Intel X550 上打硬體時間戳，使下行每個封包的單向延遲能以微秒等級量測，路徑中的地面部分貢獻約 12 ms[45, §3]。 |
| 證據與範圍 | 1,000 · 48 · 96 · 500 · 6,000 · 87 ms · 55% | 第一個觀察關於容量：最多 1,000 個封包的突發以及 48 與 96 Mbps 的穩定發送遺失接近零，意味這台終端至少有約 96 Mbps 可用，而一次 500 Mbps、6,000 封包的突發則平均 87 ms 單向延遲、55% 遺失[45, §5, Fig. 1]。 |
| 證據與範圍 | 定性範圍 | 第二個關於公平性：十條 CUBIC 流與十條 BBRv1 流競爭時，BBRv1 在傳輸後期拿走明顯更大的份額，這顯示流量份額偏離 max-min 公平分配，顯示一位使用者的所有流共享一個佇列[45, §4, Fig. 2]。 |
| 證據與範圍 | 30 · 60 ms | 第三是延遲高原，其水準在相異次執行間於約 30 到 60 ms 之間變動，而丟棄跟隨的是佇列長度，延遲界限則會產生相異的丟棄模式，排除了 CoDel 類控制器[45, §7]。 |
| 證據與範圍 | 33 · 218 | 各次執行擬合出的排空速率介於 33 到 218 Mbps，並有一些證據顯示排空速率會在突發期間隨負載調整，系統性驗證待完成[45, §5, §8, Fig. 6]。 |
3. The design3. 設計
A manually fitted queue simulator compares discard rules against packet-level delay and loss. Frame-modulated draining reproduces the loss positions and locates the queue before resource allocation.
人工擬合的佇列模擬器將丟棄規則與逐封包延遲、遺失比較，受幀調變的排空能重現遺失位置，將佇列定位在資源分配之前。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Latency comparison | 1 µs | A Python queue model uses 1 µs time slots. Queue size, drain rate and drop discipline are manually fitted to each burst's delay and loss sequence [45, §6]. |
| Evidence and scope | Qualitative scope | Two features of the empirical pattern decide the discipline. |
| Latency comparison | Qualitative scope | Under drop-tail, a full queue drops the arriving packet. Thus, the packets that do get through all wait the full queue length and the delay of successive delivered packets stays flat at the maximum. |
| Dataset and workload | Qualitative scope | Under drop-front, a full queue discards the packet at its head to admit the new arrival. Thus, a delivered packet is one that was retained until service. The per-packet delay trace shows a characteristic shape that the simulation reproduces only when the head is dropped [45, Figs. 3–4]. |
| Latency comparison | 1,400–1,600 | The queue size then follows from the number of packets in flight when loss begins and from the plateau delay, giving the 1,400–1,600-packet range. The fact that the limit is in packets rather than bytes follows from the size being independent of packet length [45, §7, Figs. 5, 7]. |
| Evidence and scope | 1.33 ms | Matching within-burst losses requires one access-enabled frame followed by three idle frames, synchronized to Starlink's 1.33 ms frame. This places the queue before resource allocation, while satellite-versus-gateway location remains unresolved [45, §6]. |
| 證據與範圍 | 1 µs | 分析工具是一個 1 µs 解析度的 Python 時槽佇列模擬器，其參數，即佇列大小、排空速率與丟棄機制，以人工調整直到模擬出的逐封包延遲與遺失序列與某次突發的實測結果相符[45, §6]。 |
| 證據與範圍 | 定性範圍 | 實測模式中的兩個特徵決定了丟棄機制。 |
| 證據與範圍 | 定性範圍 | 在丟尾端下，滿載佇列會丟棄到達的封包，因此能通過的封包都要等待整個佇列長度，連續送達封包的延遲會在最大值處保持平坦。 |
| 證據與範圍 | 定性範圍 | 在丟前端下，滿載佇列會丟棄隊首封包以容納新到達者，因此送達的封包是保留到取得服務的那些，逐封包延遲軌跡呈現一種只有在丟棄隊首時模擬才能重現的特徵形狀[45, Figs. 3–4]。 |
| 證據與範圍 | 1,400–1,600 | 佇列大小接著由遺失開始時在途的封包數與高原延遲推得，給出 1,400–1,600 封包的範圍，而上限以封包數計，則由大小在各種封包長度下保持固定推得[45, §7, Figs. 5, 7]。 |
| 證據與範圍 | 1.33 ms | 最後，突發內遺失的位置只有在排空被「一個有通道存取的幀、接著三個存取閒置幀」的模式調變、且與 Starlink 的 1.33 ms 幀同步時才能重現，這把佇列定位在資源分配瓶頸的正前方，實體位置則仍待確定，候選位置包括衛星與閘道[45, §6]。 |
Original figure note原始圖說出處
Drawn for this primer from Garcia, Sundberg & Brunstrom, arXiv 2605.27717 (IMC 2026), §4, §6–7, Figs. 3–5 and 7.| Question | 問題 | Formula | 公式 | Result | 結果 |
|---|---|---|---|---|---|
| How many bytes does a 1,500-packet queue hold if every packet is 1,500 bytes?若每個封包 1,500 位元組，1,500 封包的佇列容納多少位元組？ | \( B = 1{,}500 \times 1{,}500 \) | 2.25 MB computed. Queue size from §7, packet size assumed. The paper states the limit is in packets, so with smaller packets the byte volume is proportionally lower.計算值。佇列大小取自 §7，封包大小為假設。論文指出上限以封包數計，所以封包較小時位元組量成比例降低。 | |||
| How long does a full 1,500-packet queue of 1,500-byte packets take to drain at 124 Mbps?1,500 個 1,500 位元組封包的滿載佇列以 124 Mbps 排空要多久？ | \( t = \dfrac{1{,}500 \times 1{,}500 \times 8}{124 \times 10^{6}} \) | 145 ms Calculated from the Section 6 drain-rate fit. This is the maximum standing delay imposed by a drop-tail queue of that size. The 122 ms drop-tail mean and 85 ms drop-front mean both fall below it.計算值。排空速率取自 §6 的擬合。這是同樣大小的丟尾端佇列會造成的最大常駐延遲，122 ms 丟尾端平均與 85 ms 丟前端平均都低於此值。 |
4. Evaluation setup4. 實驗設定
The campaign measures the live downlink and fits a queue model to controlled probes. A second site checks queue behavior and the path’s treatment of ECN.
活動量測實際下行，並以受控探測擬合佇列模型。第二個站點用來核對佇列行為及路徑對 ECN 的處理。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Latency comparison | Qualitative scope | The evaluation measures production downlink paths. ISL rate, latency and topology remain outside its modeling scope. |
| Model and compute | Qualitative scope | The only model is the single-queue simulator fitted to the probes. |
| Evidence and scope | 2 · 2025 | Karlstad uses a Gen-2 Standard Actuated terminal with hardware timestamps in May 2025. The October Málaga site uses software timestamps to test queue and ECN reproducibility [45, §3, App. B]. |
| Capacity and rate | 120 · 30 · 15 · 2 | The 120 burst types vary rate and length, each run 30 times. Thus, the statistics are over repetitions of controlled bursts rather than over background traffic. The 15-second reconfiguration enters only as background in §2 rather than as a measured variable. |
| Evidence and scope | Qualitative scope | Twelve99 transit clears ECN at Karlstad, while Málaga preserves it end to end. This difference matters for future L4S-style controllers [45, App. B]. |
| 證據與範圍 | 定性範圍 | 這是對正式網路的實地量測，僅下行，模型描述的是實際地面鏈路，ISL 速率、延遲與拓樸則待指定。 |
| 證據與範圍 | 定性範圍 | 唯一的模型是擬合到探測資料的單佇列模擬器。 |
| 證據與範圍 | 2025 · 5 · 10 | 主要站點是卡爾斯塔德一台第二代 Standard Actuated 終端，於 2025 年 5 月以硬體時間戳量測，次要站點馬拉加大學於 2025 年 10 月使用軟體時間戳，用來檢核丟棄機制與 ECN 行為可在其他終端與傳輸業者路徑上重現[45, §3, App. B]。 |
| 證據與範圍 | 120 · 30 · 15 · 2 | 120 種突發類型改變速率與長度、每種執行 30 次，所以統計是對受控突發的重複，背景流量則另屬觀測範圍，而 15 秒重組只在 §2 作為背景出現，列為背景因素。 |
| 證據與範圍 | 定性範圍 | 兩條路徑都檢查了 ECN，發現卡爾斯塔德的 Twelve99 傳輸段會清除標記，馬拉加則端到端保留，這對後續任何 Starlink 上的 L4S 類控制器都很重要[45, App. B]。 |
5. What was measured5. 量到了什麼
| Claim宣稱 | Setup and caveat設定與附註 |
|---|---|
| Single per-user queue, shared-queue scheduling: 10 CUBIC + 10 BBRv1 flows, BBRv1 takes a much larger share later [45, §4, Fig. 2]每位使用者單一佇列、採用共用佇列排程：10 條 CUBIC + 10 條 BBRv1，BBRv1 後期拿走明顯更大份額[45, §4, Fig. 2] | Live downlink, one terminal. Shown as a figure, share percentages unspecified in the text實地下行、單一終端。以圖呈現，份額百分比待補充 |
| Drop-front discipline. Same 1,500-packet queue at 124 Mbps: mean delay 85 ms drop-front vs 122 ms drop-tail [45, §6, Figs. 3–4]丟前端機制。同一個 1,500 封包、124 Mbps 的佇列：平均延遲丟前端 85 ms 對丟尾端 122 ms[45, §6, Figs. 3–4] | Simulator fitted by hand to the per-packet delay pattern. The 122 ms is a simulation result以人工把模擬器擬合到逐封包延遲模式。122 ms 來自模擬，實際觀測值另列 |
| Queue size ~1,400–1,600 packets, with a packet-count limit. CoDel-like control excluded from AQM, plateau delay 30–60 ms across runs [45, §7, Figs. 5, 7]佇列大小約 1,400–1,600 封包、以封包數設定容量上限。CoDel 類 AQM 列於模型之外，高原延遲各次執行間 30–60 ms[45, §7, Figs. 5, 7] | Fit quality varies. One run had 53% empirical vs 35% simulated loss各次擬合品質有差異。某次執行實測 53% 對模擬 35% 遺失 |
| Loss placement reproduced by a 1-frame-access / 3-frame-access-idle pattern at the 1.33 ms frame. Queue sits ahead of the allocating bottleneck [45, §6]以 1.33 ms 幀下「1 幀有存取 / 3 幀存取閒置」的模式重現遺失位置。佇列位於分配瓶頸之前[45, §6] | Physical location (satellite or gateway) undetermined實體位置（衛星或閘道）待確定 |
| Near-zero loss for bursts ≤1,000 packets and at 48/96 Mbps (≥ ~96 Mbps available). 6,000-packet 500 Mbps burst: 87 ms mean OWD, 55% loss. Fitted drain 33–218 Mbps [45, §5, §8]≤1,000 封包的突發與 48/96 Mbps 下遺失接近零（至少約 96 Mbps 可用）。6,000 封包、500 Mbps 突發：平均 OWD 87 ms、遺失 55%。擬合排空 33–218 Mbps[45, §5, §8] | Load-dependent drain adaptation appeared in some runs. The simulator keeps the drain-rate setting fixed部分執行觀察到隨負載調整的排空，系統性量測則待完成。模擬器忽略速率調整 |
| ECN bleached in Twelve99 transit at Karlstad, preserved end to end at Málaga [45, App. B]ECN 在卡爾斯塔德的 Twelve99 傳輸段被清除、在馬拉加端到端保留[45, App. B] | Two paths only. L4S and BBR-specific evaluation pending僅兩條路徑。L4S 與 BBR 專屬評估待完成 |
6. Limits and open questions6. 範圍與待解問題
- The fit is manual. Queue size, drain rate and discipline were adjusted by eye until simulated and empirical traces matched, using visual comparison. The simulator ignores the drain-rate adaptation the authors themselves observed. Thus, the 1,400–1,600-packet range and the 85 versus 122 ms comparison are fitted descriptions rather than measured constants [45, §7–9].擬合是人工的。佇列大小、排空速率與丟棄機制靠目測調整直到模擬與實測軌跡相符，僅採目測誤差比較，而且模擬器忽略了作者自己觀察到的排空速率調整，所以 1,400–1,600 封包的範圍與 85 對 122 ms 的比較是擬合出的描述，其適用條件應隨設定註明[45, §7–9]。
- The scope covers two downlink sites. Uplink queue behavior remains open, including the 10:1 asymmetry and roughly 30 Mbps saturation in the Fries study. SpaceX reports deploying fq_codel and resizing buffers in March 2024 company. The 2025 downlink observations show different behavior, so the relationship between those sources needs explanation.僅下行、兩地、一台主要終端。對上行佇列列於範圍之外，而 10:1 的方向差異與 Fries 等人看到的約 30 Mbps 飽和都在上行。SpaceX 也可隨時更改組態，就像它自稱在 2024 年 3 月部署 fq_codel 並調整緩衝區大小那樣 company。2025 年探測到的下行顯示共享 FIFO 排程及佇列長度式丟棄行為，與該說法存在差異，兩個來源都對這項差異的說明待補充。
- CUBIC utilization needs a controlled test. Prior work reports CUBIC below one-quarter of BBR throughput and TCP at 39% of UDP. Early front-drop loss could explain those results and synchronize flows. Controller tests against the fitted queue remain open [45, §6, §9].CUBIC 利用率較低的原因仍待對照實驗驗證。作者引用先前 CUBIC 低於 BBR 吞吐量四分之一、TCP 只有 UDP 39% 的報告，主張丟前端佇列的提早遺失可以解釋這些現象並可能使流同步，但他們針對擬合佇列的壅塞控制器測試待完成[45, §6, §9]。
- Packet-count limits have an unquantified real-time cost. Because the limit is in packets, small voice or game packets fill the queue with little byte volume, which the paper discusses qualitatively. The byte figure of 2.25 MB in the calc table is a derivation for 1,500-byte packets, a direct derivation for this primer.以封包數為限對即時流量的代價待量化。由於上限以封包數計，小的語音或遊戲封包會以很少的位元組量填滿佇列，論文提到卻待量測。計算表中 2.25 MB 的位元組數是對 1,500 位元組封包的推導，屬於本教材的直接推導。
- The values use the preprint. The accepted IMC 2026 paper is represented here by arXiv 2605.27717v1. Proceedings section numbers and values may change. Scheduled reconfiguration supplies background context for the queue analysis.本導讀使用預印本版本。論文已被 IMC 2026 接受，但此處數字來自 arXiv 2605.27717v1，章節編號甚至數值在會議版可能相異，而 15 秒重組在本文中只作為背景，佇列行為量測另有其控制條件。
7. How it connects7. 與其他內容的關聯
- Section 6.2: the queue, the drop-front panel and the 85 versus 122 ms comparison.第 6.2 節：佇列、丟前端面板與 85 對 122 ms 的比較。
- Section 6.1: what the sender sees, where the early loss signal joins the reconfiguration swings as a second non-congestive disturbance.第 6.1 節：傳送端看到什麼，提早的遺失訊號在此與重組擺盪並列為第二種由接入機制引起的擾動。
- Section 6.4: fairness, since a shared queue with shared-queue scheduling is the environment in which SaTCP's starvation of CUBIC would play out.第 6.4 節：公平性，因為採共用排程的佇列正是 SaTCP 餓死 CUBIC 會發生的環境。
- Section 3.4: the bufferbloat and queue rows of the measured-performance table. Section 3.1 for the 1.333 ms frame the 1:3 access pattern is synchronized to. Section 3.5 for the scheduler the queue sits in front of.第 3.4 節：實測性能表中的緩衝膨脹與佇列列。第 3.1 節談 1:3 存取模式所同步的 1.333 ms 幀。第 3.5 節談佇列前方的排程器。
- Related studies: Kassem et al. and Michel et al. measure loss and underuse, while Mohan et al. examines bufferbloat. LeoCC and SaTCP develop controllers, and Fries et al. studies uplink behavior.同組導讀：Kassem 等人與 Michel 等人談這個佇列可能解釋的遺失與低利用率，Mohan 等人談緩衝膨脹，LeoCC 與 SaTCP 是必須在它後方運作的傳送端，Fries 等人則涵蓋本文範圍之外的上行側。
Key numbers關鍵數字
| Number | 數字 | Meaning (setup) | 意義（設定） |
|---|---|---|---|
| >10 M · 120 × 30 | Hardware-timestamped probes. Burst types × repetitions (~325,000 probes per set) [45, §3] | 硬體時間戳探測數。突發類型 × 重複次數（每組約 325,000 個探測）[45, §3] | |
| 1,400–1,600 pkts | Typical downlink queue size, limited in packets rather than bytes [45, §7] | 典型下行佇列大小，以封包數設定容量上限[45, §7] | |
| 85 vs 122 ms | Mean delay, drop-front vs drop-tail, same 1,500-packet queue at 124 Mbps drain [45, §6] | 平均延遲，丟前端對丟尾端，同一個 1,500 封包、124 Mbps 排空的佇列[45, §6] | |
| 30–60 ms | Plateau delay variation across runs, evidence against a CoDel-like AQM [45, §7] | 各次執行間的高原延遲變化，反證 CoDel 類 AQM[45, §7] | |
| 1 : 3 at 1.33 ms | Frame-access pattern (one access frame, three idle frames) reproducing loss placement [45, §6] | 重現遺失位置的幀存取模式（一幀存取、三幀閒置）[45, §6] | |
| ≥ ~96 Mbps | Capacity implied by near-zero loss at 48 and 96 Mbps and for bursts ≤1,000 packets [45, §5] | 由 48 與 96 Mbps 及 ≤1,000 封包突發遺失接近零推得的容量[45, §5] | |
| 87 ms · 55% | Mean OWD and loss of a 6,000-packet burst at 500 Mbps [45, §5] | 500 Mbps、6,000 封包突發的平均 OWD 與遺失[45, §5] | |
| 33–218 Mbps | Range of fitted drain rates across runs [45, §5, §8] | 各次執行擬合出的排空速率範圍[45, §5, §8] | |
| ~12 ms | Non-Starlink part of the Karlstad path delay [45, §3] | 卡爾斯塔德路徑延遲中的地面部分[45, §3] | |
| 2.25 MB · 145 ms | Queue bytes and full-queue drain time for 1,500-byte packets at 124 Mbps (computed, calc table) | 1,500 位元組封包、124 Mbps 下的佇列位元組數與滿載排空時間（計算值，見計算表） |