Re: ACK matching [was: TX status reporting with help of an ack queue]

["Mikko Virkkilä" <mikko.virkkila@bluegiga.com>]

On Thu, 2008-09-18 at 22:29 +0000, Mattias Nissler wrote:
> [I've added the zd1211rw maintainers to the CC, I hope they can shed
> some light on the question whether the ack queue mechanism that driver
> has is actually correct]
> 
> I've had a closer look at the idea of deciding whether a frame has
> been
> transmitted succesfully by monitoring incoming ACK frames and I've hit
> a
> fundamental problem: How do you correlate incoming ACK frames to the
> frames that were actually transmitted? The ACK frame only carries the
> address of the station that transmitted the frame being acked, no
> further information. Now this means if you have the hardware TX two
> frames and receive one ACK frame in the RX path, you cannot know which
> TX frame the ACK belongs to, because they will be identical, right?
> 
> The hardware, however, knows, because the ACKs are required to be
> transmitted directly after the corresponding frame is received, but we
> don't know in the driver about this timing information, at least not for
> rt2x00.
> 
> I wonder whether the ack queue idea Mikko found in the zd1211rw driver
> is actually working correctly for that driver? I've only had a short
> look, but found that incoming ACKs are only matched against transmitted
> frames by means of the address carried within the ACK. So I'd think in
> the situation I outlined above, the zd1211rw driver will also be unable
> to match the ACK to the correct frame. Any comments on this?
> 
> Mattiass
> 

AFAIK your analysis is correct and I think this is somewhat of a known
problem with the implementation in zd1211rw driver. I haven't come
across a way of getting around the problem. I read some suggestions
about stopping all transmission to a certain address until we get a
status update for the previous packet sent to that address, but iirc
this was deemed impractical. On the other hand the current
implementation in zd1211rw (and hopefully soon in rt2x00) doesn't really
break anything that works without it and on rt2x00 it gets AP-mode in a
somewhat more usable state. 

- Mikko