packetLifeTime silently reports NaN for every reassembled packet

[torokati44]

Type: bug
Component: src/inet/common/ResultFilters.cc, src/inet/protocolelement/fragmentation
Version: INET 4.7.0 (dfe270b21f, 2026-07-07)

The problem

PacketLifeTimeFilter::receiveSignal() (ResultFilters.cc:663) reports a value only when there is exactly one CreationTimeTag region:

int count = 0;
simtime_t lifeTime = -1;
for (auto& region : packet->peekData()->getAllTags<CreationTimeTag>()) {
    lifeTime = simTime() - region.getTag()->getCreationTime();
    count++;
}
fire(this, t, count == 1 ? lifeTime.dbl() : NaN, details != nullptr ? details : object);

Reassembly produces one region per fragment. DefragmenterBase.cc:36 does

defragmentedPacket->insertAtBack(fragmentPacket->peekData());

and chunk region tags ride along on peek() / insertAtBack() by design, so a packet reassembled from k fragments carries k CreationTimeTag regions - all holding the same creation time, since the packet was tagged once before it was cut. What multiplies is the number of regions, not the number of values.

The filter then fires NaN.

Impact

The packet drops out of the mean, the maximum and the histogram with no warning. Every packet that was fragmented disappears from the end-to-end delay statistic; every packet small enough to travel whole stays. The result is a delay statistic computed over a biased subset - the small packets - which looks entirely plausible and is wrong.

Reproduction

Any configuration running traffic through FragmentNumberHeaderBasedFragmenter / ...Defragmenter with packetLifeTime recorded at the sink: reassembled packets contribute NaN, unfragmented ones contribute values.

Suggested fix

In preference order:

1. Merge on reassembly. In DefragmenterBase, once the packet is complete, collapse each region tag type spanning the reassembled data into a single region. Semantically the right place - a reassembled packet is one region again - and it fixes every consumer, not just this filter.
2. Make the filter tolerant. Report the value when all regions agree on the creation time, NaN only when they genuinely differ. Cheap, but leaves the k-region representation for other consumers to trip over.
3. At minimum, make it loud. If NaN stays, warn the first time a packet is dropped from the statistic for this reason. The silence is what makes the bias dangerous.

lifeTimePerRegion (ResultFilters.cc:682) already handles multiple regions, but it answers a different question - per-region delay rather than one value per packet - so it is not a substitute here.

Workaround until then: before the sink, replace the k regions with a single one covering the whole data range, keeping the first tag's value.