Dissecting the StarLink: Characterizing Queuing and Flow Dynamics in the Starlink Network

TLDR

(1) 研究背景与动机

尽管 Starlink 已成为全球最大的商业低轨 (LEO) 卫星网络，但其内部的队列管理、带宽分配机制以及对传输层协议（如 TCP）的影响一直是个“黑盒”

先前的研究多集中在宏观尺度（秒或分钟级别），无法解释 us-level 和底层数据包动态行为

(2) 研究方法

研究团队开发了一个名为 NetScalpel 的定制网络测量工具

该工具能够以 us-level 的精度记录数据包的发送和接收时间戳，从而进行高精度的单向延迟 (OWD)、丢包率和队列状态的逆向重建与分析

(3) 核心发现

Starlink 的三大传输机制

• 队首丢弃策略 (Head-drop Queuing):

  • 与传统网络常用的“队尾丢弃” (Tail-drop) 不同，当队列堆满时，Starlink 会优先丢弃队列最前端（最老）的数据包，以降低整体排队延迟
  • 测试表明:
    • DL 的队列容量约为 1500 个数据包
    • UL 约为 4000 个数据包

• 需求驱动的带宽分配 (Demand-driven Bandwidth Allocation):

  • 带宽并非一开始就全部可用，而是基于需求动态分配的
  • 下行和上行的基础带宽分别约为 100 Mbps 和 30 Mbps
  • 当流量需求超过基础值时:
    • 网络会在约 400 毫秒内将带宽分别提升高达 3.4 倍 (DL) 和 2 倍 (UL)
    • 这种带宽分配是针对整个用户终端 (per-UT) 的，且在流量停止后几百毫秒内会迅速衰退

• 主动队列管理 (Active Queue Management, AQM):

  • Starlink 会故意引发丢包以控制队列长度
  • UL 的 AQM 非常激进，在队列远未达到 4000 个数据包的物理上限时就会大量丢包
  • DL 的 AQM 相对宽容，允许队列堆积到接近 1500 个数据包的上限，但也会在达到上限前开始丢包
  • 此外: 当下行发送速率极高（>500 Mbps）时，Starlink 的 PoP 节点还会引入额外的速率限制和缓冲

(4) 15秒重构周期的影响 (Reconfigurations)

Starlink 网络每 15 秒（在每分钟的第 12、27、42、57 秒）会进行一次全局同步的重构

• 每次重构都会“重置”当前的带宽分配，导致正在进行的传输流需要重新触发带宽爬升
• 重构会造成约 45 毫秒 (DL) 和 68 毫秒 (UL) 的短暂连接中断
• 即使没有发生卫星切换 (Satellite Handovers)，重构也会导致网络稳定的带宽和延迟发生漂移

(5) 流级别的公平队列 (Flow-level Queuing)

• Starlink 采用了一定程度的公平队列机制，成功隔离了并发流之间的单向延迟 (OWD)
  • 这对延迟敏感型应用（如游戏、VoIP）在面临并发大流量下载时非常有利
• 然而在下行链路中，由于不同流共享同一个 1500 包容量的队首丢弃缓冲池，它们的丢包率是耦合的
  • 即: 一个侵略性强的流会导致其他正常的流也遭遇丢包
• 上行链路则通过基于流的激进 AQM 机制，成功实现了丢包率的隔离

(6) 对 TCP 协议性能的影响

Starlink 特殊的微观动态（特别是 AQM 引起的"非拥塞丢包", 和需要施加队列压力才能获得更高带宽的机制）对传统 TCP 提出了挑战

• 基于模型的算法 (如 BBRv1, LeoCC, SatPipe): 表现明显优于传统算法

  • 因为: 它们根据带宽模型而不是丢包来调整速率，能够容忍 AQM 引起的丢包，从而保持足够的队列压力来维持高带宽分配

• 基于丢包的算法 (如 CUBIC): 表现较差

  • 遇到 AQM 诱导的丢包时，CUBIC 会误认为是网络拥塞并大幅降低发送速率，导致无法充分利用 Starlink 的动态带宽

总结来说, 文章揭示了 Starlink 的底层网络行为与传统的地面网络存在本质区别，未来的 LEO 卫星网络传输协议必须针对这些微观特性进行专门的优化和设计

Background & Related Work

Starlink subscribers connect to the network through a user terminal (UT) that communicates with Low Earth Orbit (LEO) satellites via Ku-band radio links (Figure 1). The satellites relay traffic to ground stations (GSs, also called “gateways”) over Ka-band connections using multiple transceivers, which in turn connect to Starlink Points of Presence (PoPs) where the subscriber’s IP address is assigned and traffic enters the public Internet. In this architecture, the uplink (UL) queue resides at the UT while the downlink (DL) queue resides on the serving satellite; both are governed by a MAC scheduler that allocates bandwidth through a grant-based mechanism [51].

Starlink 的网络架构

• 用户终端 (UT) 通过 Ku 波段与低轨卫星通信
• 卫星通过 Ka 波段将流量中继到地面站 (GS)
• 最后经由 PoP 节点接入公共互联网
• 排队机制的物理位置:
  • UL 队列驻留在用户终端 (UT) 侧
  • DL 队列驻留在提供服务的卫星侧
  • 两者均由 MAC 调度器通过授权机制进行管理

Early studies established Starlink’s ability to deliver broadband performance with median RTTs below 50 ms and throughput exceeding 100 Mbps [35]. Large-scale measurements using M-Lab tests and RIPE Atlas probes revealed globally synchronized 15second reconfiguration intervals that induce periodic latency and throughput fluctuations [23, 36]. Studies operating at timescales of seconds to minutes have characterized latency dynamics and uplink delay variations [20], inferred physical-layer transmission rates from packet timing [19], and developed throughput prediction models [34]. Concurrent work by Garcia et al. [22] identified drop-front buffer management on Starlink’s downlink, a finding our measurements corroborate, and reported an absence of perflow fair queuing, which our measurements contradict. Our work further characterizes demand-driven bandwidth allocation, active queue management, and their combined impact on transport-layer performance on both up- and downlink.

现有研究成果与局限性

• 早期大规模测量证实了 Starlink 的宽带性能（RTT 低于 50 毫秒，吞吐量超 100 Mbps），并发现了全球同步的 15 秒重构周期会导致性能波动
• 现有研究多停留在秒级或分钟级的宏观层面
• 同期的 Garcia 等人的研究发现了下行链路的“队首丢弃”机制（本文证实了这一点）
  • 但他们认为不存在流级别的公平队列，这一观点被本文的测量结果所反驳

Starlink Operations. SpaceX patents on Medium Access Control (MAC) scheduling [28], Radio Link Control (RLC) [24], and handover management [12] provide some insight into Starlink’s design. Starlink’s layer-2 comprises a MAC sub-layer and RLC sublayer, both operating on satellites. The MAC scheduler allocates transmission grants per beam in 1.33 ms frames [23, 27], adapting modulation and coding schemes (MCS) based on Signal-to-Noise Ratio (SNR) and Block Error Rate (BLER) feedback from UTs. Uplink (UL) grant allocation prioritizes UTs with low bandwidth demand while assigning unused capacity to high-demand terminals. The allocation relies on each UT reporting its buffer occupancy to the MAC scheduler, enabling demand-driven resource distribution. The RLC layer manages per-flow queues where Quality of Service (QoS) or AQM mechanisms like RED may be applied [24]. Handovers follow pre-computed schedules, with duplicate packet transmission employed to prevent loss during satellite or ground station transitions [12]. Understanding how these architectural choices affect end-to-end performance has motivated extensive measurement studies [19, 20, 23, 34–36]. Garcia et al. [21] provide the most comprehensive evaluation of TCP performance over Starlink, benchmarking 14 congestion controls and finding that BBR consistently outperforms CUBIC. Their analysis also revealed a first-comer advantage in flow fairness. To mitigate performance degradation during Starlink’s reconfigurations, several proposals preemptively stall transmissions or freeze the congestion window [30, 31, 52], while others design LEO-aware CCAs [32].

Starlink 基于专利的底层运作机制

• Starlink 的卫星端运行着 MAC 和 RLC 子层
• MAC 调度器以 1.33 毫秒为帧分配传输授权，并根据终端反馈的信噪比 (SNR) 等指标动态调整调制与编码方案
  • UL链路分配: 优先满足低需求终端，剩余容量分配给高需求终端
• RLC 层负责管理单流队列
  • 并可能应用了 QoS 或类似 RED 的主动队列管理 (AQM) 机制
• 卫星切换基于预先计算的时间表，并通过发送重复数据包来防止切换过程中的丢包

Open Questions. While patents mention per-flow queues and RED, the queue management strategy, drop policy, and bandwidth allocation behavior in production remain unknown. Prior studies have characterized Starlink’s latency, throughput, and handover patterns but have not systematically evaluated sub-second bandwidth dynamics, queuing policies, or their combined impact on congestion control. Our work addresses these gaps through targeted measurements. We reveal that bandwidth ramps up over ≈ 400 ms when demand exceeds the baseline allocation and resets at each 15-second reconfiguration. The bottleneck queues reside on the UT for UL and on the serving satellite for DL, with capacities of ≈ 4000 packets (UL) and ≈ 1500 packets (DL). Starlink uses head-drop rather than tail-drop queuing and deliberately induces losses to control queue occupancy, consistent with AQM. Finally, we show evidence of flow-level queuing that provides latency isolation and analyze how these mechanisms collectively affect transport performance.

• 尽管专利提及了某些机制，但生产环境中的实际队列管理、丢弃策略和带宽分配行为依然未知，缺乏对亚秒级微观动态的系统评估
• 本文填补了空白并得出关键结论:
  • 需求超过基线时带宽会有约 400 毫秒的爬升期, 且在每次 15 秒重构时重置
  • 上下行的瓶颈队列容量, 分别约为 4000 包 (UL) 和 1500 包 (DL)
• 生产环境实际采用了 Head-drop 策略
  • 并利用 AQM 主动诱导丢包来控制队列占用
• 本文证实了流级别排队机制的存在，该机制能够提供延迟隔离

结论整理

Queue Investigation

• 结论 1（丢弃策略）：
  • Starlink 在 DL 和 UL 均采用了 Head-drop 策略，而不是传统的 Tail-drop
  • 含义: 当队列达到容量时，最先进入队列（最老）的数据包会被丢弃
  • 意义: 在队列满载时, 能有效降低所有排队数据包的平均驻留时间 (Sojourn time)
• 结论 2（队列容量）：
  • 下行链路 (DL) 的队列容量约为 1500 个数据包，上行链路 (UL) 的队列容量约为 4000 个数据包
• 结论 3（队列限制维度）：
  • 队列的容量限制是基于数据包数量 (Packet limit) 的，而不是基于字节大小 (Byte limit)

基于 packet limit 的 packet 大小是多少

TODO

Bandwidth Allocation

• 结论 4（需求驱动的动态分配）：
  • Starlink 的 MAC 调度器基于用户需求动态分配带宽
  • 在建立连接之初，只有一部分基础带宽是立即可用的（下行约 100 Mbps，上行约 30 Mbps）
• 结论 5（带宽爬升时间与倍数）：
  • 当发送速率高于基础带宽时，会触发带宽分配的“爬升” (Ramp-up) 过程，该过程大约需要 400 毫秒
  • 在此期间，下行带宽最多可增加 3.4倍，上行带宽最多可增加 2倍
• 结论 6（带宽衰退的不对称性）：
  • 当流量需求停止时，已分配的高带宽会迅速衰退
    • 下行链路的带宽分配: 会在约 200 毫秒内线性下降至基线
    • 上行链路的带宽分配: 会先维持约 175 毫秒的高位，然后再在 200 毫秒内衰退（且调度器在决定维持分配多长时间时，会考虑队列的占用情况）
• 结论 7（终端级分配）：
  • 带宽分配是绑定在整个用户终端 (per-UT) 上的，而不是绑定在单个流 (per-flow) 上
  • 新流可以立即继承旧流刚刚触发的高带宽分配

Queue Management

• 结论 8（存在主动队列管理 AQM）：
  • Starlink 在遇到物理队列打满之前，就会通过主动队列管理 (AQM) 机制故意丢弃数据包，以控制队列的占用率
• 结论 9（激进的上行 AQM）：
  • UL 的 AQM 策略非常激进
  • 它会将队列增长限制在远低于 4000 个数据包的物理容量之下（通常连四分之一都达不到）
  • 在 0-250 个数据包的队列长度区间内，丢帧频率随队列大小线性增加
• 结论 10（宽容的下行 AQM）：
  • DL 的 AQM 相对宽容
  • 允许队列接近其约 1500 个数据包的最大容量。但在队列远未饱和时（< 500 个数据包），依然会发生明显的 AQM 诱发丢包
• 结论 11（AQM 的自适应性）：
  • AQM 策略不是固定不变的，而是与负载相关的（Adaptive）
  • 它似乎不仅监控绝对的队列大小或驻留时间，还在监控它们的变化率（类似 CoDel 或 A-RED 算法）
• 结论 12（PoP 节点的额外缓冲）：
  • 当下行发送速率极高（> 500 Mbps）时，超出链路极限的流量会触发 Starlink PoP 级别的速率限制器
  • 从而: 在数据到达卫星链路前引入额外的上游排队缓冲

Reconfigurations

• 结论 13（重置带宽分配）：
  • 每 15 秒一次的重构会重置当前的带宽分配
  • 这会导致: 即便对于已经获得高带宽的存量流量，其接收速率也会下降，并需要花费约 600 毫秒的时间重新爬升恢复
• 结论 14（引发连接中断）：
  • 由调度驱动的重构会导致下行链路出现约 45 毫秒的连接中断，上行链路出现约 68 毫秒的连接中断
  • 在此期间:
    • DL链路会在地面站引发队列激增和丢包
    • UL链路凭借极深的物理队列和激进的 AQM，能够更好地吸收这种中断带来的队列激增
• 结论 15（性能基准漂移）：
  • 重构不仅会产生临时中断，还会导致连续重构区间 (RIs) 之间的稳定带宽和单向延迟 (OWD) 发生跳变/漂移
  • 下行带宽中位数变化达 70 Mbps，上行达 26 Mbps
• 结论 16（与卫星切换无关）：
  • 上述所有重构效应（带宽重置、连接断开、性能漂移）的发生，无论当前连接的卫星是否发生了切换，都会固定出现
  • 说明: 是卫星本地状态重构导致的

Flow Queuing

• 结论 17（OWD 隔离）：
  • Starlink 实施了一种 Flow-aware queuing，成功解耦了竞争流之间的单向延迟 (OWD)
  • 即便是面临极具侵略性的"大象流"，处于公平份额内的"老鼠流"依然能保持极低的延迟
  • 这对延迟敏感型应用极其有利
• 结论 18（下行链路丢包耦合）：
  • 尽管下行链路隔离了延迟，但由于所有流共享同一个 1500 个数据包的队首丢弃队列，它们的丢包率是耦合的
  • 一个极具侵略性的流填满队列时，会导致原本在公平份额内传输的流也无辜遭遇丢包
• 结论 19（上行链路丢包隔离）：
  • 上行链路由于实施了基于流的、主动且激进的 AQM 策略，有效管理了每个流的队列积压
  • 防止了共享队列被打满，从而成功避免了丢包耦合问题，提供了更好的流隔离

Flow-aware queuing

• 传统做法 (FIFO):
  • 很多简单的路由器会把所有用户的、所有应用的数据包混在一个池子里，像单行道一样"先入先出"
• Flow-aware 的含义:
  • 网络（在这里指 Starlink 的 MAC 调度器）能够识别出数据包属于哪个具体的“流”
  • 比如: 视频流是流 Flow-A，下载任务是流 Flow-B
  • 系统会在逻辑上对这些流进行区分管理, 而不是把它们当成毫无区别的一堆数据包

---

OWD: 解耦了竞争流之间的单向延迟

• 如果没解耦（单行道）:
  • 大象流发送了海量数据包把队列塞满，老鼠流的数据包排在这些大象包的后面，必须等前面的包全部发完才能轮到自己
  • 导致两者的排队时间（延迟）变得一样长, 这对于老鼠流非常不公平!!!
• Starlink 的做法:
  • 因为 Starlink 能识别出不同的流，它的调度器像一个聪明的交警
  • 当它发现老鼠流的数据量很少（处于公平份额内）时，会优先把老鼠流的数据包从队列里“提”出来发走（类似于轮询/公平队列机制）
• 结果:
  • 大象流因为包太多，自己慢慢排队（延迟高）
  • 老鼠流则能快速通过通道（延迟极低）
  • 两者互不干扰，这就叫“解耦”

DL: 丢包率是耦合的

• 现象:
  • 在下行链路上，当大象流把网络塞满时，虽然老鼠流的延迟依然很低，但老鼠流却和大象流经历了几乎一样高的丢包率
  • 老鼠流明明很乖没超速，却跟着倒霉，这就叫丢包率“耦合”（绑定在一起了）
• 原因:
  • 虽然调度器发包时会优待老鼠流，但它们在物理上 共用同一个容量约 1500 个数据包的缓冲池
  • 大象流极其凶猛，瞬间把这个池子塞满了
  • 此时无论新进来的是谁的包，Starlink 都会触发“队首丢弃”: 无差别地把池子最前面的包扔掉。老鼠流的包恰好在池子里，就被误杀了

UL: 成功避免了丢包耦合问题

• 现象:
  • 在上行链路上，如果老鼠流保持低速率，它不仅延迟低，而且几乎不丢包
  • 只有大象流自己疯狂丢包。老鼠的丢包命运没有被大象连累
• 原因:
  • 上行链路部署了一个非常“激进”且针对每个流独立运作的主动队列管理 (AQM) 机制
  • 这个机制就像一个严格的保安，它死死盯着大象流:
    • 发现大象流发包太多，在物理队列（4000 个包容量）还没填满之前，就提前把大象流的包给丢弃了
• 结果:
  • 因为 AQM 提前拦截了大象流，导致那个共享的物理缓冲池永远填不满
  • 既然池子没满，老鼠流的数据包进出就畅通无阻，绝对不会因为池子溢出而被牵连丢弃，从而实现了丢包率的完美隔离

---

笔者读完这一部分, 最大的问题是:

(1) DL 和 UL 不是都用 AQM 吗? 为什么 DL 不能像 UL 那样做到"完美隔离"?

• UL AQM 是“激进的”:
  • 上行 AQM 非常激进，它会将队列长度死死压在物理容量（4000 包）的四分之一以下
  • 这意味着，无论大象流怎么发力，上行的物理队列永远不会满
• DL 的 AQM 是“宽容的”:
  • 相比之下，下行 AQM 比较宽容
  • 它虽然也会在队列填满前引发丢包，但它允许队列一直增长并接近其 1500 个数据包的最大容量

由于 DL AQM 的“手腕太软”，它没能压制住疯狂的大象流，导致大象流的数据包最终撞到了 1500 包的共享物理队列上限

一旦这个共享的物理池子满了，网络调度器就不得不动用“终极防线”——队首丢弃 (Head-drop) 机制

论文明确指出，当这个共享缓冲区满了之后，调度器就会丢弃队列最前端的数据包，而根本不管这个包属于哪个流

这个时候，老鼠流就不可避免地遭殃了 (尤其是它还"跑得快", 更容易集中在 queue head)

(2) 为什么 DL 不能和 UL 一样, 采取"激进的AQM管理"策略?

先叠个甲: Starlink 确切的 AQM 算法和具体机制目前依然是商业机密, 对外界来说仍是一个“黑盒”

Reason 1: 队列所在的物理位置与硬件限制不同

• UL queue 在地面:

  • UL 队列驻留在用户家中的终端天线 (UT) 上
  • 地面的设备相对容易配置较大的内存，因此其物理队列容量高达 4000 个数据包
  • 有了充足的缓冲空间，UT 就可以从容地使用激进的 AQM 来控制队列增长

• DL queue 在天上:

  • DL 队列驻留在提供服务的低轨卫星上
  • 卫星的内存、功耗和计算资源极为宝贵且受限，因此其队列容量较小，仅为 1500 个数据包
  • 不仅如此，卫星还需要同时处理和调度成百上千个用户的下行流量，管理策略自然与单用户的地面终端不同

Reason 2: 触发"需求驱动带宽"的必要妥协

论文着重讨论的 fundamental tension

• Starlink 的带宽是按需分配的:

  • 为了获得更高的下行带宽, 发送方必须通过排队来向网络证明自己的"需求压力"

• 如果 DL 端的 AQM 像 UL 一样激进，在队列刚开始堆积时就疯狂丢包

  • 那么传统的 TCP 协议（如 CUBIC）就会把这些丢包误认为是网络拥塞，从而立刻减速

• 结果:

  • 如果 DL 的 AQM 太严厉，用户的下载流根本无法建立起足够的队列压力，也就永远无法触发系统分配那额外 3.4 倍的高带宽，用户体验到的网速就会极其受限
  • 因此，DL 端的 AQM 必须保持“宽容”，允许队列堆积，给传输协议足够的时间去试探和索要更高的带宽

Reason 3: PoP 节点的二次保护机制

• 也许是因为卫星端的下行队列比较宽容(容易被打满), Starlink 在 PoP 节点 引入了额外的保护层
• 论文发现:
  • 当下行速率极高（>500 Mbps）时，PoP 节点的速率限制器会介入，在流量到达脆弱的卫星链路之前就引入额外的上游缓冲
  • 这种"两级缓冲"的架构, 也使得卫星端的 DL AQM 不需要表现得过于激进

Danger

下行链路的“宽容”, 本质上是在 有限的星载硬件资源 与 保障用户能顺利跑满高下行带宽 之间做出的工程妥协

TCP Performance

• 结论 20（慢启动的两难境地）：
  • 在 Starlink 上，TCP 慢启动机制必须施加足够的“队列压力”来触发网络分配更多带宽
  • 但如果施加得过快，又会导致缓冲区溢出和 AQM 诱导的大量丢包
  • 保守的慢启动（如 HyStart++）过早退出，无法利用全部带宽；传统的指数慢启动则会严重超调并导致严重丢包
• 结论 21（基于模型 vs. 基于丢包的拥塞控制）：
  • 基于模型的算法（如 BBRv1、LeoCC、SatPipe）性能显著优于基于丢包的算法（如 CUBIC）
  • 因为 CUBIC 会将 AQM 故意诱导的丢包误认为网络拥塞而降低速率
  • 而 BBR 类算法主要基于带宽估计，能容忍这些丢包，从而维持所需的队列压力以保住带宽分配
• 结论 22（针对 LEO 优化的 CCA 的局限性）：
  • 某些专门针对卫星切换优化的算法（如 SatPipe）, 会在重构期间主动停止传输或限制在途数据（In-flight data）以清空队列
  • 然而，测量发现这种策略反而严重延迟了重构后的带宽恢复，因为它们未能迅速重建触发"带宽分配所需的队列压力"

• 结论 23（重构后的恢复）：

  • 重构发生后，所有的 TCP 变体在探测带宽时，起始发送速率都远低于最初慢启动时的速率，导致恢复既缓慢又不完全

• 结论 24（空闲链路极低的延迟和丢包）：

  • 在几乎空闲的链路上进行探测，下行链路的平均基准 OWD 为 13 毫秒，上行链路为 17 毫秒
  • 空闲状态下的物理链路极为稳定，随机丢包率极低（下行 0.03%，上行 0.02%）
  • 这反向证明了: 高负载下的高丢包率完全是由 AQM 和缓冲区溢出引起的

Discussion & Conclusion

Starlink’s sub-second dynamics differ substantially from terrestrial networks and from the assumptions embedded in most transport protocols. Our measurements uncover three interacting mechanisms that create an environment where conventional congestion control wisdom does not always apply. First, head-drop queuing with queue sizes of ≈ 1500 packets (DL) and ≈ 4000 packets (UL). Second, demand-driven bandwidth allocation that ramps up over ≈ 400 ms by factors of 3.4× (DL) and 2× (UL). Third, active queue management that aggressively controls queue occupancy, particularly on the uplink. These mechanisms interact with Starlink’s 15-second reconfiguration cycle [23, 36], which resets bandwidth allocations and causes transient disruptions. We now discuss the implications of these findings.

(1) Starlink 核心传输机制总结

• Starlink 的亚秒级网络动态与传统地面网络存在本质区别，常规的拥塞控制经验在此并不适用
• 网络环境主要由三大相互作用的机制主导:
  • Head-Drop 机制: 下行约 1500 包，上行约 4000 包
  • 按需带宽分配 (约 400 毫秒爬升)
  • 激进的主动队列管理 (AQM)
• 上述机制还会受到每 15 秒一次的重构周期影响，该周期会不断重置带宽分配并引发瞬时中断

Transport Protocol Design. Our findings reveal a fundamental tension in designing congestion control for Starlink. To claim additional bandwidth, a sender must build a queue. Yet doing so triggers AQM-induced losses and risks filling the shared DL buffer that couples loss across flows. Loss-based CCAs like CUBIC [26] interpret these AQM drops as congestion signals and reduce their sending rate, failing to sustain the pressure needed to maintain bandwidth allocation. Model-based algorithms like BBRv1 [6] and BBRv3 [7] prove more resilient because they probe for bandwidth independently of loss. This aligns with recent findings showing BBR outperforms CUBIC on Starlink [21].

The reconfiguration cycle compounds these challenges. Every 15 seconds, the bandwidth allocation resets, requiring CCAs to reprobe for capacity. Algorithms unaware of this periodicity waste time ramping back up, while handover-aware approaches like SatPipe [52], LeoCC [32], StarTCP [30], and SaTCP [5] show promise but require explicit knowledge of reconfiguration timing. Our examination of SatPipe highlights a related challenge: tracking the frequently shifting post-reconfiguration RTT. Because BBR relies on the minimum RTT to estimate the bandwidth-delay product and dictate the sending rate, accurate measurement is critical. Future algorithms must carefully weigh how probing for the minimum RTT on an idle link impacts Starlink’s bandwidth allocation decisions. Slow start algorithms face a similar tension. They must apply enough pressure to trigger bandwidth allocation without filling the buffer so quickly that AQM induces heavy losses. HyStart++ [4] and similar conservative approaches exit slow start prematurely, failing to capitalize on Starlink’s capacity, while vanilla exponential slow start overshoots and suffers significant packet loss.

(2) 对传输协议设计的严峻挑战

• 带宽探测的根本矛盾:

  • 发送方必须建立队列(增加压力)才能获取更多带宽, 但这必然会触发 AQM 诱导的丢包
  • 基于丢包的拥塞控制算法（如 CUBIC）会因误判而减速
  • 而基于模型的算法（如 BBR）能容忍丢包，因此表现更具弹性

• 重构周期的应对难题:

  • 每 15 秒的带宽重置要求算法不断重新探测
  • 未能感知重构的算法会浪费大量恢复时间
  • 而感知重构的 LEO 优化算法（如 SatPipe）在准确测量重构后频繁波动的 RTT 时同样面临巨大的技术挑战

• 慢启动的两难境地:

  • 慢启动策略必须在 "施加足够压力以获取带宽" 和 "防止队列堆积过快导致严重丢包" 之间寻找平衡
  • 目前保守策略（如 HyStart++）利用率不足，而传统的指数增长策略又会造成严重丢包

Emulation and Simulation. Our characterization provides the foundation for more accurate modeling of LEO satellite networks. Existing network emulators like Mahimahi [37] typically assume tail-drop queues, static bandwidth, and loss patterns that do not capture Starlink’s behavior. Recent efforts to build LEO-aware emulators [40, 46] could incorporate head-drop semantics, demand-driven bandwidth allocation, and periodic reconfiguration events. Without these features, protocol evaluations risk drawing conclusions that do not generalize to real deployments. The flow queuing behavior we uncover also has implications for fairness studies. Starlink’s mechanism provides OWD isolation between flows, benefiting latency-sensitive applications sharing the link with bulk transfers. However, the shared DL queue couples loss rates across flows. This asymmetry means that fairness analyses must consider OWD and loss separately rather than assuming they correlate.

(3) 对网络仿真与公平性研究的启示

• 重塑 LEO 网络仿真基准:

  • 现有的网络仿真器（如 Mahimahi）假设的是队尾丢弃和静态带宽，无法真实反映 Starlink 的行为
  • 未来的 LEO 仿真器必须整合队首丢弃、动态带宽分配和周期性重构等特性，否则协议评估的结果将无法落地到真实场景

• 公平性指标的分离:

  • 由于 Starlink 的流排队机制成功隔离了并发流的单向延迟 (OWD)，却在下行链路共享队列中耦合了丢包率
  • 未来的公平性分析必须打破常规，将 OWD 和丢包分开独立考量

Limitations and Future Work. Several technical questions remain. Importantly, the exact AQM algorithm is not fully characterized. We find correlations with queue size and load-dependent behavior consistent with adaptive schemes like A-RED [17] or CoDel [39], but the precise mechanism remains proprietary. The interaction between bandwidth allocation and terminal density also warrants investigation. Finally, inter-satellite links (ISLs) may introduce additional dynamics not captured in our current measurements, as all our VPs followed a direct bent-pipe connection. Although ISLs are part of Starlink’s architecture, prior work [36] indicates they are currently activated only in specific cases, and identifying whether a particular connection traverses an ISL remains non-trivial as this information is not exposed to end hosts. Characterizing how ISLs affect queuing behavior (queue sizing, AQM response, bandwidth allocation) is a natural next step, and the analysis techniques we presented are directly applicable.

Additionally, the behaviors highlighted in this paper reflect Starlink-specific engineering decisions. While one can argue that these choices are transient and may evolve as Starlink iterates on its design, they are currently the reality that application (and transport) protocols must contend with. As the first and largest commercial LEO operator, Starlink’s design choices are likely to influence other satellite network operators now entering the market, such as OneWeb and Amazon’s LEO. Our work demonstrates and provides a systematic methodology on investigating these behaviors at a microscopic level through controlled measurements and queue state estimation, which can be applied to other satellite networks as they become more accessible.

(4) 研究局限与未来展望

• 未解的黑盒机制:
  • 目前 Starlink 确切的 AQM 算法仍是专有黑盒（表现出类似 A-RED 或 CoDel 的自适应特征）
  • 终端密度对带宽分配的具体影响尚未明确
• 星间链路 (ISL) 的影响:
  • 本次测量的连接均为直接的透明转发（未经过 ISL）
  • 未来需要进一步评估 ISL 激活后对排队机制、AQM 响应和带宽分配带来的额外动态影响
• 行业指导意义:
  • Starlink 当前的工程设计选择很可能会深刻影响 OneWeb 和亚马逊等即将入局的其他 LEO 运营商
  • 本文提供的基于控制测量和队列状态估计的微观方法论，可以广泛应用于未来其他卫星网络的分析中