TCP Fast Retransmission Analysis with Wireshark

Background

When conducting network packet analysis over an extended period, the accumulation of trace files is inevitable. Without effective organization, recalling the specific purpose of each file can become challenging. This article examines a trace file titled client-fast-retrans.pcapng, which was initially presumed to concern fast retransmission. However, a deeper investigation using Wireshark uncovers valuable insights into a TCP analysis challenge, specifically highlighting issues related to TCP Fast Retransmission and packet order discrepancies.

Problem Information

The basic information of the packet trace file is as follows:

$ capinfos client-fast-retrans.pcapng
File name:           client-fast-retrans.pcapng
File type:           Wireshark/... - pcapng
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: (not set)
Number of packets:   27
File size:           17 kB
Data size:           17 kB
Capture duration:    0.311468 seconds
First packet time:   2015-06-02 22:11:59.655051
Last packet time:    2015-06-02 22:11:59.966519
Data byte rate:      54 kBps
Data bit rate:       436 kbps
Average packet size: 629.70 bytes
Average packet rate: 86 packets/s
SHA256:              6ee7b5061a54bc22b44fe5bdbd10d7f0fcc2fdb63dd45f9bbf3327eefb15a191
RIPEMD160:           cd8614df4aa3316508290308c4b875459b9a9419
SHA1:                42704ab0674942a2cfcd77404784c7409b67283c
Strict time order:   True
Capture application: Editcap 2.6.13
Number of interfaces in file: 1
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 65535
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 27

1. The file should have been captured by tcpdump and then modified by editcap on Windows;
2. The number of packets is 27, and the average rate is 436 kbps;
3. The data packet capture time is 2015-06-02. (This indicates that the trace file is collected from the Internet)

Since the trace file contains only 27 packets in total, the number of issues such as retransmission or fast retransmission shown in the expert information is only 1.

Wireshark’s TCP Fast Retransmission Logic Explained

Actual data packet analysis, TCP three-way handshake is mainly as follows

The complete data package information is as follows

The trace file is an HTTP interaction. After the TCP three-way handshake establishes a connection normally, the client performs an HTTP GET request for a 100MB bin file. The server responds with HTTP 200 OK, and then the file is transferred normally.

First of all, let’s talk about a frequently asked question: how to determine the capture point of the trace file?

1. IRTT , IRTT is 0.103362s. From the time difference of TCP three-way handshake SYN-SYN/ACK-ACK, it is preliminarily judged that the capture point is the client or a place close to the client;
2. Length : First, we can look at the length of the pure ACK packet. However, because the client and server both support TCP OPT timestamps after the TCP three-way handshake negotiation, the length of the pure ACK packet is not 54 bytes. We cannot judge that it is captured on the client based on the fact that it is less than 60 bytes, and the auxiliary judgment is invalid.
3. TTL , then check TTL. The client’s TTL is 64, which is still a Linux system-originated value. Because it is possible that it was captured on the Layer 2 access switch to which the client is connected (TTL is also 64), the auxiliary judgment is also invalid.

The trace file can only be determined to be captured on the client or in a Layer 2 switching environment close to the client.

Regarding how to determine the capture point of the trace file, interested students can refer to the previous complete article 

“Capture Point of TCP Three-Way Handshake” .

Back to the issue of fast data packet retransmission, the main information is as follows

At first glance, it seems to be no different from the normal fast retransmission phenomenon. The preliminary analysis process is as follows:

1. The packet No.20 sent by the server lost a TCP segment Seq 9577, so No.20 is marked as TCP Previous segment not captured;
2. The client responds to the first No.21 DUP ACK confirmation and needs Seq 9577 segment (the original ACK is in No.19);
3. The server’s next packet No. 22 is still not TCP segment Seq 9577;
4. Therefore, the client responds with the second No.23 DUP ACK to confirm that it continues to request Seq 9577 segments;
5. At this time, the server seems to have triggered a fast retransmission because of DUP ACK and sent the No.24 Seq 9577 data packet, so Wireshark marks it here TCP Fast Retransmisson.

So it seems that Wireshark’s judgment of fast retransmission is indeed reasonable, but after careful consideration, we will find some problems: IRTT , IRTT is 0.103362s, which means that the RTT between the client and the server is about 103ms. If the capture point is on the client, the time difference between No.24 and No.23 is only 71ns. From the client sending No.23 to the server receiving No.23 and triggering fast retransmission, and then to the client capturing, this 71ns time is completely inconsistent with reality.

But why does Wireshark judge it as a fast retransmission? This is naturally the logic of Wireshark TCP analysis, which TCP Fast Retransmissionis partially explained below (those who are interested can also directly view the source code). When the following conditions are fully met, Wireshark will mark it as a fast retransmission to replace out-of-order or retransmission.

TCP Fast Retransmission
Set when all of the following are true:

This is not a keepalive packet.
In the forward direction, the segment size is greater than zero or the SYN or FIN is set.
The next expected sequence number is greater than the current sequence number.
We have more than two duplicate ACKs in the reverse direction.
The current sequence number equals the next expected acknowledgement number.
We saw the last acknowledgement less than 20ms ago.

Supersedes “Out-Of-Order” and “Retransmission”.

From the above conditions, firstly, Wireshark does not consider the time difference of context packets, so it ignores the RTT problem; secondly, Wireshark considers that DUP ACK may be lost, so it will be judged as a fast retransmission when there are >= 2 DUP ACKs.

If the No.24 packet does not look like a fast retransmission , what is it? It is definitely not a timeout retransmission, so it can only be out of order . It is completely correct to re-examine the interaction process based on the logic of out of order.

1. TCP segment Seq 9577 of the data packet sent by the server is out of order and does not arrive before No. 20;
2. Because there is no TCP segment Seq 9577 before the packet No.20 sent by the server, No.20 is marked as TCP Previous segment not captured;
3. The client responds with the first No.21 DUP ACK to confirm that it wants the Seq 9577 segment (the original ACK is in No.19);
4. The server’s next packet No. 22 is still not TCP segment Seq 9577;
5. Therefore, the client responds with the second No.23 DUP ACK to confirm that it continues to request Seq 9577 segments;
6. At this time, the data packet TCP segment Seq 9577 sent by the server arrives late after being out of order, so Wireshark’s correct judgment should be marked here TCP Out-Of-Order.

This can also be IP.IDsupported by . The IP ID of No.24 is 49749, which is before No.20 and No.22, so it is undoubtedly out of order.

Let’s take a look at how the Cole analyzer judges it again. It accurately judges it as out of order .

Summary of the problem

The current version of Wireshark is Version 3.6.3 (v3.6.3-0-g6d348e4611e2). We have not yet investigated whether this is a bug or whether we can provide an enhancement to Wireshark. Or perhaps Wireshark believes that this TCP analysis implementation logic has its own reasons. Because there are indeed too many different phenomena in the world of data packets, everything is possible.