[Martin Visser <martinvisser99@xxxxxxxxx>]

(Including the dev list as well)

There are actually 2 problems with tcp.analysis.ack_rtt.

1. Is that you need to decide for which round-trip you wish to find
the RTT for. If you have Wireshark capturing traffic close to (or even
on) the client, then you expect that the server will respond
relatively slowly to your request (assuming a WAN-type connection to
the server). However you need to remember that the client also ACKs
the data sent by the server. Depending on the flow of data, this could
be done by the client very quickly (particularly if it sends a
zero-length ACK). For example, Frame 9 shows this very quick response
by your client to Frame 8. As the client has no new data to send
(Len=0) then it's TCP stack ACKs as quickly as it can.

So if you are only interested in RTT to your client requests (and
hence in general see the response time of the server+network latency)
then you will want to discard RTT measurements for any frames where
the source is your client.

2. Often the ACKs to traffic can overlap with subsequent traffic. If
you have a reasonably large TCP window size then many unacknowledged
frames can be sent before the actual ACK is seen. Wireshark seems to
have a bug in that when it associates an ACK with the corresponding
data frame, it uses the most recent frame rather than the oldest frame
for that association.

For instance in your sample PCAP, the SEQ/ACK analysis of frame 13
indicates it is an ACK for frame 12, calculating the RTT as 0.00096
seconds. This is almost certainly wrong. Because all the way up until
frame 29, your client never sends any actual data, you can't actually
know for certain which frame 13 is an ACK for (as the ACK sequence
number doesn't need to change). Basically up until frame 29, the
server just streams and you can't for certain tell whether it is
waiting for ACKs from the client. So basically the RTT in 13 is a bug.
In fact you can see another manifestation of the bug when client
starts sending data. In frame 29 the client sends 20 bytes. The server
ACKs this in frame 31, 0.366 seconds later. However no RTT is
calculated for this. Instead Wireshark "waits" until it till Frame 36
to show the next server ACK RTT. This correctly relates the ACK to
frame 30 (with a RTT of 0.122 secs).Wireshark then goes on to claim
that frame 39 is an ACK to 38 (with an RTT of 0.0098 secs), even
though it has already sent the relative ACK 41 way back in frame 36.

Not sure if I have time to actually figure our why Wireshark makes
some wrong RTT calcs here, but it certainly needs to be looked at (as
per Ed's bug report)

Regards, Martin

MartinVisser99@xxxxxxxxx



On Mon, Jun 15, 2009 at 11:32 AM, Francis-CM
Chan<francis-cm_chan@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Thanks Ed for the response.
>
> I am using the 1.0.8 stable version to capture, and use 1.0.6 to do the
> processing. Is the problem you referring due to capturing or the
> post-processing?
>
> As a preliminary check on the capture details, I can hardly find any
> calculation problem on the packets I am checking with. Can you be more
> specific so that I can have a much clear understanding.
>
> Thank you in advance.
>
> Francis
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 13 Jun 2009 06:55:07 -0500
> From: <Ed.Staszko@xxxxxxxxxxxxxxxxx>
> Subject: Re: [Wireshark-users] tcp.analysis.ack_rtt - Unexpected short
>        TCP RTT
> To: "Community support list for Wireshark"
>        <wireshark-users@xxxxxxxxxxxxx>
> Message-ID:
>
> <OF85E4BA5A.6F4BE457-ON862575D4.0041216A-862575D4.004178C7@mutualofomaha
> .com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Unfortunately, the tcp.analysis.ack_rtt logic in Wireshark is flawed.
> (see bug report on this issue) Try using the last available version of
> Ethereal and you will see an accurate representation.
>
> Ed Staszko
> Senior Network  Analyst
> Mutual of Omaha
>
> ___________________________________________________
>
>
> Hi,
>
> Currently, I am studying the latency between a typical internet use and
> a online game server. I use the tcp.analsyis.ack_rtt to extract
> information for analysis. Here is my command line:
>
> tshark -Tfields -E header=y -e frame.number -e frame.time_relative -e
> ip.src -e tcp.flags -e tcp.analysis.acks_frame -e tcp.analysis.ack_rtt
> -r tcp.analysis.ack_rtt.pcap > tcp.analysis.ack_rtt.txt
>
> The attached capture file is a short extraction of the TCP dialog
> between the 2 end points (user 192.168.1.102 and server
> 202.123.175.210). The monitoring point was at the user side made
> possible by inserting an Extreme switch with a mirroring port
> configured. The capturing machine is an IBM X61 notebook running WinXP.
>
> I understand that I should use the tcp.analysis.ack_rtt for the
> direction 202.123.175.210->192.168.1.102 (i.e. ip.src ==
> 202.123.175.210) for the measure of the rtt of the communication link.
> However, to my surprise, I get extraordinary short measure for some
> specific cases. For example, frame 13, 16, 39, 52.
>
> Can any expert help to explain what is going on, or do I
> misunderstanding something? If my concept is right, would it be
> something wrong with the capturing environment?
>
> Regards,
> Francis Chan
>
> =========== output from tshark ================
>
> frame        frame.time        ip.src
> tcp.flags
> tcp.analysis.acks_frame        tcp.analysis.ack_rtt
> 1            0                       202.123.175.210         0x18
>
> 2            0.139957          192.168.1.102           0x10        1
>  0.139957
> 3            0.331267          202.123.175.210         0x18        2
>  0.19131
> 4            0.44172                       192.168.1.102           0x10
>  3           0.110453
> 5            0.510189          202.123.175.210         0x18        4
>  0.068469
> 6            0.643078          192.168.1.102           0x10        5
>  0.132889
> 7            0.813951          202.123.175.210         0x10        6
>  0.170873
> 8            0.823548          202.123.175.210         0x10
>
> 9            0.823555          192.168.1.102           0x10        8
>  0.000007
> 10           0.903789          202.123.175.210         0x10        9
>  0.080234
> 11           0.913734          202.123.175.210         0x10
>
> 12           0.913891          192.168.1.102           0x10        11
>  0.000157
> 13           0.92357                       202.123.175.210         0x10
>  12          0.009679
> 14           0.993972          202.123.175.210         0x10
>
> 15           0.993979          192.168.1.102           0x10        14
>  0.000007
> 16           1.003893          202.123.175.210         0x10        15
>  0.009914
> 17           1.004383          202.123.175.210         0x18
>
> 18           1.004389          192.168.1.102           0x10        17
>  0.000006
> 19           1.30019                       202.123.175.210         0x18
>  18          0.295801
> 20           1.447811          192.168.1.102           0x10        19
>  0.147621
> 21           1.580027          202.123.175.210         0x18        20
>  0.132216
> 22           1.749584          192.168.1.102           0x10        21
>  0.169557
> 23           1.820187          202.123.175.210         0x18        22
>  0.070603
> 24           1.950755          192.168.1.102           0x10        23
>  0.130568
> 25           2.220194          202.123.175.210         0x18        24
>  0.269439
> 26           2.353105          192.168.1.102           0x10        25
>  0.132911
> 27           2.420021          202.123.175.210         0x18        26
>  0.066916
> 28           2.554268          192.168.1.102           0x10        27
>  0.134247
> 29           2.756383          192.168.1.102           0x18
>
> 30           2.757533          192.168.1.102           0x18
>
> 31           2.820148          202.123.175.210         0x10
>
> 32           2.843951          202.123.175.210         0x10
>
> 33           2.853885          202.123.175.210         0x10
>
> 34           2.857996          192.168.1.102           0x10        33
>  0.004111
> 35           2.863548          202.123.175.210         0x10
>
> 36           2.880125          202.123.175.210         0x10        30
>  0.122592
> 37           2.953777          202.123.175.210         0x10
>
> 38           2.954035          192.168.1.102           0x10        37
>  0.000258
> 39           2.963877          202.123.175.210         0x10        38
>  0.009842
> 40           2.972585          202.123.175.210         0x18
>
> 41           2.972592          192.168.1.102           0x10        40
>  0.000007
> 42           3.051291          202.123.175.210         0x18        41
>  0.078699
> 43           3.157789          192.168.1.102           0x10        42
>  0.106498
> 44           3.231312          202.123.175.210         0x18        43
>  0.073523
> 45           3.334778          192.168.1.102           0x18        44
>  0.103466
> 46           3.334784          192.168.1.102           0x18
>
> 47           3.338861          192.168.1.102           0x18
>
> 48           3.400308          202.123.175.210         0x18
>
> 49           3.430135          202.123.175.210         0x10        47
>  0.091274
> 50           3.444544          202.123.175.210         0x10
>
> 51           3.444984          192.168.1.102           0x10        50
>  0.00044
> 52           3.446886          202.123.175.210         0x10        51
>  0.001902
> 53           3.513886          202.123.175.210         0x10
>
> 54           3.513895          192.168.1.102           0x10        53
>  0.000009
> 55           3.52455                       202.123.175.210         0x10
>  54          0.010655
> 56           3.533878          202.123.175.210         0x10
>
> 57           3.533885          192.168.1.102           0x10        56
>  0.000007
> 58           3.583883          202.123.175.210         0x10        57
>  0.049998
> 59           3.593878          202.123.175.210         0x10
>
> 60           3.593888          192.168.1.102           0x10        59
>  0.00001
>
> Experience the true Internet.  Right on your mobile. Right now.
> www.smartone-vodafone.com
>
> ************************************ E-mail Disclaimer ************************************
> This e-mail message (together with any attachments) is confidential to the addressee
> and may also be privileged. If you are not the intended recipient, you are hereby notified
> that any dissemination, distribution or copying of this message is strictly prohibited.
> Please also notify the sender immediately by return e-mail and delete it from your system.
>
> Internet communications cannot be guaranteed to be secure or error-free.
> The sender and the entity through which this message is sent therefore do not accept
> liability for errors or omissions as contained in the message and any spreading of viruses
> as a result of Internet transmission.
>
> Any opinions contained in this message are those of the sender personally and would
> not bind any entity unless otherwise clearly stated and with the authority of the sender
> duly verified.
> *******************************************************************************************
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>             mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
>