Wireshark · Wireshark-dev: [Wireshark-dev] Possible Bug in identifying the segment an ACK is associated with in TCP SEQ/ACK ana

["Visser, Martin" <martin.visser@xxxxxx>]

Please correct me if I'm wrong, but I think there is an error in the way
wireshark identifies a segment that is accociated with an ACK in the TCP
SEQ/ACK analysis. Consequently this affects RTT calculation. In summary
I think that Wireshark is incorrectly calculating this on the last
segment matching the ACK rather than the first.

Looking at the following print out from wireshark 0.99.5 :-

Number  Time     Len   Source                Destination
Protocol Info
    209 4.025    67    1.153.236.167       10.17.190.67          TCP
2747 > 2598 [PSH, ACK] Seq=2140 Ack=11066 Win=64067 Len=13

    210 4.098    84    10.17.190.67          1.153.236.167       TCP
2598 > 2747 [PSH, ACK] Seq=11066 Ack=2140 Win=63066 Len=30

    211 4.177    1514  10.17.190.67          1.153.236.167       TCP
2598 > 2747 [ACK] Seq=11096 Ack=2153 Win=63053 Len=1460
Frame 211 (1514 bytes on wire, 1514 bytes captured)
Internet Protocol, Src: 10.17.190.67 (10.17.190.67), Dst: 1.153.236.167
(1.153.236.167)
Transmission Control Protocol, Src Port: 2598 (2598), Dst Port: 2747
(2747), Seq: 11096, Ack: 2153, Len: 1460
    Source port: 2598 (2598)
    Destination port: 2747 (2747)
    Sequence number: 11096    (relative sequence number)
    [Next sequence number: 12556    (relative sequence number)]
    Acknowledgement number: 2153    (relative ack number)
    Header length: 20 bytes
    Flags: 0x10 (ACK)
    Window size: 63053
    Checksum: 0x9142 [validation disabled]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 209]
        [The RTT to ACK the segment was: 0.152378000 seconds]

    212 4.177    54    1.153.236.167       10.17.190.67          TCP
2747 > 2598 [ACK] Seq=2153 Ack=12556 Win=64512 Len=0

    213 4.180    1244  10.17.190.67          1.153.236.167       TCP
2598 > 2747 [PSH, ACK] Seq=12556 Ack=2153 Win=63053 Len=1190

Frame 213 (1244 bytes on wire, 1244 bytes captured)
Internet Protocol, Src: 10.17.190.67 (10.17.190.67), Dst: 1.153.236.167
(1.153.236.167)
Transmission Control Protocol, Src Port: 2598 (2598), Dst Port: 2747
(2747), Seq: 12556, Ack: 2153, Len: 1190
    Source port: 2598 (2598)
    Destination port: 2747 (2747)
    Sequence number: 12556    (relative sequence number)
    [Next sequence number: 13746    (relative sequence number)]
    Acknowledgement number: 2153    (relative ack number)
    Header length: 20 bytes
    Flags: 0x18 (PSH, ACK)
    Window size: 63053
    Checksum: 0xef6f [validation disabled]
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 212]
        [The RTT to ACK the segment was: 0.002386000 seconds]
Data (1190 bytes)


Frame 209 contains the first segment containing bytes from the segment
with relative sequence number 2153 from 1.153.236.167. Now this is ACKed
by 10.17.190.67 in frame 211 with a correct RTT of 0.152378000 seconds.

(The avg network RTT is around 100ms).

Now in frame 212, 1.153.236.167 has no more segments to send yet, so is
happy to send a pure ACK to 10.17.190.67 with a seq still of 2153. 

1.153.236.167 is sending more data in frame 213, and of course is still
going to send an ACK of 2153. But this ACK is not necessarily an ACK of
Frame 212, which is what SEQ/ACK analysis says it is!!! I know this
because of the physical RTT and that there is no way frame 212 could
have reached the other end (and the calculated RTT in 213 is 0.002386000
secs)

So I guess what I am trying to say is that wireshark is overzealously
associating ACKs with SEQs. As it has already seen an ACK to SEQ 2153 I
don't believe it should record a second one at this point. I need
wireshark in the SEQ/ACK analysis to only record times it definitely can
determine from the trace. While in some circumstances frame 213 could be
ACKing frame 212, I think that heuristically it can't assume that,
particularly as this SEQ has already been ACKed earlier by frame 211. I
really don't need wireshark to report artificially low RTTs. 

I am happy to be tarred and feathered if I have this one wrong.

Regards, Martin

Martin Visser

Technology Consultant 
Technology Solutions Group - HP Services

410 Concord Road
Rhodes NSW  2138
Australia 

Mobile: +61-411-254-513
Fax: +61-2-9022-1800     
E-mail: martin.visserAThp.com

This email (including any attachments) is intended only for the use of
the individual or entity named above and may contain information that is
confidential, proprietary or privileged. If you are not the intended
recipient, please notify HP immediately by return email and then delete
the email, destroy any printed copy and do not disclose or use the
information in it.