Re: tcptrace-bugs Using tcptrace with ns traces

From: Joshua Blanton (jblanton@masaka.cs.ohiou.edu)
Date: 09/29/04


Date: Wed, 29 Sep 2004 01:01:23 -0400
From: Joshua Blanton <jblanton@masaka.cs.ohiou.edu>
Subject: Re: tcptrace-bugs Using tcptrace with ns traces
Message-ID: <20040929050123.GA25128@jtb.ipx.ath.cx>


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

--jtb

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