From: Manikantan Ramadas (mramadas@cs.ohiou.edu)
Date: 10/08/03
Date: Wed, 8 Oct 2003 14:05:59 -0400 From: Manikantan Ramadas <mramadas@cs.ohiou.edu> Subject: Re: tcptrace-bugs measuring throughput from syn to fin Message-ID: <20031008180559.GA3765@irg.cs.ohiou.edu>
Hi Stefan,
Well, we discussed this in our weekly research meeting yesterday. It
seems to us that patching tcptrace to do such a thing (following just the
connection segments observed between SYN and FIN segments) may not be
appropriate - keeping in mind that tcptrace is designed to analyze
dumpfiles that could be collected on any host in the path between the source
and destination. I would however, find it extremely pathological to
observe this happening with real TCP stacks with checksumming being done.
Note that tcptrace uses the heuristic of detecting a new connection in
the same endpoints (in file trace.c):
o After a period of inactivity of 4 minutes (endpoint_reuse_interval,
explained in the Extended Options (General) chapter of the manual)
o You see a SYN segment and saw FIN or RST segments in the last
period of activity with the same endpoints
o You see a SYN, last saw a SYN, and the SEQ#s differ.
Since we are using heuristics as it is to group activities in the same
endpoints as a "connection", it is probably not worth adding another
quirk to it. Well, one possible (but yucky) workaround for you might be
to set the "--endpoint_reuse_interval=45" or some such appropriate value,
so that the corrupted packets get pulled over as a separate connection.
However, a better solution (as you had suggested in your email) would be
to just take off the corrupted packets marked 0xff in the IP ToS field by
dummynet from analysis.
Thanks,
- Mani.
On Fri, Oct 03, 2003 at 11:56:14AM +0200, Stefan Alfredsson wrote:
> * Quoting Manikantan Ramadas <mramadas@cs.ohiou.edu> [02 Oct-03 19:58]:
> > Could you please send us a dumpfile exhibiting this behavior?
>
> Sure!
>
> I've put it up at http://www.cs.kau.se/~alfs/pcapdump/
>
> 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.
>
> Regards,
> Stefan
>
> References:
>
> 1. http://www.cs.kau.se/~alfs/tcpl-ist-summit.pdf
>
> 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
> > >
> >
-- "Happiness is when what you think, what you say, and what you do are in harmony." - Mahatma Gandhi ____________________________________________________________________ * Manikantan Ramadas * IRG, OU * http://irg.cs.ohiou.edu/~mramadas * ____________________________________________________________________
This archive was generated by hypermail 2.1.7 : 10/09/03 EDT