[RFC] mac80211: fix short preamble determination

[RFC] mac80211: fix short preamble determination

[Johannes Berg]

When looking at this code during the rate control API rewrite
yesterday, we wondered whether the determination of short
preamble was correct or not. I don't think it was, and this
should be better.

Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
---
 net/mac80211/tx.c |   13 +++++++++----
 1 file changed, 9 insertions(+), 4 deletions(-)

--- everything.orig/net/mac80211/tx.c	2008-10-11 10:06:51.000000000 +0200
+++ everything/net/mac80211/tx.c	2008-10-11 10:22:53.000000000 +0200
@@ -474,10 +474,15 @@ ieee80211_tx_h_rate_ctrl(struct ieee8021
 		txrc.rts = rts = true;
 	}
 
-	/* XXX: Is this really the right thing to check? */
-	if (ieee80211_is_data(hdr->frame_control) &&
-	    tx->sdata->vif.bss_conf.use_short_preamble &&
-	    (!tx->sta || test_sta_flags(tx->sta, WLAN_STA_SHORT_PREAMBLE)))
+	/*
+	 * Use short preamble if the BSS can handle it, but not for
+	 * management frames unless we know the receiver can handle
+	 * that -- the management frame might be to a station that
+	 * just wants a probe response.
+	 */
+	if (tx->sdata->vif.bss_conf.use_short_preamble &&
+	    (ieee80211_is_data(hdr->frame_control) ||
+	     (tx->sta && test_sta_flags(tx->sta, WLAN_STA_SHORT_PREAMBLE)))
 		txrc.short_preamble = short_preamble = true;
 
 

Re: [RFC] mac80211: fix short preamble determination

[Jouni Malinen]

On Sat, Oct 11, 2008 at 10:26:33AM +0200, Johannes Berg wrote:
> When looking at this code during the rate control API rewrite
> yesterday, we wondered whether the determination of short
> preamble was correct or not. I don't think it was, and this
> should be better.

> -	if (ieee80211_is_data(hdr->frame_control) &&
> -	    tx->sdata->vif.bss_conf.use_short_preamble &&
> -	    (!tx->sta || test_sta_flags(tx->sta, WLAN_STA_SHORT_PREAMBLE)))
> +	if (tx->sdata->vif.bss_conf.use_short_preamble &&
> +	    (ieee80211_is_data(hdr->frame_control) ||
> +	     (tx->sta && test_sta_flags(tx->sta, WLAN_STA_SHORT_PREAMBLE)))

Changing '!tx->sta ||' to 'tx->sta &&' sounds reasonable, but I'm not so
sure about the other change.. In theory, short preamble is negotiated
per STA and while we do current disable short preamble completely in the
BSS if a non-short-preamble-capable STA associates, I'm not sure whether
that would be an absolute requirement. As far as management frames
(e.g., Probe Response) are concerned, IEEE 802.11-2007 18.2.2.2 has an
interesting statement: "all management traffic is returned with the same
type preamble as received". I have not been able to find normative
requirement for that being the case, though.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [RFC] mac80211: fix short preamble determination

[Johannes Berg]

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

On Mon, 2008-10-13 at 18:59 +0300, Jouni Malinen wrote:

> > -	if (ieee80211_is_data(hdr->frame_control) &&
> > -	    tx->sdata->vif.bss_conf.use_short_preamble &&
> > -	    (!tx->sta || test_sta_flags(tx->sta, WLAN_STA_SHORT_PREAMBLE)))
> > +	if (tx->sdata->vif.bss_conf.use_short_preamble &&
> > +	    (ieee80211_is_data(hdr->frame_control) ||
> > +	     (tx->sta && test_sta_flags(tx->sta, WLAN_STA_SHORT_PREAMBLE)))
> 
> Changing '!tx->sta ||' to 'tx->sta &&' sounds reasonable, but I'm not so
> sure about the other change.. In theory, short preamble is negotiated
> per STA and while we do current disable short preamble completely in the
> BSS if a non-short-preamble-capable STA associates, I'm not sure whether
> that would be an absolute requirement.

I don't see how it cannot be -- you need stations not capable of
short-preamble to correctly update their NAV, no?

> As far as management frames
> (e.g., Probe Response) are concerned, IEEE 802.11-2007 18.2.2.2 has an
> interesting statement: "all management traffic is returned with the same
> type preamble as received". I have not been able to find normative
> requirement for that being the case, though.

Yeah, I found that statement too, but no other information on it either,
heh. Not that we can actually support that easily at all. And besides,
it would be kinda weird to send probe _requests_ with short preamble to
start with, since then you wouldn't find APs w/o short preamble...

johannes

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

Re: [RFC] mac80211: fix short preamble determination

[Jouni Malinen]

On Mon, Oct 13, 2008 at 07:31:50PM +0200, Johannes Berg wrote:
> > Changing '!tx->sta ||' to 'tx->sta &&' sounds reasonable, but I'm not so
> > sure about the other change.. In theory, short preamble is negotiated
> > per STA and while we do current disable short preamble completely in the
> > BSS if a non-short-preamble-capable STA associates, I'm not sure whether
> > that would be an absolute requirement.
> 
> I don't see how it cannot be -- you need stations not capable of
> short-preamble to correctly update their NAV, no?

Well, if you have many such devices, yes, but one might try to live
without such protection if there are some with very limited transmit
needs. I don't know whether it would make much sense in most cases and
anyway, it would be possible to make APs reject all associations from
such devices. For example, I could see an attempt to dedicate one
channel for 11g (ERP) and short preamble supported STAs and make the
more modern implementations get somewhat better throughput there.

> > As far as management frames
> > (e.g., Probe Response) are concerned, IEEE 802.11-2007 18.2.2.2 has an
> > interesting statement: "all management traffic is returned with the same
> > type preamble as received". I have not been able to find normative
> > requirement for that being the case, though.
> 
> Yeah, I found that statement too, but no other information on it either,
> heh. Not that we can actually support that easily at all. And besides,
> it would be kinda weird to send probe _requests_ with short preamble to
> start with, since then you wouldn't find APs w/o short preamble...

I'll try to remember to file a comment to TGmb on this (they are still
collecting comments for fixing issues in 802.11 and published
amendments). Probe Request with this does not make much sense (unless
you are either only interested in BSSes that support short preamble
and/or you know that the AP you're interested is able to receive this).
Authentication, association, and public action frames might be more
likely candidates for this.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: [RFC] mac80211: fix short preamble determination

[Johannes Berg]

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

On Mon, 2008-10-13 at 20:54 +0300, Jouni Malinen wrote:

> > I don't see how it cannot be -- you need stations not capable of
> > short-preamble to correctly update their NAV, no?
> 
> Well, if you have many such devices, yes, but one might try to live
> without such protection if there are some with very limited transmit
> needs.

Would you then announce short preamble as the AP? That'd mean all other
stations would use short preamble and the poor non-short-preamble STA
would be left completely in the dark wrt. its NAV.

>  I don't know whether it would make much sense in most cases and
> anyway, it would be possible to make APs reject all associations from
> such devices. For example, I could see an attempt to dedicate one
> channel for 11g (ERP) and short preamble supported STAs and make the
> more modern implementations get somewhat better throughput there.

Indeed, that is possible, I think there's even a status code allocated
for this.

> I'll try to remember to file a comment to TGmb on this (they are still
> collecting comments for fixing issues in 802.11 and published
> amendments). Probe Request with this does not make much sense (unless
> you are either only interested in BSSes that support short preamble
> and/or you know that the AP you're interested is able to receive this).
> Authentication, association, and public action frames might be more
> likely candidates for this.

Ohh. Just a few days ago I sent an email with a request for
interpretation (there really just is a typo in 802.11-2007 but...) That
got forwarded around a lot, but I guess at least TGmb will see it :)

johannes

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

Re: [RFC] mac80211: fix short preamble determination

[Jouni Malinen]

On Mon, Oct 13, 2008 at 08:03:32PM +0200, Johannes Berg wrote:
> > Well, if you have many such devices, yes, but one might try to live
> > without such protection if there are some with very limited transmit
> > needs.
> 
> Would you then announce short preamble as the AP? That'd mean all other
> stations would use short preamble and the poor non-short-preamble STA
> would be left completely in the dark wrt. its NAV.

Yes, indeed. In other words, this would be something that could work
mostly in cases where there is a STA with very limited needs (e.g., send
measurement results once an hour, etc.). I'm not aware of any such
deployment, though.

> Ohh. Just a few days ago I sent an email with a request for
> interpretation (there really just is a typo in 802.11-2007 but...) That
> got forwarded around a lot, but I guess at least TGmb will see it :)

Yeah.. I'm sure it will show up in TGmb in Dallas meeting (mid-Nov). It
might even get fixed eventually the 802.11-2010 (or 2011, or 2012, or
who knows when.. ;-).

-- 
Jouni Malinen                                            PGP id EFC895FA