Bugzilla – Bug 2418
Packets get lost during BlockAck
Last modified: 2016-10-09 04:15:26 UTC
Created attachment 2443 [details] Simulation File The attached files contains a simulation scenario + PCAP files for two 802.11ac nodes (AP + STA) + Server node. The STA uses BulkSendApplication to upload some data to a TCP sink located in the server node (20ms of latency). After starting the simulation campaign, the TCP breaks and the throughput decreases a lot. After some analysis to the PCAP file generated by the STA, I found the following: After sending the packet with No. 4217 in the PCAP file, the BlockACK is lost. As a result, the STA sends BlockAckRequest (Packet No. 4226) requesting the AP to acknowledge the reception of Packets with Sequence Numbers (2366 upto 2379). The AP replies back to the STA, that these packets were missing, so the STA resend them and get a BlockACK back. Now the STA, continues sending packets normally starting with packet No. 4245, however it misses some TCP packets which have Sequence Numbers from (15999849 to 16011433). This is the reason why TCP breaks. I did some debugging during each of the previous steps and I found that these TCP Packets with sequence numbers exist in the queue of the STA however after getting the last BlockAck, these packets get removed from the queue. To produce the bug, run the following command: ./waf --run "wifi-tcp --bufferSize=1000000 --simulationTime=2 --RngRun=10 --pcap=1"
Created attachment 2444 [details] Traces
Pcap won't tell us more, we should have a look at debug traces. Do you know at which time does this happen when running the provided command? Do you also see the issue after applying the patch for bug 2379?
I applied batch 2379 and it solves the problem. I did multiple run for 80 seconds and simulation did not break.
Created attachment 2449 [details] NewTraces Following my previous comment, the TCP does not break and the throughput seems to be stable. However, I checked the PCAP files and I found that after sending A-MPDU, the BlockACK received from the AP acknowledges not only the previous packets but also some very old packets even-though they were acknowledged with a previous BlockACK. So is this a correct behavior?
Do you have some traces when this happens? You need to know that the BACK contains a bitmap with every packets between the first unacknowledged frame and the next 64 frames, even though some of those might have been already acknowledged.
Can we reject this bug? Still no feedback received.
Reject this bug, please open a new thread if a bug is indeed confirmed.