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.
etc. etc. until
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 Chang edited 22 Sep '16, 02:52 grahamb ♦ |
One Answer:
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 Jasper ♦♦ |
Thanks a lot Jasper, this answers my question.