Duplicate ACKs can be generated a couple of ways, often due to packet loss:
- When sending a segment, the sender doesn't receive an ACK in a configured interval (200ms is very common, but this is often configurable), it retransmits that segment, duplicating the ACK that segment contained.
- When receiving, an unexpected segment number is received; causing the receiving party to re-ack the sequence number it was expecting. This notifies the sending party that a retransmit is probably needed. what happens next depends on Selective-ACKs, which is beyond the scope of this answer.
- When receiving, get a segment that has already been ACKed.
The first and third bullets are related. If the reason the sender didn't get its ACK is because the ACK got eaten by gremlins, the timer-based retransmit will be reACKing a segment as it retransmits. The receiver, having already ACKed that, will Dup-ACK it once again and wait for the next segment. If the gremlins don't eat that Dup-ACK, the sender will continue transmitting.
In your case, the timings of the packets suggest a timer-based dup-ACK isn't at play here. The largest RTT is 14ms. That suggests an erroneous retransmit on the sender's part, triggering the Dup-ACK. I've seen that behavior due to buggy network drivers, and even NIC firmware in the case of TCP-offload engines. Though, not all that recently.