Bugzilla – Bug 1498
beacon TX cancels ACkTimeout event
Last modified: 2016-03-31 17:02:45 UTC
On 08/14/2012 08:26 PM, Ghada Badawy wrote: > Hi, > I have a network consisting of an AP and a STA with downlink data. The AP > sends a packet to the STA but it is not recieved correctly so while waiting > for the AckTimeout event to expire the beacon dca gets a tx opportunity and > cancels all the events in mac low. This leads to the Acktimeout to never > expire and edca will always have m_currentPacket !=0 so the AP is not able > to send data anymore. > > Is that a bug? Shouldn't the DdfManager know that EdcaTxopN is still > waiting for an answer so the beacon dca doesn't perform backoff? > > Regards, > Ghada > On 08/15/2012 09:10 AM, Ruben Merz wrote:> On 8/14/12 8:26 PM, Ghada Badawy wrote: > Hi, do you have a small simulation scenario that reproduce this behavior? > > R On 08/15/2012 08:41 PM, Ghada Badawy wrote: > I found the problem. It is in mac-low.cc in StartDataTxTimers the dcf > manager should be notified for blockAcktimeout for differet block ack types. > > The problem gets solved if we add "NotifyAckTimeoutStartNow (timerDelay);" > to the 2 if statements "if (m_txParams.MustWaitBasicBlockAck()) and if > (m_txParams.MustWaitCompressedBlockAck()) " On 08/16/2012 09:25 AM, Ruben Merz wrote: > Hi, > > That would be really great if you could send me a simulation script that > reproduces this bug. In order to verify and possibly apply your fix, I > do need to reproduce this problem. > > Ruben On 08/16/2012 03:31 PM, Ghada Badawy wrote:> Hi Ruben, > I can't reproduce it with the existing ns3 because it happens only when > I add aggregation and implicit block ack. > > In the existing ns3 when block ack is setup the transmitter only waits > for a blockack after sending a blockack request and since it is a small > packet the blockack timer expires fast (before the beacon dcf takes > channel access) but when I add MPDU aggregation the problem appears > because the tx time of the frame is long and the sender waits for a > blockack response after sending the A-MPDU. > If you look at the code you will find that what I say makes sense mac > low notifies dcf manager about ack timeouts then why not notify it about > blockack timeouts as well. > > Anyway I am finalizing the 11n code and planning on contributing it back > to ns3 >
Adding previous email with Ghada Hi Ruben, I can't reproduce it with the existing ns3 because it happens only when I add aggregation and implicit block ack. In the existing ns3 when block ack is setup the transmitter only waits for a blockack after sending a blockack request and since it is a small packet the blockack timer expires fast (before the beacon dcf takes channel access) but when I add MPDU aggregation the problem appears because the tx time of the frame is long and the sender waits for a blockack response after sending the A-MPDU. If you look at the code you will find that what I say makes sense mac low notifies dcf manager about ack timeouts then why not notify it about blockack timeouts as well. Anyway I am finalizing the 11n code and planning on contributing it back to ns3 Regards, Ghada On Thu, Aug 16, 2012 at 3:25 AM, Ruben Merz <ruben@net.t-labs.tu-berlin.de> wrote: Hi, That would be really great if you could send me a simulation script that reproduces this bug. In order to verify and possibly apply your fix, I do need to reproduce this problem. Ruben On 8/15/12 8:41 PM, Ghada Badawy wrote: I found the problem. It is in mac-low.cc in StartDataTxTimers the dcf manager should be notified for blockAcktimeout for differet block ack types. The problem gets solved if we add "NotifyAckTimeoutStartNow (timerDelay);" to the 2 if statements "if (m_txParams.MustWaitBasicBlockAck()) and if (m_txParams.MustWaitCompressedBlockAck()) " Regards, Ghada On Wed, Aug 15, 2012 at 3:10 AM, Ruben Merz <ruben@net.t-labs.tu-berlin.de <mailto:ruben@net.t-labs.tu-berlin.de>> wrote: On 8/14/12 8:26 PM, Ghada Badawy wrote: Hi, I have a network consisting of an AP and a STA with downlink data. The AP sends a packet to the STA but it is not recieved correctly so while waiting for the AckTimeout event to expire the beacon dca gets a tx opportunity and cancels all the events in mac low. This leads to the Acktimeout to never expire and edca will always have m_currentPacket !=0 so the AP is not able to send data anymore. Is that a bug? Shouldn't the DdfManager know that EdcaTxopN is still waiting for an answer so the beacon dca doesn't perform backoff? Regards, Ghada Hi, do you have a small simulation scenario that reproduce this behavior? R
Created attachment 1439 [details] Added NotifyAckTimoutStartNow() and NotifyAckTimeoutRestartNow() at appropriate places Here is a proposed patch
Thanks Ghada, But I don't see a patch file, I see a full file. Can you produce a proper patch with the diff utility or with mercurial? Also, do you have test scenario?
Ghada could you resubmit your patch? It seems not correctly uploaded.
This bug looks no longer valid (not reproduced anymore). I suggest to close it.
Could no longer be reproduced.