Return-path: Received: from mail-qc0-f175.google.com ([209.85.216.175]:65358 "EHLO mail-qc0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754773AbbBBEWR (ORCPT ); Sun, 1 Feb 2015 23:22:17 -0500 Received: by mail-qc0-f175.google.com with SMTP id c9so28543698qcz.6 for ; Sun, 01 Feb 2015 20:22:16 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1422801814.796219699@apps.rackspace.com> References: <1422537297.21689.15.camel@edumazet-glaptop2.roam.corp.google.com> <54CB5D08.2070906@broadcom.com> <1422623975.21689.77.camel@edumazet-glaptop2.roam.corp.google.com> <54CB8B69.1070807@broadcom.com> <1422741065.199624134@apps.rackspace.com> <1422801814.796219699@apps.rackspace.com> From: Avery Pennarun Date: Sun, 1 Feb 2015 23:21:56 -0500 Message-ID: (sfid-20150202_052224_962212_A4FFDDD1) Subject: Re: [Cerowrt-devel] Fwd: Throughput regression with `tcp: refine TSO autosizing` To: David Reed Cc: Jonathan Morton , Dave Taht , Matt Mathis , Tim Shepard , dstanley@arubanetworks.com, Kathy Giori , Stig Thormodsrud , Derrick Pallas , "cerowrt-devel@lists.bufferbloat.net" , Mahesh Paolini-Subramanya , Jim Gettys , Andrew McGregor , Jesper Dangaard Brouer , linux-wireless , netdev@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Sun, Feb 1, 2015 at 9:43 AM, wrote: > Just to clarify, managing queueing in a single access point WiFi network is > only a small part of the problem of fixing the rapidly degrading performance > of WiFi based systems. Can you explain what you mean by "rapidly degrading?" The performance in odd situations is certainly not inspirational, but I haven't noticed it getting worse over time. > Similarly, mesh routing is only a small part of the > problem with the scalability of cooperative meshes based on the WiFi MAC. That's certainly true. Not to say the mesh routing algorithms are much good either. > Also, as we noted > earlier, "handoff" from one next hop to another is a huge problem with > performance in practical deployments (a factor of 10x at least, just in > that). While there is definitely some work to be done in handoff, it seems like there are some find implementations of this already in existence. Several brands of "enterprise access point" setups seem to do well at this. It would be nice if they interoperated, I guess. The fact that there's no open source version of this kind of handoff feature bugs me, but we are working on it here and the work is all planned to be open source, for example: (very early version) https://gfiber.googlesource.com/vendor/google/platform/+/master/waveguide/ > Propagation information is not used at all when 802.11 systems share a > channel, even in single AP deployments, yet all stations can measure > propagation quite accurately in their hardware. 802.11k seems to provide for sharing this information. But I'm not clear what I should use it for. :) > Finally, Listen-before-talk is highly wasteful for two reasons: 1) any > random radio noise from other sources unnecessarily degrades communications [...] > 2) the transmitter cannot tell when the intended receiver will be perfectly > able to decode the signal without interference with the station it hears > (this second point is actually proven in theory in a paper by Jon Peha that > argued against trivial "etiquettes" as a mechanism for sharing among > uncooperative and non-interoperable stations). I've thought quite a bit about your point #2 above, but I don't know which direction to pursue. The idea is that sometimes "just shout over the background noise" is a globally optimal solution, right? The question seems to be to figure out when that is true and when it isn't. > I agree that, to the extent that managing queues in a single box or a single > operating system doesn't require cooperation, it's much easier to get such > things into the market. That's why CeroWRT has been as effective as it has > been. But has Microsoft done anything at all about it? Do the better ECN > signals that can arise from good queue management get used by the TCP > endpoints, or for that matter UDP-based protocol endpoints? If we don't know the answer to the questions, then that is itself the problem. It's a lot easier to say, hey, ChromeOS and MacOS have good network performance but Microsoft has bad network performance, if it's true and we have good reproducible tests to demonstrate that. > The reason no one is making progress on any of these particular issues is > that there is no coordination at the "systems level" around creating rising > tides that lift all boats in the WiFi-ish space. It's all about ripping the > competition by creating stuff that can sell better than the other guys' > stuff, and avoiding cooperation at all costs. > [...] > But the big wins in making WiFi better are going begging. As WiFi becomes > more closed, as it will as the major Internet Access Providers and Gadget > builders (Google, Apple) start excluding innovators in wireless from the > market by closed, proprietary solutions, the problem WILL get worse. You > won't be able to fix those problems at all. If you have a solution you will > have to convince the oligopoly to even bother trying it. As someone who works at Google Fiber (which is both a gadget maker and an ISP) and who pushes all day long for our wifi stuff to be open source, I'm slightly offended to be lumped in with other vendors in your story :) I think the ChromeOS team (which insists on only open source wifi drivers in all chromebooks) would feel similarly. We are lucky to have defined our competitive advantage as something other than short-lived slight improvements in wifi that will soon be wastefully duplicated by everyone else. That said, I see what you mean about the general state of the industry. The way to fix it is the way Linux always fixes it: make the open source version so much better that building a proprietary one, just to gather a small incremental advantage, is a huge waste of time and effort. Work on minstrel and fq_codel go really far here. > I personally think that things like promoting semi-closed, essentially > proprietary ESSID-based bridged distribution systems as "good ideas" are > counterproductive to this goal. But that's perhaps too radical for this > crowd. Not sure what you mean here. ESSID-based distribution systems seem pretty well defined to me. The only proprietary part is the decision-making process for assisted roaming (ie. the "inter-AP protocol") which is only an optional performance optimization. There really should be an open source version of this, and I'm in fact feebly attempting to build one, but I don't feel like the world is falling apart through not having it. You can build a bridged multi-BSS ESSID today with plain out-of-the-box hostapd. Have fun, Avery