1. 1 2004.5.18.  Last Class  This Class  Chapter 6.3. ~ 6.4.  TCP congestion control

2. 2 When congestion happens …  ssthresh = ½ of cwnd  In case of TCP Tahoe, cwnd = 1  When timeout happened/triple ACKs arrived  Start from minimum sending rate (slow start)  In case of TCP Reno, cwnd = ssthresh  When triple duplicate ACKs arrive  Sending rate decreased only by half (fast recovery)  When timeout happened, same as in Tahoe.

3. 3 Problems with TCP Reno  Triple ACKs often fails to be triggered due to either  Losses in burst  Small sending window  Timeout needs unnecessarily long delay.  Congestion control in Reno  Need to create packet losses to find the available bandwidth of the connection  Continually congesting the network  Creating losses for other connections sharing the link.  Oscillations

4. 4 TCP Vegas  Ideas  Detect congestion before losses occur Compare RTT between two ACKs If delay has increased, retransmit before a third ACK  Lower the rate when this imminent packet loss is detected Estimate the thruput by cwnd and RTT Increase/decrease cwnd by 1

5. 5 How would you compare Tahoe, Reno, and Vegas?  Which town offers best skiing?  Highest probability to win a jackpot?  All employ AIMD  Distributed – no coordination between connections needed?  Efficient – desired load level close to total?  Fairness – connections split the share equally?  Responsive to and smooth in equilibrium?

6. 6 Congestion Avoidance  Instead of reacting to congestion, try to predict when congestion is about to happen and reduce sending rates  DECbit  router sets congestion bit to notify users of impending congestion  Random Early Detection  Source-based Congestion Avoidance

7. 7 Random Early Drop (RED)  Main idea  Instead of waiting for the queue to get full to start dropping, it drops arriving packets with some drop probability whenver queue length exceeds some threshold.

8. 8 MaxTMinT MaxT Drop Probability 1 MaxP AvgQLen Drop all Drop with some p

9. 9 AvgQLen = (1-α) AvgQLen + α SampleLen Queue Length Time Average Instantaneous

10. 10 Drop Probability of RED TempP = MaxP ·(AvgQLen – MinT)/(MaxT-MinT) P = TempP/(1-count · TempP) count = # of pkts not dropped while MinT < AvgQLen < MaxT

11. 11 Source-Based Congestion Avoidance  Key idea  Figure out that some router’s queue is building up  Monitor RTT for increase

12. 12 Source-Based Congestion Avoidance Mechanisms 1.If CurrRTT > (minRTT+maxRTT)/2 Then decrease cwnd by 1/8 2.If (CurrW – OldW) x (CurrRTT – OldRTT) > 0 Then decrease cwnd by 1/8 Else increase cwnd by 1/8 3.Per RTT, increase/decrease cwnd by 1 pkt Compare thruput with previous one 4.TCP Vegas

13. 13 When congestion happens …  ssthresh = ½ of cwnd  In case of TCP Tahoe, cwnd = 1  When timeout happened/triple ACKs arrived  Start from minimum sending rate (slow start)  In case of TCP Reno, cwnd = ssthresh  When triple duplicate ACKs arrive  Sending rate decreased only by half (fast recovery)  When timeout happened, same as in Tahoe.

14. 14 Problems with TCP Reno  Triple ACKs often fails to be triggered due to either  Losses in burst  Small sending window  Timeout needs unnecessarily long delay.  Congestion control in Reno  Need to create packet losses to find the available bandwidth of the connection  Continually congesting the network  Creating losses for other connections sharing the link.  Oscillations

15. 15 TCP Vegas  Ideas  Detect congestion before losses occur Compare RTT between two ACKs If delay has increased, retransmit before a third ACK  Lower the rate when this imminent packet loss is detected Estimate the thruput by cwnd and RTT Increase/decrease cwnd by 1

16. 16 Quality of Service  Real-time applications  need more than best-effort  require some form of QoS guarantee  intolerant of loss/delay

17. 17 VoIP Timing Charts Sue speaks encoded and packetized at receiver played out

18. 18 QoS Support Approaches  IntServ’s RSVP  DiffServ  EF/AF  ATM  CBR  VBR-rt, VBR-nrt  ABR  UBR  Equation-based congestion control

19. 19 Next Class  HW #8 due  End-to-End data (Chap. 7)