From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 144613B2A4 for ; Tue, 3 Jan 2023 03:18:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1672733935; bh=DYmsf3I2FsAPWtUGjfp4MYMvq0sO/+EDTEzszPeyYpE=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References; b=fjta2wHnZ9kEvWOqcgchZ2Y52i7EpUtdM/8RT8dkRbAHo9gIur0h5slldtZCxjy9c S931Nwcnnf65AZbvYRhc3B0G7WT9lqVRyCpiFsgjeGirspja0s46jBIFsDASEe683w QmWSNTsHTbEvMakWIpS5NEw1n9P4HUxQ6sXB/J//2cUl5/4uKRLJtip1EqiJ3gyxDQ 1y7ADj9/Q2eIGElIyOCwTfHyL7AI8mLGfP/rsBc4HLpopSue/YsuK4mabbeqrxwKIL GRMnI5u/MYV2H1Co9Rv2gnPVINxk82SM5fXMmwji6OUehh5eLIq78zcgmD1tg4z37f rtBvo6nCKhhUw== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [127.0.0.1] ([80.187.113.129]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MMGNC-1pUhK50XRu-00JHa9; Tue, 03 Jan 2023 09:18:55 +0100 Date: Tue, 03 Jan 2023 09:18:51 +0100 From: Sebastian Moeller To: =?ISO-8859-1?Q?David_Fern=E1ndez?= , =?ISO-8859-1?Q?David_Fern=E1ndez_via_Starlink?= , starlink User-Agent: K-9 Mail for Android In-Reply-To: References: Message-ID: <83F8919D-236A-4EFE-AC4E-137ED12A68A7@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:9KejXdnzE0nIv38IMwZz8MxuLktT/ocGV6GiJfAxAcs/scn0n4M 3laQQcog0pDruslHfb8UgsPtIC8U4m57y/tPq4HXTfPRNVGJ+skms3VyTt1v/k165OdT+PD 9VVaUPCAQu6IrcRqu96agqy9WK1W2Wmb6Entbqj1tNq0U1aOcecwWdNcMzYQ3FByIOfeH5h lC1295JOmqTorj4s2Zf8A== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:PaC3ltBLssg=;OhI6ixCQkUggBPLe3hbVKu+1RaY 0IXuviyRNkeb+M5ULQIxeQDHS3Sgd6TrKJkOe5O7mUbStiXuPot7UhbGrjOD11M3O46TZRO+N AJ8kkCLmpYuwlTHBvHc8PGOmVTk5YjSOUi13jlVwhT3NZdB5UUlXXe4GlGmqY9dWaKDjnMEfa U4RP6EjiDRiukyOvRMb0PrVvOUaMi4firJT4+A13L0CgfFBXXb/RQqQ9c0dDFGl6oKv8XtDhO YN86f7vCKxdEO1VIdFZEfSdUOIjzO31aHln7v4x6bDlgtH3SfEI9X3PjrA6R33SDv7b4Iiaeb 6CScKDA+wHNG0crVYfoe4mE5LpBwp5hNbqABFEnydrevt7oLnMTjJGJp/UpcVEXV8HPc7+woX t4GJliNThN5ekeR9xE2dH5tcWyiVGkOjqz9d9Qnh6ZFkvT/j8Y47/1y5dBqZhLm11E/uiARa7 ghzs8n265pI/5PySaZixG2BcaZ0up5OPAM8SvX1nh3wIodJWo2KU9yFfkr3hPTSOJiFWkVvAV onuK3cRyz4r+jTUd7zZaXpFy2jzZ6f1kmPoIbAWdDPrkIOKOquiFz4JwTy5dFQ18aioukFdId U/GI/aHkpLFt3AcJx2NvHgmP6I8Y2v47QrJhq+FDJs6TK6AlnOdbhNwzY9LxKkn1GkoMQetxd HuRk8dQqMt0FadMRr8O5WkWSVPdIk2jK6ck7LeXGKSwHyF7hbCyI25kpVRCQsRKkYt4NjG4ti BkVsQChoSlo8iQY1kJWm7UJBK9DBKzx/zho0sOU35orQ0i4Eh6aAxqTVEEfrI0Yg2wOb0DHbN H8gZgxIRjuBrCj/Tjp8tcTGfZYogcGtiV5ZbTAhPc38W9ZNRkYrVFPHrjhDLsJZ3BpjVShom8 +tOEN7TI1DRT9ubXHVF42FELWBk945XndAj0vbkV2kBb4UHYNZjK06MqqPSGLAyQ95xl+QMJB gbOhEFif14XQFJ+lIE8cSSog7bM= Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast 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: Tue, 03 Jan 2023 08:18:57 -0000 Hi David, On 3 January 2023 08:44:39 CET, "David Fern=C3=A1ndez via Starlink" wrote: >Well, as an end-user, I would expect that the communication system is >just properly engineered, not having to check if it is or not properly >built=2E [SM] That would indeed be great, however there really are competing interp= retations on what 'properly engineered' entails=2E E=2Eg=2E the throughput-= fixated view that results often in oversized buffers and a more balanced vi= ew that wants decent throughput with acceptable responsiveness (for varying= values of 'decent' and 'acceptable') as well as likely a completely respon= siveness-fixated perspective=2E How should your gear manufacturer know whic= h to engineer for? ATM most gear is marketed for 'top-speed' (throughput) a= nd mostly marketed like that=2E To be explicit, I consider such an almost e= xclusive throughput focus to be sub-optimal and even misguided, but I under= stand where manufacturers are coming from=2E > >Only advanced users would be using monitoring tools to assess the >quality of what they are getting=2E [SM] At least in the EU the situation with internet access link quality (d= elivering the contracted rates) got bad enough to prod the EU into releasin= g a transparency regulation (regulation 2015/2122 IIRC) that included a cal= l for national regulators to implement official speed test sites so end-use= rs can fairly measure their achieved throughput=2E This is not aimed at adv= anced users, but all users=2E > >It is somehow like pretending people to analyze the tap water at home >to check its quality=2E=20 [SM] I am not sure that is a helpful analogy for internet access or networ= k gear=2E Also at least over here water supply is heavily regulated and con= trolled and mostly in communal ownership (all of which I consider good thin= gs), but that might be a peculiarity of where I live=2E=20 > Of course, if it is easier, more and more people >will do it, but usually people just get a feeling of how things work, >most of them are not going to measure anything quantitatively, even if >it is super-easy=2E [SM] That I agree with, however inside our market economies the most promi= sing way to change what manufacturers are delivering is by changing what cu= stomers ask for=2E That includes big customers like ISPs but also end-users= that might not buy big-iron routers but mere 'plastic' CPE=2E > >Then, there is the so called brand or reputation factor=2E Getting a >reputation of good service is important not only for Starlink, but the >whole SATCOM sector=2E SATCOM is considered the last resource, >expensive, lagging and to be used when nothing else is available=2E If >it succeeds in not getting bankrupt and keeping a good service, as >perceived by users, Starlink could be changing that=2E [SM] Well starlink's biggest advantage is in being the first affordable lo= w earth orbit network (IIRC iridium was earlier and allowed normal end user= s to transfer data but at a prohibitive price) so they usher in the new gen= eration of SATCOM=2E I agree that if they play their hand well, thay could = establish themselves as the dominant player in that segment for years to co= me (assuming their so farr 'vapour-competitors' will ever built usable cons= tellations, other wise starlink will stay dominant by default)=2E But I mostly agree with your sentiment, it would be nice if networking gea= r was designed and configured for good responsiveness by default=2E Regards Sebastian > >Regards, > >David > >2023-01-02 20:00 GMT+01:00, Sebastian Moeller : >> >> >>> On Jan 2, 2023, at 19:44, Ben Greear via Starlink >>> wrote: >>> >>> On 1/2/23 9:35 AM, David Fern=C3=A1ndez via Starlink wrote: >>>> Just wondering how comes that buffering is not standardized=2E Wonder= ing >>>> why buffer sizes are left to implementation decisions of possibly >>>> clueless vendors, which devices can worsen the performance of the >>>> network=2E >>> >>> There is no perfect answer, and every configuration has some trade-off= =2E >>> >>> It is a long grind of tricky code and careful and widely varied testin= g >>> to make progress in this area=2E >> >> Also the (maximum) buffer size becomes far less relevant if the buffer = is >> properly managed=2E=2E=2E >> >> Over-sized and under-managed, that is the problematic combination=2E >> >> That said, part of the challenge is that throughput is easy to measure = and >> is actively marketed and consumers have learned to look for these numbe= rs=2E >> So manufacturers increasing throughput by enlarging buffers is at least >> understandable in our market economy=2E >> This is why it is important to educate end-users and supply easy tools = to >> allow them to effortlessly measure the effect of over-buffering on >> interactivity=2E >> >> Regards >> Sebastian >> >> >> >>> >>> Thanks, >>> Ben >>> >>>>> Date: Fri, 23 Dec 2022 19:00:56 -0500 (EST) >>>>> From: "David P=2E Reed" >>>>> To: starlink-request@lists=2Ebufferbloat=2Enet >>>>> Cc: starlink@lists=2Ebufferbloat=2Enet >>>>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast >>>>> Message-ID: <1671840056=2E20758968@mobile=2Erackspace=2Ecom> >>>>> Content-Type: text/plain;charset=3DUTF-8 >>>>> >>>>> Sorry for front posting=2E The L2 and L3 >>>>> are following the "end to end argument"=2E The function of the L2 ne= twork >>>>> is >>>>> to not queue more than absolutely necessary=2E >>>>> The function at L3 is to respond to congestion signals by reducing i= nput >>>>> to >>>>> a fair share of available capacity, quickly, cooperating with other = L3 >>>>> protocols=2E >>>>> >>>>> This is understood by clueful L2 and L3 folks=2E >>>>> >>>>> Clueless vendors dominate the L2 vendor space=2E Sadly=2E They refus= e to >>>>> stop >>>>> over buffering=2E >>>>> >>>>> >>>>> Date: Fri, 23 Dec 2022 16:02:03 +0100 >>>>> : David Fern=C3=A1ndez >>>>> To: starlink@lists=2Ebufferbloat=2Enet >>>>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast >>>>> >>>>> Hi, >>>>> >>>>> Sorry, maybe I did not craft the subject correctly=2E I am receiving= the >>>>> daily digest of the list, not individual messages=2E >>>>> >>>>> I have seen before that the L2 engineers (Wi-Fi, DVB=2E=2E=2E) and t= he >>>>> Internet engineers (L3) are trying to solve the same issue (QoS, >>>>> congestion control) without being aware of what each other are doing >>>>> and not even getting coordinated=2E I am afraid that nowadays we hav= e >>>>> even the application layer engineers doing their own stuff (DASH, >>>>> CDNs=2E=2E=2E)=2E >>>>> >>>>> Some time ago, I worked in a project about cross-layer optimization >>>>> techniques for SATCOM systems, where one of the issues was to try to >>>>> optimize transport layer performance with L2 info=2E I was just a me= re >>>>> observer of what academy people in the consortium where proposing=2E >>>>> >>>>> That was quite long ago: >>>>> https://artes=2Eesa=2Eint/projects/ipfriendly-crosslayer-optimizatio= n-adaptive-satellite-systems >>>>> >>>>> Today I came across this: >>>>> https://www=2Eelektormagazine=2Ecom/news/white-paper-why-wi-fi-6-goe= s-hand-in-hand-with-cellular-to-enable-the-hyper-connected-enterprise-futur= e >>>>> >>>>> "the performance uplift of Wi-Fi 6 over Wi-Fi 5 is substantial and >>>>> more than sufficient to support innovative use cases such as automat= ed >>>>> guided vehicles, industrial robots and many other applications=2E" >>>>> >>>>> This sound like Wi-Fi 6 will support low latency and will have a goo= d >>>>> QoS support=2E Maybe=2E=2E=2E >>>>> >>>>> Regards, >>>>> >>>>> David >>>>> >>>>> 2022-12-21 8:54 GMT+01:00, Sebastian Moeller : >>>>>> Hi, >>>>>> >>>>>> See [SM] below=2E >>>>>> >>>>>> On 21 December 2022 08:37:27 CET, "David Fern=C3=A1ndez via Starlin= k" >>>>>> wrote: >>>>>>> What about this? >>>>>>> https://www=2Ewi-fi=2Eorg/discover-wi-fi/wi-fi-certified-wmm-progr= ams >>>>>>> >>>>>>> Isn't this Wi-Fi MM (Multimedia) supposed to solve Wi-Fi QoS issue= s? >>>>>> >>>>>> [SM] In home network reality it failed to do so=2E I would = guess >>>>>> partly because the admission control component is optional and as f= ar >>>>>> as I >>>>>> can tell not available in the usual WiFi routers and APs=2E A free = for >>>>>> all >>>>>> priority system that in addition diminishes the total achievable >>>>>> throughput >>>>>> when the higher priority tiers are used introduces at least as much >>>>>> QoS >>>>>> issues a it solves IMHO=2E This might be different for 'enterprise = WiFi >>>>>> gear' >>>>>> but I have no experience with that=2E=2E=2E >>>>>> >>>>>> Regard >>>>>> Sebastian >>>>>> >>>>>> P=2ES=2E: This feels like you might responded to a different thread= than >>>>>> the >>>>>> iperf2 one we are in right now? >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>>> Date: Thu, 08 Dec 2022 11:04:13 -0800 >>>>>>>> From: rjmcmahon >>>>>>>> To: Sebastian Moeller >>>>>>>> Cc: rjmcmahon via Make-wifi-fast >>>>>>>> , Dave T=C3=A4ht >>>>>>>> , Rpm , libreqos >>>>>>>> =09 >>>>> , Dave Taht via Starlink >>>>>>>> , bloat >>>>>>>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fas= t >>>>>>>> 2016 & crusader >>>>>>>> Message-ID: >>>>>>>> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed >>>>>>>> >>>>>>>> Thanks for the well-written response Sebastian=2E I need to think= more >>>>>>>> about the load vs no load OWD differentials and maybe offer that = as >>>>>>>> an >>>>>>>> integrated test=2E Thanks for bringing it up (again=2E) I do thin= k a >>>>>>>> low-duty cycle bounceback test to the AP could be interesting too= =2E >>>>>>>> >>>>>>>> I don't know of any projects working on iperf 2 & containers but = it >>>>>>>> has >>>>>>>> been suggested as useful=2E >>>>>>>> >>>>>>>> Bob >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> Starlink mailing list >>>>>>> Starlink@lists=2Ebufferbloat=2Enet >>>>>>> https://lists=2Ebufferbloat=2Enet/listinfo/starlink >>>>>> >>>>>> -- >>>>>> Sent from my Android device with K-9 Mail=2E Please excuse my brevi= ty=2E >>>>>> >>>>> >>>> _______________________________________________ >>>> Starlink mailing list >>>> Starlink@lists=2Ebufferbloat=2Enet >>>> https://lists=2Ebufferbloat=2Enet/listinfo/starlink >>> >>> >>> -- >>> Ben Greear >>> Candela Technologies Inc http://www=2Ecandelatech=2Ecom >>> >>> _______________________________________________ >>> Starlink mailing list >>> Starlink@lists=2Ebufferbloat=2Enet >>> https://lists=2Ebufferbloat=2Enet/listinfo/starlink >> >> >_______________________________________________ >Starlink mailing list >Starlink@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/starlink --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E