(In reply to Akin Soysal from comment #0)
> Created attachment 2900 [details]
> Fix in DELBA frame to tear down block ack mechanism
> 
> Hello,
> 
> There are cases when the receiver's ACK does not reach the transmitter and
> the transmitter keeps sending ADDBA request. According to 802.11-10.5.4
> Error recovery upon a peer failure, we know that there is an ADDBA
> inactivity timer. After setting a
> ns3::RegularWifiMac::BE_BlockAckInactivityTimeout for example, we see that a
> DELBA request is transmitted by the transmitter. However, since the
> receiving side is far away, there is still the possibility that the receiver
> cannot respond to this request. In this case, the packets of other users
> should not be blocked because of continuous transmission of ADDBA requests.
> Therefore, I propose to add this line in EdcaTxopN::SendDelbaFrame just
> before sending the frame to the queue:
> 
> m_baManager->TearDownBlockAck (addr, tid);
> 
> As long as the block ack mechanism is not torn down, the transmitter will be
> blocked.
> 
> I have also attached a patch for ns-3.26.
> 
> Regards,
> Akın
>

Akin, is this part of the patch for the same reason, or something else?

@@ -1466,9 +1467,13 @@
     {
       retval = hdr.GetAddr2 ();
     }
+  else if (m_typeOfStation == AP)
+    {
+      retval = hdr.GetAddr3 ();
+    }
   else
     {
-      retval = hdr.GetAddr3 ();
+      retval = hdr.GetAddr4 ();
     }
   return retval;
 }


Also, if you TearDown before sending, it seems to me that calling again TearDown() upon successful ACK will be a no-op, but is there any case in which the BA agreement is torn down, then reinitiated, but the ACK to this previous delete event would cause the newly attempted agreement to be torn down?

Akin, if you are familiar with this part of the standard (or what real implementations do), do you have any insight as to how bug 2470 should be handled:

https://www.nsnam.org/bugzilla/﷒0﷓

Created attachment 2901 [details]
Newer Fix in DELBA frame to tear down block ack mechanism

Sorry there was unrelated code in the fix. I have attached the new version with the unrelated parts removed.

Thomas, as far as I have seen from the spec there is no specific ACK for a DELBA frame.

9.21.5 Teardown of the Block Ack mechanism
When the originator has no data to send and the final Block Ack exchange has completed, it shall signal the end of its use of the Block Ack mechanism by sending the DELBA frame to its recipient. There is no management response frame from the recipient. 39 The recipient of the DELBA frame shall release all resources allocated for the Block Ack transfer.
The Block Ack agreement may be torn down if there are no BlockAck, BlockAckReq, or QoS data frames (sent under Block Ack policy) for the Block Ack’s TID received from the peer within a duration of Block Ack timeout value (see 10.5.4).

And the footnote 39 says:
39
Normal Ack rules apply.

So the ack that you see after DELBA is just a simple ack and is not a management frame. Such an ACK should not cause the teardown of a block ack mechanism anyway. I also attach the figure in 802.11-10.5.4 Error recovery upon a peer failure, you do not see any DELBA acks in that figure.

The BLOCK_ACK_DELBA enum value in the ns3 code seems to be then misleading. But in the code when the delba frame is sent, it is also set as a BLOCK_ACK_DELBA frame. In my opinion, delba frame and delba ack should be separate things and delba ack should not even exist at all.

Regarding 2470, I have to look into that and if I have an answer I will get back to you.

Created attachment 2902 [details]
802.11 - Figure 10-14—Error recovery by the receiver upon a peer failure

Why you do not do a check on the originator field?
My opinion is that we should move what is currently handled in GotAck to SendDelbaFrame:

if (delBa.IsByOriginator ())
  {
    m_baManager->TearDownBlockAck (m_currentHdr.GetAddr1 (), delBa.GetTid ());
  }
else
  {
    m_low->DestroyBlockAckAgreement (m_currentHdr.GetAddr1 (), delBa.GetTid ());
  }

Right, I did not think of the "not by originator" case. This fix is better.

OK thanks for your feedback, I will check whether this does not break any regression tests and if fine I'll push the fix to ns-3-dev.

Created attachment 2904 [details]
Additional Delba Fix

I have tried it with the current fix and it hit an ASSERT in BlockAckManager. After this fix, I have not encountered any errors.

I doubt about the second patch, I will already deliver the first one.
Can you send the script that causes the assert in BlockAckManager?

Just an idea, shouldn't we disable acks for DELBA frames then?
It appears that NeedBarRetransmission is searching for an agreement that does not exist. Perhaps it's because of a timeout of missed ack.

Sebastien, when the timeout occurs within the AP (originator), then first patch is necessary. That patch fixes some of the problems. But there are few more cases when DELBA problem happens, too, possibly when a timeout occurs in the STA(recipient). We have not kept a script for the case with second patch. I will try to regenerate it within this week but since it happens sporadically, I might not be able to reproduce it.

Matias, that is also what I understood from the specs. I hopefully manage to regenerate the second case.

Can we get an example script? What are the next actions here?

Unfortunately, I do not have an example script that catches this error, we have stopped running tests for cases when the STA is just out of coverage of the AP. Additionally since the proposed fix (just Sebastien's fix in #6) is in place, we may be avoiding it when the error should happen. This is supposed to happen when the STA is sufficiently far away from the AP and the ACKs cannot reach the AP for 802.11ac for example.

I propose to add your last fix and close the ticket until a problem pops up.

-----

if (delBa.IsByOriginator ())
  {
    m_baManager->TearDownBlockAck (m_currentHdr.GetAddr1 (), delBa.GetTid ());
  }
else
  {
    m_low->DestroyBlockAckAgreement (m_currentHdr.GetAddr1 (), delBa.GetTid ());
  }

OK, I will close this one.

Pushed in changeset 13355:aec601312ab2