I am doing an FTP of a file, the server where the file is placed is being accessed using an LTE dongle. While the while is being transferred I am seeing some duplicate ACKs, from what I have read about duplicate ACKs, I gathered that duplicate ACKs are sent for fast retransmission if some packet gets lost. But in my case I also see the sequence number for which duplicate ACKs are sent is received correctly, what could be the reason for duplicate ACKs then? Can someone please explain. Regards, Saurabh asked 27 Jan '14, 23:26  saurabhklr |
2 Answers:
Duplicate ACKs are sent when the receiver sees a gap in the packets it receives. They're not just used for fast retransmissions, it is the other way around (sort of): fast retransmissions use a counter for duplicate ACKs to trigger a retransmission faster than by Retransmission TimeOut (RTO). If you see duplicate ACKs coming in and no gaps in the packets going out it means that you capture at the source of the data (not the receiving side). That is quite normal if the packet loss occurs somewhere in the path to the receiver. You should see a retransmission though; if you don't you probably have a case where packets get reordered on the way and arrive out-of-order, which results in duplicate ACKs as well. The difference between packet loss and out-of-order is that the Duplicate ACK count is very low for out-of-order (often only going up to "Duplicate ACK #1"), while with packet loss they can reach counters above 100 in real bad cases. answered 28 Jan '14, 02:13  Jasper ♦♦ showing 5 of 9 show 4 more comments |
Old thread I know, but I had this on a 1gbps Ethernet port which some how had been taken off auto-neg and went in at 10mbps half duplex, the symptoms were exactly as described above and probably caused by the half-duplex setting creating packet loss/retransmit , the error counters on switch in question were quite busy too. answered 04 May '16, 03:42  Zer0kbps |
Hi Jasper,
Thanks for your response. I should have mentioned that I am capturing the packets at the receiver side, and in the wireshark logs I see that the receiver is sending duplicate ACKs even though no sequence numbers are missing. The duplicate ACK count goes to 15. What could be other scenarios where duplicate ACKs are sent? Please let me know if there is some way I can upload the wireshark logs for you or other members to have a look.
Thanks, Saurabh
You could upload the trace to http://www.cloudshark.org and post the link.
I have uploaded the file at http://www.cloudshark.org/captures/67e2d1911ecd Please have a look at packet number 115, duplicate Acks are sent for sequence number 40441, which has already been received at #100. Am I missing something here?
Small clarrification: the dup ACKs are for packet #99, not #100 (in case that was what you meant).
Other than that I do not really see a reason for those duplicate acks, which is quite odd. They're not fully duplicated packets (which would be a capture setup problem) since the IP-ID is different (incremented by 1 each), so it looks like the receiver is kind of getting nervous for no reason at all (timings are too fast for impatience).
Also, neither Window size nor any other detail seems to change in the dup ACKs, so unless I am overlooking something (which is not impossible) the TCP stack of 192.168.4.12 is behaving strangly.
Thanks for looking into it. Appreciate all the help.
Another thought: it seems to me that the receiving device needs some ramp-up time to get ready to handle the incomming flood of packets, because after packet 148 it seems to work fine. My guess is that the device needs some time to get the internal TCP stack mechanisms organized to deal with the incoming packets, probably when channeling the data segments to the higher layers (application).
Usually, devices drop packets when they can't handle the flood at the beginning, or use low receive windows or zero window messages to slow down the sender. This behavior of this stack is still very unusual.
There are duplicate ACKs again at #1397 and some more after that as well. This behavior certainly is strange. We are experencing large difference in speed of data transfer when using UDP (around 70 Mbps) as compared to TCP (around 5 Mbps). I think maybe this is one of the reasons for low throughput being achieved in case of TCP.
This is very common with LTE. The TCP stack generates the ACKs as usual, but they may very well be queued up for some time in LTE L2 before there is a grant to send them over the air interface is available. A Scheduling Request (SR) is sent to the network (and it may take several hundred milliseconds before the next chance rolls around). When a large enough grant does become available, it is likely that several TCP ACKs will be sent, all together, over the air.
It seems that the checksum of packet#100 is incorrect. So I believe this could be the reason duplicate ACKs are being sent. I am not sure, however, why the checksum would be incorrect.