Bugzilla – Bug 1845
FlowMonitor should discard any broadcast/multicast packet
Last modified: 2014-03-17 14:58:06 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).
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.
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.
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.
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.
Created attachment 1773 [details] new patch Oooops… forgot to update the mercurial queue before sending.
+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
changeset 10670 d04c750525d7