From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 2346321F5AE for ; Fri, 22 Aug 2014 16:52:57 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id s7MNqthv025533; Fri, 22 Aug 2014 16:52:55 -0700 Date: Fri, 22 Aug 2014 16:52:55 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: "Steinar H. Gunderson" In-Reply-To: <20140822234158.GB1272@sesse.net> Message-ID: References: <91696A3A-EF44-4A1A-8070-D3AF25D0D9AC@netapp.com> <20140821085803.GA21250@sesse.net> <20140822234158.GB1272@sesse.net> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="680960-372038471-1408751575=:19968" Cc: bloat@lists.bufferbloat.net Subject: Re: [Bloat] sigcomm wifi X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 23:52:57 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --680960-372038471-1408751575=:19968 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Sat, 23 Aug 2014, Steinar H. Gunderson wrote: > On Fri, Aug 22, 2014 at 04:34:09PM -0700, David Lang wrote: >>> Note that there's a lot more to this kind of solution than “not badly >>> overbuffered”. In particular, you have automated systems for channel >>> assignment, for biasing people onto 5 GHz (which has 10x the number of >>> nonoverlapping channels) and for forcing people to be load-balanced between >>> the different APs. All of this helps in high-density. >> is there actually anything for this in the 802.11 protocol? or is >> this just the controller noticing that this MAC address has shown up >> on 5GHz in the past so it opts to not respond to requests to >> associate with a 2.4GHz AP? > > The latter. > >> Social Enginnering works well for this without a need to technical >> tricks (Scale-slow on 2.4, Scale on 5) > > Having two separate ESSIDs is a pain, though; it means that when you go into > the outskirts of your coverage zones, you need to manually switch to 2.4. that depends on how many APs you put in place. you really should be trying to cover the area with 5GHz, and since you have so many more channels available, you can afford to use more power on 5GHs and give each AP a bigger footprint. >> Yep, if the rate of control traffic could be set to be faster it >> would help a lot. When you transmit slower, it greatly magnifies the >> chances of something else coming up on the air and clobbering you so >> your lengthy broadcast is worthless. >> >> But I thought that Dave Taht had been experimenting with this in >> cerowrt and found it didn't actually work well in the real world. > > I've tested this in the real world. It works really well. (It's also pretty > much standard practice in high-density Wi-Fi, from what I've been told.) Ok, then I'm back to "how can I do this on OpenWRT"? :-) David Lang --680960-372038471-1408751575=:19968--