Internet Networking Spring 2002

1. Internet Networking Spring 2002 Tutorial 10 TCP NewReno

2. Fast Retransmit / Fast Recoveryin TCP • A sender uses fast retransmit / fast recovery algorithm to improve throughput of TCP • “Fast” – because it doesn’t wait for time outwhen not getting an ACK for a segment • In the old version (TCP Reno – RFC 2581) the algorithm can manage a loss at most of one packet • An improvement that will be shown in the tutorial (TCP NewReno – RFC 2582, not a standard yet) enables to the algorithm to manage a loss of more than one packet without changing message structure • Another improvement (TCP SACK – RFC2018, part of the standard) enables to cope with a loss of more than one packet by changing message structure

3. Fast Retransmit / Fast Recoveryin TCP Reno • Fast Retransmit – when the sender receives 3 “duplicative acks”, i.e. 3 identical acks for the ack that come before them, then it assumes that the segment was lost, retransmits the segment and moves to Fast Recovery phase • Fast Recovery – the sender decreases Congestion Window (cwnd) twice of its original size (assuming load on the network) and continue to send new segments until receiving new different Ack, which should acknowledge receiving all segments sent till moving to Fast Recovery phase (assuming that no more segments were lost). • All this instead of moving to Slow Start phase

4. Initial state cwnd=7 Slow start 0 1 Ack(1) 2 3 Ack(1) 4 Ack(1) 5 Ack(1) 6 Ack(1) Ack(1) cwnd=8 7 8 Ack(1) Ack(1) Fast Retransmitcwnd=8/2+3=7 Ssthresh=8/2=4 => Fast Recovery 1 cwnd=8 Ack(9) cwnd=9 9 Ack(10) cwnd=10 10 cwnd=11 11 Exit Fast Recoverycwnd=ssthresh=4 => Congestion Avoidance 12

5. Limitation of TCP Reno algorithm • If cwnd size is too small (smaller than 4 packets) then it’s not possible to get 3 duplicate acks and run the algorithm • The algorithm can not manage a loss of more than one packet before Fast Retransmit phase • It will cause a use of retransmission time out • The algorithm doesn’t manage a loss of packets during Fast Recovery stage • Not a loss of the retransmitted packet • There is no recursive run of Fast Retransmit

6. Sender Receiver Initial State cwnd=7 Slow Start 0 1 Ack(1) 2 3 Ack(1) The algorithm doesn’t know which segments were acknowledged 4 5 Flight Size =No. of Unacknowledged segments Ack(1) 6 Ack(1) cwnd=8 7 8 Ack(1) Ack(1) Fast Retransmitcwnd=8/2+3=7 Ssthresh=8/2=4 => Fast Recovery 1 Ack(3) cwnd=8 cwnd=9 9 Ack(3) Exit Fast Recoverycwnd=ssthresh=4 => Congestion Avoidance What was happen if this packet was lost? Flight Size > cwnd => No new segments

7. TCP NewReno • Idea: If the sender will remember a number of the last segment that was sent before entering Fast Retransmit phase, then it can deal with a situation when a “new” Ack (which is not duplicate ack) is not cover the last remembered segment (“partial ack”), i.e. this is a situation when more packets were lost before entering Fast Retransmit • Due to discovering such situation the sender will retransmit the new lost packet too and will stay at the Fast Recovery stage • The sender will finish Fast Recovery stage when it will get Ack that cover last segment sent before Fast Retransmit

8. TCP NewReno – Retransmissiondue to Partial Ack • When the sender gets a partial ACK, it retransmit the first unacknowledged segment • Deflate the congestion window by the amount of new data acknowledged, then add back one MSS and send a new segment if permitted by the new value of cwnd • This "partial window deflation" attempts to ensure that, when Fast Recovery eventually ends, approximately ssthresh amount of data will be outstanding in the network • Do not exit the Fast Recovery procedure (i.e., if any duplicate ACKs subsequently arrive)

9. Sender Receiver Initial State cwnd=5 Slow Start 0 1 Ack(1) 2 3 Ack(1) 4 Ack(1) cwnd=6 5 6 Ack(1) Fast Retransmitcwnd=6/2+3=6 Ssthresh=6/2=3 Recover=6 => Fast Recovery Ack(1) 1 cwnd=7 7 Ack(3) Ack(3) Recover >= Ack Partial Ack cwnd=7-(3-1)+1=6 3 cwnd=7 8 Ack(8) Ack(9) Recover < Ack Exit Fast Recoverycwnd=ssthresh=3 => Congestion Avoidance

10. TCP NewReno – Retransmission Timer • When a sender should reset the Retransmit Timer ? • In the “Impatient” variant – reset the timer only after the first Partial Ack. • As the result, invoking Slow-Start when retransmit timer will expire, especially when there are several packet lost and RTO is not much larger than RTT. • This approach cause fast retransmission of many packets (Slow Start) and it’s appropriate for the case of multiple packet drops

11. TCP NewReno – Retransmission Timer • When a sender should reset the Retransmit Timer ? • In the “Slow and Steady” variant – reset the timer after each Partial Ack • As the result, remaining in Fast Recovery for a long time, especially when there are multiple packet drops and RTO is much larger than RTT • This approach recovers lost packets slowly (one at each RTT) and therefore appropriate for the case of small number of packet drops

12. TCP NewReno Summary • Optimal version of TCP NewReno should recover more quickly from multiple packet drops retransmit packets and combined this with the Slow-but-Steady variant in terms of resetting the retransmit timers • Difficult to obtain this without the SACK option • But it still worthwhile to combine NewReno in the standard together with the Sack Option, because it’s demands changing an algorithm only at the sender side, without changing a message structure and therefore enables to improve TCP effectiveness also for receivers that not support SACK.