Analyze TCP ACK and Fast Retransmission Issues with Wireshark

Background

One day, a friend in the technical exchange group asked about a TCP ACK problem, saying that normally three ACKs will result in a fast retransmission, but he saw that some packets had many ACKs but were not retransmitted quickly.

To be honest, when I first saw this message, I thought it was unlikely. Even when I saw the problem picture, I didn’t react at first. It was only after I studied the original packet trace file myself that I really figured out what was going on.

Problem Information

Back to the question from the group member, in fact, his original words and screenshots are somewhat confusing. First of all, he kept describing ACK, including the picture showing that there are indeed many Ack=110033 messages, and then he mentioned why there is no fast retransmission.

This quick retransmission made me realize that there is no DUP ACK in the screenshot? ! ! !

Why is there no DUP ACK? I immediately thought of two possibilities.

1. The other party’s Wireshark version problem;
2. The other party modified some default configurations of Wireshark, so that the expert information was not displayed.

But after further communication with this group member, I learned that his version was already the latest Version 3.6.3 at the time, and he had not changed any special configuration. So I had to download the packet trace file myself and verify it myself.

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

λ capinfos scp_client_stream1.pcap
File name:           scp_client_stream1.pcap
File type:           Wireshark/tcpdump/... - pcap
File encapsulation:  Ethernet
File timestamp precision:  microseconds (6)
Packet size limit:   file hdr: 65535 bytes
Packet size limit:   inferred: 74 bytes
Number of packets:   158 k
File size:           13 MB
Data size:           136 MB
Capture duration:    962.546364 seconds
First packet time:   2016-12-09 16:08:26.208551
Last packet time:    2016-12-09 16:24:28.754915
Data byte rate:      141 kBps
Data bit rate:       1133 kbps
Average packet size: 862.03 bytes
Average packet rate: 164 packets/s
SHA256:              cf4037505f5cdfb434f5186c6de36195f64b1025f4e5136602d4656f00f5584d
RIPEMD160:           5c4de2a8620914b4961e88b5e099a497f765bf4c
SHA1:                ced52359b86d900c83569d5bbfda693735758011
Strict time order:   True
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 = 158232

λ

1. The packet trace file is captured by tcpdump ;
2. The file shows that the data size is 136 MB, but the actual trace file is only 13 MB because it was truncated to 74 bytes during capture.
3. The capture duration is about 962 seconds;
4. Average rate: 1133 kbps;
5. The number of packets is approximately 158232.

The expert information is as follows: there are many out-of-order, retransmission, fast retransmission and suspected retransmission phenomena, and the data packets initially appear to have many problems.

Problem Analysis

Let’s first study the first question , why is there no DUP ACK? When I opened the specific information of the data packet, I found the same phenomenon, no DUP ACK, and my Wireshark was also the latest version at that time, Version 3.6.3. Based on the creation of my own Wireshark tool, I am sure that I have not changed the relevant configuration. Then the interesting question is, what is going on?

Before the prompt No.133 TCP Previous segment not captured, there were several normal data interactions from No.127 to No.132:

1. The server sends two segments No.127-128, which are acknowledged by the client No.129 ACK, and the client hopes to receive the next data packet with Seq 107257.
2. The server continues to send two segments No.130-131, and the client No.132 ACKs and expects to receive the next data packet with Seq 110033.
3. We should see two more segments sent by the server, but the trace file shows that one segment was not captured. That is, the previous TCP segment indicated by No.133 was not captured, which is the segment starting with Seq 110033. Therefore, the client will reply No.134 ACK, hoping to receive the next data packet with Seq 110033. Here, No.134 should normally be the first DUP ACK .
4. The subsequent interactions between the server and the client are like this. Because the server has not sent the segment of Seq 110033, the client will keep replying ACK that it needs the segment of Seq 110033. Normally, these ACKs should all be DUP ACKs .

With these questions, I carefully compared and analyzed the data packets and found a problem. Wireshark did not mark ACK as DUP ACK in these places because the data packet trace file was cut into 74 bytes, resulting in the 4-byte right edge part of SACK in TCP Option being missing. In this case, Wireshark lacked a complete analysis of SACK, resulting in an analysis logic error and failure to identify a normal DUP ACK.

14 Ethernet II header + 20 IPv4 header + 40 TCP header (20 + 24 TCP Options)

I thought this problem was solved, but I didn’t expect that the same packet trace file can display DUP ACK normally. The version is Version 3.2.1, as shown in the figure below.

Well, if we continue to study, this problem is easier to figure out. It should be caused by the difference in Wireshark versions. By comparing several different green versions of Wireshark, we get the following answer:

1. Wireshark, after major version 3.6.0, does not display DUP ACK under the above condition of lack of TCP Option SACK;
2. WIreshark in major versions 3.4 or 3.2 will still display DUP ACK, although some judgment conditions are missing;
3. By comparing the versions, I personally feel that this change may be more related to Wireshark’s own design of TCP ACK rather than a BUG or other issues.

The above is disappeared TCP DUP ACKthe real reason. As for the more specific reasons, it may be necessary to trace back to the differences in code between different versions, so I will not go into it further here.

Some students may remember the question that group member wants to ask, why are there so many DUP ACKs but no fast retransmission ? In fact, this question is relatively easy to answer.

Pay attention to the time. The interval between the client ACK data segments is extremely short. It can be judged that the data packet trace file was captured on the client or close to the client. Then there will be such a scenario. There is a certain distance between the server and the client. That is, assuming that the RTT is tens of ms, when the server transmits multiple data segments to the client at one time, if a segment is lost, then from the client’s local point of view, it will naturally generate many DUP ACKs because of the continuous receipt of many data segments. The first three DUP ACKs are still on the way to the server at this time. It is not until the server actually receives and triggers a fast retransmission that the fast retransmission data packet is captured on the client, which is about 1 RTT later.

Taking the third DUP ACK packet of No. 138 as the reference time, the real fast retransmission packet of Seq 110033 appears in No. 201, with an interval of about 35 ms, which is about 1 RTT.

Summary of the problem

Some questions are simple but not simple. Always keep a curious mind and look at problems from different angles, and you will find some things very interesting.