[Ns-developers] Ack Timeout bug

[kirillano]

-------- Пересылаемое сообщение --------
24.04.09, 11:58, "kirillano" <kirillano at yandex.ru>:



24.04.09, 11:26, "Mathieu Lacage" <mathieu.lacage at sophia.inria.fr>:

> On Thu, 2009-04-23 at 20:04 +0400, kirillano wrote:
> > Hi All,
> > I have tested multple queues (DcaTxops) in wifi and have faced with a
> > bug:
> >   when MacLow sends a packet while ACK timeout has not expired (In
> > 802.11 standard in chapter 9.2.8 was said, that we must wait ack
> > timeout before next transmission).
> Unless, of course, a higher-priority queue has been granted access to
> the medium which is the whole point of having multiple tx queues in a
> device.
> > I have added NS_ASSERT(false) after line, which cancels ACK timeout in
> > CancelAllEvents () method in MacLow, which is called from
> > StartTransmission () and my simulation has failed with tis assert.
> > When I have looked through output more detailed - I have seen that a
> > packet from another queue (beacon queue) has accessed the medium
> > before ACK timeout of data packet has expired after crash of ACK. I
> Yes, and this is perfectly fine I think.
> >  think, that the problem may be resolved by adding a moment of time
> > when AckTimeout expires in DcfManager. Now DcfManager knows nothing
> > about AckTimeout and can grant access before ACK timeout has expired.
> Yes, and that is precisely the expected behavior.
> > This problem seems serious to me, because when AckTimeout is
> > cancelled, the m_currentPacket in DcaTxop shall never be zero - so,
> > the queue is blocked and no data packets can be sent.
> I am not sure I understand the problem you describe here. I think that
> the DcfManager behavior is precisely what needs to be done to support
> properly multiple tx queues with different priorities. It might be that
> there is a bug somewhere else (say, in DcaTxop) which makes the priority
> preemption problematic and, if so, describing precisely the problem you
> observe when this happens would help fix it. Another way to handle that
> issue would be produce a testcase which can be used to reproduce your
> problem with ns-3-dev so that I can look at it myself.
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

Regards, Kirill Andreev 
Wireless Software R&D Group, 
IITP RAS