This part of the RFC is about passing responsibility over to the operating system or whatever is the next stage of the process. It's fundamentally concerned with the separation of layers.
An acknowledgment by TCP does not guarantee that the data has been delivered to the end user, but only that the receiving TCP has taken the responsibility to do so.
I have always thought about it this way:
- The OS could crash between sending the ACK and the data reaching the client process ("client" here means client of the OS, not "network client")
- The client process could be buggy or crash, or just much slower than anticipated to get round to dealing with its incoming data, or indeed only read it under non-obvious circumstances
- If the client is sending the data onwards, perhaps to a disk file, the file may not have been written or flushed yet
- If the client is sending the data onwards by TCP, the far side TCP may not have transmitted the data, received an ACK, or the far process successfully consumed the data
All it is saying is that this is a layer 3 acknowledgement ("I hear your bytes") not a higher layer acknowledgement. Consider for example the different between the TCP ACK, the SMTP
250 OK after the next-hop mail gateway accepts a message, a message receipt message (eg per RFC 3798), a message-opened tracking pixel, a thank-you note from a PA, and a reply saying "Yes I'll do it."
Another concrete example would be a printer:
- It must ACK the data early before it knows what the end of it contains (might be a Postscript file beginning with an included library bigger than the TCP transmit window)
- It might contain a status query ("do you have paper?", which it can obviously execute)
- It might contain a print command ("please print this", which it might fail, if out of paper)
I would suggest that if users are seeing and sending ACKs but still experiencing connectivity issues, it is orders of magnitude more likely that there are congestion, OS, or application issues than anything strictly network-related.
To diagnose I suggest looking for retransmits, rather than the ACKs specifically.