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.15.15]) by mail.toke.dk (Postfix) with ESMTPS id 7745B70164E for ; Sun, 28 Sep 2025 12:47:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.de; s=s31663417; t=1759056439; x=1759661239; i=moeller0@gmx.de; bh=V+0HFQpxkslxP+uF24RNVvMxj0Hl8ltd3uFgAWuztO0=; 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=enhayiFGnng45/DvTUKk+zW3R03wCYOR5zczkSviXjWg7z6jeQjyhaLRmEaY1fw+ 0/pB/jDIla16esgRtmCmx8gP0DMot/f0qrjHTgB2id8k0qs/wTB+K4NiX70Nwu62x RuHT4ydQoixa62HOJ/FnTTdvKrb9vFppWxxC7Uf4nBa1moXX2iVPMyrzVZTKyYyxI 52TX7Io0h/szL21FFB8AR3Z5ACxfxL9oHUhnOh1Lb704qjr7oUzbxgLTgdNJBxnOb WakKzo2w5gLMR/jNLeCtmGdH2uk8DpwGsEZemMsqrd918/cUppdQF0OusNldF3sul pSOl6NsoqGxYy5a/3g== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([185.104.138.140]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MY6Cl-1uoLXe2LTp-00TtIA; Sun, 28 Sep 2025 12:47:19 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.700.81\)) From: Sebastian Moeller X-Priority: 3 (Normal) In-Reply-To: <1759003996.780613387@apps.rackspace.com> Date: Sun, 28 Sep 2025 12:47:06 +0200 Cc: starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <2F8F8566-5C5E-4D96-AA48-90313FD33996@gmx.de> References: <175895289005.1561.17970219906621123011@gauss> <1759003996.780613387@apps.rackspace.com> To: "David P. Reed" X-Mailer: Apple Mail (2.3826.700.81) X-Provags-ID: V03:K1:fU2hmTFrLASUaoL33HHzharMxLNAQpS9ualkkNLGx/FKGsPXyEr wcjfnkce/IQXB/atAxtpgkjcC3UqxzoLsjxYg9TLof7SPpYgFG+QfkPDSOffr6t7iQCeGJG pRFvTzuT760OEQqOCHCREcU6irIZ023vc3dUJSsdOzePogYVEwXsWukIfCvYxQ2ZZdt/wPK g02D4Q/zrmzJN3k3pZbHg== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:Kh6CdDJhod0=;Op0vncvY9pNyc2ks6XTDg03bcix OWimK5Tt6EfbfIIxRdEoZ56KhWMchECfAayUba3AS3/+ZI+qsy0B9f5VjqwsiXSIRH1ejUHUl /wNegn5ap6inUmpx9mgVkCHZ+9Icfvdh1bjr/y/X63zrX5DwTCbp5ININ9b5mwkQgQBkbJi/s 3B4k5MzlJ00swLvYgCRmONKlarQQh9jY6yqoCd38qjXWT+8/Cwjqwa7W3d5NCsd26aTUJvGZb t6kKwBP9pkQrOpiY3vgbIWxnM9Y09WuAgqtsfVTDWWxU9NcFHXo8j5TUaZveeitrkSdHYYR6P tix6Of+Sbe3TPAEEERcFCUQ565wgUgQkODHkqkeb/gV0JQZeqZT2HwPu/M/YcJ+LHu1vB4CBs M6Q4OiZL0niFrEOO+HeOjZXF8yEIKrqTgG3j336yAMoMvwDKcXOkrxwzp9yx6pY/XeiJkA6WI cZXeTNQEx4ShAcXLY8U7fxHiph30o+Nn8ocHEGHGsqQeoYFoyvYK0Xc6rcutv1e1dfmGEb1WI cQAc5YTYmxIcx3mhFryrxY0xXei+/HdfUOR9E/sYPJEfqJHe8Z2IoUhMqAEK9MLxK9jt0ZwMz O/i9+JaDYmwAKSgHe/J99rXEpohiynjod8PIu2n6EZgkdvQfwAQMjUmJeusWBQUtVdXzZGUTR d5VgG+RpAuuLI6ubQYfqlzzrxMReuqvkBkJYg9Qrp7QhxhFDTcWC95CtBqWpQWwZwBwYbNiDI 0dfyEYdCB3HSbuIuOeJY2zHi0hoFLXzLcfT7+mKb1nT1Hpbrh1bXyPrtjfWzfhaydGPdOMryq XnOH/4ImmaO4Rop42Tym82qhV2WYXEUuWv1N0MBn9R4KxQe62mlmjVIFqxSpUSkjNa2YafiMi VWlRj39yzxPyayQgBJ+jtl19+0RpYoOIUcspskfcHJRLgur2szBMEWnDtcwBYwGkCkgEjSSlR I3cEG5WhCq5c7f6Em0uw7PusszOGtsBg+NDir/EWfz7SI2lf4zQAulIrGHGtdBLim524fa6Mo QfYVQKYUHlzwdtTB0ZaLVQ6bc0u7gg/+IMpf5IdIgv6lA47jBgXi+7SRhMdnOy6T4gV0UtIFM PUY5VICxa28wBJwHVqI+H6rWleG4JonreYJBjOfZHP+sn8jFsEX0pQQwOlhnE/kp3EW93+IQ7 7JADe54P3IHxOBemGkg8PybLHdzscsRvtvwx9LinQ1Qna/z0z4pccOGGVn6dZ9aeVLxMZBNfD d9Jea1ZN5uT2RZV4ffqKf6ER0gjQFIm+Ey4SgUt8Rm+GUHSFBWwXYvxdxQ/HUpL+3Ov247ejs 4gzKw+ZAoNzmV8KDeSNn7oKVi4NQyvHpvcnq1OIm3DYsYI9wDBlOiEzm+CMpBfBNttfWQ/ykP UOwLSuCMCS0oAgKl7BQDolHmFSzNx9Sgq/eDnhjc6lalCJD8QZ+ewiclrPtKW192A9aCf4+nZ +g/BNSIbzKFFDAC0K3Yu9jvD77pfv0rezmVIm6RVxGpL/FeNF1A51qGrBBTmXL9SL7CXyY2Fe xKNVf7GWpl1ALu3Fxfup/r5fix7jZBxqz7iMwKvkoeee1AZvf4bl2IURLj/3wlagOI3iy6NdL bPr2ApcC3bmtCGRtb75udj5nm1CeNDSW8crJYnC+XnF9GtO09g5/kev7zVLjjiwNjGrTiMZ+a WwPXPFbJtYFvb2G8qWL+2TzUBgOygicMmDK6uWhKmjPDd0IKv3x/LCyOT9kyRLiQT15XcV85D vC8lFlegtLupwubS8/A6t1I66a5Sy92HcmMMuBZXOgRzxVzAELCzxgec8+fvCI0ZtKlLIK94q hTZbiPmZJdmILr4F3aCr2oOvYwF6VY0eBIpTEmQmzYGGuYKvIO4L3gXep2gqcyPGifrU77rwn gBGlBlYPIJORGDTNUDfToeH9+PxioEguzqAPxhUfkhSgUohIyGXFgDNdJn/336z6SQbOIP4wq Y0s+rWrph3fLZ+OMqDO8tx/rIsFFAa8TQvvEqOi9msfDEQ+yiAwzka/Efjnz6fEs/SEwf2sKo nu0AKvKw7c0V5ccgTwX9qTjhcsgxTtueDIhUStP878oHvRkvBR+KX9K7STfdM9ZayMuDJ/lkn Pm0ZMx2UZ0zM/XMJjBZgTWuNGas96TCk6El+kZS/8+729CARyOU0ZY/bMttiZRHX5OkyE2W7j 61WjpZJt1+jPjSNiDbgFvf0lixncQeV488NPfbhrAPc10iVUlT2htb5+RdTroWTLb7DqkOaeO c2nAoxoteISWtPYLRnKM6n1hhnMOPoVVY/gGkuGdESQkKWUxUcip4IxM9DN9kcRs9yWqRR/UZ xD7AhUmEimM+i7nxOZ7PaBR4lgIFDpure0yopJ+NznHr7/lbVs+JdsiKxOPC+T0lP1I9dHrw/ EEj9dXOeg9knNmbsTr8zNtAEXT90EXZX+S2OPSGcLhV+adRxSu7AkI1Yt7Pm5uCFbFVu2/xt5 ETcLpzqWrC7vaHQBck51H6l2CsnHnTmSdGgpdfROuHzsZt8RhkbT4aghsupO6iseKEyj412uh 5ZvN+9uYg6DZNqJwMM+mybEraIPnpbjZ+dahw5Jpd3wvsSHZcXUarvPMoASFyflEsQjQDgmII HBL/MnbDfZHuEsmINBLzh/nxpJZFzpQV6F1mr1xFSNKwkxzs3Sjs1Fd+K+Y2q2hP7zFgzeNC7 qVdzcS9nPq+VgdkkvA96/Zp7K3q/0ke0hMWPva4uMseKflmBxCsmJUjS4548y1IcmNwB++inD muY2VCZI0l0EM3ABTLmhJsxND5QTvl0QCob+HCs4tqbjjLV5lmEkyX4kBenx5svQx9qfx9moW 3wqGhxVuZEF573VXSzIJh3Le2bvOrptOLYMg8IBBIAj+g97LmG5Dn6ztwsSmzOHvgStJjSxqp qz4lWr+8Jpo/b6ZtXQmbkdju3mzQbo65n5/oZkgVUKsr8A2UGyFkqiOztAguXh95ZCbb/4lY2 Ov/8q/W447+43YBFfXpA2Lq1A7vdRlg9BXmcGn+WrpWuAcpKi6Xc8byBATn2K7UXRiPTqOMM/ KdvHeXCris0i0r95apqOa5d9C3QIceRP4ZR5aBn3uTWfIa//9FxXerHibyYw+t/tJTvgBMmTf NQFE4VbA578PujCpBIK8KzL2ulMGngUeJAXoA0rUTfA8VHTcxUP3wK2xsR+jiwrKC/zkvfW76 kWRLXWZwLCnhEjsfXiJrSijRVY7XIevHHg2diFgQecpvC4BqQQ+/1PZSBO+nMiQZrCoHLcGiH DiZwmgoEN83N3Ol5SsYx2arsccRS9RJ8HW0DZSxE0K/gEXOTrjotDP/AWX2MFz6Hw67/mrDBb GUeMvD5oOVQGZkXHOggV0ZjAStjQ2+RO+r/NCzAdZKnS37mu8mtXRkRB3YCsnUUTsjcpdmrte oOy4i3z7FHGOsSbFtpRoo2/M9vhzDk2el35reuuaVGmWzFbna11DmPX6RZDmUDrD/Z0yCA1HK 2UJ/segRwa0IJgtz4f88Wp/GTxuoDuw6VGTC/c2Q2bw4tyZ0X2nDyouC7rezMzqN4OTahdM1z d+q00gTDz5GfTGoSlOzoxdI4Chd/YYeWYZdBXrKC3xBfe3IWjJ2MzEB7+IkaBRyV88tbLfTho expIqQ1eJaQ/gsEndnLJq9ZIqx3o8F2LSvGG7LtTYm9yZAAEYM9jGSzhS5yuWCebCNeC3PbTY xtgZEo11Mo8Uqbw2Y72ONcn088WpDR5Jj79jlN1y7osrPbSzMVzR8AJK115J6o/kv26OFgLZh RA8jctOTn2sLz9LTE4fbpwtupK5WCTKLBiTcA82G21w6EWt0I7J2Hs6PxRDmcRON6bXnVByK1 YeJx8JZIr8N6YSUuPMwovqkY5DVM86tlRRkEMPsGetEZJM9d6CMtauGRE0QHXUXfuf1Txh/Vc CV1P7XF/Nq6adcxm2tbl6vD+uoPrnySk2SFJB0RFM79UJ2LS4fDY8iSzU+esA8GmrPPdKCZek 5iOydteZFKDeAFT5Q51cknFHmQatB+n69AgpqI90Y3s6dIikX4OUVvAxb/QIaoxdpTP/jxNz7 HsXLjqmZGyPGso2cNAzTHlQa2M9Q0BMB0yEZTgsfS7i6uQ+xWUUoTY4jQFyVj46k3/qKKEG5q 4CBNs+pjDtgFd9xBYfaF7j+i5r/z853fEMpYHWONG8fzOyFR0h/Hwe6ASQkXiXQszY+m1Z0yM sFdwRARLjiDqtJweTSIZTuoYBzIGgns2f/2iHAJYFuq+B1plDPwaPjl7ggBUcXhxFAs+zgC/y 3bSuywI4J3vXU4XYAxKB39sPKnSOCD6mJg4LcKyevx6qjAINxQhYxkxhu3R1SPAzIk1CLovgi rqVb9L01P8F6dqvJK3EdH9CXnsUIRF9Et6A0c5fO/Z/EizYvaPXZ/z/WgtChTpIIm/Rcv4DAv W2NHN5m0xmrgzQ/wKcLNy2ZF3g71dS6tQ5/63wpoRC9DujTLPtWnXIs13B9FWbbcNs0hqdpZI X13p3YRd6emWmE/RUxJf7MJuyRhZ2PU6Kj09BBpOVwbyKB88uOxIgFb2DWxWr1EyJh5bFxmmJ x8+zOTjRYYNX7W3Id8q7S/UVf3P3wscQ5X2t8f7E5jNf27J2USCwjljGEgW8x+ELpoqUX58gx ercIelc2kNGAVZAgbgK4ximqx9ZY7+c9pYYSS/gaIfCSvPSCtw4FD8/BhajsqskH4bRxBz5Xf G4eYrEKkYuI4pIx47UrYsQPeK1iMwqTnh1xvjRqfTTiKnsfLPaygm0coveI1cNmP+h8Z+S33Q IUZIfYtmszmbahhmG2N3sxUIcBYfeljJDnPhUUMnesxPeppEosmC81TjURSBnsUr5D0kFdc0j IuTLpcOdtnfSUN0+DLU6vOiiIbUoCrSp8fQhFybN7Car6gaJA6gYlOaASBMUb8PsfAGQLZfiy Qki+GWTHwb74P/9rDapDeJqHISIauFclXG9XB7ZVNWrIwPuyjBHwhPXAwvdLKv/0ulF6PwxgD 5gK1bBQVO6Z6JXu5w5PVSgfYqpXz5UXLVFUxAVLkTWQQ2sj5+Gr8h/cP Message-ID-Hash: 7FZ74B6I5BRBDPIGORI6MU2JV5SW36B6 X-Message-ID-Hash: 7FZ74B6I5BRBDPIGORI6MU2JV5SW36B6 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 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: Hi David, > On 27. Sep 2025, at 22:13, David P. Reed via Starlink = wrote: >=20 >=20 >=20 > On Saturday, September 27, 2025 02:01, = starlink-request@lists.bufferbloat.net said: >=20 >=20 >=20 >> Date: Fri, 26 Sep 2025 15:11:23 +0200 >> From: Sebastian Moeller >> Subject: [Starlink] Re: Starlink looking less niche as its retail >> presence expands >> To: Michael Richardson >> Cc: starlink@lists.bufferbloat.net >> Message-ID: >> Content-Type: text/plain; charset=3Dus-ascii >>=20 >>=20 >>=20 >>> 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. >>=20 >> 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." >=20 > Absolutely agree. Trying to have the network elements define a "steady = state" for all entities communicating over a path in the "near future" = puts the control in the wrong place. (Well, many at IETF are "net-heads" = who think they should tell applications what they "need", and view the = network elements as a consortium run by all-powerful communications = operators like, say, the PTTs and the Comcasts). >=20 > The best (most accurate) signal is still a "dropped packet" that = results from queue overflow. And it tells you only that the source sent = too much. I do have some sympathy of the network giving some help to the end-nodes = detecting the "sent too much" state faster than drop. But if push comes = to shove that drop is essentially the only "reliable" signal... >=20 > 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... >=20 > In my view this kind of network-control is the opposite of good = Internet design. It's almost as bad as having ChatGPT write design = documents - pure artificial bullshittery. ;) >=20 > There is an end-to-end style approach that suggests that there is no = steady state end-to-end requirement at all - just the most fair sharing = of the achievable "responsiveness" or "low latency" of the end-to-end = applications. +1 >=20 > To achieve that, "throughput" matters very little. Queueing delay is = what matters. +1 >=20 > The current Internet tries to make ALL queues as close to zero in = length as possible. It doesn't succeed, of course - it can't predict = what "end users" will try to start and when. With an oracle scheduler all problems would go away :) > There's no "statistical predictor" of short-term demand that works = (yeah, you all took classes that said "assume an average load of X", and = never asked "why assume that?" I did and the answer is, that's not = reality or close to it). >=20 > So the best answer of SCONE is "the maximum you can expect" has a = denominator of the number of possible flows that can go through that = network element, and a numerator of some fixed number. >=20 > And by Little's Lemma, the latency you will get, if you fully allocate = it, is "infinity seconds". BTW, I do see some use of SCONE's maximum the path will ever sustain = information, but that is so extremely niche, that the IETF should not = bother... In cake-autorate (and similar approaches like purple-aimd = https://conference.apnic.net/60/assets/presentation-files/f6110bfa-918f-43= 0a-95d6-60a4524d62cf.pdf) were we try to adapt a traffic shaper to path = capacity* having that information available would offer a small = optimisation avoiding trying to increase the shaper above that value... = however we would need that signal not per flow and we would need to be = able to trust it. And there it essentially stops, unless an ISP is using = that signal for a load-bearing part of its own infrastructure there is = little reason this will ever be trustworthy over the open internet... it = might work for internal use-cases within corporate networks.... *) Running full steam ahead into a variant " no "statistical predictor" = of short-term ..." problem you describes, aiming not for a theoretically = perfect solution, but just for something better than doing nothing at = all. Regards Sebastian >=20 >=20 >=20 >=20 >>=20 >> That is going nowhere productive... >> 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"... >>=20 >> 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. >>=20 >>=20 >>> 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? >>=20 >> "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 >>>=20 >>> 2. assuming, yes, what would the best place to do the SCONE marking? >>=20 >> 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 >>>=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. >>=20 >> That is what feed-back-based rate-control and some modicum of healthy = (transient >> shock-absorber-style) buffering is for, no? >>=20 >>> Packets going up the link, then being dropped, is just wasted. >>=20 >> Sure, if we veridically knew which packts will get dropped, we could = avoid sending >> them in the fist place ;) >>=20 >>=20 >>>=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 >>=20 >>=20 >> ------------------------------ >>=20 >> Subject: Digest Footer >>=20 >> _______________________________________________ >> Starlink mailing list -- starlink@lists.bufferbloat.net >> To unsubscribe send an email to starlink-leave@lists.bufferbloat.net >>=20 >>=20 >> ------------------------------ >>=20 >> End of Starlink Digest, Vol 53, Issue 14 >> **************************************** >>=20 > _______________________________________________ > Starlink mailing list -- starlink@lists.bufferbloat.net > To unsubscribe send an email to starlink-leave@lists.bufferbloat.net