Re: tcptrace-bugs measuring throughput from syn to fin

From: Stefan Alfredsson (
Date: 10/03/03

Date: Fri, 3 Oct 2003 11:56:14 +0200
From: Stefan Alfredsson <>
Subject: Re: tcptrace-bugs measuring throughput from syn to fin
Message-ID: <>

* Quoting Manikantan Ramadas <> [02 Oct-03 19:58]:
> Could you please send us a dumpfile exhibiting this behavior?


I've put it up at

Some background info about the trace: traffic is sent
from "snd" to "rcv", passing a modified FreeBSD dummynet gateway
that introduces bit errors into the packets. 30 consecutive connections
are made between the two hosts, to the same port.

To easier trace which packets are in error, dummynet also
stamps the IP ToS field with 0xff (easy to color filter in ethereal,
and I dont use the ToS field anyway)

The receiver has a TCP modification [1] that accepts erronenous checksums,
and treats the header carefully since it may contain an error.

All connections should have around 40-45kb/s [2], but connection 62 and 80
in the tracefile file have at most half this rate

What is happening is easy to see in ethereal - set the display to show
"time of day", examine connection 62:

TCP connection 62:
        host ds: snd:51088
        host dt: rcv:1234
        complete conn: yes
        first packet: Tue Aug 19 03:41:04.800860 2003
        last packet: Tue Aug 19 03:41:59.060213 2003
        elapsed time: 0:00:54.259353

Browse to the time at "first packet", and we find a data packet
with port nr 51088 - its a syn for this connectio, so OK.

At 03:41:29.227542 (pkt #69388) he have the fin-ack for the connection,
and then the next connection start.

Lets visit the "last packet" at 03:41:59.060213 (#72113). If we examine
the sequence number, we see that it fits into the packet stream
that surrounds it. However, the ip.tos == 0xff, which indicates that
there are errors in this packet. So, in this case, the port number
has been changed by bit errors, and is interpreted as the last packet
in the stream, even though the fin was seen about 30 seconds earlier.

For connection 80 the case is similar but reversed.

Packet at 03:44:01.730291 (#83257) is also in error and has its port number
changed to that of a future connection, which is really starting
at 03:44:53.538986 (#87567)

So to conclude - I would like a way to specify that throughput be
measured from the syn to the fin handshakes :)

I've thought about making a hack specific for my situation, i.e. ignore
first and last packets when they have my error-marking, but I guess
a general solution would be better.




2. grep throu *.tt |grep -v NA|awk '{print $2}'

> Thanks,
> Mani.
> On Thu, Oct 02, 2003 at 05:03:27PM +0200, Stefan Alfredsson wrote:
> > Hello,
> >
> > >From what I understand, the throughput is calculated from the
> > first packet seen to the last packet seen in with the same
> > addr,port pairs.
> >
> > Is there a way to make tcptrace only count the time between syn
> > and fin instead?
> >
> > In my specific situation, I run experiments over a simulated wireless
> > link which introduces bit errors.
> >
> > Sometimes an error affects the port number, and as they are (almost)
> > sequentially allocated this means that an erronenous packet in an early
> > connection may be misjudged to belong to a later stream, or the other
> > way around.
> >
> > This means that the throughput for a connection may be way off, because
> > an erroneous packet was determined to be the "first" in the particular
> > stream.
> >
> > I tried the "-c" flag to only count connections with syn and fin seen,
> > but the same behavior existed there.
> >
> > Ideas?
> >
> > Regards,
> > Stefan
> >

This archive was generated by hypermail 2.1.7 : 10/03/03 EDT