Jtdylktuy

In RFC 793 there is a part about the acknowledgment of TCP segments:

When the TCP transmits a segment containing data, it puts a copy on a
retransmission queue and starts a timer; when the acknowledgment for
that data is received, the segment is deleted from the queue. If the
acknowledgment is not received before the timer runs out, the segment
is retransmitted.

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.

Now, this is interesting. In our NOC, we often troubleshoot connectivity issues between our network and external client network and whenever we sniff traffic on a firewall and see SYN and ACK bits sent and received in both directions, we assume that the connectivity is established and the issue has nothing to do with network.

But now this RFC made me think - what else should I check (without setting up Wireshark) if TCP connection is established but the users are still experiencing connectivity issues?

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.

From the RFC perspective, the "end user" is the application. There's no guarantee that the application got the data, just that the TCP process received it.

From your NOC perspective, the network is functioning and data reached the end host. Presumably, that's all you care about.

You could see it this way.

You are M.Smith and you want to send a letter to M.Toto (persons are the application layer).

To send the letter, you go to your local post office A which will send the letter to M.Toto local post office B (post offices are the TCP layer).

Everything could run well between you, post office A and post office B - B will send an ACK to post office A. But nothing guarantees that the letter will arrive to M.Toto. Anything could happen between post office B and M.Toto.

That's basically what RFC says.