Re: [PATCH] nl80211: allow ad-hoc to set WMM parameters from outside

[Simon Wunderlich <simon.wunderlich@s2003.tu-chemnitz.de>]

[-- Attachment #1: Type: text/plain, Size: 3979 bytes --]

On Fri, Dec 28, 2012 at 04:05:02PM +0100, Johannes Berg wrote:
> On Fri, 2012-11-30 at 14:43 +0100, Simon Wunderlich wrote:
> > On Wed, Nov 28, 2012 at 03:01:35PM +0100, Johannes Berg wrote:
> > > On Tue, 2012-11-27 at 19:50 +0100, Simon Wunderlich wrote:
> > > > It can be useful to set own WMM parameters from outside, otherwise there
> > > > is no way to change this in Ad-Hoc networks.
> > > 
> > > Having proper WMM support for IBSS doesn't seem this simple.
> > > 
> > > What about IBSS merging? What about adding WMM IEs? etc.
> > 
> > I couldn't find anything on this in the IEEE standard - it only talks
> > about infrastructure mode, and that EDCA Parameter IEs should be adopted. 
> > (Although I doubt that's a good idea).
> 
> In infrastructure mode the values are adopted, the IEs aren't ever
> transmitted by a client...
> 
> I would argue that in order to join an IBSS you need to execute the
> MLME-JOIN primitive, and that has no EDCA parameter set argument so you
> should take the values from the IBSS.
> 
> Why would that be a bad idea? It seems like a much worse idea to have
> different stations in an IBSS that have different EDCA parameters.
> 

The idea here is to use the standard EDCA parameters (as now), but allow local
changes. When something is adopted, it might override our local changes, and this
is what we don't want. 

In our special case (mesh networks, etc) we have control over our nodes and want
to set values locally - usually the same values on all nodes (different from
standard parameters), but sometimes even different parameters, e.g. to prioritize
nodes over others. The second one is more a wishlist item, however. :)

Granted, this feature will probably not be used even by the IBSS users, but
can be useful to research and special applications and shouldn't hurt to have. :)

> > All we want here is to locally change the parameters. Seems we are not the
> > first ones who want to do that [1]. The WMM specification only says that no
> > WMM IEs is in the beacon and distribution of parameters is missing, and
> > therefore defaults are to be used.
> > 
> > Therefore, I'd like to go for the local changes only and skip WMM IEs, adoption,
> > etc.
> > 
> > You have a point regarding IBSS merging - with this change, we would lose the
> > local configuration with the merge. This could be changed for mac80211,
> > not sure about other drivers (or if anyone actually cares).
> 
> Wait I'm lost -- you say you don't want to adopt the parameters from
> others but then when merging ...??

Right now, when merging __ieee80211_sta_join_ibss() is called which resets the 
parameters back to the EDCA defaults. We would like to keep it our local parameters.

> 
> It seems to me that the WMM IEs also need to be present to even tell the
> peers that you're QoS capable to start with, otherwise they'll never be
> able to use QoS towards you. You're not making all that much sense right
> now, but maybe that's because I haven't looked at the code?

Just checked again ... we already use WMM IEs in IBSS, but currently don't advertise
any EDCA parameters in them (there are appearently different WME subtypes, and only
the WME subtype==1 used by AP includes EDCA parameters). So yes, I was wrong
- we do have WMM IEs in IBSS, we use them to recognize that the peer is QoS capable.

Anyway, how can we move forward? Ways to go I see:

 1.) Use local values, don't advertise the, don't adopt anything. That is basically
     what the current patch does. As I said, we might lose the local changes when
     merging, so this would have to be changed.
 2.) Advertise EDCA parameters in WMM IEs, adopt them, and sync them with the
     other IBSS nodes. 
 3.) Skip the patchset altogether/keep it locally, as WMM parameters should
     not be changed at all (even if technically possible)

Preferences? Anyone else interested in IBSS + WMM?

Cheers,
	Simon

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]