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

1. Promoting the Use of End-to-End Congestion Control in the Internet Sally Floyd and Kevin Fall Presented by Scott McLaren

2. Overview • Introduction • The problem of unresponsive flows • Identifying flows to regulate • Alternate approaches • Conclusions and future work

3. Introduction • End-to-end congestion control mechanisms of TCP are critical to the robustness of the Internet • We can no longer rely on all end-nodes to use congestion control for best-effort traffic • We also cannot rely on all developers to use congestion control • The network must participate in resource utilization (congestion control)

4. Approach 1 – Packet scheduling in routers to isolate flows • Per-flow scheduling to regulate bandwidth • Attempt max-min fairness

5. Approach 2 – Incentives for use of congestion control • Restrict bandwidth of best-effort flows using a large share of the bandwidth • Incentive for users, developers, and protocol designers • Restrict bandwidth of flows without congestion control

6. Approach 3 – financial incentives or pricing mechanisms • Can network providers deploy effective pricing structures fast enough to keep up with growth of best-effort traffic?

7. Definitions • Best-effort – UDP, etc. • Unresponsive flows – flows that do not use end-to-end congestion control and that do not reduce their load on the network when subjected to packet drops • TCP-friendly – a flow whose arrival rate does not exceed the arrival of a conformant TCP connection in the same circumstances • Goodput – the bandwidth delivered to the receiver, excluding duplicate packets • Congestion collapse – when an increase in the network load results in a decrease in the useful work done by the network

8. Unfairness • TCP flows competing with unresponsive UDP flows for scarce bandwidth • TCP flow reduces load, UDP uses the extra bandwidth • Due to TCP’s congestion control algorithms, throughput = 1/(roundtrip time) • With multiple congested gateways, throughput = 1/sqrt(# congested gateways)

9. Simulations 3 TCP flows,1 UDP flow, FCFS Scheduling 3 TCP flows,1 UDP flow, WRR Scheduling

10. Congestion Collapse • Classical – results from unnecessary retransmissions of packets • First reported in mid 1980s, due to retransmission of packets that were in transit or already received • Corrected by timer improvements and congestion control in modern TCP implementations • From undeliverable packets – bandwidth wasted by delivering packets that will eventually be dropped • Largest unresolved danger • Condition is not stable, it returns to normal once load is reduced • Not an issue in a circuit-switched network – a sender can only send when a path exists with the necessary bandwidth

11. Congestion Collapse Simulations(top line = Bold line: Aggregate Goodput)

12. Congestion Collapse Simulations

13. Other forms of congestion collapse • Fragmentation-based – network transmits fragments or cells that are discarded because they can’t be reassembled into a valid packet • ATM uses Early Packet Discard – when a cell is dropped, a complete frame is dropped • Variant is packets received by transport-level, then later discarded before used by user • Occurs when web users abort transfers due to delays, then re-request the same data • Increased control traffic – an increasing fraction of the bytes transmitted belong to control traffic, and a decreasing fraction of the bytes are data for applications • Control packets – packet headers for small data packets, routing updates, multicast join an prune messages, session messages, DNS messages, etc

14. Incentives to use Congestion Control • The current Internet “rewards” users that do not use congestion control, they might get a larger fraction of the bandwidth • Incentives cannot come from other users, they need to come from the network • Two ways to prevent congestion collapse from undeliverable packets • End-to-end congestion control, possibly by using incentives at routers • Use of virtual-circuits, where packets only enter the network if they can reach their final destination

15. Identifying flows to regulate • Designed to detect a small number of misbehaving flows • An incentive to limit the benefits of not using congestion control • Issues not addressed • encryption and fragmentation make it more difficult to classify packets into flows • IPsec could prevent routers from using source IP addresses and port numbers

16. Identifying flows that are not TCP-friendly • T = maximum sending rate (Bps) • B = size of packets (bytes) • R = roundtrip time (s) • No simple test for this • p = packet drop rate • Use this equation to calculate the maximum arrival rate from a conformant TCP connection in similar circumstances

17. Identifying unresponsive flows • TCP-friendly test is based on TCP, routers may want to consider other protocols • One approach is to verify that a high-bandwidth flow was responsive (its arrival rate drops when its packet drop rate increases) • If drop rate increases by x, and the load does not decrease by a factor close to √x or more, the flow is unresponsive • Requires estimates of a flow’s arrival rate and packet drop rate over several long time intervals • Arrival rate estimated from packet drops from active queue management • Drop rate estimate using aggregate drop rate of the queue • Only applied to high bandwidth flows • Incentive to start with an overly-high initial bandwidth, so it would get larger share of bandwidth even after it is reduced • Example test: if drop rate increases by a factor of four, but arrival rate has not decreased to below 90% of its previous value

18. Identifying unresponsive flows • Other tests • Flows with an increasing or constant average arrival rate, while the router drop rate is increasing • Flows whose average arrival rate tracks changes in the router drop rate • Flows whose average arrival rate changes independently of the router drop rate

19. Identifying flows using disproportionate bandwidth • Router might restrict bandwidth of flows even if they are using congestion control • If it is the only TCP • with sustained demand • using large windows • with significantly smaller roundtrip time • with larger packet sizes

20. Identifying flows using disproportionate bandwidth • A flow uses disproportionate share if • Arrival rate > log(3n)/n • log(3n)/n is close to one (0.9) for n=2 • Grows slowly as a multiple of 1/n • A flow has a high arrival rate relative to the level of congestion if • Arrival rate > c/√p Bps

21. Alternate Approaches • Deploy per-flow scheduling mechanisms such as RR or FQS at all congested routers • Problem with per-flow scheduling • Encourages flows to make sure their queue never get empty – so they lose their turn at scheduling • FCFS advantages • More efficient to implement – link speeds and active flows are increasing • Allows packets arriving in a small burst to be transmitted in a burst, in stead of spread out by the scheduler

22. Alternate Approaches • FCFS with per-flow scheduling • FCFS with differential dropping for flows using large fraction of bandwidth • Scheduling mechanisms such as Class-Based Queuing or Stochastic Fair Queuing that can operate on levels other that a single flow or all of the traffic • Min-max fairness restricts attention to each component • It would be better to consider the number of congested links on each flow’s path

23. Alternate Approaches • Pricing structures • State required for this would be complex

24. Conclusions and future work • Arguments for • The need for end-to-end congestion control • The need for mechanisms in the network to detect and restrict unresponsive or high-bandwidth best-effort flows • Future Work • A specific proposal for mechanisms to identify and control unresponsive flows • The specifics are not as important as deployment of a mechanism