From: "Raja Epsilon" <raja_epsilon@hotmail.com> Subject: Re: out of order packets Date: Thu, 01 Mar 2001 19:05:41 -0000 Message-ID: <F268BZTW5k1Ed28kIN400005a4e@hotmail.com>
client-->hub-->server
|
|
\/
workstation running sniffer program
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.
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. Is it a valid way of measring TCP performance in terms of
out-of-order packets, retransmitted packets and throughput?
Thanks agin for your feedback.
Raja
> > My second question is again about out-of-order packets. I have a >
>dedicated network where two computers are connected using a hub > where one
>connection is wireless. Is it possible to get out of > order packets in
>this scenario?
>
>Probably unlikely.
>
> > I am getting lots of out-of-order packets from my experiments > using
>Tcptrace. In INTERNET it is common to have out of order > packets since
>packets are routed through different routers.
>
>Actually, the following paper argues that reordering in the Internet is
>mostly caused by load balancing.
>
>J. Bennett, C. Partridge, N. Shectman. Packet Reordering is Not Patalogical
>Network Behavior, IEEE/ACM Transactions on Networking, December 1999.
>
>But, anyway...
>
> > But how can this happen on a dedicated network? Is it because of > bit
>errors in the wireless medium that forces corrupted packets to > spend more
>time in data link layer employing FEC whereas > uncorrupte packets are
>processed quicker and passed on the > transport layer?
>
>Where are you observing the traffic? If your vantage point is the receiver
>retransmits will look out-of-order.
>
>Being completely accurate about measuring out-of-order packets really
>requires traces from both the sender and receiver side and a tool that will
>compare the order the packets were sent and the order in which they were
>received. My hit is that when you have a receiver trace, tcptrace accuratly
>measures reordering in a global sense. But, probably overestimates the
>amount of reordering caused by the network itself (due to being fooled by
>retransmits).
>
>allman
>
>
>--- Mark Allman -- BBN/NASA GRC -- http://roland.grc.nasa.gov/~mallman/
_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
----------------------------------------------------------------------------
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