TCP Session – When is the First RTT Measurement Sampled?

the server will periodically retransmit the syn-ack and eventually timeout and abandon the connection entry if the final ack is not received.

This does consume some RAM and is the subject of DoS attacks. However there are operating system mitigations available - in linux minisocks are used to keep the footprint down and after a certain point you can transition to syncookies which don't require any server side state during this period. (but they have downsides).

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.