Re: HT action frame code

[Johannes Berg <johannes@sipsolutions.net>]

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

On Tue, 2008-09-09 at 11:14 +0300, Tomas Winkler wrote:

> >> The current design assumes that hostapd takes care of all management
> >> frames, so eyes, these would need to go to hostapd for processing and
> >> then setup back to mac80211 through some new command..
> >
> > Well we can always pick out those action frames in the kernel if we want
> > to, that's not the problem, is it?
> 
> We've indeed has kept inside just BA session action frames.

Hmm? I don't think I understand what you're trying to say.

> > Should the design be changed? It seems that this is more related to the
> > rate scale algorithm and the "can we support aggregation for this STA"
> > question, both of which we currently have information about in the
> > kernel and not hostapd.
> 
> The decision might come both from RS and hostapd. RS just have more
> info whether there will be gain from aggregation. When throughput is
> not high enough it's just an overhead. Though some APs open session
> immediately uppon association without and RS decision.
> Our design is that BA can be triggered not only for RS.

Well yeah, but I'm not sure we really want to add API to cfg80211 for
this. It's not exactly hard to, but right now I don't see how hostapd
would influence the decision.

Also, I'm not talking about the AP triggering the aggregation session,
this is entirely done with the rate scaling right now, but about an
associated STA wanting to start an aggregation session. Aren't
aggregation sessions always triggered by whoever wants to send? So if a
STA notices it has lots of upload going on it could want to trigger a BA
session, which is something we don't currently support afaict.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]