| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
TCP Non-Contiguous Acknowledgment Handling and Selective Acknowledgment (SACK) (Page 2 of 4) Policies For Dealing with Retransmission When Unacknowledged Segments Exist This then leads to an important question: how do we handle retransmissions when there are subsequent segments outstanding beyond the lost segment? In our example above, when the server experiences a retransmission timeout on Segment #3, it must decide what to do about Segment #4, when it simply doesn't know whether or not the client received it. In our worst-case scenario, we have 19 segments that may or may not have shown up at the client after the first one that was lost. We have two different possible ways to handle this situation. This is the more conservative, or if you prefer, optimistic approach. We retransmit only the segment that timed out, hoping that the other segments beyond it were successfully received. This method is best if the segments after the timed-out segment actually showed up. It doesn't work so well if they did not. In the latter case, each segment would have to time out individually and be retransmitted. Imagine that in our worst-case scenario that all 20 500-byte segments were lost. We would have to wait for Segment #1 to time out and be retransmitted. This retransmission would be acknowledged (hopefully) but then we would get stuck waiting for Segment #2 to time out and be resent. We would have to do this many times. This is the more aggressive or pessimistic method. Whenever a segment times out we re-send not only it but all other segments that are still unacknowledged. This method ensures that any time there is a hold up with acknowledgments, we refresh all outstanding segments to give the other device an extra chance at receiving them in case they too were lost. In the case where all 20 segments were lost, this saves substantial amounts of time over the optimistic approach. The problem here is that these retransmissions may not be necessary. If the first of 20 segments was lost and the other 19 were actually received, we'd be re-sending 9,500 bytes of data (plus headers) for no reason.
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. |