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

[Mathieu Lacage]

On Wed, 2008-05-07 at 14:48 -0400, Joseph Kopena wrote:
> On Tue, May 6, 2008 at 10:54 AM, Mathieu Lacage
> <mathieu.lacage at sophia.inria.fr> wrote:
> >  On Tue, 2008-05-06 at 06:05 +0000, Tom Henderson wrote:
> >  > I would be fine with either possible solution (tagged bytes, as you
> >  > have now, or packets).
> >
> >  I think that the biggest advantage to tagging bytes under the hood is
> >  that it defines very precisely what happens to tags when you copy a
> >  packet, fragment it, and re-assemble it.
> 
> Hi all,
> 
> Just to increase the count of people who've looked through this, the
> new tags code seems solid to me.  I think tagging bytes is the easiest
> way to deal w/ the TCP issue of people tagging packets even though
> those packets aren't actually what's being transmitted.  As a
> sidenote, I think that's related to Packet being called Packet rather
> than FancyBuffer (not advocating in any way for change, just
> noting)---the tag system was previously treating Packets as packets,
> but TCP is using Packets as fancy buffers.  This functionality could
> also be useful to people doing things like aggregating multiple
> protocol messages into packets.  An example some of the developing
> IETF MANET architecture building and possibly running multiple
> protocols and instances on top of NHDP's HELLO messaging.  If you can
> tag bytes, you could conceivably do things like visualize how they're
> all getting aggregated, etc.  In general, this byte tagging seems to
> be a good way to avoid a sticky policy decision.
> 
> Goals aside, the implementation in ns-3-tags is definitely not naive,
> and seems pretty reasonable.  It's not obvious what the performance
> costs will be, but it looks minimal if you're not using the features,
> and about as good as you could do if you are doing a lot of tagging &
> fragging.  For anyone going through it, note that there's a lot of
> just-in-time updating, so the functionality is not totally obvious at
> first (e.g., newly irrelevant tags get cut from new packet fragments
> not at fragmentation, but when headers are added or tags retrieved).

I have added a bit of documentation about the internal implementation
and have done some basic profiling and optimization. I have not found
any more bugs but, that does not mean that there are none. The code,
however, is probably ready to be merged if we can agree that the
functionality is needed.

regards,
Mathieu