1
I use firefox to visit a web server running on a computer on my LAN. I notice that sometimes TCP doesn't acknowledge the packets it receives. For example, in the following captured packets:
https://docs.google.com/file/d/0B-LaBUj9KtQhS0RYNXF1RjZTa2M/edit?usp=sharing
the 7th 9th and 11th packets are duplicated ACK, the browser receives TCP packets 6,8 and 10, but the browser TCP stack doesn't acknowledge the received packets, why?
misteryes
Posted 2013-06-19T20:32:42.547
Reputation: 2 255
3
It does.
You're probably seeing TCP Delayed Acknowledgement, in which the recipient can delay up to 500ms in order to send a combined ACK packet which acknowledges multiple packets that were received. This is good for reducing overhead when you have a lot of packets and don't particularly care about latency.
This can increase perceived latency, and so this feature is what you see disabled in many "TCP Fixes" that you can find for games: by setting the TCP_ACKNOWLEDGE_DELAY to 0, Windows will send all ACKs immediately instead of trying to group them. This has the downside of creating more network traffic, with little benefit. It gives the appearance of lowering latency, but the data packets aren't sent any faster.
Darth Android
Posted 2013-06-19T20:32:42.547
Reputation: 35 133
It's too bad that both delayed-ack and Nagle's Algorithm entered use without any standardized means by which packets can indicate that the sender will want immediate acknowledgment, since there are some situations where the combination will frequently deadlock and only get rescued only by the half-second timeout (in some cases, degrading throughput by orders of magnitude). – supercat – 2015-09-02T18:21:39.277
did you see my captured packets? I think TCP delayed ACK can't explain the captured packets – misteryes – 2013-06-20T09:06:45.057
1The comment about ack delay also ignores Nagle. When the early ack arrives, it tells the sending site to send the next packet immediately. This does lower latency. – MSalters – 2013-06-28T12:23:28.503
3
It doesn't.
It just acknowledges each byte of the stream, which is quite different. For some reason, the receiver's TCP (the one with the browser running on top of it) misses segment #6. As the receiver immediately requests its retransmission, it must have received it with a checksum mismatch.
All subsequently received segments (8, 10, 12) are out-of-order segments and trigger duplicate acks, woose purpose is to request retransmission of segment #6. As the communcation path between receiver and sender experiences some latency, the sender notices this a bit late, reduces its pipe length (aka congestion window) and retransmits the data contained in segment #6.
Then another interesting thing happens in segment #15: the receiver does not send a cumulative acknowledgement over 8, 10, 12 but acknowledges only segment #14 which means it has discarded 8, 10 and 12, either because they were as well subject to data corruption or because it's a very simple TCP implementation. You can enable TCP checksum evaluation in wireshark, (it fails here at each outgoing segment due to the OS leaving the checksum field invalid for the ethernet card to evaluate) and it confirms the former interpretation: checksum errors on 8, 10, 12. There must be a very noisy link on the path.
artistoex
Posted 2013-06-19T20:32:42.547
Reputation: 3 353
1
Possible duplicate of: Why is client side tcp sometimes not sending ACKs, leading to retransmits? (on Stack Overflow). I also don't think this is constructive as it sits, as it really depends on so many things (what software/browser is being used, the NIC driver, the inner workings of the OS's TCP/IP stack, and how any network equipment routes the data).
– Breakthrough – 2013-06-19T20:41:16.227it is in LAN, and firefox. The question in stackoverflow is not answered... – misteryes – 2013-06-19T21:05:41.627
1
@misteryes Firefox is not involved at all in this. Individual packets are handled by the network (LAN), NIC driver, OS and the TCP/IP stack. If I can remember correctly, it's possible for an ACK to respond for multiple packets, i.e., the ACK for packets 10 and 11 might be combined into a single ACK packet.
– Darth Android – 2013-06-19T21:54:48.677@breakthrough I think the underlying problem is quite instructive as it exposes some of the more subtle aspects of TCP and thereby challenges common misconceptions. – artistoex – 2013-06-28T10:33:54.243