13

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?

Improve this question
1
  • 5
    What this sentence means is simply the literal English meaning of the sentence: the fact that the network driver received the data (and acknowledged the reception) does not guarantee that the end user receives the data. There could be a bug in the web server, for example. With regards to your closing question: the only way to figure out whether the end user received the data, is to call them and ask them.
    – Jörg W Mittag
    Commented Dec 20, 2018 at 19:24

3 Answers 3

Reset to default
25

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.

Improve this answer
4
  • Another bullet item: even if the client process is running fine, it might not have read the data yet.
    – Barmar
    Commented Dec 20, 2018 at 22:09
  • 1
    The client process (if it is feeling lazy or perverse) might simply never call recv() on the socket, in which case the received data would remain in the TCP socket's receive-buffer indefinitely.
    – Jeremy Friesner
    Commented Dec 21, 2018 at 6:04
  • Thanks both, updated it to suggest the client process can be slow, buggy, fickle.
    – jonathanjo
    Commented Dec 21, 2018 at 11:51
  • You cannot rely on ACK to ensure that the application processed your input, you must implement an application layer ACK or Check. To put this in another context. For industrial control networks using TSN with an IP Stack on the client side, the TCP ACK is not sufficient to guarantee that process variables were latched. That is, you cannot rely on TCP ACK to put the system in a safe or serviceable state, you must have acknowledgment from an application layer service that it is safe to stick your hand in the machine.
    – crasic
    Commented Dec 21, 2018 at 19:06
10

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.

Improve this answer
1

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.