Adaptive Explicit Congestion Notification (AECN) for Heterogeneous Flows. Zici Zheng. A Thesis. Submitted to the Faculty. of the

Size: px
Start display at page:

Download "Adaptive Explicit Congestion Notification (AECN) for Heterogeneous Flows. Zici Zheng. A Thesis. Submitted to the Faculty. of the"

Transcription

1 Adaptive Explicit Congestion Notification (AECN) for Heterogeneous Flows by Zici Zheng A Thesis Submitted to the Faculty of the WORCESTER POLYTECHNIC INSTITUTE in partial fulfillment of the requirements for the Degree of Master of Science in Computer Science by May 2001 APPROVED: Dr. Robert Kinicki, Major Advisor Dr. Micha Hofri, Head of Department

2 ABSTRACT Previous research on ECN and RED usually considered only a limited traffic domain, focusing on networks with a small number of homogeneous flows. The behavior of RED and ECN congestion control mechanisms in TCP network with many competing heterogeneous flows in the bottleneck link, hasn t been sufficiently explored. This thesis first investigates the behavior and performance of RED with ECN congestion control mechanisms with many heterogeneous TCP Reno flows using the network simulation tool, ns-2. By comparing the simulated performance of RED and ECN routers, this study finds that ECN does provide better goodput and fairness than RED for heterogeneous flows. However, when the demand is held constant, the number of flows generating the demand has a negative effect on performance. Meanwhile, the simulations with many flows demonstrate that the bottleneck router's marking probability must be aggressively increased to provide good ECN performance. Based on these simulation results, an Adaptive ECN algorithm (AECN) was studied to further improve the goodput and fairness of ECN. AECN divides all flows competing for a bottleneck into three flow groups, and deploys a different max p for each flow group. Meanwhile, AECN also adjusts min th for the robust flow group and max th to get higher performance when the number of flows grows large. Furthermore, AECN uses markfront strategy, instead of mark-tail strategy in standard ECN. A series of AECN simulations were run in ns-2. The simulations show clearly that AECN treats each flow fairer than ECN with the two fairness measurements: Jain s fairness index and visual max-min fairness. AECN has fewer packet drops and alleviates the lockout phenomenon and yields higher goodput than ECN. Key words: ECN, RED, AECN, heterogeneous flows, fairness, goodput. i

3 ACKNOWLEDGEMENTS Throughout my graduate student career, I ve been fortunate enough to have the help and support from many people. I would especially like to thank: Professor Robert Kinicki, my research advisor, for giving me a chance to have an insight in his research field of network congestion control, and for his patience, advice and guidance for helping me finish this thesis in time in the past year. Professor Mark Claypool, my thesis reader, for his insightful comment and advice on this thesis, and for his nile server. Professor David Brown, and Ph. D. student Janet Burge, for their allowing me to use the equipments in AI lab, which enabled me to do a lot of experiments. cc (congestion control) group members for their many useful and insightful discussions about network congestion control mechnisms. Special thanks to Jae Chang for his technical and academic help. My friends here, Jun Chen, Luping Quan, and Yan Huang, Finally, I would most like to thank my parents, my grandmother, my sister and brothers in China for their continual encouragement, guidance and support. Specially, I d most like to thank my dear wife, Min Gao, for her generous and considerate support in the past two years. ii

4 TABLE OF CONTENTS ABSTRACT... i ACKNOWLEDGEMENTS... ii LIST OF TABLES... vi LIST OF FIGURES... vii Chapter 1 Introduction Motivation and Goal Structure of Thesis... 3 Chapter 2 Background and Related Work Background TCP Congestion Control Mechanisms End-to-end Congestion Control Issues TCP Built-in Techniques TCP Variants Active Queue Management RED and ECN RED ECN Changes at the router Changes at the router TCP Host side Related Work Chapter 3 Experimental Methodology The Selection of Measurement Criteria Throughput Goodput Fairness Delay Experimental Tools Network Simulator ns iii

5 Simulation Input Scripts Simulation Output Traces Data Extraction Tools Experimental Setup and Validations Chapter 4 Evaluation of ECN with Heterogeneous TCP Flows Introduction Definitions Robust, Average and Fragile flows ECNM Simulation Scenarios Simulation Result Analyses Throughput Goodput Delay Fairness Jain s Fairness Index Visual Max-min Fairness ECNM Conclusions Chapter 5 Adaptive ECN (AECN) for Heterogeneous TCP Flows Introduction The Basic Algorithm of AECN Assumptions Terminologies Flow Queue Unlockout Range Strategies Round Trip Time Strategy Marking Front Strategy Basic Algorithm Implementation in ns Simulation Scenarios Simulation Preliminaries Performance Comparison Between AECN and ECN The Selection of and AECN ECN AECN iv

6 ECN Performance Evaluation of AECN with = Goodput Throughput Fairness Delay AECN Refinements Population-balanced AECN (AECN2) Adjusting Min th (AECN3) Adjusting max th (AECN4) Conclusions Chapter 6 Conclusions and Future Work Conclusions Future Work Appendix A Code Added for Calculating Round-trip Time Appendix B Code Modified for Implementing Three Flow Queues Bibliography v

7 LIST OF TABLES Table 3.1 ns-2 output trace format Performance statistics between AECN and ECN.60 vi

8 LIST OF FIGURES Figure 2.1: An Example of How TCP Slow-start and Congestion Avoidance works... 8 Figure 2.2. Relationship between average queue size and packet marking/dropping probability Figure 2.3. IP Header Figure 2.4. TCP Header Figure 3.1 A sample of ns-2 output trace Figure 3.2 the Simulation Processes with ns Figure 3.3 ECN router queue distribution for 60 flows, Figure 3.4. Mean aggregate goodput forecn with 60 flows during each one second interval Figure 4.1 Simulation Topology Figure 4.2 Aggregate Throughput Distribution with the Number of flows Figure 4.3 ECN: Queue Length Distribution with Time Figure 4.4 RED: Queue Length Distribution with Time Figure 4.5 Aggregate Throughput Distribution with max p, Number of flows = Figure 4.6 Aggregate Throughput Distribution with max p, Number of flows = Figure 4.7 Aggregate Goodput Distribution with the Number of flows Figure 4.8 Aggregate Goodput Distribution with max p, Number of flows = Figure 4.9 Aggregate Goodput Distribution with max p, Number of flows = Figure 4.10 Delay Distribution among Each Flow group with the Number of flows Figure 4.11 Average Queue Size Distribution (30 flows) Figure 4.12 Average Queue Size Distribution (60 flows) Figure 4.13 Aggregate Jain s Fairness Index with the Number of flows Figure 4.14 ECN Marked packet Statistics, 120 flows, max p = Figure 4.15 RED Dropped packet Statistics, 120 flows, max p = Figure 4.16 Goodput Distribution among Each Flow Group with Time Figure 4.17 Goodput Distribution among Each Flow Group with Time Figure 4.18 Goodput Distribution among Each Flow Group with Time Figure 4.19 Throughput Distribution among Each Flow Group with Time Figure 4.20 Goodput Distribution with max p, Figure 5.1 The Relationship between Three Flow Queues and Router Queue Figure 5.2 Simulation Topology Figure 5.3 Jain s Fairness Index with the Number of Flows Figure 5.4 Goodput with the Number of Flows Figure 5.5 Goodput Distribution between ECN and RED, Figure 5.6 ECN Marked packet Statistics, 60 flows, max p = vii

9 Figure 5.7 ECN Dropped packet Statistics, 60 flows, max p = Figure 5.8 RED Dropped packet Statistics, 60 flows, max p = Figure 5.9 ECN dropped packet Statistics, 120 flows, max p = Figure 5.10 ECN marked packet statistics, 120 flows, max p = Figure 5.11 RED dropped packet statistics, 120 flows, max p = Figure 5.12 Throughput with the Number of Flows Figure 5.13 One-way Delay with the Number of Flows (max p =0.1) Figure 5.14 One-way Delay with the Number of Flows (max p =0.5) Figure 5.15 One-way Delay with the Number of Flows (max p =0.8) Figure 5.16.Jain s Fairness Index with, ( = ), Figure Goodput with, ( = ), Figure Jain s Fairness Index with, ( = ), Figure Goodput with, ( = ), Figure 5.20 Goodput with the number of flows, base-max p = Figure Goodput with the number of flows, base-max p = Figure 5.22 Throughput with the number of flows, base-max p = Figure 5.23 Throughput with the number of flows, base-max p = Figure 5.24 AECN marked packet Statistics, 60 flows, max p = Figure 5.25 AECN dropped packet Statistics, 60 flows, max p = Figure 5.26 AECN dropped packet Statistics, 120 flows, max p = Figure 5.27 AECN marked packet Statistics, 120 flows, max p = Figure 5.28 AECN Queue Length Change with Time, 120 flows, max p = Figure 5.29 Jain s Fairness Index with the number of flows, base-max p = Figure 5.30 Jain s Fairness Index with the number of flows, base-max p = Figure 5.31 One-way delay with the number of flows, base-max p = Figure 5.32 Jain s Fairness Index with different base-max p Figure 5.33 Jain s Fairness Index with different base-max p Figure 5.34, The relationship between marking probability and min th Figure 5.35 The Jain s fairness index with varied min th for robust flows Figure 5.36 Goodput with varied min th for robust flows Figure 5.37 The Jain s fairness index with varied min th for robust flows, Figure 5.38 Goodput with varied min th for robust flows Figure 5.39 Throughput with varied min th for robust flows Figure 5.40 Throughput with varied min th for robust flows Figure 5.41 Jain s fairness index with different max th viii

10 Figure Goodput of AECN4 with different max th, 60 flows Figure Goodput of AECN4 with varied max th, 120 flows Figure One-way delay of AECN4 with varied max th ix

11 Chapter 1 Introduction 1.1 Motivation and Goal TCP is the dominant transport protocol used in the Internet today [THO97]. While Internet traffic continues to grow, it becomes more challenging to provide good throughput to millions of Web customers. When a packet is dropped before it reaches the destination, all of the resources the packet consumes in the transmission will have been wasted. In extreme cases, this situation can lead to congestion collapse [JAC88]. In the past decade, TCP and its congestion control mechanisms have been used in controlling packet loss and preventing congestion collapse across the Internet. Several variants of TCP (Tahoe, Vegas, Reno and NewReno) [FLO96] have been developed to provide hostcentric mechanisms to combat high packet loss rates during heavy congestion periods. Traditionally, a router reacts to congestion by dropping a packet in the absence of buffer space. This is referred to as a TailDrop router. However, the resulting drop-tail behavior fails to provide adequate early congestion notification and produces bursts of packet drops that contribute to unfair service. Although TCP has built-in techniques (such as Fast Retransmit and Fast Recovery) to minimize the impact of losses from a throughput prospective, these mechanisms are not intended to help applications that are in fact sensitive to the delay or loss of one or more individual packets [STE97] [RAM99]. So, optimizing the congestion control mechanisms used in TCP has been the focus of numerous studies and undergone a number of enhancements. Active queue management has been proposed as a solution for preventing losses due to buffer overflow. The idea behind active queue management is to detect incipient congestion early and convey congestion notification to the end-hosts, allowing them to back off before queue overflows and packet-drop occurs. Random Early Detection (RED), an active queue management technique proposed by Sally Floyd and Van Jacobson [FLO93], maintains an exponentially weighted moving average of the queue length to detect congestion. When the average queue length exceeds a minimum threshold, packets are randomly dropped with a given probability. In the current Internet 1

12 environment RED is restricted to using packet drops as a mechanism for congestion indication. However, RED can instead mark a packet with an Explicit Congestion Notification (ECN) bit with a given probability when the average queue size is between minimum threshold and maximum threshold of the router queue. ECN is an end-to-end congestion avoidance mechanism proposed by Floyd and has already been incorporated into RFC2481 [RAM99]. A connection receiving congestion notification in the form of an ECN marking, cuts its congestion window and reduces the slow-start threshold [RAM99] [STE97] in half just as if it had detected a packet loss. The probability that a packet arriving at the RED queue is either dropped or marked depends on the average queue length, the time elapsed since the last packet was dropped, and an initial probability parameter value. When the average queue length exceeds a maximum threshold, all packets are dropped. Since the introduction of RED, many researchers have done investigations about the behaviors and performances of RED and ECN, and proposed a variety of enhancements and changes to router management to improve congestion control [RAG99] [FLO91] [AHM99] [FEN97]. But these previous researches usually considered only the following two cases separately: (1) the network with a small or medium number of competing TCP flows, (2) the network with homogeneous flows. The behavior of RED and ECN congestion control mechanisms in TCP network with many competing heterogeneous flows in the bottleneck link, hasn t been sufficiently explored. This is one of the motivations for this thesis. Hence, one goal of this thesis is to investigate the behavior and performance of RED with ECN congestion control mechanisms with many heterogeneous [1] TCP Reno flows using the network simulation tool, ns-2. By comparing the simulated performance of RED routers and ECN routers, this study finds that ECN does provide better goodput and fairness than RED for heterogeneous flows. When the demand is held constant, the number of flows generating the demand has a negative effect on performance. Meanwhile, the simulations with many flows demonstrate that the bottleneck router's marking probability must be aggressively increased to provide good ECN performance. [1] Heterogeneous flows differ only in their end-to-end round-trip times (RTTs) in this study. 2

13 Based on these simulation results, this study proposes an adaptive version of ECN to further improve for ECN on the goodput or throughput and fairness by properly adjusting the relevant ECN parameters. Thus, an adaptive version of ECN (AECN) is the other goal for this study. ECN parameters include maximum drop probability (max p ), maximum threshold (max th ) and minimum threshold (min th ) for the queue, the average queue size (avg), and the weighting factor for the average queue length computation (w q ). AECN divides all flows competing for a bottleneck into three flow groups, and deploys a different max p for each flow group so that a fragile flow can have higher chance to get a proper share of bandwidth when competing with a robust flow. AECN also adjusts min th for the robust flow group and max th to get higher performance when the total number of flows changes. Furthermore, AECN uses mark-front strategy, instead of mark-tail strategy used in standard ECN 1, to mark the first unmarked packet of a corresponding flow group in the router queue to reduce the queue delay and speed up the notification of congestion to a sender. The simulation results show that AECN achieves better goodput and fairness than standard ECN in the network with many heterogeneous flows. 1.2 Structure of Thesis This thesis is organized as follows. Chapter 2 presents the background of congestion control mechanisms in TCP/IP network and a summary of the related work in this area, and introduces the current implementation of ECN. Chapter 3 describes the simulation methods deployed in our experiments, including the performance metrics (goodput, throughput, fairness and delay) that are investigated in our study, simulation tool ns-2, which is widely used in the network research community, and experimental procedures. Chapter 4 explains our performance study of ECN and RED with heterogeneous TCP flows. The various simulation scenarios are investigated for comparing the performance of ECN and RED on the characteristics of goodput, throughput, fairness and delay. Based on these simulation results, in Chapter 5, this study develops an adaptive version of ECN 1 Standard ECN only marks an incoming packet probabilistically when the average queue size is between max th and min th. If the average queue size exceeds max th, all incoming packets will be dropped at the congested ECN route. 3

14 (AECN), and presents the basic algorithm of AECN based on standard ECN and the implementation in ns-2 and the ways for further refining AECN. The evaluation of the performance and behavior of AECN on the key performance indicator is also provided in this chapter. The conclusions of this thesis and the future work are presented in Chapter 6. Moreover, Appendix A and B present the code added for the implementation of AECN in ns-2. 4

15 Chapter 2 Background and Related Work This chapter gives an overview of the past and current work in congestion control and management mechanisms used in TCP/IP networks. Since the first congestion collapse episode in 1986, several variants of TCP (Tahoe, Vegas, Reno, NewReno, and SACK) have been developed and evaluated to provide host-centric mechanisms to combat high packet loss rates during heavy congestion periods. Meanwhile, researchers have proposed new congestion avoidance techniques for Internet routers. This chapter first presents the congestion control mechanisms, including the host-centric and router-centric, in TCP/IP networks, then describes the related work of current congestion control mechanisms, especially the active queue management algorithms, such as RED and ECN. 2.1 Background TCP Congestion Control Mechanisms End-to-end Congestion Control Issues The Internet protocol architecture is based on a connectionless end-to-end packet service using the IP protocol. The advantages of its connectionless design, flexibility and robustness, have already been amply demonstrated [FLO00a]. However, these advantages are not without cost. In fact, lack of attention to the dynamics of packet forwarding can result in severe degradation, which caused researchers to develop end-to-end congestion control concerning the following several issues. During the mid 1980s, the Internet meltdown phenomenon was first observed, which is also called congestion collapse [JAC88]. Originally, TCP included windowbased flow control mechanism as a means for the receiver to control the amount of data sent by a sender. The flow control mechanism was used to prevent overflow of the receiver s data buffer space available for the TCP connection. In 1986, in order to fix Internet meltdown, Jacobson developed the congestion avoidance mechanisms which are now required in TCP implementations. These mechanisms operate in the end-hosts to cause TCP connections to backoff during congestion. Those TCP flows are said to be 5

16 responsive to congestion signals (i.e., packet loss) from the network. It is these TCP congestion avoidance algorithms that are still being used to prevent the congestion collapse of today s Internet. In addition to the concern about congestion collapse, more concern has also been paid attention to fairness for best-effort traffic. Because TCP backs-off during congestion, a large number of TCP connections can share a single, congested link in such a way that bandwidth should be shared reasonably equitably among similarly situated flows. The issue of fairness among competing flows has become increasingly important for two main reasons. First, using window scaling, individual TCPs can use high bandwidth even over high propagation-delay paths. Second, with the growth of the Web, Internet users increasingly want high-bandwidth and low-delay communications, rather than the leisurely transfer of a long file in the background. The growth of best-effort traffic that doesn t use TCP underscores this concern about fairness between competing best-effort traffic in times of congestion. For the current Internet environment, where other best-effort traffic could compete in a FIFO queue with TCP traffic, the absence of fairness with TCP could lead to one flow starving out another flow in a time of high congestion. Besides the prevention of congestion collapse and concerns about fairness, a third reason for a flow to use end-to-end congestion control can be to optimize its own performance regarding throughput, delay, and loss. In an environment like the current best-effort Internet, concerns regarding congestion collapse and fairness with competing flows limit the range of congestion control behaviors available to a flow TCP Built-in Techniques Congestion can occur when data arrives on a big pipe (a fast LAN) and gets sent out a smaller pipe (a slower WAN). Congestion can also occur when multiple input streams arrive at a router whose output capacity is less than the sum of the inputs. Congestion avoidance is a way to deal with lost packets [JAC88]. There are two indications of packet loss: a timeout occurring and the receipt of duplicate ACKs. This section presents some of the particulars of TCP congestion control mechanisms: 6

17 i). Retransmit Timers The TCP sender sets a retransmit timer to determine when a packet has been dropped in the network. When the retransmit timer expires, the sender assumes that a packet has been lost, sets ssthresh to half of the current window (W), and goes into slowstart, retransmitting the lost packet. If the retransmit timer expires because no acknowledgement has been received for a retransmitted packet, the retransmit timer is also backed-off, that is, doubling the value of the next retransmit timeout interval. ii). Slow-start The TCP sender cannot open a new connection by sending a large burst of data (e.g., a receiver s advertised window) all at once. The TCP sender is limited by a small initial value for the congestion window (cwnd). During slow-start, the TCP sender increases cwnd by the number of ACKs received in a round-trip time. Slow-start ends when the sender s congestion window is greater than the slow-start threshold (ssthresh). iii). Congestion Avoidance When cwnd is less or equal to ssthresh, TCP is in slow-start; otherwise TCP is performing congestion avoidance. Slow-start continues until TCP is halfway to where it was when congestion loss occurred, and then congestion avoidance takes over. Slow-start opens the window exponentially and increases cwnd by the number of ACKs received in a round-trip time; while congestion avoidance dictates that cwnd be increased by at most one per round-trip time when an ACK is received. Figure 2.1 shows an example of how TCP slow-start and congestion avoidance works. iv). Fast Retransmit and Fast Recovery Since a TCP sender doesn t know whether a duplicate ACK is caused by a lost packet or just by a reordering of packets, it waits for three duplicate ACKs to be received. Once the sender receives three duplicate acknowledgements, TCP supposes that a packet has been lost. Then the sender retransmits the missing packet, without waiting for a retransmission timer to expire. Meanwhile, the sender sets ssthresh to half of the current window, reduces cwnd to at most half of the previous cwnd. After fast retransmit sends what appears to be the missing packet, congestion avoidance, but not slow-start is performed. This is fast recovery algorithm. It s an improvement that allows high throughput under moderate congestion. 7

18 sshresh cwnd 4 2 W/2 W 1 RTT RTT Time (RTTs) Figure 2.1: An Example of How TCP Slow-start and Congestion Avoidance works TCP Variants Early TCP implementations followed a go-back-n model using cumulative positive acknowledgement and requiring a retransmit timer expiration to resend data lost during transport [FLO00a]. These TCPs did little to minimize network congestion. Currently, there re several different TCP variants, which have the same specification but different implementations. These TCP variants are Tahoe, Reno, New Reno, SACK, and Vegas. The Tahoe TCP implementation added a number of new algorithms and refinements to earlier implementations. It includes slow-start, congestion avoidance and fast retransmit. The Reno TCP implementation retained the enhancements incorporated into Tahoe, but modified the Fast Retransmit operation to include Fast Recovery. Reno s Fast Recovery algorithm is optimized for the case when a single packet is dropped from a window of data. The Reno sender retransmits at most one dropped packet per round-trip time. Reno significantly improves upon the behavior of Tahoe TCP when a single packet is dropped from a window of data, but can suffer from performance problems when multiple packets are dropped from a window of data. The New-Reno TCP includes a small change to the Reno algorithm at the sender that eliminates Reno s wait for a retransmit timer when multiple packets are lost from a 8

19 window. When multiple packets are lost from a single window of data, New-Reno can recover without a retransmission timeout, retransmitting one lost packet per round-trip time until all of the lost packets from that window have been retransmitted. New-Reno remains in Fast Recovery until all of the data outstanding when Fast Recovery was initiated has been acknowledged. SACK TCP is another TCP variant [FLO96]. The main difference between the SACK TCP and the Reno TCP is in the behavior when multiple packets are dropped from one window of data. SACK augments TCP s cumulative acknowledge mechanism with additional information that allows the receiver to inform the sender which packets have been missed. By specifying this information, the TCP sender can make more intelligent decision in determining when packets have been lost and in identifying which packets should be retransmitted. The TCP Vegas [BRA94] [BRA95], proposed by Peterson, L., uses source-based anticipation of congestion by monitoring gap between expected and actual (i.e., measured) throughputs to improve TCP congestion control. It s reported that it gives better 40-70% throughput than Reno Active Queue Management The traditional technique for managing router queue length is to set a maximum length (in terms of packets) for each queue, accept packets for the queue until the maximum length is reached, then drop subsequent incoming packets until the queue decreases because a packet from the queue has been transmitted. This technique is known as TailDrop. This method has served the Internet well for many years, but it has two serious drawbacks: 1. Lockout In some situations TailDrop allows a single connection or a few flows to monopolize queue space, preventing other connections from getting room in the queue. This lockout phenomenon [BRA98] is often the result of synchronization or other timing effects. 2. Global Synchronization 9

20 The TailDrop discipline allows queues to maintain a full (or, almost full) status for long periods of time, since it signals congestion only when the queue has become full. It is important to reduce the steady-state queue size, and this is perhaps the queue management s most important goal. The naïve assumption might be that there is a simple tradeoff between delay and throughput, and that the recommendation that queues be maintained in a non-full state essentially translate to a recommendation that low end-to-end delay is more important than high throughput. However, this does not take into account the critical role that packet bursts occurs in the Internet. Even though TCP constrains a flow s window size, packets often arrive at routers in bursts. If the queue is full or almost full, an arriving burst will cause multiple packets to be dropped. This can result in a global synchronization of flows throttling back, followed by a sustained period of lowered link utilization, reducing overall throughput. Queue limits should not reflect the steady state queue we want to maintain in the network; instead, they should reflect the size of bursts we need to absorb. In the current Internet, dropped packets serve as a critical mechanism of congestion notification to end nodes. The solution to the global synchronization is for routers to respond to congestion before their buffers overflow, that is, to employ active queue management, like Random Early Detection (RED) [FLO93] and Explicit Congestion Notification (ECN) [FLO94] [RAM99]. By dropping packets before buffers overflow, active queue management allows routers to control when and how many packets to drop RED and ECN RED RED is a congestion avoidance mechanism implemented in routers that work on the basis of active queue management. RED addresses the shortcomings of TailDrop. In contrast to traditional queue management algorithms, which drop packets only when the buffer is full, a RED router signals incipient congestion to TCP by dropping packets probabilistically before the queue runs out of buffer space. This drop probability is dependent on an average queue size to avoid any bias against bursty traffic. A RED 10

21 router randomly drops arriving packets, with the result that the probability of dropping a packet belonging to a particular flow is approximately proportional to the flow's share of bandwidth. Thus, if the sender is using relatively more bandwidth, it gets more of its packets dropped. The RED algorithm itself consists of two main parts: estimation of the average queue size (avg) and the decision of whether or not to drop an incoming packet. 1. Estimation of Average Queue Size RED estimates the average queue size, either in the forwarding path using a simple exponentially weighted moving average queue length computation (w q ). 2. Packet Drop Decision RED decides whether or not to drop an incoming packet (See Figure 2.2). It s RED s particular algorithm for dropping that results in performance improvement for responsive flows. Two RED parameters, min th and max th, represent thresholds set by RED when to drop a packet. Min th specifies the average queue size below which no packets will be dropped, while max th specifies the average queue size above which all packets will be dropped deterministically (100%). As the average queue size varies from min th to max th, packets will be dropped with a probability pa that varies linearly from 0 to max p, where pa is a function of the average queue size. As the average queue length varies between min th and max th, pa increases linearly towards a configured maximum drop probability, max p Mbps Drop/Mark 1 max p Probability 0 Dropping/marking probability min th max th Average Queue Size (avg) Physical queue length Figure 2.2. Relationship between average queue size and packet marking/dropping probability 11

22 Dropping packets in this way ensures that when some subset of the source TCP packets get dropped and they invoke congestion avoidance algorithms that will ease the congestion at the router. Since the dropping is distributed across flows, the problem of global synchronization is avoided ECN ECN is an extension to RED [RAM99][RAM01]. It provides a light-weight mechanism for routers to send a direct indication of congestion to the source. When avg is between min th and max th, ECN marks, instead of dropping, an incoming packet probabilistically. The marking probability in ECN varies as RED. A connection receiving congestion notification in the form of an ECN marking, cuts its congestion window in half just as if it had detected a packet loss. When avg is above or equal to max th, ECN also drops deterministically all incoming packets. Since ECN marks packets before congestion actually occurs, this is useful for protocols like TCP that are sensitive to even a single packet loss. Upon receipt of a congestion marked packet, the TCP receiver informs the sender (in the subsequent ACK) about incipient congestion which will in turn trigger the congestion avoidance algorithm at the sender. ECN requires support from both the router as well as the end hosts, i.e. the end hosts TCP stack needs to be modified. Packets from flows that are not ECN capable will continue to be dropped by RED. There are two main changes that need to be made to add ECN to TCP to an end system and one extension to a router running RED Changes at the router Router side support for ECN can be added by modifying current RED implementations. For packets from ECN capable hosts, the router marks the packets rather than dropping them (if the average queue size is between min th and max th ). It is necessary that the router identifies that a packet is ECN capable, and should only mark packets that are from ECN capable hosts. This uses two bits in the IP header. The ECN Capable Transport (ECT) bit is set by the sender end system if both the end systems are ECN capable (for a unicast transport, only if both end systems are ECN-capable). In TCP 12

23 this is confirmed in the pre-negotiation during the connection setup phase. Packets encountering congestion are marked by the router using the Congestion Experienced (CE) (if the average queue size is between min th and max th ) on their way to the receiver end system (from the sender end system), with a probability proportional to the average queue size following the procedure used in RED routers. Bits 10 and 11 in the IPV6 header are proposed respectively for the ECT and CE bits. Bits 6 and 7 of the IPV4 header DSCP field (Figure 2.3) are also specified for experimental purposes for the ECT and CE bits respectively. 4-bit version 4-bit header length DSCP field 16-bit identification E C T C E 3-bit flags 16-bit total length (in bytes) 13-bit fragment offset 8-bit time to live 8-bit protocol 16-bit header checksum 32-bit source IP address 32-bit destination IP address Figure 2.3. IP Header Changes at the router TCP Host side The proposal to add ECN to TCP specifies two new flags in the reserved field (Figure 2.4) of the TCP header. Bit 9 in the reserved field of the TCP header is designated as the 16-bit source port number 16-bit destination port number 32-bit sequence number 32-bit acknowledgement number 4-bit header length reserved field C W R E C E U R G A C K P S H R S T S Y N F I N 16-bit window size 16-bit TCP checksum 16-bit urgent pointer Figure 2.4. TCP Header 13

24 ECN-Echo (ECE) flag and Bit 8 is designated as the Congestion Window Reduced (CWR) flag. These two bits are used both for the initializing phase in which the sender and the receiver negotiate the capability and the desire to use ECN, as well as for the subsequent actions to be taken in case there is congestion experienced in the network during the established state. 1. TCP handshake phase The source and destination TCP have to exchange information about their desire and/or capability to use ECN. This is done by setting both the ECN-Echo flag and the CWR flag in the SYN packet of the initial connection phase by the sender; on receipt of this SYN packet, the receiver will set the ECN-Echo flag in the SYN-ACK response. Once this agreement has been reached, the sender will thereon set the ECT bit in the IP header of data packets for that flow, to indicate to the network that it is capable and willing to participate in ECN. The ECT bit is set on all packets other than pure ACK's. 2. Packet marking phase When a router has decided from its active queue management mechanism, to drop or mark a packet, it checks the IP-ECT bit in the packet header. It sets the CE bit in the IP header if the IP-ECT bit is set. When such a packet reaches the receiver, the receiver responds by setting the ECN-Echo flag (in the TCP header) in the next outgoing ACK for the flow. The receiver will continue to do this in subsequent ACKs until it receives from the sender an indication that it (the sender) has responded to the congestion notification. 3. ACK receipt phase Upon receipt of this ACK, the sender triggers its congestion avoidance algorithm by halving its congestion window, cwnd, and updating its congestion window threshold value ssthresh. Once it has taken these appropriate steps, the sender sets the CWR bit on the next outgoing data packet to tell the receiver that it has reacted to the receiver's notification of congestion. The receiver reacts to the CWR by halting the sending of the congestion notifications (ECE) to the sender if there is no new congestion in the network. Note that the sender reaction to the indication of congestion in the network (when it receives an ACK packet that has the ECN-Echo flag set) is equivalent to the Fast Retransmit/Recovery algorithm (when there is a congestion loss) in NON-ECN- 14

25 capable TCP, i.e. the sender halves the congestion window cwnd and reduces the slow start threshold ssthresh. Fast Retransmit/Recovery is still available for ECN capable stacks for responding to three duplicate acknowledgments. 2.2 Related Work In [FLO93], Sally Floyd and Van Jacobson introduce RED for congestion avoidance in packet-switched networks. Their simulations show that the RED gateway has no bias against bursty traffic and avoids the global synchronization of many connections decreasing their window at the same time. During congestion, the probability that the router notifies a particular connection to reduce its window is roughly proportional to that connection s share of the bandwidth through the router. [FLO94] proposes the new guidelines for TCP s response to ECN mechanism, and explores the benefits and drawbacks of ECN in TCP/IP network. By simulations, Floyd shows that one of advantages of ECN is that it can avoid unnecessary packet drops, which avoids unnecessary delay for packets from low-bandwidth delay-sensitive TCP congestions. [FLO98a] presents the implementation and validation of ECN in the famous network simulator: ns. [RAM99], [RAM01] and [FLO00c] further present their proposal on the guideline for ECN implementation in TCP/IP networks. [FLO97] discusses the rules-of-thumb values for the RED parameters. Uvaiz Ahmed and Jamal H. Salim [AHM99] have further shown that ECN enhancements on active congestion management improve both bulk and transactional TCP traffic over Reno TCP with one router. Compared with RED, ECN is fairer. The improvement is more obvious in short transaction types of flows because of two factors: (1) Fewer retransmissions occur with ECN, which means that less traffic is in the network, (2) ECN avoids timeouts by getting faster notification, which implies less time is spent during error recovery. In the experiments, they used a few homogeneous flows with one congested router in their testbed. [QIU99] addresses a phenomenon they observed in TCP/IP networks when the number of connections competing for the same bottleneck router becomes large, TCP s ability to share the bottleneck fairly and efficiently decreases. Their analysis of packet traces suggests that the degradation of TCP is substantially due to the total loss rate 15

26 observed in the Internet. This happens when many competing flows cause a higher loss rate in a bottleneck router. [GER99] finds by the simulations that the very pronounced unfairness trend is typical of the behavior of many flows. ECN works properly when the ECN router queue can hold several packets per flow. However, ECN also becomes grossly unfair when the queue size is not large enough. Even some of the connections never get a chance to transmit, which is the so-called lockout phenomenon. [FLO91] discusses the bias in TCP/IP networks against connections with multiple congested routers and the bias of the TailDrop and Random Drop routers against bursty traffic. Using simulations and a heuristic analysis, Floyd shows that in a network with TailDrop routers a longer connection with multiple congested routers can receive unacceptably low throughput, while in a network with no bias against connections with longer roundtrip times and with no bias against bursty traffic, a connection with multiple congested routers can receive an acceptable level of throughput. A longer connection is disproportionately likely to have packets dropped at the router. She also points out that although using different measures of fairness have quite different implications, there s still no generally-agreed-upon definition for fairness in a computer network. Recently, a number of research efforts have focused on possible shortcomings of the algorithms in RED and have proposed modifications and alternatives, e.g., BLUE [FEN99b], and SRED [OTT99]. Feng et al. [FEN97][FEN99a] found that one of the inherent weaknesses of RED and other proposed active queue management schemes is that the effectiveness of RED depends, to a large extent, on the appropriate parameterization of the RED queue. For example, as the number of connections becomes large, the impact of individual congestion notification decreases. Without modifying the RED algorithm to be more aggressive, the RED queue degenerates into a simple DropTail queue. On the other hand, as the number of connections becomes small, the impact of individual congestion notifications increases. In this case, without modifying the RED algorithm to be less aggressive, under-utilization can occur as too many sources back off their sending rates in response to the congestion notification. By the simulation experiments with 8, 32 and 64 homogeneous flows respectively and by the deployment of various values of max p, they showed that when the number of flows increases, RED doesn t deliver congestion notification to a sufficient number of sources. Thus, the RED 16

27 queue continually overflows causing it to behave more like a drop-tail queue. To overcome these shortcomings of RED, [FEN97] and [FEN99a] presents that adjusting RED parameters properly could effectively reduce packet loss while maintaining high link utilization under a range of network load. In [FEN99b], there are set of results from simulations of RED with ECN enabled in both routers and end-host TCP implementation. Their simulations focused primarily on the effects of the parameter w q used to smooth measurements of the average queue size. Some of these simulations use a large number of flows (1,000 4,000) that generate traffic with Pareto on/off periods. Unfortunately, they only simulated with homogeneous flows. In [CHR00], Christiansen, et al evaluate RED across a range of parameter settings and offered loads. Their results show that RED has a minimal effect on HTTP response times for offered load up to 90% of link capacity, and response times at loads in this range are not substantially effected by RED parameters, while in heavily congested network with 90%-100% load, RED parameters that provide the best link utilization produce poorer response time. They also find that except for min th, which should be set to larger values to accommodate the highly burst character of Web traffic, the guidelines [FLO97] for RED parameter settings and for configuring interface buffer sizes (FIFO and RED) also hold for the Web-like traffic used in their experiments. This paper concludes that attempting to tune RED parameters outside these guidelines is unlikely to yield significant benefits. The authors didn t investigate the performance of RED with ECNenabled in their experiments, and they didn t consider fairness at all. For the performance of networks, delivering congestion signal in time is critical. [LIU01] presents that by providing the mark-front strategy for ECN to send even faster congestion signals, mark-front strategy reduces the buffer size requirement at the routers, and it also avoids packet losses and thus improves the link efficiency when the buffer size in an ECN router is limited. With simulations, [LIU01] show that mark-front strategy improves the fairness among old and new users, and alleviates TCP s discrimination against connections with large RTT. In summary, since the introduction of RED, many researchers have done investigations about the behaviors and performances of RED and ECN, and proposed a variety of 17

28 enhancements and changes to router management to improve congestion control. But these previous researches usually considered only the specific traffic domain space in the network with a small or medium number of homogeneous TCP flows. The behavior of RED and ECN congestion control mechanisms in TCP/IP network with many competing heterogeneous flows, hasn t been sufficiently explored. This is the main motivation for this thesis. 18

29 Chapter 3 Experimental Methodology As mentioned in the previous chapters, the goals of this thesis include (1) investigating the behavior and performance of RED with ECN congestion control mechanisms with many heterogeneous TCP Reno flows; (2) exploring an adaptive version of ECN (AECN), which is based on the current standard ECN algorithm and more adaptive to heterogeneous flows and congestion conditions in such a way as to signal TCP hosts to adjust their congestion control mechanisms in time. To reach the goals, two main experimental steps are taken in the study: (1) running experiments to gather the experimental data on the key performance indicators to evaluate the behavior of ECN and RED with heterogeneous, (2) based on the results from Step 1, the basic algorithm of AECN is proposed, and then more experiments are run to compare the performance of AECN and ECN. This chapter describes our methodology for obtaining each metric data, the choice of network simulation tools and the approaches for data analysis. 3.1 The Selection of Measurement Criteria To fully evaluate the behavior and performance of RED and ECN, and AECN, four key performance indicators used in our study are throughput, goodput, fairness and delay. Based on the observation, more efforts are put on the most important ones among these four indicators Throughput Throughput is defined as the data rate at which a source can send packets (including retransmitted packets) to the sink. Assume a source sends out 10 packets in a specific time, and one of these ten packets are dropped by a router in the course of transmission, then the resulting throughput is 9*packet/time taken to transmit. Due to including retransmitted packets, throughput is normally a little higher than goodput. 19

30 3.1.2 Goodput Goodput is defined as the effective data rate as observed at the user. For example, assume 10 data packets are transmitted from a source to a sink, and two of these ten packets are retransmitted packets, then the efficiency is 80%, and the resulting goodput is 8*packet size/time taken to transmit Fairness Fairness has been defined in a number of different ways. Currently, there s still no generally-agreed-upon definition for fairness in a computer network. However, different measures of fairness have quite different implications [FLO91]. Two popular fairness measurement methods are used in our experiments: Jain s fairness index [JAI91] and max-min fairness [PET00]. 1. Jain s Fairness Index Jain s fairness index postulates that the networks is a multi-user system, and derives the metric to see how fairly each user is treated. It s a function of the variability of throughput across each user. For a set of user throughput (x 1, x 2,, x n ), Jain s fairness index to the set is defined as follows: f(x 1, x 2,, x n ) = ( n i 1 x i ) 2 / (n* n i 1 x 2 i ). The fairness index always lies between 0 and 1. A value of 1 indicates that all flows got exactly the same throughput. 2. Max-min Fairness Max-min fairness is another common fairness definition, which is also called bottleneck optimality criterion. A feasible flow rate x is defined to be max-min fair if any rate x i cannot be increased without decreasing some x j which is smaller than or equal to x i. To satisfy the min-max fairness criteria, the smallest throughput rate must be as large as possible. Given this condition, the next-smallest throughput rate must be as large as possible, and so on [FLO94]. Many researchers have developed algorithms achieving max-min fairness rates. Computing the max-min fair vector requires global information, including information from networks and hosts. In our 20

31 simulation result analyses, graphs are used to visually analyze the max-min fairness with respect to goodput for heterogeneous flows Delay Delay is another important performance indicator used in reporting our simulation results. In this study, delay refers to one-way delay, from a source to a sink, and includes link delay, propagation delay and queue delay. 3.2 Experimental Tools Network Simulator ns-2 The flexibility of exploring various simulation scenarios and unrestricted data access are the primary reasons for us to choose ns-2 [NS201]. The network simulator, ns-2, is widely adopted in the network research community. ns-2 evolved as a part of the VINT (Virtual InterNetwork Testbed) project, a collaborative project among University of Southern California, Xerox PARC, Lawrence Berkeley National Laboratory, and the University of California, Berkeley. ns-2 is a discrete event simulator which provides the following supports: Various network protocols (transport, multicast, routing); Simple or complex topologies (including topology generation); Agents, defined as endpoints where network-layer packets are constructed or consumed; Various traffic generators Simulated applications (FTP, Telnet, Web) Most queue management algorithms (TailDrop, RED, ECN) and packet scheduling schemes LAN/WAN, and wireless networks. The code of the simulator is written in C++ and OTcl. There is one-to-one correspondence between a class in C++ (compiled hierarchy of classes in ns-2) and a class in OTcl (interpreted hierarchy). This software architecture (also called split programming model) enables high-performance simulation of packet level routines 21

32 (implemented in C++) and flexible configuration and control of the simulation using an interpreted language such as OTcl [BAJ99]. The following subsections explain the ns-2 specific details for our simulations Simulation Input Scripts All the necessary information to configure and control a simulation run in ns-2 is written in the form of an input OTcl script. The simulation objects (nodes, links and traffic sources) are instantiated with the script, and immediately mirrored in the compiled hierarchy. The input script defines the topology, builds the agents (sources and destinations), sets the trace files and sets the start time for the initial events in the simulation. The initial events might later generate new events. For example, the user can only specify the start of an FTP session and the number of packets to be transferred. This is an initial event indicating the start of the FTP session. When the FTP transfer starts, new events will be generated such as a packet arrival at a router queue, a check of ECT bit of the packet, en-queue and de-queue, an arrival at a receiver, a generation of an ACK packet, etc. The simulator always executes events in the order specified in the event list, which is always sorted by time Simulation Output Traces Tracing in ns-2 can be performed by using trace or monitor objects. Trace objects collect the data for each packet generation, arrival, departure, drop or mark. Monitor objects collect data on an aggregate level and are implemented as counters of specific parameters of interest (total number of packet or byte arrivals, departures or drops). Monitor objects are useful when basic information about the dynamics of the simulation is needed. However, in order to have a comprehensive understanding of each metric pattern, this study performs tracing on a per packet basis. The aggregate information that can be obtained by monitor objects is insufficient to support a detailed study of the observed stochastic process or a process such as packet marking. An output trace in ns-2 has a fixed format, as shown in Table

33 event time from node To node pkt type pkt size flags fid Src Addr dst addr seq num pkt id Table 3.1 ns-2 output trace format Each trace line starts with an event (+, -, d, r) (See Figure 3.1) descriptor followed by the simulation time (in seconds) of that event, and from and to node, which identify the link on which the event occurred. The next information in that line before flags is packet type, which can be TCP data packet or ACK packet, and the size of that packet (TCP data packet is 1000 bytes, and ACK packet is 40 bytes as shown in Figure 3.1). Currently, ns-2 records ECN events (including C ECN Echo bit set as 1, E CE bit set as 1, A ECR bit set as 1) in the flag field. Next to the flag field is flow id (fid) of IPv6 that a user can set for each flow at the input OTcl script. The fields src addr and dst addr contain source address and destination address in the form of node.port. The seq num field contains the network layer protocol s packet sequence number. The last field is the unique id of the packet. r tcp N ack 40 C ack 40 C r ack ack ack r ack tcp N tcp N tcp AE-N r tcp N tcp N d tcp N r tcp A--N NOTE r : receive (at to_node); + : enqueue (at queue); - : dequeue (at queue) d : drop (at queue) Figure 3.1 A sample of ns-2 output trace 23

34 3.2.2 Data Extraction Tools Having simulation trace data ready, the data of interest for computation of each metric needed to be extracted. A data extraction tool C_Stat was developed with perl for generating the report on throughput, goodput, Jain s fairness index and delay, and other statistical data, such as the distribution of marked or dropped packets for each flow. Figure 3.2 summarizes the simulation processes for each simulation experiment with these experimental tools. 1). Writing simulation script OTcl 2). Running ns-2 3).Post-processing C_Stat 4).Analyzing gnuplot, excel Figure 3.2 the Simulation Processes with ns Experimental Setup and Validations In the study, different simulation scenarios are setup. More details about the scenarios are presented in Chapter 4 and 5. The ns-2 source code was modified for the implementations of ECNM 1 and AECN. In order to ensure these implementations are correct, validations were taken during the experiments to guarantee that the implementations were conformant to our design specification by visually inspecting the corresponding ns-2 traces. Each simulation experiment was run for 100 seconds, but data collected during the first 20 seconds was discarded to reduce startup and stabilization effects. These effects are illustrated in Figure 3.3 which shows the router queue distribution, and Figure 3.4 which shows a plot of mean aggregate throughput for all flows during each one second interval in a typical experiment. In each simulation with a specific number of flows, half of these flows start at second 0, and the rest start at second 2. 1 ECNM, an extension to the standard ECN, is investigated to compare with the standard ECN. The only difference between ECNM and ECN is when the average queue size is above the maximum threshold of ECN router queue, the standard ECN will drop a incoming packet while ECNM will continue to mark the incoming packets. 24

35 Figure 3.3 ECN router queue distribution for 60 flows, max_p=0.1, min_th=10 packets, max_th=30 packets, cwnd=64 packets Figure 3.4. Mean aggregate goodput forecn with 60 flows during each one second interval max_p=0.1, min_th=10 packets, max_th=30 packets, cwnd=64 packets 25

36 Chapter 4 Evaluation of ECN with Heterogeneous TCP Flows 4.1 Introduction This chapter focused on presenting the simulation results on the performance and behavior of RED routers and ECN routers with heterogeneous TCP flows. Several research studies have reported better performance for Explicit Congestion Notification (ECN) when compared against RED. These results add support to the Internet draft "Addition of ECN to IP" [RAM99]. However, most of these studies cover only a limited portion of the traffic domain space. Specifically, little attention has been given to evaluating the effects of a large number of heterogeneous flows. Although a couple of these studies consider fairness among competing homogeneous flows, ECN behavior with heterogeneous flows has not been thoroughly studied. Therefore, as mentioned in previous chapters, one of the two goals of this thesis is to add to the existing information on ECN behavior specifically with regard to the impact of the number of flows, the effect of ECN tuning parameters on performance, and the effectiveness of ECN's congestion warnings when many flows cause the congestion. This chapter presents the simulation results of the evaluation of ECN performance with many heterogeneous flows. Section 4.2 briefly defines a few measurement terms and reviews previous ECN studies to provide context for our experiments. Section 4.3 discusses experimental scenarios and details in this step. The next section analyzes the simulated results and the final section includes concluding remarks. 4.2 Definitions Robust, Average and Fragile flows Fragile TCP flows are defined as those from sources with either large round-trip time or small send window sizes and robust flows as having either short round-trip time or large 26

37 send windows [LIN97]. This delineation emphasizes a flow's ability to react to indications of both increased and decreased congestion at the bottleneck router. To evaluate the behavior of ECN with heterogeneous flows, our experiments simulate three distinct flow groups (fragile, average, and robust flows). These flows differ only in their end-to-end round-trip times (RTTs). The maximum sender window is held fixed at 64 packets in all simulations to simplify the analysis ECNM In this study, one variant of ECN, called ECNM (ECN with Marking) is also investigated to compare its behavior with standard ECN. ECNM differs from standard ECN in that ECNM marks packets when the average queue size exceeds max th and drops packets only when the router queue overflows. 4.3 Simulation Scenarios The simulation network topology (See Figure 4.1) consists of one router, one sink and a number of sources. Each source has a FTP connection feeding 1000 byte-packets into a single congested bottleneck link whose bandwidth is 10 Mbps with 5 ms delay time to the receiver. The one-way link delays to the router for the fragile (F 1,, F i ), average (A 1,, A i ) and robust (R 1,, R i ) sources are 145 ms, 45 ms and 5 ms respectively. Thus, without considering the router queue delay, the fragile, average and robust flows have minimum round-trip time of 300 ms, 100 ms, and 20 ms. The bottleneck router has a physical queue size of 120 packets. Max th is always three times than min th in the simulations. Except for the maximum send window size of 64 packets, all other parameters use the n2-s default values. A number of ns-2 experiments were run such that the cumulative traffic flow into the heavily congestion router remains fixed at 300 Mbps even though the number of flows is varied across simulations. In all cases, the number of flows is equally divided among the three flow groups. Thus, 15 flows in the following graphs of this chapter implies 5 fragile, 5 average and 5 robust flows, and each flow with a 20 Mbps data rate whereas a figure point for 120 flows implies a simulation with 40 fragile, 40 average and 40 robust 27

38 flows each with a 2.5 Mbps data rate. Simulations were run with the total number of flows set at 15, 30, 60, 240, 480, and 600 flows respectively. 300 Mbps F 1. A 1 145ms 45ms. A i 5ms R 1. R i Router 10Mbps, 5ms : Source : Sink 4.4 Simulation Result Analyses Figure 4.1 Simulation Topology Aggregate throughput (or goodput) in the following graphs is the sum of the throughput (or goodput) of all fragile, average and robust flows. Much of result analysis in this section appears in the paper [KNI01] Throughput Figure 4.2 shows the aggregate throughput distribution with the number of flows. As shown in this graph, when the number of flows is small, e.g. below 120 flows, ECN beats RED on throughput. But when the number of flows increases and the congestion becomes heavier, ECN may even lose to RED on throughput. In this figure, when the number of flows is higher than 120 flows, increasing max p doesn t help ECN instead, which actually has lower aggregate throughput than RED. For example, when max p is equal to 0.5 or 0.8, and the number of flows is 240, ECN has smaller throughput than RED. The reasons for that include: (1) ECN marks incoming packets when the average queue size is between max th and min th. This implies ECN normally has a higher current queue size and queue delay than RED; (2) When the number of flows is high and the congestion is heavy, many more packets will be marked by ECN router, which will cause the senders to slow down frequently. As show in Figures 4.3 and 4.4, ECN does have higher current 28

39 queue length than RED when the number of flows is 240. And the router has more chance to be empty than RED, which would finally degrade the throughput of ECN. Meanwhile, when the number of flows is small, such as 15 flows or 30 flows, Figure 4.2 shows that max p should be conservative enough to get higher throughput for both mechanisms. Figures 4.5 and 4.6 present the aggregate throughput distribution with different max p when the number of flows is 30 and 120 respectively. These two figures show that there s an optimal max p for ECN to get the best throughput for each different number of flows. For example, for ECN with 30 flows, max p = 0.1 is the best to get the highest throughput when min th and max th both are equal to 10 and 30. Once the number of flows increases, max p should also increase to make ECN more aggressive to notify enough sources to slow down frequently enough. Meanwhile, as shown in Figure 4.5 and 4.6, different values of min th and max th can also influence the throughput of ECN. When the number of flows increases, max th should be large enough as to provide enough space at router queue for the incoming packets to get higher throughput. Figure 4.2 Aggregate Throughput Distribution with the Number of flows. min th = 10 packets, max th = 30 packets, 29

40 Figure 4.3 ECN: Queue Length Distribution with Time. min th = 10 packets, max th = 30 packets, max p =0.5, Number of flows=240. Figure 4.4 RED: Queue Length Distribution with Time. min th = 10 packets, max th = 30 packets, max p =0.5, Number of flows=

41 Figure 4.5 Aggregate Throughput Distribution with max p, Number of flows = 30. Figure 4.6 Aggregate Throughput Distribution with max p, Number of flows = Goodput Figure 4.7 gives ECN and RED aggregate goodput with the number of flows varying from 15 to 600. ECN with higher max p provides better goodput than RED in all cases except 15 flows. When max p is equal to 0.1, ECN and RED both have large drops in goodput beginning at 60 flows. 31

42 ECN with higher min th and max th provides better goodput even when the number of flows is large. The main reason why ECN has better goodput in this case is due to the fact that ECN always marks the incoming packet when average queue size is between min th and max th, which causes less packet drops and retransmissions than RED. For the case with 15 flows, too high a value for max p also causes lower goodput for ECN compared with a lower value of max p = 0.1. This indicates when the number of flows is small and congestion is light, max p should not be too aggressive. On the other hand, while the number of flows is large and congestion is heavy, max p should increase to make ECN more aggressive so that enough sources are informed with an enough frequency to back off during heavy congestion and to get fewer packets dropped and further improve the aggregate goodput. Figure 4.7 Aggregate Goodput Distribution with the Number of flows. min th = 10 packets, max th = 30 packets Figures 4.8 and 4.9 track the effect on aggregate goodput distribution by varying max p, min th and max th in simulations with 30 and 120 flows respectively. Figure 4.8 shows that the values of min th and max th have an obvious effect on the aggregate goodput between RED and ECN. ECN gets a clear advantage over RED on goodput. But 32

43 once max p is above 0.2, the goodput doesn t change much ECN or RED with 30 flows. In Figure 4.9 where 120 flows provide the same flow demand as 30 flows in Figure 4.8, ECN with max p =0.8, min th =10, and max th =30 yields the highest aggregate goodput and there s no max p setting for RED that works well. Figure 4.8 Aggregate Goodput Distribution with max p, Number of flows = 30. Figure 4.9 Aggregate Goodput Distribution with max p, Number of flows = Delay Figure 4.10 describes the one-way delay distribution with the number of flows among these three flow groups. As shown in this figure, the robust flows have a clear advantage 33

44 over the fragile and average flows on delay. Furthermore, the one-way delay for each flow group increases a little with the number of flows increasing since more packets enter the router queue, the average queue size and queue delay increases as well. Meanwhile, ECN has a little higher one-way delay than RED. That s mainly due to the fact that ECN router normally has higher average queue size than RED router (See Figure 4.11 and 4.12), which means ECN has a little higher queue delay. The ECN goodput improvement is offset by a small increase in the one-way delay for ECN. However, even though ECN doesn t win RED on delay, ECN has an absolute advantage than RED on goodput in most cases. As shown in Figure 4.10, ECN can get around 1% higher than RED on the mean one-way delay of all flows while Figure 4.7 shows that ECN can get about 10% higher than RED on goodput. Figure 4.10 Delay Distribution among Each Flow group with the Number of flows. min th = 10 packets, max th = 30 packets 34

45 Figure 4.11 Average Queue Size Distribution (30 flows). min th = 10 packets, max th = 30 packets, max p = Fairness Figure 4.12 Average Queue Size Distribution (60 flows). min th = 10 packets, max th = 30 packets, max p =0.5 In this section, two fairness methods, Jain s Fairness Index and Visual Max-min Fairness, are used to measure the fairness metric of ECN and RED. 35

46 Jain s Fairness Index Figure 4.13 employs Jain s fairness to quantify ECN and RED behavior. ECN is fairer than RED in almost all situations. Since perfect fairness has a Jain s fairness index of 1, it s clear that as the number of flows goes above 120 none of the choices prevent unfairness. The fact, that ECN with max p =0.1 is fairest at 30 flows while max p =0.5 is the fairest at 60 flows and max p =0.8 at 120 flows, implies the marking probability should be dynamically adjusted based on a flow count estimator. The unfairness at a high number of flows can also be partially attributed to a lockout phenomenon, where some flows are unable to get any data through the congested router for the duration of the simulation. Locked out flows begin to appear for both ECN and RED above 120 flows (See Figure 4.14 and 4.15). Figure 4.13 Aggregate Jain s Fairness Index with the Number of flows. min th = 10 packets, max th = 30 packets. 36

47 Figure 4.14 ECN Marked packet Statistics, 120 flows, max p =0.8 NOTE: (1). Lockout regions: (2). Flow No. 0 ~ 39 refers to fragile flows, flow No. 40 ~ 79 for average flows, and flow No. 80 ~ 119 for robust flows. Figure 4.15 RED Dropped packet Statistics, 120 flows, max p = Visual Max-min Fairness Figure 4.16 through 4.19 provide a visual sense of max-min fairness via the gap between the averaged goodputs for the three flow groups. In all these graphs, ECN provides better 37

48 overall goodput than RED, but the difference is most pronounced in Figure 4.16 where the traffic is generated by 60 flows. Figure 4.16 and 4.17 differ only in an increase of max p from 0.2 to 0.5. The more aggressive ECN marking in Figure 4.17 provides better goodput for robust flows than RED. However, this change doesn t reduce the goodput gap between robust and fragile flows. Figure 4.18 keeps max p =0.5 but simulates 60 flows. Figure 4.16 Goodput Distribution among Each Flow Group with Time. Number of flows = 30, max p = 0.2, min th = 10 packets, max th = 30 packets. Figure 4.17 Goodput Distribution among Each Flow Group with Time. Number of flows = 30, max p = 0.5, min th = 10 packets, max th = 30 packets. 38

49 Although overall goodput remains relatively unchanged for ECN in Figure 4.18, the goodput for the robust flows goes down while the goodput of the average and fragile flows increase slightly. This implies that varying max p when there are heterogeneous flows can provide improvement in the visual max-min goodput. RED goodput is adversely affected by more flows. This suggests an adaptive ECN that uses different values of max p for the different flow groups. The significance of using goodput instead of throughput as a performance metric can be clearly seen in Figure 4.18 and Because goodput excludes retransmissions, RED has about 12% lower goodput than ECN in Figure Since RED drops and ECN marks, the RED drops trigger more TCP retransmissions. This effect is completely hidden in Figure 4.19 where aggregate RED throughput is only slightly lower than aggregate ECN throughput. Figure 4.18 Goodput Distribution among Each Flow Group with Time. Number of flows = 60, max p = 0.5, min th = 10 packets, max th = 30 packets. 39

50 Figure 4.19 Throughput Distribution among Each Flow Group with Time. Number of flows = 60, max p = 0.5, max th = 30 packets, min th = 10 packets ECNM Figure 4.20 compares standard ECN with ECNM. Recall ECNM differs from standard ECN in that ECNM marks packets when the average queue size exceeds max th and drops packets only when the router queue overflows. This graph shows that ECN provides better goodput except at small values of max p than ECNM. Figure 4.20 Goodput Distribution with max p, 40

51 4.5 Conclusions Number of flows = 120, min th = 10 packets, max th = 30 packets This chapter presents a series of ns-2 simulations that evaluate the behavior and performance of ECN by comparing it with RED with heterogeneous flows. Generally ECN provides better goodput and is fairer than RED. However, in some case RED may have better throughput than ECN, especially when the number of flows and max p are high. The results also show that the performance of both mechanisms be affected by the number of competing flows. However, ECN with an aggressive max p setting provides significantly higher goodput than RED when there are a large number of heterogeneous flows. ECN also has a higher Jain s fairness Index and visual max-min fairness in the range of flows just below where flow lockout phenomena occur. In the simulations studied, neither RED nor ECN mechanism is fairer to fragile and average flows. These results suggest that if congestion control is to handle Web traffic consisting of thousands of concurrent flows with some degree of fairness then further enhancements to ECN are needed. Based on these results, an adaptive version of ECN (AECN), which can adjust max p based on the round-trip time of a flow, is proposed in the next chapter. 41

52 Chapter 5 Adaptive ECN (AECN) for Heterogeneous TCP Flows 5.1 Introduction In the last chapter, the simulation results by comparing the simulated performance of RED routers and ECN routers shows that ECN does provide better goodput and fairness than RED for heterogeneous flows in most cases. When the demand is held constant, the number of flows generating the demand has a negative effect on performance. Meanwhile, the simulations with many flows demonstrate that the bottleneck router's marking probability must be aggressively increased to provide good ECN performance when the number of flows increases. Based on these simulation results, this chapter presents an adaptive version of ECN (AECN) that can further improve the performance of ECN on on the goodput or throughput and fairness by properly adjusting the relevant ECN parameters. Rather than treat all flows with a same max p in ECN, AECN divides all flows competing for a bottleneck into three flow groups, and deploys a different max p for each flow group so that a fragile flow can have higher chance to get a proper share of bandwidth when competing with a robust flow. Meanwhile AECN also adjusts min th for each robust flow group and max th to get higher performance when the total number of flows changes. Furthermore, AECN uses a mark-front strategy, instead of mark-tail strategy in standard ECN, to mark the first unmarked packet in the front of a corresponding flow queue so that the notification of congestion can be speeded up to a sender. 5.2 The Basic Algorithm of AECN Assumptions 42

53 Just like standard ECN, AECN is used together with TCP congestion control mechanisms like slow-start and congestion avoidance. When an acknowledgement is not marked, the source follows existing TCP algorithms to send data and increase the congestion window. Upon the receipt of an ECN-Echo packet, the source halves its congestion window and reduces the ssthresh. In the case of a packet loss, the source follows the TCP algorithm to reduce the window and retransmit the lost packet. AECN delivers congestion signals by sending CE packet, which sets the CE bit as 1, but determining when to set the bit depends on the average queue size. Like standard ECN, AECN uses the average queue length as in the proposal in [RAM99] and [RAM01]. Hence, when the average queue size of an AECN router is smaller than min th, no marking action occurs when a new packet comes in the router. When the average queue size is between min th and max th, a marking action to a packet (could be the packet at the front or the tail of the router queue) will happen with a probability. Once the average queue size is above max th, all the incoming packets will be dropped as standard ECN does. This study has a few assumptions as follows: (1) Receiver windows are large enough so that the bottleneck is in the network. (2) A sender always has packets to send and will send as many packets as its window allows. (3) Receivers acknowledge every received packet and there are no delayed ACKs. (4) Router queue length is measured in packets and all packets have the same size. (5) The TCP header has an enough extra space to contain the round-trip time information in each packet, and the round-trip time has small enough time granularity Terminologies Flow Queue A flow queue is a virtual queue, which refers to a queue storing the address of each packet in the router queue for a specific flow group. AECN divides all flows into three flow groups, i.e., fragile, average and robust flow group, depending on the round-trip time of each flow. Accordingly, AECN has three flow queues, which are called fragile, average and robust flow queues respectively. Each flow 43

54 queue maintains a range of round-trip times to be compared with the round-trip time in a new packet for deciding which flow queue this new packet belongs to, and a maximum marking probability max p for deploying different marking probabilities Base max p Just as standard ECN maintains a maximum marking probability, max p, AECN maintains a base max p for the average flow group. While the marking probability for the fragile flow group is the most conservative to permit fragile flows to get more bandwidth when competing with the other two flow groups, and the marking probability for robust flows is the most aggressive. Hence, AECN sets the maximum marking probability to (base max p / ) for fragile flow group, and to (base max p * ) for the robust flow group. and both are constants, and their concrete values depend on the average round-trip time of each flow group Unlockout Range As was shown in last chapter, ECN is better than RED in some specific ranges of the number of flows. These ranges, called the unlockout range, are determined by whether the lockout phenomenon is heavy or not. Once the lockout phenomenon occurs seriously due to the high number of flows, ECN and RED, like other TCP congestion control mechanisms, both don t help much to control the congestion effectively. Therefore, it doesn t make sense to compare the performance of AECN and ECN, and RED, beyond the unlockout range Strategies In most ECN implementations, when congestion happens, the congested router marks the incoming packets that just enter the router queue. When the buffer is full or when a packet needs to be dropped as in RED, some implementations, e.g. ns-2 simulator, uses the drop from front option as suggested in [YIN90]. A brief discussion of drop from 44

55 front in RED can be found in [FLO98b]. However, for packet marking, ns-2 still pick the just-incoming packet to mark, rather than the front packet Round Trip Time Strategy As mentioned in section 5.2.1, AECN assumes that the TCP header has enough reserved space to contain the round-trip time of each flow. The decision which flow group a new packet belongs to is dependent on the round-trip time of the packet. Before a source sends out a new packet, the round-trip time of the last ACKed outgoing packet of this flow is added into the TCP header of this new packet. The computation of round-trip time in ns-2 simulation uses the round-trip time mechanism of TCP Vegas [AHN95] [BRA95] Marking Front Strategy One of the weaknesses of mark-tail strategy is its discrimination against new flows [LIU01]. Consider the time when a new flow joins the network, but the buffer of the congested router is occupied by packets of old flows. In the mark-tail strategy, the packet that just arrived will be marked, but the packets already in the buffer will be sent without being marked. The ACK of the sent packets will increase the window size of the old flows. Therefore, the old flows which already have large share of the bandwidth will get more bandwidth. However, the new flow with small or no share of the resources has to backoff., since its window size will be reduced by the marked packets. Contrary to the mark-tail strategy, when a packet needs to be picked for marking, the mark-front strategy will pick the first unmarked packet in the front of the queue and mark it. Connections with large buffer occupancy will have more packets than connections with small buffer occupancy. Compared to the mark-tail strategy that let the packets in the buffer escape the marking, mark-front strategy helps to alleviate the lockout phenomenon [LIU01]. Therefore, we can expect that mark-front strategy would be fairer than marking-tail strategy. It s well-known that TCP s discrimination against fragile flows that have large RTT or small cwnd [QIU99]. The cause of the discrimination is similar to the discrimination against new flows. If fragile flows and robust flows start at the same time, robust flows will receive their ACKs faster and therefore grow faster, and then get more bottleneck bandwidth. When congestion happens to the bottleneck, there are more 45

56 packets from robust flows than those from fragile flows. With the mark-tail strategy, packets already in the router queue will not be marked but only newly arrived packets will be marked. This may cause robust flows to grow ever larger than fragile ones. Markfront strategy alleviates this discrimination by treating all packets in the buffer equally. Packets already in the buffer may also be marked. In this way, fragile flows can get larger bandwidth, which would make AECN fairer to all flows. Meanwhile, mark-front strategy can hasten the transmission of congestion notification to the sender since the marked packet doesn t need to wait in the router queue. In this way, the sender can get congestion notification earlier to execute congestion action Basic Algorithm The basic algorithm of AECN consists of the following three steps (See Algorithm 5.1). The relationship between the AECN router queue and the three flow queues is shown in Packet en-queue Figure 5.1. Fragile flow Queue Router Queue Average flow Queue Robust flow Queue Packet de-queue Robust packet Average packet Fragile packet Figure 5.1 The Relationship between Three Flow Queues and Router Queue 46

57 1. Initialization: Initially, all queues are set empty, including the router queue and the three flow queues. 2. En-queue: When a new packet comes into the router, AECN will check: a). If avg >= max th, AECN will drop this incoming packet just as standard ECN does. b). If avg is below max th, 1). Add this packet into the router queue. 2). Deploy AECN RTT strategy for deciding which flow queue this packet belongs to. AECN RTT strategy: 1). Get RTT contained in the incoming packet, (in milliseconds) 2). Decide which flow queue this packet belongs to: If RTT is in the RTT range of robust flow queue status = ROBUST_FLOW_QUEUE; else if RTT is in the RTT range of average flow queue status = AVERAGE_FLOW_QUEUE; else if RTT is in the RTT range of fragile flow queue status = FRAGILE_FLOW_QUEUE; 3). If avg is between min th and max th, deploy AECN marking-front strategy to mark the first unmarked packet in the corresponding flow queue. AECN marking-front strategy: 1). With the value of status, find the first unmarked packet recorded in the corresponding flow queue. 2). Select a maximum marking probability: max p, if (status == ROBUST_FLOW_QUEUE) max p = min{ (base-max p * ), 1}; else if (status == AVERAGE_FLOW_QUEUE) 47

58 max p = base-max p ; else if (status == FRAGILE_FLOW_QUEUE) max p = base max p / ; 3). Update the marking probability with the new max p 4). Mark the selected packet with the new marking probability. 3. De-queue Once an outgoing packet leaves the AECN router, AECN will check: a). If (status == ROBUST_FLOW_QUEUE) Remove the first node in the robust flow queue. Else if (status == AVERAGE_FLOW_QUEUE) Remove the first node in the average flow queue; Else if (status == FRAGILE_FLOW_QUEUE) Remove the first node in the fragile flow queue; b). Remove the packet from the router queue. Algorithm 5.1 the basic algorithm of AECN 5.3 Implementation in ns-2 To implement AECN, some code needed to be added or modified in ns-2. In this study, all flows use the TCP variant: TCP Reno. The implementation of AECN includes two aspects: 1. The implementation of AECN RTT strategy in TCP Reno: To obtain the RTT of each flow, one variable, r_rtt_, is added into the packet header of TCP Reno in ns-2. Each time a TCP Reno source receives an ACK for a specific flow, the real round-trip time of this flow is updated with the code shown in Appendix A. Before a source sends out a new packet, the updated round-trip time of this flow is put into this new outgoing packet. For the first packet sent out from a source for connection setup, i.e. handshaking, its RTT would be 0 (ms). The AECN router takes the first packet of each flow as being from an average flow. 48

59 2. The implementation of AECN based on standard ECN The second part of AECN implementation includes implementing the three flow queues (See Appendix B) and modifying the code based on standard ECN. The address of each packet in the router queue is kept by the corresponding flow queue, which maintains the current number of the packets of the same flow group. Once a new packet arrives at the router queue and the average queue size is between min th and max th, the address of this packet in the router queue is pushed into a corresponding flow queue, and a different maximum marking probability is deployed (See REDQueue::enque(), and REDQueue::drop_early() in Appendix B). When a packet leaves the router queue, its address information in a flow queue will be removed from the corresponding flow queue (See REDQueue:deque() in Appendix B). 5.4 Simulation Scenarios To compare the performance of standard ECN and AECN, a series of simulations with the ns-2 simulator were run. As mentioned earlier, the algorithm of standard ECN in ns-2 simulator is changed to implement the basic algorithm of AECN. The basic network simulation topology (Figure 5.2) used in the experiment is the same as that shown in last chapter (See Figure 4.1), but with some different parameter settings to make it closer to a real network configuration. 90Mbps F 1 F i. A 1 95ms A i 45ms. R 1 20ms. R i Router 10Mbps, 5ms : Source : Sink Figure 5.2 Simulation Topology 49

60 In [CHR00], Christiansen says that a typical round-trip time of a flow would be in the range of 7 ms to 137 ms. Accordingly, in the simulation configuration, AECN supposes that the round-trip time of a robust flow, a fragile flow and an average flow are in the ranges of [0.5 ms- 75 ms), [150 ms, +), and [75 ms, 150 ms). Meanwhile, for a packet with a RTT of 0 ms sent out by any flow, AECN takes it as an average flow. With the basic configuration shown in Figure 5.2, the link delays between a source and the router are set 95 ms, 45 ms and 20 ms for fragile, average and robust flows. Thus, the fixed round-trip times for fragile flows, average flows and robust flows, without taking into account the router queue delay, are 200 ms, 100 ms and 50ms. A FTP application runs on each source using TCP Reno. Each source has a window size of 64 packets. The data packet size, including all headers, is 1000 bytes, and the acknowledgement packet size is 40 bytes. The total capacity of the bandwidths from all sources is fixed at 90 Mbps. The router has a fixed physical size of 120 packets, and min th and max th (if not explained particularly) are 10 and 30 packets respectively. The bottleneck link has a bandwidth of 10 Mbps with a link delay of 5ms. Half of the number of flows in each flow group start at time 0, the second half start at time 2 seconds. That is, if there are 60flows. 10 fragile, 10 average and 10 robust flows start to run at second 0, and the rest 30 flows at the 2 nd second. All simulations were run for 100 seconds. 5.5 Simulation Preliminaries The main purpose of the simulations is to compare the performance of AECN and standard ECN. But, before running simulations for the performance comparison between AECN and standard ECN, some preliminary simulations were run for confirming the behavior of ECN and RED in the simulation configuration in Figure 5.2. One difference between the simulation configurations shown in Figure 5.2 and Figure 4.1 is that in Figure 5.2 the aggregate capacity of the bandwidth between all sources and the bottleneck router is 90 Mbps while it s 300 Mbps in Figure 4.1. It s believed that the change of the aggregate capacity may change the unlockout range. As shown in the last chapter, ECN is better than RED in the unlockout range. Therefore, this study concentrates on comparing 50

61 Goodput (Mbps) Jain's Fairness Index the performance of AECN and standard ECN in the unlockout range even though the simulation results beyond the range are also presented in this chapter. Figures 5.3 through 5.12 present the comparison of standard the ECN and RED on each metric. Figures 5.3 and 5.4 show the Jain s fairness index and goodput of standard ECN goes down dramatically at 120 and 240 flows for max p being 0.5 and 0.8 respectively. Figure 5.5 presents that even though ECN has better goodput than RED with 60 flows, the visual max-min fairness observed from this figure for both algorithms is relatively low since the gap between the goodput of robust flow group and fragile flow group is so obvious ECN (max_p=0.1) 0.3 RED (max_p=0.1) ECN (max_p=0.5) 0.2 RED (max_p=0.5) 0.1 ECN (max_p=0.8) RED (max_p=0.8) Number of flows Figure 5.3 Jain s Fairness Index with the Number of Flows ECN (max_p=0.1) RED (max_p=0.1) ECN (max_p=0.5) RED (max_p=0.5) ECN (max_p=0.8) RED (max_p=0.8) Number of Flows Figure 5.4 Goodput with the Number of Flows 51

62 Goodput (Mbps) Figures 5.6 through 5.8 show there are some flows gets locked out in some particular periods (The regions list some of the lockout occurrences). In these figures, y- coordinate presents the flow id of each packet. The flows with flow No refer to the 20 fragile flows, those with flow No are the 20 average flows, and the others with flow No are the robust flows. As shown in Figure 5.6, the robust flow group gets the most packets marked, while the fragile flow group gets the least. Figure 5.7 shows that there are packet drops around at second 50, 67 and 78. While compared Figure 5.8 with Figure 5.7, it s easy to find that RED has many more packet drops than ECN since RED drops an incoming packet probabilistically when the average queue size is between min th and max th. Figures 5.9 through 5.11 present the statistics of dropped or marked packets of RED and ECN with 120 flows. The flows with flow No refer to the 40 fragile flows, those with flow No are the 40 average flows, and the others with flow No are the 40 robust flows. It s obvious that the lockout phenomenon become much heavier for 120 flows than that for 60 flows, and more packets get dropped or marked Time (Seconds) Aggregate Goodput (ECN) Fragile (ECN) Avreage (ECN) Robust (ECN) Aggregate Goodput (RED) Fragile (RED) Average (RED) Robust (RED) Figure 5.5 Goodput Distribution between ECN and RED, 60 flows, max p =

63 Figure 5.6 ECN Marked packet Statistics, 60 flows, max p =0.5. Figure 5.7 ECN Dropped packet Statistics, 60 flows, max p =0.5. Figure 5.8 RED Dropped packet Statistics, 60 flows, max p =

64 Figure 5.9 ECN dropped packet Statistics, 120 flows, max p =0.5. Figure 5.10 ECN marked packet statistics, 120 flows, max p =0.5. Figure 5.11 RED dropped packet statistics, 120 flows, max p =

65 Throughput (Mbps) The lockout phenomenon is definitely more serious after 240 flows. Therefore, this study sets the unlockout range at 240 flows and below with the simulation topology shown in Figure 5.2, and focuses on evaluating the performance of AECN and ECN within this range. Figures 5.12 through 5.15 show the similar results as those in last chapter. Both ECN and RED can get high aggregate throughput (Figure 5.12). However, when max p is equal to 0.8, ECN may get less aggregate throughput than RED in some range of the number of flows. Nevertheless, ECN still has better goodput than RED in this range. The possible reasons for that include two aspects: (1). max p =0.8 is so high that a high number of packets get marked which cause the senders to slow down frequently; (2). Since ECN marks the incoming packets, instead of dropping, the ECN router will have more packets enter the router queue than RED when the number of flows is high. This causes ECN to have higher queue delay (See Figure 5.15) and higher chance than RED to hit the max th, which causes ECN to drop the packets. Figures show that ECN gets a little higher delay than RED in the unlockout range since ECN router has higher average queue size. But, once out of the unlockout range, there s no difference on delay for ECN and RED since both have an average queue size stably around max th when the number of flows is really high and the congestion is heavy ECN (max_p=0.1) 7.5 RED (max_p=0.1) 7 ECN (max_p=0.5) 6.5 RED (max_p=0.5) 6 ECN (max_p=0.8) 5.5 RED (max_p=0.8) Number of Flows Figure 5.12 Throughput with the Number of Flows 55

66 Delay (Seconds) Delay (Seconds) Delay (Seconds) Number of Flows Fragile (ECN) Average (ECN) Robust (ECN) Fragile (RED) Average (RED) Robust (RED) Figure 5.13 One-way Delay with the Number of Flows (max p =0.1) Fragile (ECN) Average (ECN) Robust (ECN) Fragile (RED) Average (RED) Robust (RED) Number of Flows Figure 5.14 One-way Delay with the Number of Flows (max p =0.5) Fragile (ECN) Average (ECN) Robust (ECN) Fragile (RED) Average (RED) Robust (RED) Number of Flows Figure 5.15 One-way Delay with the Number of Flows (max p =0.8). 56

67 5.6 Performance Comparison Between AECN and ECN This section concentrates on presenting the simulation results for AECN, and comparing it with ECN The Selection of and AECN uses two parameters, to implement two separate maximum marking probabilities for fragile flow group and robust flow group. Therefore, simulations were run to check the influence of different, on AECN performance. For simplicity, AECN first supposes that is equal to. Figure 5.16 through 5.19 shows the selection of on the performance of AECN with 60 flows and 120 flows on goodput and Jain s fairness index. In the study, simulations with of 1.0, 1.5, 2, 2.5, 2.6, 2.8 and 3.0 were run. Figures 5.16 and 5.18 present the change of Jain s fairness index with. As shown in figure 5.17 and 5.19, when increases from 1.0 to 3.0, the marking probability for the fragile flow group becomes less and less aggressive, so they get more bandwidth and then their goodput increases. While the marking probability for the robust flow group becomes more and more aggressive, and gets less bandwidth. For 60 flows (Figure 5.16), when is equal to 2.5, AECN gets the highest Jain s fairness index. Meanwhile, even though the selection of in this case seems that it doesn t change much the aggregate goodput share of the average flow group, when increases from 1.0 to 3.0, the goodput of the robust flow group comes to be less while the fragile flow group gets more and more goodput and the average flow group tends to remain stable on goodput. Especially, when is below 2.6, AECN comes to behave better on the visual max-min fairness with increasing, and reaches the best when is equal to 2.6. Considering the fact that AECN has the highest Jain s fairness index at the point of of 2.5 and tends to decrease after this point, it s believed that at the point of 2.5 is preferable for AECN when the number of flows is

68 Goodput (Mbps) Jain's Fairness Index Figure 5.18 and 5.19 further shows the results of the selection of on the performance of AECN with 120 flows. When is equal to 2.5, AECN still gets the highest Jain s fairness index, and when is above 2.5, the goodput and Jain s fairness index of AECN tends to decrease. Therefore, for 120 flows, at the point of 2.5 is also preferable for AECN even though the visual max-min fairness at the point of 2.6 is the best AECN a Figure 5.16.Jain s Fairness Index with, ( = ), 60flows, base-max p = Aggregate Goodput Fragile Average Robust a Figure Goodput with, ( = ), 60flows, base-max p =

69 Goodput (Mbps) Jain's Fairness Index AECN Figure Jain s Fairness Index with, ( = ), 120flows, base max_p=0.5. a Aggregate Goodput Fragile Average Robust a Figure Goodput with, ( = ), 120flows, base-max p =0.5. From the above observations, at the point of 2.5 is selected for AECN to compare it with standard ECN before further refining AECN. One more interesting thing, observed from figures 5.3, 5.4 and Figure 5.16 through 5.19, is that when is 1.0, which makes AECN use marking-front strategy with a same 59

70 max [1] p for the three flow groups, AECN with marking-front strategy has a little higher goodput and Jain s fairness index (See the statistics in table 5.1) than standard ECN, which uses marking-tail strategy. For example, when the number of flows is 60, the mean Jain s fairness index and aggregate goodput of AECN with equal to 1 are and Mbps, while the mean Jain s fairness index and aggregate goodput of standard ECN are and Mbps. When the number of flows is 120, the mean Jain s fairness index and aggregate goodput of AECN with equal to 1 are and Mbps, while the mean Jain s fairness index and aggregate goodput of standard ECN are and Mbps Jain s Fairness Index Goodput (Mbps) AECN ECN AECN ECN =1.0 = flows flows Table 5.1 Performance statistics between AECN and ECN, AECN: base-max p =0.5, = 1.0; ECN: max p =0.5; Performance Evaluation of AECN with = 2.5 This section presents the simulation results of AECN with of 2.5 ( = ) with different number of flows, and makes comparisons of AECN with standard ECN. All the other parameter settings for the simulations in this section are the same described in section Goodput Figures 5.20 and 5.21 present that AECN keeps getting higher goodput than ECN when the number of flows increases. This shows that by restricting robust flows with an [1] That is, the maximum marking probabilities for all flows of the three flow group are equal to base max p 60

71 Goodput (Mbps) aggressive max p and encouraging fragile flows with a conservative max p, AECN gets fewer retransmissions than standard ECN. The main contribution is that AECN marks many more packets than ECN, which reduces the chance that the average queue size hits max th. Observing both Figures 5.20 and 5.21, when base-max p = 0.5, AECN has better aggregate goodput and visual max-min fairness for 30 and 60 flows; but the aggregate goodput and visual max-min fairness goes down for 120 flows. When base-max p = 0.8, AECN gets better aggregate goodput and visual max-min fairness for 120 flows, but the advantage decreases when the number of flows is 240 flows. From these observations, we can conjecture that the selection of base-max p for AECN should be adaptive to the number of flows AECN Fragile (AECN) Average (AECN) Robust (AECN) ECN Number of Flows Figure 5.20 Goodput with the number of flows, base-max p =

72 Goodput (Mbps) AECN Fragile (AECN) Average (AECN) Robust (AECN) ECN Number of Flows Figure Goodput with the number of flows, base-max p = Throughput Figures 5.22 and 5.23 show that AECN can also keep getting higher throughput than standard ECN. Combined with Figure 5.20 and 5.21, AECN is believed to have a smaller loss rate than standard ECN. That s mainly due to the fact that marking the robust flows more aggressively can reduce the chance that the average queue size hits max th, which cause fewer packet drops. This result can be further demonstrated by comparing the statistics of dropped and marked packets shown in Figures 5.24 and 5.27 with Figures 5.6 through These figures show that AECN has fewer packet-drops than ECN, but more packet-marks than ECN. As shown in Figure 5.25, when the number of flows is 60, AECN has no drop after the 20 th second, while ECN has drop occurrence in several short periods (See Figure 5.7). Furthermore, the distribution of marked packets of AECN with 60 flows is more stable than ECN. In the case of 120 flows (See Figure 5.26 and 5.27), it s more obvious that AECN gets much fewer packet drops than ECN (See Figures 5.9 and 5.10), and gets more marks. This results shows that AECN can, to some extent, further alleviate the occurrence of lockout phenomenon and create short periods where there are no drops (See Figures 5.26 and 5.27). 62

73 Throughput (Mbps Throughput (Mbps) AECN Fragile (AECN) Average (AECN) Robust (AECN) ECN Number of Flows Figure 5.22 Throughput with the number of flows, base-max p = AECN Fragile (AECN) Average (AECN) Robust (AECN) ECN Number of Flows Figure 5.23 Throughput with the number of flows, base-max p = 0.8. Figure 5.24 AECN marked packet Statistics, 60 flows, max p =

74 Figure 5.25 AECN dropped packet Statistics, 60 flows, max p =0.5. Figure 5.26 AECN dropped packet Statistics, 120 flows, max p =0.5. Figure 5.27 AECN marked packet Statistics, 120 flows, max p =

75 One phenomenon shown in Figure 5.26 and 5.27 is that during some periods AECN gets no drops but marks. Figure 5.28 shows the reason why this phenomenon may happen. As shown in Figure 5.28, in those periods the average queue size almost seldom hits max th, but stay quite stably close to max th. Figure 5.28 AECN Queue Length Change with Time, 120 flows, max p = Fairness By restricting the robust flows with an aggressive max p and encouraging the fragile flows with a conservative max p, AECN lets the fragile flow group get a higher share of the bandwidth at the bottleneck link than ECN. On the other hand AECN reduces the bandwidth share of robust flow group. Accordingly, Jain s fairness index of AECN (See Figure 5.29 and 5.30) increases in this way. As shown in both figures, within the unlockout range, AECN has higher than 10% improvement on Jain s fairness index. Meanwhile, observing the goodput and throughput distribution among each flow group in Figure 5.5 and Figures , we ve already found that AECN has better visual maxmin fairness than ECN since the gap between the robust flow group and the fragile flow group shrink for AECN, that is, the share of goodput or throughput for the fragile flow group increases while the share for the robust flow group goes down. 65

Transmission Control Protocol. ITS 413 Internet Technologies and Applications

Transmission Control Protocol. ITS 413 Internet Technologies and Applications Transmission Control Protocol ITS 413 Internet Technologies and Applications Contents Overview of TCP (Review) TCP and Congestion Control The Causes of Congestion Approaches to Congestion Control TCP Congestion

More information

Congestion / Flow Control in TCP

Congestion / Flow Control in TCP Congestion and Flow Control in 1 Flow Control and Congestion Control Flow control Sender avoids overflow of receiver buffer Congestion control All senders avoid overflow of intermediate network buffers

More information

image 3.8 KB Figure 1.6: Example Web Page

image 3.8 KB Figure 1.6: Example Web Page image. KB image 1 KB Figure 1.: Example Web Page and is buffered at a router, it must wait for all previously queued packets to be transmitted first. The longer the queue (i.e., the more packets in the

More information

Appendix B. Standards-Track TCP Evaluation

Appendix B. Standards-Track TCP Evaluation 215 Appendix B Standards-Track TCP Evaluation In this appendix, I present the results of a study of standards-track TCP error recovery and queue management mechanisms. I consider standards-track TCP error

More information

RED behavior with different packet sizes

RED behavior with different packet sizes RED behavior with different packet sizes Stefaan De Cnodder, Omar Elloumi *, Kenny Pauwels Traffic and Routing Technologies project Alcatel Corporate Research Center, Francis Wellesplein, 1-18 Antwerp,

More information

TCP Congestion Control : Computer Networking. Introduction to TCP. Key Things You Should Know Already. Congestion Control RED

TCP Congestion Control : Computer Networking. Introduction to TCP. Key Things You Should Know Already. Congestion Control RED TCP Congestion Control 15-744: Computer Networking L-4 TCP Congestion Control RED Assigned Reading [FJ93] Random Early Detection Gateways for Congestion Avoidance [TFRC] Equation-Based Congestion Control

More information

ENRICHMENT OF SACK TCP PERFORMANCE BY DELAYING FAST RECOVERY Mr. R. D. Mehta 1, Dr. C. H. Vithalani 2, Dr. N. N. Jani 3

ENRICHMENT OF SACK TCP PERFORMANCE BY DELAYING FAST RECOVERY Mr. R. D. Mehta 1, Dr. C. H. Vithalani 2, Dr. N. N. Jani 3 Research Article ENRICHMENT OF SACK TCP PERFORMANCE BY DELAYING FAST RECOVERY Mr. R. D. Mehta 1, Dr. C. H. Vithalani 2, Dr. N. N. Jani 3 Address for Correspondence 1 Asst. Professor, Department of Electronics

More information

CS321: Computer Networks Congestion Control in TCP

CS321: Computer Networks Congestion Control in TCP CS321: Computer Networks Congestion Control in TCP Dr. Manas Khatua Assistant Professor Dept. of CSE IIT Jodhpur E-mail: manaskhatua@iitj.ac.in Causes and Cost of Congestion Scenario-1: Two Senders, a

More information

Recap. TCP connection setup/teardown Sliding window, flow control Retransmission timeouts Fairness, max-min fairness AIMD achieves max-min fairness

Recap. TCP connection setup/teardown Sliding window, flow control Retransmission timeouts Fairness, max-min fairness AIMD achieves max-min fairness Recap TCP connection setup/teardown Sliding window, flow control Retransmission timeouts Fairness, max-min fairness AIMD achieves max-min fairness 81 Feedback Signals Several possible signals, with different

More information

Chapter 3 outline. 3.5 Connection-oriented transport: TCP. 3.6 Principles of congestion control 3.7 TCP congestion control

Chapter 3 outline. 3.5 Connection-oriented transport: TCP. 3.6 Principles of congestion control 3.7 TCP congestion control Chapter 3 outline 3.1 Transport-layer services 3.2 Multiplexing and demultiplexing 3.3 Connectionless transport: UDP 3.4 Principles of reliable data transfer 3.5 Connection-oriented transport: TCP segment

More information

Fast Retransmit. Problem: coarsegrain. timeouts lead to idle periods Fast retransmit: use duplicate ACKs to trigger retransmission

Fast Retransmit. Problem: coarsegrain. timeouts lead to idle periods Fast retransmit: use duplicate ACKs to trigger retransmission Fast Retransmit Problem: coarsegrain TCP timeouts lead to idle periods Fast retransmit: use duplicate ACKs to trigger retransmission Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 Packet 6 Sender Receiver

More information

CS519: Computer Networks. Lecture 5, Part 4: Mar 29, 2004 Transport: TCP congestion control

CS519: Computer Networks. Lecture 5, Part 4: Mar 29, 2004 Transport: TCP congestion control : Computer Networks Lecture 5, Part 4: Mar 29, 2004 Transport: TCP congestion control TCP performance We ve seen how TCP the protocol works Sequencing, receive window, connection setup and teardown And

More information

Overview. TCP & router queuing Computer Networking. TCP details. Workloads. TCP Performance. TCP Performance. Lecture 10 TCP & Routers

Overview. TCP & router queuing Computer Networking. TCP details. Workloads. TCP Performance. TCP Performance. Lecture 10 TCP & Routers Overview 15-441 Computer Networking TCP & router queuing Lecture 10 TCP & Routers TCP details Workloads Lecture 10: 09-30-2002 2 TCP Performance TCP Performance Can TCP saturate a link? Congestion control

More information

UNIT IV -- TRANSPORT LAYER

UNIT IV -- TRANSPORT LAYER UNIT IV -- TRANSPORT LAYER TABLE OF CONTENTS 4.1. Transport layer. 02 4.2. Reliable delivery service. 03 4.3. Congestion control. 05 4.4. Connection establishment.. 07 4.5. Flow control 09 4.6. Transmission

More information

Congestion Control In The Internet Part 2: How it is implemented in TCP. JY Le Boudec 2015

Congestion Control In The Internet Part 2: How it is implemented in TCP. JY Le Boudec 2015 1 Congestion Control In The Internet Part 2: How it is implemented in TCP JY Le Boudec 2015 Contents 1. Congestion control in TCP 2. The fairness of TCP 3. The loss throughput formula 4. Explicit Congestion

More information

CS 5520/ECE 5590NA: Network Architecture I Spring Lecture 13: UDP and TCP

CS 5520/ECE 5590NA: Network Architecture I Spring Lecture 13: UDP and TCP CS 5520/ECE 5590NA: Network Architecture I Spring 2008 Lecture 13: UDP and TCP Most recent lectures discussed mechanisms to make better use of the IP address space, Internet control messages, and layering

More information

Congestion Control In The Internet Part 2: How it is implemented in TCP. JY Le Boudec 2014

Congestion Control In The Internet Part 2: How it is implemented in TCP. JY Le Boudec 2014 1 Congestion Control In The Internet Part 2: How it is implemented in TCP JY Le Boudec 2014 Contents 1. Congestion control in TCP 2. The fairness of TCP 3. The loss throughput formula 4. Explicit Congestion

More information

Chapter III. congestion situation in Highspeed Networks

Chapter III. congestion situation in Highspeed Networks Chapter III Proposed model for improving the congestion situation in Highspeed Networks TCP has been the most used transport protocol for the Internet for over two decades. The scale of the Internet and

More information

Congestion Control In The Internet Part 2: How it is implemented in TCP. JY Le Boudec 2014

Congestion Control In The Internet Part 2: How it is implemented in TCP. JY Le Boudec 2014 1 Congestion Control In The Internet Part 2: How it is implemented in TCP JY Le Boudec 2014 Contents 1. Congestion control in TCP 2. The fairness of TCP 3. The loss throughput formula 4. Explicit Congestion

More information

COMP/ELEC 429/556 Introduction to Computer Networks

COMP/ELEC 429/556 Introduction to Computer Networks COMP/ELEC 429/556 Introduction to Computer Networks The TCP Protocol Some slides used with permissions from Edward W. Knightly, T. S. Eugene Ng, Ion Stoica, Hui Zhang T. S. Eugene Ng eugeneng at cs.rice.edu

More information

Request for Comments: S. Floyd ICSI K. Ramakrishnan AT&T Labs Research June 2009

Request for Comments: S. Floyd ICSI K. Ramakrishnan AT&T Labs Research June 2009 Network Working Group Request for Comments: 5562 Category: Experimental A. Kuzmanovic A. Mondal Northwestern University S. Floyd ICSI K. Ramakrishnan AT&T Labs Research June 2009 Adding Explicit Congestion

More information

TCP so far Computer Networking Outline. How Was TCP Able to Evolve

TCP so far Computer Networking Outline. How Was TCP Able to Evolve TCP so far 15-441 15-441 Computer Networking 15-641 Lecture 14: TCP Performance & Future Peter Steenkiste Fall 2016 www.cs.cmu.edu/~prs/15-441-f16 Reliable byte stream protocol Connection establishments

More information

ADVANCED COMPUTER NETWORKS

ADVANCED COMPUTER NETWORKS ADVANCED COMPUTER NETWORKS Congestion Control and Avoidance 1 Lecture-6 Instructor : Mazhar Hussain CONGESTION CONTROL When one part of the subnet (e.g. one or more routers in an area) becomes overloaded,

More information

Lecture 4: Congestion Control

Lecture 4: Congestion Control Lecture 4: Congestion Control Overview Internet is a network of networks Narrow waist of IP: unreliable, best-effort datagram delivery Packet forwarding: input port to output port Routing protocols: computing

More information

Investigating the Use of Synchronized Clocks in TCP Congestion Control

Investigating the Use of Synchronized Clocks in TCP Congestion Control Investigating the Use of Synchronized Clocks in TCP Congestion Control Michele Weigle Dissertation Defense May 14, 2003 Advisor: Kevin Jeffay Research Question Can the use of exact timing information improve

More information

Congestion Collapse in the 1980s

Congestion Collapse in the 1980s Congestion Collapse Congestion Collapse in the 1980s Early TCP used fixed size window (e.g., 8 packets) Initially fine for reliability But something happened as the ARPANET grew Links stayed busy but transfer

More information

Random Early Detection Gateways for Congestion Avoidance

Random Early Detection Gateways for Congestion Avoidance Random Early Detection Gateways for Congestion Avoidance Sally Floyd and Van Jacobson Lawrence Berkeley Laboratory University of California floyd@eelblgov van@eelblgov To appear in the August 1993 IEEE/ACM

More information

6.1 Internet Transport Layer Architecture 6.2 UDP (User Datagram Protocol) 6.3 TCP (Transmission Control Protocol) 6. Transport Layer 6-1

6.1 Internet Transport Layer Architecture 6.2 UDP (User Datagram Protocol) 6.3 TCP (Transmission Control Protocol) 6. Transport Layer 6-1 6. Transport Layer 6.1 Internet Transport Layer Architecture 6.2 UDP (User Datagram Protocol) 6.3 TCP (Transmission Control Protocol) 6. Transport Layer 6-1 6.1 Internet Transport Layer Architecture The

More information

Outline Computer Networking. TCP slow start. TCP modeling. TCP details AIMD. Congestion Avoidance. Lecture 18 TCP Performance Peter Steenkiste

Outline Computer Networking. TCP slow start. TCP modeling. TCP details AIMD. Congestion Avoidance. Lecture 18 TCP Performance Peter Steenkiste Outline 15-441 Computer Networking Lecture 18 TCP Performance Peter Steenkiste Fall 2010 www.cs.cmu.edu/~prs/15-441-f10 TCP congestion avoidance TCP slow start TCP modeling TCP details 2 AIMD Distributed,

More information

Overview. TCP congestion control Computer Networking. TCP modern loss recovery. TCP modeling. TCP Congestion Control AIMD

Overview. TCP congestion control Computer Networking. TCP modern loss recovery. TCP modeling. TCP Congestion Control AIMD Overview 15-441 Computer Networking Lecture 9 More TCP & Congestion Control TCP congestion control TCP modern loss recovery TCP modeling Lecture 9: 09-25-2002 2 TCP Congestion Control Changes to TCP motivated

More information

Enhancing TCP Throughput over Lossy Links Using ECN-capable RED Gateways

Enhancing TCP Throughput over Lossy Links Using ECN-capable RED Gateways Enhancing TCP Throughput over Lossy Links Using ECN-capable RED Gateways Haowei Bai AES Technology Centers of Excellence Honeywell Aerospace 3660 Technology Drive, Minneapolis, MN 5548 E-mail: haowei.bai@honeywell.com

More information

Performance Consequences of Partial RED Deployment

Performance Consequences of Partial RED Deployment Performance Consequences of Partial RED Deployment Brian Bowers and Nathan C. Burnett CS740 - Advanced Networks University of Wisconsin - Madison ABSTRACT The Internet is slowly adopting routers utilizing

More information

Transport Layer (Congestion Control)

Transport Layer (Congestion Control) Transport Layer (Congestion Control) Where we are in the Course Moving on up to the Transport Layer! Application Transport Network Link Physical CSE 461 University of Washington 2 Congestion Collapse Congestion

More information

TCP Congestion Control

TCP Congestion Control 1 TCP Congestion Control Onwutalobi, Anthony Claret Department of Computer Science University of Helsinki, Helsinki Finland onwutalo@cs.helsinki.fi Abstract This paper is aimed to discuss congestion control

More information

IJSRD - International Journal for Scientific Research & Development Vol. 2, Issue 03, 2014 ISSN (online):

IJSRD - International Journal for Scientific Research & Development Vol. 2, Issue 03, 2014 ISSN (online): IJSRD - International Journal for Scientific Research & Development Vol. 2, Issue 03, 2014 ISSN (online): 2321-0613 Performance Evaluation of TCP in the Presence of in Heterogeneous Networks by using Network

More information

A Survey on Quality of Service and Congestion Control

A Survey on Quality of Service and Congestion Control A Survey on Quality of Service and Congestion Control Ashima Amity University Noida, U.P, India batra_ashima@yahoo.co.in Sanjeev Thakur Amity University Noida, U.P, India sthakur.ascs@amity.edu Abhishek

More information

Announcements Computer Networking. Outline. Transport Protocols. Transport introduction. Error recovery & flow control. Mid-semester grades

Announcements Computer Networking. Outline. Transport Protocols. Transport introduction. Error recovery & flow control. Mid-semester grades Announcements 15-441 Computer Networking Lecture 16 Transport Protocols Mid-semester grades Based on project1 + midterm + HW1 + HW2 42.5% of class If you got a D+,D, D- or F! must meet with Dave or me

More information

Congestion Control End Hosts. CSE 561 Lecture 7, Spring David Wetherall. How fast should the sender transmit data?

Congestion Control End Hosts. CSE 561 Lecture 7, Spring David Wetherall. How fast should the sender transmit data? Congestion Control End Hosts CSE 51 Lecture 7, Spring. David Wetherall Today s question How fast should the sender transmit data? Not tooslow Not toofast Just right Should not be faster than the receiver

More information

Performance Analysis of TCP Variants

Performance Analysis of TCP Variants 102 Performance Analysis of TCP Variants Abhishek Sawarkar Northeastern University, MA 02115 Himanshu Saraswat PES MCOE,Pune-411005 Abstract The widely used TCP protocol was developed to provide reliable

More information

Congestion Control In The Internet Part 2: How it is implemented in TCP. JY Le Boudec 2015

Congestion Control In The Internet Part 2: How it is implemented in TCP. JY Le Boudec 2015 Congestion Control In The Internet Part 2: How it is implemented in TCP JY Le Boudec 2015 1 Contents 1. Congestion control in TCP 2. The fairness of TCP 3. The loss throughput formula 4. Explicit Congestion

More information

Page 1. Review: Internet Protocol Stack. Transport Layer Services. Design Issue EEC173B/ECS152C. Review: TCP

Page 1. Review: Internet Protocol Stack. Transport Layer Services. Design Issue EEC173B/ECS152C. Review: TCP EEC7B/ECS5C Review: Internet Protocol Stack Review: TCP Application Telnet FTP HTTP Transport Network Link Physical bits on wire TCP LAN IP UDP Packet radio Transport Layer Services Design Issue Underlying

More information

Multiple unconnected networks

Multiple unconnected networks TCP/IP Life in the Early 1970s Multiple unconnected networks ARPAnet Data-over-cable Packet satellite (Aloha) Packet radio ARPAnet satellite net Differences Across Packet-Switched Networks Addressing Maximum

More information

Transport Layer PREPARED BY AHMED ABDEL-RAOUF

Transport Layer PREPARED BY AHMED ABDEL-RAOUF Transport Layer PREPARED BY AHMED ABDEL-RAOUF TCP Flow Control TCP Flow Control 32 bits source port # dest port # head len sequence number acknowledgement number not used U A P R S F checksum Receive window

More information

TCP based Receiver Assistant Congestion Control

TCP based Receiver Assistant Congestion Control International Conference on Multidisciplinary Research & Practice P a g e 219 TCP based Receiver Assistant Congestion Control Hardik K. Molia Master of Computer Engineering, Department of Computer Engineering

More information

Transport Layer. Application / Transport Interface. Transport Layer Services. Transport Layer Connections

Transport Layer. Application / Transport Interface. Transport Layer Services. Transport Layer Connections Application / Transport Interface Application requests service from transport layer Transport Layer Application Layer Prepare Transport service requirements Data for transport Local endpoint node address

More information

A Report on Some Recent Developments in TCP Congestion Control

A Report on Some Recent Developments in TCP Congestion Control A Report on Some Recent Developments in TCP Congestion Control Sally Floyd June 5, 2000 Abstract This paper discusses several changes either proposed or in progress for TCP congestion control. The changes

More information

A Report on Some Recent Developments in TCP Congestion Control

A Report on Some Recent Developments in TCP Congestion Control A Report on Some Recent Developments in TCP Congestion Control Sally Floyd October 9, To appear in IEEE Communications Magazine, April Abstract This paper discusses several changes to TCP s congestion

More information

cs/ee 143 Communication Networks

cs/ee 143 Communication Networks cs/ee 143 Communication Networks Chapter 4 Transport Text: Walrand & Parakh, 2010 Steven Low CMS, EE, Caltech Recap: Internet overview Some basic mechanisms n Packet switching n Addressing n Routing o

More information

Flow and Congestion Control (Hosts)

Flow and Congestion Control (Hosts) Flow and Congestion Control (Hosts) 14-740: Fundamentals of Computer Networks Bill Nace Material from Computer Networking: A Top Down Approach, 6 th edition. J.F. Kurose and K.W. Ross traceroute Flow Control

More information

ROBUST TCP: AN IMPROVEMENT ON TCP PROTOCOL

ROBUST TCP: AN IMPROVEMENT ON TCP PROTOCOL ROBUST TCP: AN IMPROVEMENT ON TCP PROTOCOL SEIFEDDINE KADRY 1, ISSA KAMAR 1, ALI KALAKECH 2, MOHAMAD SMAILI 1 1 Lebanese University - Faculty of Science, Lebanon 1 Lebanese University - Faculty of Business,

More information

Random Early Detection Gateways for Congestion Avoidance

Random Early Detection Gateways for Congestion Avoidance Random Early Detection Gateways for Congestion Avoidance Sally Floyd and Van Jacobson Lawrence Berkeley Laboratory University of California floyd@eelblgov van@eelblgov To appear in the August 1993 IEEE/ACM

More information

Page 1. Review: Internet Protocol Stack. Transport Layer Services EEC173B/ECS152C. Review: TCP. Transport Layer: Connectionless Service

Page 1. Review: Internet Protocol Stack. Transport Layer Services EEC173B/ECS152C. Review: TCP. Transport Layer: Connectionless Service EEC7B/ECS5C Review: Internet Protocol Stack Review: TCP Application Telnet FTP HTTP Transport Network Link Physical bits on wire TCP LAN IP UDP Packet radio Do you remember the various mechanisms we have

More information

TCP Congestion Control

TCP Congestion Control TCP Congestion Control What is Congestion The number of packets transmitted on the network is greater than the capacity of the network Causes router buffers (finite size) to fill up packets start getting

More information

TCP Congestion Control

TCP Congestion Control What is Congestion TCP Congestion Control The number of packets transmitted on the network is greater than the capacity of the network Causes router buffers (finite size) to fill up packets start getting

More information

Transport Layer TCP / UDP

Transport Layer TCP / UDP Transport Layer TCP / UDP Chapter 6 section 6.5 is TCP 12 Mar 2012 Layers Application Transport Why do we need the Transport Layer? Network Host-to-Network/Physical/DataLink High Level Overview TCP (RFC

More information

CS4700/CS5700 Fundamentals of Computer Networks

CS4700/CS5700 Fundamentals of Computer Networks CS4700/CS5700 Fundamentals of Computer Networks Lecture 15: Congestion Control Slides used with permissions from Edward W. Knightly, T. S. Eugene Ng, Ion Stoica, Hui Zhang Alan Mislove amislove at ccs.neu.edu

More information

Transmission Control Protocol (TCP)

Transmission Control Protocol (TCP) TETCOS Transmission Control Protocol (TCP) Comparison of TCP Congestion Control Algorithms using NetSim @2017 Tetcos. This document is protected by copyright, all rights reserved Table of Contents 1. Abstract....

More information

15-744: Computer Networking TCP

15-744: Computer Networking TCP 15-744: Computer Networking TCP Congestion Control Congestion Control Assigned Reading [Jacobson and Karels] Congestion Avoidance and Control [TFRC] Equation-Based Congestion Control for Unicast Applications

More information

Flow and Congestion Control

Flow and Congestion Control CE443 Computer Networks Flow and Congestion Control Behnam Momeni Computer Engineering Department Sharif University of Technology Acknowledgments: Lecture slides are from Computer networks course thought

More information

CS268: Beyond TCP Congestion Control

CS268: Beyond TCP Congestion Control TCP Problems CS68: Beyond TCP Congestion Control Ion Stoica February 9, 004 When TCP congestion control was originally designed in 1988: - Key applications: FTP, E-mail - Maximum link bandwidth: 10Mb/s

More information

Computer Networking Introduction

Computer Networking Introduction Computer Networking Introduction Halgurd S. Maghdid Software Engineering Department Koya University-Koya, Kurdistan-Iraq Lecture No.11 Chapter 3 outline 3.1 transport-layer services 3.2 multiplexing and

More information

User Datagram Protocol (UDP):

User Datagram Protocol (UDP): SFWR 4C03: Computer Networks and Computer Security Feb 2-5 2004 Lecturer: Kartik Krishnan Lectures 13-15 User Datagram Protocol (UDP): UDP is a connectionless transport layer protocol: each output operation

More information

A New Fair Window Algorithm for ECN Capable TCP (New-ECN)

A New Fair Window Algorithm for ECN Capable TCP (New-ECN) A New Fair Window Algorithm for ECN Capable TCP (New-ECN) Tilo Hamann Department of Digital Communication Systems Technical University of Hamburg-Harburg Hamburg, Germany t.hamann@tu-harburg.de Jean Walrand

More information

Investigating the Use of Synchronized Clocks in TCP Congestion Control

Investigating the Use of Synchronized Clocks in TCP Congestion Control Investigating the Use of Synchronized Clocks in TCP Congestion Control Michele Weigle (UNC-CH) November 16-17, 2001 Univ. of Maryland Symposium The Problem TCP Reno congestion control reacts only to packet

More information

Chapter III: Transport Layer

Chapter III: Transport Layer Chapter III: Transport Layer UG3 Computer Communications & Networks (COMN) Mahesh Marina mahesh@ed.ac.uk Slides thanks to Myungjin Lee and copyright of Kurose and Ross Principles of congestion control

More information

TCP reliable data transfer. Chapter 3 outline. TCP sender events: TCP sender (simplified) TCP: retransmission scenarios. TCP: retransmission scenarios

TCP reliable data transfer. Chapter 3 outline. TCP sender events: TCP sender (simplified) TCP: retransmission scenarios. TCP: retransmission scenarios Chapter 3 outline TCP reliable 3.2 principles of reliable 3.3 connection-oriented flow 3.4 principles of congestion 3.5 TCP congestion TCP creates rdt service on top of IP s unreliable service pipelined

More information

PERFORMANCE COMPARISON OF THE DIFFERENT STREAMS IN A TCP BOTTLENECK LINK IN THE PRESENCE OF BACKGROUND TRAFFIC IN A DATA CENTER

PERFORMANCE COMPARISON OF THE DIFFERENT STREAMS IN A TCP BOTTLENECK LINK IN THE PRESENCE OF BACKGROUND TRAFFIC IN A DATA CENTER PERFORMANCE COMPARISON OF THE DIFFERENT STREAMS IN A TCP BOTTLENECK LINK IN THE PRESENCE OF BACKGROUND TRAFFIC IN A DATA CENTER Vilma Tomço, 1 Aleksandër Xhuvani 2 Abstract: The purpose of this work is

More information

Chapter 3- parte B outline

Chapter 3- parte B outline Chapter 3- parte B outline 3.1 transport-layer services 3.2 multiplexing and demultiplexing 3.3 connectionless transport: UDP 3.4 principles of reliable data transfer 3.5 connection-oriented transport:

More information

Flow and Congestion Control Marcos Vieira

Flow and Congestion Control Marcos Vieira Flow and Congestion Control 2014 Marcos Vieira Flow Control Part of TCP specification (even before 1988) Goal: not send more data than the receiver can handle Sliding window protocol Receiver uses window

More information

Explicit Congestion Notification (ECN) in TCP over Wireless Network

Explicit Congestion Notification (ECN) in TCP over Wireless Network 495 Explicit Congestion Notification (ECN) in TCP over Wireless Network Roh.it Ramani * Broadband Access Technology Group Silicon Automation Systems Ltd. Bangalore- 560008, ndia rrohit@sasi.com Abhay Karandikar

More information

CS3600 SYSTEMS AND NETWORKS

CS3600 SYSTEMS AND NETWORKS CS3600 SYSTEMS AND NETWORKS NORTHEASTERN UNIVERSITY Lecture 24: Congestion Control Prof. Alan Mislove (amislove@ccs.neu.edu) Slides used with permissions from Edward W. Knightly, T. S. Eugene Ng, Ion Stoica,

More information

Random Early Detection (RED) gateways. Sally Floyd CS 268: Computer Networks

Random Early Detection (RED) gateways. Sally Floyd CS 268: Computer Networks Random Early Detection (RED) gateways Sally Floyd CS 268: Computer Networks floyd@eelblgov March 20, 1995 1 The Environment Feedback-based transport protocols (eg, TCP) Problems with current Drop-Tail

More information

TCP Congestion Control in Wired and Wireless networks

TCP Congestion Control in Wired and Wireless networks TCP Congestion Control in Wired and Wireless networks Mohamadreza Najiminaini (mna28@cs.sfu.ca) Term Project ENSC 835 Spring 2008 Supervised by Dr. Ljiljana Trajkovic School of Engineering and Science

More information

II. Principles of Computer Communications Network and Transport Layer

II. Principles of Computer Communications Network and Transport Layer II. Principles of Computer Communications Network and Transport Layer A. Internet Protocol (IP) IPv4 Header An IP datagram consists of a header part and a text part. The header has a 20-byte fixed part

More information

TCP Review. Carey Williamson Department of Computer Science University of Calgary Winter 2018

TCP Review. Carey Williamson Department of Computer Science University of Calgary Winter 2018 TCP Review Carey Williamson Department of Computer Science University of Calgary Winter 2018 Credit: Much of this content came courtesy of Erich Nahum (IBM Research) The TCP Protocol Connection-oriented,

More information

MEASURING PERFORMANCE OF VARIANTS OF TCP CONGESTION CONTROL PROTOCOLS

MEASURING PERFORMANCE OF VARIANTS OF TCP CONGESTION CONTROL PROTOCOLS MEASURING PERFORMANCE OF VARIANTS OF TCP CONGESTION CONTROL PROTOCOLS Harjinder Kaur CSE, GZSCCET, Dabwali Road, Bathinda, Punjab, India, sidhuharryab@gmail.com Gurpreet Singh Abstract CSE, GZSCCET, Dabwali

More information

CS 356: Introduction to Computer Networks. Lecture 16: Transmission Control Protocol (TCP) Chap. 5.2, 6.3. Xiaowei Yang

CS 356: Introduction to Computer Networks. Lecture 16: Transmission Control Protocol (TCP) Chap. 5.2, 6.3. Xiaowei Yang CS 356: Introduction to Computer Networks Lecture 16: Transmission Control Protocol (TCP) Chap. 5.2, 6.3 Xiaowei Yang xwy@cs.duke.edu Overview TCP Connection management Flow control When to transmit a

More information

Router participation in Congestion Control. Techniques Random Early Detection Explicit Congestion Notification

Router participation in Congestion Control. Techniques Random Early Detection Explicit Congestion Notification Router participation in Congestion Control 1 Techniques Random Early Detection Explicit Congestion Notification 68 2 Early congestion notifications Early notifications inform end-systems that the network

More information

Reliable Transport II: TCP and Congestion Control

Reliable Transport II: TCP and Congestion Control Reliable Transport II: TCP and Congestion Control Stefano Vissicchio UCL Computer Science COMP0023 Recap: Last Lecture Transport Concepts Layering context Transport goals Transport mechanisms and design

More information

CSE 123A Computer Networks

CSE 123A Computer Networks CSE 123A Computer Networks Winter 2005 Lecture 14 Congestion Control Some images courtesy David Wetherall Animations by Nick McKeown and Guido Appenzeller The bad news and the good news The bad news: new

More information

Equation-Based Congestion Control for Unicast Applications. Outline. Introduction. But don t we need TCP? TFRC Goals

Equation-Based Congestion Control for Unicast Applications. Outline. Introduction. But don t we need TCP? TFRC Goals Equation-Based Congestion Control for Unicast Applications Sally Floyd, Mark Handley AT&T Center for Internet Research (ACIRI) Jitendra Padhye Umass Amherst Jorg Widmer International Computer Science Institute

More information

Analyzing the Receiver Window Modification Scheme of TCP Queues

Analyzing the Receiver Window Modification Scheme of TCP Queues Analyzing the Receiver Window Modification Scheme of TCP Queues Visvasuresh Victor Govindaswamy University of Texas at Arlington Texas, USA victor@uta.edu Gergely Záruba University of Texas at Arlington

More information

CMSC 417. Computer Networks Prof. Ashok K Agrawala Ashok Agrawala. October 25, 2018

CMSC 417. Computer Networks Prof. Ashok K Agrawala Ashok Agrawala. October 25, 2018 CMSC 417 Computer Networks Prof. Ashok K Agrawala 2018 Ashok Agrawala Message, Segment, Packet, and Frame host host HTTP HTTP message HTTP TCP TCP segment TCP router router IP IP packet IP IP packet IP

More information

Tuning RED for Web Traffic

Tuning RED for Web Traffic Tuning RED for Web Traffic Mikkel Christiansen, Kevin Jeffay, David Ott, Donelson Smith UNC, Chapel Hill SIGCOMM 2000, Stockholm subsequently IEEE/ACM Transactions on Networking Vol. 9, No. 3 (June 2001)

More information

Operating Systems and Networks. Network Lecture 10: Congestion Control. Adrian Perrig Network Security Group ETH Zürich

Operating Systems and Networks. Network Lecture 10: Congestion Control. Adrian Perrig Network Security Group ETH Zürich Operating Systems and Networks Network Lecture 10: Congestion Control Adrian Perrig Network Security Group ETH Zürich Where we are in the Course More fun in the Transport Layer! The mystery of congestion

More information

Where we are in the Course. Topic. Nature of Congestion. Nature of Congestion (3) Nature of Congestion (2) Operating Systems and Networks

Where we are in the Course. Topic. Nature of Congestion. Nature of Congestion (3) Nature of Congestion (2) Operating Systems and Networks Operating Systems and Networks Network Lecture 0: Congestion Control Adrian Perrig Network Security Group ETH Zürich Where we are in the Course More fun in the Transport Layer! The mystery of congestion

More information

Transport layer. UDP: User Datagram Protocol [RFC 768] Review principles: Instantiation in the Internet UDP TCP

Transport layer. UDP: User Datagram Protocol [RFC 768] Review principles: Instantiation in the Internet UDP TCP Transport layer Review principles: Reliable data transfer Flow control Congestion control Instantiation in the Internet UDP TCP 1 UDP: User Datagram Protocol [RFC 768] No frills, bare bones Internet transport

More information

6.033 Spring 2015 Lecture #11: Transport Layer Congestion Control Hari Balakrishnan Scribed by Qian Long

6.033 Spring 2015 Lecture #11: Transport Layer Congestion Control Hari Balakrishnan Scribed by Qian Long 6.033 Spring 2015 Lecture #11: Transport Layer Congestion Control Hari Balakrishnan Scribed by Qian Long Please read Chapter 19 of the 6.02 book for background, especially on acknowledgments (ACKs), timers,

More information

Transport layer. Review principles: Instantiation in the Internet UDP TCP. Reliable data transfer Flow control Congestion control

Transport layer. Review principles: Instantiation in the Internet UDP TCP. Reliable data transfer Flow control Congestion control Transport layer Review principles: Reliable data transfer Flow control Congestion control Instantiation in the Internet UDP TCP 1 UDP: User Datagram Protocol [RFC 768] No frills, bare bones Internet transport

More information

Buffer Requirements for Zero Loss Flow Control with Explicit Congestion Notification. Chunlei Liu Raj Jain

Buffer Requirements for Zero Loss Flow Control with Explicit Congestion Notification. Chunlei Liu Raj Jain Buffer Requirements for Zero Loss Flow Control with Explicit Congestion Notification Chunlei Liu Raj Jain Department of Computer and Information Science The Ohio State University, Columbus, OH 432-277

More information

Outline. TCP: Overview RFCs: 793, 1122, 1323, 2018, steam: r Development of reliable protocol r Sliding window protocols

Outline. TCP: Overview RFCs: 793, 1122, 1323, 2018, steam: r Development of reliable protocol r Sliding window protocols Outline r Development of reliable protocol r Sliding window protocols m Go-Back-N, Selective Repeat r Protocol performance r Sockets, UDP, TCP, and IP r UDP operation r TCP operation m connection management

More information

Traffic Management using Multilevel Explicit Congestion Notification

Traffic Management using Multilevel Explicit Congestion Notification Traffic Management using Multilevel Explicit Congestion Notification Arjan Durresi, Mukundan Sridharan, Chunlei Liu, Mukul Goyal Department of Computer and Information Science The Ohio State University

More information

Outline Computer Networking. Functionality Split. Transport Protocols

Outline Computer Networking. Functionality Split. Transport Protocols Outline 15-441 15 441 Computer Networking 15-641 Lecture 10: Transport Protocols Justine Sherry Peter Steenkiste Fall 2017 www.cs.cmu.edu/~prs/15 441 F17 Transport introduction TCP connection establishment

More information

Computer Networking. Queue Management and Quality of Service (QOS)

Computer Networking. Queue Management and Quality of Service (QOS) Computer Networking Queue Management and Quality of Service (QOS) Outline Previously:TCP flow control Congestion sources and collapse Congestion control basics - Routers 2 Internet Pipes? How should you

More information

Quantifying the Effects of Recent Protocol Improvements to Standards-Track TCP * (Extended Version)

Quantifying the Effects of Recent Protocol Improvements to Standards-Track TCP * (Extended Version) Quantifying the Effects of Recent Protocol Improvements to Standards-Track TCP * (Extended Version) Michele C. Weigle, Kevin Jeffay, and F. Donelson Smith Department of Computer Science University of North

More information

CSC 8560 Computer Networks: TCP

CSC 8560 Computer Networks: TCP CSC 8560 Computer Networks: TCP Professor Henry Carter Fall 2017 Project 2: mymusic You will be building an application that allows you to synchronize your music across machines. The details of which are

More information

Reasons not to Parallelize TCP Connections for Fast Long-Distance Networks

Reasons not to Parallelize TCP Connections for Fast Long-Distance Networks Reasons not to Parallelize TCP Connections for Fast Long-Distance Networks Zongsheng Zhang Go Hasegawa Masayuki Murata Osaka University Contents Introduction Analysis of parallel TCP mechanism Numerical

More information

Reliable Transport II: TCP and Congestion Control

Reliable Transport II: TCP and Congestion Control Reliable Transport II: TCP and Congestion Control Brad Karp UCL Computer Science CS 3035/GZ01 31 st October 2013 Outline Slow Start AIMD Congestion control Throughput, loss, and RTT equation Connection

More information

TCP. CSU CS557, Spring 2018 Instructor: Lorenzo De Carli (Slides by Christos Papadopoulos, remixed by Lorenzo De Carli)

TCP. CSU CS557, Spring 2018 Instructor: Lorenzo De Carli (Slides by Christos Papadopoulos, remixed by Lorenzo De Carli) TCP CSU CS557, Spring 2018 Instructor: Lorenzo De Carli (Slides by Christos Papadopoulos, remixed by Lorenzo De Carli) 1 Sources Fall and Stevens, TCP/IP Illustrated Vol. 1, 2nd edition Congestion Avoidance

More information

Wireless TCP Performance Issues

Wireless TCP Performance Issues Wireless TCP Performance Issues Issues, transport layer protocols Set up and maintain end-to-end connections Reliable end-to-end delivery of data Flow control Congestion control Udp? Assume TCP for the

More information