INET, queueing, Flow Measurement usage in case of packets aggregation

[LucaC]

Hi all.

I'm facing issues in making the INET's Flow Measurement work in a network where packets are "manipulated".

More in details, I've a compound module defined as follows (simplified version, I have issues here too):

• Input gate where packets are received
• A Flow Measurement Starter module, tagging the entire packet.
• A simple module taking and sending packets. For each packet (original_packet):
  • it strips an header ( original_packet->popAtFront<>() ), 
  • puts a new header in front ( original_packet->insertAtFront() )
  • copies the whole packet's data into a new packet ( new_packet->insertAtBack(original_packet->peekData()) ).
• A Flow Measurement Recorder module, with the same flow name as the Starter.
• The output gate.

Well, the Recorder doesn't record anything. I understood from the INET's user guide that Flow Measurement's tagging is done on the data carried by packets, so I was expecting that is should work in my case. But it's not.

Any help please?

Thank you. Regards

Luca

[Levente Mészáros]

Could you please provide the code for the small example to reproduce the problem?

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/17a329f4-37b3-4a0c-a074-e06f8d64485dn%40googlegroups.com.

[LucaC]

Hi Levy,

thank you for your support.

Here it is a simple project, look at the PacketManipulator::pushPacket().

You'll see that I commented most of the lines manipulating the packet. Now the procedure just allocates a new packet, copies the data from the old to the new, and than forwards the new. Even in this really simple situation, the Flow Recorder doesn't record anything.

I'm wondering what I'm doing wrong.

Thank you

Luca

[Levente Mészáros]

The issue is that you are creating a new packet by copying the data from the old packet. The data chunk brings its own tags with it but the flow tags are attached to the packet and not the underlying data chunks. The reason is that the same chunk can be shared between several packets at different times and places in the network, and since different things can happen with those packets, the representation must support having different data per packet.

So you could either keep the old packet (if that is possible) or copy the packet level region tags from the old packet to the new one. Most INET modules don't create new packets during processing, they just simply change the data structure of the received packet.

I hope this helps.

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/b2af05e4-809b-4e6d-a946-20b3bbfb580an%40googlegroups.com.

[LucaC]

Thank you Levy. I understood differently from the documentation, good to know.

I need to do packets aggregation within a module, so for me not creating new packets isn't an option.

Two questions:

1. You say that most INET modules don't create new packet. What about, for instance, 802.11? It needs to copy data between packets for aggregation purposes. So Flow measurement doesn't work if there's an 802.11 link in between, does it?

2. How can I copy the packet level region tags?

Thank you, bye

Luca

[Levente Mészáros]

You are right that flow measurement doesn't work without copying the region tags from the original packet if aggregation or fragmentation happens. But flow measurement will still work if no such thing happens, even in the 802.11 case. I have just checked the 802.11 aggregation/fragmentation code and there's no handling of region tags. I think this code should be extended with this behavior.

In order to do this yourself, you can call getRegionTags() on the packet and then call copyTags() on the other packet's region tag set with the appropriate offsets and length.

levy

To view this discussion on the web visit https://groups.google.com/d/msgid/omnetpp/92b22d92-34a0-4faa-bf1b-d9485a8d97ebn%40googlegroups.com.

[LucaC]

Thank you Levy. I'm going to try copying tags, seems not too hard.

Bye

Luca

[Levente Mészáros]

I have just pushed a commit to INET master that solves the region tags issue with fragmentation/aggregation. See here https://github.com/inet-framework/inet/commit/13ac2b2a6e859434f2fc0657721951c21a7ee466

Also, there was a fix recently to maintaining packet level region tags.

Could you please check if this solves your issue?

Regards,

levy

To view this discussion on the web visit https://groups.google.com/d/msgid/omnetpp/bb088e75-436c-4257-9797-3422340a7c96n%40googlegroups.com.

[LucaC]

Hi Levy, sorry for my late reply.

Unfortunately I cannot rightly test your commit as I'm not using 80211. 

But indeed my model  does aggregation/deaggregation by its own, so I could match your aggregation-side code with mine. FYI I used the Packet::copyRegionTags() API, which calls the SharingRegionTagSet::copyTags() you use. Here it is my call's pseudo-code:

aggregatePacket->copyRegionTags(

    *packet, 

    packet->getFrontOffset(), 

    aggregatePacket->getTotalLength() - packet->getDataLength());

As far as I could see, your code and mine work the same.

Thank you for the support.

Ciao

Luca