1 / 20

“Promoting the Use of End-to-End Congestion Control in the Internet”

“Promoting the Use of End-to-End Congestion Control in the Internet”. Sally Floyd, Kevin Fall in Proceedings of IEEE/ACM Transactions on Networking, 1999 A Summary by Ashish Samant CS577 – Spring 2005. Outline. Need for end-to-end congestion control Unfairness, Congestion Collapse

adamtaylor
Download Presentation

“Promoting the Use of End-to-End Congestion Control in the Internet”

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. “Promoting the Use of End-to-End Congestion Control in the Internet” Sally Floyd, Kevin Fall in Proceedings of IEEE/ACM Transactions on Networking, 1999 A Summary by Ashish Samant CS577 – Spring 2005 CS577 Spring 2005

  2. Outline • Need for end-to-end congestion control • Unfairness, Congestion Collapse • Per flow based scheduling Vs Congestion Control mechanisms at the router • Identifying candidate flows for regulation • Other incentives for flows CS577 Spring 2005

  3. Introduction • End hosts/applications may not use end-to-end congestion control schemes. • Problem - This may lead to congestion collapse and unfairness, in times of congestion. • Solution – Isolate ill-behaving flows, use per-flow based queuing at routers. • This may not be sufficient !! CS577 Spring 2005

  4. Introduction …. continued • Authors suggest - Routers must support congestion control and regulate high-bandwidth flows. • Routers must regulate ‘best effort flows’ that are TCP-Unfriendly, unresponsive to congestion, use disproportionate bandwidth. CS577 Spring 2005

  5. Introduction …. continued • Unresponsive flows cause two problems - Unfairness; well-behaved flows may suffer bandwidth starvation because unresponsive flows do not react to congestion. - Congestion collapse; the scarce bandwidth of the network is consumed by packets from unresponsive flows, that will be discarded sooner or later. CS577 Spring 2005

  6. Experimental Setup CS577 Spring 2005

  7. Unfairness – 3 TCP, 1 UDP flow, FCFS CS577 Spring 2005

  8. Fairness – 3 TCP, 1 UDP flow, WRR CS577 Spring 2005

  9. Congestion Collapse – 3 TCP, 1 UDP flow, FCFS CS577 Spring 2005

  10. Congestion Control – 3 TCP, 1 UDP flow, WRR CS577 Spring 2005

  11. Congestion Control – 3 UDP, 1 TCP flow, WRR CS577 Spring 2005

  12. Identifying non TCP-Friendly Flows • TCP Friendly Flow – arrival rate does not exceed that of any other TCP conformant flow. • Maximum sending rate for a TCP Friendly flow : T - sending rate ; p - packet drop rate ; B – max packet size ; R – minimum RTT • Actual rates will be less than T. CS577 Spring 2005

  13. Identifying non TCP-Friendly Flows • Limitations : Inconsistencies in finding packet size, round trip time. Measurements should be taken over a long interval of time. Bursty packet drops. • Router Response : Routers should ‘freely restrict’ the bandwidth of non TCP – Friendly flows. CS577 Spring 2005

  14. Identifying Unresponsive Flows • TCP Friendly test cannot be used at routers that are unable to determine packet sizes and RTTs. • If packet drop rates increase by x , the arrival rate should drop by √x . • When packet drop is constant, no flow will be identified as unresponsive. CS577 Spring 2005

  15. Identifying Unresponsive Flows • Limitations : Packet drop may be because of various reasons, hard for flows with variable demand. Flows might be tempted to start with a higher initial bandwidth demand. • Response : Actively regulate the bandwidth of unresponsive flows in times of congestion. CS577 Spring 2005

  16. Identifying flows using disproportionate flows • Flows that require larger bandwidth than other flows that reduce their demand. • These might be TCP friendly but still be ‘disproportionate’. Arrival rate <= log(3n) / n ; n = no of flows Arrival rate <= c / √p ; p = pkt drop rate c = some constant CS577 Spring 2005

  17. Comments and Conclusion • Alternate approaches - use schemes that are a mix of FCFS and per-flow based approach ( FCFS scheduling with differential dropping ). - pricing incentives. • granularity of flows - apply fairness tests to single/aggregate of flows. • min-max fairness measure - need to look at the entire path, all the congested links. CS577 Spring 2005

  18. Comments and Conclusion … continued • Breaking a TCP connection, increased local throughput but also increases global packet drop rate. CS577 Spring 2005

  19. Derivation of TCP Friendly Rate • Once congestionWindow >= W ; a packet is dropped and the congestion window is halved. • As long as congestionWindow < W ; window is increased by 1, per RTT W/2 + (W/2+1) + (W/2+2) + … W = 3/8*W2 => per packet drop ; max 3/8*W2 packets are sent => max packet drops <= 1/(3/8*W2) CS577 Spring 2005

  20. Derivation of TCP Friendly Rate … Continued • Max bytes transferred per cycle of steady state: Total packets sent * Avg. packet Size Avg Round Trip Time ( Total packets sent = 0.75*W ) = > (0.75 * W * B) / R = > CS577 Spring 2005

More Related