From: Geoff Voelker To: cse222@cs.ucsd.edu Subject: Fast Recovery Date: Tue, 30 Jan 2001 20:53:26 -0800 (PST) I have received a few emails and verbal feedback saying that TCP Fast Retransmit and Fast Recovery are still a bit fuzzy and confusing. So I'm going to go through an example in more detail to try and make the behavior more clear. I'm going to use the simulation experiment from the SACK paper as an example, and to explain what happens I'll illustrate the TCP sender window as various events happen in the SACK paper graph timelines. You will probably find it very helpful to have the SACK paper with you as you go through this (Section 6.2: One Packet Loss). The behavior below corresponds to TCP Reno. The diagrams below represent the sender's sliding window. The numbers correspond to packet numbers (starting from 0). The line above the numbers correspond to the congestion window (its size and where it begins). The +'s below the numbers correspond to which packets have been acked. In the SACK simulations, the receiver's advertised window is effectively infinite (we only have to worry about the congestion window). The sender starts off in slow-start and sends packets in rounds. In the first round, one packet is sent (packet 0). When it is acked, the congestion window grows to 2 and two more packets are sent in the second round. These are acked, and in the third round four packets are sent. As these are acked, the congestion window is increased and more packets are sent until the congestion window is 8 and the next eight packets are sent (packets 7-14). This sequence is illustrated below as four rounds. Note that the last round has yet to be acked. - 0 + |-| 1 2 |+| |-----| 3 4 5 6 |+++++| |------------------| 7 8 9 10 11 12 13 14 XX At this point, we've sent out eight packets and we're waiting for acks to (1) increase the window and (2) send new data. Note that packet 14 is dropped (XX) in the simulation. Now we start to get acks back from the receiver for this round of packets sent. 7 8 9 10 11 12 13 14 |+++++++++++++++| XX |--------------...--| 15 16 17 18 ... 28 As acks arrive back from this last round, the congestion window increases from 8 to 15 (we get 7 acks, 8 + 7 = 15). It is still anchored at packet 14 since it has yet to be acked. In the SACK simulation, we receive 7 acks and so we send out 14 new packets (15-28). Even though our congestion window is 15, we don't send out a 15th new packet because the congestion window is still anchored at packet 14 (already sent). As packets 15-28 start to arrive at the receiver, the receiver will send back acks. Since packet 14 is dropped, these acks will all ack packet 13. In the diagram below, the receiver has received packets 15-17 and sends back three acks in return (but all for packet 13): 7 8 9 10 11 12 13 14 |+++++++++++++++| |--------------...--| 15 16 17 18 ... 28 |+| |+| |+| These three dup acks cause the sender to do a Fast Retransmit (original ack + 3 more (I was wrong about this in lecture -- you do need 3 dups in additon to the original)). The retransmitted packet will be the first one that has not been acked (14). The congestion window is halved to 7: 7 8 9 10 11 12 13 14 |+++++++++++++++| |--------...--| 15 16 ... 21 ... 28 Fast Retransmit -> 14 The sender is now in Fast Recovery. It will clock out packets as additional dup acks arrive (congestion window permitting), and will continue to do so until the dropped packet has been acked. As each dup ack arrives, the sender will also increase its congestion window by one. 7 8 9 10 11 12 13 14 |+++++++++++++++| |-----------...--| 15 16 17 ... 22 |+| Dup ack, increase congestion window by 1. Packet 22 has already been sent, so do nothing. 7 8 9 10 11 12 13 14 |+++++++++++++++| |--------------...--| 15 16 17 18 ... 23 |+| |+| Another dup ack, increase congestion window by 1. Again, packet 23 has already been sent, do nothing. 7 8 9 10 11 12 13 14 |+++++++++++++++| |--------...----...---| 15 16 ... 21 ... 28 Eventually, enough dup acks come back to increase the congestion window back to the size it was when packet 14 was dropped (size 15). Note that the congestion window is still anchored at packet 14. As more dup acks come back (still acking the group of packets 15-28 originally sent out), the sender's congestion window extends beyond the set of packets it has already sent. At this point, the additional dup acks clock out new packets: 7 8 9 10 11 12 13 14 |+++++++++++++++| |--------...----...-----| 15 16 ... 21 ... 28 29 |+| ^-- send in response to ack 7 8 9 10 11 12 13 14 |+++++++++++++++| |--------...----...--------| 15 16 ... 21 ... 28 29 30 |+| |+| ^-- send in response to ack When all of the dup acks have arrived, the sender's window looks like: 7 8 9 10 11 12 13 14 |+++++++++++++++| |--------...----...----------...--| 15 16 ... 21 ... 28 29 30 ... 34 Note that the sender is still in Fast Recovery mode. Now, finally, we get an ack corresponding to the retransmission of packet 14. Since there was only one drop, the retransmission fills in a gap and the receiver can ack all packets that it has received. In the SACK simulations, the receiver at this point has received packets up through 28, so the ack is for 28: 7 8 9 10 11 12 13 14 |+++++++++++++++| |--------...----...----------...--| 15 16 ... 21 ... 28 29 30 ... 34 |++++++++++++++++++++| Finally the sender exits Fast Recovery. It stops using the inflated congestion window (inflated during Fast Recovery) and goes back to using a congestion window of 7 (half the window when the packet was dropped). The window is anchored at the first packet that has not been acked (packet 29) and has size 7 (extends to 35): 7 8 9 10 11 12 13 14 |+++++++++++++++| |-----...-----| 15 16 ... 21 ... 28 29 30 ... 34 35 |++++++++++++++++++++| ^ This immediately enables the sender to send packet 35 ----/ * For brownie points and a gold star on your next eval: Redo this diagram for the two packet drop case. Laborious, I know, but I don't know how else to show what happens without all of the gory details. Hope this helps, -geoff