From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; spf=pass smtp.mailfrom=lang.hm; dkim=fail; arc=none (Message is not ARC signed); dmarc=none Received: from mail.lang.hm (wsip-70-167-213-146.ph.ph.cox.net [70.167.213.146]) by mail.toke.dk (Postfix) with ESMTPS id 388C811D09A3; Sun, 07 Jun 2026 12:19:36 +0200 (CEST) Received: from [10.2.3.133] (unknown [10.2.3.133]) by mail.lang.hm (Postfix) with ESMTP id 1DC942277F5; Sun, 7 Jun 2026 03:19:35 -0700 (PDT) Date: Sun, 7 Jun 2026 03:19:30 -0700 (MST) From: David Lang To: Sebastian Moeller cc: Frantisek Borsik , codel@lists.bufferbloat.net, bob.mcmahon@umbernetworks.com, dan , Cake List , Make-Wifi-fast , bloat In-Reply-To: <52CE3DA7-EC5A-4FF8-A88E-26A7A6661983@gmx.de> Message-ID: <8qr7qons-5sp9-o30o-49qr-02p67prss6rr@ynat.uz> References: <8e14c6935753c6263351ad00ec59b9cb@umbernetworks.com> <055e42685cddfa4c1a4ff4da089996eb@umbernetworks.com> <7455E3B4-7FB4-4D40-A900-B31151D12F6F@gmx.de> <52CE3DA7-EC5A-4FF8-A88E-26A7A6661983@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID-Hash: R2ILMNHJB5XZ5WKYK4TERYYHGQLO3DCN X-Message-ID-Hash: R2ILMNHJB5XZ5WKYK4TERYYHGQLO3DCN X-MailFrom: david@lang.hm X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Make-wifi-fast] Re: [Bloat] Re: [Codel] [Rpm] Re: Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon List-Id: Lets make wifi fast again! Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: Sebastian Moeller via Bloat wrote: > the point is current WiFi sucks under staturating loads, period. This is correct and I doubt that it can be fixed. Wifi was designed for a different era. I remember renting a pcmcia card for a conference with a $800 deposit because that was the purchase price for the card. Wifi was expected to be something rare and the protocol reflects that. In an environment where there are only a few statinos, the retry and then retry at a slower data rate do work, and the slower data rate is more likely to be deciphered if the problem is a weak signal or high noise level but today you only see such environments in a lab, on a farm, or possibly a large estate. In the more common conditions today where airtime is the limiting factor and hidden transmitters (where the receiving station can hear two stations that can't hear each other) are the rule rather than the exception, having to retransmit everything when you are stepped on because the receiving station can't validate anything it heard if it doesn't hear the complete transmission wastes airtime, and transmitting at a lower data rate will make it more likely that you get stepped on, not more likely that you will get your message through this leads to performance falling off a cliff when the available airtime fills up rather than graceful degredation If the next wifi standard could have checksums at various places during the broadcast, it would be possible for part of the data to get through, and get acked and normal tcp retries to get the rest transmitted later. Combine this with NOT slowing down when you have trouble getting through would help greatly reduce this cliff (as long as your signal strength is high enough, acks from the AP would have to report how they hear you) but without coordination between the stations that can't hear each other, you can't fix the hidden transmitter problem. you can somewhat mitigate it if you have lots of APs and you set the APs to only pay attemtion to signals that are pretty strong. If you tune this just exactly right you can make it so the stations at opposite sides of you can hear each other to avoid collisions. This tuning would be very difficult to get right. the only theoretical answer to the problem is to have the AP manage transmission slots, but that doesn't work very well in practice (the management eats so much airtime that the 'dumber' design wins with higher throughput, up until total collapse. getting cake to be able to adjust to changing bandwidth would help avoid driving the network to saturation, but being able to deploy more APs to use more channels at lower power is adding additional airtime, pushing the limit futher out. It's not the best solution, it just works in practice (most of the time) David Lang