Hello Johan,
On Tuesday, January 08, 2013 10:47:22 PM Johan Danielsson wrote:
> Maybe I'm incomprehensible, so let me try to clarify my question.
Thanks! Hopefully we can clear up some confusion.
> The normal sequence of events for HT A-MPDU BlockAck agreements are:
>
> 1) we receive an ADDBA
> 2) ampdu_action is called with RX_START
> 3) we send an ADDBA response
> 4) time passes with no activity
> 5) ampdu_action is called with RX_STOP
> 6) a DELBA is sent to the peer STA
> 7) everything is cool and froody
>
> However if 6 results in a failed transmission, mac80211 doesn't care,
> and we have a situation where the peer may continue to send A-MPDU:s,
> but we don't have any agreement, so we can't properly ACK.
Ah, I think I didn't get the "This may occur when an existing RX BACK
agreement times out, and the peer STA fails to hear the DELBA frame."
sentence in your original post.
I thought that this was just an example. But a semi-rogue device can
sent AMPDUs to anyone at anytime, so I argued that if we have no (or
no longer) a BA agreement [even if the peer never got the DELBA] we can
discard the AMPDU data and sent a DELBAs to the HT peer once it tries
sent us an A-MPDU (again). This is actually what we should do according
to 802.11-2012 10.5.4 - instead of calling dont_reorder. This would also
cover your case where a HT peer suddenly reappears again. Because once
the HT peer sends an AMPDU and the BA agreement has timed out on our side,
it will get a DELBA back the stale BA agreement on the Phoenix HT peer
will be torn down [but the peer can be established it again by sending
out a new ADDBA].
> My feeling is that nothing in 802.11-2012 covers this scenario. There
> are some paragraphs that deal with similar situations when using the
> other flavour of BlockAcks (originally defined in 802.11e I believe),
> but in my experience, you can't assume much based in this.
>
> And even if the DELBA in 6 is sent ok, there is a race between 5 and
> 6, where the originator has block ack state, but the recipient does not.
Yes, this sounds wrong. Was there a historic reason why RX_STOP was put before
DELBA? I've traced the code back to Intel's initial A-MPDU RX contribution:
commit 07db218396650933abff3c5c1ad1e2a6e0cfedeb
Author: Ron Rindjunsky <ron.rindjunsky@xxxxxxxxx>
Date: Tue Dec 25 17:00:33 2007 +0200
mac80211: A-MPDU Rx adding basic functionality
Stanislaw, do you know if iwlegacy needs AGG_RX_STOP before it can sent out
the DELBA [Maybe something about flushing an FW internal RX reorder buffer,
or anything]?
> 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.]
[Note2: Some hardware (rtlwifi) only have some sort of "fire and forget"
TX. The we don't know when, or even if a frame (like a DELBA) was received...]
[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.]
Regards,
Chr
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
