[Ns-developers] packet tags

[George Riley]

Another important consideration of the design for Tags is that they
are "serializable", meaning we can send a packet (with tags) from
one simulator to another in a distributed environment.  I believe Hagen
has been trying to figure out how to make this work, and (I believe  
again)
not had much luck.  So when re-designing, please keep this requirement
in mind.

George

--------------------------------------------------
George Riley
Associate Professor
Georgia Tech
Electrical and Computer Engineering
riley at ece.gatech.edu
404-894-4767
Klaus Advanced Computing Building
Room 3360
266 Ferst Drive
Atlanta, Georgia 30332-0765

ECE4110 Web page:
http://users.ece.gatech.edu/~riley/ece4110/

ECE4112 Web page:
http://users.ece.gatech.edu/~riley/ece4112/







On Jul 10, 2008, at 1:24 PM, Mathieu Lacage wrote:

> 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
>