INET 4.4.1, flow measurement, help in understanding the output in case of headers add/remove

[LucaC]

Hi guys.

I'm here once again to seek help in understanding how the INET's flow measurement works, specifically when headers are added/removed to packets. I'm on INET 4.4.1 & OMNeT++ 6.0.

I prepared an example project, attached. The network is as per the snippet below:

Each flowOut module is a FlowMeasurement, configured to measure the bitElapsedTimePerRegion. Moreover (have a look at the omnetpp.ini) they are configured so that they process only one flow (for instance, *.appFlowOut.bitElapsedTimePerRegion.demuxFlow.flowName = "app").

The hdrAEncapsulator and hdrADecapsulator modules add and remove an header (defined as HeaderA) to the packet. Same is for hdrB* modules, except that they add/remove an header (HeaderB) and a trailer (TrailerB) too.

Each delay block delays packets of 1s.

Well, let's focus on the hdrBFlowOut flow measurement module. I was expecting that it generates 4 same-value entries for each packet, that is to say the elapsed time (of 1s) for the 4 regions I was supposing in the packet -- 1 for the packet generated by the source, 1 for the header A, 1 for the header B and 1 for the trailer B. Instead I found in the vec file 7 entries; and the most serious part is that one of these entries has a different value, and I don't know why. Here's a snippet:

0    2    2    1    <--- these (1) are ok (1s is the delay of the d2 block)
0    2    2    1
0    2    2    2    <--- what's this??
0    2    2    1
0    2    2    1
0    2    2    1
0    2    2    1

This single value completely messes up the statistics I gather. In fact, it affects even the meanBitElapsedTimePerPacket, in case I turn to it.  (you can play with the attached project).

So I need help. What the "spurious" value is? In general, is this the INET programmers' desired behavior? In case, how can I cope with it? This output is useless to me, sadly. And sorry for the very long mail...

Thank you. Regards,

Luca

[Levente Mészáros]

I'd take a look at this but I'm on holiday right now and I won't be back for two weeks. My guess for the 2 value in the output is that the flow is somehow not filtered and there's one region that goes through both delays.

Regards,

levy

--
You received this message because you are subscribed to the Google Groups "OMNeT++ Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to omnetpp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/omnetpp/c5123861-13d1-461d-9925-7b3e6a3ca612n%40googlegroups.com.

[LucaC]

Hi Levy,

thank you. I'll wait for you to get back, enjoy your holidays.

Bye

Luca

[Levente Mészáros]

Hi Luca,

I don't see the results you are seeing.

The packets at hdrBFlowOut are 124B long. There are two 4B headers, one 100B data, and one 16B trailer in the packet. There are 3 region ElapsedTimeTags attached to the packet. The two headers are represented with one region tag. This is allowed because the attached data is the same. You can see the offsets below, the data is 1s everywhere.

As for the statistical results, three values are recorded at t=2s in hdrBFlowOut for bitElapsedTimePerRegion. Each record value is 1, and each one belongs to one region as described above.

This was tested with the current INET master branch. Which version are you using? Or am I missing something?

Best regards,

levy

[LucaC]

Hi Levy.

No good :( that the same simulation produces different results on your and my setup...

Likely (hopefully) it's something on my side I can easily fix.

I'm using INET 4.4.1 tag. And (I didn't think it was relevant) OMNeT++ 6.0 RC (2 if I remember well).

Do you think I've to update either of these?

Thank you, bye

Luca

[Levente Mészáros]

Apparently the INET 4.4.1 version doesn't contain the flow measurement fixes that were made after your other bug report.

You should use the master branch instead of v4.4.1.

Best regards,

levy

To view this discussion on the web visit https://groups.google.com/d/msgid/omnetpp/4e8c0893-4c14-4e3a-82fe-b2982358e69bn%40googlegroups.com.

[LucaC]

Ouch! In fact I see now (I didn't fetch yet) that two more commits (already in the master) have been added to the v4.4.x branch, one of it I suspect is the one fixing the flow measurement.

Ok, gonna move to the master and try.

Bye

Luca