University of Southern California Dissertations and Theses

Applying aggregate-level traffic control algorithms to improve network robustness

(USC Thesis Other)

Applying aggregate-level traffic control algorithms to improve network robustness

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content APPLYING AGGREGATE-LEVEL TRAFFIC CONTROL ALGORITHMS TO IMPROVE NETWORK ROBUSTNESS by Xuan Chen A Dissertation Presented to the FACULTY OF THE GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (COMPUTER SCIENCE) August 2004 Copyright 2004 Xuan Chen Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. UMI Number: 3145171 INFORMATION TO USERS The quality of this reproduction is dependent upon the quality of the copy submitted. Broken or indistinct print, colored or poor quality illustrations and photographs, print bleed-through, substandard margins, and improper alignment can adversely affect reproduction. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if unauthorized copyright material had to be removed, a note will indicate the deletion. ® UMI UMI Microform 3145171 Copyright 2004 by ProQuest Information and Learning Company. All rights reserved. This microform edition is protected against unauthorized copying under Title 17, United States Code. ProQuest Information and Learning Company 300 North Zeeb Road P.O. Box 1346 Ann Arbor, Ml 48106-1346 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. D ed ication This dissertation is dedicated to my family, for their endless love and support. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A ck n ow led gem en ts I deeply appreciate my advisor Dr. John Heidemann for his consistent guidance and support throughout my PhD study. He has been giving me the greatest encouragement and patience, leading me gradually toward my goal at USC. I truly believe that the value of his advice is beyond this dissertation itself, and will last in my future career. I also would like to thank my committee members, Dr. John Heidemann, Dr. Ramesh Govin- dan, and Dr. Ahmed Helmy for their insightful comments on my research. I appreciate fruitful discussions with members in SAM AN, CONSER and COSSACK projects at ISI. I am also graceful to Professor Edmond A. Jonckheere for his suggestions on presenting NEWS control diagrams, Professor Christos Papadopoulos for his comments on related work and deployment of DEWP, and Professor Deborah Estrin, Dr. Ted Faber, and Dr. Sally Floyd for their feedback on early work of SFD and NEWS. I also would like to acknowledge the Advanced IP Networks group in Nortel Networks for their contribution of Diffserv model to ns, Professor Mark Crovella for pointing us to their trace (BU98), and Stephen Adler for providing server log for slash-dot effect. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C onten ts D edication ii A cknow ledgem ents iii List O f Tables vii List O f Figures viii A bstract xi 1 Introduction 1 1.1 Motivation ................................................................................................................................. 1 1.2 Thesis S ta te m e n t....................................................................................................................... 3 1.3 C o n trib u tio n s.............................................................................................................................. 4 1.3.1 Dilferentiating Short F lo w s ....................................................................................... 5 1.3.2 Mitigating Flash Crowd T ra ffic ................................................................................ 6 1.3.3 Containing Internet Worm P ro p a g a tio n ................................................................ 7 1.3.4 Guidelines to Design Traffic Control Algorithms ................................................ 9 1.4 O rg a n iz a tio n .............................................................................................................................. 9 2 R elated W ork 10 2.1 Prior Traffic Control A lg o rith m s.......................................................................................... 10 2.1.1 Congestion Control at Different L ev els................................................................... 10 2.1.2 Admission C o n tro l....................................................................................................... 11 2.1.3 Server Overloading C o n tro l....................................................................................... 12 2.1.4 Applying Control Theory to the Internet ............................................................. 13 2.2 Quality-of-Service Support in Networks ............................................................................. 13 2.2.1 Adaptive Queue Management A lg o rith m s............................................................. 14 2.2.2 Differentiated S erv ices................................................................................................. 15 2.2.3 Size-based Service D ifferentiation............................................................................ 15 2.3 Traffic Measurement and Network M onitoring................................................................... 17 2.4 Web Caching and Content Delivery N etw o rk s................................................................... 18 2.5 Intrusion Detection and Containment ................................................................................ 19 3 R educing W eb L atency by Preferential Treatm ent for Short Flow s 21 3.1 Short and Long Flows in Internet T raffic............................................................................. 21 3.2 Interaction between Short and Long F low s......................................................................... 23 3.2.1 Impact of Long Flows on the Performance of Short F lo w s .............................. 24 3.3 Differentiating Short and Long F low s................................................................................... 26 3.3.1 Designing Traffic Differentiation ............................................................................. 27 iv Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3.3.2 Concerns with Preferential Treatment for Short F lo w s ...................................... 28 3.4 Algorithm Evaluation ........................................................................................................... 30 3.4.1 M eth o d o lo g y ................................................................................................................. 30 3.4.2 Performance Improvement of Short F lo w s ............................................................ 33 3.4.3 Impact on Long F lo w s ................................................................................................ 34 3.4.4 Overall Effects on End-user Browsing ................................................................... 36 3.4.5 Performance under Different Network L o ad s......................................................... 40 3.4.6 Sensitivity to Simulation C onfigurations................................................................ 41 3.5 S u m m a ry ................................................................................................................................... 46 4 M itigating Flash Crowds via A daptive A dm ission Control based on A pplication- level O bservations 47 4.1 Aggregate-level Control between Requests and R e s p o n s e s .......................................... 48 4.1.1 C ontributions................................................................................................................. 49 4.1.2 NEWS Performance E valuation................................................................................ 50 4.2 Flash Crowds and Early W arn in g ........................................................................................ 52 4.2.1 Observations of Flash Crowd T ra ffic ...................................................................... 53 4.2.2 Reduced Web Performance during Flash C ro w d s ............................................... 54 4.2.3 Overall Design of Network Early Warning System ............................................ 55 4.3 Detecting Flash C ro w d s ........................................................................................................ 56 4.3.1 High-bandwidth C o n n ectio n s.................................................................................... 57 4.3.2 Change Detection A lg o rith m .................................................................................... 59 4.3.3 NEWS Flash Crowd Detection A lg o rith m ............................................................ 60 4.3.3.1 Simple Analysis of NEWS Detection In te rv a l.................................... 61 4.3.4 Discovering Target S e rv e r.......................................................................................... 62 4.4 Mitigating Flash C row ds........................................................................................................ 63 4.4.1 Regulating R e q u e s ts .................................................................................................... 63 4.4.2 Controlling the Adaptive Rate L im ite r................................................................... 64 4.5 Implementing N E W S ............................................................................................................... 65 4.5.1 Connection State K eep in g .......................................................................................... 66 4.5.2 Flash Crowd Detection and Control L o g ic ............................................................. 67 4.5.3 Adaptive Token Bucket F ilte r .................................................................................... 67 4.6 Algorithm Evaluation through Sim ulations........................................................................ 68 4.6.1 M eth o d o lo g y .................................................................................................................. 68 4.6.2 Protecting Networks from O verloading................................................................... 70 4.6.3 Maintaining High Response Rate for Admitted R equests................................... 72 4.6.4 Effect of Detection I n te r v a l....................................................................................... 74 4.6.5 Bystander Traffic Protection .................................................................................... 76 4.6.6 Result Sensitivity to Other Simulation P a ra m e te rs ............................................ 77 4.7 System Evaluation through Testbed E x p erim en ts.......................................................... 79 4.7.1 Experiment Setup ........................................................................................................ 80 4.7.2 Relieving Network C ongestion.................................................................................... 82 4.7.3 Protecting Server from Flash C row ds....................................................................... 84 4.7.4 Effect of Different Detection Intervals ................................................................... 85 4.7.5 NEWS Overhead on R o u te r s .................................................................................... 87 4.7.5.1 Algorithmic Performance of NEWS Flash Crowd Detection .... 87 4.7.5.2 NEWS CPU and Memory O v erh ead ..................................................... 88 4.7.6 Bystander Traffic Protection .................................................................................... 89 4.8 S u m m a ry ................................................................................................................................... 91 v Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5 D etectin g Early W orm P ropagation through Packet M atching 92 5.1 Designing Automatic Worm Detection and Containment System .............................. 92 5.1.1 C ontributions .................................................................................................... 94 5.2 Worm Detection and C o n ta in m e n t...................................................................................... 95 5.2.1 Detecting Worm Propagation with Destination Port Matching ...................... 96 5.2.2 Containing Worm P ro p a g a tio n ................................................................................ 97 5.3 DEW P System D e sig n ............................................................................................................. 99 5.3.1 Algorithm Implementation in Simulation ............................................................ 99 5.3.2 DEW P Algorithm Overhead ...................................................................................... 100 5.4 Modeling Worm P ro p a g a tio n ................................................................................................... 102 5.4.1 Formal Representation of the M o d e l......................................................................... 103 5.4.2 Modeling the Interaction between the Protected Network and the Rest In ternet 105 5.4.3 Validating the worm propagation M o d e l.................................................................. 106 5.4.4 Expected Time of Probing and In fectio n.................................................................. 107 5.5 System E v a lu a tio n ....................................................................................................................... 109 5.5.1 M eth o d o lo g y ................................................................................................................... 109 5.5.2 Effectiveness of Worm Detection and Q u a ra n tin e .................................................. I l l 5.5.3 Effect of Worm Scanning T echniques.........................................................................112 5.5.4 Effect of Detection I n te r v a l......................................................................................... 116 5.5.5 Effect of the Protected Network T o p o lo g y ............................................................... 116 5.5.6 Understanding False D etections...................................................................................118 5.6 S u m m a ry ........................................................................................................................................120 6 G uidelines to D esign Traffic C ontrol A lgorithm s 122 6.1 Designing Adaptive S y s te m .......................................................................................................122 6.1.1 Defining Key Metrics for Traffic O b s e rv a tio n .........................................................123 6.1.2 Developing Self-Learning Control Logic ...................................................................125 6.2 Choosing Proper Detection In te rv a ls ...................................................................................... 127 6.2.1 S u m m a ry .......................................................................................................................... 129 7 Future W ork and C onclusion 130 7.1 Thesis S u m m a ry ...........................................................................................................................130 7.2 Future Work ................................................................................................................................. 132 7.3 Conclusion .................................................................................................................................... 134 R eference List 134 .1 Simulation Results with Two-layer Flash-crowd Traffic M o d e l..........................................151 vi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List O f T ables 3.1 Param eters for the two virtual RED queues.................................................................................. 30 3.2 A ttributes of our web model and corresponding distributions................................................. 31 3.3 Different network loads......................................................................................................................... 32 3.4 SFD reduces response latency for short flows (compared to D T )........................................... 33 3.5 Five representative types of web pages (taken from [38]).......................................................... 38 3.6 Latency (seconds) to retrieve different web pages....................................................................... 38 3.7 Reduction in end-to-end web latency under different scenarios and scheduling policies. . . 45 4.1 Performance of NEWS and different static rate limiters in sim ulations............................... 73 4.2 CPU time consumed by NEWS with different detection intervals (observed in experiments). 88 4.3 End-to-end latency of bystander web traffic in different experimental scenarios............... 90 5.1 Param eters used in our worm propagation model......................................................................... 104 5.2 Param eters used to model Slammer worm.......................................................................................109 1 A ttributes of our web traffic model and corresponding distributions for background traffic. 151 2 Different Session-level attributes for Background and Flash crowd Traffic........................... 151 3 Comparison of NEWS with static rate limiters in sim ulations..................................................154 vii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. List O f F igures 1.1 D issertation road map: studying two-level of network robustness with three case studies. 2 1.2 A general diagram of traffic control algorithms proposed in this work....................................... 2 1.3 Traffic control algorithms proposed in three case studies................................................................ 4 1.4 “Network hole plugging” : burst short flows leave holes for long flows......................................... 5 1.5 Requests and Responses Overload Servers and Networks during Flash Crowds....................... 6 1.6 The fast spread of an Internet worm...................................................................................................... 8 3.1 “Network hole plugging” : burst short flows leave holes for long flows........................................ 22 3.2 Web request and response exchanges.................................................................................................... 24 3.3 response latency of short flows with different traffic m ix .................................................................. 25 3.4 Control diagram of SFD algorithm ........................................................................................................ 26 3.5 Two approaches to give different treatm ent to IN and OUT packets............................................. 28 3.6 Simple dumbbell topology in sim ulations.............................................................................................. 31 3.7 Response latency of short flows under different scenarios................................................................ 33 3.8 Response latency of flows with size up to 1M bytes under different scenarios (in log-log scale)................................................................................................................................................................. 34 3.9 Response latency with different algorithm configurations to reduce the penalty to long flows (in log-log scale)................................................................................................................................. 35 3.10 CDF: Improvement of web page retrieval tim e with S-SFD........................................................... 39 3.11 Mean response latency under different network loads (in log-log scale)..................................... 40 3.12 A Network with Two Tiers of Clients.................................................................................................... 42 viii Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3.13 Similar performance in a two-tiered topology as in a simple dumbbell topology.................... 42 3.14 SFD performance varies with different R TTs...................................................................................... 43 3.15 Mean end-to-end latency of short web flows under different scenarios........................................ 45 4.1 Comparison of T C P congestion control and NEW S......................................................................... 48 4.2 NEWS control diagram s............................................................................................................................. 49 4.3 Request and response transm ission latency, web connection life time, and request interval. 52 4.4 Server and network overloading during a flash crowd...................................................................... 54 4.5 The Architecture of NEWS .................................................................................................................. 55 4.6 CDF of Flows’ Response R ate in Flash Crowd and Background Traffic.................................... 57 4.7 Flow chart of flash crowd detector.......................................................................................................... 61 4.8 NEW S control logic: score-board based rate-lim it adjustm ent..................................................... 64 4.9 NEWS im plem entation............................................................................................................................. 66 4.10 The two-level dumbbell topology in sim ulations................................................................................ 68 4.11 Request rate to World C up’98 web site (used in sim ulations)....................................... 69 4.12 Request rate to the target web server (observed in sim ulations).................................. 71 4.13 NEWS m aintains high transm ission rate for HBFs during flash crowds (observed in sim ulations).......................................................................................................................................................... 72 4.14 Transmission rate of HBFs w ith NEWS and static rate limiters in sim ulations...................... 73 4.15 The performance of NEWS under different detection intervals (observed in simulations). . 75 4.16 NEWS bystander traffic protection (in sim ulations)......................................................................... 77 4.17 Network topology in testbed experim ent.............................................................................................. 80 4.18 Request rate to World C up’98 web site (used in experim ents)...................................................... 81 4.19 Server and end-user performance during flash crowds (observed in experim ents).................. 82 4.20 Request rate observed on NEWS router in experim ents................................................................. 83 4.21 Comparison of NEWS and static rate limiter in experim ents........................................................ 84 4.22 NEWS performance in a server-limited scenario in experim ents.................................. 85 ix Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.23 Different detection intervals affect NEWS performance (observed in experim ents)............. 86 5.1 D EW P architecture..................................................................................................................................... 95 5.2 Worm containm ent in ISP 1...................................................................................................................... 98 5.3 The worm propagation model......................................................................................................................102 5.4 Worm infections in both the protected network and the rest Internet........................................... 106 5.5 The the protected network topology of a 6-nary tree.......................................................................... 110 5.6 Detect and quarantine random-scanning worm with different layers of deploym ent..................I l l 5.7 DEW P performance with detection interval as 1 second....................................................................113 5.8 Detect and quarantine local-scanning worm w ith different layers of deploym ent....................... 114 5.9 Detection interval affects DEW P perform ance.......................................................................................115 5.10 Median Number of infected hosts under different detection intervals.............................................115 5.11 Detection interval affects D EW P perform ance...................................................................................... 116 5.12 Randomly generated topology for the protected network...................................................................117 1 The two-level dumbbell topology in sim ulations....................................................................................152 2 Changes in adm itted request rate w ith NEWS (observed in sim ulations).................................... 152 3 Increased Offered Request R ate due to Retransmission (observed in sim ulations).................... 153 4 NEWS M aintains High Aggregated R ate for HBFs during Flash Crowds (observed in sim ulations)........................................................................................................................................................153 5 Aggregated rate of HBFs with static rate limiter and NEWS (observed in sim ulations). . 153 6 The aggregated rate of HBFs with NEWS and static rate limiters in sim ulations.................... 154 x Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A b stract In this dissertation, we show that we can improve network robustness by carefully designing and applying aggregate-level traffic control algorithms. We conduct our study in three different scenarios: severe network congestion, persistent overloading during flash crowds, and Internet worm attacks. In each scenario, we investigate Internet robustness from two aspects: end-user perceived performance and infrastructure stability. We present one traffic control algorithm for each case study, namely, short flow differentiating (SFD) algorithm, network early warning system (NEWS), and detector for early worm propagation (DEW P). Each algorithm illustrates particular aspects of network robustness and algorithm design considerations. We first propose SFD to protect short flows from packet loss and queuing delay during con gestion. We show that SFD reduces web latency for short flows, and improves end-user perceived web performance in general. We also evaluate the cost of SFD algorithm, penalty to long flows, and show that it is well bounded. In order to protect the target server and networks from persistent overloading during flash crowds, we design an adaptive admission control scheme, NEWS, to regulate excessive requests. NEWS applies an aggregate-level control over requests and responses. It detects overloading by monitoring performance degradation in web responses, and mitigates flash crowds by discarding excessive requests. W e ev alu ate N E W S perform ance th ro u g h b o th sim ulations an d te stb e d exper iments, showing it effectively protects server and networks from overloading and maintains high performance for adm itted end-users in both network- and server-limited scenarios. NEWS is also capable to protect bystander traffic from flash crowds. xi Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Finally, we present DEWP, an autom atic system to quickly detect and effectively quarantine worm propagation. DEWP captures worm traffic from special patterns: same destination ports between incoming and outgoing connections and large number of distinct destination addresses in outgoing connections. We evaluate DEW P performance through simulations and show that DEW P is able to rapidly detect worm probing traffic. W ith automatic worm traffic pattern discovery, DEW P effectively protects vulnerable hosts from infection by packet filtering. We further investigate several im portant aspects affecting DEW P performance such as worm scanning techniques, DEW P deployment coverage and different detection intervals. We also present our study on DEW P false detections. Based on our experience in these three case studies, we suggest two guidelines for algorithm design, namely, designing adaptive system and choosing proper detection interval. We describe our suggestions to systematically identify key observation metrics and develop self-tuning control logic. We further present the guideline to select proper detection interval for our control algorithms. We hope the insight provided in this work contribute to better understanding of traffic control algorithms to improve network robustness. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 1 In trod u ction 1.1 M otivation W ith its dramatic growth, the Internet has become an im portant part in our daily life and society. Individuals use network-based services (for example, web and email) to retrieve and exchange information. Companies like Amazon and Yahoo conduct their business online. Even government provides public services via the Internet. All these require robust network services resilient to severe network congestion, traffic anomaly and malicious attacks. However, today’s Internet is not as robust as expected. For example, end-users may experience long waiting times when retrieving web pages. This delay increases with network load. Even worse, when many users simultaneously access one particular web site (that is, flash crowds [58]), most of them receive extremely poor performance. Flash crowds further persistently overload both the target web server and network links [69], threatening the stability of Internet infrastructure. The Internet is also vulnerable to malicious attacks such as Internet worms [73, 98, 114]. In th is research, we stu d y netw ork ro b u stn ess from tw o levels. At a high level (level I), we examine end-user perceived performance (for example, web latency, web response rate, and traffic throughput) under circumstances such as severe congestion and persistent overloading during flash crowds. We also investigate the impact of flash crowds and worm attacks on the stability of 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. traffic regulation traffic filtering DEWP rate lim iting NEWS traffic differentiation SFD 1 e n d -u se r infrastructure netw ork perform ance stability robustness F igure 1.1: Dissertation road map: studying two-level of network robustness with three case studies. Aggregate Identification Control logic Traffic Regulation Figure 1.2: A general diagram of traffic control algorithms proposed in this work. Internet infrastructure (level II), examining server load, network packet loss rate, and infection of vulnerable hosts. A stable Internet infrastructure is fundamental to provide high performance for end-users. We show the road map of this dissertation in Figure 1.1. We choose three scenarios reflecting two levels of network robustness: from severe congestion (level I) to persistent overloading (level I an d II) till w orm intrusions (level II). A ccordingly, we reg u late In te rn e t traffic aggregate w ith increasingly stricter control techniques. As we will show in following chapters, traditional flow-level control schemes such as TCP and RED by themselves are not sufficient in the above scenarios. For example, persistent congestion 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. during flash crowds is caused by aggregates of well-behaved TCP flows. Worms attacks can also use TCP connections. In this dissertation, we propose to apply original traffic control algorithms at aggregate level. As shown in Figure 1.2, these algorithms have three main components: aggregate identification, regulation and control logic. We describe the detailed design of each module in our carefully selected case studies. In this dissertation, we do not attem pt to develop a mathematical model for general traffic control algorithms. Instead, we systematically study real algorithms through three case studies. While model is often more general than case studies and provides formal reasoning, it usually relies on assumptions of underlying traffic dynamics or network protocols. Therefore, a theoretical model has difficulty to be directly applied to a complicated large-scale system like the Internet. On the other hand, a carefully designed algorithm for specific scenarios is still able to achieve good performance. We further generalize design considerations based on our experience in these three case stud ies. We present two guidelines for building these algorithms to improve the robustness of future Internet. More specifically, we investigate two im portant aspects to design adaptive traffic control algorithm: defining key observation metrics and developing self-learning control logic. We also describe our suggestions on choosing proper detection intervals for these algorithms. 1.2 T h esis S tatem en t The hypothesis of this dissertation is that by carefully designing and applying aggregate-level traffic control algorithms, we can improve network robustness under conditions such as severe network congestion, persistent overloading, and worm attacks. We focus on understanding design considerations of traffic control algorithms we proposed, namely, short flow differentiating (SFD) algorithm, network early warning system (NEWS), and detector for early worm propagation (DEWP). Although we can not claim that these examples ;i Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Traffic Flow Classification Packet marking Flow Differentiating (a) SFD Traffic Flash-crowd Detection Alarm signal Rate limiting (b) NEWS Traffic W orm-probing Detection Worm signature Packet filtering (c) D EW P F igure 1.3: Traffic control algorithms proposed in three case studies. are representative, we believe that particular case studies do illustrate im portant aspects to design general mechanisms. Together with other research efforts, we hope to build up the framework for designing future traffic control algorithms to improve network robustness. 1.3 C on trib u tion s The major contributions of this dissertation are that we systematically study the design of traffic control algorithms which improve network robustness under severe congestion, persistent overload ing, and worm attacks. We choose three case studies with increasingly severity to the Internet. Correspondingly, we shift our focus from end-user perceived performance to Internet infrastructure stability. As shown in Figure 1.3, we propose one algorithm in each scenario under the general structure of adaptive control algorithms [92], We brief review prior work applying similar framework in n ext ch ap ter. O nr algorithm in each scenario d ep icts specific techniques in designing m odules of aggregate identification, regulation and control logic. These algorithms can be applied stand-alone. We first briefly review them below. In following chapters, we present their design considerations and performance evaluations in details. 4 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 0.8 c o Long flows c o N 0.6 3 C Zi 0.4 0.2 Short flows 10 20 30 40 50 60 70 80 90 100 Simulation time (seconds) F igure 1.4: “Network hole plugging” : burst short flows leave holes for long flows. As a secondary contribution, we generalize design principles for algorithms in our case studies. We hope the insight provided by this work helpful to improve network robustness with better control on Internet traffic. We summarize these design guidelines in Section 1.3.4. 1.3.1 Differentiating Short Flows We first test our hypothesis by examining a network loaded by web traffic, where most flows are short {mice) but most bytes belong to long flows (elephants) [28, 34, 51, 97]. Short flows suffer substantial queuing delay and packet loss due to bulk traffic in long flows [7, 28, 51]. So, end-users may have to wait for long time even for small web pages. As we will shown in Section 3.4.5, this waiting time increases as network load becomes heavier. Further, from end-users’ perspective, they tend to tolerate long delay when downloading large files, but easily upset with slow web surfing. Inspired by the idea of “network hole plugging” (depicted in Figure 1.4) that was first suggested by Jo h n D oyle a t Cal Tech— sh o rt flows should be able to quickly slip th ro u g h th e netw ork, while long flows should “fill in the gaps” in short, bursty traffic, we propose to differentiate short and long flows, and give short flows preferential treatm ent [28]. That is, routers protect short flows by dropping more packets in long flows upon congestion. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. requests target server rP < !n n n < !P < ! ------------------ responses^ networks t 1 packets dropped Figure 1.5: Requests and Responses Overload Servers and Networks during Flash Crowds. Simulation results show that SFD algorithm reduces the response latency for short flows by about 30% when network load in medium (defined in Section 3.4.1). Since most web flows are short, end-users perceive smaller waiting time for 99% web pages. We further show that under severe network congestion, short flows are transferred 10 tim e’s faster with SFD than with droptail or RED. As a cost for this performance improvement, SFD penalizes long flows. We evaluate this penalty and propose schemes to alleviate it. We further investigate the interaction of SFD with server-side scheduling algorithms. 1.3.2 M itigating Flash Crowd Traffic Flash crowds happen when too many end-users simultaneously send requests to one web site because of a common new interest. In minutes or even seconds the event, the volume of requests toward the target web server increases dramatically to tens or hundreds times more than normal. As shown in Figure 1.5, these requests overload the target server. The target server may reject some requests, and process those accepted ones slowly due to either resource limits at the server (CPU or disk), or congestion on the response’s network path (often in the first few links where the traffic concentration is the largest). As a result, most users receive unacceptably poor performance. In addition, flash crowds may unintentionally deny services for other end-users who either share common links with flash crowd traffic or retrieve unrelated information from the target server. We propose the network early warning system (NEWS) [26, 27] to protect the target server and networks from persistent overloading and maintain high performance for end-users. NEWS imposes aggregate-level control between requests and responses. It detects flash crowds from 6 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. performance degradation in responses and mitigates flash crowds by adm itting incoming requests adaptively. NEWS admits incoming requests based on measured performance of responses. This approach is different from previous ones that are based on explicit service requirement or measurement on requests. We propose a novel flash-crowd detection technique by monitoring changes in the aggregated performance of high-bandwidth responses because of their sensitivity to overloading conditions. We first evaluate the performance of NEWS algorithm through simulations. We find that NEWS detects flash crowds within 20 seconds. By discarding 32% incoming requests, NEWS protects the target server and networks from overloading: reducing response packet drop rate from 25% to 2%. For adm itted requests, NEWS increases their aggregated response rate by two times. This performance is similar to the best static rate limiter deployed in the same scenario. We also investigate the impact of detection intervals on NEWS performance, showing it affects both detection delay and false alarm rate. We further implement NEWS on a Linux-based router and evaluate its performance in testbed experiments with HTTP server log recorded during a flash crowd. In addition to validating our previous simulation results in network-limited scenario quantitatively, we further consider server memory-limited scenario, confirming th at NEWS is effective in both cases. We also examine the run-time cost of NEWS traffic monitoring in practice, and find that it consumes little CPU time and relatively small memory. Finally, we extend core NEWS algorithms to include a simple hot-spot identification function to protect bystander traffic from flash crowds efficiently. 1.3.3 Containing Internet Worm Propagation The most severe threat we study in this work is the Internet worm intrusion. Outbreaks of Code-Red [2, 72], Code-Red II [91], Nimda [68], Slammer [71], and SoBig [22] worms have all led to considerable large cost to our society [73, 114], Worms propagate rapidly to compromise 7 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 800 700 o o 7S 600 w V t o 500 S 400 o a > c 300 0 1 200 E Z 100 0 200 400 600 800 1000 time (second) Figure 1.6: The fast spread of an Internet worm. vulnerable hosts [101]. The Slammer worm infected a total of about 75,000 hosts in 15 minutes. The latest MyDoom worm compromised around 20,000 hosts in total within 2 hours after it was first detected. As shown in Figure 1.6, we simulate a fast-spread worm with scanning rate of 4000 per second (details about this simulation methodology are in Section 5.5.1). It infects about 70,000 hosts in just 1000 seconds. Based on our experience in developing aggregate-level traffic control algorithms, we design a router-based worm detection and containment system, DEWP, to automatically detect and quar antine Internet worm propagation. DEW P detects worm probing traffic by matching destination port numbers between incoming and outgoing connections. This approach does not require knowl edge of worm packet data contents or profiles of normal traffic conditions; it can automatically detect and suppress worms due to their unusual traffic patterns. Through simulations, we study the speed of detection and the effectiveness of vulnerable host protection relative to factors including worm scanning techniques, DEW P deployment coverage and detection intervals. We also investigate false detections with network trace playback. We show th a t D E W P d etec ts w orm p ro p ag atio n w ith in a b o u t 4 seconds. B y blocking w orm probing traffic automatically, DEW P can protect more than 99% hosts from random-scanning worms. Similar to our work on NEWS, we are interested in the effect of different detection intervals on DEW P performance. We find that an automatic worm detection system must monitor and 8 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. react to traffic changes within very small intervals in order to effectively protect vulnerable hosts from infection. On the other hand, we also observe false detections when DEW P uses very small detection intervals. We propose to reduce false alarms by separating detection interval and measurement window size, and choosing a relative large window for traffic measurement. 1.3.4 Guidelines to D esign Traffic Control Algorithm s Given the complexity of today’s Internet, there are many im portant issues that we should consider when designing traffic control algorithms to improve network robustness. We explore some of them through our case studies. Together with other research efforts, we hope to better understand design considerations for future traffic control algorithms. We present two guidelines for algorithm design, namely designing adaptive system and choos ing proper detection interval. Based on our experience in case studies, we show how to define key observation metrics and develop adaptive reaction scheme. We also present our suggestions on choosing appropriate detection intervals. We illustrate each guideline with examples in this research. In summary, we systematically study design considerations of network traffic control algorithms through three carefully chosen case studies. We hope to contribute to better understanding the design of such algorithms to improve network robustness. 1.4 O rganization After a brief review of related work in Chapter 2, we present our three case studies, SFD (Chap ter 3), NEW S(Chapter 4), and DEW P (Chapter 5). We describe detailed design and performance evaluation for each case study. Then, we generalize design principles for traffic control algorithms in Chapter 6. We discuss some future research directions and conclude this dissertation in Chap ter 7. 9 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 2 R ela ted W ork In this section, we first present previous approaches to control Internet traffic. Examples include congestion control, admission control, and server overloading control. Then, we briefly describe prior research effort to improve network robustness in the three scenarios we study. More specifi cally, we discuss differentiated services, with a focus on size-based service differentiation. We also review prior work on web caching and intrusion detection. 2.1 P rior Traffic C ontrol A lgorith m s Various protocols and algorithms have been proposed and applied to control Internet traffic to avoid congestion and achieve high end-user performance. We briefly review these approaches below. 2.1.1 Congestion Control at Different Levels TCP and its variations apply end-to-end congestion control, which is fundamental to the stability of today’s Internet. However, since it operates at flow-level, TCP is not sufficient, to regulate aggregate behavior. On the other hand, we propose to apply aggregate-level traffic control in this work. As we will show in our case studies, this high-level control is im portant to improve network robustness. 10 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Congestion manager (CM) [8] is a per-host based control algorithm, multiplexing concurrent flows among different applications of one end-host to ensure that they react to congestion coop eratively. Different from CM, our algorithms do not regulate the behavior of individual hosts. As we will shown in following chapters, per-host based information does not help to solve the problems we study in this work. Researchers have also proposed to control Internet traffic at aggregate level. For example, the aggregate-based congestion control (ACC) [69] regulates the rate of aggregates consuming most of network bandwidth and promotes fair bandwidth allocation among different flows traversing the same link. In terms of the scenarios we study in this dissertation, we can apply ACC to regulate re sponse traffic in flash crowds, which is likely to consume high bandwidth and cause large packet drops. However, ACC is not sufficient to mitigate flash crowds fundamentally because it does not have the complete control loop between requests and responses that NEWS applies. As we will show in Section 4.2, the aggregate-level control that NEWS imposes is im portant for flash crowd mitigation. 2.1.2 Adm ission Control Admission control is another example of traffic control algorithms in the Internet. It plays an im portant role to support applications with service requirement such as real-time constraint (for example, delay and jitter). Looking at public telephone networks [49] and integrated service networks [32], a call (or a new connection) explicitly describes its service requirement such as two channels for telephone conversation or 1Mbps bandwidth for Video-on-Demand service [74]. Based on this service profile an d current, available resources (circuits or netw ork b an d w id th ), adm ission control makes decision on whether it should accept the incoming request or not. Although appropriate for telephone and integrated service networks, it may be difficult for most Internet applications (for example, Web and FTP) to accurately estimate and describe 11 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. their service requirements. So, we believe that we need to determine application requirements dynamically through measurement. NEWS is such an example. To avoid under-utilization by estimating resource consumption with statistical model, measurement- based admission control (MBAC) [21, 23, 55] determines the current available resource through traffic measurement. However, MBAC still needs service profile of incoming requests. Further, MBAC aggregates the performance of all existing flows to evaluate current resource consumption; while NEWS only measures the aggregate rate of high-bandwidth responses. Also, MBAC is more conservative and only accepts the incoming requests upon sufficient resource; while NEWS sends all requests through unless a flash crowd is detected. In order to protect networks and servers from overloading, we could also apply a static rate limiter to regulate the incoming request rate below a certain threshold. It rejects excessive re quests to ensure that networks and servers always work under capacity. Despite its simplicity, a static rate limiter lacks adaptivity to different environments. In order to work properly, net work operators need to choose the rate limit carefully based on current configurations and their experience [12]. Usually, this choice is specific to a certain server or network link, and needs manual adjustment when the server’s capacity or the link’s bandwidth changes. On the con trary, we propose self-tuning traffic control algorithms, NEWS, which adapt to both network- and server-limited scenarios. 2.1.3 Server Overloading Control Recent studies [23, 25, 67, 108] proposed to apply overloading control and service differentiation on web servers to improve web performance under heavy loading and flash crowds. These schemes are com plim entary to ro u ter-b ased alg o rith m s proposed in th is d issertatio n . F u rth e r, we believe that one of our algorithms, NEWS, is also applicable to web servers. On the other hand, NEWS is more flexible than server-based overloading control, effectively protecting bystander traffic from flash crowds (Section 4.6.5). 12 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.1.4 Applying Control Theory to the Internet Researchers have also proposed to apply control theory in evaluating and designing network protocols [57, 59, 66, 81]. Control theory promotes our understanding on network stability and fair resource allocations with formal reasonings. However, they usually rely on assumptions of underline linear systems, which is not suitable to model a large-scale system like the Internet especially under unsteady conditions such as flash crowds and worm attacks. Therefore, there are challenges to apply proposed algorithms to real networks. In this dissertation, we take a different approach than developing algorithms based on theory. That is, we study the design of traffic control algorithms via case studies. We believe that a carefully designed and tuned algorithm could also be robust to control the underlying complexity of the Internet. 2.2 Q u ality-of-Service Support in N etw orks Integrated services (intserv) are proposed to provide strict QoS support for end-users in the Internet. It needs to keep per-flow state on routers and apply sophisticated admission control and resource reservation protocols. Dynamics packet state (DPS) technique [103] is proposed to provide guaranteed service without per-flow state keeping at core routers. Instead, it uses packet headers to carry flow states and needs router support to encode and decode state information. It also requires sophisticated scheduling and signaling to provide guaranteed QoS. D ifferent from th ese proposals to provide stric t QoS, th e goal of our control algorithm s is to improve network robustness. More specifically, we focus on both end-user perceived performance and infrastructure stability. Also, our control algorithms do not need per-flow state keeping at core routers or end-to-end resource reservation. They do not modify packet headers either. 13 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Our algorithms are more similar to adaptive queue management algorithms and differenti ated services. We review research effort in both areas below, and present the difference of our algorithms. 2.2.1 A daptive Queue M anagem ent Algorithm s Routers apply different queuing algorithms to support QoS for end-users and achieve fair band width allocation for different flows. These algorithms differ in flow states they keep. On one end, RED [44] do not keep per-flow states. On the other end, Fair Queuing [36] maintains states for each flow, and achieves fair bandwidth allocation for individual flows. CSFQ [102] improves fair queuing by eliminating per-flow states from core routers. Instead, it keeps flow rate in packet headers. There are some proposals between these two extremes, which keep partial flow states [65, 70, 82]. For example, FRED [65] keeps states for flows th at currently have packets in buffer. FRED determines dropping probability for one flow according to the number of its packets being queued. RED with preferential dropping (RED-PD) [70] only keeps states for high-bandwidth flows, and drops their packets preferentially. The schemes we proposed in this work have different goals than adaptive queuing algorithms. For example, SFD focuses on improving web latency by protecting short flows from packet drops and large queuing delay. Further, NEWS and DEW P target at special scenarios of flash crowds and worm attacks. Persistent dropping (PD) [56] is proposed as an augment to adaptive queuing algorithms to m itig ate flash crow d traffic. It applies a fine-grain connection-level control to p ersisten tly discard retransm itted packets. PD can also be integrated into our NEWS framework as an alternative reaction scheme. On the other hand, it does not address im portant issues such as flash crowd detection and bystander traffic protection as NEWS does. 14 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.2.2 Differentiated Services We prototype our algorithms under the framework of diffserv. In diffserv model, given a profile th at end-users agree on, routers on the edge of networks (edge routers) keep states for traffic flows; and mark packets from flows obeying the profile as IN (in profile), otherwise as OUT (out of profile). Routers inside the network (core routers) give packets different dropping preference according to their marks: OUT packets are more likely to be dropped than IN packets during network congestion. By designing one of our algorithms, SFD, under the framework of diffserv, we eliminate the overhead for flow state keeping on core routers. For example, SFD is easier to be deployed than packet scheduling mechanisms (fair queuing [36], for example), which can also be used to protect delay sensitive traffic such as telnet and short web flows. On the other hand, our algorithms do not need end-user to provide service specification (for example, with a token-bucket description). Besides diffserv, the Alternative Best-Effort Service (ABE) [53] is proposed to accommodate different requirement of delay-sensitive (green) and throughput-sensitive (blue) applications. ABE requires applications to mark their packets as either green or blue and guarantees low latency for green packets as at the risk of possibly higher drop rate. On the other hand, SFD takes a different approach: routers classify traffic and protect short flows from packet loss by giving them preferential treatment. 2.2.3 Size-based Service Differentiation R esearchers have ad v o cated th e idea of favoring sh o rt weh connections to reduce1 web laten cy [7, 9, 34, 51, 105] . Implementations vary from modified TCP protocol [7, 105, 110] to web server scheduling policy [9, 34] and router queuing disciplines [51]. We design SFD algorithm as a diffserv policy. Beyond the basic algorithms, we further investigate the effect of flow differentiation under 15 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. different network loads, and evaluate the over-all page retrieval performance with SFD and its interaction with server scheduling policies. The interaction between HTTP and TCP has also been studied [7, 78, 80]. Balakrish- nan et. al. investigated the TCP behavior of a very busy web server (the web server for 1996 Atlantic Olympics) from its trace file [7]. They explored TCP throughput and loss recovery of both single and parallel connection(s). They found that web traffic consists of many short TCP connections from a single host that show poor loss recovery performance. For improvement, they enhanced T C P ’s loss recovery mechanism. We have similar observations in our work on SFD and consider it as the main reason for slow web transactions: large latency even for a small page. As opposite to modifying TCP implementation, we propose to reduce the response latency of short flows through traffic differentiation. The idea of SFD algorithm is similar to the Shortest Remaining Processing Time (SRPT) scheduling policy which minimizes the mean response time. Recent study [9] further shows that the “unfairness” of SRPT could be extremely small, especially when the processing time has a heavy-tailed distribution. Knowing the size of documents hosted, a web server can easily determine the processing time of a web request and apply SRPT scheduling policy to reduce server response time. The shortest-connection-first scheduling policy (described below) is such an example. However, it is difficult to directly apply SRPT to networks because routers do not know the size of web object until the end of transmission. Our SFD algorithm solves this problem with a heuristic flow identification scheme as described in Section 3.3. The end-user perceived web latency is determined by many factors, such as web server load, netw ork condition, an d web page rendering tim e on brow sers [11, 37]. W e m ainly focus on the network-limited scenarios [37]. In the mean while, we are also aware of complementary work on web servers such as the shortest-connection-first scheduling policy [34]. Both work show smaller response time for short web connections, and further examine the cost of favoring short 16 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. connections: unfairness or penalty suffered by long flows. We further investigate the interaction of both schemes in our study. RIO with Preferential treatm ent to Short flows (RIO-PS [51]) is very similar to our SFD [28] in terms of the basic idea of favoring short flows. Both algorithms were proposed simultaneously but independently. Different from RIO-PS th at augments RED-IO [31] to protect short flows, we implement SFD as a diffserv policy. In terms of algorithm performance, their algorithm shows less performance improvement for short flows than SFD. On the other hand, they did not observe penalty to long flows, which we believe is possible under certain traffic pattern and network configurations. 2.3 Traffic M easu rem en t and N etw ork M on itorin g Researchers also proposed to measure Internet traffic dynamics and monitor overloading and malicious attacks [7, 12, 13, 30, 109]. We briefly review these prior studies below. Internet traffic com position: The NeTraMet web session performance project at Caida [47] examined the composition of web traffic from network traces and found that about 75% of the web traffic flows carry about or less than IK bytes. They also show that the majority web traffic flows are only consist of a few TCP packets. This observation motivates our proposal to improve user perceived web performance by favoring short flows. Crovella et. al. investigated self-similarity in web traffic [35] and discovered the size of web flows has a heavy-tailed distribution. This property is reproduced in a web workload generator SURGE [13], which is used to validate the web traffic model in our simulations [42]. O verloading and intrusion m onitoring: To determine the current network condition and help to provide acceptable network performance, the network weather service (NWS) [109] mon itors and forecasts system performance such as link and server load. The forecast information 17 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. can be used to direct incoming requests so th at they can avoid congested links or heavily-loaded servers. NWS is a centralized system. Differently, we aim at designing distributed control mech anisms which determine control action based on local observations. For problems to the Internet globally such as worm attacks, some researchers call for a nation wide Internet worm control authority to coordinate worm detection and immunization efforts [101]. There are also proposals suggesting to deploy sensors around the Internet, collect traffic statistics, and send them to a data processing center [15]. We agree th at global coordination is necessary to protect the Internet from worm intrusions. However, there are some difficulties for these proposals to realize in near future, such as resource constraint and administrative issues. Unlike these centralized schemes, we take another approach of designing a distributed system that detects worm probing traffic through local traffic observations. NetBait [30] is a distributed system that provides detailed information about network in trusions. It collects data from geographically located machines, which use traditional intrusion detection systems (such as Snort [90]) to capture worm attacks. The goal of NetBait is to provide accurate information to identify infected hosts and expedite the process of worm containment and cleanup. It is complementary to DEW P which aims at fast detection of worm propagation. 2.4 W eb C aching and C onten t D elivery N etw orks Infrastructure vendors such as Akamai deploy web caches and content delivery networks (CDN) to protect servers from overloading during flash crowds. These services need infrastructure support, a n d are usually expensive. F u rth e r, recent studies [6, 58] show th a t cu rren t web caching schem e is not efficient because dynamic contents such as pages for breaking news are not cached before flash crowds. Jung et. al. proposed a new scheme—the adaptive web caching [58] for improvement. On the other hand, we propose a low-cost alternative by regulating incoming traffic adaptively. 18 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Ideally, we should provide enough resources to prevent networks and servers from overloading. But, in reality, there are circumstances that it is either difficult or impossible to estimate and provide “enough” resources required. So, we propose NEWS to regulate excessive requests based on current available resources. 2.5 In trusion D etectio n and C ontainm ent Intrusion detection systems (IDS) are deployed to discover DDoS attacks and worm intrusions. There are two different kinds of IDS, namely signature- and anomaly-based. Signature-based IDS [85, 90] capture worm attacks based on pre-compiled signatures stored in database. Although they identify threats accurately, signature-based IDS have little effect on unknown worms. On the other hand, anomaly-based IDS [50] detect new threats by observing unusual traffic changes, th at is, the difference between current traffic measurement and its normal condition (usually in a profile). Since it is difficult to create a “proper” profile to cover all representative aspects under normal traffic condition, anomaly-based IDS have high false alarm rate. DEW P does not rely on content-based signature to detect worm attacks. Instead, it focuses on capturing special patterns in worm traffic, and is more accurate than anomaly-based IDS potentially. Early Bird System (EBS) [96] is proposed to automatically detect worm propagation. Similar to DEWP, EBS also discovers worm by observing common special patterns in network traffic. Unlike the simple port-matching in DEWP, EBS needs per-packet data content analysis and complicated hashing function to identify suspicious worm traffic aggregates. Therefore, its appli cability to real networks is questionable. Honeypot [1, 99] and its variations (through aggregation and virtulization) monitor un-used address space (that is, dark space) and capture traffic interaction with dark space as worm in trusions. Honeypot is a flexible technique to detect unknown threats, and is complementary to 19 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. router-based scheme like DEWP. However, it only detects worm propagation when being directly probed (leading to false negatives). Also, honey-pots themselves could be compromised by worms. Current schemes to contain worm propagation is by packet filtering or address blocking [73, 114]. Researchers at Silicon Defense propose to partition enterprise network into small cells, and quarantine worm propagation coordinately [100]. In this work, DEW P applies packet filtering to suppress the spread of worms. “Virus throttle” [104] is a scheme to slow down worm propagation by limiting the number of different outgoing connections that one host can initiate simultaneously. To be effective, we need to modify current network implementation on most end-hosts. Virus throttle is also complementary to DEWP. Further, DEW P applies the similar idea as “Virus throttle” , capturing large increase in the number of destinations of outgoing connections. 20 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 3 R ed u cin g W eb L aten cy by P referen tial T reatm ent for Short Flow s In our first case study, we investigate the interaction of short and log flows. We are especially interested in the scenario when the network is severely congested. We propose to improve the performance of short flows by preferentially dropping long flow packets during congestion. This idea is motivated by the observation th at most network traffic flows are short, but most network load is carried by long flows. We describe this phenomenon with details below. 3.1 Short and Long F low s in In tern et Traffic The Internet has a mix of traffic of all types including interactive traffic due to telnet and most web traffic; bulk, non-interactive traffic such as e-mail, some web traffic, and most file sharing traffic (FTP, Napster, etc.). The different needs of these traffic classes have long been recognized (for example with IP type-of-service bits [87, 88]), but recent approaches to traffic classification such as differentiated services (diffserv) focus p rim arily on price- ra th e r th a n ap p lication-based levels of service [77, 18, 31]. A second observation about Internet traffic is that most flows are short, but most bytes are in long flows. Looking at web traffic, for example, recent measurements [97] show that 85% of all 21 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 0.8 C o 3 0 .6 Long flows 3 0.4 0.2 Short flows 10 20 30 40 50 60 70 80 90 100 Simulation time (seconds) Figure 3.1: “Network hole plugging”: burst short flows leave holes for long flows. response flows sent from servers are less than 10K bytes, but they only account for about 20% of all bytes transferred; the other 80% bytes are contributed by the longest 15% flows. Finally, a common web design practice is to keep commonly viewed pages short to improve page view latencies for interactive browsing. This approach is widely discussed in web design books and has been shown to be consistent with heavy-tailed web file sizes [113]. For web traffic sent over the H TTP/1.0 protocol [16] where a new TCP connection is opened for every web object, this design approach suggests a strong correlation between short flows and interactive traffic (we discuss H TTP/1.1 [48] in Section 3.3 and 3.4.4.). These three observations imply that most interactive web traffic is in short flows and should be transferred faster. Further, we should also consider the expectations of end-users [17]. For example, end-users are likely to tolerate long delay while downloading movies, but easily feel upset if waiting too long to see Yahoo’s web page. However, short flows suffer substantial queuing delay and packet loss due to bulk traffic: in long flows. On the other hand, these observations also suggest that interactive web performance could be im proved by giving p referential tre a tm e n t to sh o rt flows. T h e idea of “netw ork hole plugging” (depicted in Figure 3.1) was first suggested by John Doyle of Cal Tech—short flows should be able to quickly slip through the network, while long flows should “fill in the gaps” in short, bursty traffic. 22 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. We propose a traffic control algorithm to realize this goal and evaluate its effectiveness through simulations. We use diffserv to prioritize traffic, giving preference to short, presumably interactive flows. We implement the basic Short Flow Differentiating (SFD) algorithm and its two variants, namely probabilistic and selective SFD algorithms, as diffserv policies. Through simulations, we find that SFD reduces the mean response latency of short flows by about 32%. This benefit increases as the network load becomes heavier. By estimating page retrieval time based on two HTTP logs, we further find that more than 90% web pages are transferred at least 30% faster with SFD. We also study the sensitivity of our simulation results, investigating the effect of network topology, flow RTTs, existence of other traffic, and server scheduling policy on SFD performance. There are two risks to this proposal. First, these improvements come at some penalty to long flows. We examine the affected flow size and assess this cost. As presented in Section 3.4.3, SFD will increase the response latency for long flows by at most 2 times. Second, the developing understanding of Internet stability is based on the importance of end- to-end congestion control [45]. This argument is based on the observation that the majority of Internet traffic is in congestion-controlled long TCP flows. Non-congestion controlled traffic and short TCP flows ( “mice”) are suspects because they are not TCP friendly and, in the aggregate, may threaten Internet stability. Although SFD favors short flows, its policies are selected so as not to destroy the benefits of end-to-end congestion control. We discuss these trade-offs in Section 3.3.2. 3.2 In teraction b etw een Short and Long Flow s In th is section, we investigate th e effect of long flows on short, flows’ perform ance. T h e classification of short and long flows is based on flow size which is defined as the amount of data carried by a flow (1000 bytes, for example); short flows are those with flow size less than a certain threshold th and long flows otherwise. In this study, we choose the threshold as 15 Kbytes. 23 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C lie n t Server response request packet 1 response transmission latency packet n Time Figure 3.2: Web request and response exchanges. We use response transmission latency (or response latency, for short) to quantify the perfor mance of web traffic flows. As shown in Figure 3.2, response latency measures the time interval from a server sending out the first packet of a response till the corresponding client receiving the last packet of that response. 3.2.1 Impact of Long Flows on the Perform ance o f Short Flows To understand the interaction between short and long flows, we describe three simulation scenarios below (the detailed simulation methodology is presented in Section 3.4.1). In these simulations, we configure routers with droptail queues, which discard incoming packets indistinguishably when the buffer is full. We show the mean response latency of short flows with different sizes in Figure 3.3. We consider three scenarios as described below. • Flows with different sizes (denoted as D T): This is the baseline scenario where short flows compete with long ones. • No long flow s (denoted as N L): W e s u b tra c t long' flows from web traffic. T h e effect of long flows is completely eliminated: the traffic load is reduced as well as the number of flows. We find that the response latency of short flows is reduced by more than 50%. This is the ideal performance of short flows if long flows posed no competition. 24 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. V) T3 C o o 0 m > * o DT c 0.6 o 'w .22 E 0 4 c L2S ( 0 I — c 0.2 < o 0 2 NL 14 6 8 10 12 2 4 Flow Size (KBytes) Figure 3.3: response latency of short flows with different traffic mix • Chopping long flow into multiple short ones (L2S): We keep the traffic load (the total amount of bytes transfered) unchanged, but intend to send them with short flows. T hat is, an original long flow is chopped into several short ones (15K bytes or less). The simulation result shows th at the response latency of short flows is about 30-50% smaller compared to the original DT case. Therefore, short flows still have better performance than a mix of short and long flows even under the same network load. These observations imply th at the competition with long flows for network resources (such as buffer space) slows down short flows. We present two reasons below: • Packet dropping during TCP slow-start: Most routers with droptail queues discard packets indistinguishably under congestion. Because of the poor loss recovery performance during TCP slow-start [7], even a few packet drops can slow down short flows greatly. Studies of TCP [7, 51] also show similar observations. Further more, the retransmission of these dro p p ed packets also consum e netw ork resources such as b an d w id th an d buffer space. • Queuing delay: Although routers can provide adequate buffer space to avoid packet drop ping, short flows still suffer from large queuing delay because they may be blocked by long 25 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Flow Classification Packet marking Traffic Flow Differentiating Figure 3.4: Control diagram of SFD algorithm. flows which send tens of packets within one congestion window. Our simulations with infi nite buffer space show that the response latency of short flows may increase especially when a very large web object (larger than 1M bytes, for example) is transferred. Because of these two reasons, a dominant percentage of web transactions are slowed down. As a result, end users may experience a long waiting time even when fetching a simple web page with short text on it. The above analysis leads to a natural question: can we protect short flows from packet dropping and queuing delay to reduce their response latency? We present such an algorithm below. 3.3 D ifferen tiatin g Short and Long Flow s We propose a simple algorithm to differentiate short and long flows, namely the short flow dif ferentiating (SFD) algorithm. As shown in Figure 3.4, the SFD algorithm has three components: flow classification, packet marking and differentiating. We implement SFD as policies for diffserv model. Edge routers identify short and long flows, a n d th e n m ark packets in sh o rt flows as IN an d long flows as O U T . C ore ro u ters give higher priority to IN packets so that they are protected against packet dropping and large queuing delay. Unlike the simple definitions previously described in Section 3.2, it is not straightforward for edge routers to determine flow size without information from web servers. Given the limited 26 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. information carried by each packet, we propose a heuristic flow identification and packet marking scheme. Edge routers examine every packet header and record the amount of bytes having been sent by each flow as a state f. bytessent. They identify one flow as short and mark its packets as IN until its /. bytessent exceeds the flow identification threshold th. In diffserv model, only edge routers need to keep flow states; but edge routers do not need to keep these states forever. They time-out one flow state after a short period 8 during which no traffic for th at flow is observed. Not only does this technique reduce router state, but it also allows routers to treat long flows that are only interm ittently active as separate short flows. For example, H T T P /1.1 traffic multiplexes multiple interactive transactions over a single TCP connection. W ith this timeout, portions of a long H TTP/1.1 flow separated by end-user think periods [97] would be treated as separate interactive short flows. In our work, we set 8 to 1 second corresponding to the user thinking time. 3.3.1 D esigning Traffic Differentiation SFD applies RED [44] to handle IN and OUT packets (similar to RED-IO [31]). RED reduces the queue length via early dropping. W hen the average queue length exceeds a minimum threshold (m in Jh ), incoming packets are dropped with a probability roughly proportional to that connec tion’s share of bandwidth through the router. This probability is bounded by a maximum value (max-p) until the average queue length becomes greater than a maximum threshold (max-th) when all incoming packets are dropped. The different treatm ent to IN and OUT packets can be realized by either preferentially drop ping OUT packets or by a packet scheduling scheme with higher priority to IN packets. We compare the architecture of both approaches in Figure 3.5. We choose the first approach in SFD. Similar to RED-IO [31], SFD uses two virtual RED queues [69] for IN and OUT packets. They have different RED parameters, and preserve packet order by actually putting incoming packets into one single FIFO buffer. Each virtual queue handles corresponding packets individually based 27 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. inJ v q IN l O U T V Q -O U T j H FIFO queue 5 4 3 2 O utgoing packets 5 43 2 1 Identifier (a ) V ir tu a l R E D q u eu es w ith p referen tia l d ro p p in g P Q -IN Incoming packets - 5 43 2 1 O U l Identifier 5 2 1 4 3 Outgoing packets 43 5 2 1 Priority Scheduler P O -O U T (b ) P h y sic a l R E D q u eu es w ith p r io rity sch ed u lin g F ig u re 3.5: Two approaches to give different treatm ent to IN and OUT packets. on its queue length and RED parameters. W ith stricter parameters, OUT packets are dropped preferentially when congestion happens. We also consider another option of using two separate RED queues with a priority packet scheduler. This approach imposes strict priority to IN and OUT packets and can not preserve packet order, which may cause starvation to long flows when applications intentionally transm it data via short flows. 3.3.2 Concerns w ith Preferential Treatm ent for Short Flows A major concern of SFD is that it does not destroy the benefit of end-to-end congestion control [45]. There are two risks here: first, it could so heavily favor short flows that long flows are starved; and second, even if long flows are not starved, the benefits of SFD could be so great that applications could intentionally chose to use multiple short flows instead of a single long flow. To alleviate the first risk, we design two revised versions of SFD algorithm to avoid over penalizing long flows. The basic idea is to promote a fraction of packets in long flows to IN status. These algorithms are: 28 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. • Probabilistic SFD algorithm (denoted as P-SFD): Edge routers promote OUT packets with a probability j b yteS ent1 where th is the flow identification threshold. This promotion prob ability decreases as more packets being sent. • Selective SFD algorithm (denoted as S-SFD): Edge routers selectively promote a fraction of OUT packets, for example one of every K OUT packets. This modification has a tunable parameter K and requires edge routers to maintain a counter for each long flow. Although both modifications “put” some OUT packets into IN virtual queue, the packet order is still preserved as we have discussed in Section 3.3.1, which can’t be guaranteed by strict packet scheduling scheme. SFD further avoids starvation of long flows through its choice of virtual RED queues. Although OUT packets suffer stricter RED parameters than IN packets (short-flow packets or promoted long-flow packets in P-SFD or S-SFD), all packets are placed in a single physical FIFO buffer. Thus, once an OUT packet is accepted it will be sent. It is true that since short flows are given priority they will grow faster than they would in an undifferentiated network. However, the Internet community has previously granted some benefits to short flows, for example, by increasing the initial window size [4]. We suggest that SFD’s policy of favoring the first th bytes of each flow is only a somewhat greater step toward favoring interactive traffic. It is also possible that SFD might cause application writers to structure content or applications to send data in small pieces. Content is already often structured in small pieces to reduce download tim e, th u s som e control over traffic is alread y o u tsid e th e realm of protocol design. F ortunately, although some applications (for example, games) use custom protocols to get minimum latency, most major applications thus far are well behaved to make equitable (non-greedy) use of network resources. SFD should not change this trend. 29 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. V irtual R E D Q ueues m ax_th min_th m ax-p w_q IN 30 10 0.02 0.02 OUT 24 8 0.10 0.02 Table 3.1: Parameters for the two virtual RED queues. 3.4 A lgorith m E valuation We implement SFD algorithm in as a diffserv policy in ns [106] and evaluate its performance through simulations. In Table 3.1, we show different RED parameters for two virtual queues. We choose this configuration under the guidance of a recent study [29]. We choose 15K bytes as the flow identification threshold in our simulations (th = 15K bytes), which has been verified as a reasonable choice from simulations (described in Section 3.4.3). W ith this threshold, 90% flows in our simulation are short. But, they only contribute about 25% of network load; most of network load are from long flows1. We also observe similar statistic in two real networks traces: UCB96 collected by Univ. of California, Berkeley in 1996 from the UC Berkeley dial-in IP modem bank [61] and BU98 collected by Boston University in 1998 from a non-caching HTTP proxy server [10]. Both traces recorded the size of web objects requested. 3.4.1 M ethodology Figure 3.6 shows the simulated network topology. 5 client hosts (C1-C5) and 5 web servers (SI - S5) are connected to router R0 and R1 by 10 Mbps links with 10ms propagation delay. Router R0 and R1 are connected by a bottleneck link with 3Mbps bandwidth and 20ms propagation delay. Routers R0 and R1 identify short and long flows. We relax this topology in Section 3.4.6. This topology can be viewed as a simplified version of the interconnection between two ISPs corresponding to RO an d R1, w here one provides user access (RO) an d th e o th e r provides WWW services (RI). W ith this specific topology, requests (from clients to servers) and responses (from 'T h is o b se rv a tio n is c o n s iste n t w ith th e h ea v y -ta ile d d is tr ib u tio n o f w eb o b je c t size. G iv en th e sa m e th resh o ld , th e traffic flow s g e n era ted b y a w eb traffic m o d el w ith lo g -n o rm a l d istr ib u te d o b je c t size is c o n s ist o f 99% sh o rt flow s. 30 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. flow identification C2 KjfMb 3Mb IQMfr C3 RO 10ms 20ms 10ms C4 F igure 3.6: Simple dumbbell topology in simulations. W eb M odel P robabilistic E lem ents E lem ent A ttrib utes D istributions Param eters Web Session Number of Web Sessions Time Interval between Sessions (seconds) Number of Web Pages per Session Constant Exponential Exponential value: 1250 mean: 15 mean: 100 Web Page Time Interval between Pages (seconds) Number of Web Objects per Page Exponential Exponential mean: 10 mean: 3 Web Object Time Interval between Web Objects (seconds) Object Size (KBytes) Exponential Pareto II mean: 0.01 mean: 12, shape: 1.2 T able 3.2: A ttributes of our web model and corresponding distributions. servers to clients) are separated in two directions. Requests (usually contain one small packet, 48 bytes in our simulations) are transm itted under very light traffic load and will not increase the overall web latency. In the web traffic model in ns [42], clients initiate a series of web sessions, each retrieving some web pages from random ly chosen servers. A web page is consist of several w eb objects, w hich should be modeled by a heavy-tailed distribution [35] to produce the self-similarity in web traffic. As summarized in Table 3.2, we model these attributes with different probabilistic distributions according to a recent study on web traffic measurement [97]. 31 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. N etw ork Loads Session N um ber Inter-session T im e (seconds) Link U tilization Loss R ate light 1000 25 30% 0.1% m edium 1250 15 40% 1% heavy 1400 9 70% 10% Table 3.3: Different network loads. The network load in our simulations can be adjusted by varying the number of web sessions and the mean inter-arrival time between sessions. We study three network load conditions: light load, medium load and heavy load. We show the corresponding load parameters (that is, the number of web sessions and the mean inter-arrival time between sessions), utilization and packet loss rate on the bottleneck link in Table 3.3. Unless otherwise specified, our simulations are under medium network load. We deploy SFD to RO and R1 and compare the simulation results (denoted as SFD) with the DT scenario described in Section 3.2. Since SFD uses virtual RED queues, we also evaluate the effect of applying RED through simulations (denoted as RED). More specifically, we deploy RED queues to RO and R1 and configure them with parameters for OUT packets to limit the number of packets in buffer. We expect smaller response latency for short flows because the queuing delay is reduced. Also, packets from short flows are unlikely to be dropped due to their relatively small bandwidth consumption. We run simulations for 12000 seconds and record data after a warming up period of 2000 seconds to avoid transient effects. We measure response latency (mean and standard deviation) for flows with different sizes. There are only a few very long flows. To increase the accuracy of our sta tistic s (by considering m ore sam ples), we group long flows to g eth er, requiring one group to have at least 200 samples. Then, we compute the mean response latency for each group. When presenting our simulation results, we do not show the confidence interval with data in graphs because it is only 1-2% compared to the mean value (with 95% confidence level). 32 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2.5 ( / ) RED DT SFD H 14 10 12 2 4 6 8 1.2 1 RED 0.8 DT 0.6 SFD 0.4 0.2 0 12 14 6 8 10 2 4 Flow Size (KBytes) Flow Size (KBytes) (a) M ea n r esp o n se la te n c y (b ) S ta n d a r d d e v ia tio n o f resp o n se la te n c y F igure 3.7: Response latency of short flows under different scenarios. R eduction in response latency Topologies m ax min mean Simple 42% 27% 32% 2-tier 26% 20% 23% T able 3.4: SFD reduces response latency for short flows (compared to DT). 3.4.2 Perform ance Improvement o f Short Flows Figure 3.7(a) and 3.7(b) show the mean and standard deviation of response latency for short flows under different scenarios (DT, RED, and SFD). It is clear that SFD gives much better performance. In Table 3.4, we present this improvement as reduction in response latency for short flows (topology: simple). We observe that SFD reduces 32% of the mean response latency for short flows in average. SFD also shows much smaller variation in response latency; the standard deviation is only half of that in DT case, which indicates that the transmission of short flows are more predictable with SFD. Given the large percentage of short flows in web traffic, more than 90% web flows have better performance. 33 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DT — RED S F D < 10 0.1 100 1000 10 1 c / ) T J c O O g C W B > . r o o s l o w ■ 2 c CD O ■Ow 5 w 2 c “ 3 c C O DT — RED — SFD 10 1 0.1 1000 1 10 100 Flow Size (KBytes) (a) Mean response latency Flow Size (KBytes) (b) Standard deviation of response latency F igure 3.8: Response latency of flows with size up to 1M bytes under different scenarios (in log-log scale). Recalling our analysis in Section 3.2, it is interesting to note th at the response latency with SFD is similar to th at of L2S case. Given the lower bound of response latency we could expect (as shown in NL case), SFD reduces short-flow response latency by about 60% of the ideal case. On the other hand, RED does not show better results than droptail queue. Similar result has also been observed in an experimental study [29], which shows th at RED does not outperform droptail queues for Web traffic under most traffic loads. 3.4.3 Impact on Long Flows SFD reduces the response latency of short flows at the cost of penalizing long flows. We quantify this penalty and the affected flow size in this section. We show that the penalty of long flows is bounded by the design of SFD. W ith the two virtual RED queues and corresponding RED param eters (Table 3.1), long flows are given the buffer space for about 15 packets which corresponds to a b o u t 30% of th e bo ttlen eck link capacity. T herefore, we can estim a te th a t th e response latency for long flows will not increase by more than 2 times. In Figure 3.8, we show that the mean and standard deviation of response latency for flows witli size up to 1M bytes. Figure 3.8(a) depicts that SFD also reduces the response latency of some 34 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DT — SFD -■ P-SFD S-SFD - 10 1 0.1 100 1000 10 1 DT — - th=15KB — th=25KB ... th=35KB » m T J C o o < u m >. o c 0 ) ( 0 _ 1 c o in in | 0.1 100 1000 10 Flow Size (KBytes) Flow Size (KBytes) (a ) P -S F D a n d S -S F D a lg o r ith m s (b ) S -S F D a lg o rith m w ith d ifferen t id e n tific a tio n th re sh o ld s Figure 3.9: Response latency with different algorithm configurations to reduce the penalty to long flows (in log-log scale). long flows (up to about 40K bytes). This result is not unexpected because the first 15K bytes are always marked as IN (as described in Section 3.3) and protected by SFD upon congestion. Since the first a few packets in long flows are also fragile due to TCP slow-start, SFD also protects long flows. This protection is especially im portant for those long flows with size up to about 30K bytes because at least 50% of their packets are within the range of protection. However, we do observe that very long flows suffer from SFD. As shown in Figure 3.8, these long flows show increased mean and standard deviation in response latency as our expense to favor short flows. For example, SFD increases response latency for 1Mbyte flows by about 20%. It implies that the original algorithm is likely to over-penalize these very long flows. We design the P-SFD and S-SFD algorithms (presented in Section 3.3.2) to be less severe to long flows. We compare the performance of SFD, P-SFD, and S-SFD (K=4) * n Figure 3.9(a). Both P-SFD and S-SFD algorithms can benefit more long flows; S-SFD algorithm shows the improved performance for flows up to about 300K bytes, corresponding to more than 98% of all web traffic flows. Compared to the basic SFD algorithm, S-SFD algorithm reduces the response 35 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. latency for very long flows: the reduction is about 90% for 1M byte flow (down to about 3-5% higher than DT case). Since S-SFD shows greater improvement and is easier to implement than P-SFD, we believe the S-SFD is a good choice to be deployed in networks. In the remaining part of this chapter, we use S-SFD as the default SFD algorithm. The flow identification threshold directly affects the flows that SFD favors. Intuitively, smaller thresholds are likely to penalize more flows, while larger ones may reduces SFD performance im provement for short flows. We study the performance of SFD with flow identification thresholds as 25Kbytes and 35Kbytes below. As shown in Figure 3.9(b), we observe slightly lower perfor mance for SFD with larger thresholds than 15Kbytes. Since the the difference for performance improvement of short flows is less than 10%, we believe that 15K bytes is a reasonable threshold for the traffic we study in our simulations. Ideally, the threshold should be able to adapt to the traffic mix observed. However, since the statistics of Internet flow size only show little changes over a relatively long period (a few years, for example), we believe that a static threshold chosen from off-line analysis is feasible. In fact, Guo et. al. showed that a threshold dynamically determined through traffic observation only shows little variance [51]. This further supports that the choice of a static threshold in this work is reasonable. 3.4.4 Overall Effects on End-user Browsing We have shown that SFD reduces the response latency for more than 98% web objects (corre sponding to short flows, both observed from simulation and estimated based on real network traces U C B 96 an d BU 98). However, we can n o t conclude th a t SFD also accelerates overall web page retrievals. There are two reasons. First, web pages may have combinations of objects with different sizes as we will demonstrate in Table 3.5. Second, based on our observation in previous sections (3.4.2 and 3.4.3), SFD benefits the transmission of small objects (for example, short text), 36 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. but is likely to penalize rich contents such as movie. Therefore, in order to evaluate the overall effect of SFD on end-user browsing, we need to examine web page retrieval latency. We describe our approach to estimate web page retrieval latency below. Different implementations of browsers and web servers restrict the number of web objects which can be retrieved simultaneously, that is, the number of concurrent connections. We examine two extreme cases below: • Parallel retrieval: The number of allowed concurrent connections is infinite: all web objects on one page are transferred in parallel. In this case, the web page retrieval latency is always determined by the largest object embedded [38] and can be simply estimated with its response latency. • Sequential retrieval-. The number of allowed concurrent connection is 1: web objects are transferred sequentially (similar to H T T P /1.1 with persistent connection). In this case, the web page retrieval latency can be estimated as the sum of transmission latencies of all web objects embedded. We believe that these two cases give us some hints about what the end-user perceived la tency for web page retrieval is likely to be. They may also show latency bounds under certain circumstances. We start with 5 representative types of web pages listed in Table 3.5 (taken from [38]). We estimate the mean page retrieval latency with S-SFD under both parallel and sequential retrieval strategies and compare the result with DT case. The absolute values of latency and improvement (in percentage) are sum m arized in T able 3.6 (positive value m eans red u ctio n in retrieval latency). We find that SFD can reduce the page retrieval latency for all these 5 types of web pages: by 15% to 77% in parallel retrieval case and by 31% to 43% in sequential retrieval case. We also observe that the improvement is not significant if the web page has a large object embedded (for example, 37 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. W eb O bjects N um ber o f W eb P age T ypes W eb O bjects N am e Size (K Bytes) O bjects E m bedded Text page large HTML part 29 1 medium images 7-13 3 Map page small HTML part 5 1 small images 1-3 3 large image 67 1 Graphics page medium HTML part 7 1 small images 1-3 9 medium images 9-12 4 Frames page small HTML parts 1-2 4 medium HTML part 7 1 large HTML part 83 1 small images 1-3 14 medium images 5-19 7 Java pages medium HTML part 8 1 small images 1-2 7 medium images 4-11 3 small Java parts 1-3 14 medium Java parts 4-18 11 Table 3.5: Five representative types of web pages (taken from [38]). Parallel R etrieval Sequential R etrieval P age typ es D T S-SFD Im provem ent D T S-SFD Im provem ent Text Page 1.27 0.78 39% 3.7 2.16 42% Map Page 2.28 1.47 36% 4.1 2.52 39% Graphics Page 0.83 0.47 77% 7.63 4.32 43% Frames Page 2.21 1.87 15% 15.92 9.47 41% Java Page 1.03 0.69 33% 20.88 14.43 31% Table 3.6: Latency (seconds) to retrieve different web pages. Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 0.9 0.7 0.6 U _ Q 0.5 O 0.4 Sequential - retrieval Parallel retrieval 0.3 0.2 / * ■ 30 40 50 60 -20 -10 0 10 20 Improvement in Latency (in percentage) Figure 3.10: CDF: Improvement of web page retrieval time with S-SFD. the Frame page contains a 83KB HTML part), because SFD increases response latency for large objects. Since these 5 types of web page are not equally likely to be retrieved in reality, we further estimate web page retrieval latency from real trace UCB96. We compute page size (including all objects on the page) by grouping requests with the same source and destination pair together. More specifically, we treat requests for html or htm objects as the beginning of new web pages, and other requests between two adjacent html or htm objects as embedded objects on that page. We estimate web page retrieval time with and without SFD under both parallel and sequen tial retrieval strategies. Then, we calculate SFD’s improvement (as a percentage) and plot its Cumulative Distribution Function (CDF) in Figure 3.10 (positive percentage means reduction in latency). We find that, by applying SFD, more than 90% web pages are transfered at least 30% faster. On the other hand, only less than 1% web pages show longer retrieval time than with droptail queuing. Therefore, we conclude that SFD reduces web latency in general. We also notice that persistent connection of HTTP/1.1 may increase the number of long flows. On one hand, SFD reduces response latency for short flows regardless of the percentage of long flows observed. On the other hand, it may not be desirable for SFD to penalize those long flows due to persistent connection if majority web transactions adopt it. 39 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 10 DT — RED — i S F D < 1 0.1 10 100 1000 1 Flow Size (KBytes) (a) Light network load 1000 DT — RED - - S F D ... w - o c o o 05 ( f ) 100 >. t > c 05 1 5 c O '« (0 'E ( 0 c CO h * c co 0 5 5 1000 100 1 10 Flow Size (KBytes) (b) Heavy network load Figure 3.11: Mean response latency under different network loads (in log-log scale). Recent measurements show a notable percentage (40-50%) of web objects are now transferred by persistent connections; but pipelining of request/response has not been supported by popular browsers yet [97]. So, with H TTP/1.1, web objects are transferred by one long flow with short idle time intervals (1 second, for example) in between. Since SFD resets flow states after a time period equal to this idle interval (as discussed in Section 3.3), the transfer of different objects within a persistent connection will be treated as separate flows. Therefore, SFD still favors short interactions within one long persistent connection. Overall, we believe that SFD should show similar performance for HTTP/1.1 web traffic as we have shown for H TTP/1.0 traffic. 3.4.5 Perform ance under Different Network Loads As presented in Section 3.2.1, low performance of short flows are due to packet dropping and queuing delay. Since b o th factors becom e m ore severe as traffic load increases, th e response latency of short flows increases under heavy network load. To evaluate the impact of network load on SFD performance, we repeat above simulations under light and heavy network loads. We have shown corresponding simulation configuration in Table 3.3. 40 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. We show the response latency of different flows under light and heavy load in Figure 3.11. We find th at under light network load, neither RED or SFD gives considerable performance improvement. SFD performs very similar to RED except very long flows are slightly penalized, increasing the mean response latency for 1Mbyte flow by 7%. On the other hand, SFD shows dramatic performance improvement for short flows under heavy load: short flows are transm itted more than 10 times faster. In the mean while, SFD increases response latency for long flows by about 2 times. Recall the comparison under medium network load shown in Figure 3.8, we claim that SFD achieves larger performance improvement as the network load increases. Intuitively, this observa tion is consistent with the idea of “network hole plugging” : at light load there is little traffic so flow differentiation is irrelevant. But, under heavy load, short flows suffer more packet dropping and queuing delay. So, protection imposed by SFD shows more significant performance improvement for short flows. 3.4.6 Sensitivity to Sim ulation Configurations The simulation results above are from a very simple scenario: simple dumbbell topology with only web traffic. To investigate the sensitivity of our previous results to network configurations, we relax the following aspects of our simulation scenario: network topology, flows with various RTTs, presence of non-web traffic, and the effect of web server CPU processing delay. While we can not claim to simulate “the Internet” [46], these results can help us to better understand the dynamics of SFD. N etw ork topology: C hoice of sim ulation topology is difficult. R a th e r th a n selecting an arbitrary topology from a real network, we focus on controlled studies of restricted topologies to understand specific network effects (as has been previously observed by Feldmann et. al. [42]). A limitation of a simple dumbbell topology (Figure 3.6) is that there is no intermediate queuing in 41 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Mean Transmission Latency (seconds) bandw idth: x bps delay: 10m s ~ 250m s 10M b 10m $' 10M b 10 or 500m s FTP traffic F igure 3.12: A Network with Two Tiers of Clients. 4 DT 3.5 3 2.5 SFD 2 1.5 1 0.5 0 12 14 4 6 8 10 2 Flow Size (KBytes) (a) S F D red u ces resp o n se la te n c y for sh o rt flow s DT — SFD - h 10 1 0.1 1000 10 100 1 Flow Size (KBytes) (b) Im p a ct o n lon g flow s F igure 3.13: Similar performance in a two-tiered topology as in a simple dumbbell topology. 42 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 3.14: SFD performance varies with different RTTs. the network. To relax this limitation, we repeat simulations in a topology (shown in Figure 3.12) with two tiers of clients being connected to router R2 with various link bandwidth and propagation delay. Thus, the second tier links could also become bottlenecks besides the link between RO and R l. We show the response latency of short and long flows for this configuration in Figure 3.13. Similar to our previous results, SFD protects short flows and penalizes long flows. As shown in Table 3.4 (scenario 2-tier), SFD reduces the response latency for short flows by 23%. We also observe that the response latency of very long flows (1M bytes) increases by about 20%. We therefore conclude that the intermediate queuing does not substantially change the performance of SFD. Various RTTs: For short flows with same flow size, their performance improvement due to SFD may vary as flows have different RTTs. To investigate this effect, we examine traffic statistics in the simulation above and group flows with same RTTs together. In Figure 3.14, we show the mean reduction in response latency for short flows with different RTTs. We observe that the variation of SFD’s performance is not significant. In order to discover its relationship with RTT, we further compute their coefficient of correlation. The result is about 0.3, which suggests that 43 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. SFD performance improvement is weakly correlated with RTTs, with slightly more benefit for far flows (with large RTTs) than for near flows. We have shown th at SFD improves the performance for short flows. We also note that far flows have worse performance than near ones. Therefore, it is not surprising that short, far flows would have a larger relative improvement than others, since they are favored (short) and can be largely improved (far). P resence o f non-w eb traffic: To evaluate SFD performance with presence of non-web traffic, we inject FT P traffic from node cs to node cc (refer to Figure 3.12). Simulation results confirm that SFD still protects short web flows effectively, ft also penalizes FT P traffic similarly as long web flows: reducing their goodput by about 40%. In the study above, we note th at long flows with low rate (for example, long FT P flows with large RTTs) have little effect on short flows’ transmission. However, SFD still penalizes these long flows because it differentiates flows only by their sizes. A potential variation could be to differentiate flows by their rates [70]. Server C P U delay: For all simulations above, we emphasize network queuing effect on the response latency of short flows. While network latency is our major concern, CPU delay is also im portant for busy web servers. We briefly investigate this effect below. We add a simple CPU model to web servers in our simulation. We assume that server CPU has infinite buffer size and constant processing rate that does not change under different loads. We implement two simple server scheduling policies: first-come, first-serve (FCFS) and shortest task first (STF). For STF policy, we assume that the server always knows the size of web object requested. We simulate two scenarios: network-limited, where the bottleneck is in networks, and server- limited, where servers process requests slowly. In both scenarios, we apply four combinations of server and network scheduling policies: DT+FCFS, D T+STF, SFD+FCFS, and SFD+STF. We 44 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. — . 8 FCFS+DT — * — STF+DT — e— ' FCFS+SFD x—- STF+SFD 3— FCFS+DT — x— FCFS+SFD - - X - - STF+DT — b — STF+SFD b— 1 2 6 10 14 14 2 4 8 12 4 6 8 10 2 Flow Size (KBytes) Flow Size (KBytes) (a) N e tw o rk -lim ite d S cen a rio (b ) S erv er-lim ite d S cen ario Figure 3.15: Mean end-to-end latency of short web flows under different scenarios. S cenarios D T+STF SFD+FCFS SFD +STF Network-limited 6% 21% 23% Server-limited 35% 16% 41% Table 3.7: Reduction in end-to-end web latency under different scenarios and scheduling policies. measure the end-to-end web latency for each request and response exchange, that is, the time from client sending out a request till it receiving the last packet of corresponding response. We show simulation results in Figure 3.15 and summarize performance improvement for short flows in Table 3.7. We find that the combination of SFD and STF always gives the best perfor mance (lowest end-to-end web latency for short flows) in both network-limited and server-limited scenarios. On the other hand, DT and FCFS always shows the worst performance. Further, the improvement by server scheduling policy is fairly small (less than 6%) in a network-limited sce nario (Figure 3.15(a)). Similarly, network scheduling policy has limited effect in a server-limited scenario, reducing end-to-end latency by 16% (Figure 3.15(b)). In summary, we find th at router and web servers should give higher priority to short web connections. Generally, these algorithms will reduce perceived web latency for end-users, 45 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 3.5 Sum m ary In this chapter, we investigated the interaction among short and long web traffic flows and showed how this interaction affects the response latency of short flows. We proposed an aggregate-level traffic control algorithm, SFD, to give preferential treatm ent to short flows. We showed that our algorithm reduces both the response latency for short flows and the overall web latency. We also investigated penalty to long flows and the sensitivity of our simulation results. In this case study, we focused on end-user perceived web performance. Particularly, we showed that SFD protects short flows when network is severely congested. SFD also reflects our general design guidelines. More specifically, SFD determines flow length through the sum of packet size observed for a particular flow. That is, the traffic observation metrics for SFD is packet size. SFD uses a static threshold to identify short flows. We have shown that the performance of SFD is not sensitive to this threshold. Since the composition of Internet traffic evolves slowly over a relatively long time period (for example, several years), SFD does not need to adjust the threshold according to transient changes in traffic mix. On the other hand, as we will show in our next two case studies, NEWS and DEW P identify aggregates (that is, flash crowd traffic and worm probing traffic) based on online observation. Since SFD continuously identifies short and long flows, we did not address the guideline of “choosing proper timescales” in this case study. We will investigate this issue in next two chapters on NEWS and DEWP. SFD drops packets in long flows with higher probability. As we will discuss in next chapter, the scheme of probabilistic packet dropping was also applied in our earlier design of NEWS. We also considered server effect in NEWS performance evaluation. 46 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 4 M itig a tin g F lash C row ds v ia A d a p tiv e A d m ission C ontrol based on A p p lication -level O bservations We have presented a high-level control algorithm, SFD, which improves end-user perceived per formance by differentiating short and long flows and giving short flows preferential treatment. We also showed that the effectiveness of SFD under heavy load. In this chapter, we consider a more severe case where networks and servers are persistently overloaded by flash crowd traffic. Flash crowds impose threats to both end-user perceived performance and infrastructure stability. Below, we apply an aggregate-level control algorithm to mitigate flash crowds. Recent studies [58, 69, 84, 56] show that the Internet is vulnerable to persistent overloading caused by flash crowds [58, 56]. Flash crowds happen when many end-users simultaneously send requests to one web site usually because of special events attracting interest of mass population. These events could be pre-scheduled such as webcast of a popular movie, or unpredictable includ ing natural disasters such as earthquakes, breaking news stories and links from popular web sites (that is, the “slash-dot effect” [3]). F lash crow d traffic p ersisten tly overloads server or netw orks. W h en a flash crow d happens, the volume of requests toward the target web server increases dramatically. The magnitude may be tens or hundreds times than normal conditions. These requests may overload network connections [69, 58] and the target server. In the mean while, response traffic could also congest 47 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. request ( client Ack counting response ack TCP Congestion Control A V request ack : congestion; • window j .adjustment (a) T C P c o n g e stio n c o n tr o l request (server) (client ) NEWS Control request limiting • it : server EC flash ■ response crowd ■ 1 detection (b ) N E W S co n tro l b e tw e e n req u ests a n d resp o n ses. Figure 4.1: Comparison of TCP congestion control and NEWS. networks (often in first few links where traffic concentration is the largest). As a result, most users perceive unacceptably poor performance. In addition, flash crowds unintentionally deny services for other end-users who either share common network links with flash crowd traffic or retrieve unrelated information from the target server. We call the corresponding traffic bystander traffic. 4.1 A ggregate-level C ontrol b etw een R eq u ests and R esp o n ses The Internet applies TCP congestion control to cope with resource constraints [45, 54]. As shown in Figure 4.1(a), TCP adjusts its window size according to acknowledgments received and infers network congestion from packet loss. However, TCP is not able to relieve the persistent over loading during flash crowds because it only regulates per-connection behavior. Other congestion control algorithms that aggregate information per-host (for example, the congestion manager [8]) also fail to solve this problem because connections arrive from many hosts during flash crowds. In this chapter, we propose network early warning system (NEWS), a router-based system, to impose aggregate-level control between requests and responses. As shown in Figure 4.1(b), 48 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. NEWS (a) N E W S en fo rces c o o p e r a tio n a m o n g T C P s . K (NEW S) A (clients) P (server and networks) (b ) T ra d itio n a l co n tr o l d iagram o f N E W S . P: th e c o n tro l p la n t o f N E W S , K: th e c o n tr o l a lg o rith m , A : th e o th er p a rt in c o n trol loop . F ig u re 4.2: NEWS control diagrams. NEWS observes web response performance (that is, flash crowd detection) and adjusts incoming request rate to the target server accordingly. Figure 4.2(a) shows the logical relationship between NEWS and TCP. The Internet has many individual TCP congestion control loops to enforce right behavior at connection level. However, they only operate on their own and do not cooperate with each other. It is the lack of cooperation that makes flash crowds possible. On the other hand, NEWS enforces cooperation among indi vidual TCPs. As a result, we have a global control of TCP connections during flash crowds and will not allow excessive connections to overwhelm servers and networks. Figure 4.2(b) depicts the control logic of NEWS with a traditional control diagram. 4.1.1 Contributions NEWS is a router-based adaptive admission control mechanism to impose aggregate-level control between requests and responses. It has two novel aspects. 49 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. First, NEWS does not consider per-flow service requirement for incoming requests like most admission control schemes [21, 23, 74, 89]. Instead, it determines end-user perceived perfor mance through measurement. Moreover, NEWS only measures performance for aggregates (de tails in Section 4.3.1), rather than for all existing flows like measurement-based admission control (MBAC) [21, 23]. NEWS is also different from schemes th at monitor increase in requests directly [19, 58]: It detects flash crowds from performance degradation in web response. As discussed in Section 4.2.2, observation in response traffic captures overloading both at the target server and in networks. On the other hand, increase in request rate alone does not necessarily imply low performance for end-users. Therefore, we believe th at we should detect flash crowd by monitoring response performance. Second, NEWS monitors changes in the performance of high-bandwidth responses because of their sensitivity to overloading conditions. Based on this observation, NEWS adjusts adm itted re quest rate automatically and adaptively. These two approaches make NEWS a self-tuning system, adaptive in both server- and network-limited scenarios (as we will show in Section 4.6.2, 4.7.2, and 4.7.3). In the case of multiple servers connecting through NEWS router, we propose the hot-spot identification algorithm (Section 4.3.4) to help NEWS regulate incoming requests intelligently. That is, automatically identifying one hot server even if many other servers are operational behind the NEWS router. 4.1.2 N EW S Performance Evaluation We first evaluate NEWS performance through simulations in Section 4.6. We find that NEWS detects flash crowds within 20 seconds. By discarding about 32% incoming requests, NEWS protects servers and networks from overloading: reducing response packet drop rate from 25% to 50 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2%. NEWS also increases the response rate for adm itted requests by two times. This performance is similar to the best possible static rate limiter deployed in the same scenario. We further implement NEWS on a Linux-based router (Section 4.5). W ith testbed experiments (Section 4.7), we validate NEWS performance in a network-limited scenario quantitatively in a more realistic experimental model than simulations. We also configure a server-limited scenario, where request processing exhausts server’s memory. We show th at NEWS is an adaptive system; effectively prevents server and network overloading in both cases. More specifically, NEWS detects flash crowds around one detection interval (88 seconds with 64 seconds’ detection interval). It automatically regulates incoming requests to a proper rate. As a result, NEWS protects target server and networks from overloading by discarding about 49% excessive requests. NEWS also shows similar performance improvement for accepted end-users as in simulation study. We also find through both simulations and testbed experiments that NEWS effectively pro tects traffic to nearby, bystander servers. For example, it reduces median end-to-end latency for bystander web traffic by about 10 times (Section 4.7.6). We investigate the overhead of NEWS detection algorithm in Section 4.7.5.1. Our analysis shows that NEWS has similar algorithmic performance as a stateful firewall. We further examine NEWS’ runtime overhead with testbed experiments, measuring router CPU and memory usage during a flash crowd. Our statistics (Section 4.7.5) show that NEWS only consumes less than 5% of CPU time and 3-10MB memory. Overall, NEWS imposes small overhead on routers and is applicable to real networks. We also investigate system performance of target server under flash crowds in details. We also study the effect of detection interval on NEWS performance in both simulations and testbed experiments. Our results show that NEWS triggers false alarms with small intervals like 15 or 30 seconds. On the other hand, larger detection intervals increase NEWS detection 51 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Target Client (C ) Server (S) ----- _ request : Tr(S,C) Tw T(resp) Time Tim e Figure 4.3: Request and response transmission latency, web connection life time, and request interval. delay. We investigate this trade-off (between detection delay and false alarm rate) in Section 4.6.4 and 4.7.4. 4.2 F lash C row ds and E arly W arning Flash crowd traffic shows different patterns than normal traffic [58]. In this section, we show some of its characteristics by examining two server HTTP logs. One was collected when a flash crowd happened to a private server (slash-dot effect [3]), the other is from 1998’s World Cup web site (www.france98.com). To better describe the characteristics of flash crowd traffic, we first define some terminologies. As depicted in Figure 4.3, a web connection from client C to server S contains one (with H TTP/1.1 [48]) or a series (with H TTP/1.0 [16]) of request and response exchanges. We define the life time of this web connection (Tw) as the time interval from a client sending the first request packet till it receiving all response packets. We quantify the performance of request and response flows with the following two metrics. T ra n sm issio n la ten cy, T(f), records the time interval (in seconds, for example) from the first packet being sent till the last packet being received. Transmission rate, R{f), measures flow bit rate (in bits per second, for example). Flows show various transmission latencies and rates due to server load and congestion condition in networks. 52 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. From the servers’ point of view, we define request interval (T r (S ,C )) as the time between two adjacent requests th at server S receives from client C. We denote T r (S ) as the interval of request from all clients to server S. Alternatively, we define R P(S ) as the request rate (in number of requests per second) observed by server S. Rp(S) records the number of requests sent to S within one time unit. 4.2.1 Observations of Flash Crowd Traffic We present two observations based on the statistics of two web server log files. First, requests show very small inter-arrival time: the mean request interval is around 1 second in the slash-dot trace and less than 10ms in world cup trace. Sometimes, the target server even recorded same arrival times for some requests due to its time granularity. So, the request rate shows a spike when a flash crowd happens. Second, we find that most connections are short in the two log files we study. That is, they retrieve small pages1. In both logs, most (90% for slash-dot log and 50% for world cup log) requests are for pages less than IK bytes. In World Cup HTTP log, more than 90% requests are for pages smaller than lOKbytes. And, they carry about 50% network load. So, there is a concentration on small pages in the log files we study. Based on these observations, we propose a simple two-layered flash crowd traffic model to test our design in early stages (details in Section .1). The characteristics of flash crowd traffic impose challenges for detection. In this study, we focus on detecting flash crowds caused by unpredictable events. This is the most challenging case because of uncertainties in three aspects including happening time, user interest (that is, the magnitude of request rate increase) and response size. In this study, we propose an adaptive algorithm to detect flash crowds without knowledge of these information. l T h e a c tu a l r esp o n se s ize varies in d ifferen t scen a rio s, a cco rd in g to c o n te n ts h o sted o n ta r g e t servers. 5d Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. requests target server response^ t I I packets dropped Figure 4.4: Server and network overloading during a flash crowd. 4.2.2 Reduced W eb Perform ance during Flash Crowds End-users may experience increased web latency during flash crowds. As shown in Figure 4.4, several factors contribute to this increase. First, even though each request may only contain just one small packet, too many of them can still cause congestion in networks. So, requests may be delayed or even dropped by networks. Second, the target server only accepts part of incoming requests due to its CPU or memory constraint and simply discards others. The target server is overloaded during flash crowds. It processes requests and generates responses slowly. Finally, responses contain number of larger packets and inject more load than requests. They are more likely to congest networks and increase transmission latency. When a response packet is dropped due to congestion, the target server needs to retransmit the lost packet even it is already overloaded. Traditional approaches detect flash crowds from increases in request rate. However, as we will show, this increase does not necessarily correlate with overloading conditions during a flash crowd. Other factors such as system capacity and response size are also important. In different circumstances, flash crowds may cause overloading at the target server or in net works. However, from end-users’ point of view, they always perceive an increased web latency or a decreased web response rate. Therefore, we design NEWS to detect flash crowds from degradation in web response rate. As we will show in Section 4.7, this approach helps NEWS to adapt to both network- and server-limited scenarios automatically. 54 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. response (outgoing) response N E W S request request (incoming) Control Logic Request Regulator Flash crowd Detector server Figure 4.5: The Architecture of NEWS 4.2.3 Overall D esign o f Network Early W arning System As shown in Figure 4.5, NEWS has three main components: the flash crowd detector, the request regulator, and the control logic. We design NEWS in a modular style so th at we have the flexibility to apply new techniques without modifying its framework. For example, we could adopt web caching techniques in the module of request regulator. We present the detailed design of flash crowd detection and regulation in Section 4.3 and 4.4. NEWS imposes a global control loop over many individual TCPs (as shown in Figure 4.2(a)). Unlike T C P ’s small time scale (that is, RTT), this global control loop operates at larger time scale such as 1 minute (discussed with more details in Section 4.6.4 and 4.7.4). As a result, NEWS can apply more sophisticated techniques while only imposes small run-time CPU and memory overhead to routers (shown in Section 4.7.5). For example, we can apply complicated change detection algorithms or implement fine-grained request regulator. We have three assumptions when designing NEWS. First, we should be able to deploy NEWS reasonably close to the target server. For example, we install NEWS on the access router of the target server or the server farm it operates. 55 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Second, we assume that request and response traverse the same access router. As depicted in Figure 4.5, when the access router is close to the target server, it is reasonable to treat in coming traffic as request and outgoing traffic as response. So, the access router does not need to decode application-level information for NEWS, for example, examining packet contents for HTTP header. This assumption well holds for the case of server farm. But, sometimes, the net work behind NEWS router might also provide Internet services for end-users. In this case, both incoming and outgoing traffic are mixed with web requests and responses. So, the assumption above is questionable. Therefore, it is im portant to deploy NEWS near the target server. We are also concerned about deploying NEWS to a multi-homed network, where requests and responses of the same web connection may traverse different routers. In that case, we need to distribute NEWS to all access routers, and coordinate flash crowd detection and request regulation at different points. But, further investigation is needed to solve the difficulties in coordination among these routers. 4.3 D etec tin g F lash C row ds As shown in Figure 4.5, flash crowd detector sets alarm signal after it detects flash crowds. In this design, we consider the following three issues: 1. What to monitor and how? As described above, NEWS detects flash crowds by discovering decrease in response rate. Since overloading either at the target server or in networks could cause low response rate, NEWS adapts to server- or network-limited scenarios [37] easily. We discuss our approach to monitor response performance in Section 4.3.1 2. How to detect changes? Change detection algorithm [14] is well studied in many fields such as signal processing and pattern recognition. Basically, it is the scheme that determines whether a change has occurred in characteristics of considered object. In this work, we tend to use a simple change detection algorithm to avoid computation complexity. On the other 56 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 0.9 a > 5 < D « c o Q. W £ '« 5 o o L L a o with flash crowd without flash crowd 0 25 50 75 100 125 150 175 200 response rate (Kbps) Figure 4.6: CDF of Flows’ Response Rate in Flash Crowd and Background Traffic. hand, we augment our algorithm with observations in network traffic to increase detection accuracy. We present our change detection algorithm in Section 4.3.2 3. When to set and reset the alarm signal? To address this question, we need to consider two trade-offs. When setting the alarm signal, we intend to achieve reliable detection (that is, low false alarm rate) at a cost of relatively long detection delay. When resetting the alarm signal, we try to avoid fluctuations in output at the risk of penalizing more incoming requests. As we will show in Section .1, frequent variation in request regulation affects end-user performance and leads to resource under-utilization. 4.3.1 H igh-bandwidth Connections Flash crowd traffic usually originates from hundreds or thousands clients. Some clients may not have visited the ta rg e t server before. W e call them cold clients. Form ally, a client, C is “cold” with respect to server S if Tr(C,S) > TVo (TVo is a constant, for example Tro = 24 hours). The existence of cold client implies that we can not monitor perceived performance for particular clients because they may not even attem pt to access the target server before the flash crowd. 57 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Also, as we have shown in Section 4.2.1, web connections during flash crowds could be short (a few packets, for example). Therefore, we can not monitor performance of particular connections either because they may disappear from our traffic observation. Further, monitoring the mean rate of all responses observed is not helpful either because flows react to congestion differently, with fast connections noticing congestion quickly, while low-speed flows (such as to users connected through modems) showing very little change. Thus, congestion results in very little change in average response rate because of those inherently low-speed flows. We propose a novel flash crowd detection algorithm by monitoring changes in the response performance of fast connections, th at is, high-bandwidth connections (HBC). These connections are most sensitive to congestion. We call the response flows of HBCs high-bandwidth response flows (HBFs). These flows form an aggregate 4 > h b f • We denote the number of flows in an aggregate as \< j> \. For example, \< p \ = 10% x |4?|, where $ is a special aggregate containing all flows. We can formally define $ as $ = </>(*,*), which implies that V < /> C < I > . To quantify the performance of an aggregate < / > , we define its transmission rate (A R $) as: We investigate the sensitivity of HBF to network congestion through simulations (detailed simulation methodology in Section 4.6.1). We measure the response rate (R ( f )) of each individual flow before and during flash crowds, and compare their cumulative distribution functions (CDFs) in Figure 4.6. If we choose 10% flows with the highest rate as HBFs, their transmission rate decreases about 78% during flash crowds. On th e o th e r h an d , if we average response ra te over all responses, th e m ean transm ission rate only decreases by 52%. Even worse, the mean rate for 10% slowest responses only reduced by about 40% during the flash crowd. Therefore, we confirm that HBFs are most sensitive to overloading conditions. 58 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.3.2 Change D etection A lgorithm We use a simple comparison-based scheme to detect changes in response rate. Mathematically, the detector detects flash crowds if condition 4.1 (listed below) holds. After it detects flash crowds, NEWS detector watches increase in AR( f>HBF, which indicates performance recovery. The detector resets alarm signal when condition 4.3 holds. A R ^ j j b f ^ AR<f)HBF * (1 Rp > Rp x (1 T d) ARd > A R < P hbf x (1 + < 5 ) 0 < 6 <1 (4.1) (4.2) (4.3) (4.4) From the view of traffic control, both condition 4.1 and 4.3 choose the operation point for NEWS, that is, the long-term average of transmission rate of HBFs. The goal of NEWS is to regulate the interaction of underlying system (including server, networks and clients) so that its behavior (measured in Af?0HBF) is maintained within a reasonable range (represented by 5) of this operation point. In above conditions, 5 reflects system’s tolerance to changes. For example, with 6 = 10%, the algorithm detects an increase when current measurement is 110% larger than average. We use condition 4.2 to reduce potential false detections. Specifically, since clients may be cold and connections may be short (details in Section 4.2.2), there are chances that only low- bandwidth hosts are active and responses only show low rate. In that case, computed among these low-bandwidth flows will cause NEWS to trigger false alarm. 59 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. To solve this potential problem, flash crowd detector also checks the aggregate request rate Rp when AR< f,HBF decreases. We define aggregate request rate (Rp) as the rate of all requests passing through a router toward the target server. W ith this additional check, the detector triggers alarm signal only when both AR< j )frBF decreases (condition 4.1) and Rp increases (condition 4.2). In this way, we are more confident that the decrease in AR<f,HDF is due to flash crowds rather than low-bandwidth connections. We calculate these long-term averages (AR^HBF and Rp) with a High-Low Filter (HLF). Very similar to the flip-flop filter [60], HLF is essentially a combination of two Exponentially Weighted Moving Average (EWMA) filters with adjustable gains to fulfill different requirements. We present an EWMA filter mathematically as: V(t) = a V (t — 1) + (1 — a)0(t). 0(t) is the current measurement (AR or Rp), V(t) is the long-term average calculated at time t (AR or Rp), and a is the gain of the filter. Large a gives a stable output; while small gain makes output sensitive to the current observation. HLF uses a low gain (a = = 0.125) under common situations without alarm signal for fast response to changes. When the alarm is set, we switch to a high gain (a = 0.875) to keep output stable and avoid oscillations. 4.3.3 NEW S Flash Crowd D etection Algorithm Flash crowd detector measures transmission rate of response flows with the time-sliding window (TSW) algorithm [31] to smooth the burntness of TCP traffic. We apply the configuration of TSW rate estimator recommended in [41]. The detector also measures aggregate request rate Rp by counting the number of incoming requests within one time unit. Every T seconds, the detector computes ARr j1HDF. Since the number of flows observed at different time could vary dramatically, we choose the top p percent of responses with highest rate as HBFs: \4>hbf\ = P x | $ | , P is a tunable parameter. We choose p = 10% based on the 60 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ( c o n n e c t io n s ta te s ) T ransm ission Rate o f H B Fs current request rate (Rq) current A R R (S ch ed u le next detection after T seconds ) ^ a v e r a g e Ri C om pute A R R U pdate lo n g -term averages Figure 4.7: Flow chart of flash crowd detector. observation in Figure 4.6. In our currently implementation, we keep transmission rate for all flows. Potentially, we can apply other schemes [39] to reduce this overhead. The detector calculates long-term average of transmission rate for HBFs (AR.,i,HBF) and ag gregate request rate (Rp). Finally, the detector compares AR with AR and Rp with Rp. It sets or resets the alarm signal according to conditions in Section 4.3.2. We show the complete procedure of flash crowd detection in Figure 4.7. 4.3.3.1 Sim ple A nalysis of N E W S D etection Interval The detection interval T is a tunable parameter. As we will show in Section 4.6.4 and 4.7.4, NEWS with smaller T detects traffic changes promptly but may trigger false alarms. On the other hand, a large T generates stable detection output but causes longer response time. In this section, we present a simple analysis to facilitate the choice of an “proper” detection interval. M ore specifically, we focus on th e effect of d etectio n interval on false alarm s. According to condition 4.1, NEWS detects the flash crowd when Rc < (1 — 5) x RQ , where Rc is the current measurement on the aggregate rate of HBFs. We also notice that the observed ag gregate rate changes constantly due to underline TCP window adjustment and network condition. 61 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. When this variation (more precisely, drop in response rate) is greater than detector’s tolerance 8, NEWS triggers a false alarm. Since there’s no congestion before a flash crowd happens, we mainly focus on the effect of TCP window adjustment, which leads to dynamics in TCP flow rate, and hence the response rate observed. We are particularly interested in the slow start phase because it has large impact on flow rate (double window size every RTT) and most web responses are short (as discussed in Chapter 3). Assume a response has a length of 5 Kbytes. If 5 is small, the life time of this response is L — log (5 + 1 ) x R T T seconds. Since most responses are less than 15Kbytes (according to Chapter 3), we can estimate L as 4 x R T T . So, we need to measure response rate in an interval of at least L seconds in order to correctly captures the flow rate of this response. An interval less than L seconds may lead to under-estimation of flow rate, and could cause NEWS to trigger false alarms. Therefore, we suggest to choose NEWS detection interval of at least 4 x R T T seconds. 4.3.4 Discovering Target Server After NEWS detects a flash crowd, it starts to identify the hot-spot, that is, the target server of flash crowd traffic. In many cases, servers operate in a server farm and connect through one access router. If we deploy NEWS on that access router, it must distinguish between flash crowd traffic going to a hot-spot and low-rate, bystander traffic going to other servers. In this section, we propose a simple hash-based algorithm to discover the target server. NEWS keeps a table of size N (hot-spot list). N is chosen based on the number of hot-spots required to identify. Each entry in the hot-spot list records one server address observed in the following procedure. It maintains a counter to record the number of corresponding address being accessed (hit.-mim.her) w ithin ce rta in tim e interval. Periodically, N E W S tim eo u ts inactive entries in the list. After NEWS detects a flash crowd, it randomly samples incoming packets and hashes their destination addresses into the hot-spot list with a function h(x) = x mod N. If the table entry 62 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. has the same address or not being used, NEWS increases the corresponding hit-number by 1. When the entry has been occupied by a different address, NEWS takes the next available entry in the hit-list. If the table is full, NEWS replaces the entry having the smallest hit-number and the longest inactive time with the new address observed. NEWS picks the address with highest hit-number as the hot-spot. Since we only consider request destination addresses, HSI only classifies incoming traffic at connection level. It can not differentiate traffic to different ports on the same server (that is, session-level classification). A potential future direction is to also consider destination port num bers, that is, to locate the target service at the target server. 4.4 M itig a tin g F lash C row ds NEWS mitigates flash crowds by discarding excessive requests. In this section, we present detailed design of request regulator and NEWS controller. When NEWS detects a flash crowd, it differentiates requests toward the target server from bystander traffic using the HSI algorithm. NEWS discards excessive requests during flash crowds with an adaptive rate limiter. As we will show in Section 4.6.2 and 4.7.2, dropped requests are retransm itted due to application or underlying TCP. 4.4.1 Regulating R equests A request regulator should ensure th at the adm itted request rate converges to a reasonable value (denoted as Rpc). Ideally, when requests arrive at rate Rpc, they fully utilize server and network resource. In th e m ean w hile, n eith er th e ta rg e t server nor netw ork is overloaded. We propose a token-bucket [83, 94] based adaptive rate limiter to regulate requests. A token bucket has two parameters: bucket size provides accommodation to bursty traffic, and token rate limits long-term arrivals. In long run, connections adm itted by a token bucket converge to the 63 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ARR + / - ARR rate ad justm ent * M describes server processing request and generateing response. * A is the algorithm to compute long-term average. Figure 4.8: NEWS control logic: score-board based rate-limit adjustment. token rate. Different from other simple token bucket algorithms, we design NEWS control logic to adaptively adjust token rate according to current observation on response performance and request rate. We present the detailed design of NEWS control logic in next section. In our early design, we tried the approach of discarding excessive requests preferentially [70] (similar to SFD). However, the result system is not stable: we observe oscillations in adm itted request rate, network load and end-user performance. This is because probabilistic dropping only guarantees expected behavior but may not lead to smooth output [69]. Further, it is also difficult to determine dropping probability for request based on measurement on response. This relationship may not be linear, and is also affected by variance in response sizes. Therefore, we propose to approximate their relationship with NEWS control logic. 4.4.2 Controlling the A daptive R ate Limiter We depict the function of NEWS control logic in Figure 4.8. Given the alarm signal, it adjusts rate limit of request regulator so that it adapts to different scenarios automatically. NEWS control logic maintains two states: current and previous alarm signals. It adjusts rate limit based on the rules described below. When alarm signal is set (transition from 0 to 1), NEWS control logic resets the rate limit to the current adm itted request rate R vo observed by detector. Intuitively, requests arriving with rate higher than R po are likely to overload the server or networks, and therefore cause decrease 64 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. in response performance. When alarm signal changes back to 0 (transitions from 0 to 0 or from 1 to 0), NEWS control logic keeps the same rate limit. If alarm signal remains set (transition from 1 to 1), NEWS control logic adjusts the rate limit with a score-board (as shown in Figure 4.8). More specifically, it assigns scores to adjustments of increasing and decreasing rate limit. It chooses the direction with higher score. For example, if current scores for increasing and decreasing rate limit are 5 and 3 respectively, NEWS control logic chooses to increase rate limit. If alarm resets (transition from 1 to 0) in next period, corresponding adjustment (that is, increasing rate limit) gets credit (now it is 6); otherwise it gets penalty (reduced to 4). W ith this scheme, NEWS learns to make decisions automatically from history. It also makes NEWS adapt to different environment without human interference. 4.5 Im p lem en tin g N E W S In order to investigate the applicability of NEWS to real network environment, we prototype NEWS on a linux-based router. We present NEWS implementation details below. We report our findings in testbed experiments in Section 4.7. We implement NEWS under the framework of iptables/netfilter [75]. Iptables/netfilter is the firewall subsystem for Linux kernel 2.4 and above. It provides various facilities such as stateful or stateless packet filtering, network address translation (NAT), and packet mangling. Netfilter and most functions of iptables (such as packet matching) are implemented in kernel. They process and manipulate packets according to different rules that users configure through iptables user interface. As shown in Figure 4.9, we implement NEWS as three kernel modules: connection state- keeping module, flash-crowd detection and control logic, and adaptive token bucket filter (ATBF). By dividing NEWS functions into different modules, we separate fast per-packet processing such as 65 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. netfilter iptables b u ck et token accepted incoming connections connections flash crowd detection & control logic connection state keeping Figure 4.9: NEWS implementation connection state keeping and packet matching and filtering from slow connection-based detection and control functions. We discuss the implementation of each module with details below. 4.5.1 Connection State K eeping We build the connection state-keeping module based on the connection tracking function in net filter, which keeps one record for each connection. Netfilter uses two specific terms to distinguish two directions of one connection, that is original and reply. For example, request in a web connec tion is in original direction, and response is in reply direction. In our currently implementation, NEWS keeps track of all connections. We measure memory consumption on NEWS router and investigate options to reduce memory usage in Section 4.7.5. We add a new state for each connection: response rate. That is, the data transmission rate (m easured in b its p er second) on reply direction. For web traffic, th is s ta te records th e ac tu a l d a ta rate end-users perceive. We compute connection response rate using time-sliding window (TSW) algorithm [31, 41]. We intentionally avoid first few control packets such as SYN and SYN-ACK to keep measured response rate stable. 66 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.5.2 Flash Crowd D etection and Control Logic Applying the algorithm described in Section 4.3, NEWS detects flash crowd periodically with an interval of T seconds. Based on alarm signal, NEWS control logic regulates incoming requests adaptively (Section 4.4) . The detection interval T is a tunable parameter. Since NEWS keeps traffic measurement for last T seconds, NEWS with a smaller detection interval is more sensitive to traffic change, and detects changes more promptly. However, the result is likely to oscillate, that is, have high false alarm rate. On the other hand, NEWS gives more stable output with larger detection interval at the expense of longer detection delay. A smaller detection interval also consumes more CPU time. But, larger T needs more memory to keep connection states. We investigate the effect of different detection intervals in Sections 4.7.4 and 4.7.5. Based on our experience, we choose T as 64 seconds for our experiments. 4.5.3 A daptive Token Bucket Filter We use an adaptive token bucket filter (ATBF) to regulate incoming requests according to Sec tion 4.4. We implement ATBF as an extension to iptables matching function. T hat is, any new connections that matches with ATBF are dropped. More specifically, each new connection adds some token into the bucket, ft passes through ATBF when there are enough tokens. Other wise, ATBF discards connections toward the target server by matching with the hot-spot list (Section 4.3.4). ATBF counts the number of accepted connections and reports it to flash crowd detector as current measurement of request rate. One observation in experiments is that connections have very small inter-arrival times, for example, a few milliseconds. To accurately keep track of token number, we have to measure time at fine granularity: micro-second. Since we can not afford the computational overhead of floating 67 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ...Q 2Mb 50Mb 2Mb 5Mb 2ms 10ms 10ms 10ms P FTP traffic (C50) R 2 R0 Figure 4.10: The two-level dumbbell topology in simulations. point number division, we scale the number of tokens both in bucket and for acceptance of one connection by 1,000,000 times. 4.6 A lgorith m E valuation through Sim ulations We first evaluate the performance of NEWS algorithm through simulations using the network simulator (ns-2.26) [106]. For fast algorithm design and evaluation, we prototype NEWS under the framework of DiffServ model contributed by the Advanced IP Networks group at Nortel Networks [86]. We further report our testbed experiments in next section. 4.6.1 M ethodology Figure 4.10 shows the network topology in our simulations. Router R0 connects a server pool with 5 web servers (S1-S5). SI is the target server. Router R2 connects 50 access routers (C1-C50). Router R1 connects R0 and R2, representing the intermediate network connection between servers and clients. Each access router (C1-C50) provides network connections for 20 clients. So, there are 1000 clients in total. To reflect the variance of link properties in real networks, we determine link bandwidths and propagation delays for second-tier links (that is, between access router and end 68 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. time (second) Figure 4.11: Request rate to World Cup’ 98 web site (used in simulations). hosts) by RAMP [62]. RAMP takes traffic measurement at USC/ISI and generates distributions of link properties such as bandwidth and delay. In this topology, the range of bandwidths and delays for second-tier links are 21K-10Mbps and 0.5ms-1.8 seconds respectively. Although we can not claim that this topology is representative, it does give us a scenario with intermediate queuing on the second-tier links and a mix of various link bandwidths and delays. We study two types of traffic: web traffic and bystander traffic (that is, other traffic sharing common links with flash crowds, details in Section 4.6.5). We generate web traffic (including background web traffic and flash crowd traffic) based on real HTTP logs on 1998 World Cup web site2. There were 4 servers deployed for this web site. Since they have shown similar patterns in request access [6], we only consider those requests toward the server at Santa Clara, California. These H TTP logs recorded all requests sent between April 30, 1998 and July 26, 1998 [61]. Each log entry keeps the following information: time when the server received a request, source and destination of a request, and size of the web page requested. Our web traffic model generates a web request for one log entry. Arlitt et. al. [6] analyzed workload characteristics based on these HTTP logs. They found that there was a large increase (5-10 times) in request rate before each game. This increase caused 2 W e h a v e a lso sim u la ted flash crow d traffic w ith a s im p le tw o -lev el m o d el in S e ctio n .1. 69 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. a flash crowd. In our simulations, we consider the game between Brazil and Scotland on April 30. We show changes in the corresponding web request rate in Figure 4.11. We observe normal traffic to web server before 1000 second. Flash crowd happens at around 1000 second with more than 6 times’ increase in request rate. We deploy NEWS on router R0. NEWS monitors web response rate (from R0 to Rl), and regulates incoming requests (from R l to R0) when it detects a flash crowd. We initialize NEWS by setting the bucket size and token rate of adaptive rate limiter to large values. For example, we set token rate as 1000 connections per second. It is about three times larger than the maximum request rate observed in simulations (about 350 connections per second). So, NEWS accepts all incoming requests under normal conditions. In most simulations below, we configure the detection interval of NEWS as 60 seconds. We present our study on different detection intervals in Section 4.6.4. We simulate scenarios with and without NEWS deployed. Each simulation runs for 4000 seconds. We record offered and adm itted request rate to the target server, and the transmission rate of HBFs. In following sections, we evaluate NEWS performance from both target server’s and end-users’ perspectives. We also investigate the sensitivity of our simulation results by considering effects such as impatient end-users and server processing delay in Section 4.6.6. 4.6.2 Protecting Networks from Overloading One goal to deploy NEWS is to protect the target server and networks from overloading. In this section, we simulate a network-limited scenario, where flash crowd traffic overloads networks with large amount of response traffic. Since NEWS detects flash crowds from observations of response traffic, we believe following findings are also valid in server-limited scenarios. We verify this claim in Section 4.6.6. In order to consider the effect of server CPU and memory constraint on request processing, we further configure a server-limited scenario in our testbed experiments (Section 4.7.3). 70 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. c c o > ■0-9 < D E 'IS 500 450 400 350 300 250 200 150 100 50 0 w ith o u t N E W S w ith N E W S 1000 2000 time (second) 3000 a > ■ ( 5 ^ . S E ? 28 3 S' CD oc_ E 4000 500 450 400 350 300 250 200 150 1 0 0 50 0 w ith o u t N E W S — ■ — -w ith N E W S ,. v - '' ** * /v A / / / v A . V V 2/ ■ f * V * ' / 1000 2000 time (second) 3000 4000 (a ) N E W S R e g u la te s th e A d m itte d R eq u e st R a te A d a p tively. (b ) In crea sed O ffered R e q u e st R a te d u e to R e tr a n sm is sion . Figure 4.12: Request rate to the target web server (observed in simulations). We first measure adm itted request rate to the target server without and with NEWS deployed (shown in Figure 4.12(a)). We observe that NEWS detects flash crowd at about 1020 second. That is, the detection latency is 20 seconds when the detection interval is set as 60 seconds. After detecting the flash crowd, NEWS adjusts its rate limit automatically and regulates incoming requests to about 107 connections per second. As a result, adm itted request rate drops by 32%. This greatly reduces congestion in response traffic by reducing packet drop rate from about 25% to 2%. Due to the bandwidth limitation in networks, NEWS discards excessive requests. These re quests m ay b e re tra n s m itte d du e to T C P , ap p licatio n an d client reactio n behavior [56]. As a result, we observe increase in offered request rate as shown in Figure 4.12(b). Although NEWS can’t serve all requests promptly, it does protect servers and networks from overloading. In the mean while, it gradually serves incoming requests. 71 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 140 . w ith o u t N E W S * 120 co 100 X c 60 o C O 0 0 1000 2000 time (second) 3000 4000 F igure 4.13: NEWS m aintains high transm ission rate for HBFs during flash crowds (observed in simu lations). 4.6.3 M aintaining High R esponse R ate for A dm itted R equests Another im portant aspect of this evaluation is to study the effect of NEWS on end-user web perfor mance. As shown in Figure 4.13, HBFs suffer a 50% performance degradation during flash crowds. Their transmission rate drops from 96 Kbps down to 58 Kbps. By deploying NEWS, adm itted end-users continuously receive high performance (90.5 Kbps) during flash crowds. Therefore, we conclude that NEWS protects adm itted requests from flash crowds. NEWS requires sophisticated techniques to achieve above performance improvement. One could argue that a simple static rate limiter is also able to give comparable performance with careful configuration. Ideally, we want NEWS to perform similarly to the best possible rate limiter in the same scenario. We investigate this issue in our simulations. We deploy static rate limiter on router R0 to control incoming requests. As depicted in Table 4.1 and Figure 4.14(a), static rate limiter shows different performance with different rate limits. In this particular scenario, we get the highest performance when we set the rate limit to 60 requests per second. We also anticipate higher end-user performance with even stricter limit. However, these limits are so strict th at more than two-thirds of incoming requests are discarded, which may under-utilize the underline system. 72 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Transmission R ate o f HBFs (Kbps) Scenarios A d m itted R equest R ate (n u m b er/s) R equest R ejection P ercentage Transm ission R ate o f H B F s (K bps) R esponse Loss R ate O riginal traffic 209.7 0% 58.2 25% N E W S 107.2 32.4% 90.5 2% S tatic rate 60 70.2% 101.36 0 lim iters 80 56.5% 100.2 0 100 40.2% 93.95 1% 120 32.8% 90.8 2% Table 4.1: Performance of NEWS and different static rate limiters in simulations. 100 NEWS R a te lim ite rs wo/ NEWS 50 100 150 200 Admitted Request Rate (number/second) 140 a §. 1 2 0 V ) m 100 X 2 80 a j C C c 60 0 't/i | 40 v > 1 20 0 Rate Limiter (60) NEWS w : ". 1000 2000 3000 time (second) 4000 (a ) C o m p a r iso n o f N E W S a n d d ifferen t ra te lim iters. (b ) C o m p a riso n o f N E W S a n d th e b e s t ra te lim iter. F ig u r e 4 .1 4 : T ran sm issio n r a te o f H B F s w ith N E W S a n d s ta tic r a te lim ite rs in sim u la tio n s. 73 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. We compare the performance of static rate limiter with NEWS in Table 4.1. We find that NEWS has similar performance to the best rate limiter: NEWS shows only around 11% less than the best static rate limiter in the transmission rate of HBFs. This result is encouraging because it verifies th at the adaptive rate limiter in NEWS approaches the best request rate, but without manual adjustment. We believe th at the overall performance difference between these two schemes reflects the cost for NEWS to adaptively discover the right rate limit after a flash crowd is detected (from 1000 to 1500 second, as shown in Figure 4.14(b)). On the other hand, NEWS only discards half of incoming requests compared to the best rate limiter. We highlight the transmission rate of HBFs with NEWS and static rate limiters in Figure 4.14(a). Given similar performance, we believe it is an advantage to deploy NEWS because it alleviates the workload for manual operations by detecting and mitigating flash crowds adaptively. 4.6.4 Effect o f D etection Interval NEWS periodically checks changes in the transmission rate of HBFs with an interval of T. As we explain in Section 4.3, this parameter reflects the trade-off between fast detection and low false alarm rate. In this section, we investigate NEWS performance with different detection intervals. From simulation results, we find that NEWS shows the best performance in terms of adm itted request rate and transmission rate of HBFs when we set detection interval as 60 seconds. We also notice th at small time intervals (like 10, 15, and 20 seconds) give inconsistent performance for HBFs. This result indicates th at it is hard to configure high-level controls like NEWS at small timescales. Recall our analysis in Section 4.3.3.1, this is due to the under-estimation of TC P flow rate. It is not unexpected that NEWS detects flash crowds quickly under very small intervals, such as 15 seconds and 30 seconds. In fact, with these small time intervals, NEWS triggers false alarm before flash crowds really happen. As a result, the adaptive rate limiter starts to regulate incoming requests. On the other hand, NEWS shows no false alarm with detection intervals larger than 74 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. False a la rm ra te (%) Transmission Rate of HBFs (Kbps) 140 120 100 40 20 30 60 90 120 150 180 0 detection interval (second) (a ) T ra n sm issio n r a te o f H B F s. e T3 < 200 100 50 0 0 30 60 90 120 150 180 detection interval (second) (b ) A d m itte d req u est rate. 100 60 40 20 30 60 90 120 150 180 0 detection interval (second) (c ) F a lse a la rm rate. 300 250 200 150 100 50 0 0 30 90 60 120 150 180 detection interval (second) (d ) D e te c tio n laten cy. Figure 4.15: The performance of NEWS under different detection intervals (observed in simulations). 75 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 90 seconds. But, the detection delay is also large. Based on these observations, we find that the detection interval of 60 seconds is feasible in the scenario we study. One possible way to reduce NEWS false alarm rate is to separate detection interval from the time period th at NEWS measures the performance for HBFs. We call this time period measurement window size. For example, NEWS measures the transmission rate for HBFs observed in past 90 seconds, but detects performance degradation with small intervals such as 30 seconds. As we will show in Section 5.5.6, the separation helps to reduce false positives in worm detection. On the other hand, we need to investigate its applicability to flash crowd detection in our future work. 4.6.5 Bystander Traffic Protection In real networks, there always exists other traffic (that is, bystanders), which we have not con sidered in our simulations so far. For example, web or FTP traffic to other servers connected through NEWS router. We investigate the effect of flash crowds and NEWS on bystander traffic in this section. This study has two goals. First, we verify NEWS performance with the existence of bystander traffic. More specifically, we investigate both flash crowd detection and response per formance for adm itted requests. Second, we are also interested in NEWS protection on bystander traffic. Since NEWS is an adaptive system, we expect NEWS improves the performance for both adm itted requests and bystanders. We examine these two aspects below. We study NEWS protection for both long-lived (such as FTP) and interactive (for example, Web) bystander traffic. We report our findings in the first case below. In Section 4.7.6, we further investigate both cases with testbed experiments. In our simulation, node S5 sends FT P traffic (long-lived) to C50 (refer to Figure 4.10). As shown in Figure 4.16(a), NEWS maintains high performance for admitted requests after detecting the flash crowd. The transmission rate for HBFs is 90.2Kbps before the flash crowd, and reaches 76 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. _ 800 ( / ) Q. §. 700 o 600 hou r N E W S w/ NEWS 3= 03 H < 5 _ 500 T3 $ 400 S' P - 300 h - L L o 200 " 5 f 100 o < 3 3000 4000 1000 0 2000 without NEWS with NEWS _ 14° ' i n § 120 (0 m 100 I S 80 "cS c c c 60 0 '55 1 40 w 5 20 C O H 2000 3000 4000 0 1000 time (second) time (second) (a ) M a in ta in in g h ig h p er fo r m a n c e for a d m itte d re- (b ) Im p r o v in g th e p er fo r m a n ce o f F T P b y sta n d er traf- q u e sts. fic. Figure 4.16: NEWS bystander traffic protection (in simulations). 86.4Kbps with NEWS deployed. Therefore, with the existence of bystander traffic, NEWS still shows consistent performance as in our previous study. We further show the goodput of FT P bystander traffic without and with NEWS deployed in Figure 4.16(b). We find that the mean goodput is about 337Kbps before flash crowd, then it drops to only about 10Kbps when flash crowd happens. W ith NEWS protection, the goodput of FTP traffic jumps back to about 120Kbps. So, NEWS improves goodput of FT P bystander traffic by more than 10 times. This improvement is because that NEWS relieves congestion in networks by discarding excessive requests. The traffic regulation benefits both web traffic and bystanders. So, we conclude that NEWS is also able to protect bystander traffic from flash crowds. 4.6.6 R esult Sensitivity to Other Sim ulation Param eters Above simulation results are from a much simpler scenario than reality. To investigate the sen sitivity of our previous results, we relax two aspects of our simulation scenario by considering impatient end-users and server processing delay. While we can not claim to simulate “the Inter net” [46], this sensitivity study together with our investigation on the effect of bystander traffic 77 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. in Section 4.6.5 helps us to better understand the dynamics of NEWS. We also gain confidence to deploy NEWS in real networks (we will report our findings in testbed experiments in next section). Impatient end-users: In real world, end-users may term inate their web requests after a long waiting time. We investigate this effect with a simple model. Our model cancels web requests th at are not served after a certain time period. It also assumes that end users’ waiting time has an exponential distribution and end users do not resume their requests after cancellation. In our simulation, we choose the average waiting time as 60 seconds. After timeout, end-users may decide if they want to continue to wait or cancel this request with equal probability. We repeat simulations with 60-second detection interval. Our results show th at NEWS still archives similar performance with the existence of impatient end-users. We believe that this result is reasonable because excessive requests (and their responses) are delayed and even dropped during flash crowds. Impatient end-users are unlikely to have large impact on this situation. On the other hand, Jamjoom et. al. has shown that retransmission due to persistent end-users (that is, very patient users) have large effect on flash crowd traffic [56]. This study also supports that the existence of impatient users does not have much effect on NEWS performance. Server processing delay: We focus on network perspective in our simulation so far. In reality, web servers impose processing delay to web requests. To investigate this effect, we add a simple web server model in our simulation. We assume th at web server has a constant processing rate (for example, lOOOKB/s in our study) and a buffer to hold incoming requests. Server applies first come, first serve (FCFS) scheduling policy and always processes the first request in its buffer. Server drops incoming requests, when its buffer is full, We first investigate a scenario where the target server has infinite buffer space. Simulation results show that NEWS gives similar performance (admitted request rate and transmission rate of HBFs) as in our previous study. This result is not unexpected because our web model only adds 78 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. delay between requests and corresponding responses. It does not relieve the overloading condition in networks. The response traffic still congests network connections. To get more realistic results, we configure the server with a limited buffer space of 1000 requests. We find that incoming requests quickly fill the server buffer, and more than 50% of requests are dropped. This effect is very similar to a simple static request rate limiter described in Section 4.6.3. Therefore, neither server CPU nor network links are overloaded. Based on these results, we conclude that our web server model in simulation does not have fundamental effect on NEWS performance. This is because our model focuses on adding server queuing and processing delay to incoming requests; it has the limitation to reflect server over loading condition, where CPU or memory is overwhelmed by incoming requests. To complete our study on server overloading condition, we configure a server-limited scenario in our testbed experiments in Section 4.7.3. 4.7 S y stem E valuation th rou gh T estb ed E xp erim en ts In Section 4.6, we have evaluated NEWS performance in simulations and shown that NEWS protects the target server and networks from overloading and maintains high performance for adm itted requests. In this section, we evaluate NEWS implementation with testbed experiments. We validate our previous simulation studies in a network-limited scenario quantitatively. More importantly, testbed experiments allow us to investigate server performance and router overhead (such as CPU and memory usage), which are not modeled in network simulations. We further evaluate NEWS performance in a server-limited scenario, confirming th at NEWS is an a d a p tiv e system , an d capable to prev en t overloading on server or in netw orks efficiently. B y examining its run-time overhead on router, we also show that NEWS is a relative light-weighted scheme. Finally, we evaluate the effectiveness of hot-spot identification algorithm through exper iments with bystander traffic. 79 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. W eb clients (C I-C 6 ) NEWS router (RO) router (R l) 100M bps 2M Fast ethem et switch lystander lient (B l) Fast ethem et switch Figure 4.17: Network topology in testbed experiment. 4.7.1 Experim ent Setup Figure 4.17 shows our testbed environment. All machines have 100Mbps fast Ethernet network interfaces. The client pool has 7 machines with various configurations ranging from 677MHz Pentium III CPU with 128MB RAM to 2GHz Pentium 4 CPU with 512MB RAM. We use 6 machines (C l C6) for flash crowd traffic generation, and one (B l) for bystander traffic experiment. Our server pool has 3 machines. Fast target server (SI) and bystander server (S3) have 2GHz Pentium 4 CPU and 512MB RAM. Slow target server (S2) has 180MHz Pentium Pro CPU and 128MB RAM. We connect client and server pools together through two routers RO and R l. We use Linux Redhat 9 (kernel 2.4.20-8) on all machines, including two routers. The NEWS router (RO) is a PC with 1.5GHz AMD Athlon 4 processor and 1GB RAM. We deploy NEWS on RO by enabling iptables service with NEWS extension. In most experiments, we configure NEWS detection interval as 64 seconds (found in Section 4.6.4). We also investigate the effect of different detection intervals in Sections 4.7.4 and 4.7.5 . We use NIST Net [79] to introduce network dynamics in our experiments. NIST Net allows Linux-based router to emulate a wide variety of network conditions, such as link bandwidth, prop agation delay, and packet loss. We configure link bandwidth between RO and R l as 2Mbps. We also set different p ro p ag a tio n delays betw een R l an d client m achines according to netw ork m ea surement at USC/ISI [62]. While we can not claim that our testbed simulates “the Internet” [46], this experimental study does help us to better understand dynamics of NEWS in a relatively real environment than simulations. 80 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 160 140 1 2 0 1 0 0 80 60 40 20 0 Log request rate i \ / i 1 / I .... I i [ 500 1000 1500 2000 Time (second) Figure 4.18: Request rate to World Cup’ 98 web site (used in experiments). Our web servers use TUX [63] to expedite request progressing. Running partially from within Linux kernel, TUX has demonstrated outstanding performance for serving static contents. We configure web servers with large SYN buffer size and H TTP backlog to ensure that they are fed with enough workload. We implement a traffic generator to playback web server log (discussed in Section 4.6.1) in experiments. It sends web requests to server according to information in log entries, such as time, server address, and request size. To simulate many concurrent connections, our traffic generation tool creates threads to accomplish request-response exchanges independently. Due to memory constraint on one single client machine, we distribute traffic generation across six client machines (C1-C6). In our experiments, we use HTTP logs as described in Section 4.6.1, but choose a different game. More specifically, we playback 2000 second of log from one semi-final between Brazil and Holland on July 7. As shown in Figure 4.18, request rate increased by about 5 times in just several minutes after the game started at 1000 second. We monitor web request rate both at NEWS router (RO) and the target web server. To quantify end-user perceived performance, we record transmission rate of HBFs on router R0. We also keep track of system and network statistics on each machine, such as CPU and memory 81 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 160 140 120 100 80 60 40 20 0 without NEWS w ith N E W S Log request rate J 0 500 1000 1500 Time (second) 2000 400 350 300 250 200 150 1 0 0 50 without NEWS w ith N E W S v M 500 1000 1500 2000 Time (second) (a) Request processing rate on target server. (b) Transmission rate of HBFs. Figure 4.19: Server and end-user performance during flash crowds (observed in experiments). usage, network utilization, and packet drop rate. We are particularly interested in changes in these statistics when flash crowds happen. 4.7.2 R elieving Network C ongestion We have two different experiment configurations, namely network- and server-limited scenarios. We have studied NEWS performance in a network-limited scenario in simulations. In this sec tion, we validate our simulation results quantitatively, confirming that NEWS effectively protects networks from overloading and maintains high performance for accepted requests. We further investigate system performance of the target server in details. In this experiment, we choose fast server SI as the target. We observe that requests do not overload SI during the flash crowd; in fact, their processing only consumes about 2-3% CPU time and about 60% memory on SI. However, the response traffic generated by SI congest network link between router R0 and R l. Our measurement shows 100% link utilization and about 60% packet drop rate. As a result, SI is kept busy with transm itting and retransm itting response traffic, and is not able to catch up with all incoming requests. As shown in Figure 4.19(a), SI can only process about 82 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 700 600 500 400 300 200 1 0 0 0 without NEWS w ith N E W S Log request rate 500 1000 1500 Time (second) (a ) O ffered req u est rate. 2000 < D -Q E 160 n c aj 140 3 o 120 tt> $ L L l 100 Z c o 80 0 ) C O w 60 0 ) 3 cr a > 40 T > a > *3 20 'E -o < 0 without NEWS w ith N E W S A / \ i / A / i i i / 1 r i .. A 1 i i i i ' i f . 0 500 1000 1500 Time (second) (b) A d m itte d req u est rate. 2000 Figure 4.20: Request rate observed on NEWS router in experiments. 80 requests per second, 32% less than the average incoming request rate during flash crowds (117 requests per second). Congestion in response network link and slow server processing (hence, large server backlog) greatly reduce end-user perceived performance: transmission rate of HBFs drops by half as shown in Figure 4.19(b). Also, about 22% connections timeout and fail due to packet loss. Failed connections resend SYN packets after timeout, and thus increase average offered request rate on NEWS router from 110 to 318 requests per second (Figure 4.20(a)). We enable NEWS on R0. W ith 64 second detection interval, NEWS detects flash crowd at about 1088 second, that is, 88 seconds after flash crowd starts. NEWS protects the target server and networks from overloading by regulating adm itted request rate down to 56 requests per second (Figure 4.20(b)). As less response traffic generated, packet loss rate on link between R0 and R l falls to less than 3%. NEWS also maintains high performance for adm itted requests during flash crowds: increasing transmission rate of HBFs from 133Kbps to 261Kbps (Figure 4.19(b)). As shown in Figure 4.21, this performance is comparable to static token-bucket based request rate limiter with manually configured token rate. Therefore, our experiment confirms that NEWS protects the server and networks from flash crowds effectively, and maintains high performance for adm itted requests. 83 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 350 & 300 .o * w 250 CD ^ 200 © c o £ 150 o V ) ■ | 1 0 0 a ) | 50 0 0 10 20 30 40 50 60 70 80 Rate Limit for Incoming Requests (number/second) Figure 4.21: Comparison of NEWS and static rate limiter in experiments. As a cost to this performance, NEWS discards about 49% of excessive requests. As observed in Figure 4.20(a), the offered request rate to RO increases by about 44% (from 318 to 459 requests per second) due to retransmissions as discussed in Section 4.6.2. R a te Hrniters NEWS *. * ............. ' w/o NEWS 4.7.3 Protecting Server from Flash Crowds We further evaluate NEWS performance in a server-limited scenario. This evaluation was not possible in simulation because network-level simulators (like ns) do not include detailed models of server CPU, memory, and disk performance. In this experiment, clients send web requests to slow target server S2. Since web requests in our experiments are only for static content, CPU usage on S2 is only about 15%. At the same time, link utilization between RO and R l is only 60%. We do not observe any packet loss. However, we find th at S2 uses up about 98% of its memory and starts swapping in order to serve the huge number of incoming requests. Swapping slows down S2 and builds up server backlog. Eventually, about 20% connections timeout due to long waiting time. As a result, end-users suffer from low web response rate even there is no packet drop in networks. 84 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ( 0 < D -O E 160 3 C 140 a > 3 2 120 C O $ L L l 100 Z c o 0 ) 80 5 to 60 < D 3 O ’ 2 40 -o 0 *s 20 E X> < 0 without NEWS w ith N E W S 500 A 1000 1500 2000 (a) A dm itted request rate. 500 450 400 350 300 250 200 150 1 0 0 without NEWS wifh NEW-b i V - A A :i ^ ■ W \ \ v? V \ a 7 \ . - i * v y \ V / . \ • • / \ " , i 500 1000 1500 2000 (b) Transm ission ra te of HBFs. Figure 4.22: NEWS performance in a server-limited scenario in experiments. Since NEWS detects flash crowds by monitoring response performance, it adapts to server- limited scenario automatically, detecting flash crowds withing about 80 seconds. By regulating incoming requests to 54 per second (as shown in Figure 4.22(a)), NEWS reduces server memory consumption to about 88%. As server stops swapping, it processes requests more promptly. Therefore, adm itted requests receive much higher performance. As depicted in Figure 4.22(b), transmission rate of HBFs jumps from 158 Kbps to 260 Kbps. Based on these results, we conclude that NEWS is an adaptive scheme, and can detect and prevent both network- and server-overloading during flash crowds. 4.7.4 Effect o f Different D etection Intervals As we explained in Section 4.3, NEWS detects flash crowds by periodically (with an interval of T seconds) checking degradation in response performance. The detection interval T is an im portant p ara m ete r affecting th e speed an d accuracy of flash crowd detectio n , an d th erefore th e overall NEWS performance. W ith testbed experiments, we first validate our findings in prior simulation study (Section 4.6.4). We further study the effect of different detection intervals on NEWS runtime overhead in next section. 85 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 400 g. 350 -Q » 300 li. m X 250 o 2 200 ( 0 c r 8 150 w w E 100 W * 50 128 256 16 32 64 detection interval (second) (a) Transm ission ra te of HBFs. “ ? 70 16 32 64 128 detection interval (second) 256 (b) A dm itted request rate. Figure 4.23: Different detection intervals affect NEWS performance (observed in experiments). Figure 4.23 shows the transmission rate of HBFs and admitted request rate under different Ts. NEWS shows best performance with detection interval at 64 or 128 seconds. We find that NEWS performance falls with either large or very small detection intervals. For example, with detection interval as 256 seconds, NEWS can’t adjust rate limit promptly as traffic changes. On the other hand, with very small intervals like 16 seconds, NEWS is so sensitive to traffic change that it triggers alarm before flash crowd happens (at 760 second). Then, it sets rate limit too low th at about 65% connections are discarded. These results confirm our findings in simulations. W ith detection interval larger than 16 seconds, NEWS always detects flash crowds slightly after one detection interval. Balancing detection delay and performance, we suggest to configure NEWS with detection interval as 64 seconds. In our experiments, NEWS does not trigger false alarms with detection intervals larger than 16 seconds. We believe this is because that requests generated from one client machine are highly correlated. We plan to deploy NEWS to real networks to further study this issue. 86 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.7.5 NEW S Overhead on R outers In this section, we first present an analysis of algorithmic performance of NEWS flash crowd detection algorithm. Then, we conduct testbed experiment to further evaluate NEWS CPU and memory consumption on a linux-based router. 4.7.5.1 A lgorithm ic Perform ance o f N E W S Flash Crowd D etection NEWS flash crowd detection consumes both CPU time and memory on routers. We analyze this overhead below. We further study NEWS runtime overhead with testbed experiment in Section 4.7.5. We first examine the overhead of NEWS flow state keeping. NEWS maintains stats for all active flows and updates flow response rate for every response packets. As shown in Section 4.5, NEWS uses the hash-based connection tracking function in iptables/netfilter [75]. Therefore, the average overhead of updating flow rate is 0 (1) (0 ( N ) in the worst case, N is the table size). On the other hand, NEWS requires to allocate memory for its hash table. We investigate this consumption in our testbed experiment (Section 4.7.5). Periodically (with an interval of T seconds), NEWS conducts flash crowd detection procedure as described in Section 4.3.2. NEWS selects the 10% fastest flows and computes their transmission rate. This task can be accomplished efficiently with a randomized selection algorithm [33], which has the average performance of (9(log N) (0 ( N ) in the worst case, N is the number of flows kept). In our current implementation, NEWS first sorts flows based on their rates with quick sort. Then, it picks the first 10% entries in the sorted list. This imposes computational overhead as 0 { N log N). Based on our analysis, NEWS imposes similar overhead to routers as a firewall keeping flow state. Therefore, we believe that NEWS is applicable to real networks to protect server and networks from flash crowds. 87 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Detection intervals before flash crowds after flash crowds offered request rate after flash crowds (request / s) 16 s 2-3.5% 5-6% 530 32 s 1.5-2% 3.5-5% 511 64 s 1-2% 2-4% 459 128 s and larger about 1% about 2% less than 400 Table 4.2: CPU time consumed by NEWS with different detection intervals (observed in experiments). 4.7.5.2 N E W S C P U and M em ory O verhead W ith testbed experiments, we are able to quantitatively investigate NEWS runtime overhead on routers, including CPU time and memory consumption. We report our findings below. Table 4.2 shows CPU usage of NEWS under different detection intervals, and the offered request rate after flash crowds. The offered request rate before the flash crowd is about 40 requests per second. When flash crowd happens, the offered request rate varies from 530 to 259 requests per second under with different NEWS detection intervals. In our experiments, we find that smaller detection intervals consumes relatively larger CPU time because of more frequent flash crowd detections. Overall, NEWS consumes less than 5% CPU time with a reasonable detection interval (for example, 64 seconds with offered request rate of about 459 per second). We also measure CPU usage when running NEWS on a slow machine (266MHz Pentium II CPU with 128MB RAM). NEWS consumes about 14% CPU time in average after flash crowds happen. Therefore, we conclude that NEWS imposes relatively small computational overhead to routers. We further study NEWS memory consumption below. NEWS needs memory to keep track of connection response rate. As shown in Section 4.5, we design this module based on connection-tracking support in netfilter, which uses hash table to keep sta te s for each connections. So, NEWS m em ory co n sum ption is determ in ed by the num ber of new connections (initiated by requests). Through our experiments, we observe that memory consumption remains about 3M bytes before the flash crowd happens. In this stage, the incoming request rate is about 40 per second. 88 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. When a flash crowd happens NEWS needs more memory as request rate increases. Depending on the rate-limit th at NEWS discovers, NEWS memory consumption varies from 10M to 12M bytes, corresponding to incoming request rate of 60 to 100 requests per second. In general, NEWS memory consumption is not sensitive to detection intervals. It is possible to reduce memory consumption for connection tracking by adjusting the value of connection timeout, th at is, the measurement window size. The default configuration of netfilter is 24 hours. We are able to reduce memory consumption after flash crowds to about 6M bytes by timing out connections every 64 seconds. We can further reduce NEWS memory consumption by random sampling incoming connections [39]. In real networks, routers usually have less memory compared to PCs used in our experiments. To have a reference on the overhead of flow state keeping on commercial routers, we substitute R0 with a Cisco 3620 router, which is widely used for mid-size networks. The router we use in this experiment has 100MHz R4700 CPU, 12MB processor memory and 8MB 10 memory. We use NetFlow [76] to keep states of individual unidirectional IP flows. W ith default flow cache size of 256K bytes and flow timeout value of 15 seconds, our Cisco router is able to track about active 4,000 flows (or 2,000 bi-directional connections), each in a 70 byte record. By repeating above experiments, we find that the average router CPU time is about 2-3% before flash crowd, and 7-8% after. The maximum CPU time reaches 10% during flash crowds. We do not observe any memory allocation failures for incoming flows. In another word, the default 256K byte flow cache is enough to keep states for all flows during the flash crowd in our experiments. Therefore, with the traffic condition in our experiments, per-flow state keeping only imposes small overhead even to real routers. 4.7.6 Bystander Traffic Protection In our simulation study (Section 4.6.5), we have shown that NEWS protects bystander FTP bulk traffic from flash crowds. We partially validate this result with experiments. More specifically, we 89 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. S cen ario s W eb L ate n cy (seconds) mean median b efo re flash crow d 0.22 0.18 d u rin g flash crow d 24.44 9.53 w ith N E W S 7.03 3.15 N E W S + H S I 0.42 0.32 T able 4.3: End-to-end latency of bystander web traffic in different experim ental scenarios. configure server S3 to constantly send 8K byte data chunks to client machine B l. Since NEWS measures aggregate request and response rate, it shows consistent performance in detecting and mitigating flash crowds. We measure goodput received by B l, and find it drops dramatically from 327 Kbps to 80Kbps as flash crowd traffic builds up. W ith NEWS deployed, B l gets a consistent goodput of 318Kbps. Therefore, NEWS can protect bystander bulk data transfer from flash crowds. We further evaluate the hot-spot identification (HSI) algorithm through experiment with by stander web traffic. In this case, B l sends web requests to server S3 based on H TTP log under light load (average request rate less than 20 requests per second). Since most web connections are short, we are interested in the end-to-end latency. We summarize experiment results in Table 4.3. We observe that the flash crowd hurts by stander web traffic greatly, increasing the median web latency by more than 50 times. By dis carding about 22% connections, NEWS (with original algorithms) reduces the median web latency for adm itted bystander requests by more than 3 times. W ith hot-spot identification technique, N EW S does n o t drop any b y sta n d er connections. As a resu lt, N EW S fu rth e r reduces th e m edian web latency for bystander web traffic by about 10 times. Therefore, we conclude that hot-spot identification algorithm is an effective technique to classify and protect bystander traffic from flash crowds. 90 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 4.8 Sum m ary In this chapter, we propose NEWS to protect servers and networks from persistent overloading caused by flash crowds. NEWS imposes aggregate-level control between requests and responses. We evaluate NEWS performance through both simulations and testbed experiments. Our results show th at NEWS quickly detects flash crowds. By discarding excessive requests, NEWS protects both the target server and networks from overloading. NEWS also maintains high performance for end-users, and protects bystander traffic from flash crowds. We also study the effect of different detection intervals on NEWS performance. Through this study, we illustrate our guidelines on designing adaptive system. More specifi cally, NEWS infers persistent overloading from end-user perceived performance. It detects flash crowds effectively by measuring changes in aggregated response rate of HBFs. As we have shown, this choice of traffic observation metris makes NEWS detection algorithm adaptive to both network- and server-limited scenarios. In term s of control logic, NEWS applies a score-board based scheme to approximate the relationship between request rate and response performance. We showed that NEWS automatically discovers the “right” limit to regulate incoming requests based on observed response performance. We further study the effect of detection intervals on NEWS performance, showing the trade-off between fast detection and low false alarm rate. We configure NEWS detection interval according to our guidelines. Since flash crowds are largely caused by human behaviors, we have relatively long response time. So, we focus on the accuracy of flash crowd detection at a cost of longer delay and use large detection interval (for example, 1 minute). Further, our guideline also suggests to use relative long interval (4-6 times of RTT) for TCP rate measurement. 9 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 5 D etec tin g E arly W orm P rop agation through P acket M atch in g In this chapter, we study an emerging threat to the Internet, th at is, worm attacks. We propose to apply high-level control algorithms to detect and quarantine worm propagation at the early stage. Since the outbreak of the Code-Red worm in July 2001 [2, 72], worm intrusion has become an increasingly severe threat to the Internet. Code-Red II [91], Nimda [68], Slammer [71], and SoBig [22] worms have all led to considerable cost to our society [73, 114]. Due to the fast spreading of worm infections, an automatic system is im portant to protect the Internet from worm attacks [73, 101]. 5.1 D esign in g A u to m a tic W orm D etec tio n and C ontain m ent S ystem In th is section, we identify th re e essential req u irem en ts for such a system . F irst, th is system must detect worm propagation at a very early stage to suppress the worm before it gets out of control [73, 101, 114]. For a router-based detection system, it needs to monitor and react to worm traffic within a small time interval (for example, in seconds) in order to quarantine worm 92 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. propagation quickly. Signature-based intrusion detection systems (IDS) can not respond at this speed due to the time-consuming worm packet content analysis. Anomaly-based IDS improve detection speed by monitoring traffic changes but usually have high false alarm rate due to the difficulty in profiling “normal” traffic condition. We believe that routers should apply simple but essential techniques for fast worm detection. These techniques should capture key characteristics of worm traffic but only consume small computational power on routers. Second, a worm defense system needs to create worm signatures without human interference in order to react and quarantine worm propagation rapidly. A signature identifies common char acteristics of a specific worm suitable for detection and suppression. For example, it could be the destination port number in worm packet headers, or substrings of worm packet payload. Although signatures based on packet data contents can unambiguously detect a worm, it is challenging for an worm detection system to generate such signatures automatically because of the large compu tational overhead. On the other hand, we will show th at simple signatures based on destination port numbers can effectively detect and contain worm traffic. Third, it is im portant to reduce the false alarm rate of worm detection because false positives potentially lead to denial-of-service to legitimate traffic. Therefore, we need to carefully consider the trade-off between fast detection and low false-alarm rate when designing an autom atic worm detection and quarantine system. In this chapter, we present a router-based worm detection and containment system called D E W P (D etecto r for E arly W orm P ro p a g atio n ). As observed below, D E W P d etec ts w orm in trusions, creates worm signatures, and contains worm propagation automatically, without hu man interference. We believe DEW P will be especially important against worms that propagate rapidly [101], such as the Slammer worm. 93 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5.1.1 Contributions DEW P has three major contributions. First, DEW P applies a novel worm detection algorithm by matching destination port numbers between incoming and outgoing connections. This idea is based on the following two observations on worm traffic. First, a worm usually exploits security vulnerabilities corresponding to specific network port numbers. Second, the nature of worms is th at an infected host will probe other vulnerable hosts exploiting the same vulnerability. There fore, routers seeing unusually high levels of bi-directional probing traffic with the same destination port number can infer a new worm has arisen. In addition, since matching destination port num bers consumes low computational power, DEW P is more applicable to real networks than systems based on packet content analysis such as the Early Bird System [96]. Second, we evaluate DEW P performance by simulating an outbreak of the Slammer worm, which is known for its extremely fast spreading (infected a total of about 75,000 hosts within 15 minutes). Our results show that DEW P detects worm propagation in about 4 seconds. W ith automatic destination port discovery and packet blocking, DEWP protects most hosts from infec tion: less than 1% of protected hosts are compromised by random-scanning worm, and about 9% of protected hosts are infected by local-scannning worm. We further investigate several im portant factors that affect DEW P performance including worm probing techniques, deployment coverage, and detection intervals. We also investigate the accuracy of the DEW P detection algorithm by examining its false detections. Due to the difficulty in generating representative background traffic in simulations, we choose to playback traces collected in real networks through the DEW P algorithm. As presented in Section 5.3, we find th at we can reduce false positives with address-counting and relatively long measurement window size. The final contribution of this work is that we introduce a new hybrid simulation model of worm propagation. This model allows detailed packet-level simulations within one particular network 94 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Incoming traffic DEWP Outgoing traffic d_port packet filter d ad d r port address matching checking worm d_port num worm detector F ig u re 5.1: D EW P architecture. while representing the rest Internet analytically. We present the detailed description of our model in Section 5.4. 5.2 W orm D etec tio n and C ontainm ent Internet worms spread very rapidly [73, 101, 64], For example, Code-Red II worm totally infected about 360,000 computers in 14 hours with a peak aggregate infection rate of 2,000 hosts per minute. The latest MyDoom worm compromised about 20,000 hosts in total within 2 hours after it was first discovered. In order to detect worm traffic promptly, routers need to automatically examine traffic changes and frequently conduct worm detections. As a result, when designing router-based algorithm, we need to choose simple but essential techniques so that worm detection does not interfere with routers’ normal operations. Intrusion detection also need finer operations: such as detailed worm behavior analysis and false alarm correction an d release. However, since such ta sk s are b o th co m p u tatio n -p o w er an d time consuming, it is not feasible to conduct them at the small timescale (in seconds) of autom atic worm detection. Rather, they should run at relatively larger time frame (in hours), or even with human interference. 95 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Figure 5.1 shows the two components th at make up DEWP: the worm detector and packet filter. DEW P detects worm intrusions with two steps: destination port matching and destina tion address counting. After it discovers a worm attack and the corresponding destination port number, DEW P deploys packet filter to block worm probing traffic. We present detailed design considerations in following sections. 5.2.1 D etecting W orm Propagation w ith D estination Port M atching DEW P applies a two-step detection algorithm, first port-matching, then address-counting. It identifies suspicious traffic by matching destination port numbers between incoming and outgoing connections. This simple technique actually captures important characteristics of worm probing traffic: worms usually exploit vulnerability in the same service, and so the same destination port number will be prominent in both incoming and outgoing traffic when a worm is spreading1. Also, since worms attem pt to infect as many vulnerable hosts as possible, compromised hosts both receive and send worm probing traffic. As a result, corresponding access routers observe probing traffic in both directions. DEW P uses port matching as a first line of filtering, since it can be done efficiently in routers, and since it can reduce computational overhead for per-port checking (that is, address counting). We examine the effectiveness of port matching in Section 5.5.6. While one might want to explicitly monitor ports with source and destination addresses (watching a particular host become infected and then this infection attacks others), we do not take this approach because a worm can easily spoof the source address of its probing packets when spreading. So, this check is less robust. Port-matching alone may identify some legitimate traffic as potential worm traffic. For exam ple, an access router of one ISP network may observe normal web requests toward both inside and 'E v e n for p o ly m o rp h ic w orm s th a t a tta c k m u ltip le v u ln er a b ilitie s, th e p o r ts u sed b y ea ch v u ln er a b ility w ill a p p ea r in traffic. 96 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. outside servers. So, port matching will capture web traffic as suspicious worm probings. To distin guish legitimate traffic from worm probings and avoid false positives, DEW P introduces a second step address counting. It counts distinct destination addresses of outgoing connections to suspi cious ports (N ). DEW P identifies worm traffic when observing large increase in N . The underline assumption is that worms probe many more unique addresses than normal traffic [104], and that worms result in a rapid increase in number of unique addresses seen. Through address-counting, DEW P is also able to capture worms that utilize popular network services such as sendmail (My- Doom and SoBig) and Web (Code-Red) since their traffic may be caught by port-matching as described in Section 5.5.6. 5.2.2 Containing W orm Propagation There are two approaches to quarantine worm propagation: address blacklisting and traffic filter ing. Address blacklisting maintains a list of addresses that are previously known of infection and blocks traffic from them. An alternative is traffic filtering, which discards packets with special patterns that have been discovered in worm traffic. DEWP uses traffic filtering, asking routers to drop packets with the automatically discovered destination port. We have chosen this alternative because it protects more vulnerable hosts than address blacklisting given the same worm attack and reaction time [73]. There are two aspects for worm containment: protecting internal hosts from both internal and external threats, and notifying other networks about the ongoing attack. Theoretically, it is always beneficial to deploy DEW P to additional ISPs if some other ISPs have already done so. T h is is because that, m u ltip le system s can co o rd in a te w orm d etectio n , an d sh a re th e w orm destination port number discovered. However, there are some difficulties in reality that prohibit such coordination including administrative issues and mutual trustiness among ISPs. So, we focus on deploying DEW P within one ISP in this work. 97 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. I S P I Figure 5.2: Worm containment in ISP I. In order to show the detailed procedure of worm containment within one ISP network, we present an example below. We assume th at routers can communicate with each other using schemes such as multicast. For an ISP I with DEW P deployed (shown in Figure 5.2), suppose router R detects the worm. It first deploys packet filter locally. R may also be able to locate infected hosts and block their network connections individually. Then, R notifies all other routers in ISP I about the ongoing worm propagation. We describe this process as two steps. First, R sends the destination port number of worm traffic to access routers of ISP I (labeled as 1 in Figure 5.2). Once these access routers deploy traffic filters, internal hosts are protected from outside probes. Also, outside hosts are no longer scanned by infected hosts in I. Next, routers (including access routers and R) that aware of worm propagation further alert their neighbors (labeled as 2 in Figure 5.2). This process continues recursively within I until all DEWP-aware routers deploy traffic filter. To protect hosts that are connected through other ISPs, access routers of I need to notify its peers about the worm attack (labeled as 3 in Figure 5.2). Upon receiving these notifications, routers in other ISPs repeat the three steps described above. 98 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In this work, we focus on early detection and fast containment of worm propagation Since DEW P captures and quarantines worm propagation by destination port number, it may block legitimate traffic to the same port. However, we believe th at this effect only exists when a worm is initially detected by DEW P (Section 5.2.1). Once we can further identify worms by finding signatures based on packet content (usually through time-consuming analysis by human beings), we should be able to resume service for legitimate traffic [114]. 5.3 D E W P S y stem D esign In this section, we present details on implementing DEW P in network simulator. We also assess its algorithmic performance below. 5.3.1 A lgorithm Im plem entation in Simulation DEWP observes packets that initiate new connections, which are defined based on different source and destination addresses and port number pairs. For TCP, DEW P simply checks SYN packets. DEW P needs to keep state for each non-TCP flow including source and destination addresses and port numbers in order to identify a new flow. NEWS maintains one list for each direction (port-list) to record the number of connections to different destination ports. A port list has 65,535 entries corresponding to all port numbers. Each entry is associated with a timer. If one port has not been accessed for certain time interval, D E W P resets th e corresponding list entry. B y th is m eans, we reduce false positives. N > N + (3 x var(N) (5.1) 99 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DEW P matches non-zero entries in both port-lists, and further monitors the outgoing des tination addresses of those connections. Every T seconds, DEW P checks the number of unique addresses observed within last time interval. It detects large increase (that is, worm probing traffic) with condition 5.1, where N is the number of unique addresses observed, N is its long term average, and var(N) measures its variation. We choose (3 = 4 as suggested in TC P RTO estimation. N = (1 - g ) N + gN (5.2) var(N) = (1 - h)var(N) + h(N - N) (5.3) Following the RTT estimation techniques in TC P [54], we compute N and var(N) using equations 5.2 and 5.3, where g = 0.125 and h = 0.25. As pointed out by Jacobson, a relatively large gain for variance estimation helps to quickly respond to changes in measurement. For worm containment, we do not consider the actual procedure to notify neighbor routers in our current work. Hence, we ignore the notification delay among routers. We will investigate this issue in our future work. 5.3.2 D E W P A lgorithm Overhead DEW P imposes both CPU and memory overhead on routers. We need to investigate this overhead in order to understand its applicability to real networks. Below, we present our analysis on algorithmic performance for port-matching (conducted upon each new connection) and address- counting (conducted every T seconds). We first examine the overhead of port-matching. DEW P keeps one port-list for each direction, which is implemented as an array with 64K entries. Since we only need to monitor if one port has been accessed, we only need one bit for each port (that is, one entry in port-list). So, two 100 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. port-lists need to allocate 8Kbyte memory (2 x 64K bits). In our current implementation, we use one byte for each port for simplicity, which leads to a memory overhead of 128Kbytes. The computational overhead of port-matching is mainly due to the process of identifying new connections. In order to do that, DEW P conducts the following per-packet operation. For TCP connections, DEW P updates port-list only when a SYN packet arrives. The overhead of this operation is 0 (1) with no extra memory required. On the other hand, DEW P needs to keep track of non-TCP flows. This can be effectively ac complished with hash table, for example, the connection tracking function in iptables/netfilter [75]. Thus, the average overhead of identifying a new non-TCP flow is also 0(1) (the worse case per formance is O(Nh), Nh, is the number of entries in the hash table). In the mean while, DEW P requires extra memory for hash table, for example, 256K bytes according to the default flow cache size for NetFlow [76]. For simplicity, we apply linked list instead of hash table to keep states for non-TCP flows in our current implementation. Correspondingly, the overhead for finding a new flow is 0 ( N nt), where Nnt is the number of flows being kept in the list. Accordingly, our implementation needs memory for Nnt flows. Since most Internet traffic is TCP, we expect less memory consumption for linked list than for hash table. Once a new connection is identified, the cost to update our array-based port-list is 0 (1) (just need to set corresponding bit to 1, for example). Then, DEWP checks corresponding entries in both port lists for possible matching, which also has the overhead of 0 (1) . In general, since it mainly involves 0 (1) operation, port-matching can be efficiently accomplished by existing stateful firewalls. Upon discovering a matched port, DEW P starts address-counting for it. This procedure requires to keep distinct destination addresses observed. We use a sorted-list in our implementa tion. The overhead to identify a distinct address and insert it to the list for an incoming packet 101 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. probing traffic the rest unprotected Internet the protected network Figure 5.3: The worm propagation model. is 0 (N alog(Na)), where Na is the list length. Also, DEW P requires 4 x Np x Nn byte mem ory to keep addresses for monitored ports (Np denotes the number of ports DEW P is currently monitoring). Periodically (with an interval of T seconds), DEW P checks condition 5.1. Since we associate counters with monitored ports to record the number of distinct addresses observed, the overhead of this comparison is 0 (N p). Based on our analysis above, DEW P imposes less (or similar) overhead to routers than a firewall keeping flow state (for example, iptables/netfilterwith connection-tracking). Therefore, we believe th at DEW P is applicable to real networks to detect worm propagation. 5.4 M od elin g W orm P rop agation In this work, we consider the scenario that one ISP network deploys DEW P to protect its vul nerable hosts. This imposes two requirements for the worm propagation model in simulations. First, it should allow detailed packet-level simulations to evaluate DEW P performance in the pro tected network. Second, it also needs to reflect a relatively realistic scenario where worms spread throughout the whole Internet with millions of vulnerable hosts. However, due to CPU and memory constraints, it is usually impossible to simulate millions of routers and hosts with packet-level details. Fortunately, since we are interested in deploying DEWP to one particular network, there is no need to model the whole Internet with such details. 102 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Instead, we use an analytical model, SIR (susceptible-infectious-removal) [52, 64, 73, 101] to represent the rest Internet without DEW P protection. In this abstract world, we only need to track several state variables such as the number of infected hosts. Figure 5.3 depicts the architecture of our hybrid model. The interaction of these two parts is through actual probing packet transmissions. Our model has three major differences from prior work [64]. First, instead of applying the analytical model to the whole Internet, we partition the Internet into two parts and only model the unprotected network analytically. Second, we model vulnerable and infected hosts in both parts of the Internet. Third, instead of using analytical model to compute traffic metrics for individual routers in detailed simulations, the protected network in our model interacts with the rest Internet through actual probing traffic. One limitation of our hybrid model is th at it only models a single path between the protected network and the rest Internet. In our future work, we hope to investigate the effect of m ulti-path and routing on the interaction of the two networks in our model and DEW P performance. 5.4.1 Formal R epresentation of the M odel Formally, we define our worm propagation model with equations 5.4 to 5.9. We describe model parameters in Table 5.1. Su(0) is the number of hosts in the rest Internet that are initially vulnerable. N is the address space of the Internet, which is used by worms to choose victims. The last equation shows a rough relationship between worm scan rate (C ) and infection parameter (/? )• dSu/dt = —fihjSu/Nu — Px, (5.4) dlu/dt = (dluSu /Nu — 7/ 1 / + Px, (5.5) dRu/dt — —"flu, (5.6) 1 0 3 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. P aram eter M ean ing the Su, 7j/, Ru number of vulnerable, infected, rest and removed hosts Internet Nu total number of hosts Qu the percentage of vulnerable hosts P infection parameter 7 removal parameter the N P total number of hosts protected network O p Pri Px percentage of vulnerable hosts number of probing packets received, sent within one time unit Px number of effective probing packets sent within one time unit N total number of hosts e overall percentage of vulnerable hosts c worm scanning rate T able 5.1: Param eters used in our worm propagation model. (5.7) Equations (5.4, 5.5, 5.6) come directly from the mathematic representation of discrete SIR model. It updates states (Ip, Su, R jj, and pr , px, Px) at each time unit. Px = Px x Su/Nu, (5.8) Pr = OCIuN d/ N , (5.9) We augment the original SIR model by including two new variables px and pr to represent probing traffic between the two networks. As shown in equations 5.8 and 5.9, the effective probing Px is proportional to px and the percentage of vulnerable hosts in the unprotected Internet. Further, pr represents the portion of aggregate probing traffic sent to the protected network. We describe probing traffic generation in Section 5.4.2. We also have the following equations to describe the relationship of different variables in the rest Internet: 104 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Su + Iu + Ru = Nu Su(0) = Nu x 9u N = 232 - 1 /3 = CSu(0)/N (5.10) We can use the mathematical expression of worm propagation model to estimate some impor tant properties. For example, in Section 5.4.4, we compute the time when the protected network receives the first probing packet (probing time), and when the first host in the protected network is compromised (infection time). We verify our simulation results with this analysis. 5.4.2 M odeling the Interaction betw een the Protected Network and the R est Internet One novel aspect of our model is that the protected network and the rest Internet interact through real probing traffic. W ith a certain scanning rate C, an infected host selects a target to send out probing packets. If the target is vulnerable, it is compromised and starts to probe other hosts. Probing packets have no effect on invulnerable or infected hosts. Worms have different options to send probing packets. For example, Code Red and Nimda first set up TCP connections with target hosts; while Slammer worm sends probing packets directly via U D P. W ith T C P connections, w orm s can send o u t large payload (for exam ple, 50K B in N im d a’s case). But, the scanning rate is limited by the end-to-end latency to victims, and therefore can not be very high. On the other hand, UDP-based worms usually have extremely large scan rate, but only one small probing packet (400 bytes in Slammer’s case). Their probing is not constrained 105 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. SIR model h v b rid m ode! 0.9 0.8 0 ) 0.7 C D C 0.6 0 ) C J < D Q _ c O 0.5 0.4 o a > 0.3 c 0.2 0.1 0 400 600 800 1000 200 time (second) Figure 5.4: Worm infections in both the protected network and the rest Internet. by latency, but limited by available network bandwidth. As more probing traffic pumped into networks, it not only affects cross traffic, but also interferes among themselves. We study two probing strategies in this work: random and local-preferred scanning. Worms (such as Code Red and Slammer) th at apply random scanning choose an IP address from the whole Internet address space randomly. This address may not even be used. Other worms (like Nimda) prefer to choose local neighbors. In this work, we model local-preference with the probability that an infected host probes its neighbors in the protected network. 5.4.3 Validating the worm propagation M odel We validate our model against the traditional SIR model through simulations. We simulate a scenario with 1000 vulnerably hosts, 500 of which are in the protected network and others are in the rest Internet. We configure the worm scanning rate as 4000 per second. We run the same simulation for 10 times and compute the mean of infection percentage. Since the confidence intervals (with 90% confidence level) are less than 2% of the mean infection percentage, we do not show them in the graph. We first record the infection percentage using SIR model. Then, we compute the overall percentage of infected hosts in our hybrid model. We show both curves in Figure 5.4. 106 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. We find th at the change of infection percentage in both models follow the same trend. If we interpret the infection percentage as the probability th at a vulnerable host will be compromised at time T, Figure 5.4 can be looked as the corresponding cumulative distribution function (CDF), th at is P(t < T). So, we can apply Kolmogorov-Smirnov goodness of fit test to formally determine if these two CDFs are significantly different. Following the methodology described in prior work [62], we first compute the maximum diver gence of these two curves (D value) and compare it to the critical value at 0.05 level significance c = 0.874 and n = 256). Since the D value (0.0515) is smaller than the critical value (0.054625), we accept the null hypothesis that the two curves are not significantly different from each other. 5.4.4 E xpected Tim e o f Probing and Infection Using the analytical representation of our worm propagation model, we can compute the time when the protected network receives the first probing packet (probing time), and the expected time when the first vulnerable host in the protected network is compromised (infection time). The probing time is determined by the ratio of hosts in both networks. The larger the protected network is, the earlier it receives probing packets. Since DEW P detects worm propagation after at least one host infected, the difference between probing time and the expected infection time is actually the lower bound of the expected detection delay. For simplicity, we do not consider removal function (5.6) below. Since there is no probing packet sent by the protected network before its first vulnerable host is compromised, we ignore function 5.8. So, we have a simplified model below: dSu ~(3IuSu t r I , , = s m ' (jll) dI'J W uSu ,r m ~ i i T = v t o p (,'-12) 107 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. CIjjNp Pr = Jj----, (5.13) The first probing packet is sent to the protected network when pr(t) > 1. From equation 5.12, we have: dlu/dt = p lu S u /S u i 0) = (3IU(SU( 0 ) ~ I U)/S U(0) (5.14) So, in our discrete-time model, we have: Iu(t) = (3Iu(t — l) (S , £/(0) — Iu(t — l) ) /5 r /( 0 ) + I u ( t - 1) = (l + P )Iu (t~ l) -P l* (t-1 ) /S u (0 ) (5.15) Combining equation 5.13 and 5.15, we get: Iu(t)CNp/N > 1 - 0 l l ( t - l ) / S u ( O ) ) > 1 (5.16) where Iy( 0) = 1. Therefore, we can solve the above in-equation to get probing time. Similarly, we have th e expression for expected infection tim e: - t 3 l l j { t - l ) / S u m > 1/Op (5.17) 108 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Parameter Value N a 200M eA 0.037% Sao 74,250 (3 0.069 n d 2550 Od 30% C 4000 / second Table 5.2: Parameters used to model Slammer worm. Given the configuration in our simulations (details in Section 5.5.1) we find that the probing time is 93.2 second, and the expected infection time is 98 second. The expected detection delay is about 4 seconds if we assume th at a detector is able to capture worm intrusion right after one host is compromised. As we will show in next section, the observed probing time in simulation is always 93.2 second, which is the same as our analytic result. We also find that the mean detection delay of DEW P is about 4.8 seconds (with full deployment and 1 second detection delay). This observation is also very close to the expected detection delay because DEW P detects worm traffic after at least one detection interval (1 second here). Therefore, our simulation results are quite consistent with the analysis presented in this section. 5.5 S y stem E valuation We implement DEW P in the network simulator (ns-2.26) [106] and evaluate its performance through simulations. In this work, we only consider scenarios of deploying DEW P to one ISP network. 5.5.1 M ethodology Since we are particularly interested in detection and quarantine of fast spreading worms, we evaluate DEW P performance with a simulated outbreak of the Slammer worm. We choose model parameters (summarized in Table 5.2) based on previous measurement study on the Slammer 109 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. lay er 3 43 lay er 0 layer 1 layer 2 access link to the rest Internet Figure 5.5: The the protected network topology of a 6-nary tree. worm [71]. For simplicity, we do not consider removal function (equation 5.6, representing hosts that die and are removed from service, or become patched and are “cured”) in our current work. To investigate the effect of different worm scanning techniques on DEW P performance, we consider both random and local probing strategies. For the protected network, we randomly select and mark 30% of end hosts as vulnerable (8o = 30%). Intuitively, the higher 0j>, the more likely that hosts in the protected network are compromised. In order to easily study the effect of deployment coverage on DEW P performance, we choose a topology of a 6-nary tree with 50 routers (shown in Figure 5.5). All connections have 100Mbps bandwidth and 50ms propagation delay. Each router connects 50 hosts with 100Mbps links (25ms propagation delay). Although easy to define, this 6-nary tree topology is artificial. To evaluate DEW P in a more complicated scenario, we investigate DEW P performance in a random-generated topology in Section 5.5.5. We deploy DEW P to routers in the protected network and quantify its performance with two metrics: detection delay and infection percentage. We define detection delay as the time interval from the first probing packet enters the protected network till DEWP detects worm propagation. The infection percentage represents the portion of vulnerable hosts in the protected network that are compromised. The coverage of DEWP-aware routers in the protected network (deployment) and the DEW P detection interval both affect performance. We vary these parameters to investigate their effects. 1 1 0 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 8 7 6 5 4 3 2 1 0 0 1 3 2 Deployment (layer) (a) M ean detection delay. 1 2 Deployment (layer) (b) M edian num ber of infected hosts. Figure 5.6: Detect and quarantine random-scanning worm with different layers of deployment. Ideally, DEW P will be deployed on all routers. But, in practice, we may only be able to deploy DEW P to some routers due to the difficulty of adding detection algorithm to existing router software and controlling router’s access policy. In Section 5.5.2 and 5.5.3, we incrementally deploy DEW P to routers on different layers (from 0 to 3 in Figure 5.5) and investigate how detection performance changes. We also study DEW P performance with different detection intervals in Section 5.5.4, and investigate false alarms of DEW P detection algorithm in Section 5.5.6, In all scenarios, we run simulations for 50 times and calculate statistics of detection delay and infection percentage in the protected network. Graphs that show mean values also indicate 90% confidence intervals; graphs that show medians instead depict 25% and 75% quartiles. 5.5.2 Effectiveness o f W orm D etection and Quarantine W e first, consider a ran d om -scanning w orm . In th is section, we p resent n u m b ers o f infected hosts instead of showing the small infection percentages (less than 1%). Our simulation results show th at DEW P detects worm traffic in 4.8 seconds when fully deployed with a 1 second detection interval. The median number of infected hosts is 1, which is the minimal requirement for DEWP 111 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. to detect worm probing traffic. Therefore, DEW P quickly detects the worm attack and effectively protects almost all vulnerable hosts from infection. We further investigate the effect of deployment on DEW P performance. As shown in Fig ure 5.6(a), DEW P always detects worm probing traffic in 4-5 seconds when deployed to different layers. So, the detection delay is not sensitive to deployment in the scenario of random-scanning worms. We also observe th at the median number of infected hosts remains 1 when DEW P deployment covers different layers (Figure 5.6(b)). This is because th at infected hosts in the protected network almost always probe outside networks rather than their neighbors: the possibility that an infected host in the protected network probes its neighbors is very small (about 2 out of 10 million probes). So, the number of infected hosts in the protected network is primarily determined by the number of probing packets received from outside. Therefore, DEW P is still able to protect almost all hosts from random-scanning worms even when only deployed on the access router. Based on our results, we conclude th at deployment does not have significant effect on DEW P performance to detect and quarantine random-scanning worms. Further, it is sufficient to deploy DEW P on the access router to protect vulnerable hosts from random-scanning worms. 5.5.3 Effect o f W orm Scanning Techniques Worms could apply more intelligent scanning techniques than just randomly choosing targets. For example, the Nimda worm chooses an address with the same first two octets with a probability of 50% and an address with the same first octet with a probability of 25%. Only 25% of the time, it picks a random address. As shown below, local-scanning worms spread rapidly within the protected network after the first host is compromised. This property imposes great challenge to worm detection and containment. In this section, we investigate its effect on DEW P perfor mance by simulating a local-scanning worm. W ith other parameters unchanged, we configure the probability that an infected host within the protected network probes its neighbors as 50%. 112 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. < D •Q > » T O T O O c o o T O T O Q c T O T O 5 8 7 6 4 3 2 0 2 3 0 1 i 0.4 Deployment (layer) (a) Mean detection delay. 1 2 Deployment (layer) (b) Median Infection Percentage. Figure 5.7: DEWP performance with detection interval as 1 second. We show DEW P performance in Figure 5.7. W ith full deployment and 1 second detection interval, we find th at DEW P detects worm probing traffic in 3.87 seconds. But almost all vul nerable hosts in the protected network are compromised before DEW P blocks worm traffic. Also, deployment does not have significant impact on either detection delay or infection percentage. Therefore, with 1 second detection interval, even though DEW P quickly detects worm traffic, it can not effectively quarantine local-scanning worm. To improve D EW P’s effectiveness in worm containment, we reduce the detection interval to 0.0625 second. In Section 5.5.4, we investigate how different detection intervals affect DEW P performance in details; however here we observe that this more frequent detection reduces vul nerability to local-scanning worms. Our simulation results show that DEW P detects worm probing traffic in 4.27 seconds with full deployment. We also find that deployment does not considerably affect DEW P detection delay. Given the similar detection delays observed in all scenarios, we conclude that DEW P is able to quickly detect worm attacks regardless probing techniques. On the other hand, even with full deployment, we still observe that about 10% of vulnerable hosts are compromised in the protected network by quarantine time. The infection percentage 113 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Q c ( 0 8 7 6 5 4 3 2 1 0 2 3 0 1 < D O ) n j c < D C J < D Q _ c o o 0.6 0 ) c 0.4 c e g T J a > 2 0.2 3 1 2 0 Deployment (layer) Deployment (layer) (a) M ean detection delay. (b) M edian Infection Percentage. F ig u re 5.8: Detect and quarantine local-scanning worm w ith different layers of deployment. increases as we reduce the number of layers with DEW P deployed. As an extreme case, when we only deploy DEW P on the access router, all vulnerable hosts in the protected network are compromised within 10 seconds. The difficulty in effectively quarantining local-scanning worms implies that a very small detec tion interval (for fast detection) and wide deployment is necessary to protect vulnerable hosts from infection. However, full deployment (which means to change software on all routers) is always difficult in reality. So, we propose the following strategy to alleviate this problem. We have shown that DEW P detection performance is not sensitive to deployment coverage. Therefore, we suggest to separate DEW P detector and traffic filter. We only need to apply DEW P detection algorithm on the access router. In the mean while, we attem pt to deploy filters to all ro u ters within one ISP. Since access control (including p er-p o rt blocking) is available even for low-end routers and management software is widely used to control routers within one ISP, it is relatively easy to instruct all routers to quarantine worm traffic based on the port number discovered by DEWP. So, we expect this separation helpful for effective host protection. 114 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Mean Detection Delay (seconds) 6 5 4 3 2 1 0 10 12 14 16 2 4 6 8 0 20 15 10 5 0 14 16 8 10 12 0 2 4 6 Timescale (seconds) Timescale (seconds) (a) M ean D etection delay. (b) Norm alized D etection delay. Figure 5.9: Detection interval affects DEWP performance. 14 12 10 8 6 4 2 0 8 10 12 14 16 0 2 4 6 Timescale (seconds) Figure 5.10: Median Number of infected hosts under different detection intervals. 115 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 8 0 w 0 0 0 0 0.2 0.4 0.6 0.8 Timescale (seconds) 0 0.2 0.4 0.6 0.8 Timescale (seconds) (a) M ean D etection delay. (b) M edian Infection Percentage. Figure 5.11: Detection interval affects DEWP performance. 5.5.4 Effect o f D etection Interval DEW P conducts address-counting with an interval of T seconds. Different detection intervals affects DEW P performance such as detection delay and infection percentage. We investigate its effect below. In this section, we fully deploy DEW P on all routers in the protected network. We first consider a random-scanning worm. As shown in Figures 5.9 and 5.10, both the detection delay and the number of infected hosts increases with detection intervals. Therefore, we believe th at an automatic system should detect worm traffic with small intervals. For local-scanning worms, small detection interval is even more critical. As shown in Fig ure 5.11, although we do not observe significant difference in detection delay (always about 4- 5 seconds), the infection percentage increases dramatically at larger intervals: from 9% (T = 0.0625second) to 100% (T — 1 second). We conclude that an automatic system needs to react to worm traffic within small time intervals in order to effectively quarantine worm propagation. 5.5.5 Effect of the Protected Network Topology So far, we have investigated D EW P’s effectiveness with a simple tree topology in the protected network. Although this setup has simplified our analysis, it does not reflect a real network 1 1 6 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. ,© — © A ccess link to the rest Internet ,©— © Figure 5.12: Randomly generated topology for the protected network. topology. To investigate the impact of network topology on DEW P performance, we evaluate DEW P performance with a randomly generated network (using GT-ITM [111, 112]) as shown in Figure 5.12. Although not necessarily “realistic”, this topology does contain more complicated patterns of connectivity than 6-nary tee, while still maintaining the hierarchical structure of an ISP network. In this study, link properties and the access connection of the protected network remain unchanged. We also fully deploy DEW P to all routers. We first investigate scenarios with random-scanning worms. Our results show that DEW P detects worm probing traffic within about 4 seconds with the detection interval of 1 second. The median number of infected hosts in the protected network is 1. So, we conclude that for these topologies, DEW P is not sensitive to the protected network topology when facing random-scanning worms. For local-scanning worms, the detection delay is still about 4 seconds with detection interval as 0.0625 second. But, we observe smaller mean infection percentage (about 5%) than our previous results. This is because some nodes in the random generated topology has larger out-degree and 117 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. deeper hierarchies, hence some probing packets are dropped due to congestion caused by more traffic aggregation. As a result, the mean infection percentage reduces. 5.5.6 U nderstanding False D etections False detection is a serious concern of autom atic worm detection systems. There are two kinds of false detections: false positives, when DEW P incorrectly identifies legitimate traffic as worms, and false negatives, when DEW P fails to identify worm traffic. Due to the large dynamics in Internet traffic (for example, traffic mix and packet arrival rate), it is difficult to generate representative background traffic as in real networks. So, we investigate DEW P false alarms (including false positives and negatives) by playing back network trace. Our trace contains two parts: background and worm probing traffic. For background traffic, we use packet trace collected by our colleague Kunchan Lan at USC/ISI. These traces were taken on August 21 2002, from a 100Mbps link connecting USC/ISI to the Internet. We choose three 1000 second trace sets recorded at different times (9am, 3pm and 7pm) to reflect changes in traffic mix. ISI has a B-class network providing services mainly for computer science researchers. It also hosts Web, FTP, sendmail servers and one b.root DNS server. Because we did not have traces that contain actual worms, we generate synthetic worm traffic using our worm propagation model and add this to our traces. We record packet trace (in simulation) at the access link (100Mbps) between the protected network and the rest Internet. During trace playback, we first start with background traffic. At the simulation time of 50 seconds, we inject worm traffic. R o le o f a d d r e s s - c o u n tin g In th e ex p erim en t, we do n o t observe any false positives w hen both stages of DEW P are used, it never classifies non-worm traffic as a worm. On the other hand, DEW P does discover (through port-matching) about 10 suspicious destination ports including 21 (FTP), 53 (DNS) and 80 (Web). 118 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. This finding has two implications. First, address-counting is im portant to reduce false pos itives. W ithout this procedure, DEW P will block popular legitimate traffic including Web and SMTP due to false detections. Second, port-matching identifies about 10 different ports out of the total of 542 active ones observed in our trace. So, DEW P only needs to count addresses to these 10 ports. Since address- counting runs with very small intervals (less than 1 second), port-matching saves the computa tional power on routers greatly. On the other hand, we find that the 10 ports that DEW P finds suspicious actually have about 24% of total packets and 85% of total connections (mainly due to DNS traffic). For the specific trace we study, port-matching does not save overhead on connection state-keeping than a stateful firewall due to the unusual large percentage of UDP traffic. However, as we have shown in Section 5.3.2, port-matching can be efficiently conducted without keeping states for TCP connections. So, the overhead of port-matching is small in general. D etectio n interval and m easurem ent w indow size In Section 5.5.4, we have shown that detection interval affects DEW P performance in terms of detection delay and vulnerable host protection. We further investigate the effect of detection interval on false detections. Another relevant param eter is the time period th at DEW P counts distinct addresses, that is, measurement window size. We find that DEW P is likely to trigger false alarms with small detection intervals and measure ment window sizes. For example, with 0.0625 second detection interval and same measurement window size, DEW P blocks Web, sendmail and DNS traffic. We believe this is because that connection arrival is more bursty within small time period. Therefore, the number of distinct addresses observed shows large variation. On the other hand, as we have observed in this study, small measurement interval is likely to cause false detection 119 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. In our analysis, we find that longer measurement interval reduces the chance of false detection. Based on our experience, we suggest that measurement window size should be configured as 6-8 times of detection interval. W o rm scan n in g ra te Another im portant issue affecting false negatives is worm scanning rate C. Low-rate worms probe less vulnerable hosts within the same time period. So, DEW P (es pecially address-counting) has difficulty distinguishing them from normal traffic. We investigate different scan rates from 4000 down to 500 per second. We observe th at even with C = 500, worm traffic still stands out compared to regular traffic: 728 distinct destination addresses within one second versus 11 of web traffic. When we further reduce C , DEW P is not able to detect worms with scanning rate lower than C = 2 because the number of distinct destination addresses only shows a small increase when compared to its long term average. So, low-speed worm is more difficult to detect by only observing traffic changes. In future, we hope to consider TCP-based worms where scan rate is constrained by the end-to- end latency between infected host and victims. Another im portant future work will be to examine traces th at include real worm propagation mixed with live Internet traffic. Unfortunately we were unable to find such a trace for this study. However, we believe that the methodology described above will be applicable to evaluations with real network traces. We also hope to prototype and deploy DEW P to a real network environment to further investigate the issues of false detection. 5.6 Sum m ary In this work, we proposed to apply high-level control algorithm (DEWP) to detect and quarantine th e p ro p ag a tio n of In te rn e t w orm s a t an early stage. DEW P identifies w orm traffic th ro u g h p o rt- matching and address-counting, we showed the effectiveness of DEW P through simulations. We also studied the effect of deployment coverage and detection intervals on DEW P performance. Finally, we investigated DEW P false detections through network traffic trace playback. 120 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. DEW P is based on our experience in designing adaptive control algorithms for previous two case studies. We apply the guideline to choose key metrics for traffic observation. More specifically, DEW P checks packet headers directly, detecting worm traffic through matched destination port numbers. As we have shown in Section 5.3, this choice is adaptive in detecting different worms. We further investigate the effect of detection interval on DEW P performance. We apply our guideline to configure a proper detection interval for DEWP. Since worm attacks are usually autom ated and spread very rapidly, we choose very small detection interval in this case study. As we have shown, fast detection (that is, a small detection interval) is im portant to protect vulnerable hosts from infection. On the other hand, false detection becomes an im portant concern for small intervals. To reduce false alarm rate, we suggest to use longer measurement window size to smooth bursty arrivals. Together with our previous two case studies, we present some qualitative guidelines in detection interval configuration in next Chapter. 1 2 1 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hapter 6 G u id elines to D esign Traffic C ontrol A lgorith m s In this section, we generalize two algorithm design guidelines through our case studies, namely, designing adaptive system and choosing proper detection interval. We explore each of them with details below. 6.1 D esig n in g A d a p tiv e S y stem Given the complexity of today’s Internet, it is im portant to build adaptive systems that work properly in different scenarios. Researchers have addressed the requirement of adaptivity for system design in prior work. Below, we take the widely-deployed transportation protocol, TCP, as an example to illustrate some design considerations and techniques. TCP is an adaptive protocol, adjusting its window size according to observed congestion condi tion in networks. The original TCP uses packet loss as a signal for network congestion. Techniques like fast retransmission (TCP Tahoe [54]), fast recovery (TCP Reno [5]) and selective acknowl edgment (TCP SACK [40]) enable senders to quickly react to different congestion conditions in netw orks from single to m u ltip le packet d ro p in one congestion w indow. TC P Vegas [20], on th e other hand, infers congestion from changes in round-trip-time (RTT). TCP also adapts to different round-trip-times (RTTs) through estimation. All these techniques have enabled TC P to contin uously serve as the main-stream reliable transmission mechanism with the constant evolving and 122 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. increasing heterogeneity in the Internet. Therefore, we also need to design adaptive traffic control algorithms, capable to adapt to different scenarios. More specifically, NEWS detects and mitigates flash crowds in both network- and server-overloading scenarios. DEW P captures worm probing traffic adaptively in a sense th at it does not check packet source address and data contents. In this work, we do not formulate a general analytical framework because of the difficulty to form a theoretical model for a complex large-scale system like the Internet. Further, there is little effort toward the analytical understand of the extreme cases that we studied. Instead, we present some new ideas in our case studies below. In NEWS, we propose to detect flash crowds by observing performance degradation in re sponses (Section 4.3). As we have shown, this technique adapts to both network- and server- limited scenarios. In our last case study, we present the original idea to detect worm intrusions through port matching. This technique is adaptive to different worm attacks in a sense that it does not need worm signature based on packet contents. It is also robust to different counter mea surements such as source address and port number spoofing (Section 5.2). W ith these techniques, our algorithms are adaptive, remaining effective in different scenarios. Based bn our experience, we further summarize two aspects for adaptive system design in traffic observation module and control logic. 6.1.1 Defining K ey M etrics for Traffic Observation An appropriate traffic observation is critical to make control decisions. In order to design an effective traffic observation module, we first need to identify some key metrics that we are most interested, that is, to accurately reflect what is causing problems? As we will show below, it can be difficult to choose “these metrics” to observe. So, based on our experience with the algorithm design of SFD, NEWS and DEWP, we suggest designers to consider the following two questions: 123 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 1. is our interest observable by examining packet contents (with simple statistics)? 2. can we infer our interest from end-user performance or server and network behaviors? For step one, we examine information in packet headers such as source and destination ad dresses, port numbers and packet size. We may also need to compute some simple statistics on these observations, like packet or bit rate. In step two, we quantify end-user performance with web latency or response rate. We also monitor server or network load and packet drop rate. This two-step guideline is our first attem pt to generalize the design of an adaptive traffic observation module. In each step of above procedure, designers may find different options. We suggest designers to test these options in different scenarios, and choose those adaptive ones. We illustrated this guideline through examples in our study. Due to the lack of application-level information on flow length, SFD cumulatively adds the size of each incoming packet of corresponding flows and use this sum to determine flow size (Section 3.3). In this case, step one, th at is a simple statistic on packet size of one flow, is sufficient for SFD to identify flow length. When designing DEWP, our interest is to capture worm probing traffic. As described in Section 5.2.1, worm traffic has some special patterns, that is, the same destination port number between incoming and outgoing connections (directly observable in packet headers) and large number of destination addresses in outgoing connections (by counting packets). So, we define our observation metrics accordingly. As shown in Section 5.3, there are other options such as payload checking and address matching. But, they are either computational consuming or less robust in real networks. Therefore, we identify the key observation metrics for worm detection from the first step: exam ining th e d estin a tio n ad d ress an d p o rt fields in packet headers. In our second case study, we need to identify flash crowd traffic, which is not directly observable because it is essentially web traffic. Instead, we monitor its impact on end-user performance. More specifically, we watch for degradations in web response performance (Section 4.2.2). We 124 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. believe th at previous approaches that choose to capture large request rate are not adequate because request rate is not necessarily correlated to persistent overloading at the target server or in networks (Section 4.2.2). Also, prior approaches are not adaptive to server- and network- limited scenarios. As a result, we apply step two to define key observation metrics for flash crowd detection, th at is, the performance of response traffic. In summary, carefully chosen metrics for traffic observation are im portant for the correctness, adaptivity, and robustness of traffic control algorithms. We show th at the observation metrics we have defined for our case studies are adaptive in different scenarios. To further assistant designers to systematically select the right observation metrics, we present the two-step procedure and illustrate each step with examples in our case studies. 6.1.2 D eveloping Self-Learning Control Logic In order to regulate underlying traffic adaptively, control logic module may need to take feedback from current traffic observation, and adjust its reaction decision accordingly. We recommend designers to first decide the relationship between traffic observation and regulation, asking are they directly or approximately related? We need to apply different techniques accordingly. In our first case study, SFD probabilistically promotes packets in long flows to the high priority queue to relieve penalty to long flows (Section 3.3.2). It determines the promotion probability by observing the number of bytes transferred. They are directly related in this case, and can be expressed as p — / b y t e s s e n t ■ That is, the less data a long flow has sent, the higher possibility its packets should be promoted. So, we use a simple equation-based control logic to reflect this relationship. O n th e o th e r h an d , as described in S ection 4.2.2, th e relatio n sh ip betw een en d-user perceived response performance and request rate is difficult to formulate with a simple equation: high request rate may lead to low response performance. So, we approximate this rough relationship with a self-learning technique. In our second case study, NEWS applies a score-board scheme to 125 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. discover a proper request rate limit based on traffic observation (Section 4.4). Therefore, some approximation techniques are needed to design control logic for indirect relationship between traffic observation and regulation. Control logic based on online feedback from traffic observation enables promote reaction to underlying traffic changes. But, it also imposes overhead to routers (for example, CPU and memory consumption). On the other hand, not all systems need to take online feedback. For example, SFD differentiates short and long flows with a static threshold and pre-compiled policies. So, SFD does not adapt to underlying traffic changes. However, it is also unnecessary for SFD to react to traffic changes within small time intervals such as minutes. This is because that the composition of Internet traffic is unlikely to have dramatic change at small timescales. Particularly, the statistics of flow size only shows slightly change over years [10]. Therefore, we decide to choose a static flow classification threshold offline and apply fixed policies. Further, we investigate the effect of this threshold on SFD performance in Section 3.4.3, and conclude th at SFD performs consistently with reasonable variance in this threshold of 15K bytes. DEW P also does not adjust its traffic regulation because that once a worm intrusion is de tected, the only choice is to block worm traffic (Section 5.2.2). The relief of traffic blocking usually needs human interference. In summary, a properly developed control logic is im portant for the adaptivity of traffic control algorithms. According to the relationship between traffic observation and regulation, we need to apply different techniques. More specifically, SFD applies a simple equation-based control logic to pro m o te th e p rio rity of packets in long flows. N E W S , on th e o th e r h an d , ap p ro x im ate s th e relationship between request rate and response performance through traffic observation. We also need to determine if online feedback is necessary according to characteristics of underlying traffic dynamics and our observation metrics. 126 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 6.2 C h oosin g P rop er D etec tio n Intervals Traffic observation module monitors changes in the metrics we are interested. Periodically (with a time interval of T seconds), it compares the current observation (over the last interval) with long term average, and triggers alarm upon large deviation. The outcome of above detection procedure directly affects our choice of reaction (for example, whether we should impose any traffic regulation or not), and therefore overall system performance. We represent conditions for flash crowd detection in 4.1 and 4.3, and worm detection in 5.1. SFD is a special case, which continuously classifies short and long flows instead of periodically detection. So, we focus on the choose of detection intervals for NEWS and DEW P below. Detection interval T is an im portant param eter in change detection. It reflects the trade-off between fast detection and low false alarm rate. As we have shown in NEWS implementation in Section 4.5, detection interval also affects CPU and memory usage on routers. We have investi gated the effect of different detection intervals through our case studies (Section 4.6.4, 4.7.4, 4.7.5, 5.5.6). We suggest different choices of detection intervals for NEWS and DEW P in the scenarios we considered. Based on our experience, we summarize some design suggestions below. We adm it finding an ideal detection interval in general is difficult due to the underling dynamics in networks and systems. The “optimal” value largely depends on underlying traffic mix and the observation metrics we are interested. So, we recommend designers to briefly survey underlying traffic characteristics, and consider the following three aspects for detection interval configuration: 1. Application requirement. Different problems require different speed of reaction. It also affects our design decision over th e trade-off betw een fast d etec tio n an d low false alarm rate. For example, flash crowds are largely caused by human behaviors, and allow relatively long response time. So, we focus on reliable detection, scarifying detection delay when designing NEWS (Section 4.3). 127 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. On the other hand, worm attacks are usually autom ated and spread very rapidly. So, worm detection and quarantine needs to be extremely fast. Therefore, we emphasize on reducing detection delay with a possible risk of false detection (Section 5.2). We further investigate the effect of DEW P configurations and worm traffic characteristics on false alarms (Section 5.5.6). 2. Separating detection and measurement intervals. We have shown that false alarm is a big concern when taking traffic measurement at small intervals (Section 4.6.4 and 5.5.6). To reduce false alarm rate, we need to measure traffic change within a large window. On the other hand, our algorithms also need to react to underlying traffic change promptly (for worm detection, for example). So, we suggest separating detection interval and measurement window. Based on our experience with DEW P (Section 5.5.6), the measurement window size should be larger than detection interval. This is because DEW P needs to detect worm probing traffic with very small intervals (for example, less than 1 second), and we observe false alarms at this timescale. We further give some recommendations on selecting an appropriate measurement window size below. 3. Traffic measurement. We suggest to use large window size for TCP rate measurement because TCP shows large rate variation at small timescales [43]. As presented in Sec tion 4.3.3.1, we also have similar findings when designing NEWS. So, we measure flow rate with a large window to detect degradation in web response rate. As derived in Section 4.3.3.1, we suggest this interval greater than of 4ATT. On the other hand, we find th at smaller detection intervals are needed to accurately capture changes in aggregated traffic because its variance are likely to be smoothed out over long periods. For example, the background traffic trace we used to study DEW P false detection is collected from one access router for USC/ISI (Section 5.5.6). ft is mixed by Web, FTP, DNS, 128 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. and mail traffic, and dominant, by UDP traffic (DNS). So, we configure small measurement window size for DEWP. On the contrary, we only study web traffic in NEWS case due to the difficulty to get router traffic trace for flash crowds (Section 4.6.1). As a result, NEWS monitors changes in response rate with longer periods. Due to the difficulty to obtain real network trace during flash crowds and worm attacks, we are only able to provide some qualitative guidelines for detection interval and measurement window configuration. Together with other research effort, we hope to better understand this im portant issues in future. 6.2.1 Summary In this chapter, we present two guidelines to develop traffic control algorithms, namely adaptive system design and choosing proper detection interval. Based on our experience in three case studies, we show how to define key observation metrics and design adaptive reaction scheme. We also give some suggestions on choosing appropriate detection intervals for our algorithms. We illustrate each guideline with examples in this research. Given the complexity of today’s Internet, there are many im portant issues that we should consider when designing traffic control algorithms to improve network robustness. Together with other research efforts, we hope to better understand guidelines for algorithm design. 129 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. C hap ter 7 F uture W ork and C onclusion In this chapter, we conclude our work on improving network robustness with aggregate-level traffic control algorithms. We briefly review the theme and contributions of this dissertation. We also present some future work in this chapter. 7.1 T h esis Sum m ary Our thesis statem ent is that we can improve network robustness by carefully designing and apply ing aggregate-level traffic control algorithms. We tested this hypothesis with three case studies, namely improving web latency by differentiating short flows, mitigating flash crowds through observation on response performance, and detecting Internet worm attack with port-matching. We systematically chose these three case studies to address network robustness issues under severe congestion, traffic anomaly, and malicious attacks. In each case study, we contributed different aggregate-level traffic control algorithms to improve network robustness, namely SFD, NEWS and DEWP. We also generalized algorithm design guidelines based on our experience. We briefly summarize our contributions below. D ifferentiating short flows: We proposed to reduce response latency for short flows by giving them preferential treatm ent. More specifically, routers drop more packets in long flows (OUT 130 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. packets) upon congestion. Through simulations, we showed the effectiveness of the SFD algorithm and its protection for short flows under severe network congestion. M itigatin g flash crowd traffic: We proposed NEWS to protect the target server and net works from persistent overloading during flash crowds and maintain high performance for end- users. NEWS detects flash crowds from performance degradation in responses and mitigates flash crowds by adm itting incoming requests adaptively. We showed NEWS performance through both simulations and testbed experiments. We further investigated the impact of detection intervals on NEWS performance, showing it affects both detection delay and false alarm rate. C ontaining Internet w orm propagation: The most severe case we study in this dissertation is the Internet worm attack. We focused on fast-spreading worms, and developed an aggregate- level traffic control algorithm, DEWP, to automatically detect and quarantine Internet worm propagation. DEW P detects worm probing traffic by matching destination port numbers between incoming and outgoing connections. Our simulation results showed that DEW P quickly detects worm attacks and effectively protects vulnerable hosts from infection. We also investigated false detections with network trace playback. Through our timescale study, we further found that an automatic worm detection system need to monitor and react to traffic changes during a worm outbreak within very small time frame. G uidelines for algorithm design: Based on our experience in the above case studies, we explored some design guidelines for aggregate-level traffic control algorithms. More specifically, we presented our suggestions on adaptive system design and choosing proper detection interval. We illustrated each guideline with examples in this dissertation. As a summary, the contributions of this dissertation are both the algorithms proposed in our case studies and the generalized design guidelines. We hope our work will contribute to 131 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. better understanding the design of aggregate-level traffic control algorithms to improve network robustness. 7.2 F uture W ork In this section, we present some potential future research directions of this dissertation. More specifically, we describe some interesting issues to investigate for the algorithms we proposed. In vestigatin g th e effect o f SFD on other ty p es of traffic: We have shown the effectiveness of SFD in protecting short web traffic in Section 3.4.2. An interesting future direction is to study the effect of SFD on other types of interactive traffic such as telnet and ssh. Another direction is to examine the interaction of SFD with other diffserv policed traffic. E valuating N E W S perform ance in a server-C P U lim ited scenario: We have shown the effectiveness of NEWS in both network- and server-memory limited scenarios (Section 4.6 and 4.7). As a potential direction for our future work, we can further evaluate NEWS performance in a scenario where server CPU is overloaded with dynamic workload. For example, clients send database queries via CGI interface on the target server. This experiment will further test the adaptivity of NEWS algorithm. M odeling th e effect o f d etection interval on N E W S perform ance: We have demon strated the impact of detection interval on NEWS performance through simulations and testbed experiments in Section 4.6.4 and 4.7.4. It is an interesting direction to model NEWS overloading protection during flash crowds. W ith this analytic effort, we should be able to derive bounds to guide our choice of appropriate detection intervals for NEWS. A pplying N E W S techniques for D D oS detection: DDoS attack [93, 95, 84] is another class of problem threatening network robustness. We can potentially extend the flash crowd detection 132 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. techniques to detect DDoS attacks toward a web server. More specifically, we can design a system to monitor end-user perceived performance and infer ongoing DDoS attacks from performance degradation. Investigating schem es to reduce th e overhead o f connection state-keeping: Currently, NEWS maintains states for each individual connection. A potential improvement of NEWS is to reduce this overhead and only keep track of high-bandwidth connections. One possible approach is to adopt schemes proposed by Estan et. al. [39]. R educing D E W P false d etection s We have presented our investigation of DEW P false de tection in Section 5.5.6. In future, we need to conduct further study to understand the effect of DEW P parameters on its false detection. One scheme th at is possible to improve the accuracy of DEW P detection is to cache the destination addresses of outgoing connections rather than just counting them as in our current algorithm. M odeling m ore com plicated scenarios: As a possible future direction to improve our hybrid worm propagation model (Section 5.4), we would like to investigate more complicated scenarios such as multi-homing and asymmetric routing. We also want to consider removal function in our future work. Investigating T C P -based worm attacks: Currently we only investigate worms that send probing traffic via UDP. We are interested in extending our work to examine scenarios of TCP- based worms. This extension will allow us to investigate the difference between TCP- and UDP- based worms and its impact on worm detection algorithms. E xam ining th e interference am ong worm traffic: Researchers have studied the effect of malicious traffic on legitimate network services such as DNS [24]. An interesting point for our future work is to investigate the interference among worm traffic in our future work. 133 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Im plem enting D E W P : A potential future work is to implement DEW P and evaluate its performance in real networks. We also hope th at implementation and deployment in real networks will help us to better understand im portant issues such as false detections. A pplying m ore sop histicated change d etection algorithm s for N E W S and D E W P : In our current design of NEWS and DEWP, we used relatively simple algorithms to detect abrupt traffic changes (in Section 4.3 and 5.3). As a future direction, we could apply more sophisticated algorithms from change detection theory [14] for potentially faster detection. Algorithms such as CUSUM [107] also provides theoretical insight on the trade-off between detection delay and false alarm rate. O ptim izing other change-detection-based algorithm s w ith th e guidelines we general ized: Researchers have proposed various schemes to detect traffic anomalies, such as TCP SYN attack [107]. These schemes are often based on periodic change detection. So, a study on the effect of detection interval is im portant to optimize the performance of these algorithms. We are interested in applying our guidelines generalized in Section 6 to improve the performance of these schemes. 7.3 C onclusion In this dissertation, we propose aggregate-level traffic control algorithms to improve network ro bustness. More specifically, we study end-user perceived performance and infrastructure stability with three case studies, namely, short flow differentiating (SFD) algorithm, network early warning system (NEWS), and detector for early worm propagation (DEWP). We generalize design principles based on our experience. Together with other research efforts, this work will build up the framework for designing future traffic control mechanisms to improve network robustness. 134 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. R eferen ce List [1] Intrusion detection systems, honeypots and incident response, http://w w w .honeypots.net/. [2] Code-Red: a case study on the spread and victims of an Internet worm. In Proceedings of the AC M SIGCOM M Internet Measurement Workshop, pages 273-284, Marseille, France, November 2002. ACM. http://w w w .caida.org/outreach/papers/2002/ codered / codered.pdf. [3] Stephen Adler. The slashdot effect, an analysis of three internet publications. February 1999. [4] M. Allman, S. Floyd, and C. Partridge. Increasing T C P ’s initial window. RFC 2414, Internet Request For Comments, September 1998. [5] M. Allman, V. Paxson, and W. Stevens. TC P congestion control. RFC 2581, Internet Request For Comments, April 1999. [6] M artin Arlitt and Tai Jin. A workload characterization study of the 1998 world cup web site. IEEE Network, Special Issue on Web Performance, 14(3):30-37, May 2000. [7] Hari Balakrishnan, Venkata Padm anabhan, Srini Seshan, Mark Stemm, and Randy H. Katz. TCP behavior of a busy Internet server: Analysis and improvements. In Proceedings of the IEEE Infocom, pages 252-262, San Francisco, CA, USA, March 1998. IEEE. [8] Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan. An integrated congestion management architecture for internet hosts. In Proceedings of the AC M SIGCOMM, pages 175-187, Cambridge, MA, USA, September 1999. ACM. [9] N. Bansal and M. Harchol-Balter. Analysis of SRPT scheduling: Investigating unfairness. In Proceedings of the ACM SIGM ETRICS, pages 279 -290, Cambridge, MA, USA, June 2001. ACM. [10] P. Barford, A. Bestavros, A. Bradley, and M. E. Crovella. Changes in web client access patterns: Characteristics and caching implications. World-Wide Web Journal, 2:15-28, 1999. [11] P. Barford and M. E. Crovella. Measuring web performance in the wide area. ACM Per formance Evaluation Review, 27(2):37-48, August 1999. [12] P. Barford and D. Plonka. Characteristics of network traffic flow anomalies. In Proceedings of the ACM SIGCOMM Internet Measurement Wor'kshop, pages 2-13, San Francisco, CA, November 2001. ACM. [13] Paul Barford and Mark Crovella. Generating representative web workloads for network and server performance evaluation. In Proceedings of the ACM SIGM ETRICS, pages 151 160, Madison, WI, USA, June 1998. ACM. 135 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [14] Michele Basseville and Igor V. Nikiforov. Detection of Abrupt Changes - Theory and A p plication. Prentice-Hall, Englewood Cliffs, NJ, first edition edition, April 1993. [15] V. Berk, G. Bakos, and R. Morris. Designing a framework for active worm detection on global networks. In Proceedings of the IEEE International Workshop on Information As surance, pages 13-23, Darm stadt, Germany, March 2003. IEEE. [16] T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext transfer protocol—H TTP/1.0. RFC 1945, Internet Request For Comments, May 1996. ftp://ftp.isi.edu/in-notes/rfcl945.txt. [17] N. Bhatti, A. Bouch, and A. Kuchinsky. Integrating user-perceived quality into web server design. In Proceedings of the International World Wide Web Conference, pages 1-16, Am sterdam, Holland, May 2000. [18] S. Blake, D. Black, M. Carlson, E. Davies, and W. Weiss Z. Wang. An architecture for differentiated service. RFC 2475, Internet Request For Comments, December 1998. [19] Rudolf B Blazek, Hongjoong Kim, Boris Rozovskii, and Alexander Tartakovsky. A novel ap proach to detection of denial-of-service attacks via adaptive sequential and batch-sequential change-point detection methods. In Proceedings of the IEEE Systems, Man, and Cybernetics Information Assurance Workshop, West Point, NY, USA, June 2001. IEEE. [20] L. Brakmo. TCP Vegas: End to end congestion avoidance on a global internet. IEEE Journal on Selected Areas in Communications, 13(8): 1465-1480, October 1995. [21] Lee Breslau, Edward W. Knightly, Scott Shenker, Ion Stoica, and Hui Zhang. Endpoint admission control: Architectural issues and performance. In Proceedings of the A C M SIG COMM, pages 57-69, Stockholm, Sweden, August 2000. [22] CERT. W 32/Sobig.F worm. Incident note, CERT-Coordination Center, August 2003. IN- 2003-03. [23] C. Cetinkaya and E. Knightly. Egress admission control. In Proceedings of the IEEE Info- com, pages 1471-1480, Tel-Aviv, Israel, March 2000. IEEE. [24] Kun chan Lan, Alefiya Hussain, and Debojyoti D utta. The effect of malicious traffic on the network. In Proceedings of the Passive and Active Measurement Workshop, San Diego, CA, USA, April 2003. IEEE. [25] H. Chen and P. M ohapatra. Session-based overload control in qos-aware web servers. In Proceedings of the IEEE Infocom, New York, NY, USA, June 2002. IEEE. [26] X. Chen and J. Heidemann. Flash crowd mitigation via an adaptive admission control based on application-level measurement. Technical Report ISI-TR-557, USC/Information Sciences Institute, May 2002. under submission. [27] X. Chen and J. Heidemann. Experimental evaluation of an adaptive flash crowd protec tion system. Technical Report ISI-TR-573, USC/Information Sciences Institute, July 2003. under submission. [28] X. Chen and J. Heidemann. Preferential treatm ent for short flows to reduce web latency. Computer Networks, 41(6):779-794, April 2003. [29] M. Christiansen, K. Jeffay, D. O tt, and F.D. Smith. Tuning RED for web traffic. In Proceedings of the AC M SIGCOMM, pages 139-150, Stockholm, Sweden, August 2000. 136 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [30] Brent N. Chun, Jason Lee, and Hakim Weatherspoon. Netbait: a distributed worm detec tion service, http://netbait.planet-lab.org/, February 2003. [31] D. Clark and W. Fang. Explicit allocation of best effort packet delivery service. A C M /IE E E Transactions on Networking, 6(4):362-373, August 1998. [32] David D. Clark, Scott Shenker, and Lixia Zhang. Supporting real-time applications in an integrated services packet network: Architecture and mechanism. In Proceedings of the AC M SIGCOMM, pages 14-26, Baltimore, MD, USA, August 1992. ACM. cite- seer.nj .nec.com/clark92supporting.html. [33] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein. Introduction to Algorithms. The MIT Press, Cambridge, MA, second edition edition, 2001. [34] M. E. Crovella, R. Frangioso, and M. Harchol-Balter. Connection scheduling in web servers. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Boulder, CO, USA, October 1999. [35] Mark E. Crovella and Azer Bestavros. Self-similarity in world wide web traffic: evidence and possible causes. In Proceedings of the AC M SIG M ETRICS, pages 160-169, Philadelphia, Pennsylvania, May 1996. ACM. [36] A. Demers, S. Keshav, and S. Shenker. Analysis and simulation of a fair-queueing algorithm. In Proceedings of the AC M SIGCOMM, pages 1-12, Austin, TX, USA, September 1989. ACM. [37] Lars Eggert and John Heidemann. Application-level differentiated services for web servers. World-Wide Web Journal, 2(3):133-142, August 1999. [38] Lars Eggert, John Heidemann, and Joe Touch. Effects of ensemble-TCP. ACM Computer Communication Review, 30(l):15-29, January 2000. [39] C. Estan and G. Varghese. New directions in traffic measurement and accounting. In Proceedings of the AC M SIGCOMM, pages 323-336, Pittsburgh, PV, USA, August 2002. ACM. [40] K. Fall and S. Floyd. Simulation-based comparisons of Tahoe, Reno, and SACK TCP. ACM Computer Communication Review, 26(3):5-21, July 1996. [41] W. Fang, N. Seddigh, and B. Nandy. A time sliding window three colour marker (TSWTCM). RFC 2859, Internet Request For Comments, June 2000. [42] Anja Feldmann, Anna C. Gilbert, Polly Huang, and Walter Willinger. Dynamics of IP traffic: A study of the role of variability and the impact of control. In Proceedings of the ACM SIGCOMM, pages 301-313, Cambridge, MA, USA, August 1999. ACM. [43] S. Floyd, M. Handley, and J. Padhye. A comparison of equation-based and airnd congestion control. 2000. [44] S. Floyd and V. Jacobson. Random early detection gateways for congestion avoidance. A C M /IE E E Transactions on Networking, 1(4):397-413, August 1993. [45] Sally Floyd and Kevin Fall. Promoting the use of end-to-end congestion control in the Internet. A C M /IE E E Transactions on Networking, 7(4):458-473, August 1999. [46] Sally Floyd and Vern Paxson. Difficulties in simulating the Internet. A C M /IE E E Transac tions on Networking, 9(4):392-403, August 2001. 137 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [47] Cooperative Association for Internet D ata Analysis. Netramet web session performance project, http://w w w .caida.org/analysis/w orkload/netram et/w eb/. [48] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext transfer protocol—H TTP/1.1. RFC 2616, Internet Request For Comments, June 1999. http://www.w3.org/Protocols/rfc2616/rfc2616.htm l. [49] R.J. Gibbens, F. P. Kelly, and P.B. Key. A decision-theoretic approach to call admission control in ATM networks. IEEE Journal on Selected Areas in Communications, 13(6):30 -37, August 1995. [50] T. M. Gil and M. Poletto. MULTOPS: A data-structure for bandwidth attack detection. In Proceedings of the USENIX Security Symposium, pages 23-38, Washington, D.C., USA, August 2001. USENIX. [51] Liang Guo and Ibrahim M atta. The war between mice and elephants. In Proceedings of the IEEE International Conference on Network Protocols, Riverside, CA, USA, November 2001. IEEE. [52] H. W. Hethcote. The mathematics of infectious diseases. SIA M Review, 42(4):599-653, October 2000. [53] P. Hurley, M. Kara, L. Boudec, and P. Thiran. ABE: Providing a low-delay service within best-effort. IEEE Network Magazine, 15(3):60-69, May 2001. [54] Van Jacobson. Congestion avoidance and control. In Proceedings of the SIG C 0M M ’ 88, pages 314-329, Stanford, California, August 1988. ACM. [55] S. Jamin, P.B. Danzig, S. Shenker, and L. Zhang. Measurement-based admission control algorithms for controlled-load service. In Proceedings of the ACM SIGCOMM, pages 2-13, Cambridge, MA, October 1995. ACM. [56] H. Jamjoom and K. G. Shin. Persistent dropping: An efficient control of traffic aggregates. In Proceedings of the ACM SIGCOMM, pages 287-298, Karlsruhe, Germany, August 2003. ACM. [57] R. Johari and D. Tan. End-to-end congestion control for the internet: Delays and stability. A C M /IE E E Transactions on Networking, 9(6):818-832, December 2001. [58] J. Jung, B. Krishnamurthy, and M. Rabinovich. Flash crowds and denial of service a t tacks: Characterization and implications for CDNs and web sites. In Proceedings of the International World Wide Web Conference, pages 252-262, Hawaii, USA, May 2002. IEEE. [59] F. Kelly, A. Maulloo, and D. Tan. Rate control in communication networks: shadow prices, proportional fairness and stability. Journal of the Operational Research Society, 49(3) :237- 252, March 1998. [60] M. Kim and B. Noble. Mobile network estimation. In Proceedings of the A C M /IE E E In ternational Conference on Mobile Computing and Networking, pages 298-309, Rome, Italy, July 2001. ACM. [61] Lawrence-Berkeley Labs. The Internet Traffic Archive, 1992. http://ita.ee.lbl.gov/. [62] Kunchan Lan and John Heidemann. Rapid model parameterization from traffic measure ment. ACM Transactions on Modeling and Computer Simulation, 12(3):201-229, July 2002. 138 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [63] Chuck Lever, Marius Aamodt Eriksen, and Stephen P. Molloy. An analysis of the TUX web server. Technical report, Center for Information Technology Integration, University of Michigan, November 2000. [64] M. Liljenstam, Y. Yuan, BJ Premore, and David Nicol. A mixed abstraction level simulation model of large-scale internet worm infestations. In Proceedings of the International Sympo sium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, pages 109-116, Fort Worth, TX, USA, October 2002. IEEE. [65] Dong Lin and Robert Morris. Dynamics of random early detection. In Proceedings of the AC M SIGCOMM, pages 127-137, Cannes, France, September 1997. ACM. [66] S. H. Low and D. E. Lapsley. Optimization flow control — I: basic algorithm and conver gence. A C M /IE E E Transactions on Networking, 7(6):861-874, December 1999. [67] C. Lu, T. F. Abdelzaher, J. A. Stankovic, and S. H. Son. A feedback control approach for guaranteeing relative delays in web servers. In Proceedings of the IEEE Real-Time Technology and Applications Symposium, Taipei, Taiwan, June 2001. IEEE. [68] A. Mackie, J. Roculan, R. Russell, and M. V. Velzen. Nimda worm analysis. Incident anal ysis report, Security Focus, September 2001. http://aris.securityfocus.com /alerts/nim da/ 010919-Analysis- N imda .pdf. [69] R. Mahajan, S. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and S. Shenker. Controlling high bandwidth aggregates in the network. Technical report, ICSI, July 2001. [70] R. M ahajan and S. Floyd. Controlling high bandwidth flows at the congested router. In Pro ceedings of the IEE E International Conference on Network Protocols, pages 1-12, Riverside, CA, USA, November 2001. IEEE. [71] D. Moore, V. Paxson, S. Savage, C. Shannon, S. Stamford, and N. Weaver. The spread of the Sapphire/Slammer worm. Technical report, CAIDA, the Cooperative Association for Internet D ata Analysis, January 2003. http://w w w .caida.org/outreach/papers/2003/ sapphire/. [72] D. Moore and C. Shannon. The spread of the code-red worm (CRv2). Techni cal report, CAIDA, the Cooperative Association for Internet D ata Analysis, 2002. h ttp :// www.caida.org/analysis/security/code-red/coderedv2_analysis.xml. [73] David Moore, Colleen Shannon, Geoffrey M. Voelker, and Stefan Savage. Inter net quarantine: Requirements for containing self-propagating code. In Proceed ings of the IEEE Infocom, pages -, San Francisco, CA, USA, March 2003. IEEE. http://w w w .caida.org/outreach/papers/2003/ quarantine/. [74] P. Mundur, R. Simon, and A. Sood. Integrated admission control in hierarchical video- on-demand systems. In Proceedings of the IEEE International Conference on Multimedia Computing and Systems, pages 220-225, Florence, Italy, June 1999. IEEE. [75] Netfilter/iptables. Netfilter/iptables project, 2003. http://w w w .netfilter.org/. [76] NetFlow. NetFlow performance analysis. W hite paper, Cisco Systems, Inc., 2003. http://w w w .cisco.com /w arp/public/cc/pd/iosw /prodlit/ntfo_w p.htm . [77] K. Nichols, V. Jacobson, and L. Zhang. A two-bit differentiated services architecture for the Internet. Internet draft, Internet Engineering Task Force, December 1997. draft-nichols- diff-svc-arch-00. tx t. 139 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [78] H. F. Nielsen, J. Gettys, A. Baird-Smith, E. P rud’hommeaux, H. W. Lie, and C. Lilley. Network performance effects of H TTP/1.1, CSS1, and PNG. In Proceedings of the ACM SIGCOMM, pages 155-166, Cannes, France, September 1997. ACM. [79] NIST. NIST net network emulator, 1998. http://is2.antd.nist.gov/itg/nistnet/. [80] V. N. Padm anabhan and J. Mogul. Improving H TTP latency. In Proceedings of the Inter national World Wide Web Conference, pages 995-1005, Chicago, IL, USA, October 1994. [81] F. Paganini, Z. Wang, S.H. Low, and J.C. Doyle. A new TCP/A Q M for stable operation in fast networks. In Proceedings of the IEEE Infocom, pages 96-105, San Francisco, CA, USA, March 2003. IEEE. [82] R. Pan, B. Prabhakar, and K. Psounis. CHOKE, a stateless active queue management scheme for approximating fair bandwidth allocation. In Proceedings of the IEEE Infocom, pages 942-951, Tel-Aviv, Israel, March 2000. IEEE. [83] A.K. Parekh and R. G. Gallagher. A generalized processor sharing approach to flow con trol in integrated services networks: the single-node case. A C M /IE E E Transactions on Networking, l(3):344-357, June 1993. [84] K. Park and H. Lee. On the effectiveness of route-based packet filtering for distributed DoS attack prevention in power-law internets. In Proceedings of the A C M SIGCOMM, pages 15-26, San Diego CA, USA, August 2001. ACM. [85] Vern Paxson. Bro: a system for detecting network intruders in real-time. Computer Net works (Amsterdam, Netherlands: 1999), 31(23-24) :2435-2463, 1999. [86] Peter Pieda, Jeremy Ethridge, Mandeep Baines, and Farhan Shallwani. A network simula tor, differentiated services implementation. http://w ww 7.nortel.com :8080/CTL/, 2000. [87] J. B. Postel. Internet Protocol. RFC 791, Internet Request For Comments, 1981. [ 88] W. Prue and J. Postel. A queuing algorithm to provide Type-of-Service for IP links. RFC 1046, Internet Request For Comments, February 1988. [89] Mohammad A. Rahin and Mourad Kara. Call admission control algorithms in atm networks: A performance comparison and research directions. Research report, University of Leeds, February 1998. [90] M artin Roesch. Snort - lightweight intrusion detection for networks. In USENIX Large Installation Systems Administration Conference, Seattle, WA, USA, November 1999. [91] R. Russell and A. Mackie. Code red II worm. Incident analysis report, SecurityFocus, August 2001. http://aris.securityfocus.com /alerts/codered2/. [92] Shankar Sastry and Marc Bodson. Adaptive Control: Stability, Convergence, and Robust ness. Prentice-Hall, Englewood Cliffs, NJ, first edition edition, 1994. [93] S. Savage, D. Wetherall, A. Karlin, and T. Anderson. Practical network support for ip traceback. In Proceedings of the AC M SIGCOMM, pages 295-306, Stockholm, Sweden, September 2000. ACM. [94] S. Shenker and J. Wroclawski. General characterization parameters for integrated service network elements. RFC 2215, Internet Request For Comments, 1997. 140 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [95] A. C. Shoeten, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio, S. T. Kent, and W. T. Strayer. Hash-based ip traceback. In Proceedings of the AC M SIGCOMM, pages 3-14, San Diego, CA, USA, August 2001. ACM. [96] S. Singh, C. Estan, G. Varghese, and S. Savage. The earlybird system for real-time detection of unknown worms. Technical Report CS2003-0761, University of California, San Diego, August 2003. http://ial.ucsd.edu/earlybird/. [97] F.D. Smith, F. Hernandez Campos, K. Jeffay, and D. O tt. W hat T C P /IP protocol headers can tell us about the web. In Proceedings of the ACM SIGM ETRICS, pages 245-256, Cambridge, MA, June 2001. [98] Eugene H. Spafford. The internet worm: Crisis and aftermath. Communications of the ACM, 32(6):678-687, June 1989. [99] Lance Spitzner. Honeypots, definitions and value of honeypots. http://w w w .spitzner.net/honeypots.htm l, May 2003. 100] S. Stamford. Containment of scanning worms in enterprise networks. W hite paper, Silicon Defense, October 2003. http://www.silicondefense.com/research/ researchpapers/scanCont ainment. 101] S. Stamford, V. Paxson, and N. Weaver. How to Own the Internet in your spare time. In Proceedings of the USENIX Security Symposium, pages -, San Francisco, CA, USA, August 2002. USENIX. 102] Ion Stoica, Scott Shenker, and Hui Zhang. Core-stateless fair queueing: Achieving ap proximately fair bandwidth allocations in high speed networks. In Proceedings of the AC M SIGCOMM, pages 118-130, Vancouver, British Columbia, Canada, September 1998. ACM. 103] Ion Stoica and Hui Zhang. Providing guaranteed services without per flow management. In Proceedings of the AC M SIGCOMM, pages 81-94, Cambridge, MA, USA, September 1999. ACM. 104] J. Twycross and M. M. Williamson. Implementing and testing a virus throttle. In Proceed ings of the USENIX Security Symposium, pages -, Washington, D.C., USA, August 2003. USENIX. 105] G. Veciana and S. Yang. Enhancing both network and user performance metrics for networks supporting best effort traffic. A C M /IE E E Transactions on Networking, 2000. accepted for publication. 106] VINT. UCB/LBNL/VINT network simulator—ns (version 2), 1997. h ttp :// www.isi.edu/nsnam /ns/. 107] Haining Wang, Danlu Zhang, and Kang G. Shin. Detecting SYN flooding attacks. In Proceedings of the IEEE Infocom, pages 1337-1345, New York City, NY, USA, June 2002. IEEE. 108] M att Welsh and David Culler. Adaptive overload control for busy internet servers. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Seattle, WA, USA, March 2003. USENIX. 109] Rich Wolski, Neil T. Spring, and Jim Hayes. The network weather service: A distributed resource performance forecasting service for metacomputing. Journal of Future Generation Computing Systems, 15(6):757-768, October 1999. 141 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. [110] S.-C. Yang and G.de Veciana. Size-based adaptive bandwidth allocation: Optimizing the average QoS for elastic flows. In Proceedings of the IEEE Infocom, volume 2, pages 594-602, New York, NY, USA, June 2002. IEEE. [111] E. W. Zegura, K. L. Calvert, and S. Bhattacharjee. How to model an internetwork. In Proceedings of the IE E E Infocom, volume 2, pages 594-602, San Francisco, CA, USA, March 1996. IEEE. [112] E. W. Zegura, K. L. Calvert, and M. J. Donahoo. A quantitative comparison of graph-based models for Internet topology. A C M /IE E E Transactions on Networking, 5(6):770-783, 1997. [113] Xiaoyun Zhu, Jie Yu, and John Doyle. Heavy tails, generalized coding, and optimal web layout. In Proceedings of the IEEE Infocom, Anchorage, Alaska, USA, April 2001. IEEE. [114] C. C. Zou, L. Gao, W. Gong, and D. Towsley. Monitoring and early warning for internet worms. In Proceedings of the ACM conference on Computer and Communication Security, pages 190-199, Washington D.C., USA, October 2003. ACM. 1 4 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. B ibliograp hy Intrusion detection systems, honeypots and incident response, http://w w w .honeypots.net/. Code-Red: a case study on the spread and victims of an Internet worm. In Proceedings of the A C M SIGCOM M Internet Measurement Workshop, pages 273-284, Marseille, France, November 2002. ACM. http://w w w .caida.org/outreach/papers/2002/ codered/codered.pdf. Stephen Adler. The slashdot effect, an analysis of three internet publications. February 1999. M. Allman, S. Floyd, and C. Partridge. Increasing T C P ’s initial window. RFC 2414, Internet Request For Comments, September 1998. M. Allman, V. Paxson, and W. Stevens. TCP congestion control. RFC 2581, Internet Request For Comments, April 1999. M artin Arlitt and Tai Jin. A workload characterization study of the 1998 world cup web site. IEEE Network, Special Issue on Web Performance, 14(3):30-37, May 2000. Hari Balakrishnan, Venkata Padm anabhan, Srini Seshan, Mark Stemm, and Randy H. Katz. TC P behavior of a busy Internet server: Analysis and improvements. In Proceedings of the IEEE Infocom, pages 252-262, San Francisco, CA, USA, March 1998. IEEE. Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan. An integrated congestion management architecture for internet hosts. In Proceedings of the AC M SIGCOMM, pages 175-187, Cambridge, MA, USA, September 1999. ACM. N. Bansal and M. Harchol-Balter. Analysis of SRPT scheduling: Investigating unfairness. In Proceedings of the AC M SIGM ETRICS, pages 279-290, Cambridge, MA, USA, June 2001. ACM. P. Barford, A. Bestavros, A. Bradley, and M. E. Crovella. Changes in web client access patterns: Characteristics and caching implications. World-Wide Web Journal, 2:15 28, 1999. P. Barford and M. E. Crovella. Measuring web performance in the wide area. ACM Per formance Evaluation Review, 27(2):37-48, August 1999. P. Barford and D. Plonka. Characteristics of network traffic flow anomalies. In Proceedings of the ACM SIGCOMM Internet Measurement Workshop, pages 2-13, San Francisco, CA, November 2001. ACM. Paul Barford and Mark Crovella. Generating representative web workloads for network and server performance evaluation. In Proceedings of the ACM SIGM ETRICS, pages 151 160, Madison, WI, USA, June 1998. ACM. 143 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Michele Basseville and Igor V. Nikiforov. Detection of Abrupt Changes - Theory and Ap plication. Prentice-Hall, Englewood Cliffs, NJ, first edition edition, April 1993. V. Berk, G. Bakos, and R. Morris. Designing a framework for active worm detection on global networks. In Proceedings of the IEEE International Workshop on Information A s- surance, pages 13 -23, Darm stadt, Germany, March 2003. IEEE. T. Berners-Lee, R. Fielding, and H. Frystyk. Hypertext transfer protocol—H TTP/1.0. RFC 1945, Internet Request For Comments, May 1996. ftp://ftp.isi.edu/in-notes/rfcl945.txt. N. Bhatti, A. Bouch, and A. Kuchinsky. Integrating user-perceived quality into web server design. In Proceedings of the International World Wide Web Conference, pages 1-16, Am sterdam, Holland, May 2000. S. Blake, D. Black, M. Carlson, E. Davies, and W. Weiss Z. Wang. An architecture for differentiated service. RFC 2475, Internet Request For Comments, December 1998. Rudolf B Blazek, Hongjoong Kim, Boris Rozovskii, and Alexander Tartakovsky. A novel ap proach to detection of denial-of-service attacks via adaptive sequential and batch-sequential change-point detection methods. In Proceedings of the IEEE Systems, Man, and Cybernetics Information Assurance Workshop, West Point, NY, USA, June 2001. IEEE. L. Brakmo. TC P Vegas: End to end congestion avoidance on a global internet. IEEE Journal on Selected Areas in Communications, 1.3(8):1465 1480, October 1995. Lee Breslau, Edward W. Knightly, Scott Shenker, Ion Stoica, and Hui Zhang. Endpoint admission control: Architectural issues and performance. In Proceedings of the AC M SIG COMM, pages 57-69, Stockholm, Sweden, August 2000. CERT. W 32/Sobig.F worm. Incident note, CERT-Coordination Center, August 2003. IN- 2003-03. C. Cetinkaya and E. Knightly. Egress admission control. In Proceedings of the IEEE Info com, pages 1471-1480, Tel-Aviv, Israel, March 2000. IEEE. Kun chan Lan, Alefiya Hussain, and Debojyoti D utta. The effect of malicious traffic on the network. In Proceedings of the Passive and Active Measurement Workshop, San Diego, CA, USA, April 2003. IEEE. H. Chen and P. M ohapatra. Session-based overload control in qos-aware web servers. In Proceedings of the IEEE Infocom, New York, NY, USA, June 2002. IEEE. X. Chen and J. Heidemann. Flash crowd mitigation via an adaptive admission control based on application-level measurement. Technical Report ISI-TR-557, USC/Information Sciences Institute, May 2002. under submission. X. Chen and J. Heidemann. Experimental evaluation of an adaptive flash crowd protec tion system. Technical Report ISI-TR-573, USC/Information Sciences Institute, July 2003. under submission. X. Chen and J. Heidemann. Preferential treatm ent for short flows to reduce web latency. Computer Networks, 41(6):779-794, April 2003. M. Christiansen, K. Jeffay, D. O tt, and F.D. Smith. Tuning RED for web traffic. In Proceedings of the ACM SIGCOMM, pages 139-150, Stockholm, Sweden, August 2000. 144 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Brent N. Chun, Jason Lee, and Hakim Weatherspoon. Netbait: a distributed worm detec tion service, http://netbait.planet-lab.org/, February 2003. D. Clark and W. Fang. Explicit allocation of best effort packet delivery service. A C M /IE E E Transactions on Networking, 6(4):362-373, August 1998. David D. Clark, Scott Shenker, and Lixia Zhang. Supporting real-time applications in an integrated services packet network: Architecture and mechanism. In Proceedings of the AC M SIGCOMM, pages 14-26, Baltimore, MD, USA, August 1992. ACM. cite- seer.nj.nec.com/clark92supporting.html. T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein. Introduction to Algorithms. The MIT Press, Cambridge, MA, second edition edition, 2001. M. E. Crovella, R. Frangioso, and M. Harchol-Balter. Connection scheduling in web servers. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Boulder, CO, USA, October 1999. Mark E. Crovella and Azer Bestavros. Self-similarity in world wide web traffic: evidence and possible causes. In Proceedings of the AC M SIGM ETRICS, pages 160-169, Philadelphia, Pennsylvania, May 1996. ACM. A. Demers, S. Keshav, and S. Shenker. Analysis and simulation of a fair-queueing algorithm. In Proceedings of the ACM SIGCOMM, pages 1-12, Austin, TX, USA, September 1989. ACM. Lars Eggert and John Heidemann. Application-level differentiated services for web servers. World-Wide Web Journal, 2(3):133-142, August 1999. Lars Eggert, John Heidemann, and Joe Touch. Effects of ensemble-TCP. AC M Computer Communication Review, 30(l):15-29, January 2000. C. Estan and G. Varghese. New directions in traffic measurement and accounting. In Proceedings of the ACM SIGCOMM, pages 323-336, Pittsburgh, PV, USA, August 2002. ACM. K. Fall and S. Floyd. Simulation-based comparisons of Tahoe, Reno, and SACK TCP. ACM Computer Communication Review, 26(3):5-21, July 1996. W. Fang, N. Seddigh, and B. Nandy. A time sliding window three colour marker (TSWTCM). RFC 2859, Internet Request For Comments, June 2000. Anja Feldmann, Anna C. Gilbert, Polly Huang, and Walter Willinger. Dynamics of IP traffic: A study of the role of variability and the impact of control. In Proceedings of the AC M SIGCOMM, pages 301-313, Cambridge, MA, USA, August 1999. ACM. S. Floyd, M. Handley, and J. Padhye. A comparison of equation-based and aimd congestion control. 2000. S. Floyd and V. Jacobson. Random early detection gateways for congestion avoidance. A C M /IE E E Transactions on Networking, 1(4):397-413, August 1993. Sally Floyd and Kevin Fall. Promoting the use of end-to-end congestion control in the Internet. A C M /IE E E Transactions on Networking, 7(4):458-473, August 1999. Sally Floyd and Vern Paxson. Difficulties in simulating the Internet. A C M /IE E E Transac tions on Networking, 9(4):392-403, August 2001. 145 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Cooperative Association for Internet D ata Analysis. Netramet web session performance project, http://w w w .caida.org/analysis/w orkload/netram et/w eb/. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext transfer protocol—H TTP/1.1. RFC 2616, Internet Request For Comments, June 1999. http: / / www.w3.org/Protocols/rfc2616/rfc2616.html. R.J. Gibbens, F. P. Kelly, and P.B. Key. A decision-theoretic approach to call admission control in ATM networks. IEEE Journal on Selected Areas in Communications, 13(6):30-37, August 1995. T. M. Gil and M. Poletto. MULTOPS: A data-structure for bandwidth attack detection. In Proceedings of the USENIX Security Symposium, pages 23-38, Washington, D.C., USA, August 2001. USENIX. Liang Guo and Ibrahim M atta. The war between mice and elephants. In Proceedings of the IEEE International Conference on Network Protocols, Riverside, CA, USA, November 2001. IEEE. H. W. Hethcote. The mathematics of infectious diseases. SIA M Review, 42(4):599 653, October 2000. P. Hurley, M. Kara, L. Boudec, and P. Thiran. ABE: Providing a low-delay service within best-effort. IE EE Network Magazine, 15 (3):60-69, May 2001. Van Jacobson. Congestion avoidance and control. In Proceedings of the SIGCOM M ’ 88, pages 314-329, Stanford, California, August 1988. ACM. S. Jamin, P.B. Danzig, S. Shenker, and L. Zhang. Measurement-based admission control algorithms for controlled-load service. In Proceedings of the AC M SIGCOMM, pages 2-13, Cambridge, MA, October 1995. ACM. H. Jamjoom and K. G. Shin. Persistent dropping: An efficient control of traffic aggregates. In Proceedings of the AC M SIGCOMM, pages 287-298, Karlsruhe, Germany, August 2003. ACM. R. Johari and D. Tan. End-to-end congestion control for the internet: Delays and stability. A C M /IE E E Transactions on Networking, 9(6):818-832, December 2001. J. Jung, B. Krishnamurthy, and M. Rabinovich. Flash crowds and denial of service at tacks: Characterization and implications for CDNs and web sites. In Proceedings of the International World Wide Web Conference, pages 252 262, Hawaii, USA, May 2002. IEEE. F. Kelly, A. Maulloo, and D. Tan. Rate control in communication networks: shadow prices, proportional fairness and stability. Journal of the Operational Research Society, 49(3):237 252, March 1998. M. Kim and B. Noble. Mobile network estimation. In Proceedings of the A C M /IE E E In ternational Conference on Mobile Computing and Networking, pages 298-309, Rome, Italy, July 2001. ACM. Lawrence-Berkeley Labs. The Internet Traffic Archive, 1992. http://ita.ee.lbl.gov/. Kunchan Lan and John Heidemann. Rapid model parameterization from traffic measure ment. ACM Transactions on Modeling and Computer Simulation, 12(3):201-229, July 2002. 146 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Chuck Lever, Marius Aamodt Eriksen, and Stephen P. Molloy. An analysis of the TUX web server. Technical report, Center for Information Technology Integration, University of Michigan, November 2000. M. Liljenstam, Y. Yuan, B J Premore, and David Nicol. A mixed abstraction level simulation model of large-scale internet worm infestations. In Proceedings of the International Sympo sium on Modeling, Analysis and Simulation of Computer and Telecommunication Systems, pages 109-116, Fort Worth, TX, USA, October 2002. IEEE. Dong Lin and Robert Morris. Dynamics of random early detection. In Proceedings of the AC M SIGCOMM, pages 127-137, Cannes, France, September 1997. ACM. S. H. Low and D. E. Lapsley. Optimization flow control — I: basic algorithm and conver gence. A C M /IE E E Transactions on Networking, 7(6):861-874, December 1999. C. Lu, T. F. Abdelzaher, J. A. Stankovic, and S. H. Son. A feedback control approach for guaranteeing relative delays in web servers. In Proceedings of the IEEE Real-Time Technology and Applications Symposium, Taipei, Taiwan, June 2001. IEEE. A. Mackie, J. Roculan, R. Russell, and M. V. Velzen. Nimda worm analysis. Incident anal ysis report, SecurityFocus, September 2001. http://aris.securityfocus.com /alerts/nim da/ 010919-Analysis-Nimda.pdf. R. Mahajan, S. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and S. Shenker. Controlling high bandwidth aggregates in the network. Technical report, ICSI, July 2001. R. M ahajan and S. Floyd. Controlling high bandwidth flows at the congested router. In Pro ceedings of the IEEE International Conference on Network Protocols, pages 1-12, Riverside, CA, USA, November 2001. IEEE. D. Moore, V. Paxson, S. Savage, C. Shannon, S. Staniford, and N. Weaver. The spread of the Sapphire/Slammer worm. Technical report, CAIDA, the Cooperative Association for Internet D ata Analysis, January 2003. http://w w w .caida.org/outreach/papers/2003/ sapphire/. D. Moore and C. Shannon. The spread of the code-red worm (CRv2). Techni cal report, CAIDA, the Cooperative Association for Internet D ata Analysis, 2002. http: / / www.caida.org/analysis/security/code-red/coderedv2_analysis.xml. David Moore, Colleen Shannon, Geoffrey M. Voelker, and Stefan Savage. Inter net quarantine: Requirements for containing self-propagating code. In Proceed ings of the IE E E Infocom, pages -, San Francisco, CA, USA, March 2003. IEEE, http: / / www.caida.org/outreach/papers /2003/ quarantine/. P. Mundur, R. Simon, and A. Sood. Integrated admission control in hierarchical video- on-demand systems. In Proceedings of the IEEE International Conference on Multimedia Computing and Systems, pages 220-225, Florence, Italy, June 1999. IEEE. Netfilter/iptables. Netfilter/iptables project, 2003. http://w w w .netfilter.org/. NetFlow. NetFlow performance analysis. W hite paper, Cisco Systems, Inc., 2003. http://w w w .cisco.com /w arp/public/cc/pd/iosw /prodlit/ntfo_w p.htm . K. Nichols, V. Jacobson, and L. Zhang. A two-bit differentiated services architecture for the Internet. Internet draft, Internet Engineering Task Force, December 1997. draft-nichols- diff-svc-arch-00, tx t. 147 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. H. F. Nielsen, J. Gettys, A. Baird-Smith, E. P rud’hommeaux, H. W. Lie, and C. Lilley. Network performance effects of H TTP/1.1, CSS1, and PNG. In Proceedings of the ACM SIGCOMM, pages 155-166, Cannes, France, September 1997. ACM. NIST. NIST net network emulator, 1998. http://is2.antd.nist.gov/itg/nistnet/. V. N. Padm anabhan and J. Mogul. Improving H TTP latency. In Proceedings of the Inter national World Wide Web Conference, pages 995-1005, Chicago, IL, USA, October 1994. F. Paganini, Z. Wang, S.H. Low, and J.C. Doyle. A new TCP/AQ M for stable operation in fast networks. In Proceedings of the IEEE Infocom, pages 96-105, San Francisco, CA, USA, March 2003. IEEE. R. Pan, B. Prabhakar, and K. Psounis. CHOKE, a stateless active queue management scheme for approximating fair bandwidth allocation. In Proceedings of the IEEE Infocom, pages 942-951, Tel-Aviv, Israel, March 2000. IEEE. A.K. Parekh and R. G. Gallagher. A generalized processor sharing approach to flow con trol in integrated services networks: the single-node case. A C M /IE E E Transactions on Networking, l(3):344-357, June 1993. K. Park and H. Lee. On the effectiveness of route-based packet filtering for distributed DoS attack prevention in power-law internets. In Proceedings of the AC M SIGCOMM, pages 15-26, San Diego CA, USA, August 2001. ACM. Vern Paxson. Bro: a system for detecting network intruders in real-time. Computer Net works (Amsterdam, Netherlands: 1999), 31(23-24) :2435-2463, 1999. Peter Pieda, Jeremy Ethridge, Mandeep Baines, and Farhan Shallwani. A network simula tor, differentiated services implementation. http://www 7.nortel.com :8080/CTL/, 2000. J. B. Postel. Internet Protocol. RFC 791, Internet Request For Comments, 1981. W. Prue and J. Postel. A queuing algorithm to provide Type-of-Service for IP links. RFC 1046, Internet Request For Comments, February 1988. Mohammad A. Rahin and Mourad Kara. Call admission control algorithms in atm networks: A performance comparison and research directions. Research report, University of Leeds, February 1998. M artin Roesch. Snort - lightweight intrusion detection for networks. In USENIX Large Installation Systems Administration Conference, Seattle, WA, USA, November 1999. R. Russell and A. Mackie. Code red II worm. Incident analysis report, SecurityFocus, August 2001. http://aris.securityfocus.com /alerts/codered2/. Shankar Sastry and Marc Bodson. Adaptive Control: Stability, Convergence, and Robust ness. Prentice-Hall, Englewood Cliffs, NJ, first edition edition, 1994. S. Savage, D. Wetherall, A. Karlin, and T. Anderson. Practical network support for ip traceback. In Proceedings of the ACM SIGCOMM, pages 295-306, Stockholm, Sweden, September 2000. ACM. S. Shenker and J. Wroclawski. General characterization parameters for integrated service network elements. RFC 2215, Internet Request For Comments, 1997. 148 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. A. C. Shoeten, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio, S. T. Kent, and W. T. Strayer. Hash-based ip traceback. In Proceedings of the ACM SIGCOMM, pages 3-14, San Diego, CA, USA, August 2001. ACM. S. Singh, C. Estan, G. Varghese, and S. Savage. The earlybird system for real-time detection of unknown worms. Technical Report CS2003-0761, University of California, San Diego, August 2003. http://ial.ucsd.edu/earlybird/. F.D. Smith, F. Hernandez Campos, K. Jeffay, and D. O tt. W hat T C P /IP protocol headers can tell us about the web. In Proceedings of the ACM SIGM ETRICS, pages 245-256, Cambridge, MA, June 2001. Eugene H. Spafford. The internet worm: Crisis and aftermath. Communications of the ACM, 32(6):678-687, June 1989. Lance Spitzner. Honeypots, definitions and value of honeypots. http://www .spitzner.net/honeypots.htm l, May 2003. S. Staniford. Containment of scanning worms in enterprise networks. W hite paper, Silicon Defense, October 2003. http://www.silicondefense.com/research/ researchpapers/scanContainment. S. Staniford, V. Paxson, and N. Weaver. How to Own the Internet in your spare time. In Proceedings of the USENIX Security Symposium, pages -, San Francisco, CA, USA, August 2002. USENIX. Ion Stoica, Scott Shenker, and Hui Zhang. Core-stateless fair queueing: Achieving ap proximately fair bandwidth allocations in high speed networks. In Proceedings of the ACM SIGCOMM, pages 118-130, Vancouver, British Columbia, Canada, September 1998. ACM. Ion Stoica and Hui Zhang. Providing guaranteed services without per flow management. In Proceedings of the ACM SIGCOMM, pages 81-94, Cambridge, MA, USA, September 1999. ACM. J. Twycross and M. M. Williamson. Implementing and testing a virus throttle. In Proceed ings of the USENIX Security Symposium, pages -, Washington, D.C., USA, August 2003. USENIX. G. Veciana and S. Yang. Enhancing both network and user performance metrics for networks supporting best effort traffic. A C M /IE E E Transactions on Networking, 2000. accepted for publication. VINT. UCB/LBNL/VINT network simulator— ns (version 2), 1997. h ttp : / / www .isi.edu/n sn am /n s/. Haining Wang, Danlu Zhang, and Kang G. Shin. Detecting SYN flooding attacks. In Proceedings of the IEEE Infocom, pages 1337-1345, New York City, NY, USA, June 2002. IEEE. M att Welsh and David Culler. Adaptive overload control for busy internet servers. In Proceedings of the USENIX Symposium on Internet Technologies and Systems, Seattle, WA, USA, March 2003. USENIX. Rich Wolski, Neil T. Spring, and Jim Hayes. The network weather service: A distributed resource performance forecasting service for metacomputing. Journal of Future Generation Computing Systems, 15(6):757-768, October 1999. 149 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. S.-C. Yang and G.de Veciana. Size-based adaptive bandwidth allocation: Optimizing the average QoS for elastic flows. In Proceedings of the IEEE Infocom, volume 2, pages 594-602, New York, NY, USA, June 2002. IEEE. E. W. Zegura, K. L. Calvert, and S. Bhattacharjee. How to model an internetwork. In Proceedings of the IEEE Infocom, volume 2, pages 594-602, San Francisco, CA, USA, March 1996. IEEE. E. W. Zegura, K. L. Calvert, and M. J. Donahoo. A quantitative comparison of graph-based models for Internet topology. A C M /IE E E Transactions on Networking, 5(6):770-783, 1997. Xiaoyun Zhu, Jie Yu, and John Doyle. Heavy tails, generalized coding, and optimal web layout. In Proceedings of the IEE E Infocom, Anchorage, Alaska, USA, April 2001. IEEE. C. C. Zou, L. Gao, W. Gong, and D. Towsley. Monitoring and early warning for internet worms. In Proceedings of the AC M conference on Computer and Communication Security, pages 190-199, Washington D.C., USA, October 2003. ACM. 150 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. W eb M odel E lem ents E lem ent A ttrib utes P robabilistic D istributions Param eters Web Session Number of Web Sessions Time Interval between Sessions (seconds) Number of Web Pages per Session Constant Exponential Exponential value: 100 mean: 600 mean: 5 Web Page Time Interval between Pages (seconds) Number of Web Objects per Page Exponential Exponential mean: 30 mean: 5 Web Object Time Interval between Web Objects (seconds) Object Size (KBytes) Exponential Pareto II mean: 0.01 mean: 12, shape: 1.2 Table 1: Attributes of our web traffic model and corresponding distributions for background traffic. Traffic Session Inter-session N um ber o f P ages B ulk T ype N um ber T im e (seconds) in one Session Size background 100 600 5 NONE flash crowd 1000 6 3 Exponential (mean: 3) Table 2: Different Session-level attributes for Background and Flash crowd Traffic. .1 S im u lation R esu lts w ith T w o-layer F lash-crow d Traffic M od el In this section, we briefly review our early simulation studies with the simple two-layer flash crowd traffic model. We use this model to test NEWS design in early stage. We have repeated these simulations with web server logs in Section 4.6. We model flash crowd traffic with two layers: background models the normal web traffic pattern, and flash crowd captures the characteristics of flash crowd traffic. Background traffic exists throughout simulation, while flash crowd traffic only appears during a certain time period. We model both background and flash crowd layers based on the web traffic model in ns [42], which has been described with details in Section 3.4.1. Table 1 summarizes the attributes and corresponding distributions for background traffic. T h e difference betw een flash crow d an d background traffic is a t session level, ra th e r th a n at, page level. This is because web pages are not likely to change under either condition. So, we use the same page level attributes for both background and flash crowd traffic modeling. We change session level attributes to reflect some characteristics of flash crowds: larger number of clients, shorter inter-session time, and smaller number of web pages within on session. We also model bulk arrivals (that is, the bulk size) for flash crowd traffic. We show the difference between flash crowd and background traffic in Table 2. 151 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 5M b 2M b 5M b RO 60ms 40ms 20ms C4j Figure 1: The two-level dumbbell topology in simulations. 14 without NEWS with NEWS 12 1 0 C C -o T o § C D o o 3 a , 8 S f - s s C C < D ■ o - Q 6 0 ) c t- 3 1 “ 4 2 0 0 4000 8000 12000 20000 16000 time (second) (a ) N E W S r eg u la te s th e a d m itte d req u est ra te a d a p tiv ely . C O C C S w § < D C D - g C C C D -o-g (D E to o I S ? 14 without NEWS with NEWS 12 10 8 6 4 2 0 0 1000 2000 3000 4000 5000 6000 7000 8000 time (second) (b ) E arly p er io d o f th e a b o v e figure. Figure 2: Changes in admitted request rate with NEWS (observed in simulations). Figure 1 shows the simulated network topology. The simulation runs for 20000 seconds. We inject flash crowd traffic at 1000 second. W ithout NEWS, the flash crowd ends at 8000 second. We conduct simulations with and without NEWS deployed. We measure the adm itted request rate to the target server and compare the results without and with NEWS deployed in Figure 2(a). Looking at the early stage of flash crowds in Figure 2(b), NEWS detects flash crowd at 1595 second with the detection interval T = 240seconds. T hat is, the detection latency is about 10 minutes, which is about 2 or 3 detection intervals. After detecting the flash crowd, NEWS adjust its rate limit automatically and regulates the in coming requests to a proper rate. As a result, the adm itted request rate drops; and the congestion in response traffic is relieved, reducing packet drop rate from 17% to 1%. Figure 3 shows the offered request rate increases because of request retransmissions. NEWS also maintains high performance for adm itted end-users (Figure 4). This performance is comparable to static rate limiters. As shown in Figure 5(a), we find that rate limiter gives best performance when the rate limit is set to 4 requests per second. We compare NEWS with the best rate limiter in Figure 5(b) and summarize their performance in Table 3. We highlight 1 5 2 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. 2 5 without NEWS with NEWS 20 0 0 _ ir 9 ^ c to o < D O 3 0 O'co 0 nr 0 J D E 3 0 S ■ o 0 O 4000 8000 12000 16000 20000 0 time (second) Figure 3: Increased Offered Request Rate due to Retransmission (observed in simulations). 200 without NEWS • with NEWS 180 £ 160 0 140 § 1 120 8-a cw 100 a:£ Sx 8 0 | 60 2? 40 0 5 < 20 8000 12000 16000 0 4000 20000 time (second) Figure 4: NEWS Maintains High Aggregated Rate for HBFs during Flash Crowds (observed in simula tions). 220 200 ° 180 0 | 160 % ' S 140 | I 1 ^ 0 100 -o c o ® t 80 0 0 60 o > O ) 40 0 4000 8000 12000 16000 20000 180 Rate limiter NEWS 160 o £ 140 c r 120 W C O a s 100 to 80 -O CD ® I 0 D > 60 0 o > o > < 0 4000 8000 12000 16000 20000 tim e < second> time (second) (a ) T h e a g g r eg a ted ra te o f H B F s w ith d ifferen t ra te (fa) C o m p a rin g th e b e s t s ta tic ra te H m iter w ith N K W S lim its. Figure 5: Aggregated rate of HBFs with static rate limiter and NEWS (observed in simulations). 153 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission. Scenarios A d m itted R equ est R ate (n u m b er/s) R equest R ejection R ate A ggregated R ate of H B F s (K bps) R esp on se Loss R ate O riginal traffic 4 0% 48.9 17% N E W S 3.6 56% 102 1% R ate lim iter 3.6 67% 117.8 0.1% T able 3: Comparison of NEW S with static rate limiters in simulations. 120 110 100 - / Q . C O C O Q . a> -Q cc* ( 0 CO o > x 90 80 - 70 - 60 - 50 - 40 NEWS Rate limiters wo/NEVVS.. 3 4 5 6 7 8 9 Rate limit (number/second) 10 F ig u re 6: The aggregated rate of HBFs w ith NEWS and static rate limiters in simulations. the aggregated rate of HBFs in Figure 6. In summary, adm itted end-users perceive high web performance with NEWS deployed. 154 Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

Linked assets

University of Southern California Dissertations and Theses

Conceptually similar

PDF

Diagnosis and localization of interdomain routing anomalies

PDF

Adaptive energy conservation protocols for wireless ad hoc routing

PDF

Grid workflow: A flexible framework for fault tolerance in the grid

PDF

Adaptive routing services in ad-hoc and sensor networks

PDF

Distributed resource allocation in networks for multiple concave objectives

PDF

Directed diffusion: An application -specific and data -centric communication paradigm for wireless sensor networks

PDF

Call admission control and resource allocation for quality of service support in wireless multimedia networks

PDF

Analysis of wired short cuts in wireless sensor networks

PDF

Design of wireless sensor network based structural health monitoring systems

PDF

Energy latency tradeoffs for medium access and sleep scheduling in wireless sensor networks

PDF

Systematic test synthesis for multipoint protocol design

PDF

Architecture -independent programming and software synthesis for networked sensor systems

PDF

Algorithms for performance and trust in peer -to -peer systems

PDF

Boundary estimation and tracking of spatially diffuse phenomena in sensor networks

PDF

Characterizing Internet topology, routing and hierarchy

PDF

Bioscope: Actuated sensor network for biological science

PDF

Design issues in large-scale application -level routing

PDF

A hybrid systems modeling framework for transport protocols

PDF

Deadlock recovery-based router architectures for high performance networks

PDF

Automatically and accurately conflating road vector data, street maps and orthoimagery

Asset Metadata

Creator Chen, Xuan (author)

Core Title Applying aggregate-level traffic control algorithms to improve network robustness

School Graduate School

Degree Doctor of Philosophy

Degree Program Computer Science

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag Computer Science,OAI-PMH Harvest

Language English

Contributor Digitized by ProQuest (provenance)

Advisor Heidemann, John (committee chair), Govindan, Ramesh (committee member), Helmy, Ahmed Abdel-Ghaffar (committee member)

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c16-660215

Unique identifier UC11340203

Identifier 3145171.pdf (filename),usctheses-c16-660215 (legacy record id)

Legacy Identifier 3145171.pdf

Dmrecord 660215

Document Type Dissertation

Rights Chen, Xuan

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the au...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus, Los Angeles, California 90089, USA