wifi: Issues with QosTxop::StartNextPacket

By inspecting the code, I believe there are a few issues with QosTxop::StartNextPacket, i.e., the method that determines whether another frame can be sent in a TXOP. The goal of this report is to keep track of these issues and double check in case I missed anything obvious. I spotted the following issues:

• if the BA Manager retransmit queue is not empty, a packet is dequeued from such queue:

Ptr<const Packet> peekedPacket = m_baManager->GetNextPacket (hdr, true);

(the remove parameter is true). However, assuming that we enter the body of the if statement ("start next packet"), a packet is dequeued from the EDCA queue and such packet is passed to MacLow. Thus, the packet dequeued from the BA Manager retransmit queue is lost.

• A-MSDU aggregation is not attempted in the body of the if statement "start next packet". Thus, if A-MSDU aggregation is enabled, only the first frame in the TXOP is an A-MSDU and the following ones are not aggregated.

• if there is time for another packet (thus we enter the body of the if statement "start next packet"), a packet with the same TID and recipient of the current packet is dequeued from the EDCA queue. Hence, in a TXOP, the TXOP holder only transmits packets destined to the same station, while it could send packets destined to other stations as well (provided that they belong to the same AC).

• the condition to enter the body of the if statement "start next packet" is:

if (txopLimit >= GetLow ()->CalculateOverallTxTime (peekedPacket, &hdr, m_currentParams))

Thus, the overall TX time is compared to the whole duration of the TXOP. In my opinion, it should be compared to the remaining TXOP time.