WASHINGTON UNIVERSITY SEVER INSTITUTE OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING

Transcription

1 WASHINGTON UNIVERSITY SEVER INSTITUTE OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING IMPROVING THE PERFORMANCE OF INTERNET DATA TRANSPORT by Anshul Kantawala, B.S. M.S. Prepared under the direction of Professor Jonathan S. Turner A dissertation presented to the Sever Institute of Washington University in partial fulfillment of the requirements for the degree of Doctor of Science May, 2005 Saint Louis, Missouri

2 WASHINGTON UNIVERSITY SEVER INSTITUTE OF TECHNOLOGY DEPARTMENT OF COMPUTER SCIENCE AND ENGINEERING ABSTRACT IMPROVING THE PERFORMANCE OF INTERNET DATA TRANSPORT by Anshul Kantawala ADVISOR: Professor Jonathan S. Turner May, 2005 Saint Louis, Missouri With the explosion of the World Wide Web, the Internet infrastructure faces new challenges in providing high performance for data traffic. First, it must be able to provide a fair-share of congested link bandwidth to every flow. Second, since web traffic is inherently interactive, it must minimize the delay for data transfer. Recent studies have shown that queue management algorithms such as Tail Drop, RED and Blue are deficient in providing high throughput, low delay paths for a data flow. Two major shortcomings of the current algorithms are: they allow TCP flows to get synchronized and thus require large buffers during congestion to enable high throughput; and they allow unfair bandwidth usage for shorter round-trip time TCP flows. We propose algorithms using multiple queues and discard policies with hysteresis at bottleneck routers to address both these issues. Using ns-2 simulations, we show that these algorithms can significantly outperform RED and Blue, especially at smaller buffer sizes.

3 Using multiple queues raises two new concerns: scalability and excess memory bandwidth usage caused by dropping packets which have been queued. We propose and evaluate an architecture using Bloom filters to evenly distribute flows among queues to improve scalability. We have also developed new intelligent packet discard algorithms that discard packets on arrival and are able to achieve performance close to that of policies that may discard packets that have already been queued. Finally, we propose better methods for evaluating the performance of fair-queueing methods. In the current literature, fair-queueing methods are evaluated based on their worst-case performance. This can exaggerate the differences among algorithms, since the worst-case behavior is dependent on the the precise timing of packet arrivals. This work seeks to understand what happens under more typical circumstances.

4 to my parents, my wife and my daughter

5 Contents List of Tables vii List of Figures ix Acknowledgments xiii 1 Introduction TCP Overview Reliability Congestion Control High queueing delay due to large buffers Unfairness due to differences in round-trip times Evaluating Fair Queueing Algorithms Interaction of TCP and Router Buffer Management TCP Flow Control and Tail Discard Simple Buffer Analysis for TCP-like Flows RED TCP Fairness and Round-Trip Times (RTT) Per-Flow Queueing Algorithms Evaluation Continuous TCP Flows Single Bottleneck Link Results Multiple Round-Trip Time Configuration Results iv

6 3.3.5 Multi-Hop Path Configuration Results Connections with Multiple Short Transfers Single Bottleneck Link Results Multiple Roundtrip-time Configuration Results Multi-Hop Path Configuration Results A Closer Look at Queue State DRR Simple Buffer Analysis for TCP Flows using QSDRR Desychronizing effects of QSDRR QSDRR with a Small Number of TCP Flows Experimental Results Usability over Large Networks Simulation Setup Results Scalability Issues Flow Distribution Algorithm Overview of Bloom filters Bloom filter architecture Distribution Policy Bloom filter queue ratios and memory usage Dynamic rebalancing Periodic Balancing (PB) Balancing at Dequeue (DB) Results Flows arriving and leaving the system Static number of flows Packet Discard on Arrival Memory Bandwidth Issues Algorithms Simulation Environment v

7 6.3.1 Single Bottleneck Link Multiple Roundtrip-time Configuration Multi-Hop Path Configuration Results Single-Bottleneck Link Multiple Round-Trip Time Configuration Multi-Hop Path Configuration Scalability Issues Short-Term Fairness Metrics for Evaluating Fair-Queueing Algorithms Delay Performance Throughput Performance Single Target Flow Model Delay Performance Throughput Performance Related Work Other Buffer Management Policies FRED Self-Configuring RED TCP with per-flow queueing TCP/Active Queue Management (AQM) Analysis Bloom Filters Queue Management: Stochastic Fair Blue (SFB) Traffic Measurement and Accounting Shared-Memory Buffer Management Fair Queueing (FQ) Conclusions and Future Work 112 References 114 Vita 120 vi

8 List of Tables 2.1 Definitions of terms used in analysis Comparing queue drop and cycle time obtained using the analytical model vs. simulation data Throughput variations when changing RED s dropping probability Average Throughputs for 40 ms RTT and 200 ms RTT flows under Tail Discard and RED RED parameters Blue parameters Definitions of terms used in analysis Number of flows affected during the first drop interval, comparing the analytical and simulation values SRAM memory needed for per-flow queueing vs. Bloom filter architecture for 100,000 flows Max/min flows queue ratios for Bloom architecture vs. simple hashing Max/min flows queue ratios for Bloom architecture with Periodic, Dequeue and both dynamic rebalancing vs. simple hashing for dynamic number of flows Max/min flows queue ratios for Bloom architecture with Periodic, Dequeue and both dynamic rebalancing vs. simple hashing for dynamic number of flows Max/min flows queue ratios for Bloom architecture with Periodic, Dequeue and both dynamic rebalancing vs. simple hashing for dynamic number of flows Max/min flows queue ratios for Bloom architecture with Periodic, Dequeue and both dynamic rebalancing vs. simple hashing for static number of flows 78 vii

9 5.7 Max/min flows queue ratios for Bloom architecture with Periodic, Dequeue and both dynamic rebalancing vs. simple hashing for static number of flows Max/min flows queue ratios for Bloom architecture with Periodic, Dequeue and both dynamic rebalancing vs. simple hashing for static number of flows Discard queue time statistics viii

10 List of Figures 2.1 Bottleneck queue behaviour for Tail Discard with buffer size 4167 packets (round-trip delay times bandwidth) Single Bottleneck Link Network Configuration Comparison of analytical queueing behaviour with simulation results Comparison of analytical queueing behaviour with simulation results when queue underflows Buffer Occupancy Time History for RED with changing Drop Probability Average TCP Congestion Window Sizes for TCP sources with different RTT using Tail Discard Average TCP Congestion Window Sizes for TCP sources with different RTT using RED Algorithm for QSDRR Single Bottleneck Link Network Configuration TCP Reno Goodput distribution over single-bottleneck link with 200 packet buffer Standard deviation relative to fair-share for TCP Reno flows over a singlebottleneck link Fair share performance over a single bottleneck link Fair share performance of TDRR over a single bottleneck link with varying exponential weights Multiple Round-Trip Time Network Configuration Fair share performance of different RTT flows over a single bottleneck link Multi-Hop Path Network Configuration Fair Share performance of end-to-end and cross traffic flows over a multihop path configuration Single Bottleneck Link Network Configuration ix

11 3.12 Performance of short burst TCP flows over a single bottleneck link Multiple Roundtrip-time Network Configuration Performance of short burst TCP flows over a multiple round-trip time configuration Multi-Hop Path Network Configuration Performance of short burst TCP flows over a multi-hop path configuration Queue lengths for 10 flows with buffer size = 417 pkts Queue lengths for 10 flows with buffer size = 50 pkts Queue lengths for 10 flows with buffer size = 100 pkts Packet drop trace for QSDRR compared to Tail Drop for a fair share window size of 5 packets over a single bottleneck link Packet drop trace for QSDRR compared to Tail Drop for a window size of 25 packets over a single bottleneck link Packet drop trace for QSDRR compared to Tail Drop for a window size of 5 packets over a multiple-rtt configuration Packet drop trace for QSDRR compared to Tail Drop for a window size of 25 packets over a multiple-rtt configuration Fair share performance of a small number of TCP flows over a single bottleneck link Fair share performance of 2 TCP flows with different RTTs over a single bottleneck link Fair share performance of 4 TCP flows with different RTTs over a single bottleneck link Fair share performance of 8 TCP flows with different RTTs over a single bottleneck link Time history of congestion window sizes for 4 TCP flows using Tail Drop Experimental configuration using two Multi-Service Routers and four NetBSD hosts Experimental fair share performance and standard deviation for 32 TCP flows over a single bottleneck link Experimental fair share performance and standard deviation for 48 TCP flows over a single bottleneck link Experimental fair share performance and standard deviation for 60 TCP flows over a single bottleneck link x

12 4.17 Single Bottleneck Link Network Configuration Performance of TCP flows over single bottleneck link while varying the bottleneck link Performance of TCP flows over single bottleneck link while varying the RTT Performance of TCP flows over single bottleneck link while varying the number of sources Performance of TDRR and QSDRR for a buffer size of 1000 packets, with varying number of buckets Flow distribution using Bloom Filters Algorithm for distributing Bloom filters among queues Max/min queue ratios for Bloom filter architecture compared with simple hashing for flow to queue ratios from 1 to 1, Memory usage for Bloom filter policies compared with per-flow queueing for flow to queue ratios from 1 to 1, Max/min queue ratios for Bloom filter architecture without dynamic rebalancing compared with simple hashing Policy for updating Bloom filter counts Algorithm for periodically balancing flows across queues Algorithm for balancing flows during dequeue Flows arriving and departing at a rate of 10 flows/s Flows arriving and departing at a rate of 20 flows/s Flows arriving and departing at a rate of 50 flows/s Flows arriving and departing at a rate of 100 flows/s Mean destination hold time = 2s Mean destination hold time = 5s Algorithm for DSDRR Single Bottleneck Link Network Configuration Multiple Roundtrip-time Network Configuration Multi-Hop Path Network Configuration Standard deviation relative to fair-share for long-lived TCP Reno flows over a single-bottleneck link Fair share performance for long-lived TCP Reno flows over a single bottleneck link Ratio of maximum to minimum flow throughputs xi

13 6.8 Performance of short burst TCP flows over a single bottleneck link Fair share performance of different RTT long-lived TCP flows over a single bottleneck link Performance of short burst TCP flows over a multiple round-trip time configuration Fair Share performance of long-lived TCP flows over a multi-hop path configuration Performance of short burst TCP flows over a multi-hop path configuration Performance of DTDRR and DSDRR for a buffer size of 1000 packets, with varying number of buckets Distribution of queue discard times for DSDRR and QSDRR Average and Maximum Delays for small (1 Mb/s) flows Average and Maximum Delays for the large (10 Mb/s) flow Time taken for flows to reach within 10% of their fair-share bandwidth Average delay experienced by the 5 Mb/s target CBR flow Maximum delay experienced by the 5 Mb/s target CBR flow Time taken for 5 Mb/s target flow to reach within 10% of its fair-share bandwidth xii

14 Acknowledgments First, I would like to acknowledge my advisor, Prof. Jonathan Turner for his extraordinary guidance and patience which enabled me to achieve this goal. I would also like to thank Dr. Guru Parulkar, who was my advisor during my undergraduate years and my initial thesis advisor and has been gracious enough to be on my D.Sc. committee. He was instrumental in guiding me during the earlier years and his encouragement and help have gone a long way towards my success. I also thank the rest of my committee for their help and insight in my research. Finally, I would like to thank my parents and my wife for their undying support, encouragement, love and patience that propelled me to this goal. I also thank all my friends and colleagues in the department who made my life so much more interesting and enjoyable during my tenure here as a graduate student! Washington University in Saint Louis May 2005 Anshul Kantawala xiii

15 1 Chapter 1 Introduction Given the current explosive growth of the Internet, one of the main challenges is to improve performance of data transport in the Internet in the presence of both transient and sustained congestion. The key issues pertaining to data transport performance in the Internet are: Ensuring goodput when bandwidth is limited. Minimizing queueing delay at a router without underutilizing the link. Providing a fair-share of the bandwidth resources amongst competing flows. Adapting to changing traffic behaviour and available bandwidth. Millions of flows may traverse an Internet router at any given time. If each source sent at its fair share, the router would not need extensive buffers or complex packet scheduling policies to manage the traffic. In practice, sources tend to be greedy, causing the load on the links to fluctuate. The traditional role of buffer space in an Internet router is to absorb the transient imbalances between offered load and capacity. Choosing the correct buffer size is something of an art: too small risks high loss rates during transient congestion and low utilization, too large risks long queueing delays. In this thesis, we concentrate on buffer management in the network data path for improving the data transport performance. The first part of this work proposes buffer management algorithms that can provide high throughput for TCP flows using very small buffers while providing a fair-share of the bandwidth resources to each flow regardless of differences in round-trip times and hop counts. The second part of this work proposes new methods for evaluating fair-queueing algorithms.

16 1.1 TCP Overview 2 Before we discuss the problems in further detail, we present a brief overview of the TCP protocol. TCP is a reliable transport protocol that operates on top of IP. Along with providing an acknowledgment (ACK) based reliable data transfer, it implements a window based congestion control algorithm. The subsections below provide a brief overview of the TCP protocol Reliability TCP provides reliability by doing the following: The application data is broken up into chunks called segments. The maximum sized segment (MSS) a TCP connection can send is negotiated during TCP connection setup. When TCP sends a segment it maintains a timer, waiting for the other end to acknowledge reception of the segment. If an acknowledgement is not received, the segment is retransmitted. When TCP receives a segment from the other end, it sends an acknowledgement (ACK). This ACK may be delayed for a fraction of a second in the hope that there is some data to send in the same direction as the ACK. This allows the receiver to piggyback the ACK with the data. TCP maintains an end-to-end checksum on its header and data in order to detect any modification of the data in transit. Since TCP segments are transmitted as IP datagrams, they can arrive out of order. A TCP receiver must resequence the data if necessary. A TCP receiver is also responsible for discarding duplicate segments. TCP also provides flow control. At connection set-up, each TCP receiver advertises a maximum window size it can handle. This window size corresponds to the amount of buffer space it has for the connection.

17 1.1.2 Congestion Control 3 In this section, we briefly present mechanisms used by TCP for congestion control. TCP congestion control consists of two main components: slow start and congestion avoidance. A TCP sender uses the size of the sending window to provide flow control as well as congestion control. Slow Start Slow start is a mechanism used by the TCP sender to gauge the amount of network bandwidth available for the connection. The TCP sender maintains a window, called the congestion window (cwnd), for slow start and other congestion control mechanisms. When a new connection is established, cwnd is initialized to one segment. Each time an ACK is received (for a packet of any size), cwnd is increased by one segment. Although cwnd is maintained in bytes, slow start always increments it by the segment size. The sender starts by transmitting one segment and waiting for its ACK. When the ACK is received, cwnd is incremented from one to two, and two segments can be sent. When both of those segments are acknowledged, cwnd is increased to four. Thus, slow start provides an exponential increase in the sending rate. At some point, the capacity of the connection path is reached and the intermediate router will start discarding packets. This tells the sender that the window has grown too large and the sender enters congestion avoidance. The sender can transmit up to the minimum of cwnd and the advertised window. Thus, cwnd serves as the sender imposed flow control while the advertised window is the receiver imposed flow control. Congestion Avoidance Slow start is used by TCP to initiate data flow in a connection. However, once the connection exceeds the capacity of an intervening router, there will be dropped packets. TCP uses a congestion avoidance algorithm to deal with lost packets. We briefly describe the congestion avoidance algorithm and point out the differences between TCP Tahoe and TCP Reno implementations. This algorithm is described in detail in [35]. Congestion avoidance and slow start require two variables to be maintained for each connection: a congestion window, cwnd, and a slow start threshold, ssthresh. The algorithm works as follows: Initially, cwnd is set to one segment and ssthresh to bytes.

18 4 Congestion is detected via a timeout or duplicate ACKs. Since TCP sends out a cumulative ACK for the segments received in order, if a packet is dropped by an intermediate router, packets following the dropped packet will cause the receiver to generate duplicate ACKs. When congestion is detected (either via a timeout or duplicate ACKs), ssthresh is set to one-half of the current window size (the minimum of cwnd and the receiver s advertised window). If congestion is detected due to duplicate ACKs, cwnd is set to ssthresh in TCP Reno and set to one segment (slow start) in TCP Tahoe. If congestion is detected via a timeout, cwnd is set to one segment (slow start) in both TCP Reno and TCP Tahoe. When new data is acknowledged, the sender increases cwnd, but the way it increases depends on whether the source is performing slow start or congestion avoidance. If cwnd is less than ssthresh, the source performs slow start, otherwise it does congestion avoidance. On entering slow start, the source sets cwnd to one segment and while in slow start, it increases cwnd by one segment every time an ACK is received. In congestion avoidance, the source increases cwnd by (MSS*MSS)/cwnd every time an ACK is received. Thus, cwnd will increase by at most one segment every round-trip time. This is an additive increase compared to slow start s exponential increase. If three or more duplicate ACKs are received in a row, the sender concludes that there was a packet loss and immediately retransmits what appears to be the missing segment without waiting for a timeout. This is called the fast retransmit algorithm. The retransmission is followed by slow start in TCP Tahoe and congestion avoidance TCP Reno (this is referred to as the fast recovery feature of TCP Reno). The fast recovery algorithm is briefly outlined below: 1. When the third duplicate ACK is received, ssthresh is set to one-half the current value of cwnd. The missing segment is retransmitted and cwnd is set to ssthresh plus 3 times the segment size. 2. Each time another duplicate ACK is received, cwnd is incremented by one segment and a new packet is transmitted if allowed by the new value of cwnd. 3. When the next ACK arrives acknowledging new data, cwnd is set to ssthresh and the sender enters congestion avoidance as described above.

19 1.2 High queueing delay due to large buffers 5 Routers today primarily use First-In-First-Out (FIFO) queues with a Tail Drop packet drop policy. A Tail Drop policy means that when the queue is full, a new incoming packet is dropped on arrival. With such a drop policy, TCP flows tend to get synchronized during congestion and need a buffer size comparable to the link bandwidth-delay product to ensure high throughput and minimize the chance of underutilization. Thus, backbone routers in the Internet are typically configured with buffers that are several times larger than the product of the link bandwidth and the typical round-trip delay on long network paths. Such buffers can delay packets for as much as half a second during congestion periods. When such large queues carry heavy traffic loads, and are serviced using the Tail Drop policy, the large queues remain close to full much of the time. Thus, even if each flow is able to obtain its share of the link bandwidth, the end-to-end delay remains very high. This is exacerbated for flows with multiple hops, since packets may experience high queueing delays at each hop. This phenomenon is well-known and has been discussed by Hashem [34] and Morris [51], among others. This prevents us from realizing one of the key benefits of high bandwidth links, which is lower queueing delays. To address this issue, researchers have developed alternative queueing algorithms which try to keep average queue sizes low, while still providing high throughput and link utilization. The most popular of these is Random Early Discard or RED [30]. RED maintains an exponentially-weighted moving average of the queue length which is used to detect congestion. When the average crosses a minimum threshold ( ), packets are randomly dropped or marked with an explicit congestion notification (ECN) bit. When the queue length exceeds the maximum threshold ( ), all packets are dropped or marked. RED includes several parameters which must be carefully selected to get good performance. To make it operate robustly under widely varying conditions, one must either dynamically adjust the parameters or operate using relatively large buffer sizes [23, 64]. Another queueing algorithm called Blue [27], was proposed to improve upon RED. Blue adjusts its parameters automatically in response to queue overflow and underflow events. When the buffer overflows, the packet dropping probability is increased by a fixed increment ( ) and when the buffer empties (underflows), the dropping probability is decreased by a fixed increment ( ). The update frequency is limited by a freeze time parameter. Incoming packets are then randomly dropped or marked with an ECN bit. Although Blue does improve over RED in certain scenarios, its parameters are also sensitive to different congestion conditions and network topologies.

20 6 Although RED and Blue try to alleviate the synchronization problem by using a random drop policy, they do not perform well with buffers that are smaller than the bandwidthdelay product. When buffers are very small, even with a random drop policy, there is a high probability that all flows suffer a packet loss. 1.3 Unfairness due to differences in round-trip times Since TCP uses a window-based flow and congestion control algorithm, whereby each flow can only have a window-size number of outstanding bytes, flows with larger window sizes achieve higher throughput. Also, this window size is incremented when packets are successfully acknowledged. Thus, flows with a shorter round-trip time (RTT) can increase their window size faster and thus achieve a higher throughput compared to flows with a longer RTT which are sharing the same bottleneck link. Current buffer management policies such as Tail Discard, RED and Blue use random dropping and thus cannot differentiate flows based on their RTTs. This leads to shorter RTT flows grabbing an unfair share of the bottleneck bandwidth. To tackle the above issues, we investigate queueing algorithms that use multiple queues, to isolate flows from one another. While algorithms using multiple queues have historically been considered too complex, continuing advances in technology have made the incremental cost negligible, and well worth the investment if these methods can reduce the required buffer sizes and resulting packet delays. We show, using ns-2 simulations, that the proposed queueing algorithms represent major improvements over existing methods for both the issues described above. Although per-flow queueing helps in desynchronizing TCP flows and provides fairshare throughput to flows with different RTTs, it raises two new issues: 1. Scalability Per-flow queueing policies require a certain amount of memory to store queue pointers and flow filters. These fields are typically stored in SRAM, since the memory access speeds are critical for high performance routers. Although this memory may be small in comparison to the total buffer memory, there is some legitimate concern about the cost associated with using a large number of queues. 2. Memory bandwidth wastage Standard per-flow fair-queueing algorithms usually drop packets that have already been queued which can require significantly more memory bandwidth than policies

21 that drop packets on arrival. In high performance systems, memory bandwidth can become a key limiting factor Evaluating Fair Queueing Algorithms In the Internet, along with TCP flows, UDP flows also share the link bandwidth. These flows may be reserved flows for applications requiring some Quality of Service (QoS) or unreserved datagram traffic. There has been a lot of work recently developing workconserving fair-queueing (FQ) algorithms for reserved flows (UDP traffic). We would like to evaluate how our buffer management algorithms compare against other FQ algorithms. The usual evaluation method used for FQ algorithms is worst-case delay analysis. Although the analytical methods provide worst-case delay bounds, they tend to exaggerate the differences since they rely on precise timings of individual packet arrivals. Until now, there has not been a concerted effort to develop a simulation framework for evaluating different FQ algorithms over realistic network configurations and traffic patterns. In one previous study [37], the authors present a simulation study of hierarchical packet fair queueing algorithms. The simulation study bolsters our claim by showing that there is a significant gap between the worst delays obtained via simulation for non-wf Q and what we would expect from the analytical bounds. Although this study is a step in the right direction, the simulation scenarios are fairly limited and concentrate only on the delay metric. We propose to pursue a more systematic and complete study of different metrics for evaluating FQ algorithms. The rest of the thesis is organized as follows. Chapter 2 illustrates the interaction between TCP flow control and the Tail Discard dropping policy. We present an approximate analysis of the queueing behaviour for a congested bottleneck-link buffer with TCP-like flows. We also describe the effect of different RTTs on a TCP flow s congestion window size and its throughput. Chapter 3 discusses the per-flow queueing algorithms we propose for improving performance over a congested link along with simulation results. Chapter 4 presents a detailed study of QSDRR s properties and experimental results. In Chapter 5, we discuss scalability issues and present an architecture for distributing flows among queues using Bloom filters. Chapter 6 presents algorithms for intelligent packet discard on arrival to minimize excess memory bandwidth usage. Chapter 7 outlines the current issues with evaluating fair-queueing algorithms and presents results derived from a new set of simulation configurations. Chapter 8 presents a brief summary of related work and Chapter 9 has the conclusions and future work.

22 8 Chapter 2 Interaction of TCP and Router Buffer Management 2.1 TCP Flow Control and Tail Discard When a congested link drops packets, TCP flow control reacts by cutting its congestion window size in half. For congested links using a Tail Drop packet drop policy, what we observe is that TCP sources tend to get synchronized and the buffer occupancy exhibits a high degree of oscillation. This happens due to the TCP sources cutting their congestion window to half at the same time due to near simultaneous packet drops, caused by the full buffer. Figure 2.1 illustrates the buffer occupancy oscillation for TCP flows with a Tail Drop packet discard policy. For additional insight into this issue, we present an analysis of a simplified protocol similar to TCP in its congestion control behaviour in the following section Simple Buffer Analysis for TCP-like Flows In this section, we present a simplified analysis of buffer occupancy of a congested bottleneck link using the Tail Drop packet discard policy in the presence of a large number of TCP Reno flows. The motivation for this analysis is not to provide a precise model for TCP, but to help develop some elementary insights into its behaviour. This insight is useful in understanding the much more detailed simulation results presented in later sections. The assumptions we make for the analysis are: The analysis is a discrete time analysis considering one RTT as a unit.

23 Queue Level (pkts) Time (s) Figure 2.1: Bottleneck queue behaviour for Tail Discard with buffer size 4167 packets (round-trip delay times bandwidth) Table 2.1: Definitions of terms used in analysis Number of sources Link rate in packets/second Buffer size Round-trip time when queue is empty Round-trip time when queue level is Fair-share window-size for each TCP flow when queue is empty Fair-share window-size for each TCP flow when queue is full Probability that a source experiences a packet drop in RTT when buffer becomes full The Tail drop policy is used in the bottleneck link buffer. All TCP flows are in congestion avoidance mode. All packet drops are indicated by duplicate ACKs. All TCP flows are synchronized initially (i.e. they have the same cwnd value) at the time of buffer overflow. In each RTT period, we assume a fluid model for the TCP data traffic. During each RTT period, all TCP flows transmit their entire cwnd and receive ACKs for all successfully received packets.

24 10 Table 2.1 describes the notation we use in the analysis. We present an approximate calculation of the drop in queue level after a buffer overflow and the time between consecutive buffer overflow events. We note that given our assumptions, the queue overflows when each source sends packets (i.e. cwnd for each source is ). From our assumptions, we have: (2.1) (2.2) (2.3) (2.4) In the first RTT after overflow, let the expected number of sources experiencing a packet drop equal. We expect to be between 1/2 and 1. For these sources, the new value of cwnd is equal to, since these sources experience a drop and will reduce their cwnd by half. For sources, the new value of cwnd is equal to, since these sources do not experience any drops and thus will increase their cwnd by one each RTT. Now, in this RTT, the number of packets drained from the buffer is and the number of packets sent by the sources is level after first RTT is: Since, we can substitute!. Hence, queue (2.5) " # for $ giving (2.6)

25 In the second RTT after overflow, the number of packets drained from the buffer is and the number of packets sent by the sources is. Hence, the queue level after the second RTT is: 11! (2.7) Note that! (2.8) Substituting Equation 2.8 into Equation 2.7 we get, (2.9) From the second RTT onward, each RTT, the queue level increases by packets until the queue is full. Thus, the total number of steps (RTTs) from the second RTT until the queue is full again is given by: (2.10) (2.11) The time taken for the first step (RTT) = and for the second step = After the second RTT, for each step, the RTT increases by a fixed constant =. Also, the time for the last step (RTT) =. Thus, the average time for each step from the second RTT to the last = The total time taken from the time the queue overflows to the next time the queue is full is:. "! $# %! '& (! (2.12)

26 The main thing to take away from this analysis is that the time between the periods when the buffer overflows is roughly proportional to the product of and when is not too small and is between 1/2 and S1 D1 10 Mb/s S2 R Mb/s 50ms R 2 D2 0.5ms S100 D100 Figure 2.2: Single Bottleneck Link Network Configuration To verify the accuracy of our analysis, we compare the evolution of the bottlenecklink queue occupancy using our analytical model against ns-2 simulations. The configuration used for the simulation is shown in Figure 2.2. Figure 2.3 shows the queue occupancy curves as predicted by the analytical model compared with actual levels obtained using two ns-2 simulation models. Figure 2.3(a) shows the queue occupancy curves for 100 TCP Reno sources and Figure 2.3(b) shows the queue occupancy curves for 200 TCP Reno sources. As we would intuitively expect, when we increase the number of sources, the buffer fills up faster, and thus we have a shorter time period for each cycle. One of our analytical model assumptions is that all packet losses are detected via duplicate ACKs and the TCP source enters fast recovery mode after retransmission of the packet instead of slow start. To try and simulate this behaviour, we changed the TCP Reno implementation in ns-2 to enter fast recovery mode even after a timeout. The curve labeled Simulation (dup. only) represents a simulation run using such modified TCP Reno sources. The curve labeled Simulation (std.) represents the queue occupancy curve obtained from a simulation using regular TCP Reno sources. From Figure 2.3 we conclude that although our analytical model does not exactly match the simulation results, it captures the first-order behaviour of the system and its relative simplicity provides useful insight into the behaviour of real TCP implementations. In particular, it clarifies what factors would improve performance by reducing the drops in queue occupancy after packet drops and reducing total queue cycle times. One of the reasons for the discrepancy between our model and the simulation results is due to timeouts. Although we modified the TCP Reno sources to enter fast recovery after a timeout, the time

27 Maximum queue capacity Maximum queue capacity Queue Level (pkts) Queue Level (pkts) Analytical Simulation (std.) 1000 Analytical Simulation (std.) Simulation (dup. only) Time (s) Simulation (dup. only) Time (s) (a) 100 TCP flows (b) 200 TCP flows Figure 2.3: Comparison of analytical queueing behaviour with simulation results taken by the source to react to (detect) a packet loss is much longer than one RTT, since a TCP timeout is usually two or three times the actual RTT value. During the RTT periods that sources are waiting for a timeout, they do not transmit any packets. However, in our analytical model, we assume that every source will react to a packet loss within one RTT and continue to send packets. Thus, the curves obtained via simulation show a slightly higher drop in queue occupancy after packet drops. Also, given that the queues level drops further, the time taken for the queue to fill up again is longer thus causing the analytical curves to complete each cycle in less time than the simulation Maximum Queue Capacity Analytical Simulation (std.) Queue Level (pkts) Simulation (dup. only) TIme (s) Figure 2.4: Comparison of analytical queueing behaviour with simulation results when queue underflows

28 Table 2.2: Comparing queue drop and cycle time obtained using the analytical model vs. simulation data Buffer Size Analysis Simulation Queue Drop (pkts) Cycle time (s) Queue Drop (pkts) Cycle time (s) Figure 2.4 shows the queue occupancy curves for 100 TCP Reno sources with a maximum buffer size of 800 packets. This graph illustrates that our analytical model is also able to handle scenarios when the buffer size is small and the queue underflows. Finally, Table 2.2 compares the queue drop and total cycle ( ) values obtained using the analytical model and the simulation (dup. only) for different buffer sizes. For our analytical model numbers, we chose to be 0.7. When TCP sources are synchronized, the probability that a source will experience a packet drop can be approximated by even for fairly small values of. Although, in practice, all TCP sources do not remain synchronized every RTT period, we found that this value of provides a good approximation in our analysis. Overall, we emphasize that the exercise of developing the rudimentary analytical model was to get a handle on what parameters predominantly affect length of the period of buffer oscillation. The simulation comparison was done only to judge the rough accuracy of our model and observe that the slopes obtained via the analytical model matched the slopes obtained via simulation. From our analytical model, we observe that (the fair-share window size of each TCP flow when the buffer is full) is a predominant factor determining the length of the period of buffer oscillation. Thus, if we have very small TCP flows (fairshare window size less than 5), the oscillation periods will be smaller RED To address the issue of TCP flow synchronization due to Tail Drop packet discard policies, researchers have developed alternative queueing algorithms which try to keep average queue sizes low, while still providing high throughput and link utilization. The most popular of these is Random Early Discard or RED [30]. RED maintains an exponentiallyweighted moving average of the queue length which is used to detect congestion. When the average crosses a minimum threshold ( ), packets are randomly dropped or marked

29 15 with an explicit congestion notification (ECN) bit. When the queue length exceeds the maximum threshold ( ), all packets are dropped or marked. RED includes several parameters which must be carefully selected to get good performance. To make it operate robustly under widely varying conditions, one must either dynamically adjust the parameters or operate using relatively large buffer sizes [23, 64] Queue Level (pkts) Queue Level (pkts) Time (s) Time (s) (a) Drop Prob. = 0.05 (b) Drop Prob. = Queue Level (pkts) Time (s) (c) Drop Prob. = 0.01 Figure 2.5: Buffer Occupancy Time History for RED with changing Drop Probability Figure 2.5 further illustrates this issue by showing the effect of different packet drop probabilities used for RED on buffer occupancy over a single bottleneck link. The minimum and maximum thresholds were fixed at 400 and 800 packets respectively for

30 16 the simulation runs. Table 2.3 shows how the parameter settings for RED affect average throughputs achieved by TCP flows. As expected from the buffer occupancy graphs, as we reduce the dropping probability, the average throughput increases. Table 2.3: Throughput variations when changing RED s dropping probability RED Drop Probability Mean Throughput (Mb/s) TCP Fairness and Round-Trip Times (RTT) Given TCP s window-based flow and congestion control algorithms, flows with a shorter RTT will be able to increase their congestion windows faster and thus are able to grab an unfair share of the bottleneck bandwidth. Also, flows with a longer RTT need a larger window size to achieve comparable throughput to flows with a short RTT. This is due to the fact that a TCP connection can only have a window s worth of bytes in transit at any time. Thus, the maximum throughput a flow can achieve is its window size divided by the RTT. Figure 2.6 illustrates the dynamic behaviour of the congestion window sizes of two sets of TCP flows using the Tail Discard packet drop policy. The short RTT flows have a RTT of 40 ms (in the absence of queueing delays), while the long RTT flows have a RTT of 200 ms. The buffer size of 4167 packets is equal to the bandwidth-delay product for a flow with an RTT of 100 ms. To achieve ideal fairness, the long RTT flows should have a congestion window size of about 5 times that of the short RTT flows. With the Tail Discard packet drop policy, all incoming packets are dropped at random when the buffer overflows, thus affecting both short and long RTT flows equally. This effect is somewhat offset for long RTT flows by the fact that since they take longer to recover after packet drops, during subsequent overflow periods, the short RTT flows will have a greater proportion of packets and hence a higher probability of getting dropped. From Figure 2.6(a), we observe that for small buffers, the congestion window sizes for the 200 ms RTT flows are only about one and a half times that of the 40 ms RTT flows. Thus, the 40 ms RTT flows can achieve more than 2 times the throughput compared to the 200 ms RTT flows. For the larger buffer size, Figure 2.6(c), Tail discard does allow the 200 ms RTT flows to reach a larger window size,

31 17 Queue Level (pkts) Time (s) Average Congestion Window Size (pkts) ms RTT flows 200 ms RTT flows Time (s) (a) Buffer Occupancy (Max = 800) (b) Congestion Window (Max = 800) 5000 Queue Level (pkts) Average Congestion Window Size (pkts) ms RTT flows 40 ms RTT flows Time (s) Time (s) (c) Buffer Occupancy (Max = 4167) (d) Congestion Window (Max = 4167) Figure 2.6: Average TCP Congestion Window Sizes for TCP sources with different RTT using Tail Discard but it is only thrice that of the 40 ms RTT flows. Thus, the 40 ms RTT flows will still get higher throughput compared to the 200 ms RTT flows. Figure 2.7 illustrates the dynamic behaviour of the congestion window sizes of two sets of TCP flows using RED. We observe that the congestion window sizes of both the 40 ms RTT and 200 ms RTT flows are approximately equal for small and large buffer sizes. Thus, 40 ms RTT flows can achieve about 5 times the throughput of the 200 ms RTT flows. This shows that RED s discarding policy is unfair to higher RTT flows regardless of buffer size.

32 Queue Level (pkts) Time (s) Average Congestion Window Size (pkts) ms RTT flows 40 ms RTT flows Time (s) (a) Buffer Occupancy (Max = 800) (b) Congestion Window (Max = 800) Queue Level (pkts) Average Congestion Window Size (pkts) ms RTT flows 200 ms RTT flows Time (s) Time (s) (c) Buffer Occupancy (Max = 4167) (d) Congestion Window (Max = 4167) Figure 2.7: Average TCP Congestion Window Sizes for TCP sources with different RTT using RED Finally, Table 2.4 summarizes the throughputs achieved by the 40 ms RTT and 200 ms RTT flows under both Tail Discard and RED. As we observed with the congestion window size graphs, regardless of buffer size, RED discriminates against the higher RTT flows whereas Tail discard is less unfair to the longer RTT flows when buffer sizes are sufficiently large.

33 19 Table 2.4: Average Throughputs for 40 ms RTT and 200 ms RTT flows under Tail Discard and RED Buffer Size (pkts) Average Throughput Mb/s Tail Drop RED 40 ms RTT 200 ms RTT 40 ms RTT 200 ms RTT

34 20 Chapter 3 Per-Flow Queueing The results presented in this Chapter show that both RED and Blue are deficient in meeting the objectives of a packet scheduler as described in Chapter 1. Both perform fairly poorly when buffer space is limited to a small fraction of the round-trip delay. Although Blue is less sensitive to parameter choices than RED, it still exhibits significant parameter sensitivity. Both RED and Blue exhibit a fairly high variance among individual TCP flow goodputs even over a single-bottleneck link. The TCP analysis presented in Chapter 2 gives us valuable insight into the bottleneck queue behaviour. We notice that if more sources are synchronized ( is high), the drop in queue level ( ) will be higher and the cycle time ( ) will increase. In the algorithms presented below, we use multiple queues to explicitly control the number of flows that suffer a packet loss. This significantly reduces the synchronization among flows and allows us to get very good performance over buffers which are a fraction of the bandwidth-delay product. 3.1 Algorithms Given the problems with existing congestion buffer management algorithms, we decided to evaluate a fair queueing discipline for managing TCP flows. We started by using Deficit Round Robin (DRR) [59]. DRR is an approximate fair-queueing algorithm that requires only work to process a packet and thus it is simple enough to be implemented in hardware. Also, since there are no parameters to set or fine tune, it makes it usable across varying traffic patterns. We evaluated three different packet-discard policies. It is worth noting that although we have chosen DRR as the packet scheduler, our discard policies are not specific to DRR and can be used with other packet scheduling algorithms.