Bug 1844

DSR is an IP-level routing protocol. FlowMonitor doesn't track it for two reasons:
1) FlowMonitor doesn't track multicast packets (and DSR uses broadcast addresses), and
2) DSR packets aren't UDP or TCP (FlowMonitor only tracks L4 protocols).

So, an empty report is pretty much normal.

I'd close this bug as "Invalid".

If you want we can open another bug (enhancement level) to track that it would be nice to track multicast and IP-level traffic (maybe dividing it according to the protocol).

The difficulty might be to find appropriate statistic for those kind of traffic, as some of the actually tracked ones have little or no sense at all for multicast/broadcast messages.

(In reply to Tommaso Pecorella from comment #1)
> DSR is an IP-level routing protocol. FlowMonitor doesn't track it for two
> reasons:
> 1) FlowMonitor doesn't track multicast packets (and DSR uses broadcast
> addresses), and

As you said, FlowMonitor does not track multicast, but DSR is broadcast, which FlowMonitor DOES track (e.g. the HELLO messages from OLSR).

> 2) DSR packets aren't UDP or TCP (FlowMonitor only tracks L4 protocols).
> 

DSR is derived from the IpL4Protocol, thus is a L4 protocol. So, it should be tracked.

> So, an empty report is pretty much normal.
> 

I do not want to track the packets generated within DSR, but the UDP traffic on top of that.

> I'd close this bug as "Invalid".
> 
> If you want we can open another bug (enhancement level) to track that it
> would be nice to track multicast and IP-level traffic (maybe dividing it
> according to the protocol).

This bug was opened as enhancement but I still do not know, is it the FlowMonitor that should be "enhanced" or we need to re-think the DSR implementation?

> 
> The difficulty might be to find appropriate statistic for those kind of
> traffic, as some of the actually tracked ones have little or no sense at all
> for multicast/broadcast messages.

After checking twice the code, I have an even better explanation about why the traffic is not tracked.

Dsr is a *shim* protocol between UDP/TCP and IP. Actually it encapsulates the L4 traffic in its own packet. Or, if you like more the idea, it's adding its headers between IP and UDP/TCP.

FlowMonitor is not able to understand this, and packets are not tracked. Simple as this.

A way to fix this would be to mark the packets at UDP/TCP level and not at IP level, which is a bit more complex than one might think.

On the other hand, we could do it with the actual tag system, but I'll have to think about it.

Still, there's the issue of multicast packets, which might be a blocker.

(In reply to Konstantinos Katsaros from comment #2)
> (In reply to Tommaso Pecorella from comment #1)
> > DSR is an IP-level routing protocol. FlowMonitor doesn't track it for two
> > reasons:
> > 1) FlowMonitor doesn't track multicast packets (and DSR uses broadcast
> > addresses), and

Aaaaand… you found a bug :P

  if (ipHeader.GetDestination () == Ipv4Address::GetBroadcast ())
    {
      // we are not prepared to handle broadcast yet
      return false;
    }

But "GetBroadcast" is 255.255.255.255, which is a bit too broadcast. The correct thing would had be "broadcast in the local network". Which is different.

I'll have to think (again) what's the problem with broadcasts and if we can remove this (useless) check. I.e., why Gustavo didn't want to track broadcasts.

Hi.

Flow Monitor is not designed to handle point-to-multipoint flows.  If it tried to do it, statistics would get all wrong.  The same packet is transmitted once but received N times, with N <= number of receivers.  What does it even mean?  Tracking of lost packets would be completely inaccurate (e.g., if you don't know beforehand all the receivers, how do you find out whether a packet was lost or not?), and not sure what it means in this context.

Multicast and broadcast are a lot more complicated and require a lot of explanation of what each metric would mean in this context.  Flow Monitor was not designed for this.  It's better to do less things and do them well than to design a system that can do lots of things but also becomes very complex to write and maintain.

For my own research, I also had my own routing protocol and I simply designed a separate system for measuring the routing protocol overhead in each node.  It's not too hard, I think.

(In reply to Tommaso Pecorella from comment #3)
> After checking twice the code, I have an even better explanation about why
> the traffic is not tracked.
> 
> Dsr is a *shim* protocol between UDP/TCP and IP. Actually it encapsulates
> the L4 traffic in its own packet. Or, if you like more the idea, it's adding
> its headers between IP and UDP/TCP.
> 
> FlowMonitor is not able to understand this, and packets are not tracked.
> Simple as this.

And why can't it understand it? If the DSR header is between TCP/UDP and IP, then it should be able to. FlowMonitor traces Ipv4 packets, i.e. those with IPv4 header, right?


(In reply to Gustavo J. A. M. Carneiro from comment #5)

I do not think that DSR is a point-to-multipoint at least for the actual data. The route discovery is broadcast, but the data is unicast. The bug I have reported here is that FlowMonitor can't trace those packets. So, perhaps only for DSR we should mark them within DSR if possible, but without the IP header it might be a challenge.

(In reply to Konstantinos Katsaros from comment #6)
> (In reply to Tommaso Pecorella from comment #3)
> > After checking twice the code, I have an even better explanation about why
> > the traffic is not tracked.
> > 
> > Dsr is a *shim* protocol between UDP/TCP and IP. Actually it encapsulates
> > the L4 traffic in its own packet. Or, if you like more the idea, it's adding
> > its headers between IP and UDP/TCP.
> > 
> > FlowMonitor is not able to understand this, and packets are not tracked.
> > Simple as this.
> 
> And why can't it understand it? If the DSR header is between TCP/UDP and IP,
> then it should be able to. FlowMonitor traces Ipv4 packets, i.e. those with
> IPv4 header, right?

Easy. FlowMonitor picks the packet at the IPv4's SendOutgoing trace. In that point the "next" header is DSR, not UDP. So the packet is automatically marked as not interesting. In order to see that it's a real UDP packet, one should check the DSR header as well, but that would introduce a dependency between FlowMonitor and DSR, which is not good.

 
> (In reply to Gustavo J. A. M. Carneiro from comment #5)
> 
> I do not think that DSR is a point-to-multipoint at least for the actual
> data. The route discovery is broadcast, but the data is unicast. The bug I
> have reported here is that FlowMonitor can't trace those packets. So,
> perhaps only for DSR we should mark them within DSR if possible, but without
> the IP header it might be a challenge.

Maybe you're right, but the above point makes it hard to track the data-carrying packets. Moreover, the final destination is substituted in the IP header by the next hop one, so the classification should be done in a completely different way.

For the record, the IPv4 (and IPv6) probes skip *any* packet whose next header is not UDP or TCP. So the same issue might arise with IPv6 packets carrying extension headers.

In order to fix this in the "right" way, one should make a new FlowProbe and FlowClassifier for DSR, and have it handle this. It would probably require some additions in DSR as well, to have the right traces.
Moreover, the script would have to be modified in order to automatically detect if the dar module is compiled (we can not take it for granted).

In order to make a probe for DSR, one should define the following traces in DSR:
    .AddTraceSource ("SendOutgoing", "A newly-generated packet by this node is about to be queued for transmission",
                     MakeTraceSourceAccessor (&Ipv4L3Protocol::m_sendOutgoingTrace))
    .AddTraceSource ("UnicastForward", "A unicast IPv4 packet was received by this node and is being forwarded to another node",
                     MakeTraceSourceAccessor (&Ipv4L3Protocol::m_unicastForwardTrace))
    .AddTraceSource ("LocalDeliver", "An IPv4 packet was received by/for this node, and it is being forward up the stack",
                     MakeTraceSourceAccessor (&Ipv4L3Protocol::m_localDeliverTrace))

and use them in the very same way as Ipv4L3Protocol.

Plus, one should define a new Probe/Classifier.

Last but not least, the script should be modified to compile the DSR probe/classifier only if the DSR module has been built. rd-net-device might be used as a reference (probably). This to not introduce an unwanted DSR dependency on FlowMonitor.

Not an impossible task, overall.

T.