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?
Best Answer
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.
I have always thought about it this way:
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:
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.