1 / 27

Comparison between TCPWestwood and eXplicit Control Protocol (XCP)

This report presents a detailed comparison between TCP Westwood (TCPW) and Explicit Control Protocol (XCP), focusing on the shortcomings of traditional TCP in handling high bandwidth-delay environments. The discussion covers how TCPW and XCP improve congestion control mechanisms, specifically through enhanced data flow management and feedback systems. Simulation results demonstrate the performance benefits of XCP, which achieves faster convergence to link capacity and better fairness allocation. The report outlines both protocols' algorithms and their impact on throughput, fairness, and congestion management.

sidone
Télécharger la présentation

Comparison between TCPWestwood and eXplicit Control Protocol (XCP)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Comparison between TCPWestwood and eXplicit Control Protocol (XCP) Jinsong Yang Shiva Navab CS218 Project - Fall 2003

  2. Outline • Traditional TCP shortcomings • How TCPW and XCP address those shortcomings • XCP: eXplicit Control Protocol • TCPW: TCP Westwood • Simulation Results

  3. Traditional TCP Shortcomings in High BW*Delay • Congestion Detection • Based on receiving ACK (congested or not) • No information on degree on congestion • Reaction to Random Loss • Throughput inversely proportional to RTT • Unfairness in different RTT • Reaching to the full link capacity in high BW • AIMD increase Cwind 1 per RTT • Short Flows can cause instability in high BW • Never exit slow start exponential increase

  4. Addressing TCP problemsCongestion Control Mechanism • TCPW • Rate Estimate based on ACK rate • Modification on the Sender • XCP • Based on INFORMATON on each ACK header • Modification on Sender, Receiver and Router

  5. TCP Westwood • Enhance congestion control via Eligible Rate Estimates (ERE) • Estimates are computed at the sender by sampling and exponential filtering methods • ERE determined from ACK arrival process statistics and info in ACKs regarding amounts of bytes delivered • ERE is used by sender to appropriately set cwnd and ssthresh after packet loss or during slow start

  6. TCPW Algorithm • When three duplicate ACKs are detected: • set ssthresh=ERE*RTTmin (instead of ssthresh=cwin/2 as in Reno) • if (cwin > ssthresh) set cwin=ssthresh • When a TIMEOUT expires: • set ssthresh=ERE*RTTmin (instead of ssthresh=cwnd/2 as in Reno) and cwin=1 Note: RTTmin = min round trip delay experienced by the connection and is an estimate of the propagation time over the path (roundtrip)

  7. eXplicit Control Protocol (XCP) • Senders express their setting (cwnd, RTT) to routers, and routers express changes required to senders • Exchange of information in packet header • Recognizes two types of requirements for Congestion Control: • Efficiency:Achieve high link utilization • Allocation:Allocate bandwidth according to desired criteria; e.g. fairness, QoS, etc.

  8. XCP Sender and Receiver • Sender • Receiver • Similar to TCP receiver (send back ACK) • But it copies the header of packet to ACK

  9. XCP Router • Approach: Decouple controls for efficiency and allocation • Control aggregate traffic to achieve efficient link utilization • Divide link bandwidth among connections to achieve desired criteria

  10. Efficiency Controller • Goal: Match aggregate input traffic to link capacity & drains the queue • Algorithm(MIMD): •  :Aggregate feedback (increase or decrease) •  increases with an increase in spare BW • decreases with an increase in the router queue size; i.e. • S: Spare Bandwidth & Q: Queue Size • d: Current router’s estimate of RTT

  11. Fairness Controller • Goal: Divide  among flows to converge to fairness criteria • Algorithm (AIMD): • If> 0 ⇒ Divide  equally between flows (regardless of current rate) • If < 0 ⇒ Divide  between flows in proportion to their current rates • If  = 0 ⇒ bandwidth Shuffling • Allocate & deallocate BW such that total traffic range doesn’t change y= input traffic in avg RTT

  12. Fairness Controller • Feedback field: • Positive Feedback: • Negative Feedback:

  13. Addressing TCP problemsReaction to Error Loss • TCP Reno • Halves cwind for each loss (error or overflow) • TCPW: • A small fraction of isolated “randomly” lost packets does not impact the ERE value in TCPW Thus, cwnd = ERE * RTTmin remains unchanged • XCP: • Distinguishes Random loss and recovers fast • Congestion drop will be preceded with a ACK (to tell the sender to decrease its cwind)

  14. Addressing TCP problemsReaching to Full Link Capacity • TCP Reno • AIMD- increasing 1 per RTT • TCPW • Doesn’t reduce cwind drastically catches up fast • XCP • Reaches the full capacity in several RTT based on the information about the spare bandwidth on the received ACK

  15. Pros of XCP • Stable for Bandwidth and delay • Uses AQM • Parameters independent of environment • Scalable for number of flows • No per flow state  keeps the state in the header • Almost NO Packet Drop • No slow start • Reaches to full capacity fast • Smaller queue size comparing to other queuing schemes

  16. Cons of XCP • Needs router participation • deployment might prove to be difficult • Malicious Sender can falsify the header and mess up the feedback calculation • Issue: Uses average RTT • Problem if RTT varies in a large range

  17. Simulation Results-NS2 • Topology • Bottleneck • single hop • Parameters • Bandwidth • Delay • Loss Rate • Number of Flows

  18. Throughput Comparison BW=20M Delay=10ms No Loss

  19. Impact of Capacity Single Flow Different BW Delay= 10ms

  20. Impact of Link Delay Different Delay BW= 20Mbps No Loss

  21. Different Loss Rate BW=20 Mbps Delay= 10ms

  22. Impact of Loss Rate Diff. Loss Rate BW= 20Mbps Delay= 10ms

  23. Impact of Number of Flows BW=10 Mbps Delay=20ms

  24. Impact of Web-Like Traffics BW 10 Mb, # of Short Flows 500, Start @ Random Time, Running for 1 sec ,Link Delay 45 ms 500/30=17 10M/18=0.55M XCP not friendly

  25. Fairness Study – No Loss TCPW XCP BW=100 Mbps Delay=20 ms

  26. Fairness Study – Different Delay TCPW XCP BW=20 Mbps d1=10, d2=50, d3=100ms

  27. References • [1] Katabi, D., M. Handley, C. Rohrs. Internet Congestion Control for Future High Bandwidth-Delay Product • [2] M. Gerla, M. Y. Sanadidi, R. Wang, A. Zanella, C. Casetti, S. Mascolo, "TCP Westwood: Congestion Window Control Using Bandwidth Estimation", In Proceedings of IEEE Globecom 2001, Volume: 3, pp 1698-1702, San Antonio, Texas, USA, November 25-29, 2001 • [3]Mascolo, S., C. Casetti, M. Geral, M. Y. Sanadidi, R. Wang. TCP Westwood: Bandwidth Estimation for Enhanced Transport over Wireless Links • [4] Ren Wang, Massimo Valla, M. Y. Sanadidi, and Mario Gerla, Adaptive Bandwidth Share Estimation in TCP Westwood, In Proc. IEEE Globecom 2002, Taipei, Taiwan, R.O.C., November 17-21, 2002 • [5]Claudio Casetti, Mario Gerla, Saverio Mascolo, M.Y. Sansadidi, and Ren Wang, TCP Westwood: End-to-End Congestion Control for Wired/Wireless Networks, In Wireless Networks Journal 8, 467-479, 2002 • More TCP Westwood papers on http://www.cs.ucla.edu/NRL/hpi/tcpw/ • [6] Network simulator ns-2. http://www.isi.edu/nsnam/ns • [7] Sally Floyd, HighSpeed TCP for Large Congestion Windows Internet draft draft-ietf-tsvwg-highspeed-01.txt, work in progress, August 2003. • [8] Red parameters http://www.icir.org/floyd/red.html#parametes

More Related