How to suspect TCP Retransmission

It depends on where you are capturing in relation to the point of packet loss (upstream or downstream). It is normal to see the sequence number only once if you are capturing downstream from the point of packet loss.

If you are capturing upstream from the point of packet loss--packets are being dropped after they pass your capture point--then Wireshark will see both the original packet and the retranmission and it will be clear that the second one is a retransmission. In this case, you will see the expected sequence number twice.

If you are capturing downstream from the point of packet loss--packets are being dropped before they pass your capture point--then Wireshark will only see the retransmission. In this case, there will be a gap in the sequence numbers, Wireshark's expert will say "Previous segment not captured," and then the expected packet will show up later. In this case, you will see the expected sequence number only once.

Unfortunately, out-of-order packets look exactly the same as retransmissions where you are downstream from the point of packet loss: There is a gap in the sequence numbers and the packet shows up later than expected. Wireshark has to try to distinguish between out-of-order packets and retransmissions.

In Wireshark versions up to and including 1.10.x, Wireshark will identify the packet as an out-of-order packet if it appears within 3 ms of where it should have been, and will identify it as a retransmission if it appears more than 3 ms from where it should have been. This is a hard-coded number, and Wireshark can mis-identify out-of-order packets as retransmissions and vice-versa.

Beginning with Wireshark 1.12.x, if the TCP three-way handshake is present in the trace, Wireshark will calculate the initial round-trip time and compare to that instead of to 3 ms. If the three-way handshake is not present, then Wireshark will use the 3-ms rule.