TCP OPTIMIZATION OVER WIRELESS AND MOBILE NETWORKS VIA TCP-PRN MECHANISM By Osei Gyamfuah Grace (Reg.

No: 15607004)

A PROJECT REPORT Submitted to the School of Computer Science and Engineering in the FACULTY OF ENGINEERING & TECHNOLOGY In partial fulfillment of the requirements for the award of the degree of MASTER OF TECHNOLOGY IN SOFTWARE ENGINEERING SCHOOL OF COMPUTING FACULTY OF ENGINEERING AND TECHNOLOGY SRM UNIVERSITY May, 2009

ii

BONAFIDE CERTIFICATE

Certified that this project report titled TCP OPTIMIZATION OVER WIRELESS AND MOBILE NETWORKS VIA TCP-PRN MECHANISM is the bonafide work of Miss Osei Gyamfuah Grace who carried out the research under my supervision. Certified further, that to the best of my knowledge the work reported herein does not form part of any other project report or dissertation on the basis of which a degree or award was conferred on an earlier occasion on this or any other candidate.

A. JEYASEKAR, M. E. (Ph. D) Internal Guide SRM University.

PROF.C.MALATHY Head of the Department, SRM University.

Signature of Internal Examiner Date:

Signature of External Examiner Date:

iii

ABSTRACT

Supporting users mobility over wireless networks has changed the basic paradigm of transmission control protocol (TCP), where only network congestion generates a packet loss. In addition to network congestion, which has been the primary reason for packet loss, bit error corruption due to an unreliable wireless link easily induces packet loss at the TCP receiver. Temporal link disconnection during handoff also introduces consecutive packet losses. The preceding causes force TCP to aggravate the bandwidth utilization of wireless networks.

In response to these problems, the research community has proposed various solutions to improve the reliability of wireless links such as error recovery methods through strong bit error correction or local retransmission at lower layers of the transport protocol, such as Snoop, AIRMAIL and TULIP but these solutions proposed introduced the problem of packet reordering. However, the temporal disconnection during handoff that generates multiple packet losses requires a different approach hence Freeze-TCP was first proposed to resolve this problem. Its main idea is to avoid packet losses by ceasing packet transmission during a handoff. Even though Freeze-TCP achieves performance increase during handoff, detecting accurate handoff time and the vulnerability of high variation in the round trip time (RTT) become obstacles for deploying Freeze-TCP in a real environment.

Hence, a path recovery notification (TCPPRN) mechanism has been proposed to prevent performance degradation during a handoff. The proposed protocol, TCPPRN, quickly recovers lost packets by restoring the congestion window, preventing the congestion window to decrease, or immediately initiating the slow start algorithm. However, this TCP-PRN has a problem with adapting to congestion window in wireless networks where mobile nodes move and this is what this project seeks to resolve. The simulation results of this project show better performance improvement during handoff.

iv

ACKNOWLEDGEMENT I would like to thank God Almighty for this wonderful opportunity of being alive and being able to undertake this venture. It is by His will that I am alive today and I would like to praise Him for this gift of life and the wisdom He has bestowed on me. I am highly indebted to the management of SRM University for their support and well wishes in the process of pursuing this strenuous and arduous task. I am really appreciative of their support. I profusely thank Mr. A Jeyasekar M.E., (Ph. D), SL, Department of Computer Science and Engineering for his valuable suggestions and for guiding this project until now. Moreover, I would like to express my profound thanks and gratitude to my parents, Mr. and Mrs. Osei and my siblings for their immense support and prayers. I would want to specially thank Alfred Obiri-Yamoah for his love and support; not forgetting my friends especially Lydia and all those who in one way or the other, contributed their quota to the success of this project. Also, I want to say a very big thank you to the president, Rev. Dr. Samuel Donkor and the management of All Nations University College for their support in diverse ways. Finally, I wish to thank all the staff of Computer Science and Engineering department for providing timely support and co-operation in realizing this project.

DEDICATION

To the blessed memory of my beloved grandmother, Madam Margaret Adaawa.

vi

TABLE OF CONTENTS Content Page Number ii iii iv v vi x xi xiii 1 2 2 2 3 3 4 4 5 6 6

Certification Abstract.. Acknowledgement. Dedication. Table of Contents.. List of Tables List of Figures.. List of abbreviations Chapter 1. INTRODUCTION..
1.1 Explanation of concepts used. ..

1.1.1

Round Trip Time (RTT)

1.1.2 Slow Start mechanism.. 1.1.3 1.1.4 1.1.5 1.1.6 1.1.7 Congestion avoidance... Fast retransmit.. Fast recovery.. .. Congestion window.. Handoff.

Chapter 2. LITERATURE SURVEY. 2.1 TCP.

vii

2.1.1 2.1.2 2.1.3 2.2 2.3 2.4 2.4.1

TCPs window management and problems in mobile environments Problems with TCP in mobile environments TCP Control.. TCP-Reno.. TCP-Newreno........

8 9 9 10 12

The Snoop protocol model.. 13 Snoop_output() 14

2.4.2 Snoop_input().. 15 2.5 2.6 Freeze TCP... 17 TCP- PRN (TCP-Path Recovery Notification). 21 23 23

Chapter 3. SOFTWARE REQUIREMENT SPECIFICATION. 3.1 3.2 3.3 3.4 3.5 3.6 3.6.1 3.6.2 3.6.3 Scope..

Audience. 23 Existing System.. 24 Proposed System 25

Project Description.. 26 Functional Specification.. 28 Topology Generation.. 28 Sender side TCP agent 29 Receiver side TCP agent. 29

3.6.4 Modification over preprocessor directives.. 29

viii

3.6.5 3.7 3.8 3.9

Modification over ns-default.tcl Non-Functional Specification

30 30

Hardware requirement 30 Software requirement 30 31

Chapter 4. SOFTWARE DESIGN SPECIFICATION 4.1 4.2 4.2.1 4.2.2 4.3 4.3.1 4.3.2 4.4 4.5 4.5.1 4.5.2 4.5.3

Network Topology.. 31 Sender side TCP agent 31 Sender side operation.. 31 Sender side pseudocode. 33

Receiver side TCP agent. 33 Receiver side operation.. 33

Receiver side pseudocode 34 Modification over preprocessor directives and ns-default.tcl. 35 Design diagrams.. 36 Flow chart for Freeze-TCP.. 36 Flow chart for PRN-TCP 38 Interaction diagrams 40 42

Chapter 5. IMPLEMENTATION AND TESTING. 5.1 5.2 5.3

Implementation 42 Testing. 45 Screen shots. 45

ix

5.4 5.5

Throughput graphs Performance analysis.

47 53 57 58

Chapter 6. CONCLUSION AND FUTURE WORK References

LIST OF TABLES 1. Characteristics of various mobile TCP solutions 2. Throughput of generating/sending packets.. 27 53 54 56

3. Throughput of receiving packets.. 4. Throughput of dropping packets..

xi

LIST OF FIGURES 1. TCP Window Management.. 2. State Machine for snoop_output() 3. Performance of snoop protocol compared to normal TCP.. 4. State machine for snoop_input(). 5. Relation between ts, rtt and w state. 6. Illustration of increased throughput due to Freeze-TCP 7. TCP three-way handshake 8. Topology for simulation 9a. All packet losses with RTO.. 9b. All packet losses without RTO. 10. Freeze-TCP operations. 11. TCPPRN operations.. 12. Normal PRN operation. 13. PRN operation when ack is not received. 14. PRN response after timer expires. 15a . Wired cum wireless topology (with mobile host moving).. 8 13 16 16 18 19 22 31 32 34 36 38 40 40 41 45

15b. Wired cum wireless topology (with stationary mobile host) 46 16. Throughput of sending/generating packets 47 17. Throughput of receiving packets 48 18. Throughput of forwarding packets 49

xii

19. Throughput of dropping packets 20. Throughput of sending/generating packets(prn vs freeze) 21. Throughput of receiving packets(prn vs freeze).. 22. Throughput of forwarding packets(prn vs freeze) 23. Throughput of dropping packets(prn vs freeze) 24-26. Performance analysis on the throughput graphs.

50 51 51 52 52 53

xiii

List of Abbreviations 1 2 3 4 5 6 7 8 9 TCP.. . PRN RTT MSS CWND ACK .. MH. FH. BS.. Transmission Control Protocol Path Recovery Notification Round Trip Time Maximum Segment Size Congestion Window Acknowledgement Mobile Host Fixed Host Base Station Zero Window Advertisement Non-Zero Window Advertisement Zero Window Probe

10 ZWA . 11 NZWA 12 ZWP

xiv

CHAPTER 1

1.0 INTRODUCTION With the rapid development of wireless network technologies, such as cellular networks and WLANs, wireless data communication is becoming a reality. Given the wide deployment of the Transmission Control Protocol (TCP) as the Transport Layer protocol in wired networks and the desire to allow internetworking between wired and wireless networks, it is becoming necessary to use TCP not only in the wired Internet but also in wireless networks due to the potential simplifications and reduction in costs allowed by an all-IP network. Wireless communication is the transfer of information over a distance without the use of electrical conductors or "wires"[9]. The distances involved may be short (a few meters as in television remote control) or very long (thousands or even millions of kilometers for radio communications). Wireless network
[9]

refers to any type of computer network that is wireless,

and is commonly associated with a telecommunications network whose interconnections between nodes is implemented without the use of wires. Mobile computing is a generic term describing one's ability to use technology while moving, as opposed to portable computers, which are only practical for use while deployed in a stationary configuration[9][10]. The wireless and mobile networks allow roaming users to access their data and keeping connections active while moving from one access point to another. Making this roaming seamlessly and efficient at high hand-over rates is a challenge. To make intelligent mobile-aware applications and to achieve efficient routing management, it may be important to anticipate the change of location of users in mobile networks. Wireless networking has become popular due to ease of installation which comes with it. Currently, wireless and mobile networking has now become a critical issue and topic that is discussed almost everywhere. Most companies and organizations are implementing this new technology. So, supporting users mobility over this wireless network is one new important area that has to be considered and this has thus changed the basic paradigm of the transmission control protocol, where only network congestion generates packet losses.

xv

Although the idea of going completely wireless is compelling, in most cases, a mixed wired/wireless environment seem to serve our needs better and this is what this project seeks to implement. 1.1 EXPLANATION OF CONCEPTS USED 1.1.1 ROUND TRIP TIME (RTT) It refers to the time required for a network communication to travel from the source to the destination and back or time elapsed for a message to a remote place and back again. Round-trip delay time is significant in systems that require two-way "interactive" communication. It may range from a very few microseconds for a short line-of-sight (LOS) radio system to many seconds for a multiple-link circuit with one or more satellite links involved. This includes the node delays as well as the media transit time
[9][10] .

In TCP communication, the RTT time is

calculated from the 3-way handshake by measuring the time between segment transmission and ACK receipt. Initially, window size is calculated based on the baseRTT and later, it is determined by meanRTT. The average RTT(avgRTT) varies from time to time. Hence, it is very difficult to accurately calculate the RTT and this results in poor estimation of window size.

1.1.2 SLOW START MECHANISM The larger the receiver Window used in TCP, the more segments that a sending TCP entity can send before it must wait for an acknowledgement. This can create a problem when a TCP connection is first established, because the TCP entity is free to dump the entire window of data on the internet. One strategy that could be followed is for the TCP sender to begin sending from some relatively large but not the maximum window, hoping to approximate the window size that would ultimately be provided by the connection
[10]

. This is risky because the sender might flood the

internet with many segments before it realizes from timeouts that the flow was excessive. Instead, some means is needed for gradually expanding the window until acknowledgements are received. This is the purpose of the slow start mechanism. The slow start actually probes the

xvi

internet to make sure that the TCP entity is not sending too many segments into an already congested environment.

1.1.3 CONGESTION AVOIDANCE 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. The assumption of the algorithm is that packet loss caused by damage is very small (much less than 1%), therefore the loss of a packet signals congestion somewhere in the network between the source and destination. There are two indications of packet loss: a timeout occurring and the receipt of duplicate ACKs. Congestion avoidance and slow start require that two variables be maintained for each connection: a congestion window, cwnd, and a slow start threshold size, ssthresh. [19]

1.1.4 FAST RETRANSMIT Modifications to the congestion avoidance algorithm were proposed. Before describing the change, realize that TCP may generate an immediate acknowledgment (a duplicate ACK) when an out-of-order segment is received. This duplicate ACK should not be delayed. The purpose of this duplicate ACK is to let the other end know that a segment was received out of order, and to tell it what sequence number is expected. Since TCP does not know whether a duplicate ACK is caused by a lost segment or just a reordering of segments, it waits for a small number of duplicate ACKs to be received. It is assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK. If three or more duplicate ACKs are received in a row, it is a strong indication that a segment has been lost. TCP then performs a retransmission of what appears to be the missing segment, without waiting for a retransmission timer to expire.[19]

1.1.5 FAST RECOVERY

xvii

After fast retransmit sends what appears to be the missing segment, congestion avoidance, but not slow start is performed. This is the fast recovery algorithm. It is an improvement that allows high throughput under moderate congestion, especially for large windows. The fast retransmit and fast recovery algorithms are usually implemented together as follows.

1. When the third duplicate ACK in a row is received, set ssthresh to one-half the current congestion window, cwnd, but no less than two segments. Retransmit the missing segment. Set cwnd to ssthresh plus 3 times the segment size. This inflates the congestion window by the number of segments that have left the network and which the other end has cached (3).

2. Each time another duplicate ACK arrives, increment cwnd by the segment size. This inflates the congestion window for the additional segment that has left the network. Transmit a packet, if allowed by the new value of cwnd.

3. When the next ACK arrives that acknowledges new data, set cwnd to ssthresh (the value set in step 1). This ACK should be the acknowledgment of the retransmission from step 1, one round-trip time after the retransmission. Additionally, this ACK should acknowledge all the intermediate segments sent between the lost packet and the receipt of the first duplicate ACK. This step is congestion avoidance, since TCP is down to one-half the rate it was at when the packet was lost.[19]

1.1.6 CONGESTION WINDOW (CWND) In TCP, the congestion window determines the number of bytes that can be outstanding at any time. This is a means of stopping the link between two places from getting overloaded with too much traffic. It actually controls startup and limits throughput in the face of loss. The size of this window is calculated by estimating how much congestion there is between the two places. The sender maintains the congestion window. When a connection is set up, the congestion window is set to the maximum segment size (MSS) allowed on that connection
[10]

. If all segments are

received and the acknowledgements reach the sender on time, then the window size is doubled. The Window keeps growing exponentially till either a timeout occurs or till the receiver reaches

xviii

its limit. If a "timeout" occurs, the window size is halved. The cwnd gets larger after every new ACK and gets smaller when loss is detected. TCPPRN allows the sender to transmit extra packets by sending the lost packets or by restoring the reduced cwnd. When congestion losses and wireless losses occur simultaneously, TCPPRN appears to exacerbate the network congestion. TCPPRN can recover lost packets without reducing cwnd and ssthresh after a wireless link is reconnected.

1.1.7 HANDOFF In cellular telecommunications, the term handoff refers to the process of transferring an ongoing call or data session from one channel connected to the core network to another [2]. There may be different reasons why a handoff (handover) might be conducted:

when the phone is moving away from the area covered by one cell and entering the area covered by another cell, the call is transferred to the second cell in order to avoid call termination when the phone gets outside the range of the first cell;

when the capacity for connecting new calls of a given cell is used up and an existing or new call from a phone which is located in an area overlapped by another cell, is transferred to that cell in order to free-up some capacity in the first cell for other users, who can only be connected to that cell.

CHAPTER 2

xix

2.0 LITERATURE SURVEY 2.1 TCP TCP is a very popular transport protocol and is the most widely used for today's Internet data applications. It combines logic for routing through an internet with end-to-end control [8]. The Transmission Control Protocol (TCP) is one of the core protocols of the Internet Protocol Suite. The Transmission Control Protocol (TCP) is a connection oriented byte stream transport protocol used by many end-user applications.TCP is so central that the entire suite is often referred to as "TCP/IP." Whereas IP handles lower-level transmissions from computer to computer as a message makes its way across the Internet, TCP operates at a higher level, concerned only with the two end systems. In particular, TCP provides reliable, ordered delivery of a stream of bytes from one program on one computer to another application on another computer using port address. Among its management tasks, TCP controls message size, the rate at which messages are exchanged, and network traffic congestion. TCP is actually a collection of algorithms that send packets into the network without a reservation and then react to observable events to occur. Such algorithms include congestion control and recovery from loss of packets. TCP provides a communication service at an intermediate level between an application program and the Internet Protocol (IP). That is, when an application programmer desires to send a large chunk of data across the Internet using IP, instead of breaking the data into IP-sized pieces and issuing a series of IP requests, the programmer can issue a single request to TCP and let TCP handle the IP details. IP works by exchanging pieces of information called packets. A packet is a sequence of bytes and consists of a header followed by a body. The header describes the packet's destination and which routers on the Internet to use to pass the packet alonggenerally in the right directionuntil it arrives at its final destination. The body contains the data which IP is transmitting. When IP is transmitting data on behalf of TCP, the contents of the IP packet body is TCP data. Due to network congestion, traffic load balancing, or other unpredictable network behavior, IP packets can be lost or delivered out of order. TCP detects these problems, requests retransmission of lost packets, rearranges out-of-order packets, and even helps minimize network congestion to reduce the occurrence of the other problems. Once TCP at the receiving end has

xx

finally reassembled a perfect copy of the large data chunk originally transmitted, it passes that single chunk up to the application program at the receiving end. Thus, TCP greatly simplifies the application programmer's network communication task. TCP is a reliable stream delivery service that guarantees delivery of a data stream sent from one host to another without duplication or losing data. Since packet transfer is not reliable, a technique known as positive acknowledgment with retransmission is used to guarantee reliability of packet transfers. Since TCP is optimized for accurate delivery rather than timely delivery, TCP sometimes incurs relatively long delays while waiting for out-of-order messages or retransmissions of lost messages, and it is not particularly suitable for real-time applications such as Voice over IP. TCP has been optimized for wired networks. Any packet loss is considered to be the result of congestion and the congestion window size is reduced dramatically as a precaution [6]. However, TCP is based on some assumptions that are not valid in wireless environments. This leads to poor performance of TCP in mixed wired-wireless environments. Wireless links are known to experience sporadic and usually temporary losses due to fading, shadowing, hand off, and other radio effects, that cannot be considered as congestion. After the (erroneous) back-off of the congestion window size, due to wireless packet loss, there can be a congestion avoidance phase with a conservative decrease in window size. Several modifications at the transport layer have been proposed and studied in recent years to deal with the problem of timeout back-off and congestion window reduction during disconnections (due to handoffs, fading etc.) or to deal with the high corruption rate of wireless channels.

2.1.1 TCPS WINDOW MANAGEMENT AND PROBLEMS IN MOBILE ENVIRONMENTS TCP uses a sliding window mechanism to accomplish reliable, in-order delivery and flow/congestion control. Figure 1 show this graphically, with the window sliding towards the right. The window size (W) is determined as the minimum of receivers advertised buffer space, and the perceived network congestion[18]. The sender allows up to W outstanding or

xxi

unacknowledged packets at a time. This results in a usable window size equal to W minus the number of outstanding packets.

Fig. 1 TCP Window Management [18] Under normal conditions, the right edge of the window stays fixed (when the packets in the current window remain unacknowledged), or advances to the right along with the left edge of the window, as packets are acknowledged. If the consuming process at the receiver end is slower than the sender, the receivers buffers will begin to fill causing it to advertise progressively smaller and smaller window sizes. Eventually the receiver may run out of buffer space in which case it advertises a window size of zero. Upon seeing an advertised window size of zero, the sender should freeze all re-transmit timers and enter a persist mode. This involves sending probes (called the Zero Window Probes or ZWPs) until the receivers window opens up. Eventually the receiver responds to a ZWP with a non-zero window size, and the sender will continue transmission using a window size consistent with the advertised value.

2.1.2 PROBLEMS WITH TCP IN MOBILE ENVIRONMENTS TCP was conceived for wired, fixed topologies which are fairly reliable. TCP performs very well on such networks by adapting to end-to-end delays and packet losses. TCP provides reliability by maintaining a running average of estimated round-trip delay and mean deviation, and by retransmitting any packet whose acknowledgment isnt received within twice the deviation from the average. Due to the relatively low error rates over wired networks, packet losses are assumed

xxii

to be as a result of congestion. Hence it operates on the assumption that any losses are due to congestion, which is reasonable for a reliable infrastructure. In mobile environments, however, losses are more often caused by: (i) The inherently higher bit error rates of the wireless links, and (ii) Temporary disconnections (due to signal fading or other link errors; or because a mobile node moves, etc). Unfortunately, in the presence of the high error rates and temporary disconnection characteristic of wireless links, this assumption causes TCP to suffer a significant degradation in performance in the form of poor throughput and very high interactive delays when used in a wireless environment. This behavior arises due to the fact that errors on the wireless link or delays due to handoffs are incorrectly interpreted by TCP at the sender as congestion. In response to this congestion, TCP drops its transmission window size before retransmitting packets, initiates congestion control mechanisms (slow start) and resets the retransmission timer using an exponential backoff computation from the previous value (using Karns Algorithm ), thereby unnecessarily reducing its bandwidth utilization. Several approaches have been proposed to overcome these shortcomings of standard TCP. Some of these include The Berkeley Snoop module, Indirect TCP (I-TCP), MTCP, etc) [18]

2.1.3 TCP CONTROL Each sender maintains two windows: the window RWND the receiver has granted and a second window CWND called the congestion window. The minimum of the congestion window and the receiver's window is used when sending packets. The congestion control mechanism has two distinct phases: Slow Start and Congestion Avoidance. Upon starting a connection or restarting after a packet loss, the congestion window size is set to one packet, and then doubled once every Round-Trip Time (RTT), i.e. upon the receipt of an acknowledgement (ACK). Congestion avoidance takes care of violation which would occur if the retransmit time is too short. During this phase, CWND is linearly increased as opposed to exponential increase during slow start phase. A third parameter SSTHRESH is used to start the congestion phase and is usually initially

xxiii

set to 64 KB (kilo bytes). Upon notification of network congestion, i.e. a timeout, SSTHRESH is set to half the current CWND and CWND is set to one and the slow start phase restarts once again. There are several ways to detect a packet loss: (1) a timer: when the timer is greater than the Retransmission Time Out (RTO), a packet is assumed to be lost; and (2) when a packet has been acknowledged more than three times, the next packet is assumed to be lost [11][13]. 2.2 TCP-RENO This Reno retains the basic principle of Tahoe, such as slow starts and the coarse grain retransmit timer. However it adds some intelligence over it so that lost packets are detected earlier and the pipeline is not emptied every time a packet is lost. Reno requires that we receive immediate acknowledgement whenever a segment is received. The logic behind this is that whenever we receive a duplicate acknowledgment, then his duplicate acknowledgment could have been received if the next segment in sequence expected, has been delayed in the network and the segments reached there out of order or else that the packet is lost[4]. If we receive a number of duplicate acknowledgements then that means that sufficient time have passed and even if the segment had taken a longer path, it should have gotten to the receiver by now. There is a very high probability that it was lost. So Reno suggests an algorithm called Fast ReTransmit. Whenever we receive 3 duplicate ACKs we take it as a sign that the segment was lost, so we re-transmit the segment without waiting for timeout. Thus we manage to re-transmit the segment with the pipe almost full. Another modification that RENO makes is in that after a packet loss, it does not reduce the congestion window to 1. Since this empties the pipe. It enters into this Fast-Re-Transmit algorithm. The basic algorithm is presented as under: 1) Each time we receive 3 duplicate ACKs we take that to mean that the segment was lost and we re-transmit the segment immediately and enter Fast-Recovery 2) Set SSthresh to half the current window size and also set CWD to the same value. 3) For each duplicate ACK receive increase CWD by one. If the increase CWD is greater than the amount of data nin the pipe then transmit a new segment else wait. If there are w segments in the window and one is lost, then we will receive (w-1) duplicate ACKs. Since CWD is reduced to W/2, therefore half a window of data is acknowledged before we can send a new segment. Once we retransmit a segment, we would have to wait for atlease one RTT before we would receive a fresh acknowledgement. Whenever we receive a fresh ACK we reduce the

xxiv

CWND to SSthresh. If we had previously received (w-1) duplicate ACKs then at this point we should have exactly w/2 segments in the pipe which is equal to what we set the CWND to be at the end of fast recovery.[6][8] Thus we dont empty the pipe, we just reduce the flow. We continue with congestion avoidance phase of Tahoe after that. The algorithm for the window
size used in the reno is shown below:

This code inflates the window by duplicate window value (dupwnd_). This dupwnd_ will be non-zero during fast recovery, at which time it contains the number of duplicate acknowledgements (dup acks). int win = int(cwnd_) + dupwnd_; if (frto_ == 2) { // First ack after RTO has arrived. // Open window to allow two new segments out with F-RTO. win = force_wnd(2); } if (win > int(wnd_)) win = int(wnd_); return (win);

Problems: Reno performs very well over TCP when the packet losses are small. But when we have multiple packet losses in one window then RENO doesnt perform too well and its performance is almost the same as Tahoe under conditions of high packet loss. The reason is that it can only detect single packet losses. If there is multiple packet drops, then the first information about the packet loss comes when we receive the duplicate ACKs. But the information about the second packet which was lost will come only after the ACK for the retransmitted first segment reaches the sender after one RTT. Also it is possible that the CWD is reduced twice for packet losses which occurred in one window. Another problem is that if the widow is very small when the loss occurs then we would never receive enough duplicate acknowledgements for a fast retransmit and we would have to wait for a coarse grained timeout. Thus it cannot effectively detect multiple packet losses [8]. 2.3 TCP- NEWRENO

xxv

New RENO is a slight modification over TCP-RENO. It is able to detect multiple packet losses and thus is much more efficient than RENO in the event of multiple packet losses. Like Reno, New-Reno also enters into fast-retransmit when it receives multiple duplicate packets, however it differs from RENO in that it doesnt exit fast-recovery until all the data which was out standing at the time it entered fast recovery is acknowledged. Thus it overcomes the problem faced by Reno of reducing the CWD multiples times [6]. The fast-transmit phase is the same as in Reno. The difference in the fast recovery phase which allows for multiple re-transmissions in new-Reno. Whenever new-Reno enters fast recovery, it notes the maximum segment which is outstanding. The fast-recovery phase proceeds as in Reno, however when a fresh ACK is received then there are two cases: If it ACKs all the segments which were outstanding when we entered fast recovery, then it exits fast recovery and sets CWD to ssthresh and continues congestion avoidance like Tahoe. If the ACK is a partial ACK then it deduces that the next segment in line was lost and it re-transmits that segment and sets the number of duplicate ACKS received to zero. It exits Fast recovery when all the data in the window is acknowledged.

Problems: New-Reno suffers from the fact that it takes one RTT to detect each packet loss. When the ACK for the first retransmitted segment is received only then can we deduce which other segment was lost. [8] 2.4 THE SNOOP PROTOCOL MODEL The Snoop protocol is a TCP-aware link layer protocol designed to improve the performance of TCP over networks of wired and single-hop wireless links. The main problem with TCP performance in networks that have both wired and wireless links is that packet losses that occur because of bit-errors are mistaken by the TCP sender as being due to network congestion, causing it to drop its transmission window and often time out, resulting in degraded throughput. The Snoop protocol works by deploying a Snoop agent at the base station and performing retransmissions of lost segments based on duplicate TCP acknowledgments (which are a strong indicator of lost packets) and locally estimated last-hop round-trip times. The agent also

xxvi

suppresses duplicate acknowledgments corresponding to wireless losses from the TCP sender, thereby preventing unnecessary congestion control invocations at the sender. This combination of local retransmissions based primarily on TCP acknowledgments, and suppression of duplicate TCP acknowledgments, is the reason for classifying Snoop as a transport-aware reliable link protocol. The state maintained at the base station is soft, which does not complicate handoffs or overly increase their latency

Fig 2. State Machine for snoop_output() [14] Given a protocol in the context of a single TCP connection consisting of a fixed host (FH) connected to a mobile host (MH) through a basestation (BS). The basestation routing code is modified by adding a layer, the snoop layer, which monitors every packet that passes through the connection in either direction. No transport layer code runs at the basestation. The snoop layer maintains a cache of TCP packets sent from the FH that havent yet been acknowledged by the MH. This is easy to do since TCP has a cumulative acknowledgment policy for received packets. When a new packet arrives from the FH, the snoop layer adds it to its cache and passes the packet on to the routing code which performs the normal routing functions. The snoop layer also keeps track of all the acknowledgments sent from the mobile host. When a packet loss is detected (either by the arrival of a duplicate acknowledgment or by a local timeout), it retransmits the lost packet to the MH. Thus the base station hides the packet loss from the FH by not propagating duplicate acknowledgments, thereby preventing unnecessary congestion control mechanism invocations. The snoop layer has two linked state machines, snoop_output() and snoop_input(). Snoop_output() processes and caches packets intended for the MH while snoop_input()

xxvii

processes acknowledgments (ACKs) coming from the MH and performs local retransmissions. These local retransmissions are initiated using a timeout mechanism based on a TCP style roundtrip time (RTT) estimate of the last (wireless) link. We limit the maximum number of local retransmissions (the optimal value of this limit is still undetermined). The state machines for snoop_output() and snoop_input() are shown in Figures 4 &5 and are described below:

2.4.1 Snoop_output() One of three types of packets can arrive from the FH: 1. A new packet in the normal TCP sequence. In this case add the packet to the snoop cache and also route it to the MH. 2. An out-of-sequence packet that has been cached earlier. In this case this packet has been transmitted either as a result of a sender timeout or as part of the data stream following a TCP fast-retransmission [RFC89]. In general, we allow the local retransmission scheme to deal with the delivery of cached packets. To allow local retransmissions to progress, we reset the count of such retransmissions to 0. 3. An out-of-sequence packet that has not been cached earlier. In this case this packet has either been delivered out of order by the network or was lost earlier due to congestion on the wired network. Therefore, this packet is marked as having experienced congestion loss. Snoop_input() uses this information to deal with TCP acknowledgments.[14][15]

2.4.2 Snoop_input() Snoop_input() monitors the acknowledgments (ACKs) sent back by the MH. These ACKs fall into one of three categories: 1. A spurious ACK, out of the normal non-decreasing order of TCP ACKs. This ACK is discarded since TCPs acknowledgments are cumulative. 2. A duplicate ACK (DUPACK), identical to a previously received one. In this case the next packet in sequence from the DUPACK has not been received by the MH. However, some subsequent packets in the sequence have been received. We take one of several actions: If the desired packet is not in the snoop cache or is marked as a congestion loss, we route the DUPACK to the FH. This is because we need the FH to resend the packet after invoking its congestion control mechanisms.

xxviii

Otherwise, if we are not expecting a DUPACK for this packet, we retransmit the packet to the MH. Based on state we maintain (sequence numbers of the last transmitted packet and the expected ACK), we estimate the number of DUPACKs that the lost packet will create, update the state and set the wireless retransmission timer.

Finally, if we are expecting a DUPACK for this packet (based on the above estimate), we discard the DUPACK.

3. A new ACK. In this case the ACK signifies an increase in the packet sequence received at the MH. Based on the state we maintain (the expected ACK), we determine if a packet has been lost on the wireless link, and if so, retransmit it. We also set the retransmission timer and update the state. Otherwise, no packets have been lost and we use this ACK to update our RTT estimate for the last link and free the buffers in our cache. In addition, snoop_input() must retransmit a packet when a timeout occurs on the wireless link Some advantages of the snoop protocol include:

Preserving end-to-end TCP semantics Secondly, it requires no changes in TCP for fixed hosts. Also, No changes in TCP are possible for the mobile hosts, but reverse direction traffic can benefit from changes at mobile host.

There is no need for handoff Finally, it automatically falls back to standard TCP in case of any encountered problems.

xxix

(A)

(B)

Fig 3. Performance of snoop protocol compared to normal TCP - (A) shows end-to-end bandwidth with standard deviations. (B) Shows bandwidth speedup of the snoop protocol.[15]

Fig 4. State machine for snoop_input()[15] 2.5 FREEZE-TCP Freeze-TCP is a method that places the sender in persist mode prior to a disconnection through signal strength measurements. Freeze-TCP mechanism is a true end-to-end scheme that does not require the involvement of any intermediaries (such as base stations) for flow control. Furthermore, this scheme does not require any changes on the sender side or intermediate routers; changes in TCP code are restricted to the mobile client side, making it possible to fully

xxx

inter-operate with the existing infrastructure. It relies on the prediction of an impending disconnection and the selection of a precise warning period. Once the Freeze-TCP identifies this, the receiver begins to transmit Zero Window Advertisement (ZWA) packets to the sender one RTT before the disconnection in order to prevent packet losses. [18] The main idea behind Freeze-TCP is to move the onus of signaling an impending disconnection to the client. A mobile node can certainly monitor signal strengths in the wireless antennas and detect an impending handoff; and in certain cases, might even be able to predict a temporary disconnection (if the signal strength is fading, for instance). In such a case, it can advertise a zero window size, to force the sender into the ZWP mode and prevent it from dropping its congestion window. Even if one of the zero window probes is lost, the sender does not drop the congestion window. To implement this scheme, only the clients TCP code needs to change and there is no need for an intermediary (no code changes are required at the base station or the sender).

If the receiver can sense an impending disconnection, it should try to send out a few (at least one) acknowledgements, wherein its window size is advertised as zero (let an ACK with a zero receiver window size be abbreviated ZWA, i.e., Zero Window Advertisement). The question is: how much in advance of the disconnection should the receiver start advertising a window size of zero? This period is in a sense the warning period prior to disconnection. Ideally, the warning period should be long enough to ensure that exactly one ZWA gets across to the sender. If the warning period is any longer, the sender will be forced into Zero Window Probe mode prematurely, thereby leading to idle time prior to the disconnection. If the warning period is too small, there might not be enough time for the receiver to send out a ZWA which will cause the senders congestion window to drop due to packets lost during the disconnection (which, in turn leads to some idle-time/underutilization after the reconnection). Given this, a reasonable warning period is the round-trip-time (RTT). During periods of continuous data transfer, this allows the sender to transmit a packet and then receive its acknowledgment.

Since the ZWPs are exponentially backed off, there is the possibility of substantial idle time after a reconnection. This could happen, for instance, if the disconnection period was long and the reconnection happened immediately after losing a ZWP from the sender. In that case, the sender will go into a long backoff before sending the next probe. Meantime the receiver has already

xxxi

reconnected, but the connection remains idle until the sender transmits its next probe. To avoid this idle time, a suggested scheme has been implemented in which when connection is reestablished, the receiver sends 3 copies of the ACK form the last data segment it received prior to the disconnection. This scheme is henceforth abbreviated as TR-ACKs (Triplicate Reconnection ACKs). Unlike M-TCP, there is no advantage to holding back them ACK to the last byte. For M-TCP it was useful because even when the mobile client was disconnected, the base station could still signal the sender on behalf of the client. In the case of Freeze-TCP, since changes are restricted to the client end, holding back the ACK for the last byte does not help. The Freeze-TCP will avoid any re-packetization penalty at the sender end (which M-TCP might incur because it holds back the ACK to the last byte) [18]. Figures 5 and 6 below helps in the estimation of the performance gain possible due to the Freeze-TCP technique.

Fig 5. Relation between TS, RTT AND W [18] In Figure 2, ts is the time required to put or write the packet on the wire, RTT is the total round trip delay including the ts delays at sending, receiving as well as any intermediate nodes; and W is the senders window. From the figure, it is seen that if any idle periods are to be avoided:
(1)

Since

(ignoring processing/queuing delays internal to the host, collisions in

case of shared medium, etc.) it is seen that the [delay _ bandwidth] product is important in determining how big the congestion window, W needs to be if underutilization of network capacity is to be avoided.

xxxii

Assuming

is required for

(2)

full network capacity utilization. Figure 3 pictorially illustrates the increased throughput under this condition, when Freeze- TCP prevents sender side window, W, from dropping and regrowing (due to packet losses). From the figure it can be seen that the (approximate) number of extra packets transferred by the Freeze-TCP scheme is given by:

(3)

Fig 6. Illustration of increased throughput due to Freeze-TCP [18] In addition to (2), the above expression (3) also assumes that upon a disconnection (and the loss of packets), regular TCP drops the congestion window all the way down to 1, and first grows it by a factor of 2 each time an ACK is received, until it reaches W=2. From there on, it is incremented by 1 each time an ACK is received until it reaches the same size W prior to disconnection. This congestion window growth mechanism is dubbed slow-start congestion avoidance. In spite of the performance achieved, the Freeze-TCP is disturbed by these two factors that: The first factor is that the measured RTT varies with a high variance due to changes in the queuing delay in a bottleneck link or transmission delay of wireless links. Although the receiver sends ZWA packets one RTT before the disconnection, the actual delay that

xxxiii

the packets experience may be longer than the measured RTT. This leads to packet losses and aggravates the performance of Freeze-TCP. This aggravation becomes more severe when the bandwidth-delay product increases. The second factor is that Freeze-TCP should be able to identify the exact time duration from the present time until the link disconnection. This time depends on the velocity of the moving host. Singh et al. raises the issue on the unpredictability of this time. To obtain the speed of the moving host, the mobile host needs to utilize the signal strength function expressed by velocity and time (or distance). Some signal strength models like the space model, the two-ray ground reflection model and the shadowing model were used to evaluate the distance between the mobile host and the base station. However, these models brought to light the fact that the speed of the moving host will have different values and may lead to different warning periods for this Freeze-TCP.

Hence, it has been concluded that the Freeze-TCP that is based on the RTT and the prediction of the disconnection time requires some level of improvement.

2.6 TCP- PRN (TCP-PATH RECOVERY NOTIFICATION) Even though Freeze-TCP achieves a performance increase during handoff, detecting accurate handoff time and the vulnerability of high variation in the round trip time (RTT) become obstacles for deploying Freeze-TCP in a real environment, hence the proposition of this PRN mechanism. The basic principle of TCPPRN is to fast recover the adverse impact of the temporal link disconnection due to a handoff. To alleviate the influence of packet losses during the disconnection, a TCP receiver on an MN notifies its TCP sender on a FN of the temporal disconnection through a special ack. Then, the TCP sender retransmits the lost packets and restores the reduced cwnd and ssthresh, if a false RTO occurs [13]. TCPPRN requires modifying both the senders and receivers operations on the TCPSACK option. Some variables included in TCPPRN are listed as follows:

xxxiv

PRN option: This option plays a role in notifying the sender that a wireless link was temporally disconnected and reconnected. The option is set to one of three condition flags: reconnection (RC), partial loss (PL), and no packet arrival (NPA)[13].

_ ocwnd: This variable is a copy of cwnd. It is used to restore cwnd if an RTO occurred due to a disconnection. _ ossthresh: This variable is a copy of ssthresh. It is used to restore ssthresh if an RTO occurred due to a disconnection. _ lsent_time: This variable indicates the time of the last packet transmitted from the TCP sender within a window due to a RTO or a fast retransmit. _ PRN timer: If this timer expires, the PRN option with NPA is sent to the sender to notify that there may have been a loss of all packets.

Modifying the senders and receivers operations raises compatibility issues. If both of them shall be changed, the generality of network protocol is broken because only the same sort of TCP pair can communicate with each other. However, using the TCP-PRN, it is possible to easily check if the counter party can operate TCPPRN with the same process as the timestamp option usage checking during the TCP three-way handshake. The TCP three-way handshake (also called the three message handshake) is the method used to establish and tear down network connections. This handshaking technique is referred to as the 3way handshake or as "SYN-SYN-ACK" (or more accurately SYN, SYN-ACK, ACK). The TCP handshaking mechanism is designed so that two computers attempting to communicate can negotiate the parameters of the network connection before beginning communication. This process is also designed so that both ends can initiate and negotiate separate connections at the same time. Client A Client B

SYN

SYN-

xxxv

Fig7. TCP Three-way handshake

CHAPTER 3

3.0 SOFTWARE REQUIREMENT SPECIFICATION 3.1 SCOPE The scope of this project revolves around the world of wired and wireless networks. It aims at preventing performance degradation during a handoff in a wired cum wireless environment. Even though Freeze-TCP achieves a performance increase during handoff, detecting accurate handoff time and the vulnerability of high variation in the round trip time (RTT) become obstacles for deploying Freeze-TCP in a real environment. The proposed protocol, TCPPRN, quickly recovers lost packets by restoring the congestion window, preventing the congestion window to decrease, or immediately initiating the slow start algorithm. This is attained by making slight modification to the Reno TCP.

xxxvi

3.2 AUDIENCE The wired cum wireless environment, though not an old phenomena, seems to have several applications in the real world. It can be used in the areas of: Video conferencing: It has to do with a set of interactive telecommunication

technologies which allow two or more locations to interact via two-way video and audio transmissions simultaneously. It has also been called visual collaboration and is a type of groupware. It differs from videophone in that it is designed to serve a conference rather than individuals[9]. Mobile Internet: This is also referred to as the mobile web. The Mobile Web refers to the access to browser-based web services such as the World Wide Web, WAP, and iMode using a mobile device such as cell phones, PDAs, and other portable gadgets connected to a public network. Such access does not require a desktop computer, nor a fixed landline connection.[3] P2P file transfer in wireless communication: this form of communication does not have the notion of clients or servers but only equal peer nodes that simultaneously function as both "clients" and "servers" to the other nodes on the network. This model of network arrangement differs from the client-server model where communication is usually to and from a central server.[9] It also helps in the reliable database updation in the wireless networks. Finally, it can be used in the medical field for transferring medical related files.

3.3 EXISTING SYSTEM

The main idea behind Freeze-TCP is to move the onus of signaling an impending disconnection to the client. A mobile node can certainly monitor signal strengths in the wireless antennas and detect an impending handoff; and in certain cases, might even be able to predict a temporary disconnection (if the signal strength is fading, for instance). In such a case, it can advertise a zero window size, to force the sender into the ZWP mode and prevent it from dropping its congestion window. Even if one of the zero window probes is lost, the sender does not drop the congestion window. To implement this scheme, only the clients TCP code needs to change and there is no need for an intermediary (no code changes are required at the base station or the sender).

xxxvii

If the receiver can sense an impending disconnection, it should try to send out a few (at least one) acknowledgements, wherein its window size is advertised as zero (let an ACK with a zero receiver window size be abbreviated ZWA, i.e., Zero Window Advertisement). But the question is: how much in advance of the disconnection should the receiver start advertising a window size of zero? This period is in a sense the warning period prior to disconnection. Ideally, the warning period should be long enough to ensure that exactly one ZWA gets across to the sender. If the warning period is any longer, the sender will be forced into Zero Window Probe mode prematurely, thereby leading to idle time prior to the disconnection. If the warning period is too small, there might not be enough time for the receiver to send out a ZWA which will cause the senders congestion window to drop due to packets lost during the disconnection (which, in turn leads to some idle-time/underutilization after the reconnection).

Given this, a reasonable warning period is the round-trip-time (RTT). During periods of continuous data transfer, this allows the sender to transmit a packet and then receive its acknowledgment. Since the ZWPs are exponentially backed off, there is the possibility of substantial idle time after a reconnection. This could happen, for instance, if the disconnection period was long and the reconnection happened immediately after losing a ZWP from the sender. In that case, the sender will go into a long backoff before sending the next probe. Meantime the receiver has already reconnected, but the connection remains idle until the sender transmits its next probe. To avoid this idle time, they implemented a scheme in which as soon as a connection is re-established, the receiver sends 3 copies of the ACK for the last data segment it received prior to the disconnection. This scheme is henceforth abbreviated as TR-ACKs (Triplicate Reconnection ACKs).[18]

3.4 PROPOSED SYSTEM To accommodate TCP to more real handoff situations, a path recovery notification (TCPPRN) mechanism is proposed. To illustrate, when a TCP receiver1 is attached to a new access point after a disconnection period or handoff, it sends a special ack. This ack consists of two components: one is a PRN option, and the other is a TCP SACK option which contains information on the sequence numbers of the lost packets. This ack notifies a TCP sender that

xxxviii

which packets are lost due to this temporal link disconnection. Then, the TCP sender immediately attempts to retransmit those lost packets. If the congestion window (cwnd) and the slow start threshold (ssthresh) are unnecessarily reduced due to a false retransmission timeout (RTO) happening not due to network congestion but due to the handoff, the TCP sender restores the cwnd and the ssthresh with the values before the handoff [13]. The basic principle of TCPPRN is to fast recover the adverse impact of the temporal link disconnection due to a handoff. To alleviate the influence of packet losses during the disconnection, a TCP receiver on a (Mobile Node) MN notifies its TCP sender on a (Fixed Node) FN of the temporal disconnection through a special ack. Then, the TCP sender retransmits the lost packets and restores the reduced cwnd and ssthresh, if a false RTO occurs. TCPPRN requires modifying both the senders and receivers operations on the TCPSACK option. Some variables included in TCPPRN are listed as follows: _ PRN option: This option plays a role in notifying the sender that a wireless link was temporally disconnected and reconnected. The option is set to one of three condition flags: reconnection (RC), partial loss (PL), and no packet arrival (NPA). win_: This is an existing variable already declared in the reno tcp. With respect to the new protocol proposed, instead of adding a duplicate value of the cwnd_ to the actual cwnd_ and storing it in the win_, this new protocol simply stores the value of the cwnd_ in this variable win_ and hence, win_ in our new protocol is a variable that holds a copy of cwnd. It is used to restore cwnd if an RTO occurred due to a disconnection. ssthresh_: This variable holds half the value of the cwnd_ value. It is used to restore ssthresh if an RTO occurred due to a disconnection and if this ssthresh_ is greater than the max_ssthresh_ value. _ lsent_time: This variable is a copy of the ts_ time stamp and it indicates the time of the last packet transmitted from the TCP sender within a window due to a RTO or a fast retransmit. PRN_ timer: This variable has been designated as lsent_time + last_rtt_. If this timer expires, the PRN option with NPA is sent to the sender to notify that there may have been a loss of all packets [13].

3.5 PROJECT DESCRIPTION

xxxix

In the TCPPRN algorithm, the sender should decide whether all packets were lost during handoff or not. The key factors to determine this are lsent_time and RTT. Because the receiver only informs the sender of three conditions, i.e., RC, PL, and NPA, used in TCP PRN algorithm, the sender cannot tell how many packets were lost when it received a PRN option set to RC flag
[13]

. Through simulations, we found that all packets were lost in cases where the

sender received a PRN option with RC flag after lsent_time + RTT. This observation leads to the conclusion that a PRN option after lsent_ time + RTT ensures all packets were dropped during handoff. Additionally, because TCPPRN uses RTT only for determining the state of lost packets, the effect of RTT variation becomes insensitive to the TCP performance. Basically, TCPPRN does not modify the existing RTT estimation algorithm. When the RTT estimation is incorrect, the performance of TCPPRN will be similar to that of Freeze-TCP. Even though both of them stop sending packets during an RTT period, TCPPRN stops sending the lost packets during a RTT after handoff, whereas Freeze-TCP does it during a RTT before handoff. In view of this, in this project, some means will be found to estimate: RTT

This RTT calculation will be done for the existing proposed solution- that is the Freeze-TCP. Also, there will be RTT estimation for the new proposed mechanism- that is the TCP-PRN RTO

Based on the RTT estimation, RTO will be estimated for both the freeze-TCP and the TCP-PRN. Window size

Similarly, window size estimation will be done for both the existing proposed solution (FreezeTCP) and the new proposed mechanism- (TCP-PRN)

After the estimation of the Round Trip Time (RTT) and the Window size, a fairness factor will be added. This fairness Factor will include delay time, time to transmit frame, propagation time, processing time at station, time to transmit acknowledgement, etc.

Also, the Freeze-TCP made use of several TCP solutions in that it was a modification of these solutions. Some of them include snoop, I-TCP, M-TCP, Delayed Dupacks, and ESBN. Based on the strengths and weaknesses of these solutions, they came out with the freeze-TCP. Below is a table of the comparison made and the basis on which the comparison was made.

xl

SNOOP

ITCP MTCP

& M-TCP

Delayed Dupacks

ESBN

Proposed FreezeTCP

Requires intermediate node TCP mods?

yes

yes

Yes

no

yes

no

Handle Encrypted no Traffic? End-to-End semantics Handle disconnections Frequent Disconnections no long no TCP yes

no

No

yes

no

yes

no

No

yes

no

yes

May run out yes of buffers Handoff costly Handoff may be costly

no

yes

yes

no

yes

yes

Handle high BER

yes

yes

yes

no

no

no

Table 1. Characteristics of various mobile TCP solutions (BER refers to bit-error-rate)[18]

However, the new protocol takes the existing Reno TCP solution and makes alterations and modifications to give a much better result when compared with the Freeze TCP.

3.6 FUNCTIONAL SPECIFICATION The proposed protocol involves the inclusion of some preprocessor directives and the generation of some agents for both the sender side and the receiver side. The existing tcp.h has been altered to enable us obtain the required output. In addition to the tcp.h, tcpprn.cc (i.e. the tcp-prn agent in our proposed protocol) has been generated. The tcp-reno.cc is the parent class of this newly generated agent with some modifications as per the descriptions stated in the base paper. At the receiver side, a new sink agent known as tcp-prn-sink.cc has been generated. This new sink agent was derived from the existing TcpSink class. As per the project description, the following functions/modules were developed and these are:

xli

Topology generation. Sender side TCP agent. Receiver side TCP agent. Modification over preprocessor directives Modification over ns-defaut.tcl

3.6.1 Topology generation A wired cum wireless topology has been generated to help in the implementation of the proposed protocol. This topology consists of a fixed host, a gateway node, base station and a wireless/mobile node. Packets of data are sent from the fixed host to the mobile node via the gateway and base station nodes. The proposed protocol (the proposed tcp agent and its sink agent) has been attached to this protocol.

3.6.2 Sender side TCP agent In other to develop the proposed protocol, a sender side TCP agent known as TCP-PRN was developed. This was derived from the Reno TCP agent and some modifications were made in the congestion window (cwnd_), window size (wnd_) values and some new variables like new_rtt_, lsent_time_ and ssthresh_ were introduced to help in the realization of the proposed protocol.

3.6.3 Receiver side TCP agent Similar to the sender side, a TCP sink agent has been developed to help in the proper and near accurate implementation of the proposed protocol. This new sink agent is referred to as the PRNSink agent and was derived from the main TCPSink agent with some modifications and introduction of some classes such as predict_con(), predict_discon() which helps in informing about a disconnection or connection and what needs to be done.

3.6.4

Modification over preprocessor directives

With respect to the base paper, some existing preprocessor directives were modified. These are tcp.h and packet.h. In the tcp.h, the following lines were added:
class PrnTcpAgent : public virtual TcpAgent { public: PrnTcpAgent();

xlii virtual int window(); virtual int ssthresh(); //virtual double tstamp(); virtual double windowd(); virtual double ssthreshd(); virtual void recv(Packet *pkt, Handler*); virtual void timeout(int tno); virtual void dupack_action(); protected: int allow_fast_retransmit(int last_cwnd_action_); unsigned int dupwnd_; int new_rtt_; int ssthresh_; int pl_; int npa_; int rc_; }

In the packet.h, a new packet was introduced. This new packet is known as PT_PRN. This new packet is sent based on the type of PRN option (that is either pl_, npa_, or rc_) is received.

3.6.5

Modification over ns-defaut.tcl

The ns-default TCL file was modified. This line was added to it Agent/TCP/Prn set new_rtt_ 0 to set a default value for the new_rtt_ variable declared. Similarly, the ssthresh_ variable declared has been initialized in the ns-default.tcl.

3.7

NON-FUNCTIONAL SPECIFICATION

This project will also require some non-functional requirements such as: Reliability

The protocol to be designed is expected to ensure reliability properties with respect to the delivery of data to the intended recipient(s) (Mobile host, Fixed host and the base stations). Response Time

In this proposed protocol, it is expected that the time elapsed between the dispatch (time when task is ready to execute) to the time when it finishes its job (one dispatch) is minimal.

3.8 HARDWARE REQUIREMENTS Processor: Intel Pentium III processor Memory: 128 MB RAM

xliii

Hard disk: 40 GB

3.9 SOFTWARE REQUIREMENTS NS-2 Tool C++, TCL Linux platform Windows XP TraceGraph and Xgraph CHAPTER 4

4.0 SOFTWARE DESIGN SPECIFICATION

In order to realize the proposed protocol, some classes and variables were declared in addition to the existing ones. These classes are ssthresh(), ssthreshd(), predict_con() and predict_discon(). In addition to these classes, some modules have been developed. Below is a design of those modules as specified in the functional specification.

4.1 NETWORK TOPOLOGY The generated topology consists of four nodes. These are Fixed host (FH), Gateway (G), Base Station (BS) and Mobile node (MH). The bandwidth between the FH and the G is 5MB and is at a speed of 100ms. Between the G and the BS is 1MB at a speed of 10ms. This is a bottle-neck topology.

FH

5MB 100m

1MB 10ms

BS -------------------Wireless network

MH

Wired network

Fig 8 topology for simulation

4.2 SENDER SIDE TCP AGENT 4.2 .1 Sender side operation

xliv

The sender begins to recover lost packets when it receives an ack with a PRN option. The detailed operations of the sender are as follows: (1) When the sender receives a PRN option and a retransmission timer is pending, the sender checks the condition flag of the PRN option. (a) If the PRN option is set to RC condition flag, the sender compares the time, lsent_time + RTT2 with the time, now. If now is larger than lsent_time + RTT, the TCP sender regards all packets as lost and then retransmits all unacknowledged packets; Otherwise, the sender does nothing. If the sender transmitted the lost packets, the process moves to Step 1(d). (b) If the PRN option is set to NPA condition flag, the sender follows the operations in Step 1(a). However, if now is smaller than lsent_time + RTT, the sender cancels the pending retransmission timer and enters the slow start algorithm. (c) If the PRN option is set to PL condition flag and SACK blocks are included, the sender retrieves the sequence numbers of the lost packets from each SACK block, immediately sends the lost packets to the receiver, and resets the retransmit timer to prevent the timer from expiring during the recovery of the lost packets. If the sender transmitted the lost packets, the process moves to Step 1(d). (d) When the sender receives duplicate acks after transmitting the lost packets, it transmits a new packet for each dupack if congestion window is available, which is similar to the method adopted in [13] and the limited transmit algorithm [14]. (e) All other PRN options are ignored if the retransmitted packets by the first PRN option are still in-flight and if the retransmission timer is not expired yet. If the retransmitted packets successfully arrive and the sender receives a new non-dupack from the receiver, it continues to send new packets upon an incoming ack. (2) When the sender receives a PRN option and RTO has already occurred, the sender replaces cwnd and ssthresh with ocwnd and ossthresh, respectively, as shown in Fig. 9a. With an enlarged cwnd, the sender flushes both the unacknowledged packets and new packets into the network and continues the normal operation of TCP.

FH

BS MH

xlv

4.2 .2

Fig. 9a All packet losses with RTO [13]

Sender side Pseudocode if PRN option is

received and retransmission time is pending then check if PRN option = RC then compare (lsent_time + RTT) with now if now is greater than (lsent_time +RTT) then sender regards all packets as lost (npa) and then retransmits all unacknowledged packets.

else check if PRN option = NPA then compare (lsent_time + RTT) with now if now is less than (lsent_time +RTT) Then sender cancels pending retransmission and enters the slow start algorithm. else Check if PRN option = PL and SACK blocks are induced sender retrieves the sequence numbers of lost packets from each SACK block sender sends the lost packets to the receiver.

4.3 RECEIVER SIDE TCP AGENT 4.3.1 Receiver side operation The receiver reacts to a temporal disconnection as follows: (1) The receiver recognizes the recovery of the wireless link with the assistance of the link layer and Mobile IP [1]. Once the receiver knows that the wireless link has been reconnected, it informs the sender with this information by sending an ack with a PRN option set to the condition flag RC. The sender immediately checks if the senders retransmission timer expires or if one RTT has passed after the lsent_time. (2) Next, the receiver schedules a PRN timer with RTT because any additional packets are expected to be delivered within RTT/2, if they exist.

xlvi

(a) Before the PRN timer expires, if new packets arrive at the receiver as shown in Fig. 9b, it is possible that they include gaps in the sequence numbers. In this case, the receiver sends an ack packet with a PRN option set to PL flag and a SACK block. This ensures that the sender only transmits the lost packets. Then, the receiver cancels the PRN timer. (b) If no new packets arrive at the receiver and the PRN timer expires, the receiver sends an ack packet with only the PRN option set to NPA. This forces the sender to send all unacknowledged packets or to perform the slow start algorithm.

FH

BS MH

Fig 9b All packet losses without RTO [13]

4.3.2 Receiver side pseudocode After reconnection, set timer = RTT/2 While timer is less than (RTT/2) If new packets arrive (then there is possibility of gaps in sequence) Hence receiver sends an ack packet with PRN option = PL Then sender retransmits only loss packets else while timer is less than (RTT/2) and if no new packets arrive and the timer expires, receiver sends an NPA ack packet Then sender sends all unacknowledged packets or performs the slow start algorithm

xlvii

4.4 MODIFICATION OVER PREPROCESSOR DIRECTIVES AND THE NSDEFAULT.TCL Some lines of code were added to the existing tcp.h to enable us obtained the proposed protocol. Some of the classes and variables that were added include: ssthresh(); ssthreshd(); int new_rtt_; int ssthresh_; int pl_; int npa_; int rc_; In addition to the tcp.h, the packet.h was also modified. A new packet known as PT_PRN was added to enable the new protocol to respond to the various PRN options. Similarly, the nsdefault.tcl was also modified. Variables like new_rtt_ and ssthresh_ were given default values.

xlviii

4.5 DESIGN DIAGRAMS 4.5.1 Flow chart for Freeze-TCP

Start Sending Packets

Packet sent from FH

Packet successfully delivered to BS

Packet Sent from BS

Any possible handoff predicted?

NO

Packet successfully sent to MH

YES
MH sends ZWA and Freeze Packet Transmission

FH receives ZWA and starts sending ZWP

xlix

Check if link is reconnected ?

NO

Sender Keeps send ZWP and Checks if reconnected

YES
MH sends TR-ACK

Sender starts transmitting data exponentially End of transmissio n

Fig 10. Freeze-TCP operations

4.5.2 Flow chart for PRN

Start Sending Packets

Packet sent from FH to BS

Packet successfully delivered to BS

Any possible disconnecti on signal from MH

Packet successfully sent to MH

Special ACK sent to sender (BS)

Receiver attached to new access point (BS)

ACK sent to Sender

li

Check if any packet got lost

Transmission continues

Sender retransmits lost packets

Is cwnd and ssthresh unnecessarily reduced due to false RTO happening not due to congestion

Transmission continues

Sender restores cwnd and ssthresh values with values before handoff End of transmissio n

Fig 11. PRN-TCP operations

lii

4.5.3 Interaction Diagrams Scenario 1.

F H
t1 Forward packet to BS t2 Packet delivered t3 t4 t5 t6 t7

G
Send packet to MH via G

BS

MH

Ack received. So new packet would be sent at time t7

ack sent to FH ack forwarded

Fig. 12 - Normal PRN operation

Scenario 2
F H
Send packet to MH via G

BS

MH

t1 t2 t3 t4 t5 t6 t7

Forward packet to BS Packet delivered

Sender pends waiting for ack so it can send the next packet

ack sent but not delivered

Fig 13. PRN operation when ack is not received

Scenario 3

liii

F H

BS

MH

Send packet to MH via G t1 t2 t3 t4 t5 Sender pends waiting for ack so it If the timer expires and RTO has already occurred, FH flushes the unack packets and new packets into the ntwk and continues normal TCP operation ack sent but not delivered
Forward packet to BS Packet delivered

Fig14-PRN response after timer expires

liv

CHAPTER 5

5.0 IMPLEMENTATION AND TESTING

5.1 IMPLEMENTATION The proposed protocol was implemented in the TCL language. The topology that was developed/generated was a wired cum wireless network. In this topology, there are four nodes which perform the roles of a fixed host, gateway node and a base station and a mobile node. Packets are sent from the fixed host to the mobile host through the gateway and base station nodes. Some of these packets drop due to temporal disconnection and handoffs. Below is a sample of the TCL code used in implementing this proposed protocol:
### This simulation is an example of combination of wired and wireless ### topologies. #source C:/ns-allinone-2.31/ns-2.31/tcl/lib/dump_.tr.ip.tcl source /root/Desktop/ns-allinone-2.33/ns-2.33/tcl/lib/ns2_shared_procs.tcl #load /usr/local/lib/libnsfreezetcp.so global opt set opt(chan) Channel/WirelessChannel set opt(prop) Propagation/TwoRayGround set opt(netif) Phy/WirelessPhy set opt(mac) Mac/802_11 set opt(ifq) Queue/DropTail/PriQueue set opt(ll) LL set opt(ant) Antenna/OmniAntenna set opt(x) 670 set opt(y) 670 set opt(ifqlen) 50 set opt(tr) tcpprn.tr set opt(namtr) tcpprn.nam set opt(nn) 1 set opt(adhocRouting) DSDV set opt(cp) "" set opt(sc) "../mobility/scene/scen-3-test" set opt(stop) 10 set num_wired_nodes 2 set num_bs_nodes 1

set ns_

[new Simulator]

# set up for hierarchical routing $ns_ node-config -addressType hierarchical AddrParams set domain_num_ 3 lappend cluster_num 2 1 1 AddrParams set cluster_num_ $cluster_num

lv
lappend eilastlevel 1 1 4 1 AddrParams set nodes_num_ $eilastlevel set trace_fd [open $opt(tr) w] #set ns use-newtrace $ns_ trace-all $trace_fd set nam_trace_fd [open $opt(namtr) w] $ns_ namtrace-all $nam_trace_fd

set topo [new Topography] $topo load_flatgrid $opt(x) $opt(y) # god needs to know the number of all wireless interfaces create-god [expr $opt(nn) + $num_bs_nodes] #create wired nodes set temp {0.0.0 0.1.0} for {set i 0} {$i < $num_wired_nodes} {incr i} { set FH($i) [$ns_ node [lindex $temp $i]] } $ns_ node-config -adhocRouting $opt(adhocRouting) \ -llType $opt(ll) \ -macType $opt(mac) \ -ifqType $opt(ifq) \ -ifqLen $opt(ifqlen) \ -antType $opt(ant) \ -propInstance [new $opt(prop)] \ -phyType $opt(netif) \ -channel [new $opt(chan)] \ -topoInstance $topo \ -wiredRouting ON \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF set temp {1.0.0 1.0.1 1.0.2 1.0.3} set BS(0) [$ns_ node [lindex $temp 0]] $BS(0) random-motion 0 $BS(0) set X_ 1.0 $BS(0) set Y_ 2.0 $BS(0) set Z_ 0.0

#configure for mobilenodes $ns_ node-config -wiredRouting OFF for {set j 0} {$j < $opt(nn)} {incr j} { set node_($j) [ $ns_ node [lindex $temp \ [expr $j+1]] ] $node_($j) base-station [AddrParams addr2id [$BS(0) node-addr]] } $node_(0) $node_(0) $node_(0) $node_(0) random-motion 0 set X_ 125.0 set Y_ 125.0 set Z_ 0.0

lvi

$ns_ at 0.0 "$node_(0) setdest 25.0. 25.0. 150.0" $ns_ at 5.0 "$node_(0) setdest 250.0 250.0 15.0"

#create links between wired and BS nodes $ns_ duplex-link $FH(0) $FH(1) 5Mb 100ms DropTail $ns_ duplex-link $FH(1) $BS(0) 1Mb 10ms DropTail

#Define the queue size for the link between node G and BS $ns_ queue-limit $FH(1) $BS(0) 5 $ns_ duplex-link-op $FH(0) $FH(1) orient right $ns_ duplex-link-op $FH(1) $BS(0) orient right #Monitor the queues for links $ns_ duplex-link-op $FH(0) $FH(1) queuePos 0.5

$ns_ duplex-link-op $FH(0) $FH(1) orient down $ns_ duplex-link-op $FH(1) $BS(0) orient left-down #$ns_ duplex-link-op $W(1) $BS(1) orient right-down # setup TCP connections set tcp1 [new Agent/TCP/Prn] $tcp1 set class_ 2 set sink1 [new Agent/TCPSink/Prn] $ns_ attach-agent $FH(0) $tcp1 $ns_ attach-agent $node_(0) $sink1 $ns_ connect $tcp1 $sink1 set ftp1 [new Application/FTP] $ftp1 attach-agent $tcp1 $ns_ at 0.10 "$ftp1 start"

for {set i } {$i < $opt(nn) } {incr i} { $ns_ at $opt(stop).0000010 "$node_($i) reset"; } $ns_ at $opt(stop).0000010 "$BS(0) reset"; $ns_ at $opt(stop).1 "puts \"NS EXITING...\" ; $ns_ halt" puts "Starting Simulation..." $ns_ run dump_.tr.ip tcpprn.tr

5.2 TESTING The protocol has been tested under unit and Integration testing.

Unit testing

lvii

All the modules and classes have been tested individually and are working properly.

Integration Testing The modules developed have been integrated and have been tested and its working as required.

5.3 SCREEN SHOTS

Fig 15a.Wired cum wireless topology (with mobile host moving)

lviii

Fig 15b. Wired cum wireless topology (with stationary mobile host)

lix

5.4 Throughput Graphs

Fig 16. Throughput of sending/generating packets

Reno TCP (a) TCP (c)

New Reno TCP

(b)

Freeze

lx

Fig 17. Throughput of receiving packets

lxi

Reno TCP (a) Freeze TCP (c)

New Reno TCP (b)

Fig 18. Throughput of forwarding packets

lxii

Reno TCP (a) TCP(c)

New Reno TCP (b)

Freeze

lxiii

Fig 19. Throughput of dropping packets

lxiv

lxv

Reno TCP (a)

New Reno TCP (b)

Freeze T

Throughput graphs for the proposed protocol (PRN TCP agent) in comparison with throughput graphs of the Freeze TCP agent

Fig 20. Throughput of sending/generating packets Fig 21. Throughput of receiving packets

lxvi

PRN vs Freeze

PRN vs Freeze

Fig 22. Throughput of forwarding packets Throughput of dropping packets

Fig 23.

lxvii

PRN TCP

Freeze TCP

PRN TCP

lxviii

5.4 PERFORMANCE ANALYSIS Throughput of generating/sending packets Time (Reno) (NewReno) (Freeze) 0 0 0 0 1 18 18 20 2 21 22.5 19 3 4 20 14.5 4 21.5 10 25 5 33 29 35 6 48 41.5 55 7 60 57.5 65 8 74 67 59.5 9 74.5 74 15 10 75 73.5 20 Table 2. Throughput of generating/sending packets

(PRN) 0 20 19.9 17 23 45 52.5 69.5 72 75 73

Fig 24a Throughput of generating/sending packets

lxix

Fig 24b Throughput of generating/sending packets All the four agents were implemented using the same parameters. From the implementation it could be seen that the proposed protocol sends more packet as compared to the others.

Throughput of receiving packets Time (Reno) (NewReno) (Freeze) 0 0 0 0 1 10 10 10 2 20 21 19.6 3 10 19 15 4 18 10.5 20 5 30.5 21.5 35 6 40.5 39.5 58 7 58 51 63 8 69 64.5 61 9 73.5 74 21 10 59 60 15 Table 3. Throughput of receiving packets

(PRN) 0 10 20 17 22 39 50 63 72 75 58.5

lxx

Fig 25a. Throughput of receiving packets

Fig 25b. Throughput of receiving packets From the implementation it could be seen that the proposed protocol enable the tcp receiver at the receiver side to receive more packets as compared to the others hence reducing the number of packets dropped.

lxxi

It could be seen from the various implementation that the proposed protocol performs better than the others. However, the freeze TCP agent also does well. Hence, a close comparison is made to identify which amongst the two drops more packets. Throughput of dropping packets Time (Freeze) (PRN) 1 1 1 2 1 1 3 0 0 4 0 0 5 0 0 6 0 0 7 0.2 0 8 2 0 9 0 0 10 1 0 Table 4. Throughput of dropping packets

Fig 26. Throughput of dropping packets It clearly shows that the Freeze TCP agent keeps dropping more packets even at a time when the proposed protocol does not, hence making our proposed protocol quite better than the existing ones.

lxxii

CHAPTER 6

6.0 CONCLUSION AND FUTURE WORK The proposed protocol has been simulated in NS2. Graphs have been obtained with the help of trace graph. From a careful analysis and from the extensive simulations, it has been found that the proposed protocol outperforms the other protocols in a more real wired cum wireless environment. In spite of the increase in performance, there is the need to further investigate the fast adaptation of the congestion window in wireless networks where mobile nodes move. Also, there is the need to increase the window size to allow for more packet transmission while minimizing packet drops.

lxxiii

REFERENCES 1. A&M Records v. Napster, Inc., 239 F.3d 1004, 1019 (9th Cir. 2001) citing Matthew Bender & Co. v. West Publ'g Co., 158 F.3d 693, 706 (2d Cir. 1998) 2. Antonio Iera, Antonella Molinaro, and Salvatore Marano. (SEPTEMBER 2002). Handoff Management with Mobility Estimation in Hierarchical Systems- IEEE transactions on vehicular technology, VOL. 51, NO. 5 3. Banerjee, Syagnik & Dholakia, Ruby Roy. (2008)"Does Location Based Advertising Work?" (International Journal of Mobile Marketing, Dec) 4. C. Parsa, J. Garcia-Luna-Aceves. (2000). Improving TCP performance over wireless networks at the link layer. ACM Mobile Networks and Applications. 5. C. Perkins. (2002). IP Mobility Support. RFC. 6. Dzmitry Kliazovich and Fabrizio Granelli. (2004). A Cross-layer Scheme for TCP Performance Improvement in Wireless LANs. IEEE Communications Society 7. E. Ayanoglu, S. Paul, T.F. LaPorta, K. Sabnani, R.D. Gitlin. (1995). AIRMAIL: a link-layer protocol for wireless networks. ACM Wireless Networks. 8. H. Balakrishnan, S. Seshan,.R.H. Katz. (1995). Improving reliable transport and handoff performance in cellular wireless networks. ACM Wireless Networks 9. http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.10.4942 10. http://www.cs.cmu.edu/~srini/Papers/1995.Balakrishnan.winet.pdf\ 11. Liangping Ma, Student Member, IEEE, Gonzalo R. Arce, Fellow, IEEE, and Kenneth E. Barner, Senior Member, IEEE.( JUNE 2004). TCP Retransmission Timeout Algorithm Using Weighted Medians- IEEE signal processing letters, VOL. 11, NO. 6. 12. M. Allman, H. Balakrishnan, S. Floyd. (2003). Enhancing TCPs Loss Recovery Using Limited Transmit, RFC, 3042. 13. Myungjin Lee, Moonsoo Kang, Myungchul Kim, Jeonghoon Mo. (2008). A cross-layer approach for TCP optimization over wireless and mobile networksComputer Communications 31, 26692675 14. P. Sarolahti, M. Kojo, K. Raatikainen. (2003) F-RTO: an enhanced recovery algorithm for TCP retransmission timeouts. ACM SIGCOMM Computer Communication

lxxiv

15. R. Hsieh, A. Seneviratne (2003). A comparison of mechanisms for improving mobile IP handoff latency for end-to-end TCP- International Conference on Mobile Computing and Networking. 16. R. Ludwig, R.H. Katz. (2000). The Eifel Algorithm: making TCP robust against spurious Retransmissions.ACM SIGCOMM Computer Communication Review. 17. S. Bhandarkar, N.E. Sadry, A.N. Reddy, N.H. Vaidya. (2005). TCP-DCR: a novel protocol for tolerating wireless channel errors- IEEE Transaction on Mobile Computing. 18. T. Goff, J. Moronski, D. Phatak, V. Gupta. (2000). Freeze-TCP: a true end-toend TCP enhancement mechanism for mobile environments- IEEE International Conference on Computer Communication, vol. 3. 19. W. Richard Stevens.(1997). RFC 2001 - TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. Network Working Group