From: Christian Lamparter <chunkeey@googlemail.com>
To: Johannes Berg <johannes@sipsolutions.net>
Subject: Re: mac80211 and RX of A-MPDU with missing back agreement
Date: Wed, 9 Jan 2013 14:46:44 +0100
Cc: Johan Danielsson <joda@kth.se>, linux-wireless@vger.kernel.org,
	sgruszka@redhat.com
References: <CAESKgcgVQYwT770OfOXZnB-06SnidfxV7DnUrAMquJZtLNsYHg@mail.gmail.com> <201301090038.01984.chunkeey@googlemail.com> <1357732965.9757.4.camel@jlt4.sipsolutions.net>
In-Reply-To: <1357732965.9757.4.camel@jlt4.sipsolutions.net>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Message-Id: <201301091446.44597.chunkeey@googlemail.com> (sfid-20130109_144653_390447_5AAA54EA)
Sender: linux-wireless-owner@vger.kernel.org

On Wednesday, January 09, 2013 01:02:45 PM Johannes Berg wrote:
> On Wed, 2013-01-09 at 00:38 +0100, Christian Lamparter wrote:
> > > So, my question now is: Does this reasoning make sense, or have I
> > > missed anything?
> >  
> > I think reordering 5 and 6 won't stop the race entirely. ACKs are 
> > usually generated by hardware (or firmware) right away when the received
> > frame passed the CRC checks and found a place to stay in the HW's FIFOs.
> > However by the time DELBA is processed by the peers' 802.11 stack, some
> > frames on the tx-path might have left the DELBA in the dust [keep-alives
> > and friends].
> > 
> > [Note: Action frames like DELBA have to be encrypted/decrypted when 
> > MFP/802.11w is enabled on the link and some HW/FW can't do that. So
> > it takes even longer to react to those.]
> 
> Actually no: HT action frames aren't robust management frames.

DelBA is part of the Block Ack Actions as defined in 802.11-2012 8.5.5.
The Block Ack category is marked in Table 8-38 as "robust"?!

Was this changed from the original 11w spec? Maybe that would explain
why the Nexus 4 thinks it doesn't need to de-/encrypt BA agreements?.

> FWIW, our (Intel's) firmware will send frames from the aggregation
> queues unaggregated as soon as it receives a DelBA frame from the
> peer, so as long as it receives it there's no issue.
Good. Then it was probably just more convenient ;). But we still need
a case for HW which doesn't support IEEE80211_HW_REPORTS_TX_ACK_STATUS.

> > [Note3: What will happen to DELBAs if they aren't acked? Is there a timeout
> > or are they retried until the peer is dropped by other means?
> > I'm asking this because with some hardware we have to be greedy with the
> > number of open BA Agreements. For example ti's wl12xx can only support a
> > limited number of open RX BA Agreements.]
> 
> DelBA frames are unicast frames, so they're retried normally.
Uh, this note was out of context. It had to do with a sentence
from a previous post that wasn't discussed:

On Tuesday, January 08, 2013 11:39:10 AM Johan Danielsson wrote:
> It seems more reasonable to send the DELBA and wait for an ACK
> before removing the BACK state (with ampdu_action). Currently this
> is done the other way around.

If we only call ampdu_action(RX_STOP) as part of a callback when we have
received an ACK from a outgoing DELBA [yes I know some HW doesn't support
that] what happens to BA agreements after all DELBAs retries have been 
used up? Or do we have to retry them endlessly? [I'm asking this because
we do have a retry-when-we-receive-unicast for BARs already...].

Regards,
	Chr