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.

PROF.C.MALATHY

Head of the Department,

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

SRM University. SRM University.

Signature of Internal Examiner Signature of External Examiner

Date: Date:

iii

ABSTRACT

Supporting user’s 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 (TCP–PRN) mechanism has been proposed to prevent

performance degradation during a handoff. The proposed protocol, TCP–PRN, 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.

v

DEDICATION

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

vi

TABLE OF CONTENTS

Content Page Number

Certification…………………………………………………………………………… ii

Abstract……………………………………………………………………………….. iii

Acknowledgement……………………………………………………………………. iv

Dedication……………………………………………………………………………. v

Table of Contents…………………………………………………………………….. vi

List of Tables………………………………………………………………………… x

List of Figures……………………………………………………………………….. xi

List of abbreviations………………………………………………………………… xiii

Chapter 1. INTRODUCTION…………………………………………………….. 1

1.1 Explanation of concepts used……………………………………………. .. 2

1.1.1 Round Trip Time (RTT)……………………………………………… 2

1.1.2 Slow Start mechanism……………………………………………….. 2

1.1.3 Congestion avoidance.……………………………………………….. 3

1.1.4 Fast retransmit……………………………………………………….. 3

1.1.5 Fast recovery…….. ………………………………………………….. 4

1.1.6 Congestion window………………………………………………….. 4

1.1.7 Handoff………………………………………………………………. 5

Chapter 2. LITERATURE SURVEY……………………………………………. 6

2.1 TCP…………………………………………………………………. 6

vii

2.1.1 TCP’s window management and problems in mobile environments…… 8

2.1.2 Problems with TCP in mobile environments…………………………… 9

2.1.3 TCP Control…………………………………………………………….. 9

2.2 TCP-Reno……………………………………………………………….. 10

2.3 TCP-Newreno………………………………………………………........ 12

2.4 The Snoop protocol model……………………………………………….. 13

2.4.1 Snoop_output()…………………………………………………………… 14

2.4.2 Snoop_input()…………………………………………………………….. 15

2.5 Freeze TCP………………………………………………………………... 17

2.6 TCP- PRN (TCP-Path Recovery Notification)……………………………. 21

Chapter 3. SOFTWARE REQUIREMENT SPECIFICATION……………………. 23

3.1 Scope…………………………………………………………………….. 23

3.2 Audience…………………………………………………………………. 23

3.3 Existing System………………………………………………………….. 24

3.4 Proposed System………………………………………………………… 25

3.5 Project Description……………………………………………………….. 26

3.6 Functional Specification………………………………………………….. 28

3.6.1 Topology Generation…………………………………………………….. 28

3.6.2 Sender side TCP agent…………………………………………………… 29

3.6.3 Receiver side TCP agent…………………………………………………. 29

3.6.4 Modification over preprocessor directives……………………………….. 29

viii

3.6.5 Modification over ns-default.tcl………………………………………… 30

3.7 Non-Functional Specification…………………………………………… 30

3.8 Hardware requirement…………………………………………………… 30

3.9 Software requirement…………………………………………………… 30

Chapter 4. SOFTWARE DESIGN SPECIFICATION……………………………… 31

4.1 Network Topology……………………………………………………….. 31

4.2 Sender side TCP agent…………………………………………………… 31

4.2.1 Sender side operation…………………………………………………….. 31

4.2.2 Sender side pseudocode…………………………………………………. 33

4.3 Receiver side TCP agent…………………………………………………. 33

4.3.1 Receiver side operation………………………………………………….. 33

4.3.2 Receiver side pseudocode………………………………………………… 34

4.4 Modification over preprocessor directives and ns-default.tcl……………. 35

4.5 Design diagrams………………………………………………………….. 36

4.5.1 Flow chart for Freeze-TCP……………………………………………….. 36

4.5.2 Flow chart for PRN-TCP………………………………………………… 38

4.5.3 Interaction diagrams……………………………………………………… 40

Chapter 5. IMPLEMENTATION AND TESTING…………………………………. 42

5.1 Implementation…………………………………………………………… 42

5.2 Testing……………………………………………………………………. 45

5.3 Screen shots………………………………………………………………. 45

ix

5.4 Throughput graphs……………………………………………………… 47

5.5 Performance analysis……………………………………………………. 53

Chapter 6. CONCLUSION AND FUTURE WORK……………………………… 57

References……………………………………………………………………… 58

x

LIST OF TABLES

1. Characteristics of various mobile TCP solutions……………………………… 27

2. Throughput of generating/sending packets………………………………….. 53

3. Throughput of receiving packets…………………………………………….. 54

4. Throughput of dropping packets…………………………………………….. 56

xi

LIST OF FIGURES

1. TCP Window Management…………………………………………………….. 8

2. State Machine for snoop_output()……………………………………………… 13

3. Performance of snoop protocol compared to normal TCP…………………….. 16

4. State machine for snoop_input()………………………………………………. 16

5. Relation between ts, rtt and w state……………………………………………. 18

6. Illustration of increased throughput due to Freeze-TCP……………………… 19

7. TCP three-way handshake……………………………………………………… 22

8. Topology for simulation………………………………………………………… 31

9a. All packet losses with RTO…………………………………………………….. 32

9b. All packet losses without RTO…………………………………………………. 34

10. Freeze-TCP operations…………………………………………………………. 36

11. TCP–PRN operations………………………………………………………….. 38

12. Normal PRN operation…………………………………………………………. 40

13. PRN operation when ack is not received………………………………………. 40

14. PRN response after timer expires………………………………………………. 41

15a . Wired cum wireless topology (with mobile host moving)…………………….. 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………………………………………………… 50

20. Throughput of sending/generating packets(prn vs freeze)……………………… 51

21. Throughput of receiving packets(prn vs freeze)……………………………….. 51

22. Throughput of forwarding packets(prn vs freeze)……………………………… 52

23. Throughput of dropping packets(prn vs freeze)………………………………… 52

24-26. Performance analysis on the throughput graphs……………………………. 53

xiii

List of Abbreviations

1 TCP…………………….. ……………………. Transmission Control Protocol

2 PRN…………………………………………… Path Recovery Notification

3 RTT…………………………………………… Round Trip Time

4 MSS…………………………………………… Maximum Segment Size

5 CWND………………………………………… Congestion Window

6 ACK ………………………………………….. Acknowledgement

7 MH……………………………………………. Mobile Host

8 FH……………………………………………. Fixed Host

9 BS…………………………………………….. Base Station

10 ZWA …………………………………………. Zero Window Advertisement

11 NZWA………………………………………… Non-Zero Window Advertisement

12 ZWP…………………………………………… Zero Window Probe

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 user’s 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. TCP–PRN 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, TCP–PRN appears to exacerbate the network

congestion. TCP–PRN 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 along—generally in the

right direction—until 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 TCP’S 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 receiver’s 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 receiver’s 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 receiver’s 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 isn’t 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 Karn’s 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 re-

transmit 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 Re-

Transmit’. Whenever we receive 3 duplicate ACK’s 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 ACK’s 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 ACK’s. 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 ACK’s 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 don’t 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 doesn’t 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 doesn’t 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 haven’t 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 round-

trip 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 TCP’s 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 client’s 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

sender’s 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 re-

established, 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.

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 sender’s window. From the figure, it is seen that if any idle periods are to be avoided:

Fig 5. Relation between TS, RTT AND W [18]

(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

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 re-

growing (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:

(2)

(3)

is required for Assuming

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 TCP–PRN 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].

TCP–PRN requires modifying both the sender’s and receiver’s operations on the TCP–SACK

option. Some variables included in TCP–PRN 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 sender’s and receiver’s 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 TCP–PRN 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 3-

way 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, TCP–PRN,

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 i-

Mode 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 client’s 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 sender’s 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 (TCP–PRN)

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 TCP–PRN 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. TCP–PRN

requires modifying both the sender’s and receiver’s operations on the TCP–SACK option. Some

variables included in TCP–PRN 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 TCP–PRN 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 TCP–PRN uses RTT only for determining the state of lost

packets, the effect of RTT variation becomes insensitive to the TCP performance. Basically,

TCP–PRN does not modify the existing RTT estimation algorithm. When the RTT estimation is

incorrect, the performance of TCP–PRN will be similar to that of Freeze-TCP. Even though both

of them stop sending packets during an RTT period, TCP–PRN 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 (Freeze-

TCP) 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

Freeze-

TCP

Requires

intermediate node

TCP mods?

yes yes Yes no yes no

Handle Encrypted

Traffic?

no no No yes no yes

End-to-End TCP

semantics

yes no No yes no yes

Handle long

disconnections

no May run out

of buffers

yes no yes yes

Frequent

Disconnections

no Handoff

costly

Handoff

may be

costly

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.

-------------------- Fig 8 topology for simulation

FH G BS MH

Wired network Wireless network

5MB 1MB

100m 10ms

FH G BS MH

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.

MH

BS

FH

xlv

4.2 .2 Sender side Pseudocode

if PRN option is received and retransmission time is pending

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

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 sender’s 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.

MH

BS

FH

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 NS-

DEFAULT.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 ns-

default.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 NO YES

Packet successfully delivered to BS

Packet sent from FH

Packet Sent from BS

Any possible handoff predicted?

Packet successfully sent to MH

MH sends ZWA and Freeze Packet Transmission

FH receives ZWA and starts sending ZWP

Start Sending Packets

xlix

NO

Check if link is reconnected?

YES Fig 10. Freeze-TCP operations

MH sends TR-ACK

Sender Keeps send ZWP and Checks if reconnected

Sender starts transmitting data exponentially

End of transmission

l

4.5.2 Flow chart for PRN

Packet successfully delivered to BS

Packet sent from FH to BS

Any possible disconnection signal from MH

Packet successfully sent to MH

Special ACK sent to sender (BS)

Start Sending Packets

Receiver attached to new access point (BS)

ACK sent to Sender

li

Check if any packet got lost

Sender retransmits lost packets

Transmission continues

Sender restores cwnd and ssthresh values with values before handoff

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

Transmission continues

End of transmission

Fig 11. PRN-TCP operations

lii

4.5.3 Interaction Diagrams Scenario 1. t1

G BS MHF

H

t2 t3 t4 ack sent to FH t5 ack forwarded t6

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

Packet delivered

Forward packet to BS

Send packet to MH via G

t7 Fig. 12 - Normal PRN operation Scenario 2

t1

t2

t3

t4

t5

t6

Sender pends waiting for ack so it

can send the next packet

FH

G BS MH

ack sent but not delivered

Send packet to MH via G

Forward packet to BS

Packet delivered

t7

Fig 13. PRN operation when ack is not received

Scenario 3

liii

t1

t2

t3

t4

t5

Fig14-PRN response after timer expires

Send packet to MH via G

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

Sender pends waiting for ack so it

FH

G BS MH

ack sent but not delivered

Forward packet to BS

Packet delivered

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) random-motion 0 $node_(0) set X_ 125.0 $node_(0) set Y_ 125.0 $node_(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) New Reno TCP (b) Freeze TCP (c)

lx

Fig 17. Throughput of receiving packets

lxi

Reno TCP (a) New Reno TCP (b) Freeze TCP (c)

Fig 18. Throughput of forwarding packets

lxii

Reno TCP (a) New Reno TCP (b) Freeze TCP(c)

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 Fig 23. Throughput of dropping packets

lxvii

PRN TCP Freeze TCP PRN TCP

lxviii

5.4 PERFORMANCE ANALYSIS

Throughput of generating/sending packets Time (Reno) (NewReno) (Freeze) (PRN)

0 0 0 0 0 1 18 18 20 20 2 21 22.5 19 19.9 3 4 20 14.5 17 4 21.5 10 25 23 5 33 29 35 45 6 48 41.5 55 52.5 7 60 57.5 65 69.5 8 74 67 59.5 72 9 74.5 74 15 75 10 75 73.5 20 73

Table 2. Throughput of generating/sending packets

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) (PRN)

0 0 0 0 0 1 10 10 10 10 2 20 21 19.6 20 3 10 19 15 17 4 18 10.5 20 22 5 30.5 21.5 35 39 6 40.5 39.5 58 50 7 58 51 63 63 8 69 64.5 61 72 9 73.5 74 21 75 10 59 60 15 58.5

Table 3. Throughput of receiving packets

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 TCP’s 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 networks”-

Computer Communications 31, 2669–2675

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-to-

end 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