Multiple DUP ACK for one packet

asked 2019-08-27 14:05:35 +0000

mkelley_25
5 ●1 ●1 ●3

I am trying to troubleshoot a "slow file upload speed" issue for a customer, and I have a Wireshark capture that shows seemingly HUNDREDS of DUP ACK's for one packet. I don't have enough "karma" to upload the capture file, so let me try this: https://1drv.ms/u/s!Ai804OSraN7whOMk4...

Packet 39 seems to be getting acknowledged hundreds of times, starting at packet 40 to packet 290. Then, same thing for packet 301, getting ACK'd hundreds of times from packet 302 to 927.

I've seen DUP ACK packets before, but never this many for seemingly the same source frame. Any ideas? Thank you in advance

edit retag flag offensive close merge delete

add a comment

answered 2019-08-27 14:29:27 +0000

SYN-bit

18528 ●9 ●343 ●255 https://SYN-b.it

Unfortunately your capture shows only one flow of the TCP connection and does not include the three-way-handshake (for iRTT calculation), so it is not possible to comment on your specific case. But...

In general, when there is a high bandwidth network, there are many packets being send per second. Whenever a packet is lost, all the other packets that are already on the wire will be received and will generate a DUP-ACK. For instance, when a TCP connection fully saturates a 1Gbit/s link with full-size frames, there are about 80.000 packets per second. If your RTT is 1 ms, you will have 80 packets on the way before the first DUP-ACK returns to the sender.

edit flag offensive delete link

Comments

Hi, thank you for answering so quickly. That capture file was filtered then exported. I uploaded the entire, unfiltered capture file (named 300719-1105-45MBDOWN.pcapng) to that same shared folder. The issue begins at packet 764. I also uploaded the 240719-1204-03MBDOWN.pcapng file, where you should find the three-way handshake between source 10.16.116.122 and destination 13.107.136.9 at packets 383 through 386. I hope that gives you the info you need, because I'm stuck, haha. Thank you again.

mkelley_25 ( 2019-08-27 14:44:45 +0000 )edit

Thank you for the new capture files. The round-trip-time for this connection is ~29 ms. When the client receives frame #761, it sees that it is missing a segment, so it sends a DUP-ACK. So, between the time that the server did send the frame with the segment that got lost and the time that it receives this DUP-ACK, ~29ms have passed. During that time, a lot of other segments were already put on the wire. Each of those will generate another DUP-ACK for the same missing segment. In frame 1264, the fast retransmission for the missing segment is received by the client. The delta between frame 1264 and frame 761 is ~29 ms.

SYN-bit ( 2019-08-27 15:07:00 +0000 )edit

Thank you so much for that info. So in short, it started with one missing segment, which has to be re-transmitted, and in the time it takes to do that, the other segments being put on the wire are now "out of order", (which shouldn't matter) and each of them must now also send a "hey, we're missing segment X" message back to the source, and duplicate ACK's must now be sent for each of them? Good grief, that's a lot of traffic generated for "one mistake," hahaha. Thank you again.

mkelley_25 ( 2019-08-27 15:24:37 +0000 )edit

Yup, you got it! :-)

If this answered your question, could you be so kind to click on the checkmark next to this answer so other people will know it has been answered?

SYN-bit ( 2019-08-27 17:22:46 +0000 )edit

add a comment

Multiple DUP ACK for one packet

1 Answer

Comments

Your Answer

Question Tools

Stats

Multiple DUP ACK for one packet edit

1 Answer

Comments

Your Answer

Question Tools

Stats

Multiple DUP ACK for one packet