From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp67.iad3a.emailsrvr.com (smtp67.iad3a.emailsrvr.com [173.203.187.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C1AE83CB37 for ; Fri, 23 Dec 2022 19:00:56 -0500 (EST) Received: from app14.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp1.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 49BB51732; Fri, 23 Dec 2022 19:00:56 -0500 (EST) Received: from deepplum.com (localhost.localdomain [127.0.0.1]) by app14.wa-webapps.iad3a (Postfix) with ESMTP id 33E4F600BA; Fri, 23 Dec 2022 19:00:56 -0500 (EST) Received: by mobile.rackspace.com (Authenticated sender: dpreed@deepplum.com, from: dpreed@deepplum.com) with HTTP; Fri, 23 Dec 2022 19:00:56 -0500 (EST) Date: Fri, 23 Dec 2022 19:00:56 -0500 (EST) From: "David P. Reed" To: starlink-request@lists.bufferbloat.net Cc: starlink@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID: <1671840056.20758968@mobile.rackspace.com> X-Mailer: mobile/8.0.1 X-Classification-ID: ac39919d-8126-469f-8433-5a414c779621-1-1 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: Sat, 24 Dec 2022 00:00:56 -0000 Sorry for front posting. The L2 and L3=20 are following the "end to end argument". The function of the L2 network is = to not queue more than absolutely necessary. The function at L3 is to respond to congestion signals by reducing input to= a fair shareof available capacity, quickly, cooperating with other L3 prot= ocols. This is understood by clueful L2 and L3 folks. Clueless vendors dominate the L2 vendor space. Sadly. They refuse to stop o= ver buffering. Date: Fri, 23 Dec 2022 16:02:03 +0100 : David Fern=C3=A1ndez=20 To: starlink@lists.bufferbloat.net Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast Hi, Sorry, maybe I did not craft the subject correctly. I am receiving the daily digest of the list, not individual messages. I have seen before that the L2 engineers (Wi-Fi, DVB...) and the 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. I am afraid that nowadays we have even the application layer engineers doing their own stuff (DASH, CDNs...). 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. I was just a mere observer of what academy people in the consortium where proposing. That was quite long ago: https://artes.esa.int/projects/ipfriendly-crosslayer-optimization-adaptive-= satellite-systems Today I came across this: https://www.elektormagazine.com/news/white-paper-why-wi-fi-6-goes-hand-in-h= and-with-cellular-to-enable-the-hyper-connected-enterprise-future "the performance uplift of Wi-Fi 6 over Wi-Fi 5 is substantial and more than sufficient to support innovative use cases such as automated guided vehicles, industrial robots and many other applications." This sound like Wi-Fi 6 will support low latency and will have a good QoS support. Maybe... Regards, David 2022-12-21 8:54 GMT+01:00, Sebastian Moeller : > Hi, > > See [SM] below. > > On 21 December 2022 08:37:27 CET, "David Fern=C3=A1ndez via Starlink" > wrote: >>What about this? >>https://www.wi-fi.org/discover-wi-fi/wi-fi-certified-wmm-programs >> >>Isn't this Wi-Fi MM (Multimedia) supposed to solve Wi-Fi QoS issues? > > [SM] In home network reality it failed to do so. I would guess > partly because the admission control component is optional and as far as = I > can tell not available in the usual WiFi routers and APs. A free for all > priority system that in addition diminishes the total achievable throughp= ut > when the higher priority tiers are used introduces at least as much QoS > issues a it solves IMHO. This might be different for 'enterprise WiFi gea= r' > but I have no experience with that... > > Regard > Sebastian > > P.S.: 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=20 >>> To: Sebastian Moeller=20 >>> Cc: rjmcmahon via Make-wifi-fast >>> =09, Dave T=C3=A4ht >>> =09, Rpm , libreqos >>> =09 , Dave Taht via Starlink >>> =09, bloat=20 >>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast >>> =092016 &=09crusader >>> Message-ID:=20 >>> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed >>> >>> Thanks for the well-written response Sebastian. I need to think more >>> about the load vs no load OWD differentials and maybe offer that as an >>> integrated test. Thanks for bringing it up (again.) I do think a >>> low-duty cycle bounceback test to the AP could be interesting too. >>> >>> I don't know of any projects working on iperf 2 & containers but it has >>> been suggested as useful. >>> >>> Bob >>> >>_______________________________________________ >>Starlink mailing list >>Starlink@lists.bufferbloat.net >>https://lists.bufferbloat.net/listinfo/starlink > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > ------------------------------ Subject: Digest Footer _______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink ------------------------------ End of Starlink Digest, Vol 21, Issue 14 ****************************************