I see packet dropped in Flow Monitor , but I could not see packetsDropped and bytesDropped by reason code

[vicente angelo de sousa junior]

Hi all,

I am trying to evaluate a WiFi (802.11g) infraestucture scenario when the number of STAs is increased (and when we have only a user, but its offered rate is increased). In both cases, I get a lot of packet drops and thoughput behaviour is strange, specially when a I changed the simulation time. Packet drop increases a lot when the simulation is increased. I want to investigate the reason of drops using flowmonitor, but I got other strange results.

When a I run the attached script, I can see that there are packets lost in my flowmonitor results, but (iter->second.packetsDropped) is always equal to zero. In this way, flowmonitor does not help me to figure out the reasons of dropping.

Should I need to configure something to get Drop Reason code? Please can someone give me a suggestion how to find out the cause for these lost packets.

I also attached the xml results from flowmonitor. For one flow in DL (AP to STA) and the other in UL (STA to AP), I got the following results:

Flow 1:

txPackets=833340

rxPackets=92868

lostPackets=660606

Can someone explain the reason of (rxPacktes + lostPackets = 753474) is different (smaller than) of (txPackets = 833340).

Flow 2:

txPackets=833340

rxPackets=92217

lostPackets=661201

BTW, I configure 100 Mpbs of offered rate to get packet drop faster.

BR

Vicente Sousa

[Tommaso Pecorella]

Hi,

the packet are not shown in the xml because they're not dropped, they're "lost".

A dropped packet is one that is dropped by a node, and there's a reason for dropping it.

A "lost" packet is one that has been recorded as sent, but it never reached its final destination, nor it has been dropped by a node.

Now, a precision is due. The drops are recorded at IP level. All the packets dropped by MAC queues or for channel errors aren't recorded (Flow Monitor works at IP level).

Moreover, your packets are lost at the simulation end. Basically you have a clogged network, and all the sent packets are held in the Tx queues. When the simulation ends, the queue is flushed and the packets still there are lost.

The numbers (lost + Rx != Tx) may be different due to a number of reasons, mainly fragmentation and retransmissions.

Keep in mind that FlowMonitor isn't really meant to be used in a congested network, as... well, no stats are really meaningful when your network is congested.

Hope this helps,

T.

[vicente angelo de sousa junior]

Hi,

Thanks for your reply. I'm gonna make some tests with lower offered data rate and see the network behavior.

BR,

Vicente

[vicente angelo de sousa junior]

Hello Tommaso,

I'm back trying to understand a bit more this issue. I reduced offered traffic load (1e3) and it is still having lost packets, even if the network has only one AP and one STA (with DL and UP Traffic - two UDP flows). Considering, that we have 802.11g (and I'm using AarfWifiManager as the rate adaptation scheme), it is a bit strange result, isn't it?

I also reduced the simulation grid to a 10X10 meters square, set channel to default Yans and set ON-OFF traffic to 50% (ON)/ 50% (OFF), but I'm still getting of about 50% of Packet Loss Ratio for a simulation of 200s.

Do you give me any suggestion to explain the reason I have a clogged network with this configuration and so low offered CBR traffic? I have not undestand why, in this situation, the packets have been recorded as sent, but it never reached its final destination.

Do you suggest to abandon Flowmonitor and get metrics at MAC layer (Tput, Delay, etc)? Do you have any hint how to do this?

Does anybody else help me? I wonder if I am configuring or understand anything wrong (my script could be found in my first message).

Thanks in advance,

Vicente Sousa

[Tommaso Pecorella]

Hi,

short answer (not much time today).

Without the script I can't say anything. However, if the packets are lost there's a reason.
FlowMonitor Vs MAC level measures: it has been discussed before AND it is in the manual...

Have fun,

T.

[Saurabh Sharma]

Hi, Tommaso i want to know that what did you mean by- no stats are really meaningful when your network is congested.

[Divyasheel]

Hi,
I am using flow-monitor to determine the Rx packets for each flow in a dumbell topology to further find the Throughput of the flow. 
Using the Rx tracesource on the destination nodes seems to give inaccurate results.
I am using these results to study congestion in BBR vs other loss bases CCAs. 

"Keep in mind that FlowMonitor isn't really meant to be used in a congested network, as... well, no stats are really meaningful when your network is congested."

But now I found this comment mentioning that flow-monitor is not supposed to be used in a congested network? Is that really problematic and if so what could be the workaround? ( other trace sourcing Rx on the nodes ).

[Tommaso Pecorella]

BLAST FROM THE PAST !!!

I love when zombies are resurrected, but it's Easter, so it's kinda expected. 9 yeas is a quite long time tho....

FlowMonitor and congested networks are not a real issue, it's an issue when people are dumb as a pile of rocks and forget to include in their statistics the packets that are in-flight and (maybe) in the queues of intermediate nodes.

Of course if the network is congested (by definition) the packet delay is a non-stationary statistic, so it doesn't make sense to get numbers and think they're meaningful.

Said that, Dumbbell topology -> you have an intermediate router.

Hence, packets can be dropped by the intermediate router.

FlowMonitor will consider these as well, the end node Rx doesn't (of course).