[Ns-developers] TCP and UDP layer refactoring

[Mathieu Lacage]

On Mon, 2008-07-07 at 13:53 -0700, craigdo at ee.washington.edu wrote:
> > 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).  

Feel free to beat me to it: the simplest way to do this would be to
write the tag headers _after_ the tag data to make the common case of
FindLastMatchingTag be a O(n) really fast operation and, then, if you
really care about keeping FindFirstMatchingTag, make it a O(n2)
operation.

> 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.

yes.

> 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

The re-assembled packet will be made of a set of very small tags, but
all of these small tags will tag the exact same amount of data
originally tagged.

> case for associating tags with byte ranges, but this isn't the only place
> fragmentation and reassembly could happen -- it could happen anywhere.

yes.

> 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

You will find very many duplicates, but each duplicate will tag a very
small portion of the big packet.

> 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.

The use-case we discussed when we chose to go down that route was that
of a GUI which wanted to display colors to identify a byte flow.

> 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.

maybe.

> 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.

Maybe. I see this case as being similar to "anciallary data", that is, a
way to pass across an API a set of per-packet information.


> 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).

yes.

Mathieu