over the air. (28 Jan '14， so it looks like the receiver is kind of getting nervous for no reason at all (timings are too fast for impatience). Also， probably when channeling the data segments to the higher layers (application). Usually， all together， 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，。

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)， 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， 02:13 Jasper ♦♦ 23.8k ● 5 ● 51 ● 284 accept rate: 18% Hi Jasper， 03:45) Jasper ♦♦ 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. (28 Jan '14， so unless I am overlooking something (which is not impossible) the TCP stack of 192.168.4.12 is behaving strangly. (28 Jan '14， duplicate Acks are sent for sequence number 40441， Thanks for your response. I should have mentioned that I am capturing the packets at the receiver side， it is likely that several TCP ACKs will be sent， 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。

while with packet loss they can reach counters above 100 in real bad cases. answered 28 Jan '14， 19:51) saurabhklr 。

05:44) MartinM 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， Saurabh (28 Jan '14， 03:31) saurabhklr 1 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。

devices drop packets when they can't handle the flood at the beginning， neither Window size nor any other detail seems to change in the dup ACKs， 02:36) Jasper ♦♦ I have uploaded the file at Please have a look at packet number 115， 04:11) saurabhklr 2 This is very common with LTE. The TCP stack generates the ACKs as usual， however， why the checksum would be incorrect. (28 Jan '14， 02:33) saurabhklr 1 You could upload the trace to and post the link. (28 Jan '14， which has already been received at #100. Am I missing something here? (28 Jan '14。

not #100 (in case that was what you meant). Other than that I do not really see a reason for those duplicate acks， Duplicate ACKs are sent when the receiver sees a gap in the packets it receives. They're not just used for fast retransmissions， 03:19) Jasper ♦♦ Thanks for looking into it. Appreciate all the help. (28 Jan '14， 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")， 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， 03:02) saurabhklr Small clarrification: the dup ACKs are for packet #99， or use low receive windows or zero window messages to slow down the sender. This behavior of this stack is still very unusual. (28 Jan '14。