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 Reliability and Flow Control Features and Protocol Modifications 1 2 3 TCP Non-Contiguous Acknowledgment Handling and Selective Acknowledgment (SACK)

TCP's basic data transfer and acknowledgment mechanism uses a set of variables maintained by each device to implement the sliding window acknowledgement system. These pointers keep track of the bytes of data sent and received by each device, as well as differentiating between acknowledged and unacknowledged transmissions. In the preceding section I described this mechanism, and gave a simplified example showing how a client and server uses them for basic data transfer.

One of the reasons why that example is simplified is that every segment that was transmitted by the server was received by the client, and vice-versa. It would be nice if we could always count on this happening, but as we know, in an Internet environment this is not realistic. Due to any number of conditions, such as hardware failure, corruption of an IP datagram or router congestion, a TCP segment may be sent but never received. To qualify as a reliable transport protocol, TCP must be able detect lost segments and retransmit them.

The method for detecting lost segments and retransmitting them is conceptually simple. Each time we send a segment, we start a retransmission timer. This timer starts at a predetermined value and counts down over time. If the timer expires before an acknowledgment is received for the segment, we retransmit the segment.

TCP uses this basic technique but implements it in a slightly different way. The reason for this is the need to efficiently deal with many segments that may be unacknowledged at once, to ensure that they are each retransmitted at the appropriate time if needed. The TCP system works according to the following specific sequence:

• Placement On Retransmission Queue, Timer Start: As soon as a segment containing data is transmitted, a copy of the segment is placed in a data structure called the retransmission queue. A retransmission timer is started for the segment when it is placed on the queue. Thus, every segment is at some point placed in this queue. The queue is kept sorted by the time remaining in the retransmission timer, so the TCP software can keep track of which timers have the least time remaining before they expire.
  
  
• Acknowledgment Processing: If an acknowledgment is received for a segment before its timer expires, the segment is removed from the retransmission queue.
  
  
• Retransmission Timeout: If an acknowledgment is not received before the timer for a segment expires, a retransmission timeout occurs, and the segment is automatically retransmitted.

Of course, we have no more guarantee that a retransmitted segment will be received than we had for the original segment. For this reason, after retransmitting a segment, it remains on the retransmission queue. The retransmission timer is reset, and the countdown begins again. Hopefully an acknowledgment will be received for the retransmission, but if not, the segment will be retransmitted again and the process repeated.

Certain conditions may cause even repeated retransmissions of a segment to fail. We don't want TCP to just keep retransmitting forever, so TCP will only retransmit a lost segment a certain number of times before concluding that there is a problem and terminating the connection.

TCP Reliability and Flow Control Features and Protocol Modifications 1 2 3 TCP Non-Contiguous Acknowledgment Handling and Selective Acknowledgment (SACK)