Digest · Transport and congestion control · read after Chapter 6
導讀 · 傳輸層與壅塞控制 · 第 6 章後閱讀
Looking at Stars: Analyzing Real-Time Video Conferencing over Starlink仰望星空：分析 Starlink 上的即時視訊會議
This digest explains how Starlink reconfiguration misleads WebRTC’s delay estimator and lowers Teams’ uplink bitrate despite spare capacity. It also places handover-alignment statistics within the paper’s video-conferencing study.讀完後，你能說明為什麼一個輕鬆容納在 Starlink 終端容量內的 2.5 Mbps Teams 上行仍會掉到目標以下、WebRTC 基於延遲的壅塞估計器如何把 15 秒重組誤認為壅塞，以及為什麼這篇論文常被單獨引用的換手對齊統計，其實是一項視訊會議研究的副產品。
Main result
主要結果
Fries and colleagues show that WebRTC’s delay estimator mistakes Starlink reconfiguration for congestion. Teams then reduces its bitrate despite spare uplink capacity.
Fries 等人顯示，WebRTC 的延遲估計器會把 Starlink 重組誤判為壅塞，讓 Teams 在上行容量仍有餘裕時降速。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 2025 · 2026 · 2.5 | Fries, Matezki, Bose and Mohan tested original Teams and instrumented LibWebRTC senders from Munich, Delft, Oslo and McMurdo between November 2025 and April 2026. They examine below-target bitrate on a 2.5 Mbps uplink despite ample link capacity [51, §3–4]. |
| Latency comparison | Qualitative scope | The answer is that WebRTC's Google Congestion Control (GCC) is steered almost entirely by its delay-based estimator |
| Capacity and rate | 96.4–99.6% | which held the bandwidth estimate 96.4–99.6% of the time across the four sites |
| Latency comparison | 15 · 60.7–100% · 0.8 · 1–2 s | The estimator interprets Starlink's 15-second latency steps as congestion. Reconfiguration or handover coincides with 60.7–100% of overuse transitions. Teams loses about 0.8 Mbps within 1–2 s and recovers only partly over ten seconds [51, §4.1–4.2]. |
| Evidence and scope | 89% · 1 s · 12 · 27 · 42 · 57 · 97.6° · 208 · 678 · 30.7% | Handover alignment is a secondary result. At least 89% of European handovers fall within ±1 s of :12/:27/:42/:57 boundaries. McMurdo uses the 97.6° shell and ISLs to Sydney, with 208 of 678 handovers (30.7%) off-boundary [51, §4.2]. |
| Evidence and scope | Qualitative scope | The study measures the uplink only and leaves combined the polar shell, the ISL path and Antarctic weather as causes of McMurdo's weaker alignment. |
| 證據與範圍 | 2025 · 11 · 2026 · 4 · 2.5 | Fries、Matezki、Bose 與 Mohan 在 2025 年 11 月至 2026 年 4 月間，從慕尼黑、台夫特、奧斯陸與南極麥克默多站，透過 Starlink 執行原版 Microsoft Teams 與一個加裝量測的 LibWebRTC 傳送端，探問為什麼一條只需 Starlink 上行容量一小部分的 2.5 Mbps 上行視訊串流，仍會跌到目標位元率以下[51, §3–4]。 |
| 證據與範圍 | 96.4–99.6% · 15 · 60.7–100% · 1–2 · 0.8 | 答案是 WebRTC 的 Google 壅塞控制（GCC）幾乎完全由其基於延遲的估計器主導，在四個站點中該估計器有 96.4–99.6% 的時間掌控頻寬估計值，而這個估計器會把 Starlink 15 秒重組造成的延遲階躍讀成壅塞，因為它 60.7–100% 的過載轉換與重組或天線換手同時發生，而 Teams 上行位元率在重組後 1–2 秒內下降約 0.8 Mbps，接下來十秒也只部分恢復[51, §4.1–4.2]。 |
| 證據與範圍 | 89% · 12 · 27 · 42 · 57 · 1 · 97.6° · 678 · 208 · 30.7% | 換手對齊是論文的副結果，主題則是視訊會議：在三個歐洲站點，至少 89% 的天線換手落在 :12/:27/:42/:57 邊界的 ±1 秒內，而由 97.6° 極地殼層服務、經星間鏈路送到雪梨 PoP 的麥克默多站，678 次換手中有 208 次（30.7%）偏離排程邊界的[51, §4.2]。 |
| 證據與範圍 | 定性範圍 | 這項研究只量測上行，也將極地殼層、ISL 路徑與南極天氣分開，作為麥克默多對齊較弱的原因。 |
1. Where this paper sits1. 這篇論文的位置
Earlier Starlink transport work focused on bulk TCP. This study examines real-time GCC behavior and distinguishes scheduled reconfiguration, dish handover and queue effects.
早期 Starlink 傳輸研究著重大量 TCP 傳輸，本研究轉向即時 GCC 行為，並區分排程重組、天線換手及佇列效應。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 2024 | Earlier work examines bulk TCP. Kassem et al. find BBR using about half the UDP-measured capacity. SaTCP, HotNets patches and LeoCC add reconfiguration awareness, while Mohan et al. provide an early media study. |
| Latency comparison | 52 · 14 ms · 27 · 7 ms · 146 · 99 · 2 | [49] gives Zoom uplink delay of 52 ± 14 ms, versus terrestrial 27 ± 7 ms. FEC rates are 146 ± 99 versus 2 ± 2 kbps [51, Fig. 10]. |
| Capacity and rate | Qualitative scope | Fries et al. examine GCC, the WebRTC controller used in Teams, Meet and most browser calls. The modest encoder cap usually leaves spare link capacity. |
| Latency comparison | 2022 · 12 · 27 · 42 · 57 | Earlier studies disagree on attribution. Kassem et al. linked 2022 loss clusters to handover. Tanveer et al. located latency changes at :12/:27/:42/:57 boundaries. |
| Evidence and scope | Qualitative scope | and Mohan et al. saw those shifts even with a single satellite in view |
| Evidence and scope | 35 | which led the fact base to record scheduled reconfiguration, dish handover and the drop-front queue as three separate phenomena (factbase Part C item 35). |
| Dataset and workload | 8 | Fries et al. separate handover effects in a video-conferencing study. The fact base identifies that application context as the appropriate citation scope (Part C item 8). |
| 證據與範圍 | 2024 | 早期關於 Starlink 的傳輸層研究集中在大量傳輸的 TCP 上：Kassem 等人發現 BBR 只達到 UDP 量得容量的一半左右，SaTCP、HotNets 2024 修補與 LeoCC 則各自打造了能感知重組的傳送端。 |
| 證據與範圍 | 52 · 14 ms · 27 · 7 ms · 146 · 99 · 2 · 10 | 即時媒體只在 Mohan 等人[49]有過初步觀察，其 Zoom 上行單向延遲 52 ± 14 ms 對地面網路 27 ± 7 ms，同時前向錯誤更正達 146 ± 99 kbps 對 2 ± 2 kbps（Mohan 等人 Fig. 10）。 |
| 證據與範圍 | 定性範圍 | Fries 等人把問題帶到另一種應用：它的壅塞控制器採用內建於 WebRTC、因而也內建於 Teams、Meet 與大多數瀏覽器通話中的 GCC，而它的編碼器被限制在較低速率，使容量很少成為真正的限制。 |
| 證據與範圍 | 2022 · 12 · 27 · 42 · 57 · 35 | 這篇論文也承接了一場關於成因的爭論：Kassem 等人在 2022 年把遺失叢歸因於衛星換手，Tanveer 等人隨後把延遲狀態轉變定位在每分鐘的第 12、27、42 與 57 秒，Mohan 等人則在只有一顆衛星可見時仍看到這些轉變，使事實庫把排程重組、天線換手與丟前端佇列記錄為三個相異的現象（事實庫 Part C 第 35 項）。 |
| 證據與範圍 | 8 | Fries 等人補上了這個區分中換手的那一環，這也是它有時被當成換手研究引用的原因。事實庫 Part C 第 8 項記載，它應該以其本質，即一篇視訊會議論文，被引用。 |
2. The problem, measured2. 問題，用量測說話
Median performance stays near the Teams target, while tail samples reveal repeated shortfalls. Their timing points to sender decisions as the immediate cause.
中位數接近 Teams 目標，尾端樣本卻顯示反覆降速，其發生時序指向傳送端決策這個直接原因。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 2.5 · 720 · 30 · 2.51 · 2.52 · 75% | Teams targets 2.5 Mbps at 720p and 30 frames/s. Median rates are 2.51 Mbps on Starlink and 2.52 Mbps terrestrially. Both reach 30 FPS about 75% of the time [51, §4.1, App. B.3]. |
| Dataset and workload | 0.375 · 34.9% · 24.8% · 5.7% · 2.7% | The shortfall measure counts samples more than 0.375 Mbps below target. Shares are McMurdo 34.9%, Oslo 24.8%, Munich 5.7% and Delft 2.7% [51, §4.1, Figs. 2–3]. |
| Evidence and scope | 46.3% · 32.0% · 5.5% · 4.9% | The share of that below-target time attributable to reconfigurations was 46.3% at McMurdo, 32.0% in Oslo, 5.5% in Delft and 4.9% in Munich. Thus, the reconfiguration explains almost half of the shortfall where the shortfall is largest and little of it where the call is already healthy. |
| Reliability and accuracy | 0.8 · 1–2 s · 1.65 | Reconfiguration cuts bitrate by about 0.8 Mbps within 1–2 s. Recovery remains partial after ten seconds, when McMurdo's median is still 1.65 Mbps [51, §4.1]. |
| Capacity and rate | 30 · 2.5 | European saturating uplinks reach about 30 Mbps. A 2.5 Mbps call uses roughly one-twelfth of capacity, so sender rate reduction explains the shortfall despite spare capacity. |
| 證據與範圍 | 720 · 30 · 2.5 · 2.51 · 2.52 · 75% | 中位數顯示整體表現接近正常，因為 Teams 在 720p、每秒 30 幀時把上行限制在 2.5 Mbps，而 Starlink 上的位元率中位數是 2.51 Mbps，地面線路是 2.52 Mbps，兩者約有 75% 的時間達到 30 FPS[51, §4.1, App. B.3]。 |
| 證據與範圍 | 0.375 · 34.9% · 24.8% · 5.7% · 2.7% | 困難藏在尾端：作者以低於目標超過 0.375 Mbps 的樣本比例來量測，這個比例在麥克默多達 34.9%、奧斯陸 24.8%、慕尼黑 5.7%、台夫特 2.7%[51, §4.1, Figs. 2–3]。 |
| 證據與範圍 | 46.3% · 32.0% · 5.5% · 4.9% | 這些低於目標的時間中可歸因於重組的比例，在麥克默多是 46.3%、奧斯陸 32.0%、台夫特 5.5%、慕尼黑 4.9%，所以在缺口最大的地方，重組解釋了將近一半的缺口，而在通話本來就健康的地方只解釋了一小部分。 |
| 證據與範圍 | 1–2 · 0.8 · 1.65 | 典型事件是位元率在重組後 1–2 秒內下降約 0.8 Mbps，接著的恢復在十秒後仍只是部分恢復，麥克默多的中位數此時仍停在 1.65 Mbps[51, §4.1]。 |
| 證據與範圍 | 30 · 2.5 | 由於同一篇論文中，飽和其配額的歐洲上行流可達約 30 Mbps，一通 2.5 Mbps 的通話只用了可用上行的大約十二分之一（見下方計算），這表示下降來自傳送端自行降速，鏈路容量仍有餘裕。 |
3. The design3. 設計
Instrumented WebRTC exposes the bandwidth estimators alongside live packet probes. Reconfiguration creates a delay gradient that can trigger GCC’s overuse state.
加裝量測的 WebRTC 配合實際封包探測，揭露頻寬估計器的狀態。重組造成的延遲梯度可能觸發 GCC 過載判定。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | The study is built to see inside the congestion controller as well as at the wire. |
| Evidence and scope | 143 · 142 · 8593 | Original Teams runs in headless Chromium 143 through DevTools. Instrumented Chromium 142 LibWebRTC exposes GCC state. Pion sends synthetic RFC 8593 video with congestion control disabled or SCReAMv1 enabled. |
| Evidence and scope | 50 ms | WebRTC statistics are logged every 50 ms alongside IRTT and ICMP probes [51, §3]. |
| Capacity and rate | Qualitative scope | GCC itself keeps two estimates of available bandwidth and sends at the lower of them. |
| Latency comparison | Qualitative scope | The loss estimate follows receiver-reported loss. The delay estimate follows one-way delay variation between packet groups. It reduces rate in the overuse state because rising delay suggests queue growth. |
| Latency comparison | Qualitative scope | That design is sound on a wired path, where delay rises only when a queue grows |
| Latency comparison | 15 | but on Starlink the 15-second reconfiguration reallocates satellites and frames and moves the latency in a step |
| Evidence and scope | 74 ms · 140 ms | which Casparsen et al. measure as a start-of-period spike averaging about 74 ms above the period mean within the first 140 ms [57, Fig. 3] preprint |
| Latency comparison | Qualitative scope | so the trend filter sees a delay gradient that arises from reconfiguration and declares overuse at a moment when capacity may be unchanged or larger. |
| 證據與範圍 | 定性範圍 | 這項研究的設計是要同時看進壅塞控制器內部與線路上。 |
| 證據與範圍 | 143 · 142 · 8593 | Teams 在背景執行的 Chromium 143 中原版地執行，由 DevTools 協定驅動，另一個以 Chromium 142 自建的 LibWebRTC 則揭露 GCC 的內部狀態，而以 Pion 為基礎、各自停用壅塞控制與採用 SCReAMv1 的傳送端，發送合成的 RFC 8593 視訊流量作為基準。 |
| 證據與範圍 | 50 ms | WebRTC 統計每 50 ms 記錄一次，並搭配 IRTT 與 ICMP 探測[51, §3]。 |
| 證據與範圍 | 定性範圍 | GCC 本身維持兩個可用頻寬估計，並以兩者中較低者發送。 |
| 證據與範圍 | 定性範圍 | 基於遺失的估計對接收端回報的封包遺失比例做出反應，基於延遲的估計則觀察封包群組之間單向延遲變化的趨勢，在過載、正常與欠載三種狀態間移動，並在宣告過載時降低速率，因為延遲梯度上升是它判斷佇列正在累積的訊號。 |
| 證據與範圍 | 定性範圍 | 這個設計在有線路徑上是合理的，因為延遲只會在佇列增長時上升。 |
| 證據與範圍 | 15 · 140 ms · 74 ms | 但在 Starlink 上，15 秒重組會重新分配衛星與幀，讓延遲以階躍方式移動，Casparsen 等人量得週期起始的前 140 ms 內平均比週期均值高約 74 ms 的尖峰[57, Fig. 3]預印本，於是趨勢濾波器看到一個來自重組的延遲梯度，在容量可能維持固定甚至更大的時刻宣告過載。 |
The study labels reconfiguration from earlier timing evidence and detects dish handovers from obstruction maps. Its attribution window is a stated heuristic.
研究依先前時序證據標記重組，並從遮蔽圖辨識天線換手，事件歸因窗口則採用明列的啟發式方法。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | Qualitative scope | Two event labels make this testable. |
| Evidence and scope | 12 · 27 · 42 · 57 · 1 · 1 s | Prior work supplies the synchronized :12/:27/:42/:57 labels. Dish handovers come from angular shifts in consecutive obstruction maps, polled through gRPC at 1 Hz. Alignment means within ±1 s of reconfiguration [51, §3, §4.2]. |
| Evidence and scope | 1.5 s · 15% | Attribution uses a 1.5 s event window and a 15% threshold. The authors identify this rule as a heuristic. |
| Evidence and scope | 5–10 | A satellite remains visible for 5–10 minutes, so only a few of the four reconfigurations per minute involve handover. Separate labels allow separate effect comparisons. |
| Capacity and rate | 50 ms · 0.31 · 0.18 · 0.15 · 0.12 | Handovers cause longer overuse and larger rate cuts. Duration gaps exceed 50 ms at McMurdo and Munich. Median cuts are Oslo 0.31, McMurdo 0.18, Munich 0.15 and Delft 0.12 Mbps [51, §4.2, Fig. 6]. |
| 證據與範圍 | 定性範圍 | 兩種事件標籤讓這件事可以被檢驗。 |
| 證據與範圍 | 12 · 27 · 42 · 57 | 重組錨定在先前研究得出、全球同步的 :12、:27、:42 與 :57 邊界，其依據是先前研究。 |
| 證據與範圍 | 1 | 天線換手則從終端 gRPC 介面以 1 Hz 輪詢所回傳的連續遮蔽圖之間的角度位移來辨識，換手落在某次重組的 ±1 秒內時稱為規則換手，窗口之外則為偏離排程邊界的換手[51, §3, §4.2]。 |
| 證據與範圍 | 1.5 · 15% | 過載轉換與低於目標的時段，若落在某事件的 1.5 秒窗口內並超過 15% 門檻，就歸因於該事件，這是作者公開說明的啟發式方法。 |
| 證據與範圍 | 5–10 | 由於一顆衛星通常在天線換手前保持可見 5–10 分鐘，每分鐘四次重組中只有極少數伴隨換手，因此兩種標籤對應相異事件，論文也才能各自探問換手與單純重組何者傷害較大。 |
| 證據與範圍 | 50 ms · 0.31 · 0.18 · 0.15 · 0.12 | 結果顯示換手造成較長的過載期與較大的發送速率削減，在麥克默多與慕尼黑的持續時間差距超過 50 ms，發送速率變化中位數在奧斯陸為 0.31 Mbps、麥克默多 0.18、慕尼黑 0.15、台夫特 0.12[51, §4.2, Fig. 6]。 |
Original figure note原始圖說出處
Drawn for this primer from Fries, Matezki, Bose & Mohan, IMC 2026, §3, §4.1–4.2, Figs. 2–3, 6. Boundary seconds from Tanveer et al., CoNEXT 2023 Companion.Original figure note原始圖說出處
Drawn for this primer from Fries, Matezki, Bose & Mohan, IMC 2026, §4.1–4.2, Figs. 2–3.| Question | 問題 | Formula | 公式 | Result | 結果 |
|---|---|---|---|---|---|
| How often would a randomly timed handover land within ±1 s of a 15-s boundary by chance?隨機時間點發生的換手，偶然落在 15 秒邊界 ±1 秒內的機率是多少？ | \( p = \dfrac{2\ \text{s}}{15\ \text{s}} \) | 13.3% computed. Window from §4.2, period from Tanveer et al. Both the ≥89% European and the 69.3% McMurdo alignment are far above this chance level.計算值。窗口取自 §4.2，週期取自 Tanveer 等人。歐洲 ≥89% 與麥克默多 69.3% 的對齊率都遠高於這個偶然水準。 | |||
| What share of McMurdo handovers was aligned?麥克默多的換手有多少比例是對齊的？ | \( \dfrac{678 - 208}{678} \) | 69.3% computed from the 208 of 678 off-boundary handovers in §4.2.由 §4.2 的 678 次中 208 次偏離排程邊界的換手計算。 | |||
| What fraction of the Teams target is lost in a 0.8 Mbps drop?0.8 Mbps 的下降佔 Teams 目標的多少比例？ | \( \dfrac{0.8}{2.5} \) | 32% computed. Cap and drop from §4.1. The call falls to about 1.7 Mbps.計算值。上限與下降量取自 §4.1。通話降到約 1.7 Mbps。 | |||
| How many reconfiguration boundaries pass during one satellite's 5–10 min visibility?一顆衛星 5–10 分鐘的可見期間會經過多少次重組邊界？ | \( (5\text{–}10\ \text{min}) \times 4\ \text{min}^{-1} \) | 20–40 computed. Dwell from Fries et al., four boundaries per minute from Tanveer et al. Most reconfigurations therefore retain the dish’s serving satellite.計算值。停留時間取自 Fries 等人，每分鐘四次邊界取自 Tanveer 等人。因此對某一天線而言，大多數重組只涉及排程重組。 | |||
| What fraction of a saturated European uplink does a Teams call use?一通 Teams 通話佔飽和的歐洲上行多少比例？ | \( \dfrac{2.5\ \text{Mbps}}{\approx 30\ \text{Mbps}} \) | ≈ 8% computed. Both values from Fries et al. The shortfall comes from the sender’s decision while link capacity remains available.計算值。兩個數值皆取自 Fries 等人。缺口是傳送端的決定，，容量仍有餘裕。 |
4. Evaluation setup4. 實驗設定
The measurement covers uplink conferencing traffic at European and Antarctic LEOScope sites. The Antarctic path additionally carries traffic over ISLs to a distant PoP.
量測涵蓋歐洲與南極 LEOScope 站點的上行會議流量，南極路徑還經 ISL 將流量送往遠端 PoP。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Evidence and scope | 48 · 52 · 60 · 78 · 2025 · 2026 | LEOScope provides live measurements from Munich (≈48°N), Delft (≈52°N), Oslo (≈60°N) and McMurdo (≈78°S), spanning November 2025–April 2026 [51, §3]. |
| Evidence and scope | 97.6° | European sites use bent-pipe access to Frankfurt. McMurdo uses the 97.6° shell and ISLs to Sydney, making it the study's sole ISL call path. |
| Latency comparison | Qualitative scope | The study measures the live network. ISL rate, latency, topology and hop count on the McMurdo path remain unspecified. |
| Evidence and scope | 15 · 30 s · 10 · 7 · 2.5 · 13 · 19 | Runs last 15 minutes, with the first and last 30 s discarded. At 2.5 Mbps, video exceeds ten hours per site except Oslo's seven hours. Munich adds 13 hours at 10 Mbps, and Pion baselines add 19 hours. |
| Evidence and scope | 5 · 10 | The Delft node, a Raspberry Pi 5, was excluded from the 10 Mbps runs. |
| Evidence and scope | Qualitative scope | Every measurement is on the uplink, from the terminal toward the conferencing service. |
| 證據與範圍 | 2025 · 11 · 2026 · 4 · 48° · 52° · 60° · 78° | 這是在正式網路上的實地量測，於 2025 年 11 月至 2026 年 4 月間在慕尼黑（約北緯 48°）、台夫特（約北緯 52°）、奧斯陸（約北緯 60°）與麥克默多（約南緯 78°）的 LEOScope 節點上進行[51, §3]。 |
| 證據與範圍 | 97.6° | 三個歐洲站點經彎管抵達法蘭克福 PoP，麥克默多則由 97.6° 殼層服務，流量經星間鏈路送到雪梨 PoP，使它成為研究中唯一由 ISL 承載通話的路徑。 |
| 證據與範圍 | 定性範圍 | 論文待建立星座模型，因此陳述待補充 ISL 速率、ISL 延遲或拓樸，也回報待補充麥克默多路徑上的 ISL 跳數。 |
| 證據與範圍 | 15 · 30 · 2.5 · 10 · 7 · 13 · 19 | 每次執行 15 分鐘，捨棄頭尾各 30 秒，在 2.5 Mbps 下得到麥克默多、慕尼黑與台夫特各超過 10 小時、奧斯陸超過 7 小時的視訊，另有慕尼黑 10 Mbps 的 13 小時與 Pion 基準的 19 小時。 |
| 證據與範圍 | 5 · 10 | 台夫特節點是一台 Raspberry Pi 5，列於範圍之外 10 Mbps 的實驗。 |
| 證據與範圍 | 定性範圍 | 所有量測都在上行，即從終端往會議服務的方向。 |
Higher-rate Munich runs amplify the same controller response. A sender with congestion control disabled demonstrates spare capacity on the tested link.
慕尼黑的較高速率實驗放大了相同控制器反應，停用壅塞控制的傳送端則顯示測試鏈路仍有可用容量。
| Item項目 | Values數值 | Conditions and source條件與來源 |
|---|---|---|
| Capacity and rate | 10 | The 10 Mbps runs in Munich show the same mechanism at a rate where it bites harder. |
| Capacity and rate | 9.5% · 41.5% · 4.62% · 0.25% · 2.5 · 3.5% · 100 · 1.0% · 0% · 10 | At 10 Mbps, Teams meets bitrate targets 9.5% of time and frame-rate targets 41.5%. Loss-driven reductions rise from 0.25% to 4.62%. Loss affects 3.5% of 100-ms intervals versus 1.0%, yet median reconfiguration loss is 0%. A sender with congestion control disabled delivers 10 Mbps on the same link [51, §4.2, App. B.5–B.6, Fig. 8]. |
| Capacity and rate | Qualitative scope | The link can carry the rate, so the gap between what it carries and what Teams sends is the price of the controller's interpretation. |
| 證據與範圍 | 10 | 慕尼黑的 10 Mbps 實驗在一個影響更明顯的速率下展現了同一機制。 |
| 證據與範圍 | 9.5% · 41.5% · 2.5 · 0.25% · 4.62% · 100 ms · 1.0% · 3.5% · 0% · 10 | Teams 只有 9.5% 的時間達到目標位元率、41.5% 的時間達到目標幀率，基於遺失的降速從 2.5 Mbps 時的 0.25% 時間升到 4.62%，有遺失的 100 ms 區間從 1.0% 升到 3.5%，但重組周圍的遺失中位數是 0%，而一個停用壅塞控制的傳送端在同一條鏈路上能送出 10 Mbps[51, §4.2, App. B.5–B.6, Fig. 8]。 |
| 證據與範圍 | 定性範圍 | 鏈路承載得了這個速率，所以鏈路能承載的與 Teams 實際送出的之間的差距，就是控制器解讀方式的代價。 |
5. What was measured5. 量到了什麼
| Claim宣稱 | Setup and caveat設定與附註 |
|---|---|
| Delay-based GCC estimator controls the bandwidth estimate 96.4–99.6% of the time (AQ 99.0, DE 99.6, NL 99.1, NO 96.4) [51, §4.2]基於延遲的 GCC 估計器有 96.4–99.6% 的時間掌控頻寬估計（AQ 99.0、DE 99.6、NL 99.1、NO 96.4）[51, §4.2] | Instrumented LibWebRTC, 2.5 Mbps, uplink only加裝量測的 LibWebRTC，2.5 Mbps，僅上行 |
| 60.7–100% of overuse transitions attributable to reconfigurations or handovers (AQ 60.7% of 140, DE 100% of 35, NL 97.4% of 78, NO 91.0% of 78) [51, §4.2]60.7–100% 的過載轉換可歸因於重組或換手（AQ 140 次中 60.7%、DE 35 次中 100%、NL 78 次中 97.4%、NO 78 次中 91.0%）[51, §4.2] | Heuristic attribution with a 1.5 s window and 15% threshold. Time in overuse only 0.07–0.40%以 1.5 秒窗口與 15% 門檻的啟發式歸因。處於過載的時間只有 0.07–0.40% |
| Teams uplink drops ~0.8 Mbps within 1–2 s of a reconfiguration, partial recovery over 10 s (McMurdo median 1.65 Mbps at t = 10 s) [51, §4.1]Teams 上行在重組後 1–2 秒內下降約 0.8 Mbps，十秒內只部分恢復（麥克默多 t = 10 秒時中位數 1.65 Mbps）[51, §4.1] | Unmodified Teams at 720p30 with a 2.5 Mbps cap原版 Teams，720p30，上限 2.5 Mbps |
| Below-target share 34.9% AQ, 24.8% NO, 5.7% DE, 2.7% NL, of which reconfigurations explain 46.3%, 32.0%, 4.9%, 5.5% [51, §4.1]低於目標比例 AQ 34.9%、NO 24.8%、DE 5.7%、NL 2.7%，其中重組各自解釋 46.3%、32.0%、4.9%、5.5%[51, §4.1] | Margin of 0.375 Mbps below target. Median bitrate 2.51 vs 2.52 Mbps terrestrial以低於目標 0.375 Mbps 為界。位元率中位數 2.51 對地面 2.52 Mbps |
| ≥89% of handovers within ±1 s of a boundary at DE/NL/NO. 208 of 678 (30.7%) off-boundary at McMurdo [51, §4.2]DE/NL/NO 至少 89% 的換手在邊界 ±1 秒內。麥克默多 678 次中 208 次（30.7%）偏離排程邊界的[51, §4.2] | Handovers inferred from 1 Hz obstruction maps. Boundaries assumed from prior work, taken from prior work換手由 1 Hz 遮蔽圖推斷。邊界取自先前研究的時程假設 |
| Handovers cause longer overuse (gap >50 ms at AQ, DE) and larger send-rate cuts (medians 0.12–0.31 Mbps) than plain reconfigurations [51, §4.2, Fig. 6]換手比單純重組造成更長的過載（AQ、DE 差距 >50 ms）與更大的發送速率削減（中位數 0.12–0.31 Mbps）[51, §4.2, Fig. 6] | 21 of McMurdo's off-boundary handovers triggered delay-based overuse麥克默多的偏離排程邊界的換手中有 21 次觸發基於延遲的過載 |
| At 10 Mbps (Munich), target bitrate met 9.5% of the time while a sender with congestion control disabled delivers 10 Mbps [51, §4.2, App. B.5–B.6]在 10 Mbps（慕尼黑）下只有 9.5% 的時間達到目標位元率，而停用壅塞控制的傳送端能送出 10 Mbps[51, §4.2, App. B.5–B.6] | One site only. Delft excluded只有一個站點。台夫特列於範圍之外 |
6. Limits and open questions6. 範圍與待解問題
- McMurdo combines several changed conditions. Its polar shell, ISL path to Sydney and weather differ from the European sites. Their effects remain combined. Attributing the 30.7% off-boundary share or 46.3% reconfiguration-related shortfall specifically to ISLs therefore needs additional evidence.麥克默多的成因相互混淆。南極站點與歐洲站點在殼層（97.6° ，歐洲使用中傾角殼層）、路徑（經 ISL 到雪梨，歐洲則經彎管到法蘭克福）與天氣上都相異，論文將這些因素合併觀察，所以 30.7% 的偏離排程邊界的比例與 46.3% 歸因於重組的缺口，歸因於 ISL 路由仍需各自證據。
- Labels combine coarse observations and assumed timing. One-hertz polling gives the same time resolution as the ±1 s alignment window. Boundaries come from Tanveer et al., so schedule changes could invalidate the labels. Attribution also uses a stated 1.5 s window and 15% heuristic threshold. A random event enters the alignment band about 13.3% of the time. Observed alignment exceeds that baseline, while attribution percentages still need an equivalent comparison.事件標籤粗略，且部分出於假設。換手是透過 1 Hz 輪詢的遮蔽圖觀察的，因此偵測解析度與決定換手如何規則的 ±1 秒窗口同樣大小。而邊界取自 Tanveer 等人，其量測來源是先前研究，這表示 15 秒排程後續若改變，就需要更新事件標籤。過載與缺口的歸因使用作者自稱為啟發式的 1.5 秒窗口與 15% 門檻，而隨機事件約有 13.3% 的時間會落在 ±1 秒帶內（見計算表），對齊百分比遠高於這個基準，但歸因百分比與此基準的比較則待補充。
- The measurement covers uplink Teams traffic and one controller family. The downlink, where Garcia et al. Characterised the queue, remains outside the measurement scope, Zoom and Meet remain outside the measurement scope. The Pion and SCReAM baselines send synthetic RFC 8593 traffic rather than a real encoder's output. A reconfiguration-aware controller remains to be tested. A controller in the style of LeoCC is tried for real-time media. The detector the authors sketch would need more frequent RTCP feedback than Teams sends, so the remedy remains a proposal.量測範圍涵蓋 Teams 上行與單一控制器家族。下行，也就是 Garcia 等人刻畫佇列的方向，量測待完成。Zoom 與 Meet 量測待完成。Pion 與 SCReAM 基準發送的是合成的 RFC 8593 流量，，實際編碼器輸出則待另行測試。即時媒體採用 LeoCC 式重組感知控制器的測試仍待完成，而作者勾勒的偵測器需要比 Teams 更頻繁的 RTCP 回饋，所以解方仍停留在提議階段。
- Rare events have large effects. Delay-based overuse occupies 0.07–0.40% of time, with 35–140 transitions per site. This demonstrates clustering but gives limited samples for site comparisons. The 10 Mbps test uses Munich alone.罕見的事件，巨大的影響。基於延遲的過載只佔 0.07–0.40% 的時間，因此結論建立在每站 35 到 140 次過載轉換上，足以顯示過載聚集在重組時刻，但用來比較站點則顯得單薄，而 10 Mbps 的結果只來自慕尼黑。
- The citation scope is video conferencing. Handover alignment gives timing, while direct handover delay and loss effects remain open measurements. The fact base records this application scope in Part C item 8.依其本質引用。由於換手對齊數字常被單獨流傳，事實庫記載這篇論文必須以 WebRTC 視訊會議研究的身分被引用（事實庫 Part C 第 8 項）。±1 秒對齊統計說的是換手何時發生，，一次換手增加的延遲與遺失則需另行量測，後者的直接量測待補充。
7. How it connects7. 與其他內容的關聯
- Section 6.5 compares GCC's 96.4–99.6% delay-based share and 0.8 Mbps drop with earlier Zoom delay and FEC measurements.第 6.5 節：應用一節，GCC 96.4–99.6% 的延遲主導比例與 0.8 Mbps 的下降，在此與 Mohan 等人的 Zoom 延遲與 FEC 數字並列。
- Section 6.1 relates GCC's latency steps to the scheduled changes that affect BBR and Copa bulk transfers.第 6.1 節：傳送端看到什麼，因為誤導 GCC 的延遲階躍，正是大量傳輸研究中誤導 BBR 與 Copa 的同一個 15 秒階躍。
- Section 3.5 distinguishes handover from scheduled reconfiguration using alignment results, alongside Tanveer's boundaries and Casparsen's initial spikes.第 3.5 節：15 秒排程與換手，≥89% 對 30.7% 的對齊統計在此與 Tanveer 等人的邊界及 Casparsen 等人的週期起始尖峰一起，把天線換手與排程重組區分開來。
- Related studies: Garcia et al. examines queues, Tanveer et al. supplies boundaries, and Mohan et al. measures earlier video performance. Kassem et al. supplies handover attribution, while Lai et al. [56] and LeoCC develop bulk-transfer controllers.同組導讀：Garcia 等人談完成三方區分的下行佇列，Tanveer 等人談本文假設的邊界，Mohan 等人談最早的視訊會議數字，Kassem 等人談本文細化的換手歸因，Lai 等人[56]與 LeoCC 則是迄今針對大量傳輸打造，即時媒體的適用性則待研究的重組感知控制器。
Key numbers關鍵數字
| Number | 數字 | Meaning (setup) | 意義（設定） |
|---|---|---|---|
| 96.4–99.6% | Time the delay-based GCC estimator controls the bandwidth estimate, four sites [51, §4.2] | 基於延遲的 GCC 估計器掌控頻寬估計的時間比例，四個站點[51, §4.2] | |
| 60.7–100% | Overuse transitions attributable to reconfigurations or handovers, AQ lowest, DE highest [51, §4.2] | 可歸因於重組或換手的過載轉換，AQ 最低、DE 最高[51, §4.2] | |
| −0.8 Mbps · 1–2 s | Teams uplink drop after a reconfiguration, from a 2.5 Mbps cap [51, §4.1] | 重組後 Teams 上行從 2.5 Mbps 上限下降的幅度與時間[51, §4.1] | |
| ≥89% | Handovers within ±1 s of :12/:27/:42/:57 at Munich, Delft, Oslo [51, §4.2] | 慕尼黑、台夫特、奧斯陸落在 :12/:27/:42/:57 ±1 秒內的換手比例[51, §4.2] | |
| 208 / 678 = 30.7% | Iraligned handovers at McMurdo, 97.6° shell with ISLs to the Sydney PoP [51, §4.2] | 麥克默多的偏離排程邊界的換手，97.6° 殼層、經 ISL 到雪梨 PoP[51, §4.2] | |
| 34.9% · 46.3% | McMurdo samples below target, and the share of that time attributable to reconfigurations [51, §4.1] | 麥克默多低於目標的樣本比例，以及其中可歸因於重組的比例[51, §4.1] | |
| 2.51 vs 2.52 Mbps | Median Teams bitrate, Starlink vs terrestrial [51, §4.1, App. B.3] | Teams 位元率中位數，Starlink 對地面網路[51, §4.1, App. B.3] | |
| 9.5% | Time the 10 Mbps target is met in Munich, while a sender with congestion control disabled delivers 10 Mbps [51, App. B.5–B.6] | 慕尼黑 10 Mbps 目標被達成的時間比例，而停用壅塞控制的傳送端能送出 10 Mbps[51, App. B.5–B.6] | |
| 13.3% | Chance that a random event falls within ±1 s of a 15-s boundary (computed, calc table) | 隨機事件落在 15 秒邊界 ±1 秒內的機率（計算值，見計算表） |