Freeze TCP with Timestamps for Fast Packet Loss Recovery after Disconnections
Gustavo M.T. Da Costa
University of Canterbury*
gustavo.dacosta@alliedtelesyn.co.nz
Harsha R. Sirisena
University of Canterbury
h.sirisena@elec.canterbury.ac.nz
Keywords – End-to-end TCP enhancements, Wireless
Networks, RTT Estimate, Proactive Control
to-end IP connectivity, so that wireless networks become
part of the global Internet.
Abstract
However, TCP is based on some assumptions that are not
valid in wireless environments [1]. This leads to poor
performance of TCP in mixed wired-wireless environments.
Several modifications at the transport layer have been
proposed and studied in recent years to deal with the
problem of timeout backoff and congestion window
reduction during disconnections (due to handoffs, fading
etc) [2], [3], [4], [5] or to deal with the high corruption rate of
wireless channels [6], [7], [8].
TCP optimization for wireless networks, for dealing with
packet losses and disconnections due to fading, shadowing
and handoffs, ideally should maintain TCP end-to-end
semantics with minimal dependence on intermediate nodes.
This paper presents such a mechanism that uses
disconnection duration estimates at the receiver, derived
from timestamps, to avoid an increase in the retransmission
timeout (RTO) estimate at the sender following
disconnections. Simulation results are presented to illustrate
the problem, and to show that the proposed modification
significantly improves performance. Incorporating this into
the recently proposed Freeze -TCP scheme, which uses
disconnection predictions at the receiver, is shown to
increase robustness to packet losses during disconnections.
1. 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. Future wireless networks (e.g. a 4G
cellular system) are expected therefore to move towards end-
*
Currently at Allied Telesyn Research
As shown in [5], the TCP performance degradation is
particularly serious in non-overlapping cell environments due
to the temporary loss of the connection during a handoff,
which can lead to timeouts and even timer backoff. It is on
this type of environment that we focus our attention. Recent
developments to deal with the problem of timeouts at the
sender try to place the sender into persist mode by sending a
zero window advertisement (ZWA) when a disconnection is
detected [2], [3]. This causes the sender's timers to be frozen.
Furthermore, loss of the unacknowledged data will not
reduce the congestion window. Although RFC1122 [9]
strongly discourages shrinking the window to the right to
avoid the usable window becoming negative, for robustness
of the protocol, it mandates that TCP implementations must
nevertheless be able to deal with this situation.
Freeze-TCP, a method to place the sender in persist mode
prior to a disconnection through signal strength
measurements, was proposed in [4]. In this method, the
mobile monitors the signal strength and sends zero window
advertisements if it detects an impending disconnection. The
where three copies of the ACK of the last segment received
prior to the disconnection are sent by the receiver, with a
non-ZWA, upon reconnection detection. The Freeze -TCP
method has the advantage that it does not require
involvement by intermediate nodes and hence can be used if
the IP payload is encrypted [4], and is therefore a promising
approach, e.g. in Virtual Private Networks (VPNs). Significant
performance improvements have been shown [10] in
simulations using signal strength measurements at the mobile
to put the sender in persist mode as compared to unmodified
TCP.
Nevertheless, ensuring that the zero window advertisements
are sent soon enough to avoid loss of data in transit while
also avoiding freezing the sender excessively soon is difficult
in practice. Hence, although Freeze-TCP can be very effective
in avoiding performance problems due to disconnection, it
may be unable to eliminate losses in some scenarios.
In this paper, we look at a scenario where the loss of data
during a handoff (e.g due to the late freezing of the sender)
can lead to performance degradation of the sender freezing
mechanism when compared to unmodified TCP. This
degradation is due to the inflation of the RTO following a
reconnection where losses have occurred. A modification to
the receiver to allow faster recovery of the data lost by
avoiding unnecessary RTO inflation using the timestamp
option [11] is proposed.
The RTO inflation problem was observed though simulations
and analysis of sender trace files, as will be shown in Figures
2-4 in Section 5.
The paper is organized as follows. In Section 2 a brief
overview of the TCP retransmission timeout calculation
mechanisms is presented. The problem of inflated RTO
following a reconnection is discussed in Section 3. This
motivates the modification to the Freeze-TCP action at the
receiver suggested in Section 4. Our implementation of the
Freeze-TCP scheme, as well as the implementation of our
proposed modification and simulation results are then
presented in Section 5. The conclusions drawn and ideas for
future work are given in Section 6.
2. TCP RETRANSMISSION TIMEOUT
CALCULATION OVERVIEW
authors of the Freeze-TCP scheme also use the method in [5]
TCP calculates the retransmission timeout (RTO) based on
sample measurements of the round trip time (RTT)
experienced by the connection. Instead of measuring the
RTT of every data segment, TCP implementations measure
only one RTT per connection in a window of data unless the
timestamp option [11] is used. If the timestamp option is not
used, a new packet to be transmitted is timed only if there is
no packet being timed [12]. In this case, the time when the
packet is sent is recorded and the RTT sample is calculated
when an ACK for new data with sequence number greater
than or equal to the timed segment is received. The RTT
sample is then
RTTs = Current time – time when timed segment was sent
Karn’s algorithm determines that the RTT estimator cannot
be updated when an ACK for a retransmitted segment is
received. This is due to the retransmission ambiguity
problem, which makes it impossible to know whether the
ACK was for the original or retransmitted segment [12]. The
reception of an ACK for a retransmitted segment also causes
the last exponential backoff to be used in the RTO for the
next segment transmission. Therefore, a RTT sample is only
used to update the RTO if the received ACK acknowledges
new data.
If a RTT sample can be collected to update the RTO due to
new data being acknowledged by this ACK, and the
timestamp option is used, the RTT sample is
RTTs = Current time – time when this segment was sent
A problem with the Timestamp Option is that it increases the
overhead in every packet. This is a particularly serious
concern over wireless links where bandwidth is scarce. [13]
suggested adding timestamp compression to the existing
TCP/IP header compression schemes or only timing and
replying required packets. These, however, require
modifications at the end-hosts in the fixed network and hence
would have deployment concerns.
3. PROBLEM OF INFLATED RTO
ESTIMATE AFTER RECONNECTION
Although freezing the TCP sender to avoid timeouts and
packet losses can provide significant performance
improvements [2], the choice of when to send a zero window
advertisement to freeze the sender is difficult. In timer based
methods, such as M-TCP, the intermediate node uses a timer
granularity that must be smaller than the sender timer
granularity, so that it can timeout before the sender and
hence deduce a disconnection in time to send a zero window
advertisement that reaches the sender before it times out.
The choice of when to send a zero window advertisement is
even more critical in Freeze-TCP since it does not have the
support of an intermediate node which can start buffering
when a disconnection is predicted. Hence it is more
susceptible to loss of in -flight segments.
We have modified the ns-2 network simulator [14] to
implement the signal strength based disconnection
prediction scheme of Freeze -TCP and study the effects of
different power thresholds on the TCP goodput performance
achieved. During the studies of the performance and
behavior of TCP with different warning threshold powers, it
was observed that if the sender does not have enough time
to stop the transmitter in time to avoid packet losses, a
slightly worse performance could at times be observed when
such losses occurred, compared to the unmodified SACK
implementation when adjacent cells were used. Analyses of
sender trace files suggest that Freeze -TCP tends to recover
from these handoff losses through a fast retransmit followed
by a timeout since multiple packets are lost in a window of
data.
In Freeze-TCP, if the first acknowledgements sent to warn
the sender of the reconnection acknowledge new data at the
sender, the RTO is updated. This situation may occur if the
last ACKs sent before the discon nection are lost. This can be
caused by packet corruption or it can happen if the MH
leaves its current cell after receiving data but it still attempts
to send the ACKs to the old cell since the handoff to the new
cell is not yet completed. Such ACKs are therefore lost. In
this paper we focus on the latter case.
The RTO is inflated due to the inclusion of the disconnected
time in the RTT sample used in the new RTO calculation.
Since data was lost and needs to be retransmitted, the ACKs
for the new data sent after reconnection will generate
DUPACKs and the TCP sender will need to recover from the
multiple losses in the window of data through a timeout. This
situation is shown in Figure 3 of Section 5.
The inflation of the timeout value described previously may
lead to the sender waiting a long period of time for this
timeout to occur so that normal transmission can restart.
Furthermore, since the disconnection is already over, there is
no need to include this time in the current RTO estimate and
we would like to have a more accurate estimate of the
connection RTT for recovery purposes.
4. PROPOSED MODIFICATION
This section describes an improvement proposed we made
to the Freeze-TCP proposed in [4] that attempts to avoid the
RTO inflation problem after a reconnection is determined,
without requiring modifications to the fixed sender. This
modification is useful in cases where the Timestamp Option
is being used and does not affect the connection if this
option is not in use. An improvement to the scheme is also
suggested to avoid the need to use timestamps and may be
implemented in the future.
The receiver is assumed to use the timestamp echo bug fix
described in [15] when deciding on the timestamp value to be
echoed
to
the
sender.
A
new
variable
(time_last_ZWA_sent_) is introduced at the receiver. It
records the time the last zero window advertisement was
sent. It is started with value zero and every time the receiver
sends a ZWA in response to a predicted disconnection, the
current time is recorded in this variable.
In this way, when the mobile host (MH) determines that the
disconnection is over and sends copies of the last ACK with
an advertised window larger than zero to restart the sender
(as in Freeze-TCP), the timestamp echoed to the sender is
modified as:
ts_to_echo_ = ts_of_last_packet_ +
(current_time_ - time_last_ZWA_sent_)
In this way, the RTT calculation will not include the time the
MH was disconnected due to the handoff since
(current_time_ - time_last_ZWA_sent_) is an estimate of the
disconnection duration and the time stamp echoed is inflated
by this time. Therefore, the sender (if using the time stamp
option) will have a better estimate of the proper timeout value
after the disconnection.
Since the disconnection is already over, this time should not
be included in the RTO estimation since it does not
correspond to the current state of the link. Note also that the
receiver and sender clocks do not need to be synchronized
since the time added to the sender timestamp is the difference
of two times measured at the receiver.
We only consider the case where all packets are timed by the
sender and the echo sent back by the receiver as we wish to
avoid the need to change the fixed host. However, the sender
could be modified so that, even if the timestamp option is not
used, it recognizes and uses the timestamp echo instead of
the time when the timed segment was sent when a timestamp
echo is received and the RTT sample must be updated. In
this case, the ech o sent by the receiver would contain only
the disconnection duration estimate given by the time when
the reconnection was detected minus the time the last zero
window advertisement was sent.
environment is beyond the scope of this paper and requires
the implementation of the scheme in a real testbed. This is left
for future work.
Our updated timestamp can therefore be sent when a
reconnectio n is detected and the sender benefits from it
without the need to use the timestamp option. This would be
a reasonable approach for implementation in new fixed hosts.
Old fixed hosts would have to use the timestamp option in
order to use the timestamp update mechanism.
S(0)
5. PERFORMANCE ANALYSIS
S(1)
An implementation of Freeze-TCP as well as the
modifications described in Section 4 were added to the ns2.1b7 network simulator [14].
S(2)
This simulator version has a Mobile IP implementation as
well as support for wire less simulation. This includes an
implementation of the IEEE 802.11 MAC protocol. A number
of TCP variants are also available in this simulator. The
changes were added on top of the existing TCP-SACK
implementation (called Sack1) of ns-2.1b7.
Since the base distribution only contains ad-hoc routing
protocols, the NOAH (non-ad-hoc) routing model [16] was
added to our simulator installation. This routing model only
allows communication to/from wireless nodes through a base
station. This allows simulation of a cellular-based
environment without unwanted effects from ad-hoc routing
protocols.
Simulation Methodology and Scenario
We consider the case where a fixed host sends data to a
mobile host, which is a common case for bulk data transfer.
FTP is used to transfer data to the MH. This means that the
sender does not have direct knowledge of the receiver
mobility or wireless link conditions. The environment of
interest is a cellular network where the mobile periodically
moves into a new cell, requiring a handoff. Packets are
received correctly as long as the MH is within the BS
communication range.
This scenario allows a precise control of events and focus
on the problem being studied. This will allow an evaluation of
the extent of the problem and the benefits of our
modification. A quantification of the performance in a real
1.5Mbps
0.5ms
10Mbps
2.0ms
MH2
Gateway
FA
FA2
1.5Mbps
100ms
MH1
10Mbps
2.0ms
FA1
S(3)
2Mbps
Negligible
Propagation
Delay
Figure 1: Network topology for simulations.
We consider a large delay between the sender and receiver
in order to investigate the effects on the TCP end-to-end
recovery mechanism. In the environment studied, the cells do
not overlap. This highlights the problems suffered by TCP
when a handoff occurs and connection with the fixed
network is temporarily lost. The communication to and from
the mobile is considered to go through a base station; no ad hoc communication between mobiles is possible.
Since a real network will have background traffic, rather than
just the connection of interest, bursty background traffic was
added. This background traffic is not an attempt to model real
background traffic that would be encountered in practice as
the traffic in the Internet is highly variable and difficult to
model. Instead, a background traffic that simply provides
some burstiness is used. The level of background traffic is
chosen to avoid congestion losses when we would like to
avoid such losses to be able to isolate performance problems
caused by other factors, such as handoffs.
Figure 1 shows the network topology used including the link
speeds and link delays. S(0-3) contain Pareto background
sources while S(0) also contain a TCP source. Two
background sources send UDP data to the stationary MH
(MH2) while the other two background sources send data to
the moving MH (MH1). The TCP connection is between S(0)
and MH1.
Although we consider a pedestrian mobility scenario,
handoffs are performed each 5.0 seconds and simulations are
run for 100 seconds. This small cell latency provides a
number of disconnection events in a simulation run. The use
of a 5 second cell latency was motivated by the desire to
study the effe ct of disconnection in general in a controlled
manner. A disconnection can happen not only due to a
handoff but also due to temporary fading.
We therefore consider the case of temporary disconnection
where the MH has enough time to detect the incoming
disconnection but in -flight packets are still lost due to the
warning not being sent soon enough. This can be done
through the use of a proper warning power threshold to
provide the desired effect, given the link delays used. The
mobile moves with speed 1.5 m/s. and the TCP packet size is
1000 bytes while acknowledgement packet size is 40 bytes.
The sender uses the timestamp option in all simulations.
Modifications Made to the ns -2 Simulator
Besides the inclusion of the NOAH routing agent into the
ns-2 simulator used, several modifications were also
performed. The main additions were the capability to set the
advertised window to zero, based on the received signal
power, and the ability to freeze the sender retransmit timer if a
zero window advertisement is received by the sender. Zero
window probes with exponential backoffs [9] were also
added.
In our implementation, the receiver sends zero window
advertisements based on the received signal strength and
comparison to a fixed threshold value that is pre-determined.
This value can be changed in different simulations to test
how sensitive the scheme is to the threshold used.
Freeze-TCP proposed in this paper were also implemented in
the ns-2 version used.
Results and Discussions
Now that the problem of increased timeout and delayed
recovery following multiple packet losses after window
unfreezing was presented and studied, the proposed
modification is tested in our simulated environment. The main
purpose of these tests is to provide a better idea of the
extents of performance gains achieved and how the modified
scheme compares to the base TCP (TCP-SACK) and FreezeTCP in the environment of our study.
First, sender traces of Freeze-TCP with and without the
proposed modification are presented to illustrate the problem
of delayed recovery following reconnection when packets are
lost and the RTO is inflated. A comparison with TCP-SACK
is also shown. Simulation results comparing the performance
of the three implementations in the scenario described
previously are then presented to illustrate the potential for
improvement when multiple occurrences of packet losses
happen during the data transfer and the sender is unfrozen
by new ACKs.
Illustration of sender behaviors following a
reconnection
In order to show the performance penalty after the sender is
unfrozen but packets were lost during the disconnection
period, traces of TCP-SACK, Freeze-TCP and of Freeze-TCP
with the proposed modification are shown next. These traces
show the inactive time at the sender due to the mobile
moving out of the coverage area of FA1 in Figure 1 and into
the coverage area of FA2 at time 55 seconds.
First we show the recovery of the unmodified TCP-SACK
following a handoff 55 seconds into the simulation. Figure 2
shows that for TCP SACK, two timeouts occurred due to the
handoff and the fact that the sender timer was not frozen.
The exponential backoff causes unnecessary inactive time at
the sender. From this figure it can be seen that one second
elapsed between the first and the second timeout
Sender Trace - SACK1
1890
The ability to send three copies of the ACK for the last
received packet upon handoff completion [4], [5] was also
added. The handoff completion is indicated by the reception
of a registration reply from the new FA/BS.
Departure From FH
Ack. Received by FH
1880
The modifications mentioned above refer to the
implementation of Freeze-TCP. Besides them, the changes to
Packet Seq. Number
1870
1860
1850
1840
1830
1820
55
55.5
56
56.5
57
Time (s)
57.5
58
58.5
59
the sender needs to wait for, since there were multiple losses
in the window of data and hence it cannot recover through
the fast retransmission.
Note that approximately 1.6 seconds were required for the
timeout to occur after the fast retransmit took place, even
though there was no exponential timer backoff due to
multiple timeouts. We would prefer to restart normal
transmission as soon as possible after the fast retransmission
since the link now is capable of receiving data. TCP-SACK
(Figure 2) on the other hand had two timeouts and a RTO of
1.0 second after the timer backoff following the first timeout.
This shows that Freeze-TCP had to wait for a significant
unnecessary idle time for the timeout. Figure 4 illustrates a
trace of the sender in the same configuration of Figure 3 but
now including the timestamp update procedure.
Figure 2: Sender trace zoom showing recovery time for Sack1
after a handoff.
The situation where packets are lost due to late sender
freezing and the time taken to restart the sender following the
handoff is illustrated in Figure 3. In this case, a warning
power threshold 0.5% above the minimum receive power
threshold was used. This caused the ZWAs to be sent
too late to avoid the loss of in-flight data.
Sender Trace - Freeze-TCP (0.5%) + ts-echo fix
1780
Departure From FH
Ack. Received by FH
1890
1755
Packet Seq. Number
1775
1750
1860
1770
Packet Seq. Number
Departure From FH
Ack. Received by FH
1900
Sender Trace - Freeze-TCP (0.5%)
1880
1765
1760
1870
TR-ACK
1745
1850
1740
TR-ACK
1735
55
55.5
56
56.5
Time (s)
57
57.5
58
58.5
1730
55
55.5
56
56.5
57
Time (s)
57.5
58
58.5
Figure 3: Zoom of sender trace showing late window
freezing problem.
The figure shows that the TR-ACK sent by the receiver
unfreezes the sender, which sends a burst of new packets.
However, due to the loss of data due to the late freezing of
the sender, DUPACKs are returned for these packets and a
fast retransmission takes place. Since the first ACK in the
TR-ACK acknowledge new data, the RTO is updated.
However, since the ACK is for a packet sent before the
disconnection, the RTO will be unnecessarily increased.
This is the reason for the large delay for the time out, which
59
Figure 4: Sender trace zoom showing recovery from losses
due to late window freezing, using timestamp updates
In the trace of Figure 4, the timeout that restart successful
communication occurs less than a second after the fast
retransmission even though the first ACK in the TR-ACK
received after the handoff also acknowledges new data.
The traces of Freeze-TCP with losses requiring a timeout
(Figure 3and Figure 4) also show that most new packets sent
by the sender after reception of the reconnection warning
ACKs (TR-ACK) and before the fast retransmission are still
retransmitted, even though they arrived at the receiver. This
59
is due to the TCP go-back-N and slow start policy following a
timeout.
Receiver Throughput Performance Simulations
Figure 5 shows a comparison of the mean throughput
obtained for TCP-SACK, Freeze -TCP and the modified
Freeze-TCP in the scenario studied, for adjacent cells and for
one-second cell separation [5] for a number of simulation
runs.
It was found that no losses occurred for a TCP-SACK
connection with no movements and with the background
traffic used. Therefore, all losses are due to the handoffs and
the experiment is performed in a controlled way.
Throughput For Warning Threshold = 0.5%
Above Minimum Receive Threshold
Throughput (Kbps)
350
300
250
200
0s Cell Gap
150
1s Cell Gap
100
Figure 5 shows that for the adjacent cells, Freeze-TCP
implementation performed on average 6.2% worse than the
base TCP (Sack1). The modified Freeze -TCP, on the other
hand, performed on average 4% better than the Sack1
implementation and on average 11% better than the
unmodified Freeze -TCP.
When the disconnection period is increased, the unmodified
Freeze-TCP still performs better than Sack1 due to the higher
penalty suffered by Sack1 due to timer backoffs during the
longer handoffs. This could be seen by the fact that in the 1 s
cell gap there were approximately twice as many timeouts
than in the adjacent cells case for Sack1. On the other hand,
the number of timeouts was practically unchanged for the
unmodified and modified Freeze-TCP tests in the adjacent
and 1 second cell gap cases (on average nine timeouts during
the simulation). The performance improvement of the
modified over unmodified Freeze-TCP is 19% when a one
second cell gap was used. This is larger than the
improvement observed for the previous adjacent cells
scenario (11%). The greater improvement can be explained by
the fact that in this latter scenario a larger disconnection time
exists and hence the new ACKs received by the sender after
a handoff will further increase the RTO. This will lead to
worse performance when the sender needs to recover from
the multiple losses due to the handoff with a timeout.
6. CONCLUSION AND FUTURE WORK
50
0
TCP-SACK
The problem of an inflated RTO estimate following a
reconnection when TCP persist mode is activated by zero
window advertisements was highlighted and a modification
to Freeze -TCP to overcome it was proposed.
Freeze-TCP Freeze+ TS
Update
Figure 5: Throughput comparison of Sack1 and Freeze -TCP
with and without timestamp update: handoff losses.
Table 1: 95% Confidence intervals of schemes performance
in adjacent cells with handoff losses scenario.
Scheme
Sack1
Freeze-TCP
Freeze+TS Echo
Update
Throughput (Kbps)
Min.
291
273
Mean
299
281
Max.
307
288
310
311
313
This modification can make Freeze -TCP more robust to
packet losses, thereby avoiding the need for intermediate
node intervention so that the TCP end-to-end semantics can
be maintained. It requires only the use of the existing
Timestamp Option and no other modification is introduced at
the sender. If the Timestamp Option is not used by the
sender, there is no incompatibility and the resultin g
performance is that of unmodified Freeze -TCP. As with
Freeze-TCP, the success of this modification is dependent on
the ability of the lower layers to detect an incoming
disconnection and notify this in a timely manner to the TCP
layer.
Although more work is required to better characterize the
benefits offered by this modification, especially using real
network measurements, our results show that this
modification can aid in the avoidance of unwanted RTO
inflation following receiver reconnection. As wit h other
schemes, the performance enhancement achieved is highly
dependent on the environment studied. We intend in the
future to make a performance evaluation of this scheme in
different scenarios to get a better picture of the magnitude of
the improvement yielded.
REFERENCES
[1] Xylomenos, G.; Polyzos, G. C.; Mahonen, P., and
Saaranen, M., 2001. “TCP Performance Issues Over Wireless
Links”, IEEE Communications Magazine, Vol. 39, Issue 4,
April: 52-58.
[2] Brown, K., and Singh, S., 1997. “M -TCP: TCP for Mobile
Cellular
Networks”,
ACM
SIGCOMM
Computer
Communication Review (CCR), Vol. 27, Issue 5, October: 1943.
[3] Elaoud, M. and Ramanathan, P., 2000. “TCP-SMART: a
technique for improving TCP performance in a spotty wide
band environment”, 2000 IEEE International Conference on
Communications (ICC 2000), Vol. 3: 1783 -1787
[4] Goff, T.; Moronski, J. and Phatak, D. S., 2000. “FreezeTCP: A True End-to-End TCP Enhancement Mechanism for
Mobile Environments”, In Proceedings of the IEEE
INFOCOM’ 2000, Vol. 3: 1537-1545.
[5] Càceres, R., and Iftode, L., 1995. “Improving the
Performance of Reliable Transport Protocols in Mobile
Computing Environments”, IEEE JSAC Vol. 13, No. 5, June:
850-857.
[6] Balakrishnan, H.; Seshan, S. and Katz, R. H., 1995.
“Improving Re liable Transport and Handoff Performance in
Cellular Wireless Networks”, ACM/Baltzer Wireless
Networks Journal, Vol. 1, No. 4, December: 469-481.
[7] Vaidya, N.; Metha, M.; Perkins, C. and Montenegro, G.,
1999. “Delayed Duplicate Acknowledgements: A TCP
Unaware Approach to Improve Performance of TCP over
Wireless”, Technical Report 99-003, Computer Science
Department, Texas A&M University, February.
[8] Bakre, A. and Badrinath, B. R., 1995. “I-TCP: Indirect TCP
for Mobile Hosts”, In Proceedings of the 15th International
Conference on Distributed Computing Systems, Vancouver,
Canada, June: 136-143.
[9] Braden, R., 1989. “Requirements for Internet Hosts –
Communication Layers”, Request for Comments RFC1122,
Internet engineering Task Force, October.
[10] Onoe, Y.; Atsumi, Y.; Sato, F. and Mizuno, T., 2000. “An
Efficient TCP/IP Hand-over Control Scheme for Next Generation Mobile Communication Networks”, Internet
Conference 2000 (IC2000)
[11] Jacobson, V.; Braden, R. and Borman, D., 1992. “TCP
Extensions for High Performance”, Request for Comments
RFC1323, Internet engineering Task Force, October, May.
[12] Stevens, W.R. 1994. TCP/IP Illustrated, Volume 1(The
Protocols), Addison-Wesley, Reading, Mass.
[13] Ludwig, R. and Katz, R. H., 2000. “The Eifel Algorithm:
Making TCP Robust Against Spurious Retransmissions”,
ACM Computer Communication Review, Vol. 30, No.1,
January: 30-36.
[14]
The
Network
Simulator
ns-2,
http://www.isi.edu/nsnam/ns/index.html
[15] Stevens, W.R. and Wright, G.R. 1994. TCP/IP Illustrated,
Volume 2 (The implementation) , Addison-Wesley, Reading,
Mass.
[16] Widmer, J., 2001. “Extensions to the ns Network
Simulator”, http://www.icsi.berkeley.edu/~widmer/mnav/nsextension/