Bug 952 - WifiMacQueue sender queue drops every 120 seconds of simulation, apparently for no particular reason
WifiMacQueue sender queue drops every 120 seconds of simulation, apparently f...
Status: RESOLVED INVALID
Product: ns-3
Classification: Unclassified
Component: wifi
ns-3-dev
All Linux
: P3 normal
Assigned To: Nicola Baldo
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-29 05:50 UTC by Christian
Modified: 2010-08-04 05:54 UTC (History)
2 users (show)

See Also:


Attachments
Simulation scripts reproducing the bug (5.04 KB, text/x-c++src)
2010-06-29 05:50 UTC, Christian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian 2010-06-29 05:50:19 UTC
Created attachment 930 [details]
Simulation scripts reproducing the bug

WifiMacQueue sender queue drops around 120 secs.
Scenario tested:
wifi adhoc net, 2 nodes, sender: node 1, receiver: node 2, OnOffApplication (always on).

Specifically:
  - after 120 secs, no packet is enqueued.
  - at 121-122 secs, a packet is enqueued and the size of the queue drops. Then, the queue grows again and everything turns normal.
  - the behavior happens cyclically (period ~120 secs).

To record the behavior I have put a couple of NS_LOG instructions in the Enqueue method:
void
WifiMacQueue::Enqueue (Ptr<const Packet> packet, const WifiMacHeader &hdr)
{
  Cleanup ();
  if (m_size == m_maxSize)
    {
      NS_LOG_LOGIC ("qsize " << m_size);
      return;
    }
  Time now = Simulator::Now ();
  m_queue.push_back (Item (packet, hdr, now));
  m_size++;
  NS_LOG_LOGIC ("qsize " << m_size);
}

Example w/ MaxPacketNumber=400,MaxDelay=2:
121.001 400
121.002 400
121.002 400
121.661 1
121.661 2
121.661 3
...

Example w/ MaxPacketNumber=1000,MaxDelay=10:
121.001 1000
121.002 1000
121.002 1000
122.002 392
122.645 2
122.645 3
122.645 4
...

AFAIK, the behavior is:
  - independent from the L4 protocol: tested with both TCP and UDP
  - independent on the MaxDelay attribute: tested with 10 (default), 2, 20
  - dependent on the MaxPacketNumber attribute: tested with 400 (default), 100, 1000). With 1000 the queue first drops by ~600 packets and after another second it drops to zero. With 100 and 400 it drops directly to zero.

Revision used to test this bug: 6e83ec53ba0a.

Attached there's a sample script to reproduce the bug.
Comment 1 Nicola Baldo 2010-08-02 13:31:53 UTC
I confirm the behavior with latest ns-3-dev. We need to understand what is happening.
Comment 2 Kirill Andreev 2010-08-04 04:24:29 UTC
(In reply to comment #1)
> I confirm the behavior with latest ns-3-dev. We need to understand what is
> happening.

I have observed, that data is not more sent when ARP entry expires (120s). So, this is not a problem of mac queue, this is a possible problem of medium access (may broadcast collide in a scenario with two stations?)
Comment 3 Nicola Baldo 2010-08-04 05:54:34 UTC
Kirill, thank you for investigating the problem. I confirm it is an ARP issue, in fact enabling logging for ArpCache we can see the following:

121.002s ArpCache:MarkWaitReply()
121.661s ArpCache:MarkAlive()

ARP packets might be lost, either due to a collision (as said by Kirill) or more simply due to the overflow of the MAC queue. Still, I think the behavior seen is explained by the fact that when the ARP cache entry is in the WaitReply state, all packets from the upper layers are queued in the ARP queue, and will be forwarded to the device only when the ARP cache entry is refreshed. In the meanwhile, the MAC queue will gradually be emptied.

To summarize, this is not a bug.