[Ns-developers] Ack Timeout bug

[Mathieu Lacage]

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