Date: Fri, 7 Mar 2003 10:45:45 -0500 From: Manikantan Ramadas <mramadas@cs.ohiou.edu> Subject: Re: tcptrace about TCP RTT calculation when packet truncation happens Message-ID: <20030307104545.C23681@irg.cs.ohiou.edu>
Hi,
My apologies for the delayed response.
I am positive that tcptrace would skip processing a TCP packet if it was
truncated and its entire header was not available.
( A check is made for it in the gettcp() function call made from the
ProcessFile() function. )
However tcptrace does skip thru' such a truncated packet (with the header
truncated, that is). My first question is, did you try getting the dumpfile
without any of the packets getting truncated? In tcpdump for e.g., you may
try using "-s 1500" to raise the snaplen. I am sure windump must have a
similar option.
The presence of a NAT in between your source and destination in a wired
ethernet could also affect measurements depending on how it is setup. For
e.g., the NAT could open another active connection to the destination, for
the source machine. If that is the case, the measurements at the
destination would show a connection originating from NAT<==>Destination,
instead of Source<==>Destination. Could you repeat your experiments without
the NAT?
I am sorry if I am missing something here.
- Mani.
On Tue, Feb 25, 2003 at 09:10:52PM -0800, Minghua Chen wrote:
> Today I tried to get RTT statistics on both sender and receiver sides,
> sender is a fixed host, receiver is a mobile host. Receiver is connected
> to sender via a 802.11b interface, and in the other experiment via CDMA
> data network.
>
> However, I still can not get correct RTT statistics. On receiver side, it
> provides only incorrect RTT statistics, on sender side, it even does not
> provide any RTT statistics! I use command like this:
> tcptrace -l -r -n test.dump
> where test.dump is the dump file given by windump (tcpdump windows
> version)
>
> Also, I notice that in both cases, the packets are all truncated, which
> make me wonder whether it is because of truncation that the RTT statistics
> can not work. So I try to do experiment on two desktops connected by
> ethernet, where packet truncation is not supposed. However, the two
> machines I can control is seperate by a NAT device, so the packet still
> get truncated (shown in tcptrace result) and the RTT still not correct,
> could somebody do the experiment or give me an answer why I can not get
> correct RTT statistics? Thanks
>
> Minghua
>
> On Tue, 25 Feb 2003 uaca@alumni.uv.es wrote:
>
> > On Mon, Feb 24, 2003 at 02:44:41PM -0800, Minghua Chen wrote:
> > > Hi,
> > [...]
> > > Any suggestions on how can i get the correct RTT in my senario?
> >
> > this is a topic covered some time ago (3 or 4 months ago or something more)
> >
> > tcprace can only meassure RTT in one of the ends, it uses the same method
> > that the TCP stacks (is supossed) they use, here is were it comes the needed
> > to put the dumping utility in one of the two ends
> >
> > Ulisses
> >
> >
> >
> > >
> > > Thanks
> > >
> > > Minghua
> > >
> > > -------------- examples of RTT raw file of the FTP data packets:
> > > 2629228319 196
> > > 2629230103 0
> > > 2629231563 0
> > > 2629234483 0
> > > 2629235943 0
> > > 2629238863 0
> > > 2629240323 0
> > > 2629243243 0
> > > 2629244703 102
> > > 2629246487 0
> > > 2629247947 0
> > > 2629250867 0
> > > 2629252327 0
> > > 2629255247 0
> > > 2629256707 0
> > > 2629259627 0
> > > 2629261087 107
> > > 2629262871 0
> > > 2629264331 0
> > > 2629265791 174
> > > 2629268711 0
> > > 2629270171 136
> > > 2629271631 157
> > > 2629273091 0
> > > 2629274551 117
> > > 2629277471 0
> > > 2629277795 100
> > > 2629279255 120
> > > 2629280715 0
> > > 2629283635 0
> > > 2629285095 0
> > > 2629286555 164
> > > 2629289475 0
> > > 2629290935 126
> > > 2629293855 0
> > > 2629294179 108
> > > 2629295639 126
> > > 2629297099 0
> > > 2629298559 170
> > > 2629301479 0
> > > 2629302939 152
> > > 2629304399 173
> > > 2629305859 0
> > > 2629307319 114
> > > 2629310239 0
> > > 2629312023 0
> > > 2629313483 0
> > > 2629316403 0
> > > 2629317863 0
> > > 2629320783 0
> > > 2629322243 0
> > > 2629325163 0
> > > 2629326623 177
> > > 2629328407 0
> > > 2629329867 0
> > > 2629332787 0
> > > 2629334247 0
> > > 2629337167 0
> > > 2629338627 0
> > > 2629341547 0
> > > 2629343007 142
> > >
> > >
> > >
> > > ----------------------------------------------------------------------------
> > > To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
> > > majordomo@tcptrace.org.
> >
> > --
> > Debian GNU/Linux: a dream come true
> > -----------------------------------------------------------------------------
> > "Computers are useless. They can only give answers." Pablo Picasso
> >
> > ---> Visita http://www.valux.org/ para saber acerca de la <---
> > ---> Asociación Valenciana de Usuarios de Linux <---
> >
> >
>
>
> ----------------------------------------------------------------------------
> To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
> majordomo@tcptrace.org.
--
"A man is but a product of his thoughts; what he thinks, that he becomes."
- Mahatma Gandhi
____________________________________________________________________________
* Manikantan Ramadas * IRG, Ohio Univ. * http://irg.cs.ohiou.edu/~mramadas *
____________________________________________________________________________
----------------------------------------------------------------------------
To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
majordomo@tcptrace.org.
This archive was generated by hypermail 2b30 : 03/08/03 EST