This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Over 1,000 duplicate ACKs without TCP retransmission

0

I'm capturing packets using tshark at the server side (simple client-server setup with a number of routers in-between - the server is behind a NAT gateway). The client is connected to a private LTE network, so the air interface could cause some packet loss, which was expected.

During the capture, I've seem quite a few times where the client (10.5.21.32) sends over 1,000 duplicate ACK to the server. I've attached some of the typical entries below.

The format is:

Packet ID / timestamp / Source IP / Source Port / Dest IP / Dest Port / Length / Info

First, some entries with out-of-order packet arrivals (I think this is normal).

27011 1474467575.009112204   10.5.21.32 43880 10.5.3.229   8080 78 TCP 43880 → 8080 [ACK] Seq=2920 **Ack=82981452**
27012 1474467575.009180913   10.5.3.229 8080 10.5.21.32   43880 10202 TCP [TCP segment of a reassembled PDU]
27013 1474467575.009265903   10.5.3.229 8080 10.5.21.32   43880 5858 TCP [TCP segment of a reassembled PDU]
27018 1474467575.014182750   10.5.21.32 43880 10.5.3.229   8080 94 TCP [TCP Dup ACK 27011#1] 43880 → 8080 [ACK] Seq=2920 **Ack=82981452**
27019 1474467575.014185135   10.5.3.229 8080 10.5.21.32   43880 1514 TCP [TCP Out-Of-Order] [TCP segment of a reassembled PDU]

Next, some entries with retransmissions (normal too).

27122 1474467575.024498471   10.5.21.32 43880 10.5.3.229   8080 94 TCP [TCP Dup ACK 27011#61] 43880 → 8080 [ACK] Seq=2920 **Ack=82981452**
27123 1474467575.024500370   10.5.3.229 8080 10.5.21.32   43880 1514 TCP [TCP Retransmission] 8080 → 43880 [ACK] Seq=83052404 Ack=2920

Now is the questionable part: tshark keeps capturing duplicate ACKs with the same Seq and Ack numbers, even when there're no retransmissions or out-of-order packets.

27474 1474467575.045264093   10.5.21.32 43880 10.5.3.229   8080 94 TCP [TCP Dup ACK 27011#246] 43880 → 8080 [ACK] Seq=2920 **Ack=82981452**
27475 1474467575.045266169   10.5.3.229 8080 10.5.21.32   43880 4410 TCP [TCP segment of a reassembled PDU]

etc. etc.

until

28708 1474467575.145437844   10.5.21.32 43880 10.5.3.229   8080 94 TCP [TCP Dup ACK 27011#889] 43880 → 8080 [ACK] Seq=2920 **Ack=82981452**

which is the last dup ack in this case (889 in total). This happened a couple more times.

Note that all these dup acks were sent within a period of ~130ms. The RTT between client and server is ~20ms.

I've analyzed the entire trace (lasted ~7 min), and below are the statistics:

Out of order: 2655 packets, 4019670 bytes  
Retransmission: 3683 packets, 5542322 bytes  
Duplicate ACK: 42078  
Total packets: 844503

Any advice on why there are so many more duplicate ACKs than the retransmission events?

asked 22 Sep '16, 02:02

Chang's gravatar image

Chang
16337
accept rate: 0%

edited 22 Sep '16, 02:52

grahamb's gravatar image

grahamb ♦
19.8k330206


One Answer:

1

This is usually caused by buffer bloat: https://en.wikipedia.org/wiki/Bufferbloat

I also talked about this kind of thing in my Sharkfest 2015 talk available here, starting at 25:00:

https://www.youtube.com/watch?v=L5cbn2iF91s#t=25m00s

answered 22 Sep '16, 04:07

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks a lot Jasper, this answers my question.

(22 Sep '16, 04:58) Chang