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):
- Segment #1:Sequence Number field is 1 and segment length is 80. So the last sequence number in Segment #1 is 80.
- Segment #2:Sequence Number field is 81 and segment length is 120. The last sequence number in Segment #2 is 200.
- Segment #3:Sequence Number field is 201 and segment length is 160. The last sequence number in Segment #3 is 360.
- 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 calledadaptive retransmission.