Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Nitinder Mohan <N.Mohan@tudelft.nl>
To: "starlink@lists.bufferbloat.net" <starlink@lists.bufferbloat.net>
Cc: Hendrik Cech <hendrik.cech@tum.de>
Subject: [Starlink] Dissecting Starlink: head-drop queuing, AQM, and flow dynamics (SIGCOMM '26)
Date: Wed, 22 Jul 2026 09:00:53 +0000	[thread overview]
Message-ID: <D6D70BEF-3FB6-4279-815A-817B926CAE0A@tudelft.nl> (raw)

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/


                 reply	other threads:[~2026-07-22  9:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D6D70BEF-3FB6-4279-815A-817B926CAE0A@tudelft.nl \
    --to=n.mohan@tudelft.nl \
    --cc=hendrik.cech@tum.de \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox