1 Tuning RED for Web Traffic SIGCOMM 2000 Paper by M. Christiansen, K. Jeffray, D. Ott, F.D. Smith, UNC – Chapel Hill CS 590 F Fall 2000 Paper presentation by Vadim Gorbach

2 Overview What is RED and its goals Alternatives RED parameters Web Traffic: Optimizing RED Results of the experiments

3 What is RED? Random Early Detection (Drop, Discard) Proposed by Sally Floyd and Van Jacobson (IEEE Transactions on Networking, August 1993) Aimed to reduce negative effects of Tail-Drop (FIFO) Policy in routers Claim: Improves congestion avoidance, end- to-end delay by controlling the average queue size

4 Tail-Drop (FIFO) Queue Mgmt Discard a datagram that arrives, if the queue is filled If traffic is multiplexed (it commonly is), TD drops segments from many sources, causing Global Synchronization Effect (especially in 4.3 BSD TCP Tahoe) High average queue size, leading to higher average delay through the network Optimal queue size: 1-2 bandwidth-delay products

5 RED: Motivation Floyd and Jacobson: Gateway-centric view Need for high throughput and low queue occupancy (low end-to-end delay) Plaguing synchronization (synchronous slow start) effect Dynamic queue size management with preventive drops, allowances for bursty traffic Compatibility with installed client and server base

6 RED Parameters and Queue Management Policy Qlen, minth, maxth, wq, maxp Qavg – average queue length Qavg < minth, add the datagram Qavg > maxth, discard the datagram – forced drop minth < Qavg < maxth, random discard according to probability p – early drop test RED Modifications and Alternatives: BLUE, SRED, ARED, FRED, BRED, RED w/ ECN (see paper for references)

7 Optimizing RED Optimal minth, maxth, maxp minth: chosen large enough to ensure output link has high utilization maxth: If Qlen  maxth, close to tail-drop behavior; maxth > 2 x minth is recommended p: depends on current queue size, e.g. linearly with increase from minth to maxth; but traffic is bursty, that is why weighted queue size is used in practice; S.Floyd, V.Jacobson: weighted average queue size Early drop probability p = maxp x (avg – minth) / (maxth – minth), where avg depends on wq

8 Focus of the Paper Web traffic, which makes 70% of all TCP/IP traffic Worst case considered: Web traffic, based on HTTP 1.0, for highly- variable and bursty demands on the network dynamically changing number of TCP connections Main criterion is a user-visible measure: End-to-end response time

9 Experimental Network Browsers (clients): PCs with Web request generator software, 10 Mbps Servers: Web response generator software, 10 Mbps 2 router PCs: ALTQ software for FIFO, RED, CBQ and WFQ queue management 2 stacks of switches (Cisco Catalyst 5000) to concentrate Web request and Web response traffic Static routes to separate Requests and Responses into different Ethernet segments

10 Web-like Traffic Generation 230 hours of traces from UC-Berkeley campus, 1.6 million HTTP protocol packets HTTP model: HTTP request length in bytes HTTP reply length in bytes Number of embedded file references per page Time between retrieval of two successive pages (user “think” time) Number of consecutive pages requested from server HTTP version 1.0

11 Experiments Calibrations to make sure: CPUs and network interfaces are not resource constraints (Fig. 1) FreeBSD limitation of 64 sockets per process is not constraint Whether generated loads merge successfully (Fig. 2) Experimental Procedures: Offered loads: 50, 70, 80, 90, 98, 110% (120% exhausts sockets) 90 minutes, first 20 minutes ignored (Fig. 5)

12 FIFO vs RED FIFO: Fixed offered load, varying queue length (Fig.7) Utilization above 90% seriously impacts response time (Fig.8) RED: Fixing RED parameters per guidelines (Fig.9) Varying minth and maxth: guidelines fail to impress (Fig. 10) What about minth, wq and maxp for bursty traffic (Fig. 11, 12) Utilization and Response Time trade-off (Fig. 13) Pitfalls: Reasonable parameters but poor results (Fig.14)

13 Conclusions Comparing at different loads: Contrary to expectations, compared to TD(FIFO), RED has a minimal effect on HTTP response times for offered loads up to 90% of link capacity Response times at loads in this range are not substantially effected by RED parameters Between 90% and 100% load, RED can be carefully tuned to superior performance, however response times are quite sensitive Trade-off: in such heavily congested networks, RED parameters that provide the best link utilization produce poorer response times