[Ns-developers] network path packet tag

[Tom Henderson]

On 09/06/2011 05:10 AM, Oliveri, Payton M USA CTR (US) wrote:
> We were looking to implement a way to track packets through the network from source to destination to observe the route taken. We initially set this up through a series of callbacks connected to the IP layer, identifying the original send, each forward, and the final receive; however, this very quickly degrades efficiency (it takes approx 30 times as long to run with this added load).
> Our next thought was to simply develop our own packet tag, that could be removed at each new hop, that hop's id appended, and the tag re-added to the packet. However this starts to compete with PACKET_TAG_MAX_SIZE defined in packet-tag-list.h. We realize that simply increasing this value for the expected diameter of the network is very poor in terms of memory management, especially since it affects each packet tag's memory allocation.
> Is there a recommended way of gathering this information? Is there a way to modify how we use our new packet tag to avoid this issue, possibly with variable length packet tags?
> Thanks,
> Payton Oliveri

A similar issue arose back in 2009* when considering how to integrate 
NixVector routing to the existing packet class.  NixVector also didn't 
have a fixed-length tag that could fit the existing field.  The decision 
taken at the time was to put an explicit NixVector pointer into the 
packet class, file a bug** on it to remind us to fix it, and try to find 
a better solution going forward.  However, the bug remains open.

It seems that we now have two use cases for variable-length packet 
tagging capabilities, so perhaps we should revisit whether/how this is 
possible to do by extending the tag framework or adding some other 
similar facility.

In the meantime, expanding the PACKET_TAG_MAX_SIZE to fit your 
topologies might be the best workaround to try, unless your packets 
happen to have lots of unrelated tags.

- Tom


* http://mailman.isi.edu/pipermail/ns-developers/2009-September/006558.html

** https://www.nsnam.org/bugzilla/show_bug.cgi?id=837