This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP ACK Behavior

0

I've been doing a lot of reading to try and conclusively determine the behaviour of ACKs (specifically delayed-ACKs) over TCP. I understand the concepts of delayed-ACKs but I'm trying to figure out how the receiving device determines when/how often to send an ACK.

The extract below may help determine what I mean - This is a single reassembled HTTP GET (to bbc.co.uk) fragmented accordingly but what has got my interested is the varying ACK response. Sometimes every packet appears to be ACK'd, sometimes every other packet (which I understand to be typical delayed-ACK behaviour), but then I also see 3, 4, or more ACK-less packets before an ACK is sent.

Can anyone possibly give me an answer as to not only why this behaviour is seen, but also how the client and server at either end would know to wait for 2 packets before an ACK, then wait for 4, etc. Have I missed anything in the packet detail itself that perhaps tells me this?

alt text

Many thanks for any help!

asked 29 Dec '14, 02:41

MetalMike's gravatar image

MetalMike
16114
accept rate: 0%


One Answer:

4

It is not necessary to "wait" for an ACK on either side unless the advertised window of the other side was completely used (which Wireshark diagnoses as "TCP Window Full" in most cases), so it doesn't matter if the receiver acks 1,2,3 or more packets in a single ACK.

The only thing it needs to do is to ACK when its own receive window is full. This ususally never (or at least should not) happens because every other packet is ACKed. You could call this "premature" ACK, because packets are acknowledged when there really is no need - but of course it helps keeping a fluid conversation if you ACK packets in a nice rhythm. It prevents the sender having to wait until the ACK comes in when the window is full.

Other than that, the ACK rhythm is determined (often based on some kind of heuristics) by each TCP stack, so it's hard to say why it was done in a certain pattern. A typical thing is that either every other packet is ACKed, or that you see receivers acking more and more packets in a single ACK when a lot of packets are transmitted in short order.

So lets say you have a stack that is set to wait for 200ms before ACKing a new packet to see if more packets come in that it could ACK with a single packet. If packets come in fast you may have 3 or more fitting into that time frame, which would mean all of them could be ACked in one packet. If they come in slow it will only ACK 2, or sometimes even just 1 packet if the delayed ACK timer runs out before another packet comes in. This usually happens for the last packet in a transmission if there is an odd number of segments.

answered 29 Dec '14, 03:11

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks very much Jasper, this explains it for me perfectly.

(29 Dec '14, 03:25) MetalMike