1 / 13

CS 590 F Fall 2000 Paper presentation by Vadim Gorbach

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. Overview. What is RED and its goals Alternatives RED parameters Web Traffic: Optimizing RED

raymond-stephens
Download Presentation

CS 590 F Fall 2000 Paper presentation by Vadim Gorbach

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Tuning RED for Web TrafficSIGCOMM 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 andQueue 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 probabilityp = 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

More Related