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

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

[Nitinder Mohan]

Dear all,

Sharing our upcoming ACM SIGCOMM '26 paper that should interest this list, since it lands squarely on queuing and AQM in a network that has become hard to ignore. Paper: https://spearlab.nl/papers/2026/sigcomm26-dissect-starlink.pdf. Hendrik Cech, the lead on this work is in CC.

We ran the microsecond-precision measurements of Starlink's internal queue management, using a custom tool (NetScalpel) across dishes in Europe and the US. Our study uncovers several operational aspects about Starlink internal queue management that were previously unknown to the community.

  *   Starlink uses head-drop, not tail-drop (which is more popularly used usually). When the buffer fills, the packet at the front is discarded. This cuts sojourn time but produces loss patterns that loss-based congestion control does not expect.
  *   The buffers are deep, roughly 1500 packets on the downlink and 4000 on the uplink. Head-drop combined with active management keeps delay bounded despite the depth.
  *   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.
  *   Bandwidth is demand-driven and ramps up over about 400 ms only when a flow sustains queue pressure, then resets every 15 seconds. Conservative, queue-avoiding senders cannot claim their full share.
  *   Flow-level queuing isolates one-way delay between concurrent flows, but the shared downlink buffer couples their loss.

If you are interested in understanding and improving queueing dynamics in LEO, this paper would be an excellent resource for you. The tool, datasets, and analysis code are all open. Happy to take questions.

Thanks and Regards,

Nitinder Mohan
Assistant Professor
Head of SPEAR Lab, Networked Systems Group
TU Delft, Netherlands
Personal website: https://www.nitindermohan.com/
Lab website: https://spearlab.nl/

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

[Kathleen Nichols]

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] Re: Dissecting Starlink: head-drop queuing, AQM, and flow dynamics (SIGCOMM '26)

[Nitinder Mohan]

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 to starlink-leave@lists.bufferbloat.net

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

[Jianping Pan]

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 to starlink-leave@lists.bufferbloat.net

_______________________________________________
Starlink mailing list -- starlink@lists.bufferbloat.net
To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

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

[Nitinder Mohan]

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 to starlink-leave@lists.bufferbloat.net

_______________________________________________
Starlink mailing list -- starlink@lists.bufferbloat.net
To unsubscribe send an email to starlink-leave@lists.bufferbloat.net

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

[Jianping Pan]

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 to starlink-leave@lists.bufferbloat.net

_______________________________________________
Starlink mailing list -- starlink@lists.bufferbloat.net
To unsubscribe send an email to starlink-leave@lists.bufferbloat.net