Differential Congestion Notification: Taming the Elephants

1. Differential Congestion Notification:Taming the Elephants Long Le, Jay Kikat, Kevin Jeffay, and Don Smith Department of Computer science University of North Carolina at Chapel Hill http://www.cs.unc.edu/Research/dirt Published on ICNP 2004 Presented by Feng Li (lif@cs.wpi.edu) CS577(Spring 2005)

2. Outline • Background: Router-based congestion control • Active Queue Management (AQM) • Explicit Congestion Notification (ECN) • Do AQM schemes works? • The case for differential congestion notification (DCN). • A DCN prototype and its empirical evaluation. CS577(Spring 2005)

3. Router-Based Congestion ControlThe Case against drop-tail queuing (FIFO) • Large (full) queues in routers are bad things. • End to end latency is dominated by the length of queues at switches in network. • Allowing Queues to overflow is a bad thing • Connections that transmit at high rates can starve connections that transmit at low rates. • Causes connections to synchronize their response to congestion and become unnecessarily busty. CS577(Spring 2005)

4. Router-Based Congestion ControlActive Queue Management (AQM) • Key concept: Drop packets before a queue overflows to signal incipient congestion to end-system. • Basic mechanism: When the queue length exceeds threshold, packets are probabilistically dropped • Random Early Detection (RED) AQM: • Always en-queue if queue length less than a low-water mark • Always drop if queue length is greater than a high-water mark • probabilistically drop/en-queue if queue length is in between these two marks. CS577(Spring 2005)

5. The Proportional Integral (PI)Controller • PI attempts to maintain an explicit target queue length. • PI Samples instantaneous queue length at fixed intervals and computes a mark/drop probability at Kth sample: • p(KT)=a x (q(kT) – qref ) – b x (q ((k-1) T) – q ref) + p ((k-1) T) • a, b, and T depends on link capacity, maximum RTT and the number of flows at a router. CS577(Spring 2005)

6. Explicit congestion Notification Overview • Set a bit in a packet’s header and forward towards the ultimate destination • A receiver recognizes the marked packet and sets a corresponding bit in the next outgoing ACK • When a sender receives an ACK with ECN it invokes a response similar to that for packet loss CS577(Spring 2005)

7. Put the piece together :AQM+ECN • If a RED Router detects congestion it will mark arriving packets. • The router will then forward marked packets from ECN-Capable senders. • … and drop marked packets from all other senders. CS577(Spring 2005)

8. Do AQM Schemes work? Evaluation of AFER, PI and REM • “The effects of Active Queue Management on Web Performance” [SIGCOMM 2003]. When user response times are important performance metrics: • Without ECN, PI results in a modest performance improvement over drop tail and other AQM schemes. • With ECN, both PI and REM provide significant performance improvement over drop-tail. CS577(Spring 2005)

9. Evaluation of AQM, PI and REMExperimental results – 98% Load. [From SIGCOMM 2003] CS577(Spring 2005)

10. Outline • Background: Router-based congestion control • Active Queue Management (AQM) • Explicit Congestion Notification (ECN) • Do AQM schemes works? • The case for differential congestion notification (DCN). • A DCN prototype and its empirical evaluation. CS577(Spring 2005)

11. Discussion of ECNDisadvantages • Claim • ECN deployment requires the participation of both router and end-systems. That raises cost and complexity • Firewalls and network address translators intentionally or unintentionally drop all ECN packets or clear ECN bits. Only 1.1% websites correctly deployed ECN in 2003. • Conclusion • AQM would be more appealing without ECN. CS577(Spring 2005)

12. The Structure of Web TrafficDistribution of Response sizes (figure 1) CS577(Spring 2005)

13. The Structure of Web TrafficPercent of Bytes transferred by response sizes (figure 2) CS577(Spring 2005)

14. DiscussionDo AQM designs inherently require ECN? • Claim: Differentiating between flows at the flow-level is important. • ECN is required for good AQM performance because it eliminates the need for short flows (a significant fraction of their) data • With ECN, short flows (mostly) no longer retransmit data • But their performance is still hurt by AQM • Why signal short flows at all? • They have no real transmission rate to adapt • Hence signaling these flows provides no benefit to the network and only hurts end-system performance CS577(Spring 2005)

15. Outline • Background: Router-based congestion control • Active Queue Management (AQM) • Explicit Congestion Notification (ECN) • Do AQM schemes works? • The case for differential congestion notification (DCN). • A DCN prototype and its empirical evaluation. CS577(Spring 2005)

16. Realizing Differential NotificationIssues and approach • How to identify packets belonging to long-lived, high bandwidth flows with minimal state? • Adopt the Estan & Varghese flow filtering scheme developed for traffic accounting [SIGCOMM 2002] • How to determine when to signal congestion (by Dropping packets) • Use a PI-Like scheme [INFOCOM 2001] • Differential treatment of Flows: an old idea. • FRED, CHOKe, AFD, RIO-PS • SRED, SFB, RED-PD… CS577(Spring 2005)

17. Classifying FlowsA score-boarding Approach • Use two hash tables (Hash keys are formed by IP addressing 4-tuple plus protocol number. • A “suspect” flow table HB (“High Band Width”) and • A per-flow packet count table SB (“score board”) • Arriving packets from flows in HB are subject to dropping • Arriving packets from other flows are inserted into SB and tested to determine if the flow should be considered high bandwidth. • Using a simple packet count threshold for this determination. CS577(Spring 2005)

18. Classifying FlowsA score-boarding approach(figure3) CS577(Spring 2005)

19. An Alternate ApproachAFD [Pan et al. 2003] “Approximate Fairness through Differential Dropping” • Sample 1 out of every s packets and store in a shadow buffer of size b • Estimate Flow’s rate as rest = R * (#matches/b) • Drop packet with probability p= 1- rfair/rrest CS577(Spring 2005)

20. Another Alternate ApproachRIO-PS[Guo and Matta 2001] • Edge Routers: maintain per-flow counters and classify flows into two classes: “short” or “long” • Core Routers: • Use different RED engines for short and long flows • Use different RED parameter settings to give preferential treatment to short flows CS577(Spring 2005)

21. Another Alternate ApproachRIO-PS [Guo and Matta 2001] • Edge Routers: maintain per-flow counters and classify flows into two classes: “short” or “long” • Core Routers: • Use different RED engines for short and long flows • Use different RED parameter settings to give preferential treatment to short flows CS577(Spring 2005)

22. Outline • Background: Router-based congestion control • Active Queue Management (AQM) • Explicit Congestion Notification (ECN) • Do AQM schemes works? • The case for differential congestion notification (DCN). • A DCN prototype and its empirical evaluation. CS577(Spring 2005)

23. Evaluation Methodology[SIGCOMM2003] • Evaluate AQM schemes through “live simulation” • Evaluate the browsing behavior of a large population users surfing the web in a laboratory test bed. • Construct a physical network emulating a congested peering link between two ISPs • Generate synthetic HTTP requests and responses but transmit over real TCP/IP stacks, network links, and switches • Also perform experiments with mix of TCP applications. CS577(Spring 2005)

24. Experimental MethodologyHTTP traffic generation • Synthetic web traffic generated using the UNC HTTP model [SIGMETRICS 2001, MASCOTS 2003] • Primary random variables: CS577(Spring 2005)

25. Experimental MethodologyTestbed emulating an ISP peering link • AQM schemes implemented in FreeBSD routers using ALTQ kernel extensions • End-systems either a traffic generation client or server • use dummynet to provide to provide per-flow propagation delays • Two-way traffic generated, equal load generated in each direction CS577(Spring 2005)

26. Experimental Methodology1 Gbps Network calibration experiments • Experiments run on a congested 100 Mbps link • Primary simulation parameter: Number of simulated browsing users browsing users • Run calibration experiments on an un-congested 1 Gbps link to relate simulated user populations to average link utilization • (And to ensure offered load is linear in the number of simulated users -- i.e., that end-systems are not a bottleneck) CS577(Spring 2005)

27. Experimental Methodology1 Gbps Network Calibration Experiments CS577(Spring 2005)

28. DCN EvaluationExperimental Plan • Run experiments with DCN, AFD, RIO-PS, and PI at different offered loads • PI always uses ECN, test AFD and RIO-PS with and without ECN • DCN always signals congestion via drops • Compare DCN results against… • The better of PI, AFD, and RIO-PS (the performance to beat) • The un-congested network (the performance to approximate) CS577(Spring 2005)

29. Experiment Results – 90% LoadDCN Performance (figure 5) CS577(Spring 2005)

30. Experimental Results – 98% LoadDCN Performance (figure 5) CS577(Spring 2005)

31. Experimental Result – 90% LoadDCN Performace (figure 9) CS577(Spring 2005)

32. Experiment Results – 98% LoadComparison of all schemes(figure-11) CS577(Spring 2005)

33. DCN EvaluationSummary • DCN uses a simple, tunable two-tired classification scheme with • Tunable storage overhead • O(1) Complexity with High Probability • DCN, without ECN, meets or exceeds the performance of the best performing AQM designs with ECN • The performance of 99+% flows is improved • More small and “medium” flows complete per unit time. • On heavily congested networks, DCN closely approximates the performance achieved on an un-congested network CS577(Spring 2005)

34. Summary and Conclusions • For offered loads of 90% or greater there is benefit to control theoretic AQM but only when used with ECN • bandwidth Heuristically signaling only long-lived, high-bandwidth flows improves the performance of most flows and eliminates the requirement for ECN • One can operate links carrying HTTP traffic at near saturation levels with performance approaching that achieved on an un-congested network • Identification of high-bandwidth flows can be performed with tunable overhead and effectively complexity CS577(Spring 2005)

35. Experimental Results – 90% LoadComparison of all schemes (CCDF) CS577(Spring 2005)

36. Experimental Results – 98% LoadComparison of all schemes (CCDF) CS577(Spring 2005)

37. Experimental Results – With General TCP TrafficComparison of all schemes (Figure 19) CS577(Spring 2005)

38. Experimental Results – With General TCP TrafficComparison of all schemes CCDF (Figure 20) CS577(Spring 2005)

39. Reference • Authors’ slides in ICNP 2004 • http://www.cs.unc.edu/~jeffay/talks/ICNP-04-slides.pdf • Authors’ slides for SIGCOMM2003 • http://www.cs.unc.edu/~jeffay/talks/Penn-DCN-ECN-Study-04.pdf • Research Group Websites • http://www.cs.unc.edu/Research/dirt CS577(Spring 2005)

40. Differential Congestion Notification:Taming the Elephants (IEEE ICNP 2004) Thank you CS577(Spring 2005)