Differential Congestion Notification: Taming the Elephants

Transcription

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 Published on ICNP 2004 Presented by Feng Li CS577(Spring 2005) 1

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) 2

3 Router-Based Congestion Control The 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) 3

4 Router-Based Congestion Control Active 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) 4

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 K th sample: p(kt)=a x (q(kt) q ref ) 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) 5

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) 6

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) 7

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) 8

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

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) 10

11 Discussion of ECN Disadvantages 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 Conclusion AQM would be more appealing without ECN CS577(Spring 2005) 11

12 The Structure of Web Traffic Distribution of Response sizes (figure 1) CS577(Spring 2005) 12

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

14 Discussion Do AQM designs inherently require ECN? Claim: Differentiating between flows at the flowlevel 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) 14

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) 15

16 Realizing Differential Notification Issues 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) 16

17 Classifying Flows A 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) 17

18 Classifying Flows A score-boarding approach(figure3) CS577(Spring 2005) 18

19 An Alternate Approach AFD [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 r est = R * (#matches/b) Drop packet with probability p= 1- rf air /r rest CS577(Spring 2005) 19

20 Another Alternate Approach RIO-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) 20

21 Another Alternate Approach RIO-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

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) 22

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) 23

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

25 Experimental Methodology Testbed 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) 25

26 Experimental Methodology 1 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) 26

27 Experimental Methodology 1 Gbps Network Calibration Experiments CS577(Spring 2005) 27

28 DCN Evaluation Experimental 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) 28

29 Experiment Results 90% Load DCN Performance (figure 5) CS577(Spring 2005) 29

30 Experimental Results 98% Load DCN Performance (figure 5) CS577(Spring 2005) 30

31 Experimental Result 90% Load DCN Performace (figure 9) CS577(Spring 2005) 31

32 Experiment Results 98% Load Comparison of all schemes(figure-11) CS577(Spring 2005) 32

33 DCN Evaluation Summary 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) 33

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, highbandwidth 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) 34

35 Experimental Results 90% Load Comparison of all schemes (CCDF) CS577(Spring 2005) 35

36 Experimental Results 98% Load Comparison of all schemes (CCDF) CS577(Spring 2005) 36

37 Experimental Results With General TCP Traffic Comparison of all schemes (Figure 19) CS577(Spring 2005) 37

38 Experimental Results With General TCP Traffic Comparison of all schemes CCDF (Figure 20) CS577(Spring 2005) 38

39 Reference Authors slides in ICNP Authors slides for SIGCOMM Study-04.pdf Research Group Websites CS577(Spring 2005) 39

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