Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Sebastian Moeller <moeller0@gmx.de>
Cc: "David P. Reed" <dpreed@deepplum.com>, starlink@lists.bufferbloat.net
Subject: [Starlink] Re: Starlink Digest, Vol 53, Issue 14
Date: Sun, 28 Sep 2025 03:59:13 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.2509280357250.14652@nftneq.ynat.uz> (raw)
In-Reply-To: <2F8F8566-5C5E-4D96-AA48-90313FD33996@gmx.de>

Sebastian Moeller wrote:

>> There are no "guarantees" unless you run a central scheduler that takes all demand known to happen in the next period P (after the current operation period P-1), and distribute a "fair share" (according to a committee of network operators) among all users, then not admitting packets during the period P, except for those allocated.
>
> In this long enough to at least have an opinion ;) : IMHO there are three options for "fairness":
> a) instructed fairness, where there needs to be some veridical (preferably out of band) way to signal desired capacity share of different aggregates (and how to detect these aggregates)
> b) emergent fairness, where the network uses some unambiguous aggregate identifier (e.g. 2-tupel, 4-tupel. 5-tubel from the IP header) and foregoes the need for a reliable timely side-channel to signal relative importance of packets/flows
> c) do not bother at all
>
> Status quo is IMHO c), b) has been shown to be both achievable (at least at leaf networks) and to offer a noticeable improvement over c) for many use-cases, but everybody and their dog obsesses about a) in spite of this in practice only ever working in well controlled niches...

The other problem to deal with is how your new system is going to do in an 
environement where not everyone uses it. (akd, the current Internet) and how it 
deals with a small number of nodes trying to get more than their 'fair share'

David Lang

  reply	other threads:[~2025-09-28 10:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <175895289005.1561.17970219906621123011@gauss>
2025-09-27 20:13 ` David P. Reed
2025-09-28 10:47   ` Sebastian Moeller
2025-09-28 10:59     ` David Lang [this message]
     [not found] <175900400148.1561.6981645218542924150@gauss>
2025-09-28 17:32 ` David Fernández
2025-09-28 18:51   ` Sebastian Moeller

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=alpine.DEB.2.02.2509280357250.14652@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=dpreed@deepplum.com \
    --cc=moeller0@gmx.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