[Ns-developers] Ack Timeout bug

[Mathieu Lacage]

I meant this:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=556

On Fri, 2009-04-24 at 14:48 +0200, Mathieu Lacage wrote:
> 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