[Ns-developers] Ack Timeout bug

[Mathieu Lacage]

see bug 556 to track this issue

On Fri, 2009-04-24 at 14:35 +0200, Mathieu Lacage wrote:
> On Fri, 2009-04-24 at 12:00 +0400, kirillano wrote:
> 
> > I have observed this problem running my mesh script
> > Code repository is https://forge.wenos.ru/hgprojects/ns3dev/
> > (was merged with ns3dev repository just 2 days ago)
> > I have run ./waf --run "mesh --x-size=1 --y-size=2 --seed=123 --packet-size=1000 --packet-interval=0.001"
> > I have obsreved this by printing moments of:
> >   1. NotifyAccessGranted () of DcaTxop
> >   2. Moment when MacLow schedules ack timeout and AckTimeout value
> >   3. The following moments of time in DcfManager:
> >     Time m_lastNavStart;
> >     Time m_lastNavDuration;
> >     Time m_lastRxStart;
> >     Time m_lastRxDuration;
> >     bool m_lastRxReceivedOk;
> >     Time m_lastRxEnd;
> >     Time m_lastTxStart;
> >     Time m_lastTxDuration;
> >     Time m_lastBusyStart;
> >     Time m_lastBusyDuration;
> > and at the simulation time = 5043781863ns beacon has accessed medium
> > before ack timeout has expired.
> > I think, this is a problem of DcfManager, because it keeps last tx and
> > rx moments of time, last NAV busy, and, as I think, it must know about
> > expire-time of current ACK timeout. Now Ack timeout is scheduled at
> > mac-low layer, and no information is passed to DcaTxop.
> > So, I think to ask mac-low when ACK and CTS timeouts are expire and
> > notify DcfManager about it, Also when GotAck - notify that timeouts
> > may be cancelled
> 
> I assume that you reference 9.9.1.3-c.1/2 from 802.11-2007: in the
> future, when you are arguing against invalid implementation behavior, it
> would be nice to point me to the spec sections rather than make me dig
> out the relevant items: it would save you a lot of time to convince me
> that what you are describing is a real bug.
> 
> To answer your point, yes, I think that you are right and that I was
> wrong: the DcfManager appears to be in need of some extra knowledge
> about pending transmissions waiting for an ack: I suspect that you will
> have to rename MacLowNavListener to MacLowDcfListener and extend it to
> report WaitAck and GotAck events. If you do this, you will have to
> provide first a new testcase in dcf-manager-test.cc to show that it
> fails with the current implementation, and, then, that the new
> implementation passes that new testcase.
> 
> Yes, the above is a lot of work, but the DcfManager code is the most
> scary piece of code in wifi and I am very scared by the idea of
> modifying it without serious regression tests.
> 
> thanks for taking time to identify and report this bug,
> Mathieu