UNIVERSITY OF NAIROBI STABILITY OF TCP/IP PROTOCOLS

Transcription

1 UNIVERSITY OF NAIROBI STABILITY OF TCP/IP PROTOCOLS PROJECT INDEX: PRJ 148 BY NAME: NJERU PATRICK MAGOCHI REG. NO: F17/1360/2010 SUPERVISOR: DR. G.S. ODHIAMBO EXAMINER: PROF. V.K. ODUOL Project report submitted in partial fulfillment of the requirement for the award of the degree of Bachelor of Science in Electrical and Electronic Engineering of the University of Nairobi Date of Submission: 23 RD April, Department of Electrical and Information Engineering i

2 DECLARATION OF ORIGINALITY FORM This form must be completed and signed for all works submitted to the University for Examination. Name of Student Registration Number College Faculty/School/Institute Department NJERU PATRICK MAGOCHI F17/1360/2010 Architecture and Engineering Engineering Electrical and Information Engineering Course Name Title of the Work Bachelor of Science in Electrical & Electronic Engineering Stability of TCP/IP Protocols DECLARATION 1. I understand what Plagiarism is and I am aware of the University s policy in this regard 2. I declare that this final year report is my original work and has not been submitted elsewhere for examination, award of a degree or publication. Where other people s work or my own work has been used, this has properly been acknowledged and referenced in accordance with the University of Nairobi s requirements. 3. I have not sought or used the services of any professional agencies to produce this work 4. I have not allowed, and shall not allow anyone to copy my work with the intention of passing it off as his/her own work 5. I understand that any false claim in respect of this work shall result in disciplinary action, in accordance with University Plagiarism Policy Signature Date ii

3 DEDICATION To Dad and Mum. iii

4 ACKNOWLEDGEMENT Although this project bears the name of one person, it s surely not the product of just one person s work. I would like to sincerely thank my supervisor Dr. G. S. Odhiambo for all the guidance that he accorded me during this period. My appreciation also goes to my friends and classmates for their opinions, suggestions and criticisms of this work. Lastly my family, without whom all this wouldn t be possible. iv

5 CONTENTS 1. CHAPTER INTRODUCTION CHAPTER AN OVERVIEW OF CONGESTION AVOIDANCE IN TCP TCP OVERVIEW ADDITIONAL TCP DETAILS CONNECTION HANDLING: THE THREE WAY HANDSHAKE FLOW CONTROL: THE SLIDING WINDOW CONGESTION COLLAPSE TCP VARIANTS LOSS-BASED TCP PROTOCOLS VARIANTS DELAY-BASED TCP PROTOCOLS CONTROLLING CONGESTION: DESIGN ALGORITHMS THE ERRONEOUS RETRANSMISSION TIMEOUT (RTO) ESTIMATE PROBLEMS THE PACKET LOSS DETECTION PROBLEM DETECTING AVAILABLE NETWORK RESOURCES AND ADJUSTING RATE TO DETECTED RATE FAIR RESOURCE SHARING OF TCP ALGORITHMS CHAPTER A SIMPLE MODEL FOR TCP-RENO INTRODUCTION TO TCP RENO MATHEMATICAL MODELLING TCP RENO SIMULATION USING NS CHAPTER CONCLUSION v

6 ABBREVIATIONS ACK Acknowledgements AIMD Additive Increase Multiplicative Decrease CMND congestion Window FTP File Transfer Protocol IP Internet Protocol RTO R T O RTT Round Trip Time SACK Selective Acknowledgements SYN - Synchronization TCP Transmission Control Protocol UDP User Datagram Protocol vi

7 TABLE OF FIGURES Figure 1 Kenya internet users Figure 2 TCP packet format... 6 Figure 3 TCP Three way handshake... 7 Figure 4 The buffer of a TCP sender... 8 Figure 5 Evolutionary graph of TCP variants that solve the congestion collapse problem Figure 6 Congestion window dynamics and effectiveness of slow start Figure 7 Congestion window dynamics and effectiveness of Congestion Avoidance Figure 8 Slow-Start Algorithm Figure 9 Congestion avoidance (AIMD) Figure 10 Characteristic states of TCP Reno s Fast Recovery Figure 11 Congestion window dynamics of TCP Reno Figure 12 Topology for same delay and same link capacities Figure 13 Topology for different link delays but same capabilities Figure 14 Topology for TCP Reno link with high available capacity Figure 15 TCP Reno at equal delay and equal link capacities Figure 16 TCP Reno with different delay but same link capacity Figure 17 TCP Reno with high bandwidth allocation vii

8 ABSTRACT The internet is emerging to be the basic need of our times impacting our social lives, the way companies do business, the education sector and even government. There has hence been a huge almost exponential rise in the number of internet users in recent times. In this journey, the internet has also evolved from a simple research project at the Defense Advanced Research Projects Agency (DARPA) to a global interconnected network on which most critical aspects of our lives depend on. This increase and dependency on the internet has resulted in a form of congestion collapse where service providing servers are unable to service their workload and users are competing for available bandwidth. The basic idea of this work is to simulate TCP Reno using NS2 at different delay times and window size, to find out its stability. The result is that TCP-Reno is not a scalable protocol, i.e., its stability is compromised if either the RTT of the users is large or if the available capacity per user at the router is large. This leaves room for research into techniques aimed at improving TCP s Congestion Control algorithms abilities. viii

9 1. Chapter INTRODUCTION Transmission Control Protocol (TCP) is one of the core protocols of the TCP/IP Protocol Suite. TCP is used to provide reliable data transmission between two nodes and works at the transport layer of the TCP/IP model. TCP operates at a higher level of the stack, concerned only with the two end systems, for example, a Web browser and a Web server. In particular, TCP provides reliable, ordered delivery of a stream of bytes from a program on one computer to another program on another computer. Besides the Web, other common applications of TCP include e- mail and file transfer. Among its other management tasks, TCP controls message size, the rate at which messages are exchanged, and network traffic congestion. As the global Internet traffic increases, many popular sites are often unable to serve their TCP/IP workload, particularly during peak periods of activity. Recent examples in Kenya include server outages during elections and exam releases. The graph below shows that as of 2014, 64.3% of Kenyans were using the internet [1]. To address this issue many servers are allocated to service host requests. But what happens when sometimes even the requests do not reach the servers? Since network traffic is similar, a method is needed to support workload sharing especially at bottleneck links. This is to ensure that one user does not use up all the bandwidth while other users are disconnected. It also ensures that each user gets the maximum fair share of the available resources. 1

10 Figure 1 Kenya internet users 2014 Unless for very privileged users, the internet simply provides a best effort delivery of data; without any guarantees. Sometimes your files download in a few seconds and other times it takes a few minutes, at extreme times you cannot download files. This report goes into detail on TCP congestion handling. Chapter 2 starts with an introduction of TCP, its features and variants. Chapter 3 describes a mathematical model for analyzing TCP Reno, one of TCP s variants then verifies this mathematical model by simulating TCP Reno s performance in NS2. 2

11 2. Chapter AN OVERVIEW OF CONGESTION AVOIDANCE IN TCP In this chapter we describe TCP in relation to congestion control. This chapter is organized as follows. Section 2.1 and 2.2 provides some background information on TCP and describes the features that can exist in a typical TCP flow. In section 2.3 we look at congestion collapse. In section 2.4 we analyse the main TCP variants. Section 2.5 provides an analysis of algorithms that control congestion TCP OVERVIEW TCP is one part of two well-known protocol standards commonly referred to as TCP/IP. TCP sits on top of the IP layer and passes segments onto the IP layer for further processing. These segments are then passed onto the lower level layers and eventually onto the network. TCP was officially adopted as a standard in RFC 793 in 1981 and was designed to deal with message flow control and error correction, ensuring reliable delivery of a message from a source application to a destination application. IP was also officially adopted as a standard in RFC 791 in IP deals with logical addressing and specifies source and destination addresses. These address are used to route a message to its destination and to provide a return address for any response. 3

12 The origins of TCP/IP stem from DARPA research into resilient networks for use in a battlefield environment. The goal of this research was to design a protocol suite that could cope with network link failure and ensure delivery of data to its destination [2]. As TCP/IP evolved it moved from the research environment to be deployed in isolated networks that were eventually interconnected to become what we now know as the Internet. The Internet Protocol suite employs two transport control protocols: The connection oriented Transmission Control Protocol (TCP) and the connectionless User Datagram Protocol (UDP). TCP is reliable as it ensures that transmitted data is delivered and that packets are received in the correct order whereas UDP does not ensure the data delivery and is unreliable. A significant amount of today s internet traffic including web pages namely world wide web (www) or hypertext transfer protocol (http), file transfer such as file transfer protocol (ftp), based on Simple Mail Transfer Protocol (SMTP) and remote access traffic e.g. Telnet, is carried by the TCP Additional TCP Details In this section we briefly describe some additional features of TCP relevant to this research. A TCP packet format is as showed below. The TCP packet comprises the following fields: Source Port and Destination Port. Identifies points at which upper-layer source and destination applications receive TCP services. Sequence Number. Specifies the number assigned to the first byte of data in the current message. In the TCP handshake phase, this field also can be used to identify an initial sequence number to be used in an upcoming transmission. 4

13 Acknowledgment Number. Contains the sequence number of the next byte of data the source of the packet expects to receive. Length. Indicates the number of 32-bit words in the TCP header. Flags. Carries a variety of control information, including the SYN and ACK bits used for connection establishment, and the FIN bit used for connection termination. Window Size. Specifies the size of the source s receive window (that is, the buffer space available at the destination for incoming data). Checksum. Indicates whether the header was damaged in transit. Urgent Data Pointer. Points to the first urgent data byte in the packet. Options. Specifies various TCP options such as the MSS, the window scale value and the time the packet was sent. Also used by SACK receivers to pass lost packet information back to the source. 5

14 Figure 2 TCP packet format Connection Handling: The three way handshake TCP initiates a three part handshake to establish a connection with a destination. This handshake is used to set up initial conditions for the connection and works in the following way: 6

15 Figure 3 TCP Three way handshake Host 1 sends a segment with the SYN flag set in order to initiate a connection. Host 2 replies with a SYN, ACK (both the SYN and ACK flags in the TCP header are set), and finally, Host 1 acknowledges that the connection is now active with an ACK. These first segments of a connection also carry the initial sequence numbers, and they can be used for some additional tasks. At the end of the actual data flow, the connection is terminated as shown in Figure 3(b). In contrast to the connection establishment procedure, a four-way handshake is carried out in order to ensure that the connection is correctly terminated from both ends Flow control: The Sliding Window TCP uses window-based flow control. This means that the receiver carries out flow control by granting the sender a certain amount ( window ) of data; the sender must not send more than the full window without waiting for acknowledgements at any time. Sliding window protocols require the sender and receiver to keep track of a number of variables; the things that the sender must know about are illustrated in Figure 3.3. In the depicted scenario, ten segments were placed 7

16 in the buffer for transmission. The receiver advertised a window of six segments; note that all these numbers refer to bytes and not to segments in TCP thus, the Window field in the header carries a value of 6 MSS in our example. Segments 0 and 1 were transmitted and acknowledged and can be removed from the buffer. Segments 2, 3 and 4 were transmitted but not yet acknowledged, and segments 5, 6 and 7 are ready for transmission because the window spans across these segments. If an acknowledgement for segment 2 arrives and the advertised window remains the same, the sender can advance ( slide ) its window by one segment then, segment 2 can be discarded and segment 8 becomes ready for transmission. Segment 9 can only be sent when the next acknowledgement arrives. All this remains relatively simple as long as the window size is fixed. In practice, the window can change: for example, the ACK for segment 2 could contain an advertised window of seven segments, which would allow the sender to transmit all the buffered segments (the window opens). Similarly, it could contain an advertised window of five segments, which means that the window closes the left edge advances, but the right stays the same. Window Sent and acknowled g ed Sent, not ACKed Can be sent Must wait until window move s Figure 4 The buffer of a TCP sender What if the advertised window in this ACK is of four segments? Since we cannot skip data, this would mean that the right edge moves to the left the window shrinks, and any segments to the right of this edge theoretically should not have been sent, even if they already were. Shrinking is 8

17 ugly, and according to RFC 793, it is strongly discouraged but still possible in TCP. RFC 1122 says that a TCP sender must be able to cope with receivers that shrink the window CONGESTION COLLAPSE The initial TCP standard has a serious drawback: it lacks any means to adjust the transmission rate to the state of the network. When there are many users and user demands for shared network resources, the aggregate rate of all TCP senders sharing the same network can easily exceed (and in practice do exceed) the capacity of the network. It is commonly known in the flow-control world that if the offered load in an uncontrolled distributed sharing system (e.g., road traffic) exceeds the total system capacity, the effective load will go to zero (collapses) as load increases [3]. With regard to TCP, the origins of this effect, known as a congestion collapse can be illustrated using a simple example. Let us consider a router placed somewhere between networks A and B which generate excessive amounts of TCP traffic. Clearly, if the path from A to B is congested by 400% (4 times more than the router can deliver), at least 75% of all packets from network A will be dropped and at most 25% of data packets may result in ACKs. If the reverse path from B to A is also congested (also by 400%, for example), the chance that ACK packets get through is also 25%. In other words, only 25% of 25% (i.e., 6.25%) of the data packets sent from A to B will be acknowledged successfully. If we assume that each data packet requires its own acknowledgement (not a requirement for TCP, but serves to illustrate the point), then a 75% loss in each direction causes a 93.75% drop in throughput (good put) of the TCP like flow [4]. 9

18 2.4. TCP VARIANTS To resolve the congestion collapse problem, a number of solutions have been proposed. All of them share the same idea, namely of introducing a network-aware rate limiting mechanism alongside the receiver-driven flow control. For this purpose the congestion window concept was introduced: a TCP sender s estimate of the number of data packets the network can accept for delivery without becoming congested. In the special case where the flow control limit (the so called receiver window) is less than the congestion control limit (i.e., the congestion window), the former is considered a real bound for outstanding data packets [4]. RFC 793 Tahoe Reno DUAL FACK New Reno Vegas Vegas+ Veno Vegas A Reactive Proactive (loss-based) (delay-based) Figure 5 Evolutionary graph of TCP variants that solve the congestion collapse problem 10

19 Loss-based TCP protocols variants These are the protocols which uses packet drop probability as the main factor for adjusting the window size. These variants of TCP use congestion control algorithms. There were developed initially and are still used. Loss based TCP protocols are more aggressive than the delay based TCP protocols. These are classified as TCP Tahoe and TCP Reno Delay-based TCP Protocols Delay-based algorithms were developed so as to provide stable throughput at the receiver end. These TCP variants use congestion avoidance algorithms to avoid the packet loss and are less aggressive than packet loss based TCP protocols. Delay-based algorithms can maintain a constant window size, avoiding the oscillations inherent in loss-based algorithms. However, they also detect congestion earlier than loss based algorithms, since delay corresponds to partially filled buffers, while loss results from totally filled buffers. This can be either a strength or a weakness. If the only protocol used in a network is delay-based, then the inefficiency of loss can be avoided; however, if loss-based and delay-based protocols share the network, then delaybased algorithms tend to be less aggressive. These are the protocols which uses queuing delay as the main factor for adjusting the window size. These variants were developed so as to provide stable throughput at the receiver end. These TCP variants use congestion avoidance algorithms to avoid the packet loss and are less aggressive than packet loss based TCP protocols. These are classified as TCP Vegas and Fast TCP. 11

20 2.5. CONTROLLING CONGESTION: DESIGN ALGORITHMS The TCP variants discussed above employ one or more congestion control algorithms to prevent TCP users from collapsing the network [5]. This section aims to explain the design algorithms that TCP variants use and they are discussed according to the problems that they solve THE ERRONEOUS RETRANSMISSION TIMEOUT (RTO) ESTIMATE PROBLEMS If this value is overestimated, the TCP packet loss detection mechanism becomes very conservative, and performance of individual flows may severely degrade. In the opposite case, when the value of the RTO is underestimated, the error detection mechanism may perform unnecessary retransmissions, wasting shared network resources and worsening the overall congestion in the network. Since it is practically impossible to distinguish between an ACK for an original and a retransmitted packet, RTO calculation is further complicated. THE ROUND-TRIP VARIANCE ESTIMATION (RTTVAR) ALGORITHM tries to mitigate the overestimation problem. Instead of a linear relationship between the RTO and estimated round-trip time (RTT) value (β SRTT, in which β is a constant in range from 1.3 to 2 and SRTT is an exponentially averaged RTT value), the algorithm calculates an RTT variation estimate to establish a fine-grained upper bound for the RTO (SRTT + 4 rttvar) [6]. THE EXPONENTIAL RETRANSMIT TIMER BACKOFF ALGORITHM solves the underestimation problem by doubling the RTO value on each retransmission event. In other 12

21 words, during severe congestion, detection of subsequent packet losses results in exponential RTO growth, significantly reducing the total number of retransmissions and helping stabilize the network state. The ACK ambiguity problem is resolved by KARN S CLAMPED RETRANSMIT BACKOFF algorithm [7]. Importantly, the RTT of a data packet that has been retransmitted is not used in calculation for the average RTT and RTT variance, and thus it has no impact on the RTO estimate The packet loss detection problem The original TCP specification defines the RTO as the only loss detection mechanism. Although it is sufficient to reliably detect all losses, this detection is not fast enough. Clearly, the minimum time when loss can be detected is the RTT i.e., if the receiver is able to instantly detect and report a loss to the sender, the report will reach the sender exactly one RTT after sending the lost packet. The fast Retransmit Algorithm. Duplicate ACKs that were mentioned to be one way of detecting lost packets, can also be caused by reordered packets. When receiving one duplicate ACK the sender cannot yet know whether the packet has been lost or just gotten out of order but after receiving several duplicate ACKs it is reasonable to assume that a packet loss has occurred. The purpose of fast retransmit mechanism is to speed up the retransmission process by allowing the sender to retransmit a packet as soon as it has enough evidence that a packet has been lost. This means that instead of waiting for the retransmit timer to expire, the sender can retransmit a packet immediately after receiving three duplicate ACKs. 13

22 Detecting Available network resources and Adjusting rate to detected rate. Assuming random packet corruption during transmission is negligible, then the sender can treat all detected packet losses as congestion indicators. In addition, the reception of any ACK packet is an indication that the network can accept and deliver at least one new packet (i.e., the ACKed packet has left and a new one can enter the network). Thus the sender, reasonably sure it will not cause congestion, can send at least the amount of data that has just been acknowledged. The slow start algorithm reception of an ACK packet is considered an invitation to send double the amount of data that has been acknowledged by the ACK packet (multiplicative increase policy). In other words, instead of a step-like growth in the number of outstanding packets (as given in the original specification [6]), this growth follows an exponential function on an RTTdefined scale (Figure 6). The word slow in the algorithm name makes reference to this difference. If a packet loss is detected (i.e., the network is experiencing congestion because all network resources have been utilized), the congestion window is reset to the initial value (e.g., one) to ensure release of network resources. Graphs on Figure 6 show two cases of the congestion window dynamics: the left graph represents the case when the receiver cannot process at the receiving rate (i.e., the original assumption of TCP), and the right graph shows the congestion window dynamics when the network cannot deliver everything at the transmitted rate. 14

23 Receiver limit Network limit Network limit Receiver limit Time Time Detected packet loss Figure 6 Congestion window dynamics and effectiveness of slow start Congestion Avoidance Algorithm. It s aimed at improving TCP effectiveness in networks with limited resources. As opposed to doubling the congestion window increases by one only if all data packets have been successfully delivered during the last RTT. Also in contrast to restarting at one after a loss, the congestion window is merely halved. This is known as Additive Increase Multiplicative Decrease (AIMD). 15

24 Loss detection Network limit Time Figure 7 Congestion window dynamics and effectiveness of Congestion Avoidance 2.6. FAIR RESOURCE SHARING OF TCP ALGORITHMS Due to the resource-sharing nature of IP networks, TCP algorithms should enforce fair resource sharing. Chiu and Jain developed a fairness measure F (the so-called Jain s fairness index) as a function of network resources consumed by each user sharing the same path: F =(_nifi)2n _nif2i Where n is the number of users sharing the path and fi is the network share of i th user. If we assume that each user as only one TCP connection per particular network path, then Jain s index can be considered a fairness measure for TCP flows. This index ranges from 0 to 1, where 1 is achieved if and only if each flow has an equal (fair) share (fi = fj i, j) and tends to zero if a single flow usurps all network resources (limn F = 0) [8]. 16

25 Slow Start and Congestion Avoidance exhibit good fairness (F 1) under certain network conditions as follows. Let us consider two flows competing with each other on the same network path and with no other flows present. If we assume that (a) the network share for each flow is directly proportional to its congestion window size, (b) both flows have equal RTT values, and (c) we can simultaneously detect packet losses (a so-called synchronized loss environment), then the network share dynamics for each algorithm can be represented by the convergence diagrams in Figures 8 and 9. The equal share line represents states when network resources are fairly distributed between flows and the network limit line when all network resources are consumed (either by one or both flows). These diagrams show how network resource proportions would change (paths x0 x1, x1 x2...xn 1 xn) if two TCP flows started competing with each other from an initial state x0 under the ideal network conditions. In Figure 8 the aggressive (multiplicative) congestion window increase in Slow Start favours the flow having a larger network share. More precisely, the slope of x0 x1 segment is proportional to the ratio between each flow s share in state x0. After detection of a packet loss, both flows reset their congestion windows (x1 x2). Obviously, resetting of the congestion window equalizes the network share of the flows that provides fairness of the network resource distribution in the future (the flows become locked-in between the states x2 and x3). 17

26 Network Limit x 3 Packet Losses x 1 x 0 Network Share (flow1) Figure 8 Slow-Start Algorithm x0 x increase1,..., x rate n xo fn+1 their multiplicative congestion windows)increase (both flows have the same x1 x2 equalization of the congestion window sizes Congestion Avoidance ensures a uniform congestion window increase by each flow from any initial state (45 slope of x1 x2 and xn xn+1 segments in Figure 9). This property eliminates the necessity of the congestion window equalization. Instead, to provide fair network usage between flows, it is enough that the flow having a larger network share decreases by a greater amount. In fact, the multiplicative decrease (i.e., congestion window halving) as a reaction to a packet loss in Congestion Avoidance guarantees share equalization (fairness) in a finite number of steps [4]. 18

27 Network Limit x n+1 Packet Losses x n x 1 x 2 x 0 Network Share (flow1) Figure 9 Congestion avoidance (AIMD) x0 x1, rate...,of xn their xncongestion+1 additive windows)increase (both flows have the same increase x1 x2,..., xn 1 xn multiplicative decrease (a flow with the larger congestion window decreases more than a flow with the smaller) 19

28 3. Chapter A SIMPLE MODEL FOR TCP-RENO Introduction to TCP Reno As a solution to congestion collapse problem, TCP Reno seeks to improve the performance of TCP by revising the original composition of slow start and congestion avoidance by differentiating between major and minor congestion events. Reducing the congestion window to one packet as a reaction to packet loss, as occurs with TCP Tahoe, is rather draconian and can, in some cases, lead to significant throughput degradation. For example, a 1% packet loss rate can cause up to a 75% throughput degradation of a TCP flow running the Tahoe algorithm [9]. A loss detection through the retransmission timeout indicates that for a certain time interval (as an example, RTO minus RTT) some major congestion event has prevented delivery of any data packets on the network. Therefore, the sender should apply the conservative policy of resetting the congestion window to a minimal value. Quite a different state can be inferred from a loss detected by duplicate ACKs. Suppose the sender has received four ACKs, where the first one acknowledges some new data and the rest are the exact copies of the first one (usually referred to as three duplicate ACKs). The duplicate ACKs indicate that the some packets have failed to arrive. Nonetheless, presence of each ACK including the duplicates indicates the successful delivery of a data packet. The sender, in addition to detecting the lost packet, is also observing the ability of the network to deliver some data. Thus, the network state can be considered to be lightly congested, and the reaction to the loss event can be more optimistic. In TCP Reno, the optimistic reaction is to use the Fast 20

29 Recovery algorithm [10]. The intention of Fast Recovery is to halve a flow s network share (i.e., to halve the congestion window) and to taper back network resource probing (holding all growth in the congestion window) until the error is recovered. In other words, the sender stays in Fast Recovery until it receives a non-duplicate acknowledgment. The algorithm phases are illustrated in Figure 10, where congestion window sizes (cwnd) in various states are denoted as the line segments above the State lines, and the arrows indicate the effective congestion window size the amount of packets in transit. Figure 10 Characteristic states of TCP Reno s Fast Recovery The transition from State 1 to State 2 shows the core concept of optimistic network share reduction, using the multiplicative decrease policy. After the reduction (i.e., from cwnd to cwnd/2), the algorithm not only retransmits the oldest unacknowledged data packet (i.e., applies the Fast Retransmit algorithm), but also inflates the congestion window by the number of 21

30 duplicate packets (see transition from State 2 to State 3 in Figure 14). As we already know, an ACK indicates delivery of at least one data packet. Thus, if we want to maintain a constant number of packets in transit, we have to inflate our congestion window to open a slot for sending new data (State 4 in Figure 14). Without this increase, new packets cannot be sent before the error is recovered, and the amount of packets in transit can decrease more than expected. In the final stage (State 5), when a non-duplicate ACK is received, we want to resume Congestion Avoidance with half of the original congestion window. With high probability, the non-duplicate ACK will acknowledge delivery of all data packets previously inferred by the duplicate ACKs previously received. At this point, congestion window deflation to cwnd/2 (to the value just after entering recovery, State 2 in Figure 14) is a simple and reliable way to ensure the target exit state from Fast Recovery. The resulting theoretical congestion window dynamics in TCP Reno are Loss detection Network limit ssthresh Time SS FR CA Figure 11 Congestion window dynamics of TCP Reno 22

31 (SS: the Slow Start phase, CA: the Congestion Avoidance phase, FR: the Fast Recovery phase) Compared to the dynamics of TCP Tahoe (Figure 9), the overall effectiveness in the steady state is considerably improved by replacing Slow Start phases after each loss detection by typically shorter Fast Retransmit phases [4]. In fact, recovering from a single loss would usually occur within one RTT. However, efficiency is improved not only by shortening the recovery period, but also by allowing data transfers during the recovery. Having substantial performance improvement compared to Tahoe, TCP Reno remains fair to other TCP Reno flows. Due to its simplicity and performance characteristics, Reno is generally the congestion control standard for TCP. At the same time, there are a wide range of network environments where Reno has inadequate performance. For example, it has severe performance degradation in the presence of consecutive packet losses, random packet losses, and reordering of packets. It is also unfair if competing flows have different RTTs, and it does not utilize high-speed/long-delay network channels efficiently MATHEMATICAL MODELLING The TCP-Reno algorithm is quite complicated and therefore, for our modelling purposes, we consider the following simplified version of the algorithm. Assume that there is a mechanism for the receiver to indicate to the source that a packet has been lost in the network. Then, the essential features of the TCP-Reno algorithm can be summarized as below: Upon receipt of a ack, the source increases its current window size, denoted by cwnd, as follows: cwnd cwnd + 1/cwnd. 23

32 Upon being informed of a loss, the source decreases its window size by a factor of two: cwnd cwnd/2. The key feature of TCP-Reno is that it increases its window size when it does not detect congestion which is indicated by the reception of an ack, and it decreases its window size upon detecting congestion, which is indicated by the detection of a lost packet. We now present a differential equation model that describes the TCP Reno congestion control algorithm. Consider N TCP-Reno sources, all with the same RTT, accessing a single link. Let Wr(t) denote the window size of flow r, T be its RTT, and q(t) be the fraction of packets lost at the link at time t. Then, the congestion avoidance phase of TCP-Reno can be modelled as where xr(t) = Wr(t)/T is the transmission rate. The parameter β is the decrease factor and is taken to be 1/2 although studies show that a more precise value of β when making a continuous-time approximation of TCP s behaviour is closer to 2/3. Substituting for Wr(t) in terms of xr(t) gives The loss probability q(t) is a function of the arrival rate at the link. Thus, let Where f( ) is an increasing function and y(t) is the total arrival rate at the link and is given by 24

33 The equilibrium value of xr is easily seen to be Where qˆ is the equilibrium loss probability. The functional form of f(y) could be quite complicated in general. Among other things, it will depends on the assumptions on the stochastic behaviour of the packet arrival process at the router. To simplify the analysis, we will assume that f(y) is of the form Thus, this form of f(y) can be interpreted as a fluid approximation to the loss probability: it is equal to zero if the arrival rate is less than the capacity of the link and is otherwise equal to the fraction by which the arrival rate exceeds the link capacity. Recall that the RTT T consists of two components, namely the propagation delay Tp and the queuing delay at the router. Just like the loss probability, it is difficult to precisely capture the queuing delay using a simple analytical formula. To obtain a tractable expression for the queuing delay, we recall that the TCP-Reno protocol attempts to fill up the buffer at the router and uses the resulting packet loss to obtain congestion information. Therefore, it seems reasonable to assume that the queue is full most of 25

34 time. Under this assumption, our approximation to the queuing delay takes the form B/c, where B is the buffer size at the router. Thus, for all users, the RTT is given by To study the stability of the congestion controller given in (2), we first linearize the system around its equilibrium point. Defining δxr = xr xˆr, and δq = q q, the linearized form of the congestion control algorithm is given by Defining δy = y y,ˆ and using the equilibrium relationship (3) yields From Hayes lemma [7], the linearized delay-differential equation describing TCP-Reno s dynamics is stable if one of the following conditions is satisfied: α1 α2, α1 < α2 and 26

35 For the first condition to be satisfied, we require qˆ 1/2. This is not a practical scenario since it requires at least half the packets to be dropped at the router. The second condition can be written as Note that the equilibrium relationship (3) can be rewritten as If we let c/n (which is simply the capacity per user) be a constant and increase the RTT, then it is clear from the previous equation that qˆ must decrease. Thus, for large T, the right-hand side of the stability condition can be approximated by letting qˆ = 0 which gives the following condition for stability c N T < π 2β 27

36 Clearly, this condition will be violated as T increases or c/n increases. From the above analysis, we can conclude that TCP-Reno is not a scalable protocol, i.e., its stability is compromised if either the RTT of the users is large or if the available capacity per user at the router is large TCP RENO SIMULATION USING NS2 To simulate the stability of TCP RENO by comparing the congestion window at different delays and or speed of links. NS2 a discrete event simulator targeted at network research is used. Simulation is based on the dumbbell topology shown in figure below in which two sources i.e. N1 and N2 are sending TCP Reno data to sink nodes i.e. N4 and N5 through a bottleneck shared link between nodes N0 and N3. These nodes hence act as routers that forward data over the network. In the first instance, the delay for all the side links is kept constant at 1ms while the delay of the bottleneck link is fixed at 8ms. The link capacities are also taken at a conservative values as shown. To make a comparison on the basis of how different RTT affect TCP RENO, the delay of source 2 i.e. N2 is varied 50ms. The delay at sink node N5 is also varied giving a total delay of 108ms for data sent from N2 to N5 compared to 10ms for data sent from N1 to N4. To make a comparison on the effect of large link capacity on TCP RENO, the link capacity at all the side links was changed to X. The bottleneck link was also upgraded to x Gbps. The topologies are as showed below. 28

37 Figure 12 Topology for same delay and same link capacities. Figure 13 Topology for different link delays but same capabilities 29

38 Figure 14 Topology for TCP Reno link with high available capacity 30

39 3.4. RESULTS AND DISCUSSION. Figure 15 TCP Reno at equal delay and equal link capacities At equal delay and equal link capabilities, although flow 1 starts before flow 2, TCP Reno adjusts its rates and shares the available bandwidth equally. This results in the congestion window showed above. This behaviour of TCP Reno is also not desirable because the best way to utilize all the network bandwidth would be for one of the flows to cut back. This should however not always be the same flow. 31

40 Figure 16 TCP Reno with different delay but same link capacity Figure 17 TCP Reno with high bandwidth allocation. 32

41 At different delay times for one link, TCP Reno does not synchronize the flows and the congestion window of flow 2 is much lower than that of flow 1. Another major drawback of TCP Reno is that it performs slow start at the same time. In an ideal situation, one of the flows would perform slow start as the other is in congestion avoidance phase. This is because slow start relieves bandwidth that is usable by the other flows. In a high bandwidth network TCP Reno performs two slow starts before entering congestion avoidance. The flow ends at 100ms while Reno has not yet reached its full capacity. 33

42 4. Chapter CONCLUSION In this paper, the stability properties of TCP Reno were analysed and then simulated using NS2. The major drawbacks of TCP Reno are its low performance on fast and long distance networks. It also experience abrupt change in the window size with congestion. Fairness and stability are two important considerations in designing congestion control mechanisms that allow resource-sharing in a network with many competing users. By associating a utility function with each user and defining fairness to mean the maximization of the sum utility of the network, the fair resource sharing problem can be viewed as an optimization problem. 34

43 APPENDIX A.1 NS2 EQUAL DELAY AND EQUAL LINK CAPACITIES CODE # Make a simulator (scheduler) set ns [new Simulator] #Define different colors for data #flows (for NAM) $ns color 1 Blue $ns color 2 Red # Open the NAM trace file set file2 [open out.nam w] $ns namtrace-all $file2 # # Open the Window plot file # set winfile [open WinFile w] set winfile2 [open WinFile2 w] # # Define a 'finish' procedure # proc finish {} { global ns file2 $ns flush-trace close $file2 exec nam out.nam & exit 0 } # Create the configuration: # # Create the 6 nodes: set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] set n4 [$ns node] set n5 [$ns node] # Create the links: $ns duplex-link $n0 $n2 2Mb 1ms DropTail $ns duplex-link $n1 $n2 2Mb 1ms DropTail $ns simplex-link $n2 $n3 0.3Mb 8ms DropTail $ns simplex-link $n3 $n2 0.3Mb 8ms DropTail $ns duplex-link $n3 $n4 0.5Mb 1ms DropTail $ns duplex-link $n3 $n5 0.5Mb 1ms DropTail #Monitor the queue for link (n0- #n1). (for NAM) $ns duplex-link-op $n2 $n3 queuepos 2 # Give node position (for NAM) $ns duplex-link-op $n0 $n2 orient right-down $ns duplex-link-op $n1 $n2 orient right-up $ns simplex-link-op $n2 $n3 orient right $ns simplex-link-op $n3 $n2 orient left $ns duplex-link-op $n3 $n4 orient right-up $ns duplex-link-op $n3 $n5 orient right-down # Set Queue Size of link (n2-n3) to #10 (default is 50) $ns queue-limit $n2 $n3 10 # Setup First TCP connection 35

44 set tcp [new Agent/TCP/Reno] $ns attach-agent $n0 $tcp set sink [new Agent/TCPSink] $ns attach-agent $n4 $sink $ns connect $tcp $sink $tcp set fid_ 1 $tcp set window_ 8000 $tcp set packetsize_ 552 # Setup a FTP over TCP connection set ftp [new Application/FTP] $ftp attach-agent $tcp $ftp set type_ FTP # Schedule start/stop times $ns at 0.1 "$ftp start" $ns at "$ftp stop" # Setup Second TCP connection set tcp2 [new Agent/TCP/Reno] $ns attach-agent $n1 $tcp2 set sink2 [new Agent/TCPSink] $ns attach-agent $n5 $sink2 $ns connect $tcp2 $sink2 $tcp2 set window_ 8000 $tcp2 set packetsize_ 552 #This give the packet of TCP flow #2 a different color in nam... $tcp2 set fid_ 2 # Setup a FTP over TCP connection set ftp2 [new Application/FTP] $ftp2 attach-agent $tcp2 $ftp2 set type_ FTP # Schedule start/stop times $ns at 20.0 "$ftp2 start" $ns at 80.0 "$ftp2 stop" # plotwindow(tcpsource,file): write #CWND from $tcpsource #to output file $file every 0.1 sec # #### { proc plotwindow {tcpsource file} global ns set time 0.1 set now [$ns now] set cwnd [$tcpsource set cwnd_] set wnd [$tcpsource set window_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotwindow $tcpsource $file" } $ns at 0.1 "plotwindow $tcp $winfile" $ns at 0.1 "plotwindow $tcp2 $winfile2" ################################## # Set simulation end time $ns at "finish" # Run!!!! $ns run A.2 NS2 DIFFERENT DELAY BUT SAME LINK CAPACITY CODE # Make a simulator (scheduler) set ns [new Simulator] #Define different colors for data #flows (for NAM) $ns color 1 Blue $ns color 2 Red # Open the NAM trace file set file2 [open out.nam w] $ns namtrace-all $file2 36

45 # # Open the Window plot file # set winfile [open WinFile w] set winfile2 [open WinFile2 w] # # Define a 'finish' procedure # proc finish {} { global ns file2 $ns flush-trace close $file2 exec nam out.nam & exit 0 } # # Create the configuration: # ############## # Create the 6 nodes: set n0 [$ns node] set n1 [$ns node] set n2 [$ns node] set n3 [$ns node] set n4 [$ns node] set n5 [$ns node] # Create the links: $ns duplex-link $n0 $n2 2Mb 1ms DropTail $ns duplex-link $n1 $n2 2Mb 50ms DropTail $ns simplex-link $n2 $n3 0.1Mb 8ms DropTail $ns simplex-link $n3 $n2 0.1Mb 8ms DropTail $ns duplex-link $n3 $n4 0.5Mb 1ms DropTail $ns duplex-link $n3 $n5 0.5Mb 50ms DropTail #Monitor the queue for link (n0- #n1). (for NAM) $ns duplex-link-op $n2 $n3 queuepos 2 # Give node position (for NAM) $ns duplex-link-op $n0 $n2 orient right-down $ns duplex-link-op $n1 $n2 orient right-up $ns simplex-link-op $n2 $n3 orient right $ns simplex-link-op $n3 $n2 orient left $ns duplex-link-op $n3 $n4 orient right-up $ns duplex-link-op $n3 $n5 orient right-down # Set Queue Size of link (n2-n3) to #10 (default is 50?) $ns queue-limit $n2 $n3 10 # ################################## # Setup First TCP connection set tcp [new Agent/TCP/Reno] $ns attach-agent $n0 $tcp set sink [new Agent/TCPSink] $ns attach-agent $n4 $sink $ns connect $tcp $sink $tcp set fid_ 1 $tcp set window_ 8000 $tcp set packetsize_ 552 # Setup a FTP over TCP connection set ftp [new Application/FTP] $ftp attach-agent $tcp $ftp set type_ FTP # Schedule start/stop times $ns at 0.1 "$ftp start" $ns at "$ftp stop" ################################## # Setup Second TCP connection 37

46 set tcp2 [new Agent/TCP/Reno] $ns attach-agent $n1 $tcp2 set sink2 [new Agent/TCPSink] $ns attach-agent $n5 $sink2 $ns connect $tcp2 $sink2 $tcp2 set window_ 8000 $tcp2 set packetsize_ 552 #This give the packet of TCP flow #2a different color in nam... $tcp2 set fid_ 2 # Setup a FTP over TCP connection set ftp2 [new Application/FTP] $ftp2 attach-agent $tcp2 $ftp2 set type_ FTP # Schedule start/stop times $ns at 20.0 "$ftp2 start" $ns at 80.0 "$ftp2 stop" # # plotwindow(tcpsource,file): write #####CWND from $tcpsource # to output file every 0.1 sec # { proc plotwindow {tcpsource file} global ns set time 0.1 set now [$ns now] set cwnd [$tcpsource set cwnd_] set wnd [$tcpsource set window_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotwindow $tcpsource $file" } $ns at 0.1 "plotwindow $tcp $winfile" $ns at 0.1 "plotwindow $tcp2 $winfile2" # ################################# # Set simulation end time $ns at "finish" # Run!!!! $ns run A.3 RENO WITH HIGH BANDWIDTH ALLOCATION CODE # Make a simulator (scheduler) set ns [new Simulator] #Define different colors for data #flows (for NAM) $ns color 1 Blue # Open the NAM trace file set file2 [open out.nam w] $ns namtrace-all $file2 # Open the Window trace file set winfile [open WinFile w] # Define a 'finish' procedure proc finish {} { global ns file2 $ns flush-trace close $file2 exec nam out.nam & exit 0 } # Create the configuration: # 38

47 # # Create the nodes: set n0 [$ns node] set n2 [$ns node] set n3 [$ns node] set n4 [$ns node] # Create the links: $ns duplex-link $n0 $n2 2Gb 10ms DropTail $ns simplex-link $n2 $n3 1.0Gb 200ms DropTail $ns simplex-link $n3 $n2 1.0Gb 200ms DropTail $ns duplex-link $n3 $n4 2.0Mb 40ms DropTail #Monitor the queue for link (n0- #n1). (for NAM) $ns duplex-link-op $n2 $n3 queuepos 0.1 # Give node position (for NAM) $ns duplex-link-op $n0 $n2 orient right-down $ns simplex-link-op $n2 $n3 orient right $ns simplex-link-op $n3 $n2 orient left $ns duplex-link-op $n3 $n4 orient right-up # Set Queue Size of link (n2-n3) to #10 (default is 50) $ns queue-limit $n2 $n3 10 # Setup a TCP connection set tcp [new Agent/TCP/Reno] $ns attach-agent $n0 $tcp # set sink [new #Agent/TCPSink/DelAck] set sink [new Agent/TCPSink] $ns attach-agent $n4 $sink $ns connect $tcp $sink $tcp set fid_ 1 $tcp set window_ 8000 $tcp set packetsize_ 552 # Setup a FTP over TCP connection set ftp [new Application/FTP] $ftp attach-agent $tcp $ftp set type_ FTP # Schedule start/stop times $ns at 0.1 "$ftp start" $ns at "$ftp stop" # plotwindow(tcpsource,file): write #CWND from $tcpsource #to output file $file every 0.1 sec { proc plotwindow {tcpsource file} global ns set time 0.1 set now [$ns now] set cwnd [$tcpsource set cwnd_] set wnd [$tcpsource set window_] puts $file "$now $cwnd" $ns at [expr $now+$time] "plotwindow $tcpsource $file" } # Start plotwindow $ns at 0.1 "plotwindow $tcp $winfile" # Set simulation end time $ns at "finish" # Run!!!! $ns run 39

48 REFERENCES [1] J. Postel, RFC793 transmission control protocol, RFC, [2] D. Clark, The Design Philosophy of the DARPA Internet Protocols," Proceedings of SIGCOMM '88, Computer Communication Review, vol. 18, no. 4, pp , [3] M. Gerla and L. Kleinrock, Flow control: a comparative survey, IEEE Trans. Commun., vol. 28, no. 4, pp , April [4] Afanasyev, A., Tilley, N., Reiher, P., & Kleinrock, L. (2010). Host-to-host congestion control for TCP. Communications Surveys & Tutorials, IEEE, 12(3), [5] M. Gerla and L. Kleinrock, Flow control: a comparative survey, IEEE Trans. Commun., vol. 28, no. 4, pp , April [6] J. Postel, RFC793 transmission control protocol, RFC, [7] P. Karn and C. Partridge, Improving round-trip time estimates in reliable transport protocols, in Proc. SIGCOMM, 1987 [8] D.-M. Chiu and R. Jain, Analysis of the increase and decrease algorithms for congestion avoidance in computer networks, Computer Networks and ISDN Systems, vol. 17, no. 1, pp. 1 14, [9]V. Jacobson, Modified TCP congestion avoidance algorithm, to the end2end list, April [10] M. Allman, V. Paxson, and W. Stevens, RFC2581 TCP congestion control, RFC, 1999 [11] Srikant, R. (2005). Models and methods for analyzing Internet congestion control algorithms. In Advances in communication control networks (pp ). Springer Berlin Heidelberg. 40