[Starlink] Re: Dissecting Starlink: head-drop queuing, AQM, and flow dynamics (SIGCOMM '26)

[Hendrik Cech <hendrik.cech@tum.de>]

Hi everyone,

The tests from our main vantage point in Munich were conducted without the Starlink WiFi router in the loop:

Server [Client] <-- Ethernet --> Dishy

Therefore, we aren't measuring the router's fq_codel behavior, but rather an additional AQM scheme running directly on Dishy.

The interaction between fq_codel (router) and this custom AQM (Dishy) could be interesting to study further. However, I suspect CoDel isn't actively dropping packets in this setup since the 1G Ethernet link isn't the bottleneck; it likely only activates for WiFi clients.

Best,
Hendrik

On 22.07.26 17:23, Jianping Pan wrote:
> yes, and the starlink router is the device under test (dut) and we control both ends ;-)
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM),Pan@UVic.CA, Web.UVic.CA/~pan
>
> ________________________________________
> From: Nitinder Mohan<N.Mohan@tudelft.nl>
> Sent: Wednesday, July 22, 2026 8:21 AM
> To: Jianping Pan; Kathleen Nichols
> Cc:starlink@lists.bufferbloat.net; Hendrik Cech
> Subject: Re: [Starlink] Re: Dissecting Starlink: head-drop queuing, AQM, and flow dynamics (SIGCOMM '26)
>
> Hi J,
>
> I didn't quite get it. Do you have a way of isolating traffic only in Starlink router (so before it is sent to the dishy)?
>
> Get Outlook for Android<https://aka.ms/AAb9ysg>
> ________________________________
> From: Jianping Pan<pan@uvic.ca>
> Sent: Wednesday, 22 July 2026 17:18:55
> To: Kathleen Nichols<nichols@pollere.net>; Nitinder Mohan<N.Mohan@tudelft.nl>
> Cc:starlink@lists.bufferbloat.net <starlink@lists.bufferbloat.net>; Hendrik Cech<hendrik.cech@tum.de>
> Subject: Re: [Starlink] Re: Dissecting Starlink: head-drop queuing, AQM, and flow dynamics (SIGCOMM '26)
>
> we can measure the traffic in and out of the starlink router to profile it for you. cheers.  -j
> --
> J Pan, UVic CSc, ECS566, 250-472-5796 (NO VM),Pan@UVic.CA, Web.UVic.CA/~pan
>
> ________________________________________
> From: Nitinder Mohan via Starlink<starlink@lists.bufferbloat.net>
> Sent: Wednesday, July 22, 2026 7:26 AM
> To: Kathleen Nichols
> Cc:starlink@lists.bufferbloat.net; Hendrik Cech
> Subject: [Starlink] Re: Dissecting Starlink: head-drop queuing, AQM, and flow dynamics (SIGCOMM '26)
>
> Hi Kathie,
>
> You are, indeed, absolutely correct. Our takeaway largely is that the AQM being used is proprietary, it resembles A-RED and CoDEL at some instances but its not a 1:1 match. SpaceX also confirms that there is some “inspiration". We have a discussion on this in sec 4.3 on page 8.
>
> Best,
>
> Nitinder
>
>> On 22 Jul 2026, at 15:49, Kathleen Nichols via Starlink<starlink@lists.bufferbloat.net> wrote:
>>
>>
>> This is interesting work, thanks. But I want to point out that, if indeed the "Loss frequency grows with queue occupancy" that isn't CoDel which increases loss frequency with a persistent sojourn delay. (A large point of CoDel was to get away from queue occupancy as a congestion signal.)
>>
>>        Kathie
>>
>> On 7/22/26 2:00 AM, Nitinder Mohan via Starlink wrote:
>> ...
>>>    *   There is a real AQM that deliberately drops to control occupancy. The uplink is aggressive and holds flows below a quarter of physical capacity. The downlink is more permissive. Loss frequency grows with queue occupancy, and the load-dependent profile looks closer to CoDel or adaptive RED than fixed RED.
>> ...
>>
>> _______________________________________________
>> Starlink mailing list --starlink@lists.bufferbloat.net
>> To unsubscribe send an email tostarlink-leave@lists.bufferbloat.net
> _______________________________________________
> Starlink mailing list --starlink@lists.bufferbloat.net
> To unsubscribe send an email tostarlink-leave@lists.bufferbloat.net

-- 
Hendrik Cech, M.Sc.
Technical University of Munich
TUM School of Computation, Information and Technology
Department of Computer Engineering
Chair of Connected Mobility (I11)