From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9597A3B2A4 for ; Mon, 2 Jan 2023 13:44:21 -0500 (EST) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.7.67.131]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 85F7E1C007E; Mon, 2 Jan 2023 18:44:19 +0000 (UTC) Received: from mail3.candelatech.com (mail2.candelatech.com [208.74.158.173]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 468BA980068; Mon, 2 Jan 2023 18:44:19 +0000 (UTC) Received: from [192.168.100.195] (50-251-239-81-static.hfc.comcastbusiness.net [50.251.239.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail3.candelatech.com (Postfix) with ESMTPSA id AE6E313C2B0; Mon, 2 Jan 2023 10:44:18 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.candelatech.com AE6E313C2B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=candelatech.com; s=default; t=1672685058; bh=DYR7Izbm5+fzXzFiVA4NOkpvRhKYRCK6RXXKqHsVbdo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=AmIiqnWv6ss/Tm95KVkG5zAqWnv2WdtK2o2I3u/UQn6JSgtjAYpC/+vJbtBQ9HdQF SUN0q21Znh7bbWZ9GmcUYg8kztGFYUa5V1a4nO8ZLOTFlLLjFYRMMUk9FdTMGli/4N HGogY7JflT+GtksUy4e3ZNdjBmqx9o7+0yWHk/4M= To: =?UTF-8?Q?David_Fern=c3=a1ndez?= , starlink@lists.bufferbloat.net References: From: Ben Greear Organization: Candela Technologies Message-ID: Date: Mon, 2 Jan 2023 10:44:18 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MDID: 1672685060-r8Ch2dcCox1T X-MDID-O: us5-ut7-1672685060-r8Ch2dcCox1T 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 18:44:21 -0000 On 1/2/23 9:35 AM, David Fernández 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. There is no perfect answer, and every configuration has some trade-off. It is a long grind of tricky code and careful and widely varied testing to make progress in this area. Thanks, Ben > >> 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=UTF-8 >> >> 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. >> >> This is understood by clueful L2 and L3 folks. >> >> Clueless vendors dominate the L2 vendor space. Sadly. They refuse to stop >> over buffering. >> >> >> Date: Fri, 23 Dec 2022 16:02:03 +0100 >> : David Fernández >> 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-hand-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ández 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 >>> 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... >>> >>> 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 >>>>> To: Sebastian Moeller >>>>> Cc: rjmcmahon via Make-wifi-fast >>>>> , Dave Täht >>>>> , Rpm , libreqos >>>>> >> , 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=UTF-8; format=flowed >>>>> >>>>> 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. >>> >> > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > -- Ben Greear Candela Technologies Inc http://www.candelatech.com