Bug 1302

Summary:	Flow monitor bug
Product:	ns-3	Reporter:	Gustavo J. A. M. Carneiro <gjcarneiro>
Component:	flow-monitor	Assignee:	Gustavo J. A. M. Carneiro <gjcarneiro>
Status:	RESOLVED FIXED
Severity:	normal	CC:	ns-bugs, tommaso.pecorella
Priority:	P5
Version:	ns-3-dev
Hardware:	All
OS:	All
Attachments:	test program from Mauro Vidotto test program from Mauro Vidotto, updated to ns-3-dev API

Description Gustavo J. A. M. Carneiro 2011-11-22 07:23:17 UTC

Created attachment 1274 [details]
test program from Mauro Vidotto

See
https://groups.google.com/d/topic/ns-3-users/U_MnZRioG60/discussion



No idea if it is a bug or not... i could see that in my case this error produces when an ARP package is dropped at some intermediate node because of the droptail queue policy.

Comment 1 Gustavo J. A. M. Carneiro 2011-11-23 05:42:06 UTC

./waf --run "scratch/sbs4.test --tcpModel=ns3::TcpNewReno --nCsma=10"

Comment 2 Tommaso Pecorella 2012-02-07 18:50:18 UTC

My best bet is:

ARP isn't IP-encapsulated (baaaad ARP, BAD!), so it isn't tagged by FlowMon.
On the other hand when it's dropped the packet IS sent to FlowMon to be analyzed. Thus FlowMon Complains.

Fix for this: don't loose ARPs.

Seriously, I know Gustavo is working on it, so I'll leave him the burden to find a good design fix. My "n00b" fix would be:
+ you got a dropped packet? Check if it's an ARP. If it is, then who cares, else try to find the tag.

Cheers,

T.

Comment 3 Gustavo J. A. M. Carneiro 2012-02-08 04:17:34 UTC

I am not working on it, unfortunately, I haven't had time lately :-(
But it doesn't sound complicated to fix, now that we have a simple way to reproduce it.

Comment 4 Gustavo J. A. M. Carneiro 2012-02-08 04:46:50 UTC

Created attachment 1330 [details]
test program from Mauro Vidotto, updated to ns-3-dev API

Comment 5 Gustavo J. A. M. Carneiro 2012-02-08 04:58:39 UTC

This code path was introduced by bug 854.

Comment 6 Gustavo J. A. M. Carneiro 2012-02-08 05:07:20 UTC

I think the problem is simply that the Flow Monitor is assuming that all queue drops are for packets that passed through the IP stack before, and are all IP packets.  However, this is a wrong assumption, a L2 device can receive non-IP packets, and these can be dropped.

We can use the presence (or not) Ipv4FlowProbeTag itself to decide whether this is an IP packet or not.  If the tag is missing, ignore it, don't abort.

Comment 7 Gustavo J. A. M. Carneiro 2012-02-08 05:13:13 UTC

And, yes, I am to blame for this, since I asked for the assert.  I just didn't think it through.


changeset:   7703:a982d8c7aa32
tag:         tip
user:        Gustavo J. A. M. Carneiro  <gjc@inescporto.pt>
date:        Wed Feb 08 11:12:17 2012 +0100
summary:     Bug 1302 - Flow monitor bug