RE: mac80211 aggregation (was: iwlwifi aggregation info)

[Johannes Berg <johannes@sipsolutions.net>]

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

On Thu, 2008-08-07 at 14:21 +0200, Friedrich.Beckmann@infineon.com
wrote:

> The aggregation is introduced in 802.11n and A-MPDU aggregation
> always comes together with block acknowledgement. The reason is that
> the component frames of an A-MPDU aggregate are individually subject
> to retransmission but not the aggregate itself.

Sure, but for the purpose of the discussion the actual aggregation
doesn't matter much, and the block-ack was introduced by 11e

> Block Acknowlegment allows to have a configurable number of
> outstanding packets (up to 128) which you can transmit before
> you require an acknowledgement. Therefore you also have to
> keep the packets for which you do not have already an
> acknowledgement. This is similar to TCP windows.

Sure, I can read 11e too :)

> The AC has first hand only to do with the access priority to the
> air, but as a consequence the order of packets is only guaranteed
> within each AC. So each AC needs an individual TID and as a result an
> individual sequence number counter in order to do
> the duplicate detection.

This is a bit confusing to me, I don't think each AC has a TID, rather
more than one TIDs map into a single AC.

> The atheros way is for sure possible but it comes with some constraints
> in building the aggregates.
> 
> a) You can not dynamically adapt the A-MPDU to the remaining TXOP.
> b) You need to start a retransmission process of the aggregate packets in
>    the AC queue immediatly, because otherwise you cannot release the
>    buffers.

I wouldn't be so sure about either of these, Atheros hardware has an
elaborate scheme for suppressing frames and asking software to requeue
them to the hardware at a later time. I suspect they can use it here to
adapt the A-MPDU to the TXOP and suppress the remaining MPDUs if they
need to, and tell the driver which of the aggregate packets needs to be
retried later. I suppose that would need fairly shallow DMA queues, but
that's doable.

johannes

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