K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-06-13T06:42:25.924155Z
K 7
svn:log
V 1167
Begin fleshing out the AMPDU pending/running logic.

If AMPDU-TX negotiation is pending, packets for that given TID should not
be transmitted but instead should be queued.

Once the AMPDU-TX request/response has occured, packets should be dequeued.

This is so that the initial negotiated BA start stays valid (hopefully!)
until the end of the request/response exchange. The transmitter must
not queue packets with incrementing seqnum's until that ADDBA exchange
has completed.

Once AMPDU-TX is established, it then doesn't matter if they're sent
aggregated or not - any seqnum being sent updates the BAW.

If this isn't done, then the sender may TX a packet (say an ARP request)
between the BA request and BA response. Thus the BA window start negotiated
as part of the ADDBA exchange doesn't match the seqnum of the first packet
received after the ADDBA exchange (as the packet in-between has helpfully
updated it for you), and you end up with a BA window that doesn't match.

This isn't currently important as ampdu TX is still non-functional
(the ath(4) driver doesn't add sequence numbers and doesn't update
the BA window); this is just in prepration for that.

END