Bug 1845

Summary:	FlowMonitor should discard any broadcast/multicast packet
Product:	ns-3	Reporter:	Tommaso Pecorella <tommaso.pecorella>
Component:	flow-monitor	Assignee:	Tommaso Pecorella <tommaso.pecorella>
Status:	RESOLVED FIXED
Severity:	minor	CC:	ns-bugs, tomh
Priority:	P5
Version:	ns-3-dev
Hardware:	All
OS:	All
Attachments:	patch new patch

Description Tommaso Pecorella 2014-01-25 06:51:03 UTC

The problem is that, for IPv4, there's no way to know if a an address is a subnet-broadcast or a normal address (dang).

Ipv4L3Protocol knows it since it can access the subnet masks of the node's interfaces, but FlowMonitor only checks the IP address, which leads to unwanted packets being tracked.

One solution is to access the node's interfaces, the other (more intrusive) is to modify the traces to add this information (i.e., if a packet is being sent to some broadcast address).

Comment 1 Tommaso Pecorella 2014-01-25 06:59:35 UTC

An additional comment.

The solution 1, as is to ask Ipv4L3Protocol is the address is a subnet-directed broadcast is extremely simple (only requires one new function in Ipv4L3Protocol). however it's potentially a performance-hungry solution. It would only hit when FlowMonitor is used, tho.

The solution 2, as is to modify the traces, is not impacting performances (Ipv4L3Protocol already do that when sending a packet), BUT it would require an API change.

Opinions needed before I implement either idea.

Comment 2 Tom Henderson 2014-01-25 11:39:31 UTC

What, in general, is the expected behavior for flow monitor handling of non-unicast packets?  Are these also counted as flows and some subset of statistics can be reported, or are they excluded?

Regarding the solutions, performance drawback of 1) could be alleviated by caching.

Comment 3 Tommaso Pecorella 2014-01-25 11:50:01 UTC

The discussion is in in bug #1844. Non-unicast packets are not meant to be considered by FlowMonitor, since the statistics FlowMonitor collects makes no sense for multicast and broadcast packets.

About caching, it makes sense, but I think it would be an overkill. The performance hits are only potential. Only nodes with a lot of interfaces should be really hit.

Comment 4 Tommaso Pecorella 2014-01-26 11:11:58 UTC

Created attachment 1772 [details]
patch

The patch adds a new function (bool Ipv4L3Protocol::IsUnicast (Ipv4Address ad) const), so bindings must be rebuilt.

Anyway, the patch forces FlowMonitor to not classify any non-unicast packet.

Comment 5 Tommaso Pecorella 2014-01-26 11:24:41 UTC

Created attachment 1773 [details]
new patch

Oooops… forgot to update the mercurial queue before sending.

Comment 6 Tom Henderson 2014-03-17 09:14:47 UTC

+1

Would perhaps be useful to also add in documentation somewhere that FlowMonitor applies only to unicast.

I guess this relates to bug 1802 (documentation/fragmentation).

So, since we have only a placeholder to INESC Porto's flow monitor paper at the moment in the model library documentation, I would suggest to add an executive summary above the paper reference such as 

"FlowMonitor is for monitoring packet flows; it originally supports IPv4 and by ns-3.20 was extended for IPv6.  It integrates with pyviz (see example ...).  It doesn't handle multicast or broadcast, and it handles fragmentation as follows ...."  etc.


And also add this URL reference to below the NsTools reference:
http://telecom.inescporto.pt/~gjc/flowmon-presentation.pdf

Comment 7 Tommaso Pecorella 2014-03-17 14:58:06 UTC

changeset 10670	d04c750525d7