“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 1/14/2019 CS577 Spring 2005

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 1/14/2019 CS577 Spring 2005

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 !! 1/14/2019 CS577 Spring 2005

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. 1/14/2019 CS577 Spring 2005

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. 1/14/2019 CS577 Spring 2005

Experimental Setup 1/14/2019 CS577 Spring 2005

Unfairness – 3 TCP, 1 UDP flow, FCFS 1/14/2019 CS577 Spring 2005

Fairness – 3 TCP, 1 UDP flow, WRR 1/14/2019 CS577 Spring 2005

Congestion Collapse – 3 TCP, 1 UDP flow, FCFS 1/14/2019 CS577 Spring 2005

Congestion Control – 3 TCP, 1 UDP flow, WRR 1/14/2019 CS577 Spring 2005

Congestion Control – 3 UDP, 1 TCP flow, WRR 1/14/2019 CS577 Spring 2005

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. 1/14/2019 CS577 Spring 2005

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. 1/14/2019 CS577 Spring 2005

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. 1/14/2019 CS577 Spring 2005

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. 1/14/2019 CS577 Spring 2005

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 1/14/2019 CS577 Spring 2005

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. 1/14/2019 CS577 Spring 2005

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

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) 1/14/2019 CS577 Spring 2005

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 = > 1/14/2019 CS577 Spring 2005