| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TCP Non-Contiguous Acknowledgment Handling and Selective Acknowledgment (SACK) (Page 1 of 4) Computer science people sometimes use the term elegant to describe a simple but effective solution to a problem or need. I think the term applies fairly well to the cumulative acknowledgment method that is part of the TCP sliding window system. With a single number, returned in the Acknowledgment Number field of a TCP segment, the device sending the segment can acknowledge not just a single segment it has received from its connection peer, but possibly several of them. We saw how this works in the topic on the fundamentals of sliding windows, and again in the previous topic on retransmissions. Even the most elegant technique has certain weaknesses, however. In the case of the TCP acknowledgment system, it is the inability to effectively deal with the receipt of non-contiguous TCP segments. The Acknowledgment Number specifies that all sequence numbers lower than its value have been received by the device sending that number. If we receive bytes with sequence numbers in two non-contiguous ranges, there is no way to specify this with a single number. This can lead to potentially serious performance problems, especially on internetworks that operate at high speed or over inherently unreliable physical networks. To see what the problem is, let's go back to the example in the previous topic. There, the server sent four segments, and received back an acknowledgment with an Acknowledgment Number value of 201. Segment #1 and Segment #2 were thus considered acknowledged. They would be removed from the retransmission queue, and this would also allow the server's send window to slide 80+120 bytes to the right, allowing 200 more bytes of data to be sent. However, let's again imagine that Segment #3, starting with sequence number 201, disappears. Since the client never receives this segment, it can never send back a acknowledgment with an Acknowledgment Number higher than 201. This causes the sliding window system to get stuck. The server can continue to send additional segments until it fills up the client's receive window, but until the client sends another acknowledgment, the server's send window will not slide. The other problem we saw is that if Segment #3 gets lost, the client has no way to tell the server that it has in fact received any subsequent segments. It's entirely possible that the client does receive the server's Segment #4, and in addition, later segments sent until the window filled up. But the client can't send an acknowledgment with a value of 501 to indicate receipt of Segment #4, because this implies receipt of Segment #3 as well.
And here we see the drawback of the single-number, cumulative acknowledgment system of TCP. We could imagine a worst-case scenario in which the server is told it has a window of 10,000 bytes, and sends 20 segments of 500 bytes each. The first segment is lost and the other 19 received. But since it is the first segment that never showed up, none of the other 19 segments can be acknowledged!
Home - Table Of Contents - Contact Us The TCP/IP Guide (http://www.TCPIPGuide.com) Version 3.0 - Version Date: September 20, 2005 © Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved. Not responsible for any loss resulting from the use of this site. |