RTT calculation using tcptrace

For the below attached tcptrace output (this is taken from the site http://tcptrace.org/manual/index.html under RTT stats)

1 arg remaining, starting with 'indica.dmp.gz'
Ostermann's tcptrace -- version 6.4.5 -- Fri Jun 13, 2003

153 packets seen, 153 TCP packets traced
elapsed wallclock time: 0:00:00.128422, 1191 pkts/sec analyzed
trace file elapsed time: 0:00:19.092645
TCP connection info:
1 TCP connection traced:
TCP connection 1:
    host a:        192.168.0.70:32791
    host b:        webco.ent.ohiou.edu:23
    complete conn: yes
    first packet:  Thu Aug 29 18:54:54.782937 2002
    last packet:   Thu Aug 29 18:55:13.875583 2002
    elapsed time:  0:00:19.092645
    total packets: 153
    filename:      indica.dmp.gz
   a->b:                  b->a:
     total packets:            91           total packets:            62      
           . . .                                  . . .
           . . .                                  . . .
     throughput:               10 Bps       throughput:               94 Bps  

     RTT samples:              48           RTT samples:              47      
     RTT min:                74.1 ms        RTT min:                 0.1 ms   
     RTT max:               204.0 ms        RTT max:                38.8 ms   
     RTT avg:               108.6 ms        RTT avg:                 8.1 ms   
     RTT stdev:              44.2 ms        RTT stdev:              14.7 ms   

     RTT from 3WHS:          75.0 ms        RTT from 3WHS:           0.1 ms   

     RTT full_sz smpls:         1           RTT full_sz smpls:         1      
     RTT full_sz min:        79.5 ms        RTT full_sz min:         0.1 ms   
     RTT full_sz max:        79.开发者_如何学JAVA5 ms        RTT full_sz max:         0.1 ms   
     RTT full_sz avg:        79.5 ms        RTT full_sz avg:         0.1 ms   
     RTT full_sz stdev:       0.0 ms        RTT full_sz stdev:       0.0 ms   

     post-loss acks:            0           post-loss acks:            0

So the question I have is that if you see RTT average for a->b and for b->a there is a major difference in the values. I dont expect them to be exaclty the same but the difference is quite big. I think there is something happening behind the scene in the way RTT is being calculated which I am not sure of.

Summary: Make sure you look at the RTT for the correct half of the conversation, depending on where you made the capture

This answer explains that tcptrace uses the difference between timestamps of the data segment and that of the ACK that acknowledges it to calculate RTT. This means that the RTT calculation will depend on where you are capturing the trace

For example, if you are capturing packets on node A, you will see A's ACK almost immediately after you see the corresponding segment arriving from node B and thus see a very low value for RTT in the B->A segments. For A->B segments you will be measuring the real RTT as a 'real' round-trip will have occurred between seeing the segment from A and the corresponding ACK from b.

If you made the capture on node b the situation would be reversed, and if you made the capture somewhere in the middle the 'true' RTT would be approximately the sum of A->B + B->A.

The RTT calculations are not made at the sender node. They could have been made at a point along the path. The a->b and b->a is not necessarily between the sender and receiver nodes.

It can be something like this

S--A--------->R where S is Sender and R is receiver and A is some point between S and R. a->b can represent the RTT from A to R while b->a can represent RTT from A to S.