Our paper "Dissecting the StarLink: Characterizing Queuing and Flow Dynamics in the Starlink Network" has been accepted at ACM SIGCOMM 2026! The work was led by Hendrik Cech, with Prof. Jörg Ott (TU Munich) and myself.
Starlink now serves over two million subscribers worldwide, but how it actually moves traffic on the inside has stayed a black box. Existing measurement studies could see throughput swing and latency rise, but stopped at observing the symptoms. This paper goes a level deeper. Hendrik built a measurement tool, stltrace, that captures per-packet timestamps at microsecond precision from controlled terminals across Europe and the US, and uses them to reconstruct what is happening inside Starlink at sub-second timescales.
A few things came out of this that nobody had documented before. Starlink hands every terminal a baseline rate of around 100 Mbps down and 30 Mbps up; to get more, your traffic has to actively push on the network, and the allocation then ramps up by 3–4x over roughly 400 ms. Its queues drop the oldest packet when they fill, not the newest, which is the opposite of what most transport protocols assume. And Starlink runs an aggressive active queue management scheme, especially on the uplink, that drops packets well before any buffer is actually full. Every 15 seconds the whole bandwidth allocation resets, even when the satellite has not changed.
Together, these mechanisms explain something the community has been seeing without a clean explanation: BBR keeps holding its rate over Starlink while CUBIC backs off. CUBIC reads Starlink's deliberate AQM drops as congestion and slows down — at exactly the moment it needs to keep pushing to defend its bandwidth allocation. BBR does not react to loss the same way, so it stays out of that trap. The paper turns what has been folklore among Starlink users into a concrete model of why.
We will release the stltrace tool, datasets, and analysis code together with the paper. Huge congrats to Hendrik on getting this one over the line.
