[Ns-developers] packet tags

[Tom Henderson]

Mathieu Lacage wrote:
> 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.
> 

I'd like to summarize some discussion that Craig, Mathieu, and I had 
yesterday about the tag design.

- we agreed that we have at least two general use cases or scopes for 
tags:  i) cross-layer traversal within a node only, and ii) end-to-end. 
  Craig pointed out that one can come up with a finer granularity of use 
cases than just two, and this was agreed, but we think that these two 
types of scope are probably sufficient to cover most cases and will keep 
the implementation and usage simpler if we restrict it to these two.

- we discussed bringing two tagging systems to cover these two cases. 
Options included resurrecting the old system (which tagged packets, not 
bytes) and using it for cross-layer cases, or using two instances of the 
existing implementation and API.  For consistency, we agreed on the latter.

- for local tags, they can be stripped when a packet leaves a node, such 
as when it is passed to a Channel.  For end-to-end tags, they are never 
stripped until the packet is freed.

- if packets never are stripped of their end-to-end tags, receivers of a 
particular tag are going to have to iterate the tag list if there is a 
possibility that more than one tag of the same type is stored in the 
packet.  Tags will have to store whatever context is necessary for 
readers of the tag to disambiguate them when multiple tags can be appended.

- we could have two separate but related APIs (e.g. AddLocalTag(const 
Tag &tag) and AddE2ETag (const Tag &tag), or could have a single API 
with a scope argument and have, underlying this, two tag lists.  We 
favored keeping the existing API and just adding a scope argument, such 
as AddTag (const Tag &tag, enum Tag::Scope scope).  Note that this will 
break the current API.

Although we didn't discuss this in depth, I believe that the API changes 
proposed are basically to add a scope argument to AddTag(), PrintTags(), 
GetTagIterator(), FindFirstMatchingTag(), and RemoveAllTags().

Mathieu agreed to implement these changes sometime in the next two or 
three weeks.

Tom