[Ns-bugs] [Bug 166] Loss of Tag and change in size of Packet using TCP.

bugzilla-daemon@nsnam-www.ece.gatech.edu bugzilla-daemon at nsnam-www.ece.gatech.edu
Tue Apr 15 08:16:43 PDT 2008


http://www.nsnam.org/bugzilla/show_bug.cgi?id=166





------- Comment #8 from mathieu.lacage at sophia.inria.fr  2008-04-15 11:16 -------
(In reply to comment #6)
> The tag being lost is a "feature" (but kind of a bug :-).  The implementation
> of TCP simply copies the data in a packet into an internal TX buffer.  Then TCP
> copies segments out of this buffer, packetizes them, and sends them according
> to its congestion control algorithm.  Unfortunately, this is where the tag is
> lost.  The way I conceived of the TCP API was that it dealt with real world
> buffers, not with ns3::Packets.  This is because even if you send a single
> tagged Packet with TCP, there is no guarantee that that information will go on
> the wire as one packet (in fact if the data is larger than an MSS, it WILL NOT
> hit the wire as one packet).
> 
> I think a solution that preserves tags might be possible if some kind of tag
> structure is kept in paralell to the TX buffer...but what about a case where
> the MSS boundaries overlap two differently tagged packets?  I'm not sure what
> to do in this case...

What I expected your tcp implementation to do is to implement the byte buffer
using a list of packet pointers to avoid the extra copy you do right now. If
you do that, tags will be copied around transparently _and_ you will be highly
efficient. One of the use-cases sally insisted a lot about is fast-tcp where
doing what you do is just unacceptable because every simulation will become
memory-bound almost immediately due to the high number of packet buffers in
flight at the same time. If, instead, you use pointers to packets and
instanciate these packets with Packet::Packet (uint32_t size), then, no memory
will ever be allocated for the tcp payload.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


More information about the Ns-bugs mailing list