From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (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 BB61E3B2A4 for ; Mon, 2 Jan 2023 14:00:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1672686004; bh=ljwNNKWXKmBlIzy66T3yccTf1Y/Ctf+jbGdwIF51zzI=; h=X-UI-Sender-Class:Subject:From:In-Reply-To:Date:Cc:References:To; b=mrkxALvMKXyXrLIBUY1rGc3OmJeKpT5X7SZ915+1tOklzeFJPacJbNquodsnyIAzY Vd5vleKQQiyKlcJNrDchZCDxDnZPmyfw3P6HgrlXWMTmSFDV4uJeQMV+opclefsIgJ 1iCCOLCGHYfKa6yN57787LaFcldlurmMuYJ7hxOTOQPnbwHg/i9ZBZFgXEL+molOMF gTP9Li7VOxTdwicAve/hQYmn2ZP6LwJ5ecXNSejvc/LRvrbbTcikSuJyAKH82iRouy JNKhcEb0wdVcpRVthhB+aKICEXGxu71HHorTb7N4mPxVkAJnqQj3Ugp2o6S8Y1y9LC 95S1+qqF2h7CQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from smtpclient.apple ([77.8.117.177]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MmlXA-1oV53y0fjS-00jtX4; Mon, 02 Jan 2023 20:00:04 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 2 Jan 2023 20:00:03 +0100 Cc: =?utf-8?Q?David_Fern=C3=A1ndez?= , starlink@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ben Greear X-Mailer: Apple Mail (2.3696.120.41.1.1) X-Provags-ID: V03:K1:t7H4DYPyM695vrZXxP6oQ30XAYys8lYU/3D6EAwKUig4VQP63zo q9qxE4tXcU9TKibuat2vrSfx/bz4JLZKXSiwwGlS83riYZ+X6qe0Vee6c6yyy+l7dnasv4C d8VZxD8Ylv6ruaxsflk4k6MlUJHXRUmf5pK95VxdWjdv5sqaEpgMTzKd704LR8aXZLREI8m cbrYMCGeTt2l4QWjhFsBQ== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:P2ENO+mn/HM=;92m90jpO1gasXTJ3xQpp2mRWG7c Cc6CF90aAPJQyDW51MvwspbkaFW0c5fOqo06Rn4SA3avgLGtR0n0xNKr2noaWWpOPrRCUTubg 8UOrUpLUN7DIvSgNC89hRL1PbPSIvuW3zjsd2HyX4ppoYF4RmHJU5hNcKcxth5Whf7UhPD+p2 khsPT00le0mQzK4Iijk2hwuUiyZocmoeFQKOm6fr8XM7HEsEW07Q11NJb3S2EyF/d3+IZWTcX zD90LmB+m8f1EwLdeOXxqIcRg6rQAH0QwdNWqcPxxa5qvFZWk38W1/7QJN876GnMNXejJxmUN 2SMr1HPtfibF/UwXr6ZU8fCMUJI6Z5q06cNu7aWsmc/q0yX63iHDmc8JBHSmSXD55JuUCwehT 74tnjIGfFhq39nVGahRm0997oPEX5t4s86Z36/1tvwUZwxvo/pG6FWltMaUzI1/f5TzyyteVL Y3LWXnQUdnBT+DO6GErhndh93lI/nKPHo41OGSul5ijD0IzoNDcknZIVbrwoBmSGfXNhH3lyW O0zjSZtakH1zpFY41ob4KojmRTGze0am+rESj3KKwN2IH80PoiEkCC/zIQsKQOyQdaMnOww3T VJ7fufCN5XikKoHJ3FKLbg7unHYrUYSd33XX6rOJRh70aWbSx/o+WJinJ75tCOiK9gix7BjzQ guuiZzMJYAj1iwQ/ugEoaKyoUWEnrpSOc1pTDLOL/Wfn9EbW8lSJMAkTjIAIooBSFax/MpLEm EmGNZLS/NnVvjhJaLhLlC2goeQiJqJy0jX1Ci2k+8BgDEbpyBrXnLAcD3mP+Z67uzjg16F9di GNa8fnFqKmDTbcJ1QhUpGymRiQESsM15d5qxWPjR6huIgOxgcRVDcSLy7H4jEJ2hXo54ARnuO vSRF3tXDEKcz54bnbol7iDTkZpzTbO4B4xNTigK7ulbh91QdLzFOZlv4Fe7wbq5HU9InoPhMu 0kJFKOTyR1SXwfHn2EQPVi/QHZE= 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: Mon, 02 Jan 2023 19:00:14 -0000 > On Jan 2, 2023, at 19:44, Ben Greear via Starlink = wrote: >=20 > On 1/2/23 9:35 AM, David Fern=C3=A1ndez via Starlink wrote: >> Just wondering how comes that buffering is not standardized. = Wondering >> why buffer sizes are left to implementation decisions of possibly >> clueless vendors, which devices can worsen the performance of the >> network. >=20 > There is no perfect answer, and every configuration has some = trade-off. >=20 > It is a long grind of tricky code and careful and widely varied = testing > to make progress in this area. Also the (maximum) buffer size becomes far less relevant if the buffer = is properly managed... Over-sized and under-managed, that is the problematic combination. 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 = numbers. So manufacturers increasing throughput by enlarging buffers is at least = understandable in our market economy. 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. Regards Sebastian >=20 > Thanks, > Ben >=20 >>> 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 >>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast >>> Message-ID: <1671840056.20758968@mobile.rackspace.com> >>> Content-Type: text/plain;charset=3DUTF-8 >>>=20 >>> Sorry for front posting. The L2 and L3 >>> 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 share of available capacity, quickly, cooperating with other = L3 >>> protocols. >>>=20 >>> This is understood by clueful L2 and L3 folks. >>>=20 >>> Clueless vendors dominate the L2 vendor space. Sadly. They refuse to = stop >>> over buffering. >>>=20 >>>=20 >>> Date: Fri, 23 Dec 2022 16:02:03 +0100 >>> : David Fern=C3=A1ndez >>> To: starlink@lists.bufferbloat.net >>> Subject: Re: [Starlink] [Rpm] Fwd: [Make-wifi-fast] make-wifi-fast >>>=20 >>> Hi, >>>=20 >>> Sorry, maybe I did not craft the subject correctly. I am receiving = the >>> daily digest of the list, not individual messages. >>>=20 >>> 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...). >>>=20 >>> 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. >>>=20 >>> That was quite long ago: >>> = https://artes.esa.int/projects/ipfriendly-crosslayer-optimization-adaptive= -satellite-systems >>>=20 >>> Today I came across this: >>> = https://www.elektormagazine.com/news/white-paper-why-wi-fi-6-goes-hand-in-= hand-with-cellular-to-enable-the-hyper-connected-enterprise-future >>>=20 >>> "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." >>>=20 >>> This sound like Wi-Fi 6 will support low latency and will have a = good >>> QoS support. Maybe... >>>=20 >>> Regards, >>>=20 >>> David >>>=20 >>> 2022-12-21 8:54 GMT+01:00, Sebastian Moeller : >>>> Hi, >>>>=20 >>>> See [SM] below. >>>>=20 >>>> 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 >>>>>=20 >>>>> Isn't this Wi-Fi MM (Multimedia) supposed to solve Wi-Fi QoS = issues? >>>>=20 >>>> [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 >>>> throughput >>>> 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 >>>> gear' >>>> but I have no experience with that... >>>>=20 >>>> Regard >>>> Sebastian >>>>=20 >>>> P.S.: This feels like you might responded to a different thread = than the >>>> iperf2 one we are in right now? >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>>> 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-fast >>>>>> 2016 & crusader >>>>>> Message-ID: >>>>>> Content-Type: text/plain; charset=3DUTF-8; format=3Dflowed >>>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> I don't know of any projects working on iperf 2 & containers but = it has >>>>>> been suggested as useful. >>>>>>=20 >>>>>> Bob >>>>>>=20 >>>>> _______________________________________________ >>>>> Starlink mailing list >>>>> Starlink@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/starlink >>>>=20 >>>> -- >>>> Sent from my Android device with K-9 Mail. Please excuse my = brevity. >>>>=20 >>>=20 >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >=20 >=20 > --=20 > Ben Greear > Candela Technologies Inc http://www.candelatech.com >=20 > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink