wifi: TCP timeout when STR MLO and Uplink OFDMA are both used in 802.11be networks

I am encountering an issue when trying to use TCP with multiple links and uplink OFDMA active in 802.11be networks, with MLO. I have two wireless links on the 5 and 6 GHz, with EMLSR disabled and minimal noise, in a simple network with just one AP (sender) and one STA (receiver). However, at some point in the simulation, the AP stops receiving any TCP ACKs from the STA in the uplink direction. This can also happen at different points in the simulation, depending on the configuration or the run number. But it usually happens right in the first 10 seconds after the application started. In addition, I no longer see this issue if I disable the uplink OFDMA. The flow monitor will also indicate that packets were lost in the uplink direction, when this issue occurs.

After adding some more logs to the RecipientBlockAckAgreement, I have noticed that the block ack window stops advancing when the issue occurs, preventing the AP from receiving any more uplink data from the STA. I have also noticed that the issue tends to happen after a Multi-STA All-ack frame was issued by the AP. Still, not all Multi-STA All-ack frames appear to provoke this, but it will happen at some point in the simulation.

To validate that the Multi-STA All-ack frame could be causing some issues, I changed the TID value in the HeFrameExchangeManager::SendMultiStaBlockAck function, from uint8_t tid = staInfo.first.second; to tid = 0; in order to skip the if (tid == 14) block and build either a normal ACK or a BA frame. After this change, the TCP data flow started working again like normal, with STR MLO and uplink OFDMA active. So is this a known issue or did I miss something in the configuration ? Is the current OFDMA implementation more optimized for the EMLSR mode instead ?

For testing purposes, I am providing the script that I used for the simulations, with the AP (192.168.1.1) sending TCP data to the STA client (192.168.1.2), over two links on the 5 and 6 GHz. Version 3.46 of ns3 was used, although I see the same issue when using the current dev build. There is some basic monitoring of the packet sink as well, that will show various TCP RTO and Retries once the issue happens. ofdma-str-mlo.cc