[Ns-developers] [ns3] byte-level tags

[Tom Henderson]

>-----Original Message-----
>From: Mathieu Lacage [mailto:mathieu.lacage at sophia.inria.fr]
>Sent: Thursday, April 24, 2008 03:19 PM
>To: 'ns-developers'
>Subject: [Ns-developers] [ns3] byte-level tags
>
>hi,
>
>Bug 166 outlined recently a that one of our "features" was going to be a
>problem for stream-based sockets. Namely, tags, which are currently
>attached to packets do not work very well when you start slicing the
>packets and re-aggregating them (which is bound to happen when you use a
>stream-based protocol). A followup discussion on irc with joe and raj
>showed that a possible solution would be to make Packet::AddTag tag
>bytes within a packet, rather than the packet itself. The hard part, is,
>of course, tracking which bytes are tagged by which tag in a packet as
>it is sliced and reassembled. What is _really_ hard is doing all of this
>in an efficient way which does not require large amounts of memory.
>
>To make progress on this issue for the june release, I have implemented
>a pretty inefficient version of that in
>http://code.nsnam.org/mathieu/ns-3-tags

Mathieu,

I looked over your repo and had a few comments.  

We could decide to either tag packets or bytes.  Just based on the current API naming alone, I would expect that a packet tagging facility would tag the packet, and as the packet evolved (headers added and removed) the tag would persist, until removed.  If the packet were fragmented, then the tags could either be copied to each fragment or not, depending on policy.  If two packets were grafted together, and they had conflicting tags of the same type, there could be some policy decision (such as take the first one) on how to handle it.

Your proposal instead tags bytes but kind of keeps the initial appearance at the API (at least, as presently documented) that it is tagging packets.  Maybe it could be clearer in that regard, somehow.

I think your approach is consistent with your philosophy of not implementing policy in the core (in this case, the policy of which tag to keep when they conflict in a spliced packet) but delegating the policy to the user.  Your proposed API provides a function to just get the first matching tag but also allows the user wanting to see the exact byte ranges for tags to use the TagIterator, so I think it still supports the use case where the user wants to think about these in terms of having packet granularity, as sketched out above.

I would be fine with either possible solution (tagged bytes, as you have now, or packets).

- Tom