Message-Id: <200112040359.WAA29656@lawyers.grc.nasa.gov> From: Mark Allman <mallman@grc.nasa.gov> Subject: Re: Why so many zeros? Date: Mon, 03 Dec 2001 22:59:57 -0500
> But the data was about a long FTP from Beijing Univeristy in
> China to the University of Delaware in US. Suppose the distance is
> 12,000km, there are 10 hops with capacity of 1Gb/s, the MTU is
> 1500 bytes. The two-way delay should be more than 0.4 ms, which
> does not count the processing delay and queuing delay. If we are
> lucky, we can have zero queuing delay. But there are must be some
> nonzero value for processing delay. If the RTT is rounded, then
> the processing delay is under 0.1ms. I don't know the typical
> value for the processing delay. I am worry that the RTT is very
> easily to exceede 0.5 ms.
I understand that the RTT is very likely not less than 1 ms. But,
think about the vantage point of your trace machine. Think about it
like this example:
time 0ms -- machine A sends a packet to machine B
time 100ms -- machine B receives packet from machine A
time 100.1ms -- machine B sends a response to machine A
time 200.1ms -- machine A receives response from machine B
If the vantage point of your trace machine is at the sender side of
this transaction you will correctly measure the RTT as ~200ms
because you will only see the first and last event listed above.
But, if you are tracing things at the receiver you will only see the
middle two events above. So, tcptrace is fooled into thinking the
RTT is 0.1ms (time between seeing the request and seeing the
response). I suspect you are tracing near the receiver and
therefore only seeing the middle two events, which is screwing up
your sampling.
(Also note that this is not a tcptrace problem, per se. This an
instance of a more general vantage problem in network measurement.
For TCP there are some heuristics that one can apply to get real
RTTs from a receiver-only trace. But, that would move tcptrace
towards more analysis (as compared the reporting that it mostly does
currently). Besides, such heuristics open up a whole can of
analysis worms.)
allman
----------------------------------------------------------------------------
To unsubscribe, send a message with body containing "unsubscribe tcptrace" to
majordomo@tcptrace.org.
This archive was generated by hypermail 2b30 : 12/04/01 EST