DSR and FlowMonitor

[Vod]

Dear all,
I am using ns3.19, some of nodes and a sink node, i am using also the DSR routing protocol,

however i want to use the FlowMonitor in my script, when i use it, it does'n show me any thing, when i change the protocole such as AODV or DSDV, it show me the statistics that i want,

Can u help me,

Thank you for your replies.

[Konstantinos]

It is a known issue with DSR reported in https://www.nsnam.org/bugzilla/show_bug.cgi?id=1844 due to the implementation of DSR.

So, you need to use a different method to capture statistics, e.g. statistics module.

[Tommaso Pecorella]

Hi,

I have a good news and a bad news.

The bad news is that DSR can't be tracked by FlowMonitor

The good news is that AODV (dunno about DSDR, maybe that one too) will not be tracked anymore by FlowMonitor starting from 3.20.

The reason for this is not that I'm evil. Well, I may be a little evil, but that's not the reason for removing this "feature". The problem is: the "feature" was a bug.

AODV uses boadcast packets to carry data packets. As a consequence, FlowMonitor can not reliably collect any statistic. FlowMonitor was never meant to measure broadcast packets, and this has been fixed. The drawback is that AODV will not be traced anymore.

About DSR, the reason is slightly different.

FlowMonitor requires either UDP or TCP. DSR adds a DSR header to IP packets between IP and L4 (TCP and UDP). As a consequence, FlowMonitor can not recognize the L4 header and can not collect stats.

Sorry...

T.

[Vod]

Hi,

Thank you very much for your replies,
Ok so statistics module is the good way to calculate the statistics ?
i will be obliged to use statistics module, do you have some advices or sources code or tutorial for this ?

Thank you.

[Tommaso Pecorella]

Hi,

I'd say that the stats module is the right choice.

The manual can help you on using it: http://www.nsnam.org/docs/manual/html/data-collection.html

Cheers,

T.

[Vod]

Ok,
Thank you i will use it then;

Respect.

[Scott Carpenter]

I have a question / comment on this.  I was already aware of the DSR issue with Flowmon.  But now with AODV "fix" due to broadcast issue, this leaves me wondering about a consistent way to capture routing performance metrics (i.e. routing stats).  So, if the stats module is the right solution and can correctly capture ALL routing stats for all routing protocols, then is there a suggestion on how to go about implementing a "routing stats" type of class?  That is, what I would really like is a simple-to-use-flowmon-like-API that allows me to easily and consistently collect stats for ANY routing protocol.  The question seems to come up on a routing protocol by protocol basis, and we could benefit from a single, consistent solution.

As one example, in wireless broadcast packets, I want to know the packet delivery ratio (PDR).  Would be nice to consistently and correctly calculate that, too.

Thoughts or suggestions?

Thx.

[Konstantinos]

Hi Scott,

Delivery Ratio for broadcast packets is quite difficult to calculate because it is difficult to define. 

One possible definition could be #ofRx/#ofExpectedRx

where #ofRx can be easily be counted from trace sources but #ofExpectedRx has to take into consideration the mobility (position of nodes) and propagation. You could simply assume unit-circle com. range, and estimate beforehand the number of 'neighbors' (nodes within the com. range) each node could have every second. So that could give you the expected Rx (all neighbors should be able to receive it.

However, for routing-stats you usually care about overhead, which is the total number of Tx routing packets or ratio of routing/data (either in # packets or bytes).
This can be calculated with statistics module.

[Tommaso Pecorella]

Hi,

this is a very valid point. The problem is: define a metric to measure.

As an example, the PDR for broadcast packets is not so simple to define (what's the number of nodes that should had received the packet?). In a wired network is easy. In a wireless network it isn't. If the packet is lost, it's the routing or the channel ?

Another example. Some routing protocols avoid duplicate packets, while others have them consistently (e.g., flooding, but also others). What shall we do with duplicates ?

As a consequence, the first question is: what should we measure ?

The problem isn't to code something, it's to code something general enough to be useful.

One could, of course, hook FlowMonitor to the L4 socket and have L4 stats (minus the intermediate hops data). However also this isn't as easy as one may think. As an example:

1) UDP - how do we decide if a packet is a duplicate ?

2) TCP - a packet sent may be received in two segments...

Note that this aren't just special cases. UDP - you loose one packet and you receive one twice. If you don't count the duplicates you'll think you have a 100% PDR ... 

Anyway, when we'll find a good metric to measure, I'm up to coding any solution.

Cheers,

T.

[Scott Carpenter]

I am confused on how to best get routing stats.

Let's take routing throughput as an example.  Specifically, goodput, or total successfully routed data (bytes) / time.  Let's consider manet-routing-compare.  That is heavily cited and used, and should, in fact allow us to compare routing performance, like goodput.  Flowmon code is conveniently commented out in that example.  DSR and soon AODV and maybe even DSDV should not be using flowmon for stats. 

Now, there exists in the Wifi code Athstats (helper provided, thank you) and also the stats package.  So, what would be the right way to capture "routing goodput".  Do I count /Mac/MacRx or maybe /Phy/State/RxOk?  It seems this is going to count ALL packets including routing protocol overhead (at MAC or PHY layer).  Maybe that is okay, maybe not.  Strictly speaking, I would prefer to exclude routing overhead from application data, but I'm not sure if Athstats or stats allows me to so easily differentiate.

I'd like to use Athstats if possible, but as documented, does not calculate cumulative stats.  Are there examples on how to do this (easily - sorry, I know I am not asking multiple questions in one post).

thx.

[Konstantinos]

If you want to look at goodput, you simply need to look what is delivered to the application, i.e. PacketSink (or similar). 

There is a trace source Rx at PacketSink application that is triggered upon reception. That can give you goodput.

AthStat, Mac and PHY are not goodput. They have all packets from routing overhead, TCP ACKs etc.

So, using stats module, you can record incoming and outgoing packets from the applications (both sink and source applications provide respective traces) and hence calculate your stats (goodput, delay, jitter etc). In addition, you can even calculate overhead (routing or any other) by hooking the corresponding traces. For example a trace when a RREQ or a HELLO is broadcasted.

[Sidoine Samo Djossi]

Greeting Sir. Please I would like to have a script in which one use the stat module to calculate the throughput, the end-to-end delay and the packet delivery ratio. Thanks in advance.

S.

[Sidoine Samo Djossi]

Please Vod did you succeed in calculating the throughput, PDF and end-to-end delay with the statistic module? I need your help. Thanks in advance

S.