[Ns-developers] TCP and UDP layer refactoring

[craigdo@ee.washington.edu]

> That goes back to another discussion but tags should not be 
> removed once
> added, mainly because it is too painful to do. Another way to 
> deal with
> this is to replace the use of Packet::FindFirstMatchingTag by
> Packet::FindLastMatchingTag (which is not implemented yet, but should
> not be too hard to do).

I have lingering questions regarding the tags interface and usage.  There do
seem to be other reasons for not removing tags as well.

FindLastMatchingTag does seem to make tags actually usable, and really does
seem trivial to implement (I can go ahead and add that).  

I don't know if it's just me, but I'm getting foggy on what this facility is
supposed to do and how it is expected to be used.  I don't have a consistent
conceptual model of tags any more.  I am experiencing cognitive dissonance
and I can't get up :-)

A long time ago in an ns-3 far, far away, there used to be methods in the
packet to:

  - add a tag;
  - remove a tag;
  - peek at a tag;
  - remove all tags.

Tags were 16-byte objects and the "scope" of a tag was an entire packet.  I
could see how this was supposed to be used in a fairly straightforward way.

Fragmentation seems to have thrown us a curve.

Now we have 

  - add a tag;
  - get a tag iterator;
  - find the first matching tag;
  - remove all tags;
  - print tags.

The 16-byte limit seems to have been relaxed, and the ability to remove a
tag has been elided.  Now, I believe that when you add a tag to a packet,
you are still tagging all of the bytes in the packet.  My understanding is
that a key difference now is that if you fragment a packet, the tags
associated with the bytes in the original packet are associated with
corresponding bytes in a fragment, so tags will be duplicated in fragments.

I'm not real clear on what we expect if the fragments are reassembled
somewhere.  For example, what happens if a packet with some number of tags
is fragmented by a device / channel and then reassembled (ATM is an extreme
example with 48 byte payloads in a cell).  TCP is, I believe, the driving
case for associating tags with byte ranges, but this isn't the only place
fragmentation and reassembly could happen -- it could happen anywhere.

Should the rule be that we will find at least one instance of an original
tag and perhaps very many duplicates?  This would imply that
FindLastMatchingTag is really the only correct way to get a tag.  I can
imagine lots of mechanisms that would duplicate tags and I'm not real clear
on some issues such as preserving an order and when an iterator would
actually be useful since tags would just appended in what amounts to a
haphazard way.

It seems to me that a good model for what to expect these things to do is
critical and missing in our documentation.  The answer may be as simple as
documentation + FindLastMatchingTag.

Having said that, there seem to be cases in our code where tags are used to
avoid having to plumb parameters through the code (I won't use the word lazy
:-).  For example in the sockets code, an address tag is used to attach a
packet address to a packet that is pushed on a packet queue and is gotten on
the way out of the queue.  This strikes me as an abuse of tags.

Tags seem to me to be a mechanism to attach useful information to a packet
that flows across boundaries where you would normally not want or be able to
plumb in parameters (i.e., across channels, cross-layer info, flow info).

In any case, I think that a method for finding the last matching tag is
required, but I'm not real clear on a model for how to think about tags
anymore.

-- Craig