Chunk::addTag() problem when updating chunk length

[edlongman]

Problem

The chunkLength is the default used to set the length of the RegionTag in the region tag set, even though the length is not that meaningful.

When findTag is used after the chunk length has changed, the old chunk length persists and throws an error from getTagIndex. because of the following check. https://github.com/inet-framework/inet/blob/3b64766f17a25193519d44cf20a039e68baa94b7/src/inet/common/packet/tag/RegionTagSet.cc#L104

Since the length of the region tag set is stored separately anyway, does this really do anything useful or have I completely misunderstood what I am doing with RegionTags?

Reproducing problem

1. Create chunk with TlvOptions like Ipv4Header
2. Add regionTag to Header (like CreationTimeTag) using Chunk::addTag()
3. Add TlvOption
4. setChunkLength( calculateHeaderByteLength() )
5. Add another region tag to Header using Chunk::addTag() - Causes error <!> Overlapping tag is present -- in module (RegionTagErrorModule) ErrorNetwork.regionTagErrorModule (id=2), during network initialization

Minimal example

RegionTagErrorModule.cc

using namespace inet;

class RegionTagErrorModule : public omnetpp::cSimpleModule
{
    void initialize() override{
        auto header = makeShared<Ipv4Header>();
        auto regiontag = header->addTag<CreationTimeTag>();
        auto option = new Ipv4OptionRouterAlert();
        header->addOption(option);
        header->setChunkLength( header->calculateHeaderByteLength() );
        header->addTag<HopLimitInd>();

        // Cleanup
        delete option;
    }
};

Define_Module(RegionTagErrorModule);

ErrorNetwork.ned

simple RegionTagErrorModule
{
    @class(RegionTagErrorModule);
}

network ErrorNetwork
{
    submodules:
        regionTagErrorModule: RegionTagErrorModule;
}

[levy]

Region tags are attached to a specific region of a chunk. For example, a BytesChunk that is 100 bytes long can have a region tag attached to the first 50 bytes. When later the chunk length is increased to 150 bytes, the attached region tag is expected to stay where it is (i.e. 0 -> 50 bytes) because in general it's unknown what the tag actually means and whether it is meaningful to extend it automatically to the updated chunk length. It is up the user to update the region tag offsets/lengths in such a case. In your example it would be better to attach the region tag after the chunk has been extended, but of course your real example may be more complicated than that.

[edlongman]

As you guessed, my real example is much more complicated than that!

I am using it following the use of region tags for CreationTimeTag, which is used for statistics calculation since it is not stripped when passed between nodes. I have a made a custom tag that I add to the network later header that records the energy consumed by each node and associates it with that packet. It always felt like a bit of a nasty trick though, and I understand better now why.

For the mean time I have explicitly specified the offset and length arguments for addTag but if there is a better way to pass information that is not strictly part of headers and only for statistics through the simulation I'd love to use it!

[levy]

The way you are using region tags is exactly why the region tags are there. Actually using a region tag that specifies what is the average energy consumed per bit is the right way to do it because, for example, a packet can be fragmented and some fragments may go on a different path than others, but later on may be merged again, the end result being that the bits ultimately ending up with a different energy consumption. Remember that region tags are attached to individual bits (but optimized for regions to reduce memory consumption) as opposed to normal tags which are attached to the packet as a whole.

The reason that normal tags are deleted is that we don't want to accidentally reuse some tags from one node to another. In fact, we could let them through, this is just a protection against programming errors. We may remove this limitation in the future, we simply didn't see the need for it.

[levy]

I want to add that region tags can also be attached to packets instead of chunks. These two are not the same because chunks can be shared between multiple packets. It all depends on what you are planning to use the tags for. For example, the IdentityTag is attached as a region tag to chunks. This tag allows tracking the identity of individual bits along the network, that is whenever a module sees a chunk it can simply identify the bits (regions) of the data using that tag. For example, this could be used in sophisticated path visualizer which is able to follow fragmentation/aggregation throughout the network without actually knowing what the protocols are really doing.

[edlongman]

Thanks, that's really helpful. I currently attach the Region Tag to the Network header post-fragmentation although I realize now it would probably make more sense to attach the tag to the payload of the network packet, since this is what it logically corresponds to.

What you've written up above it would be really helpful to have in the class file or documentation somewhere.

I do agree about generally removing tags when the data is transmitted in a fundamental form though, since this is the reality of any physical implementation!

[levy]

I checked the documentation and added some more to what was already there.