[Ns-developers] packet tags

[Mathieu Lacage]

On Thu, 2008-07-10 at 14:37 -0400, Joseph Kopena wrote:
> On Thu, Jul 10, 2008 at 1:24 PM, Mathieu Lacage
> <mathieu.lacage at sophia.inria.fr> wrote:
> > There are really two conflicting major use-cases for packet tags:
> >   a) temporary ancillary data attached to packets as they flow up and
> > down the stack.
> >   b) long-term metadata attached to a packet as it travels through a
> > simulation and crosses multiple nodes.
>
> Would you (or someone) elaborate on what is mutually exclusive about
> these two cases?  It's not obvious to me why/how they conflict.

You really want to rip out the data associated to a) when you cross a
node boundary (typically in a channel) but you don't want to do it for
the data associated to b).

Now, if the question is, why would you want to rip out the data
associated to a), the answer is that, each node the packet goes through
is likely to want to set the same set of tags (a) on the packet so, you
need to either make it a non-error to set twice the same tag on the
packet, or you must allow setting the tag on the packet only once. If
you allow setting the same tag on the same packet multiple times, you
must also specify a policy for reading the tag from the packet: when the
tag has been set multiple times, which one is the one you really want ? 

We have had some discussions that the one you want might very well be
the last one you set of the requested type (which would be exactly what
the method Packet::FindLastMatchingTag would do, as opposed to
Packet::FindFirstMatchingTag). The testcase which started this
discussion was bug 231:
http://www.nsnam.org/bugzilla/show_bug.cgi?id=231

In the end, though, FindLastMatchingTag feels like a hack so, I have to
confess, that it seems to be more pain than it is worth to keep track of
all the "duplicate" tags set as your packet travels across multiple
stacks, hence, potentially, the need to simply separate the two types of
tags in two separate lists, one which would be easy to rip out entirely
and which would refuse duplicate tags and would be used to tag packets,
and not the bytes within the packet, and the other one which would be
long lived, could not be ripped out, would be used to tag bytes, not
packets.

regards,
Mathieu