Upload
vanessa-harris
View
30
Download
0
Tags:
Embed Size (px)
DESCRIPTION
software requirement specification is described here for the software requirements information
Citation preview
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