Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Transport Layer Protocols            9  Transmission Control Protocol (TCP) and User Datagram Protocol (UDP)                 9  TCP/IP Transmission Control Protocol (TCP)                      9  TCP Reliability and Flow Control Features and Protocol Modifications

TCP Segment Retransmission Timers and the Retransmission Queue 1 2 3 4 TCP Adaptive Retransmission and Retransmission Timer Calculations

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!

TCP Segment Retransmission Timers and the Retransmission Queue 1 2 3 4 TCP Adaptive Retransmission and Retransmission Timer Calculations