From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=; dkim=pass header.d=gmx.de header.i=moeller0@gmx.de; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=gmx.de policy.dmarc=quarantine Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by mail.toke.dk (Postfix) with ESMTPS id 5253B6F5BE1 for ; Fri, 26 Sep 2025 15:12:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1758892358; x=1759497158; i=moeller0@gmx.de; bh=MgI18/PpLk3hfsCVdZL2VimNl25UeJecs+FeBjm/pCA=; h=X-UI-Sender-Class:Content-Type:Mime-Version:Subject:From: In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id: References:To:cc:content-transfer-encoding:content-type:date:from: message-id:mime-version:reply-to:subject:to; b=IMc7vHy0udi11gzqjogTFKn+5vsXgB5vDRXA5SwlM09KmmUsm3csPYr41osr+ZLE GIshLxLJWBzmS5ZvRNC7Bk2wkYYfQ0oiyYXx/mWRB1ELrTWwdA8sv68neOnfUwJzV ddFU7VZhTshdayIHH62KI/oZ2Lo2FDJp+G18uDVooud3zCi9iGgZwVG7itx5Wd5On CPWDUPg8sxQ/DtRj1yGdGrCHwx3CdW2Tj1LXO0oj/bptKq4q61XVEIA3JFTn1rFyF Z5yfbN4HyB5a4/DgVITyeeCGs14scd6eygqEaI97b48C3TwAim9YWvLcaRm18lBp3 uj1AYCVE2oiCHagWvg== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([212.133.41.31]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MLiCu-1ukbNu2CH2-00IDrz; Fri, 26 Sep 2025 15:12:38 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) From: Sebastian Moeller In-Reply-To: <30473.1758822310@obiwan.sandelman.ca> Date: Fri, 26 Sep 2025 15:11:23 +0200 Cc: starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: <175876550514.1555.8294777204829819629@gauss> <30473.1758822310@obiwan.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.3826.700.81) X-Provags-ID: V03:K1:5CC7dPK/DgR+indklULOvAOZJaZeHo07eNxAIeUQtt5Q3iL1oLN 3RYrHgbMbn7rjM5jR4zRK0HUffXaU1d+OVhctPJq4EVfepSJoJM1GYNkMLpZf1vRNqaxFk1 38FIkBBhiicaNwimWmKciVOrO8PQ0ORHgamO+BhFPrm+KKRhCu0U3C9UmaajSLttld/Dflv nmFnBMHHSOcNSSUhVof8w== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:hN0oSK3WZ58=;4fMXHcij0gt7lpGNWVKxEpIxfop e+J7DHEi9uVeIzq4McST29I3QQgKacHKPrG0nGgA8xMPlyezon7mf9DX6HqPKMFJFIkHn7CH5 DgQ1xXF3jeC3sG2pG/yMZFcsxVMM+Ijn1aUbq52M65UJWETDOIRFR+z7/u+eDxUIg6H1Xz19O 6AU3E4zNMfUx2xHe5kcrtZ9VntU3wv2mkvEKpOdggSMOkYBcIEMlH4Jk5vyPAHVfw8gnTb+ZK z39oHc8B78WnOeAieNQ62VhjILWTYt3t34gHIUac+2z+jY9F2ewWjKrvuX+LCe4Uo4Z5VWjBp QwKVBIaI/svk5gxM5Em/+PJquuvEM60FpYRw4dEPnjSYutKlHiCutp5Cpm2EqVsrYrEHM74Xh q8+yefIQcD36Ra9wUfAJgGpYyi2p9m6KZLEt6BR9Ut72TljzbBS95lTNs9JIge/zRpzgCy1VH yYo+bCZtv0CH1npZRAXbGr3GG2YseEI+xxPt9FY3cR7Ci5/fBl4jDcBg16SOb8EtLEawb/egr FoT+Li8dozPGu31dTGMP0EsHTy44Qx3M9b7bDiUl2KVyUkBjRSmy55WaD5TOVWn+18oOql9cb 02V58L6tK/HFJSWK64+BUxv0ZiGUrnbo/zKl3/soni2/vgLW83rOmy/njqHBa1C7fl5IErEtY j59A9wMgU5n/K/QnQsf7xqYkv39py9StcQY4K1nIqTnhYuFjCWTHwWT2Ei54DfbBqSsG5+JnG JOUKWFtO+rOOiWcha5F1RAyvoGk01RlDUuUkK9Z7MJr7PJ2jvW9rSyuhhZuCm8WsTASbRaqad LwuSUfX5J4dva45vHGPgAzTqlPVTPXy9IkJl6PaMhitQCtcIhARL+LpTZ4ZN3JQSP9wivtVwc tx6eWnrsbU8rBubbEiWxAi/jJFSpDTJz5Z1SD4k1yIH45EEDp3iQG82k9eNw/qbzaMxw6vnxQ BWDTSwWl07cJ8KrfI/3YL5YP49k687/fdi2ID67H+5KoAPjm0wd73dNWiJKrMeIcU7X4PHlvj 1c0asUfCy8ciixuFJlgKV5EqIWqZdRRoVuyFi9XMnvZgkBRtni8Gv6F8EDQDdhfVoswqf9YMd vFl9EUXmu4f6UhY3T9/u3PbWyLtI/0B49mZVMQMBNvdh6qFXi/Df6knQ4UI90alhYU3U5xBqQ 5QP5V8jb2AYGNOqaywNEMZD7voqlF0i2QXyXXUOK9OyVV4cooyTx41fwYldwbTwAbGvgwvYjQ AWXYzUEBPegxF9eHmyYmiDVszq1HgEQPSERP16HNyN+hIPI55wU2bnVcI8Xrrvbwy+ypiUrjL LQQ1orHNx2Wq574m5w23qQmy9trO3T2lX1/2zyjiVxFRq4St93YIz+KI7+Yh4n0QhxXXTqyso CAWNjnSISdV7adCBrGm+Ix+sYTLIFZn8wXhPKr47DWYwGaDGv5yRA9b0G3x+KXC21HEJpKm97 znhL6OX8YfcDttglVRLY/OcPc78tWGoninwa+wEIcC7SZP4YMNBe2BSvV+/WsspmTC7opcti4 CU9SoGOUbRvvHN7zpWdyl0wnUz4Pw9Hbq+fH+vtP0JtXnRCwsZaGqWjuBTaJwsovd4BYWkVaf 657kdakjwcLP2nkq9VEt7WNWTOJSVX0C0HMA/DtUZAZIKd2LTkokpDioLQ7rCiVpihNvNrmJM i+3vAMzvlWM/+rMnZq9jwYayMpJLhB5CY9qcELZAMS+ZsHSfLsNrqpZ0fF2J5cedHUpQxMlKl FJjCjNYP53qX6mbuAYNA9TFmYm3G3u9oYCk9zOB0zQcosIrEyM0IR6gDuiLrv8NBG4/hbKiXI anGBKBO9fixoW6RmecAdcG2yRd8BTFPATCqdvB0KWk+PkBGw8YewzmqO2mXX7yloVzyvkTg6h BhVml3crXFzb4Ws2DeZZkX/AYXSX1kAcCdqwRzClTGDENyWLqDQlWyIoLs6P8D74f00AbKESc NW34UFoJiQCrC2MMtVZPs/JwXXWdAdbfgl/5t/FfR1gm6o6xp6V/vxddbSvxYRwmFSXRANlY+ 0NwK8kOaxYbyFTIN323yLhktehp2SeLDv5wiOmR1bY1OAKu9Tlrc8BO8Aayu0UAv8XRFcXSk7 ZlMk3mjY2fdAldVIHM+LQcCtAYzSuHKo1cmT2IpfnZhcWZV+7DxfIx4nVWWhO4aj4Y1XkMd37 ft/TueRn+so9uvPXhw59uG4tU4IgmFqkyZXHg6o5n7RRJwxfDpZ4g3fY2kwmD0MUSttT4CgVK zB6ZgC6mPjc6xNan8Do+UyiodxLDQUHMiBXBUIrUHPYIllJUr0pqts6n7gO53YoaJP6yR+R38 DQs9a+Z6uUO1CpZtomtonNKCvqDffwxPHDDCPAviVFFwp45ehm4VN6aYfxgTXWHNRa4XVKdGe JEJjse9doP2eQ4bk7mAEJEwp/rmvWHddjRL7L/0jZgqzKI4JRyI7/X2UMA5AZv8pFuOU1qzcl z5PB43/YZkMlHhD0M8G8+FeyRPA3O7YhMXMGNSsTtGZsCHaf5Tn1mX8KA2zsQ7hS+q6x6ishq YbcGb1e/bwpR1DM8paDChJWz6iFBVzZW14g5wDyJtLob3HfwXCRpY6OJneAZ4j4vZ/R4b7Vi1 NKXUJuq6iDd/D8vecMwNm/N7InK/LQyMONYtyRoYfaqaUMaYLFYt6redflcaeF+9g0GRfw2a6 lCa+cV8OMvAUSUPTEtq5MVSDxa6ulbW8nznSvsXM2TQ7tHvq57EO0aLP/7Hh7CyNINWTjJq0V 5zDIGMvfqeFzFzqS6k/4XDaUAc98YnK6guUaNzSdVzyg42Aufp4mjensoHItls+FXA8Vd8pOi O1tyM7Kx7NY0AKhSzojY8MZ2BtQ8SxZBS7oIsvwSJCdPjVXBNHiVxwoVDJDMerjMO0R8mmF9n 58P2GJYi69eMK+oWUTMzlQBMgnBQEwBZtcWfCtjqw0hg59PLCMOj6/O8t3aEQYsQgn1DlsPKn KtReEMeVMfxnTOWUs/Yg38070kW1/ZI4uzcK4SgcNCnfuKmii0v0RXtWn6Tm5tBuCn1GvNsfE ac8eeoMDEyw/wBCC5sjTswMywqD17xxadLHf+njmC4M2vv1v49lXY5pEWg4fLrQTnJfJnLPhf NMMuVrPRNbKVqpPy4RIzd8ClI7TDyi/w9pIwDEAqrjWsfFUfS1OUOvrcniNvkYXcTJ0xOOpIS QSgBw+DtP3l8Pw3htnghmhzdfLxYD+e3tTgC6EtqS6xKyc/inRpKQeOQRmkXvZ4F7iIkAtLLq Eeo4+xWrwDGpioJhqhozkHcUvQsuthsPaf+n/ARgbUTY7Hb6mW6I56fyF5EcFwQSEVgoQhCX9 RXcQ0E+g1ntiY8tyCMTsBvxD9O7kERHOa2qoAw+b4MBtb7AXMhGGapcRwhT1GldtVeep8tYFi 9sOd3l3gAqM0jgy9EqspgT48MsUscD/QGroIirdvZEphQmOxzUUM0YR28TIbou726AeFKiqsj cOF1OlscbXM4WimEf9aS8OZdw5gNwsuHFP/9ZKMKfxur0Dbbp9AjYgLuzM0pV8V73+bPr4Vrw J8JT2apUQCJHtF8gA9DXkGt5LLgjiHbbfiD3ckftbsS2k7TIhnRKjfN3BgwW5N66lTqJAAzUQ 567ebOpRc4oCUCI8StG4HkirFjb6flYuTW7ciwNZf0fBgmTrtvSXCSBI0ABE60kc0k3DAynb5 dRvOLWBFHGm5c6FuzKzpqQwUmZ4PTtg0NMhtdRHH8R7wJQ3MuqeCMJrhA2yzyoGZEdEVfaVcb xTsKbtKeO6C1JU1rMe5X4DeE3n2ZRE5sOZq07W2aLlukEicy9sOkvIMN6AvzyuewB4S/oiwyh n6XA4pG6qwDUcMq0gP7o/fFKBoG+J7yTRN1ro9yLEa92NMJEQXXZtWZ1/ZVBktGeggM2DtxNl hULPni4WIMfCwAA+fAlpuNbFradzKfWPLL7hLrO232My1+MHi9ztoIahBksjIRbeM09gWG0hF rQ9gm0hK9pAKlmVDT6f+Re+wHJYM3Zs1mUukOQ4wDLXK7S/oV12KPkIEVr0imSU53UN9MmNfq QfadjE669VS54Dga4wAyLkvEiXDKSId6K0IzpPTrfRkvhR9RTGc1gra0tTeIn/ILQP4oz8vKc muR0RedgwuhmqS5PwZt9/wHAST+svDf7Ejrdrm3iLykKhlBhVxinmMwrnvKK53HesriMOeOW3 LpJIQ0RAzqVuZ9haF3T0LNQ0pGLv6F+mkmsP3L1ymsZt6IyQKdZFwxFZllRCl0SdI8aPeogmM uF0j9t4MSNHKQwwmXqZe3GwOr70O5q9hHICPr57tmGF9iWDiPxVRYbhFK3t61FZg0pNk1GOiz aWc1ZX0QWVbHwYLRAvWjjo6YOPLLht27LLZ7LwE+oO4TQYYE7k1K3KcYGJ6dsljTOr2MV1r/X mX2T35IjBydCh9jSA0+8L7L+RNsrtPdeMoQhqPJ60ljo70v3thrMTTiYqLOA4sZn8x/k30hq+ rBTqTXGO6Ged2eHDwtXvQFrU3ltmDRrMIBaUVOf/PN7VxrDCHedPPVDDla4ER81hM9tCKAxfj oFO/oZ0GIHfUm2YpR9VwVc1FAZlfJg3Pn3/pck1dQuJ8MO9MbcRgapcHsjUjDGzdyHqJrUjhC yG8L/qXAJu6JHCfCRpgBzsw1r+QzBw9pSbzSi+mrLUCgiblz0CYeGKnm6dACKwabIalx16fXd qAUtpzJKO59IvV6hhh+GUaimmTWq9nkBZ3kwLv1LonvVH2HhEOCE++IuWuvVqbzmCMw22rbIx AEf9k472c4MnEe8uYeMhHYhNtB0c2ZXug/4/qSop0cLt9l7ridS0xgwXIAXjyxxw8SM/79DjJ zeLC4/USkojATLltCsbj89OX+KQHunJF3NzdcADz22XFlxGN3KnUVZ4K2uptCvejy/zMRPVER Vx1e32DLZmqyEe6/7Kxcft0B2ezd4QX/wU97DRhJ3n0+KYCoUMF4XEoXDr7bg3/b+ba+q3Nti wgK6HblHqBbQ7ScNANSPR/h1vE5cJ3bpU4E2drwdbKWeHba82XiMmdYtTikYqxFhY7TcDEUhu 035bQ== Message-ID-Hash: 5RITM7EQPAEHIHMVQQ2EPSHMXKYNUGZU X-Message-ID-Hash: 5RITM7EQPAEHIHMVQQ2EPSHMXKYNUGZU X-MailFrom: moeller0@gmx.de 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 looking less niche as its retail presence expands List-Id: "Starlink has bufferbloat. Bad." Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > On 25. Sep 2025, at 19:45, Michael Richardson via Starlink = wrote: >=20 > {resending without signature, since new list can't cope with = attachments yet} >=20 > Luis A. Cornejo via Starlink wrote: >> Since Starlink controls all the wireless parts of their system. Does >> anybody here know what they could do to mitigate the limits of >> classical wireless comms, like Shannon-Hartley Capacity Theorem or = the >> interference? >=20 > I don't know much about this part. > I am kinda hijacking this thread, but I think there is a connection. > Dr.Pan gave a talk about Starlink measurements last week in Ottawa. > (The time slot was way too short. Very nice talk) >=20 > I was thinking about the many places where bandwidth can go up and = down, both > for Starlink's various mis-attachment situations, but also for = OneWeb's Polar > orbit mechanism. (I didn't know it was doing that). > And just getting redirected to a different downlink/base-station, and = then > have to cross over Starlink's internal network to the same exit point. > (Too bad MobileIP never took off) >=20 > I think the only thing worse than bufferbloat is varying bandwidth = rates. > That's because the only way to use that bandwidth is to introduce = bufferbloat :-) > It was the cablemodem burst mechanism that clued Jim into bufferbloat. >=20 > So my related question is, if they could mitigate, they likely can't = do it > continuously, so things will up/down. The IETF now has a SCONE WG, = with the > aim of inserting signals into QUIC traffic about bandwidth available. > Yes, meddling by middle boxes. Ick. Regarding SCONE: "The Standard Communication with Network Elements (SCONE) protocol is negotiated by QUIC endpoints. This protocol provides a means for network elements to signal the maximum available sustained throughput, or rate limits, for flows of UDP datagrams that transit that network element to a QUIC endpoint." That is going nowhere productive...=20 a) restricting this to QUIC is fine only if you believe that QUIC will = take over all traffic soon (keep in mind what we expected for IPv6) b) "signal the maximum available sustained throughput" on a shared = network like the internet has a simple true answer "0B"... IMHO what we will end up doing, after exhaustively attempting and = failing with more ambitious schemes like SCONE is tp collect something = like the maximum of current capacity use in percent of all nodes along a = path and have the endpoints use this to track changes in left over = capacity and try to control their rates accordingly. That is better = rate-control that is still driven by the endpoints. > Could Starlink even do this given the lack of L3 processing along the > entire link? At least according to Dr. Pan's diagrams. > (An L2 hop could well mess with packets too). > Ideally, one or more of the satellites involved in the ISL would > know what the current bandwidth to a given terminal is, and could = inform the > end system. >=20 > The two questions: > 1. are the limits/conditions stable enough for long enough that the = available > bandwidth could be communicated back to the uplink? "long enough" is a relative term... but sure if the latency/"frequency = of signalling" is substantially slower than the expected capacity = fluctuations then this will not gain much, but if enough of those = fluctuations are "slow" compared the RTT of a flow this scheme can have = overall beneficial effects. >=20 > 2. assuming, yes, what would the best place to do the SCONE marking? In our dreams.... in reality instead use the kind of marking that has = already been shown to work in the real life... if I sound disillusioned = about SCONE it is because I am, we knew even before L4S was ratified, = that it is "too little, too late" and again instead of doing the proven = thing IETF contemplates another academic proposal. I wonder who has the = actual problem of a missing advisory signal that SCONE offers to solve. >=20 >>> Let's recap: Spectrum's boxed in, and power is boxed in. That = imposes >>> a hard limit on total capacity (look up the Shannon-Hartley Capacity >>> Theorem if you don't believe me). This capacity is all that Starlink >>> has to share among its users in a cell. No matter how many = satellites >>> they launch or how big the rocket. Add more users in a cell, and the >>> capacity per user there has to go down. Law of nature. >=20 > And users will need to know what they have on a minute-by-minute basis = so > that they avoid screwing themselves, let alone their neighbours. That is what feed-back-based rate-control and some modicum of healthy = (transient shock-absorber-style) buffering is for, no? > Packets going up the link, then being dropped, is just wasted. Sure, if we veridically knew which packts will get dropped, we could = avoid sending them in the fist place ;) >=20 > ps: > I have been watching: = https://www.youtube.com/playlist?list=3DPL-_93BVApb58SXL-BCv4rVHL-8GuC2WGb= > where they have powered up 50+ year old Apollo Transponders. >=20 > -- > ] Never tell me the odds! | ipv6 mesh = networks [ > ] Michael Richardson, Sandelman Software Works | IoT = architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [ > _______________________________________________ > Starlink mailing list -- starlink@lists.bufferbloat.net > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net