From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=lang.hm; dkim=fail; arc=none (Message is not ARC signed); dmarc=none Received: from mail.lang.hm (wsip-70-167-213-146.ph.ph.cox.net [70.167.213.146]) by mail.toke.dk (Postfix) with ESMTPS id 79E59701760 for ; Sun, 28 Sep 2025 12:59:15 +0200 (CEST) Received: from asgard.lang.hm (syslog [10.0.0.100]) by mail.lang.hm (Postfix) with ESMTP id 9B9CC20A6C0; Sun, 28 Sep 2025 03:59:13 -0700 (PDT) Date: Sun, 28 Sep 2025 03:59:13 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Sebastian Moeller cc: "David P. Reed" , starlink@lists.bufferbloat.net In-Reply-To: <2F8F8566-5C5E-4D96-AA48-90313FD33996@gmx.de> Message-ID: References: <175895289005.1561.17970219906621123011@gauss> <1759003996.780613387@apps.rackspace.com> <2F8F8566-5C5E-4D96-AA48-90313FD33996@gmx.de> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Message-ID-Hash: CDUQUEMLZHYYMWKLKYQ3LLPAPKZN4LF6 X-Message-ID-Hash: CDUQUEMLZHYYMWKLKYQ3LLPAPKZN4LF6 X-MailFrom: david@lang.hm X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Starlink] Re: Starlink Digest, Vol 53, Issue 14 List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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