A Browser-side View of Starlink Connectivity從瀏覽器端看 Starlink 連線

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

Two Starlink measurement papers appeared at IMC 2022 and they are complementary rather than redundant. Michel et al. used controlled probes at one Belgian dish for five months, with a CUBIC-only QUIC stack. Their results give precise local loss and latency statistics. Kassem et al. trade precision for breadth through a browser extension and three low-cost nodes on three continents.

The two papers therefore answer different questions. The congestion-controller comparison belongs to Kassem et al. Michel et al. provide a separate CUBIC-only study (factbase Part C item 4). This is the earliest published evidence that loss-tolerant, model-based BBR leaves a large share of Starlink capacity unused. This is the symptom that SaTCP, the HotNets 2024 study and LeoCC later set out to explain and cure.

IMC 2022 同時出現兩篇 Starlink 量測論文，兩者提供互補證據。Michel 等人在比利時用一台天線量了五個月，探測受控，QUIC 協定堆疊只用 CUBIC，因而對單一觀測點給出精確的遺失與延遲統計。Kassem 等人則以廣度換取精度，透過瀏覽器擴充套件招募一般使用者，並在三個大陸各放一台便宜的量測節點。兩篇論文回答的是各種的問題，而事實庫也明確指出壅塞控制器的比較屬於 Kassem 等人（事實庫 Part C 第 4 項）。對傳輸層這一章而言，本文提供了最早發表的證據，顯示像 BBR 這種容忍遺失、基於模型的傳送端在 Starlink 上會留下大量剩餘容量，而這正是 SaTCP、HotNets 2024 研究與 LeoCC 之後試圖解釋並修正的症狀。

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

瀏覽器端的觀測以網頁傳輸時間為核心，也就是頁面載入時間中純屬網路的部分。

The Raspberry Pi nodes add the transport-level picture.Raspberry Pi 節點補上傳輸層的圖像。

3. The design3. 設計

This is a measurement paper. Thus, its design is the measurement apparatus and the congestion-control experiment it enables. The browser extension reports page transit time, page load time and speed tests against a Google Cloud server in Iowa. The server stays fixed while clients span several cities.

The Pi nodes schedule speed tests, iperf3 sessions, traceroutes and congestion-control trials. Linux permits sender-algorithm changes per socket. The authors therefore ran BBR, CUBIC, Reno, Veno and Vegas sequentially over the same dish. A concurrent UDP burst provided the capacity reference for each run.

The campus Wi-Fi control matters because it shows that the same kernels reach more than 90% of UDP capacity on a conventional access network. Thus, the gap on Starlink is a property of the path and with the same test harness held fixed ^{[46, Fig. 8]}.

這是一篇量測論文，所以它的設計就是量測裝置以及由此得以進行的壅塞控制實驗。擴充套件坐在使用者的瀏覽器裡，回報網頁傳輸時間、頁面載入時間，以及對愛荷華 Google Cloud 伺服器的速度測試，這讓伺服器端固定、客戶端則分布於各種城市。Pi 節點依固定時程執行速度測試、iperf3、traceroute 與壅塞控制試驗，而由於同一個 Linux 核心可以逐個 socket 切換傳送端演算法，作者得以在同一台天線上接連跑 BBR、CUBIC、Reno、Veno 與 Vegas，並各自對照同時以 UDP 突發量到的容量。校園 Wi-Fi 的對照組很重要，因為它顯示同樣的核心在傳統接取網路上能達到 UDP 容量的 90% 以上，所以 Starlink 上的差距是路徑的性質，對照組則顯示工具能充分使用地面路徑容量^{[46, Fig. 8]}。

4. Evaluation setup4. 實驗設定

Everything here is live measurement on the production Starlink network of December 2021 to mid-2022, using live observations and FCC-derived visibility parameters. The paths use bent-pipe user links to a nearby point of presence. Before the February–April 2022 AS migration, these were typically Google Cloud locations. Thus, the paths use ground links exclusively, placing ISL rate, latency and topology outside the results.

The three Pi nodes give controlled, repeated measurements at fixed sites while the extension gives breadth at the cost of control. The congestion-control comparison was run on the Pi nodes against the Iowa server with a UDP burst as the capacity reference. Because each algorithm ran in a separate session, the comparison is sequential rather than simultaneous. The paper reports it as a figure with tabulated throughput values still pending.

這裡的一切都是在 2021 年 12 月到 2022 年中的正式 Starlink 網路上做的實地量測，證據全部來自實地觀測，星座資訊僅採用 FCC 的可見性參數。路徑是通往附近接入點的彎管式用戶鏈路，論文描述該接入點在 2022 年 2 至 4 月的 AS 遷移之前通常是一處 Google Cloud 機房，因此路徑只含彎管用戶鏈路，結果裡也計算範圍排除任何 ISL 速率、延遲或拓樸假設。三台 Pi 節點在固定地點提供受控且可重複的量測，擴充套件則以犧牲控制為代價換取廣度，而壅塞控制比較是在 Pi 節點上對愛荷華的伺服器進行，以 UDP 突發作為容量參考。由於每種演算法各在獨立的連線中執行，比較是依序進行，同時對照仍待補充的，而且論文以圖呈現，吞吐量以圖呈現。

5. What was measured5. 量到了什麼

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

• The sample is small and self-selected. The sample has eighteen Starlink users in ten cities, sparse nighttime data, uncontrolled dish placement and local Wi-Fi. It supports exploratory geographic comparisons. The authors label their claims of 2.3× USA delay and 2.6× lower throughput relative to the UK as speculative.樣本小且自我選擇。十個城市的 18 位 Starlink 使用者，夜間資料稀少，天線擺放與本地 Wi-Fi 皆由使用者自行決定，僅支持把「美國使用者延遲是英國 2.3 倍、吞吐量低 2.6 倍」視為探索性結果，作者自己也把地理結論標為推測。
• The headline congestion-control number requires a numerical table. The "about half of UDP capacity" result is read from Fig. 8. Thus, a chapter can quote the ratio with absolute Mbps still requiring a reported value for BBR or CUBIC. The sequential test design mixes time-of-day capacity changes with algorithm behavior.壅塞控制比較以圖呈現比例。「約 UDP 容量一半」是從 Fig. 8 讀出的，章節可以引用比例，BBR 或 CUBIC 的絕對 Mbps 則須從原圖估讀，而依序測試需要同時對照，才能分離日內容量變化與演算法行為。
• The handover explanation is now known to be incomplete. The authors align loss clusters with serving satellites leaving the line of sight. Tanveer et al. ^[13] and Mohan et al. ^[49] later identify 15-second reconfiguration at :12/:27/:42/:57. It shifts latency even with one satellite visible. Garcia et al. ^[45] identify a queue that drops packets at its head. Factbase Part C item 35 records that these are three separate phenomena that the 2022 reading conflated.換手解釋需要後續發現的排程機制補充。論文把遺失叢歸因於服務衛星離開視線，但 Tanveer 等人^[13]與 Mohan 等人^[49]後來證明有一個每 15 秒、落在 :12/:27/:42/:57 秒的全域重組，即使只有一顆衛星可見也會讓延遲移位，而 Garcia 等人^[45]發現一個會在佇列前端造成遺失的丟前端佇列。事實庫 Part C 第 35 項記錄這是三個被 2022 年解讀混在一起的獨立現象。
• Why BBR stops at half remains an open question. The paper measures the gap with its mechanism still open. Candidate mechanisms include 10–65 Mbps reconfiguration swings that mislead BBR's bandwidth model, and early loss signals from the drop-front queue (Garcia et al.). Each still requires comparison with the 2022 dataset. ^[56]BBR 止步於一半的機制仍待解釋。論文量到了差距，機制仍待後續研究解釋。後來的候選解釋包括重組造成 10–65 Mbps 的容量擺盪誤導 BBR 的頻寬模型^[56]，以及丟前端佇列過早送出的遺失訊號（Garcia 等人），這些候選機制對這份 2022 年資料集的回溯驗證仍待完成。
• Bent pipe only, early fleet. All paths are single-hop user links to a nearby PoP in early 2022, so inter-satellite congestion control lies outside its scope. The throughput levels are those of a network that has since changed PoPs, autonomous systems and, by SpaceX's own account, queue configuration company.僅彎管路徑、早期機隊。所有路徑都是 2022 年初通往附近 PoP 的單跳用戶鏈路，跨星間鏈路壅塞控制屬於這些觀測範圍之外，而吞吐量水準也屬於一個之後已更換 PoP、自治系統，以及依 SpaceX 自述更換了佇列組態的網路 company。

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

• Section 6.1: what the sender sees, where the BBR ≈ ½ result and the loss clusters are introduced.第 6.1 節：傳送端看到什麼，BBR ≈ ½ 的結果與遺失叢在此引入。
• Section 6.2: the drop-front queue that offers a mechanism for the early loss signal this paper measured.第 6.2 節：丟前端佇列，為本文量到的過早遺失訊號提供一個機制。
• Section 6.3: the reconfiguration-aware controllers that try to recover the unused half.第 6.3 節：試圖找回那閒置一半的重組感知控制器。
• Section 3.4 and Section 3.5: the measured-performance table and the 15-second schedule that reinterprets the loss clusters.第 3.4 節與第 3.5 節：實測性能表，以及重新解讀遺失叢的 15 秒排程。
• Sibling digests: Michel et al. cover the CUBIC-only IMC 2022 study. Lai et al. [56] and LeoCC explain reconfiguration. SaTCP covers handover prediction. Garcia et al. cover queue behavior, Fries et al. handover alignment, and Mohan et al. the global view.同組導讀：Michel 等人是只跑 CUBIC 的 IMC 2022 單天線姊妹篇，Lai 等人[56]與 LeoCC 給出重組解釋，SaTCP 是換手預測的解方，Garcia 等人談佇列，Fries 等人談換手對齊，Mohan 等人提供全球視角。

Key numbers關鍵數字