---

TCP Reno: improving the performance of TCP Tahoe with Fast Recovery

---

• Making more sense out of the packet drop signal
  • Consider the following 2 scenarios:

    Heavy congestion: Characteristic: A large portion of the packets transmitted are dropped Moderate congestion: Characteristic: A few of the packets transmitted are dropped

    ---

  • Proper response for each scanrio:

    If some node in the network is heavily congested, we must reduce the network traffic drastically The proper response is to use slow start: Every sender will reduce its CWDN to 1 immediately The traffic rate will be reduced dratically and immediately If a node in the network are only moderately congested (and no node is heavily congested) we can resolve the congested situation by reduce the network traffic a little bit The slow start response is too drastic... A better response would be: Every sender will reduce its CWDN by half immediately But we must not allow the sender to increase the CWND too fast I.e., the sender must remain in the congestion avoidance mode

  ---

  ---

  ---

• How can the sender distiguish between heavy congestion and moderate congestion ?
  • Example of heavy congestion: a large portion of the transmitted packets are dropped

  • Example of moderate congestion: a few of the transmitted packets are dropped

    ---

  • Conclusion:

    In a moderate congestion network state, the sender will receive many duplicate ACK messages (Due to the fact that the receiver will respond with an ACK message when it receives new data But because there is some missing packet, the receiver must send an ACK with a lower ACK number) We can exploit the large number of duplicate ACK to identify the moderate congested state !!!

    ---

    ---

  • $64,000 question:

    How many duplicate ACKs should the receiver receive to decide between moderate congestion and heavy congestion ???

    Answer:

    3... This is the same number to trigger fast retransit (Maybe the designers want to piggyback the decision onto the fast retransmit code Afterall, the code to detect 3 duplicate ACKs is already available in TCP Tahoe)

   

   

  ---

  ---

  Fast Recovery

  ---

  ---

• The Fast Recovery method

  • Research finding:

    Most Fast Retransmit actions occur during moderate congested situations The retransmission was able to recover the loss packet correctly Putting TCP (Tahoe) in the slow start mode is actually wasting unused bandwidth (Because many TCP Tahoe connections use CWND = 1, the network links become underused !!!)

    ---

    ---

  • The Fast recovery method:

    When TCP receives 3 duplicate ACKs: set SSThresh = CWND/2 set CWND = SSThresh + 3 * MSS. (The rationel is that 3 duplicate ACK was triggered by 3 packets after the dropped packet - so the network could handle 3 MSS more bytes) TCP will continue to use congestion avoidance (because CWND > SSThresh).

  • Example:

    Notes:

    When TCP retransmits packet 14, it must also reset the time outs for packets 15, 16, ... that are still outstanding. Packet 14 can still timeout because the retransmitted packet is dropped If TCP times out, it will enter the slow start mode (TCP will now assume heavy congestion)

  ---

  ---

  ---

  ---

• TCP Reno
  • The TCP protocol that contain the Fast Recovery method is called TCP Reno

    TCP Reno is currently the most popular TCP protocol:

  ---

  ---

• TCP Reno Demo (Reno implements Fast Recovery)
  • Here is a NS2 source file to simulate a TCP Reno source: click here
    • Right click and save the file in your directory.
    • Run program with:

            /home/cs558000/bin/ns   Reno.tcl
      

    • You should see the Network Animator window when it finish running... click PLAY to see the simulation in action

  • You don't need to run the simulation to see the animation... I have saved a copy of the animation file generated by the simulation.

    The NAM (Network Animation) output file is here: click here

    To see the animation, save the NAM file in your directory and use this command:

        /home/cs558000/bin/nam   Reno.nam
    

  • The Congestion Window CWND plot data output file is here: click here
    To see the plot of the CWND of TCP, save the Congestion Window CWND plot file in your directory and run gnuplot

    In gnuplot, issue the command:

         plot "Reno-Window" using 1:2 title "Flow 1" with lines 1
    

    You should see this plot:

    You can see that this small change in TCP Reno has resulted in a huge performance improvement:

    1. Again, at time 20, TCP Reno is in congestion avoidance mode

    2. At approximately time 27, TCP Reno detects packet loss and performs a fast retransmit and the fast recovery was successful. TCP Reno continues in the congestion avoidance mode without performing a slow start (We can see this because CWND did not start with 1)

    3. Again, at approximately time 40, TCP Reno detects packet loss and performs a fast retransmit and the fast recovery was successful. TCP Reno continues in the congestion avoidance mode without performing a slow start (We can see this because CWND did not start with 1)

  ---

  ---

  ---

  ---