Re: Roaming / offchannel enhancements for broadcast / multicast frames

[Johannes Berg <johannes@sipsolutions.net>]

On Fri, 2010-10-08 at 17:08 -0700, Paul Stewart wrote:

> > 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.

I'd tend to agree -- what point is there in receiving data when you
can't even ACK it any more.. you'll just hurt everybody else by using
huge amounts of airtime, and if the situation persists hopefully the AP
will kick you off quickly anyway.

> > 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.  There's an additional issue about what happens
> when we are in the middle of a bgscan and new tx traffic appears.

I really don't want to add API for "force" to userspace -- it's entirely
pointless. If userspace wants their scan, so they'll always have to set
the force flag anyway. Postponing it for a bit seems much saner. I think
you're trying to solve a problem with say an existing NM that tries to
scan every two minutes -- but that problem need not be solved at this
layer.

> > 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.

Skew between APs is minimal -- the clocks are required to be accurate to
5ppm IIRC.

And in any case, there's no way to achieve perfect multicast reliability
_anyway_, so I don't see why you're even trying? Can somebody actually
come up with a problem statement? All I've seen so far is DHCP, but for
just that, what's wrong with doing what you already do now?

johannes