Message-Id: <200103012001.PAA12403@lawyers.grc.nasa.gov> From: Mark Allman <mallman@grc.nasa.gov> Subject: Re: out of order packets Date: Thu, 01 Mar 2001 15:01:01 -0500
> Thanks for your feedback. This is how my scenario looks like. I am
> transferring files from the client to the server. The connection
> from the client to the hub is a wired one that simulates a
> wireless connection. The simulated wireless channel is exposed to
> extreme interference while transferring traffic and the traffic is
> captured at the hub using a sniffer program called ethereal. I am
> running tcptrace on the captured traffic. The throughput of the
> TCP really drops at certain SNR value where the retransmissions
> are not that many, but out of order packets are exponentially
> high. Client, server, and the workstation running sniffer are
> using redhat 7. I checked that the client and server are using the
> SACK option that explains the small number of retransmissions.
OK. I don't think that explains the out-of-order segments. Maybe
your simulator is garbling things up (?). Sounds like you'll have
to do some digging.
> I avoided runing any program at the client and server to avoid
> putting extra load on the client and server while transferring
> data. I though it might affect my results.
Generally speaking this is a falsehood, in my opinion. Unless you
are pumping data at extremely fast rates a modern workstation/PC can
send/receive data and capture it at the same time with no
performance penalty (and, with the greatest amount of accuracy).
> Is it a valid way of measring TCP performance in terms of
> out-of-order packets,
Not really. But, there is no "good" way to assess out of order
packets when watching from one vantage point and using tcptrace (as
sketched in my last night).
> retransmitted packets
Maybe. Where are the packets being lost? You want to be watching
at a point *before* the loss to see all the transmissions.
Otherwise, you'll be guessing about retransmits (and, tcptrace must
see both the transmit and the retransmit to measure rexmts if I
remember correctly -- and, if not, I'll note that as something to
argue with Shawn about)..
> and throughput?
Maybe. The problem is that you're getting throughput from somewhere
in the middle. That might be fine. But, for instance, if you're
looking for something like the throughput experiecned by a user
receiving data you'd be better off measuring at the receiver.
Likewise, if you're looking at performance from a data server's
perspective it would be better to measure things at the sender
side. It all depends on your purpose.
The bottom line is that watching from the middle of a network path
makes analysis more difficult because you are inferring more than
you are measuring. The closer you get to either end the better.
Ideally, you'd always be watching on both ends. But, that is often
not possible.
Aaron Falk and I put together some supposed words of wisdom on
conducting TCP evaluations that might be worth reading. It contains
some discussion of the things you have asked about above. The paper
is:
Mark Allman, Aaron Falk. On the Effective Evaluation of TCP. ACM
Computer Communication Review, 29(5), October 1999.
http://roland.grc.nasa.gov/~mallman/papers/tcp-evaluation.ps
http://roland.grc.nasa.gov/~mallman/papers/tcp-evaluation.pdf
allman
--- Mark Allman -- NASA GRC/BBN -- http://roland.grc.nasa.gov/~mallman/ ---------------------------------------------------------------------------- To unsubscribe, send a message with body containing "unsubscribe tcptrace" to majordomo@tcptrace.org.
This archive was generated by hypermail 2b30 : 03/02/01 EST