From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp79.iad3a.emailsrvr.com (smtp79.iad3a.emailsrvr.com [173.203.187.79]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 344093B29D for ; Mon, 2 Aug 2021 10:57:57 -0400 (EDT) Received: from app57.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp26.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C703842D0 for ; Mon, 2 Aug 2021 10:57:56 -0400 (EDT) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app57.wa-webapps.iad3a (Postfix) with ESMTP id B1A8FE0129 for ; Mon, 2 Aug 2021 10:57:56 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Mon, 2 Aug 2021 10:57:56 -0400 (EDT) X-Auth-ID: dpreed@deepplum.com Date: Mon, 2 Aug 2021 10:57:56 -0400 (EDT) From: "David P. Reed" To: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: X-Client-IP: 209.6.168.128 Message-ID: <1627916276.724715743@apps.rackspace.com> X-Mailer: webmail/19.0.8-RC X-Classification-ID: d087a274-6e46-4841-991e-1509dcdd1e56-1-1 Subject: [Starlink] Bloat generic discussions on Starlink list X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 14:57:57 -0000 It appears that Dave Taht and others have expanded this list to an incredib= ly diverse collection of folks that are interested in all kinds of things (= imagined and real) about Starlink by adding cc's etc.=0A=0AI have no partic= ular issue either way, but...=0A=0AThe technical issues of AQM and the deep= understanding of the "lag under load" or "queueing anomalies" in the Inter= net are somewhat technically difficult to comprehend, as those who have bee= n working on this issue for nearly 50 years now understand.=0A=0AThe divers= e nature of people on this list allows "everyone to have the expertise to h= ave an opinion" largely based on incorrect understandings of the underlying= network architectural problems that the Internet has successfully addresse= d, and those that are still ongoing work.=0A=0ASadly, the idea of "back pre= ssure from the network to the sender" is now resurfacing as a "solution", r= ather than local queue management and signalling to the *packet destination= * not the source. There are very good reasons why the Internet is architect= ed the way it is, and why congestion control is done at the queue managemen= t level in a forwarding node whose input rate can exceed its output rate. = =0A=0AAnd few, even most wannabe protocol designers, understand why congest= ion control is a *global* phenomenon, not a per-flow phenomenon, which requ= ires a specific kind of *fairness* in order to prevent livelock or deadlock= of the network. (Not the kind of "fairness" that strives to perfectly bala= nce all users with precisely equal service, but what is technically called = fairness in the literature on synchronization and scheduling primitives lik= e semaphores, ...).=0A=0ASo - I'd suggest that it is a waste of time here t= o propose solutions to the "bloat" problem of the Internet here on this lis= t, or to debate the clueless, or even to invent "explanations" (like "backp= ressure in the pipes") that are profoundly misleading.=0A=0AInstead, talk a= bout how cool the "phased array" antennas are (even though they aren't phas= ed arrays, just multi-element MIMO antennas). Or speculate on how Starlink = might perhaps replace any need for fiber by using inter-satellite mesh rout= ing dynamics that somehow fix the "congestion" problem by scrambling routin= g every few minutes so the paths are never stable.=0A=0AI personally think = fixing the Starlink-caused internal bufferbloat issues to deliver on Musk's= promise of well under 20 msec. end to end packet latency is pretty damn ha= rd, and this free-for-all won't help anyone get there.=0A=0AHave fun...=0A= =0A=0AOn Sunday, August 1, 2021 12:00pm, starlink-request@lists.bufferbloat= .net said:=0A=0A> Send Starlink mailing list submissions to=0A> =09starlink= @lists.bufferbloat.net=0A> =0A> To subscribe or unsubscribe via the World W= ide Web, visit=0A> =09https://lists.bufferbloat.net/listinfo/starlink=0A> o= r, via email, send a message with subject or body 'help' to=0A> =09starlink= -request@lists.bufferbloat.net=0A> =0A> You can reach the person managing t= he list at=0A> =09starlink-owner@lists.bufferbloat.net=0A> =0A> When replyi= ng, please edit your Subject line so it is more specific=0A> than "Re: Cont= ents of Starlink digest..."=0A> =0A> =0A> Today's Topics:=0A> =0A> 1. Re= : [Bloat] Of interest: Comcast AQM Paper (Neal Cardwell)=0A> 2. Re: [Blo= at] Of interest: Comcast AQM Paper (Michael Richardson)=0A> =0A> =0A> -----= -----------------------------------------------------------------=0A> =0A> = Message: 1=0A> Date: Sat, 31 Jul 2021 18:55:53 -0400=0A> From: Neal Cardwel= l =0A> To: Aaron Wood =0A> Cc: Sim= on Barber ,=0A> =09"starlink@lists.bufferbloat.net" <= starlink@lists.bufferbloat.net>,=0A> =09bloat = =0A> Subject: Re: [Starlink] [Bloat] Of interest: Comcast AQM Paper=0A> Mes= sage-ID:=0A> =09=0A> Content-Type: text/plain; charset=3D"UTF-8"=0A> =0A> On Sat, = Jul 31, 2021 at 3:27 PM Aaron Wood wrote:=0A>>=0A>> If = we see that AQM appears to be not functioning as expected=0A>> for upstrea= m connections on DOCSIS3.1, what's the right avenue=0A>> for getting that r= esolved? (and does that only apply to the=0A>> Comcast-owned, vs. customer= -owned, modems?)=0A> =0A> FWIW, from the paper it sounds like not all Comca= st cable modems=0A> had/have PIE, which enabled the A/B experiment:=0A> =0A= > "10. Latency Measurement Results=0A> As explained earlier, for two varian= ts of XB6 cable modem gateway,=0A> upstream DOCSIS-PIE AQM was enabled on t= he CGM4140COM (experiment)=0A> variant but was not available on the TG3482G= (control) variant during=0A> the measurement period. The TG3482G variant u= sed a buffer control=0A> configuration that predated AQM in DOCSIS."=0A> = =0A> neal=0A> =0A>>=0A>> On Sat, Jul 31, 2021 at 10:50 AM Simon Barber wrote:=0A>>>=0A>>> Awesome to hear that you are turning = this on both upstream and downstream. Do=0A>>> you know if the wifi stacks = in your home routers also have AQM?=0A>>>=0A>>> Simon=0A>>>=0A>>>=0A>>> > O= n Jul 30, 2021, at 10:28 PM, Livingood, Jason via Bloat=0A>>> wrote:=0A>>> >=0A>>> > FYI that I will be presenting a lig= htning talk at the IRTF MAPRG meeting today=0A>>> at 17:30 ET=0A>>> (https:= //datatracker.ietf.org/meeting/111/materials/agenda-111-maprg). The=0A>>> t= alk links to a just-published paper at https://arxiv.org/abs/2107.13968=0A>= >> (click PDF link in upper right of page) that will likely be of interest = to=0A>>> these two lists.=0A>>> >=0A>>> > High-level: turning on AQM in the= cable modem (upstream queue) took working=0A>>> latency from around 250 ms= to between 15-30 ms, which is actually kind of=0A>>> cool. ;-) AQM is turn= ed on in all of our CMTSes (downstream queue) and in=0A>>> DOCSIS 3.1 modem= s (upstream queue).=0A>>> >=0A>>> > Have a nice weekend,=0A>>> > Jason=0A>>= > >=0A>>> > _______________________________________________=0A>>> > Bloat m= ailing list=0A>>> > Bloat@lists.bufferbloat.net=0A>>> > https://lists.buffe= rbloat.net/listinfo/bloat=0A>>>=0A>>> _____________________________________= __________=0A>>> Bloat mailing list=0A>>> Bloat@lists.bufferbloat.net=0A>>>= https://lists.bufferbloat.net/listinfo/bloat=0A>>=0A>> ___________________= ____________________________=0A>> Bloat mailing list=0A>> Bloat@lists.buffe= rbloat.net=0A>> https://lists.bufferbloat.net/listinfo/bloat=0A> =0A> =0A> = ------------------------------=0A> =0A> Message: 2=0A> Date: Sun, 01 Aug 20= 21 09:13:25 -0400=0A> From: Michael Richardson =0A> = To: Neal Cardwell , Aaron Wood=0A> =09, "starlink\@lists.bufferbloat.net"=0A> =09, bloat =0A> Subject: Re: [Starlink] [Bloa= t] Of interest: Comcast AQM Paper=0A> Message-ID: <27719.1627823605@localho= st>=0A> Content-Type: text/plain; charset=3D"utf-8"=0A> =0A> =0A> Neal Card= well via Bloat wrote:=0A> > On Sat, Jul 3= 1, 2021 at 3:27 PM Aaron Wood wrote:=0A> >>=0A> = >> If we see that AQM appears to be not functioning as expected=0A> >>= for upstream connections on DOCSIS3.1, what's the right avenue=0A> >> = for getting that resolved? (and does that only apply to the=0A> >> Com= cast-owned, vs. customer-owned, modems?)=0A> =0A> > FWIW, from the pape= r it sounds like not all Comcast cable modems=0A> > had/have PIE, which= enabled the A/B experiment:=0A> =0A> This does bring up an interesting dis= covery question:=0A> =0A> the presences of AQM (whether PIE or FQ_CODEL), a= nd what the settings might=0A> be (for some things need to be tuned), would= be something that might be=0A> interested to emit via LLDP.=0A> And/or at = a /.well-known URL (accessible via IPv6-LL only).=0A> =0A> --=0A> Michael R= ichardson . o O ( IPv6 I=C3=B8T consulting )=0A> = Sandelman Software Works Inc, Ottawa and Worldwide=0A> =0A> =0A>= =0A> =0A> -------------- next part --------------=0A> A non-text attachmen= t was scrubbed...=0A> Name: signature.asc=0A> Type: application/pgp-signatu= re=0A> Size: 487 bytes=0A> Desc: not available=0A> URL:=0A> =0A> =0A> ------------------------------=0A> =0A> Subject: Digest= Footer=0A> =0A> _______________________________________________=0A> Starli= nk mailing list=0A> Starlink@lists.bufferbloat.net=0A> https://lists.buffer= bloat.net/listinfo/starlink=0A> =0A> =0A> ------------------------------=0A= > =0A> End of Starlink Digest, Vol 5, Issue 1=0A> *************************= *************=0A> =0A