© 2004 andreas haeberlen, rice university 1 the effects of active queue management on web...

32
© 2004 Andreas Haeberlen, Rice University 1 The Effects of Active Queue Management on Web Performance Long Le Jay Aikat Kevin Jeffay F. Donelson Smith Dept. of Computer Science University of North Carolina (Chapel Hill) Annual Conference of the Special Interest Group on Data Communication (SIGCOMM 2003) August 25-29, 2003 Karlsruhe, Germany Presentation: Andreas Haeberlen COMP629, February 26, 2004

Upload: shanon-haynes

Post on 02-Jan-2016

213 views

Category:

Documents


0 download

TRANSCRIPT

© 2004 Andreas Haeberlen, Rice University1

The Effects of Active Queue Management on Web Performance

Long LeJay Aikat

Kevin JeffayF. Donelson Smith

Dept. of Computer ScienceUniversity of North Carolina

(Chapel Hill)

Annual Conference of the Special Interest Group on Data Communication (SIGCOMM 2003)

August 25-29, 2003Karlsruhe, Germany

Presentation: Andreas HaeberlenCOMP629, February 26, 2004

2 © 2004 Andreas Haeberlen, Rice University

Who would you believe?

Larry L. Peterson (Princeton)Scout, TCP Vegas, x-Kernel...

David Clark (MIT)81-89: Internet Chief Protocol Architect

Bruce Davie (Cisco)MPLS

? Deborah Estrin (UCLA)Multicast routing, BGMP, ...

Craig Partridge (UCLA)RTP, Gigabit Networking

Scott Shenker (ICSI)CAN, RSVP, ALM, ...?

Sally Floyd (ICIR)Pushback, ECN, High-speed TCP, TFRC, ...

"Thou shalt use AQM" -- RFC2309

Kevin Jeffay (UNC)Real time (YARTOS), QoS, Multimedia

F. Donelson Smith (UNC)Andrew, SNA, FAPL

"AQM is useless without ECN" -- this paper

3 © 2004 Andreas Haeberlen, Rice University

Introduction Internet uses packet

switching Need queues to handle bursts

X

Host

Router

Queues are of finite length Drop packets when queue is full

Overload can lead to congestion collapse

Solution: Congestion control mechanism

AIMD extension for TCP

4 © 2004 Andreas Haeberlen, Rice University

Introduction: RED Problems with 'drop tail':

High packet loss Full queue latency Lockout

X

minmax

pdrop

Average queuelength

Idea: Drop some packets before queue is full to trigger AIMD mechanism

Short bursts should still be tolerated!

RED: Use average queue length (EWMA) to compute drop probability

5 © 2004 Andreas Haeberlen, Rice University

Introduction: ARED, PI, REM RED improvements:

Gentle mode Adaptive RED (ARED)

Average queuelength

pdrop

min max

1.0

0

thth

thPb

avgp

minmax

)min(max

RED:

))1(()))1((())(()( TkpqTkqbqkTqakTp refref

PI:

)))()))((()1(,0max()( ctxqtqtptp ref

REM:

Many other variants; >50 proposed in 1999!

Biggest problem: RED is either unstable or responds too slowly

Application of control theory: Proportional integrator (PI)

Random exponential marking (REM)

6 © 2004 Andreas Haeberlen, Rice University

Introduction: ECN Idea: Mark packets instead

of dropping them

CE: CongestionExperienced

ECE:Echo CE

CWR: CongestionWindow Reduced

4 IHL DSCP Length16-bit ID flags Fragm. offset

TTL Protocol ChecksumSource IP

Destination IP

Data

...

TCP WindowFlagsOffset

IPheader

...

TCPheader

Explicit congestion notification (ECN)

Special bits in IP and TCP headers

Effect: Send window is reduced

Sender Receiver

7 © 2004 Andreas Haeberlen, Rice University

Goal of this paper

Study the effects of active queue management on the response times experienced by web users

Compare ARED, PI, REM with/without ECN

8 © 2004 Andreas Haeberlen, Rice University

Methodology

Network models interconnection between two ISPs

FreeBSD machines(ARED, PI, REM)

Traffic generators emulate browsing users Offered load varied between 80%-105% of bottleneck

Trafficgenerator

Server

9 © 2004 Andreas Haeberlen, Rice University

Results: 80% load, no ECN

Offered load: 80% of bottleneck link (100Mbps)

Response time (ms)

Cum

ula

tive p

robabili

ty

Result 1: For offered loads up to 80%, AQM does not provide better response time than drop-tail FIFO

Result 2: ARED even decreases performance!

10 © 2004 Andreas Haeberlen, Rice University

Results: 90% load, no ECN

Offered load: 90% of bottleneck (98%, 105% similar)

Response time (ms)

Cum

ula

tive p

robabili

ty

Result 1: For 80% of the responses, PI, REM and drop-tail all provide reasonable performance

Result 2: In the remaining cases, PI is better

11 © 2004 Andreas Haeberlen, Rice University

Results: 98% load, with ECN

Offered load: 98% of bottleneck

Response time (ms)

Cum

ula

tive p

robabili

ty

Cum

ula

tive p

robabili

ty

Response time (ms)

Result 1: With ECN, both PI and REM significantly improve response time at offered loads >90%

Result 2: Response time with ARED is consistently poor

12 © 2004 Andreas Haeberlen, Rice University

Summary and Conclusions

Major results: Up to 80% load, drop-tail is as good as AQM Without ECN, PI is slightly better than ARED, REM With ECN, both PI and REM improve response

times significantly at 90% load and above ARED consistently performs poorly, even with ECN

Conclusions: AQM without ECN: Small improvement AQM with ECN: Significant improvement - good

enough to operate links at near saturation levels!

13 © 2004 Andreas Haeberlen, Rice University

Review

Sound: Realistic experiments, good results, well presented

Relevant: Shows a way for providers to get better link utilization (ECN-capable routers)

Interesting: Results for RED inconsistent with its high reputation in the community

14 © 2004 Andreas Haeberlen, Rice University

The End

Rebuttal

15 © 2004 Andreas Haeberlen, Rice University

80% Uncongested

Argument: Queue management in an uncongested network is not very interesting

Purpose is to show what the interesting case is

16 © 2004 Andreas Haeberlen, Rice University

ECN helps over 90%

Argument: PI paper already has that result

Paragraph of prose is not a proof Popular belief about ARED shows that

intuition is sometimes misleading What is new? - Experimental validation

17 © 2004 Andreas Haeberlen, Rice University

"Everybody loves RED"

May, M., Bolot, J., Diot, C., and Lyles, B., Reasons not to deploy RED, technical report, June 1999."The main results we found were, first, that RED with small buffers does not improve significantly the performance of the network... Second, parameter tuning in RED remains an inexact science, but has no big impact on end-to-end performance."

M. Christiansen, K. Jeffay, D. Ott, and F.D. Smith, Tuning RED for Web Traffic, ACM SIGCOMM, August 2000. "We conclude that for links carrying only web traffic, RED queue management appears to provide no clear advantage over tail-drop FIFO for end-user response times... There are some limitations of this study that should be considered... Congestion on both paths on a full-duplex link and over multiple router hops should also be considered."

18 © 2004 Andreas Haeberlen, Rice University

ARED is bad

Argument: Goal is link utilization, stabilize queue delay

Stable, but high queue delay is not desirable

Argument: Web traffic results were already published in SIGCOMM 2000

Best paper award for stale results?!? -> See conspiracy theory slide

19 © 2004 Andreas Haeberlen, Rice University

RED Deployment

Argument: Would Cisco deploy it without proof that it works?

If IETF can make an error, so can Cisco Huge companies have made huge

mistakes: Microsoft and the Internet IBM and microkernels

Proof by Credibility

20 © 2004 Andreas Haeberlen, Rice University

RED Parameter Setting

Argument: Need more research on parameter setting

Many papers have been written on RED - lack of research?

There are even summary papers on the family of RED techniques!

Even RED authors do not have good recommendations

21 © 2004 Andreas Haeberlen, Rice University

Evaluating RED

Argument: RED was designed for something else

Question: Which metrics matter? Delay for interactive applications

certainly matters!

22 © 2004 Andreas Haeberlen, Rice University

"Experiment is unrealistic"

Web traffic only Focus is response time; web surfing is

the dominant interactive application Network too small

Need controlled evironment Access to backbone routers?

Configuration error Careful calibration; built on previous

work Much better than in pro-RED papers

23 © 2004 Andreas Haeberlen, Rice University

PI is cool

Not the main point of the paper - really advocates use of ECN (if you read between the lines)

24 © 2004 Andreas Haeberlen, Rice University

"ECN is not yet deployed widely"

Not true - newer OSes do have support for it

Paper breaks the 'vicious circle of deployment' by providing a good case for ECN

25 © 2004 Andreas Haeberlen, Rice University

Conspiracy: Best paper award

Did SIGCOMM PC conspire against RED? Is that plausible, given the list of names

on the RED RFC? How is best paper decision made?

26 © 2004 Andreas Haeberlen, Rice University

The End

Backup

27 © 2004 Andreas Haeberlen, Rice University

"Experimental error"

"Usually, there were no noticeable differences between repetitions; where there were..." Unrealistic to assume that results from an

experiment of this size can be reproduced exactly

28 © 2004 Andreas Haeberlen, Rice University

"Experimental error" II

"We chose two target queue lengths..." - "a queue size ... that would represent a 'best practice' choice" They did try other parameters Many other authors complain that choosing

parameters for DT/RED is not an 'exact science'

29 © 2004 Andreas Haeberlen, Rice University

"Experimental error" III

"This is an artifact of our traffic generation model wherein browsers generate requests less frequently as response time increases" Is this really unrealistic? Applies only to 105% results; main points

can be demonstrated at 90%/98% "The exact reasons for the observed

differences remains the subject of continued study."

30 © 2004 Andreas Haeberlen, Rice University

"Experimental error" IV

"The exact reasons for the observed differences remains the subject of continued study."

31 © 2004 Andreas Haeberlen, Rice University

"AQM method X performs better"

AQM design space is large

32 © 2004 Andreas Haeberlen, Rice University

"What about other protocols?

TCP/IP is the dominant protocol in the internet today

ARED and the other AQM schemes were specifically designed for TCP/IP