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 Transaction Example with Retransmission

Let’s use an example to clarify how acknowledgments and retransmissions work in TCP (illustrated in Figure 223, to which you may wish to refer as you read on). Suppose the server in a connection sends out four contiguous segments (numbered starting with 1 for clarity):

1. Segment #1: Sequence Number field is 1 and segment length is 80. So the last sequence number in Segment #1 is 80.
   
   
2. Segment #2: Sequence Number field is 81 and segment length is 120. The last sequence number in Segment #2 is 200.
   
   
3. Segment #3: Sequence Number field is 201 and segment length is 160. The last sequence number in Segment #3 is 360.
   
   
4. Segment #4: Sequence Number field is 361 and segment length is 140. The last sequence number in Segment #4 is 500.
   

   Figure 223: TCP Transaction Example With Retransmission

   This diagram illustrates a simple transaction and shows the server’s send pointers and client’s receive pointers. The server sends three segments to the client in rapid succession, setting a retransmission timer for each. Parts 1 and 2 are received and the client sends an Acknowledgment for them; upon receipt of this ACK, 1 and 2 are taken off the retransmission queue. However, Part 3 is lost in transmit. When Part 4 is received, the client cannot acknowledge it; this would imply receipt of the missing Part 3. Eventually the retransmission timer for Part 3 expires and it is retransmitted, at which time both Part 3 and Part 4 are acknowledged.

   
   

Again, these can be sent one after the other without having to wait for each preceding transmission to be acknowledged; this is a major benefit of TCP’s sliding window mechanism.

Now let’s say the client receives the first two transmissions. It will send back an acknowledgment with an Acknowledgment Number field value of 201. This tells the server that the first two segments have been successfully received by the client; they will be removed from the retransmission queue (and the server’s send window will slide 200 bytes to the right). Segment #3 will remain on the retransmission queue until a segment with an Acknowledgment Number field value of 361 or higher is received; Segment #4 requires an acknowledgment value of 501 or greater.

Now, let’s further suppose in this example that Segment #3 gets lost in transit, but Segment #4 is received. The client will store Segment #4 in its receive buffer, but will not be able to acknowledge it, because of TCP’s cumulative acknowledgment system—acknowledging #4 would imply receipt of #3 as well, which never showed up. So the client will have to simply wait for #3. Eventually, the retransmission timer that the server started for Segment #3 will expire. The server will then retransmit Segment #3. It will be received by the client, which will then be able to acknowledge both #3 and #4 to the server.

There’s another important issue here, however: how exactly the server should handle Segment #4. While the client is waiting for the missing Segment #3, the server is receiving no feedback; it doesn’t know that #3 is lost, and it also doesn’t know what happened to #4 (or any subsequent transmissions.) It is possible that the client has already received Segment #4 but just couldn't acknowledge it. Then again, maybe Segment #4 got lost as well. Some implementations may choose to only re-send Segment #3, while some may choose to re-send both Segment #3 and Segment #4. This is an important issue that is discussed in more detail in the next topic.

A final issue is what value we should use for the retransmission timer when we put a segment on the retransmission queue. If it is set too low, excessive retransmissions occur; if set too high, performance is reduced due to extraneous delays in re-sending lost segments. In fact, TCP cannot use a single number for this value; it must determine it dynamically using a process called adaptive retransmission.

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