TCP packets ACKed ~50ms after

[JMarq.1]

Hi, two years ago I posted this thread:

Solved: How to set "Don't fragment" flag LWIP short TCP pa... - STMicroelectronics Community

Now I just was reviewing it for another application that truly needed to send more data and was not allowed to wait 50ms for every sent packet.

Final root cause explanation

The 415-byte packets were being ACKed after ~40–50 ms because I was only sending one TCP segment at a time and waiting for it to be acknowledged within my application code, before sending the next one.

This behavior is due to the TCP Delayed ACK algorithm implemented by Windows. When Windows receives a single TCP segment smaller than the MSS, it does not immediately send an ACK. Instead, it waits approximately 40–50 ms before acknowledging it.

This behavior is described in RFC 1122, section 4.2.3.2 ("When to Send an ACK Segment"), which explains that a TCP implementation may delay sending an ACK in order to reduce protocol overhead.

If a second TCP segment is received before the delayed ACK timer expires, Windows immediately sends a single ACK acknowledging both segments.

After modifying my implementation to send two TCP segments consecutively (without waiting for the first ACK), Windows responds immediately with a combined ACK, and the 40–50 ms delay disappears.

So the issue was not related to Don't fragment flag, LwIP configuration, MSS, or buffer sizes, but rather to my application-level logic implementing a stop-and-wait pattern on top of TCP.

Sorry for getting you confused.

Best regards.

[STackPointer64 · Accepted solution]

Hello @JMarq.1 ,

---

@JMarq.1 wrote:

Hi, two years ago I posted this thread:

Solved: How to set "Don't fragment" flag LWIP short TCP pa... - STMicroelectronics Community

Now I just was reviewing it for another application that truly needed to send more data and was not allowed to wait 50ms for every sent packet.

Final root cause explanation

The 415-byte packets were being ACKed after ~40–50 ms because I was only sending one TCP segment at a time and waiting for it to be acknowledged within my application code, before sending the next one.

This behavior is due to the TCP Delayed ACK algorithm implemented by Windows. When Windows receives a single TCP segment smaller than the MSS, it does not immediately send an ACK. Instead, it waits approximately 40–50 ms before acknowledging it.

This behavior is described in RFC 1122, section 4.2.3.2 ("When to Send an ACK Segment"), which explains that a TCP implementation may delay sending an ACK in order to reduce protocol overhead.

If a second TCP segment is received before the delayed ACK timer expires, Windows immediately sends a single ACK acknowledging both segments.

After modifying my implementation to send two TCP segments consecutively (without waiting for the first ACK), Windows responds immediately with a combined ACK, and the 40–50 ms delay disappears.

So the issue was not related to Don't fragment flag, LwIP configuration, MSS, or buffer sizes, but rather to my application-level logic implementing a stop-and-wait pattern on top of TCP.

Sorry for getting you confused.

Best regards.

---

Thank you very much for your detailed explanation and for sharing your findings. I truly appreciate the time you took to clarify the root cause and how the TCP Delayed ACK algorithm affected your application. Your insights are very helpful and clear, and I’m grateful for your effort in revisiting this issue and providing the update.

To make this post more visible and easier to find by others who may face the same issue, I mark my reply as the solution.

Best regards,