Re: tcptrace-bugs Using tcptrace with ns traces

From: Joshua Blanton (
Date: 09/29/04

Date: Wed, 29 Sep 2004 01:01:23 -0400
From: Joshua Blanton <>
Subject: Re: tcptrace-bugs Using tcptrace with ns traces
Message-ID: <>

Bharath Bhushan wrote:
> Actually I am using the FullTcp Agent in ns. I am running a simple
> fulltcp based simulation (tcl file attached with this mail along with
> the trace file). I have not modified ns source code.
> About the flags that you mention for proper processing of ns traces, I
> assume they are tcptrace compilation flags. Am I right here?
> ns version I am using - 2.27
> The traces that I have are the "normal traces" with 14 fields (18 for
> tcp specific traces). I have not worked with the ns "new" traces.
> After applying the patch related to the trace file format recognition
> (sent by Joshua Blanton), the ns trace files are getting recognized
> properly but lots of hardware duplicates are seen in the tcptrace
> output.

As Wes said, the hardware duplicates come from having more than just a
sender-side trace (the + packets that the sender sends, and the -
packets from the receiver as they are received by the sender). If you
want to plot all connections in a file, write a simple script that
chooses and endpoint for each connection and filters out the correct
packets to display; you can then generate the corresponding "other
side" (with the senders and receivers reversed) and trace that as well,
if it is useful.

Basically, tcptrace is not smart enough (and I would argue *cannot* be
smart enough, without specifying more information about the simulation
to it) to understand that the multiple instances of one packet are just
that packet propogating across a path. You must filter out all but one
instance of each packet, to avoid getting errors about duplicated


Those who beat their swords into plowshares usually end up plowing for
those who didn't.
	-- Ben Franklin

This archive was generated by hypermail 2.1.7 : 09/30/04 EDT