| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TCP Segment Retransmission Timers and the Retransmission Queue (Page 3 of 3) TCP Transaction Example with Retransmission Lets 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):
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 TCPs sliding window mechanism. Now lets 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 servers 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, lets 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 TCPs cumulative acknowledgment systemacknowledging #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. Theres 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 doesnt know that #3 is lost, and it also doesnt 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.
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. |