Promoting the Use of End-to-End Congestion Control

1. Promoting the Use of End-to-End Congestion Control Tapan Karwa CS590F

2. What is Congestion Control • Its a control problem. • Its concerned with allocation of resources. • The problem – limited resources. • Will infinite BW, buffer space and super fast processors help? • CC is not a resource shortage problem. • Congestion will occur. It needs to be handled. Dynamically.

3. Classical Congestion Collapse • Congestion collapse occurs when the network is increasingly busy, but little useful work is getting done. • Problem : paths clogged with unnecessarily retransmitted packets. • Reasons : heterogeneity, dynamic network conditions, bad timers with Go-back-N retransmissions. • Fix : Modern TCP retransmit timer and congestion control algorithms. Based on the assumption that sources will cooperate.

4. Congestion Collapse from undelivered packets • Problem : Paths clogged with packets that are discarded before they reach the receiver. • Reasons : open-loop apps not performing end-to-end CC, best-effort apps increasing their sending rate on packet loss. • Unresponsive flows. No cooperation. Router mechanisms (scheduling mechanisms, ECN) don’t help either. • Fix : Either end-to-end CC, along with mechanisms to detect unresponsive flows, or virtual-circuit style of guarantee packet delivery.

5. Why do we need CC • So that the application can better achieve its goals of minimizing loss and delay, maximizing throughput. • Fairness. Especially with unresponsive flows around.

6. What is the fairness goal? • No connection /session/end-node should hog the network resources. • TCP is the dominant transport protocol in the Internet (90-95% of the bytes/packets). • Routers are likely to use FIFO scheduling. • New forms of traffic/new applications that compete with TCP as best-effort traffic in FIFO queues should not be significantly more (or less) aggressive than TCP.

7. Mechanisms within the network • Mechanisms within the network infrastructure to restrict unresponsiveness during times of congestion. • Max sending rate :

8. Identifying TCP-unfriendly flows • Given R and B, if the steady-state packet drop rate is ‘x’, then the arrival rate of the flow should be at most ‘y’. • R is set to twice the propagation delay of the attached link. • Limitations : • Difficult to determine B, R. • Applies only to non-bursty packet drop behavior. During severe congestion, multiple packet drops are very likely. • Measurements should be taken over large intervals in comparison to the RTT of the connection.

9. Identifying unresponsive flows • To test if a high BW connection is responsive, check if, when the steady-state drop rate increases by factor x, does the arrival rate decrease by a factor close to squareroot(x). • Can be applied to aggregated traffic too. • Limitations : • Requires estimates of a flows arrival rate and packet drop rate over long time intervals. • Flows could start with high initial BW and then reduce it. This means that just testing for unresponsiveness might not be enough.

10. Identifying flows with disproportionate BW • Applied when a flow is consuming a larger share than other flows who could use more BW. • Two components : • Check if flow is using more than its share. • Check if flow has a high arrival rate, relative to the level of congestion, as reflected by the drop rate. • Limitations : • Difficult to access how unsatisfied a flow is.

11. Other approaches and Conclusion • Instead of using the mechanisms proposed, we could use per-flow scheduling. • Limitations : difficult to implement, FCFS is more optimal. • End-to-end congestion control is required for reasonable usage of the Internet. • Mechanisms to punish non-responsive flows are also required to prevent pathological situations.