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).
Next, some entries with retransmissions (normal too).
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.
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:
Any advice on why there are so many more duplicate ACKs than the retransmission events?
asked 22 Sep '16, 02:02
edited 22 Sep '16, 02:52
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:
answered 22 Sep '16, 04:07