[Ns-developers] packet tags

[Mathieu Lacage]

Hi all,

A couple of weeks before release 3.1, we eventually got to rewrite the
tag support in ns-3 packets and, it turns out that the result is still
not exactly what everyone expected so, this email is an attempt to
summarize what use-cases I think ns-3 should solve. I have also included
a couple of possible solutions but, just to be clear, none of these make
me especially happy so, this is really an open question I think.

1) Use cases
-------------

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.

Examples of a) are:
  - a QoS class id to make sure that some packets end up in the right
outgoing queues at the wifi layer (AC_BE vs AC_VO, etc.). This is a sort
of cross-layer signaling scheme where the application notifies the MAC
layer of a per-packet information and where you don't want to plumb the
extra per-packet information throughout every function in the stack.

  - the source ipv4 address of a packet received: as a packet goes up
the stack, higher layers of the code need to have access to different
values coming from lower layers. There are cases where it is easier to
pass these values explicitely in every function call and propagate them
but there are also cases where it is really damn convenient to store
them in the incoming packet instead.

Examples of b) are:
  - a flow id which allows you to figure out which application generated
a specific packet anywhere the packet ends up being.
  - a timestamp which allows you to figure out when the packet went
through a specific location in the system (for example, when it was
generated at the application layer).

In the case of a), it is possible that, if the packet is forwarded
across multiple nodes, it will have different values for the same 'tag'
over its course in each node. In the case of b) the value stored in the
'tag' is immutable and will never change once set until the packet is
destroyed.

To summrize, in the case of a), you most likely want to cleanup all tags
before forwarding the packet across node boundaries. In the case of b),
you never want to do this.

2) What can we do about this ?
------------------------------

It is now clear to me that we have two conflicting use-cases so, I have
a hard time figuring out how to support both within the same framework.
Right now, I would say that we need two different 'tags' facilities so,
the only question is, how do we provide them ?

a) Add a second tagging system to packets
-----------------------------------------

We could do that and support Packet::AddTemporaryTag and
Packet::AddForeverTag.

b) define a second tagging system outside of packets
----------------------------------------------------

We could also define a TemporaryTags class and store arbitrary data in
it and, pass this class up and down the stack together with every
packet. 

Pros: it is trivial to 'cleanup' the tags when you cross a node
boundary: you don't propagate the associated TemporaryTags class.

Cons: changes the whole stack because we need to add an extra argument
to every function which takes a Packet.

At this point, I can't make myself like any solution so, comments would
be welcome.

regards,
Mathieu