Return-path: Received: from mail-iw0-f174.google.com ([209.85.214.174]:58106 "EHLO mail-iw0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752368Ab0JIAnd convert rfc822-to-8bit (ORCPT ); Fri, 8 Oct 2010 20:43:33 -0400 MIME-Version: 1.0 In-Reply-To: References: From: "Luis R. Rodriguez" Date: Fri, 8 Oct 2010 17:43:12 -0700 Message-ID: Subject: Re: Roaming / offchannel enhancements for broadcast / multicast frames To: Paul Stewart Cc: linux-wireless , linux-kernel@vger.kernel.org, Matt Smith , Srinivasa Duvvuri , Carolyn Waller , Amod Bodas , David Quan , Bennyam Malavazi , Cliff Holden , Aeolus Yang , Kevin Hayes Content-Type: text/plain; charset=UTF-8 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Fri, Oct 8, 2010 at 5:08 PM, Paul Stewart wrote: > On Fri, Oct 8, 2010 at 12:54 PM, Luis R. Rodriguez wrote: >> We spoke about how to handle broadcast / multicast frames when going >> offchannel at the Wireless Summit [1]. A lot of these talks were lead >> due to a Chrome side open bug [2]. > > Thanks for getting the ball rolling, Luis.  Technically the bug is in > ChromumOS ("Chrome" is a web browser). Heh, yeah sorry. >> Userspace may want to force a roam when this deadzone event hits. > > Why not just disassociate at this point?  I'm not sure what the > difference is between a "dead zone" situation and a reason to > completely disconnect. Not sure what is best, but one reason for considering to just roam is we are at least getting data while we roam. I hope we can iron out the best algorithm through this thread. >> Once we have these two in place we can then ignore bgscan requests >> (when associated) unless a force scan command has been issued by >> userspace, or unless we are idle. > > By "ignore" do you mean "postpone" or or "return an appropriate error > to userspace"?  Either of those are acceptable.  Not doing anything at > all wouldn't be good. Good questions. If we postpone it means we end up queuing up all these scan requests, unless we only let a few queue up, or just one? > There's an additional issue about what happens > when we are in the middle of a bgscan and new tx traffic appears. We can force going back on channel in this case I think. >> In the worst case scenario and unfortunately this seems to be the most >> common one, a DTIM of 1 is used and we will have to be on channel and >> awake every beacon interval. In this case we may want to optimize scan >> time by not scanning passive scan channels. > > A compromise would be to go off-channel for less than a full beacon > interval when doing background passive channel scans in DTIM=1 > networks.  It's certainly better than (a) not scanning at all and (b) > arguably better than intentionally dropping mcast.  An 80% beacon-time > passive listen will get you 80% of the beacons, assuming linear > probability, and even more over time if you account for beacon skew > between networks. Sure it just also means our bgscans can take up ages, if they take up ages and we queue up a few of them then we can get a backlog of requests from userspace agents. I suppose we need to figure out this fine line. But yeah -- you're right, we can do scanning for less than a beacon interval if DTIM is 1. This can mean 1024 TUs, not sure how long it takes for us to do a passive scan, this likely is radio/chipset specific so we'd have to add those values maybe to the wiphy characteristics. Worth trying and seeing if its possible. Luis