Packets not getting dropped for queue size of 1 for WifiNetDevice

[Boong Baang]

• I am generating messages using GenerateTraffic function at rates varying from 1 Hz to 80 Hz, and I vary the queue size at the MAC layer from 1 packet to 1000 packets. From my understanding of the theory, the queue of size 1 won't be able to store all the messages being generated (obviously true for higher rates) and thus I should see a large number of drops at the MAC layer of the sender. However I don't see any drops in the MAC layer of the sender using trace MacTxDrop. Could someone analyze why this is happening ? I found this question that asks a similar question (link), but the solution is not mentioned.

• Also I am not able to verify the cause of packet drops 'caught' by different traces and here are my assumptions:

MacTxDrop - MAC buffer not able to store all packets generated by the application at the sender and so packet drops occur.
PhyTxDrop - When a transmission is ongoing, another packet arrives and if preemption is enabled, the previous packet will be dropped.
PhyRxDrop - Due to packet collision and out of range, if the packet energy level is lower than the sensing/energy detection threshold, packet drop occurs at the receiver.
MacRxDrop - If the MAC buffer at the receiver is not able to store all the packets that are sent from the Phy layer (due to limited buffer size), packets will be dropped at the MAC layer of the receiver.

Is my understanding of the above traces correct ?

• I am using the  source->SetAllowBroadcast (true); so when 1 packet is dropped from 1 sender, do all the receiver's PhyRxDrop show that as a drop ?

I am attaching my code below for verification. Please help if someone has got any insights on it.

[Boong Baang]

I have localised the issue, even though the GenerateTraffic keeps generating packets at the intended intervals, the packets are not getting queued. This can be verified by the using the Enqueue trace. It seems once the queue is full, no new packets attempt to enqueue. Thus the drops do not happen. However, I can't understand why the newer packets are not trying to enqueue: once a packet is generated, it should be sent to the queue and depending on whether the queue has empty slots or full, the packet should get enqueued or dropped. 

Help in any way is very much appreciated.

[menglei zhang]

The Packets are not queued in the net device. They are queued in the Wi-Fi Mac Queue. You can find the attribute (Ptr<WifiMacQueue> m_queue;) in the following link.

https://www.nsnam.org/doxygen/txop_8h_source.html#l00504

[Boong Baang]

Yes, and I add a trace to the enqueueing event to the WifiMacQueue,

  std::string enqueue_path= "/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/*/$ns3::OcbWifiMac/*/Queue/Enqueue";

and it prints whenever a packet has been queued:

void EnqueueTrace(std::string context, Ptr<const WifiMacQueueItem> item)
{
  Time entry_time = Simulator::Now();
  std::cout<<"Packet entered queue at"<<entry_time<<std::endl;
}

The problem is that when I keep the queue size smaller than the number of packets that arrive, the EnqueueTrace is not fired after the queue is full.

So I don't get what you said, I am looking at the queue I think.

[menglei zhang]

If you are using the Wave, I am not familiar with that module. A brute force way is going to the EnqueueTrace and print out more information from there.

[Adil Alsuhaim]

When the queue is full, a new packet doesn't get enqueued so "Enqueue" event won't fire, and that's why EnqueueTrace doesn't fire.

If you try to enqueue a packet with the queue full, the DropBeforeEnqueue event fires instead.

[Adil Alsuhaim]

Here are some details

• MacTxDrop this event is triggered from one of the WifiMacQueue queues. A packet can be dropped either because the queue is full, or if it exceeds its time in the queue. I think it is more reliable to track the Queue events such as EnqueueTrace, DropBeforeEnqueue, etc to get more information. 
• PhyTxDrop For PhyTx, it seems that packets will only get dropped if the device is in sleep mode. Checkout the WifiPhy class (in the file src/wifi/wifi-phy.cc) for where the function NotifyTxDrop
• PhyRxDrop A packet reception fails for many "reasons". Starting from ns-3.30 (I think) the trace PhyRxDop includes a reason parameter that is defined in WifiRxfailureReason. If you check wifi-phy.cc for when "NotifyRxDrop" function is called, you can see the reason for dropped packets. 
• MacRxDrop If the packet is received by PHY correctly, there is no Rx buffer that I can see in the code and it is not enqueued by receivers. If you check out the OcbWifiMac class, you can see that it calls the function NotifyRxDrop (inherited from WifiMac), to fire this event if a packet was received but it's MAC address is not broadcast, or the node's MAC address. 

PhyRxDrop only fires if a node sees a packet but can't receive it for some reason. Broadcast or not, shouldn't matter. A receiver will read the signal and then examine the MAC address. So PhyRxDrop fires independently, some node may drop a packet if they're already in Tx, already in Rx, in sleep mode, etc.

[Boong Baang]

I see, but even when I use OldestDrop or PushFront (LCFS), the new packets are still not enqueued. I am attaching a file where I generate 10 packets and queue size is 1. So I would assume the 1st packet goes through as there is no queueing before it. When the 2nd packet comes, it has to wait for some time until the 1st packet is sent out. But I made the packet interval small so that the rest of the packets (3-10) arrives before the 2nd paket is transmitted. As OldestDrop is selected, when the queue is full, the queue should drop the 2nd packet and enqueue the newer packets that are arriving. But this is not happening, and the 2nd packet is sent.

I am attaching the file, could you please have a look at it ?

i am also attaching the verbose output (results.txt): it shows that once the queue is full, the WifiNetDevice in the transmitter node doesn't call the Send method.

[Adil Alsuhaim]

Packets in MAC queues also have to content for channel access and there's a mechanism for it specified by the 802.11e standard by generating a random backoff timer. Try to set the queue sizes using MaxQueueSize attribute instead

Config::Set ("/NodeList/*/DeviceList/*/$ns3::WifiNetDevice/Mac/$ns3::RegularWifiMac/$ns3::OcbWifiMac/*/Queue/MaxQueueSize", StringValue ("1p"));

You can check if you have set it correctly by trying to access the WifiMacQueue (which is not straight forward)

  Ptr<WifiNetDevice> dev = DynamicCast <WifiNetDevice> (c.Get(0)->GetDevice(0));

 Ptr<OcbWifiMac> mac = DynamicCast<OcbWifiMac> (dev->GetMac());

 PointerValue val;

 mac->GetAttribute("BE_Txop", val);

 Ptr<Txop> txop = DynamicCast<Txop>(val.GetObject());

 Ptr<WifiMacQueue> queue = txop->GetWifiMacQueue();

  std::cout << "QueueMaxSize=" << queue->GetMaxQueueSize() << "\tMaxSize: " << queue->GetMaxSize()

                       << " CurrentSize:" << queue->GetNPackets() <<std::endl;

I tried to use "DropBeforeEnqueue" and "Drop", but the events never fired.

I think the problem you're having is with the Socket not actually triggering the device's Send function. Because that's where the enqueue process occurs. Socket are an abstraction of the communication process, and I think something happens somewhere that makes the packets not make it to the Send function of the WifiNetDevice. 

I personally don't use Socket class to send out packets in my work, and use the device directly. But if you do that, you may want to add the necessary headers to that outgoing packet since these are added to outgoing packets when you use sockets.

You can try this hack

Ptr<WifiNetDevice> dev = DynamicCast <WifiNetDevice> (socket->GetNode()->GetDevice(0));

//Should add UdpHeader, and Ipv4Header if you want to properly send the packet.
dev->Send (p , Mac48Address::GetBroadcast(), 0x0800); //0x0800 is IPv4, 0x88dc is WSMP

For the record, I personally use WaveNetDevice, and manually send packets using the WaveNetDevice object. This allows me to have more control over transmission parameters per packet like the data rate, the Wifi Queue to use, etc. I attach an example of basic code with proper comments that explains how I do it if you think it can be helpful.

[Boong Baang]

If the problem is with the socket, them I am in trouble as I need to work with SetRecvCallback and afaik, it is only defined for socket class of objects. 

The issue is really confusing: it works well until the queue is not full and suddenly the sender WifiNetDevice stops sending packets.

Thanks for adding the new program, I will see if I can use it for my needs. I have learnt a lot from your posts and replies in this group, and I appreciate your time and effort in helping others. 

[Boong Baang]

The program verify_oldest_drop.cc that I had attached to reproduce my issue runs in ns 3.29 but gives the following error with ns 3.30

msg="Incompatible types. (feed to "c++filt -t" if needed)
got=CallbackImpl<void,ns3::Ptr<ns3::Packet const>>
expected=CallbackImpl<void,ns3::Ptr<ns3::Packet const>,ns3::WifiPhyRxfailureReason>", file=./ns3/callback.h, line=1449
file=./ns3/traced-callback.h, line=268
terminate called without an active exception
Command ['/home/winser/ns-allinone-3.30/ns-3.30/build/scratch/verify_oldest_drop'] terminated with signal SIGIOT. Run it under a debugger to get more information (./waf --run <program> --command-template="gdb --args %s <args>").

 

This may be related to the issue. Attaching the file again for ease of checking.

[Hassam Mughal]

Thank you for your detailed explanation. I have a query related to this posted on these links;

https://groups.google.com/forum/#!topic/ns-3-users/ZAwb8CNKX-4

https://groups.google.com/forum/#!topic/ns-3-users/ZeagCqZRsP4

Should I also follow the same pattern as you do? Because I need to also consider the queue waiting time later in my scenario for task scheduling and selection of node. Moreover, I will be using three wireless interfaces simultaneously to send and receive packets on each mobile node in Adhoc mode.

[Boong Baang]

Hassam Mughal I don't understand what you mean by pattern, The queueing delay can be calculated by the difference of the time instants the dequeue trace fires and the enqueue trace fires and that part has been implemented in the code Adil Alsuhaim has added here. 

[Hassam Mughal]

Dear Boong Baang,

With the pattern, I meant the way Adil is using Wave model instead of sending packets through the socket directly. Because, in my case, I have tried to get the data rate trace of MinstrelHt, Aarf and Aparf WifiManagers but none of them is triggering the trace. And in the power-adaptation-interference.cc example it is triggered only 4 times initially but later in the simulation, it is not. Even when I am printing the datarate value in yanswifiphy it is getting changed but the trace is not triggered. So, should I also use the wave model instead of wifi?

Thanks

[Biplav Choudhury]

I used Adil's file and the Enqueue and Dequeue traces as expected. So I think it should work properly.

I am yet to check for the MAC packet loss trace. Good luck.

--
Posting to this group should follow these guidelines https://www.nsnam.org/wiki/Ns-3-users-guidelines-for-posting
---
You received this message because you are subscribed to a topic in the Google Groups "ns-3-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ns-3-users/-yaX3tS0gbw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ns-3-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ns-3-users/c1e59b15-3c05-459a-a103-e24dbbf66f63%40googlegroups.com.