A Survey on Next Generation TCP Derivatives for Mobile Environment
Sandeep Kumar Davu
Email: sdavo@cs.kent.edu
Prepared for Prof. Javed I. Khan
Department of Computer Science, Kent State University
Date: May 2003
[Keyword]: mobile, Maximum Transmission
Unit (MTU).
Introduction (top)
Evolution of TCP (top)
Transmission Control Protocol (TCP) is one of the important standards in the internet world. It provides a connection oriented service with reliable data transfer over the unreliable underlying protocols. It uses sequence numbering and timers to ensure reliable transfer of packets. TCP's flow control increases the data sending rate until there are signs of congestion in the network. To make TCP more reliable and robust various versions of TCP have been proposed. The use of congestion window avoids the packets to be lost due to network congestion. This congestion control mechanism developed in 86 by Jacobson and Karels was known as TCP Tahoe. This led to a series of versions of TCP which improved the performance enormously.
TCP Reno also called as additive increase and multiplicative decrease induces packets into the network to estimate the network bandwidth. If there is no packet loss TCP Reno increases the window size by one whenever it receives an acknowledgement of the previous packets. When there is a packet loss it reduces it window by half and then repeats the process until there is packet loss again. This version of TCP has a varying window size on each round trip. This leads to oscillating Round Trip Time (RTT).
Another version called TCP Vegas has a sophisticated estimation of bandwidth. It calculates the available bandwidth by finding out the difference between actual round trip time and expected round trip time. The difference between these two flow rates can be used to estimate the level of congestion in the network and the window size can be adjusted accordingly. All these versions treat packet loss as a cause of congestion in the network.
Drawbacks of the existing system (top)
With the advent of small and portable computers, mobile wireless computing will take over the traditional version in the world of networking. Wireless links are less reliable and slower than the wired links. Moreover communication over such networks shows different characteristics compared to the traditional wired networks. Packets on the internet may be lost due to congestion or due to corruption by the underlying physical medium. In wired networks all the loss of packets can be related to congestion. Unfortunately, the high error rates in mobile networks are also related to congestion in the network while they may also be caused due to the handoffs. These handoffs involve the transfer of communication state from one base station to another. This may be considered as normal congestion by TCP. There are three major impacts on TCP during the handoff scenario. The packets will experience a higher delay during handoff due to packet re-routing. Secondly the packets already in transit for the old access point are generally dropped during the handoffs. Lastly TCP has to deal with massive packet re-ordering after a handoff.
Proposed solutions (top)
The first section of the paper discusses a simple extension of the protocol to lessen this effect. The main advantage of this protocol is it does not require any changes to the implementation of TCP at end hosts and also doesn't require recompiling or relinking existing applications. The only modification required is at the network layer software of the base station. In the second section there are two more approaches that will improve the performance of TCP in wireless networks. They are packet size variation and explicit feedback. The performance of TCP can be substantially improved if the packet size selection is optimal. This optimal packet size is dependent on the error rate that occurred on that wireless link. This could improve the performance by over 30% without requiring any changes to be made at the transport or link layers of the TCP connection.
The explicit feedback mechanism eliminates the use of the timeouts at the source when there is local recovery, which is mentioned in the first section of the paper. Explicit feedback improves the local recovery scheme furthermore by eliminating timeouts at the time of local recovery.
The next section deals with a modified version of TCP called the Indirect TCP (I-TCP). The main purpose to deal with this protocol is to handle handoffs in mobile networks. When a mobile host is shifting from one base station to another it is called handover and there are many compatibility issues that are to be taken care off during this process. In this approach the end-to-end TCP connection between a fixed host and a mobile host is split into two separate connections.
The connection is split into two separate connections so as to provide compatibility of wireless networks with the existing fixed networks.
1. Local
Recovery Model (Snoop) (top)
The main aim of designing such a protocol is to use TCP as the default
protocol because it is ubiquitous and it is desirable that there is no
change in implementing TCP. The modification is done only at the
network layer of the base station, where one can expect to have full
control, rather than changing it elsewhere in the fixed network. The
modification essentially targets the router code of the base station
where the data meant for the mobile host is cached and introduces some
simple rules dealing with the acknowledgements and retransmissions. The
main aim is to shield the sender from the inconsistencies of the
wireless link and the mobility of the receiver and maintaining the
end-to-end semantics, modifying host TCP code, or relinking existing
applications. The protocol is described in the context of a single TCP
connection consisting of a fixed host (FH) connected to a mobile host
(MH) via a base station (BS).
The modification done to the base station is in the form of adding another layer, called "snoop layer", whose purpose is to monitor all the packets that passes through the connection in both directions. The snoop layer maintains a cache of TCP packets that are not yet acknowledged by MH Whenever the snoop layer receives a packet from FH that is destined for MH it first caches the packet and continues the routing normally. The snoop layer also keeps track of all the acknowledgements sent by the MH. This is because it need not have to cache the packets that are acknowledged. When there is a packet loss it is retransmitted by the BS. By having this snoop functions one has the advantage of hiding the packet loss through the wireless link. This prevents from unnecessary implementation of congestion control algorithms by FH. Snoop function consists of two functions, snoop_output( ) and snoop_input( ). The snoop_output( ) functions handles the processing and caching of packets at the BS and snoop_input( ) is used for processing about the acknowledgements which are sent by the MH.
Snoop_output() (top)
There are three possibilities that could happen
Figure1: State Machine for snoop_output( )[1]
Snoop_input() (top)
This is used for monitoring the acknowledgements sent by the MH. There
are three conditions that could be encountered while dealing with this
function.
Figure2: State Machine for snoop_input( )[1]
2. Effects of
packet size variation. (top)
The TCP has a concept of Maximum Transmission Unit (MTU), which it
decides while establishing a connection and remains constant for the
rest of the connection. This MTU for wireless networks is always kept
very small for most of the wireless links. These small MTU's will be
problematic because they have to be fragmented at the BS before sending
them to the MH. This is although advantageous as the end hosts need not
worry about the packet size and intermediate network configurations, it
has its own disadvantages because an error in a single fragment of the
packet results in all the subsequent fragments to be discarded. This
would result in the source to retransmit the discarded packet, which
would result in more fragmentation, and this would increase the
congestion in the network. While throughput mostly depends on the error
characteristics of the link, it also depends on the packet size. So
deciding an optimal packet size is the key to reduce congestion in the
network, which is done using the Path MTU discovery (PMTU). This would
give the packet size that is equal to the smallest MTU among all links
along the route for the connection. This would obviously be the MTU of
the wireless link or if nothing is specified then a default IP datagram
size of 576 bytes is assumed as the packet size. Based on this model if
a good packet size is selected it would significantly improve the
performance of TCP connection without having to maintain any state
information at the BS's per connection. This is very simple to
implement. Every BS will be maintaining a fixed table, which maps a
particular wireless link error characteristic to a good packet size for
that particular error characteristic.
3. Indirect
TCP (I-TCP) (top)
The basic idea of this model is to implement the existing TCP
connection as two different type connections as they are implemented on
two drastically different media- one for each kind of communication
medium. An indirect transport layer between a FH and the BS is
implemented by fixed network protocol and the communication between MH
and BS is handled by mobile network protocol. If there are different
presentation requirements over wired and wireless links then an indirect
presentation layer protocol can be incorporated. The reason to choose BS
for splitting the connection is that it is easy to incorporate any new
changes or protocols and anyhow the BS needs its routing software to be
modified for supporting mobile hosts. By splitting the protocol stack
at the BS, the corrective measures taken to address the change in the
environment, are employed at the place where the changes occur. Even
though the connection is divided into two separate connections this is
invisible to the FH. It thinks that it is communicating directly with
the MH - its peer. The BS fakes the FH that it is the MH. During
handover this faked image is handed over to the corresponding BS when a
MH is engaged in switching cells. The I-TCP is a reliable
stream-oriented transport player protocol for mobile hosts, which is
fully compatible with TCP/IP and is built around the simple concepts
listed below.
Figure 3. Indirect Transport Layer [3]
Establishing
a connection (top)
The MH requests the BS with which it is registered to establish a
connection with the FH. The BS then establishes a fixed TCP connection
with the FH on behalf of the MH. In doing so it uses the IP address and
the port number of the mobile host. This is the first part of the
connection in the I-TCP protocol. The second part of the connection is
established between the MH and the BS using any existing protocols (now
a days we use TCP for this part also). The BS uses its own IP address
and port number for establishing a connection with MH.
Handover in
I-TCP: (top)
Whenever MH requests a connection with the FH, first Base Station BS1
establishes a connection on behalf of the MH with the FH using the MH's
address and port number. It also establishes a wireless I-TCP connection
to communicate with the mobile host using its own IP address and port
number. Handover occurs when MH switches cells. When a MH starts to
switch cell the state associated with the two sockets I-TCP connection
is handed over to the next BS to which the MH will register. The new BS
(BS2) will create two sockets corresponding to the I-TCP connection
using the same end point parameters. There is no need to reestablish a
connection at the new BS because the endpoints of MH and FH are the
same. This also ensures that FH doesn't know about the indirection used
in the connection establishment. This concept is explained in the
diagram below.
Figure 4. Handoff in I-TCP [3]
4. Freeze TCP: (top)
Zero Window
Acknowledgement (ZWA) (top)
TCP uses a sliding window mechanism for transmitting packets reliably.
This sliding window protocol also provides congestion and flow control
apart from reliable packet transfer. The sender and receiver will agree
upon a window size on each size. The window size (W) is determined as
the minimum of receiver's advertised buffer space, and the perceived
network congestion. The sender allows up to W outstanding or
unacknowledged packets at a time. This results in a "usable window" size
equal to W minus the number of outstanding packets. The usable window
size reduces when there are more unacknowledged packets and increases as
the packets are acknowledged. If the receiver is slow to empty the
buffers there may be a situation that the usable window becomes zero.
Then the receiver 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. After freezing the sender keeps on
probing the receiver to see if it advertises a non-zero window. These
probes are called the Zero Window Probes or ZWPs. The interval between
successive probes grows exponentially (exponential back-off) until it
reaches 1 minute, where it remains constant. For each ZWP a receiver
advertises a zero window until its buffers are available again. This
advertisement is called Zero Window Acknowledgement (ZWA). Because
these probes are not delivered reliably, the sender does not drop its
congestion window if a Zero Window Probe itself gets lost.
Freezing
the TCP connection (top)
The main idea behind Freeze-TCP is to use the Zero Window
Acknowledgement (ZWA) when the mobile node detects an impending handoff.
A mobile node can certainly monitor signal strengths in the wireless
antennas and detect an impending handoff. 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. In the persist mode the
sender doesn't drop the congestion window even if packets that are
intended to the mobile hosts are lost. This achieves a tremendous
improvement over the standard TCP because the loss of packets are not
misinterpreted as congestion in the network. This implementation
requires only the client's TCP code to be changed. This is an end-to-end
protocol which doesn't involve any intermediary as the base station. If
the receiver can sense an impending disconnection, it should try to send
out a few (at least one) acknowledgements, wherein it's window size is
advertised as zero (let an ACK with a zero receiver window size be
abbreviated "ZWA", i.e., Zero Window Advertisement).
The period after a ZWA is sent and the receiver actually disconnects and reconnects is called warning period. Ideally, the warning period should be long enough to ensure that exactly one ZWA gets across to the sender. If the warning period is not chose correctly the sender gets affected. If the warning period is 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 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. Note that Freeze-TCP is only useful if a disconnection occurs while data is being transferred (as opposed to when the receiver is idle for some time and then gets disconnected).
There could also be a substantial delay before a ZWP is sent after a reconnection. This would leave the receiver idle for that amount of time even after reconnection. This can be avoided using a scheme called Thrice Acknowledgement (TR-ACK). As soon as the connection is re-established the receiver or the mobile host will send the acknowledgement thrice. When the sender looks at the triplicate acknowledgement it starts sends a WZP and gets a non-zero acknowledgement. From here on it starts sending data with the same window size that was used before handoff or temporary disconnection. So both the congestion and slow start algorithms can be avoided by using the Freeze-TCP protocol.
Figure 5. Increased throughput due to Freeze-TCP [4]
Comparison of
Different implementations of TCP (top)
The table below gives an extensive view of all the protocols and there
relative advantages and disadvantages.
SNOOP | ITCP & MTCP | Delayed Dupacks | EBSN | Freeze-TCP | iTCP | |
Requires intermediate node | Yes | Yes | No | Yes | No | No |
Handle encrypted traffic | No | No | Yes | No | Yes | Yes |
Handle long disconnections | No | May run out of buffers | No | Yes | Yes | Yes |
Frequent disconnections | No | Handoff costly | No | Yes | Yes | Yes |
Handle high BER | Yes | Yes | No | No | No | No |
End-to-End TCP semantics | Yes | No | Yes | No | Yes | Yes |
Interactivity | No | No | No | No | No | Yes |
Complexity | Yes | Yes | No | Yes | No | No |
Comparison of various mobile TCP
The original comparison was given in [4]. The table above is more extensive and has more comparison parameters than the original one. The comparison of various TCP's is based on major factors that should be considered in assessing any TCP enhancements.
Conclusion (top)
This paper presents simple protocol to improve the performance of TCP
on networks with wireless links and mobile hosts. Some of these
protocols work by modifying the network-layer software at the base
station and some of them only needs modification at ends of TCP
connection. Each proposed variant has its own relative advantage and
disadvantage over the other. In spite of all this extensive work done on
mobile and wireless networks, there appears to be no effective solution
that is robust and less complex. Complexity plays a major role for
building mobile compliant applications. Can TCP be made compatible to
handle mobile applications?
References (top)
[1] Elan Amir, Hari Balakrishnan, Srinivasan Seshan, Randy H. Katz, "Efficient TCP over Networks with Wireless Links."
[2] Bikram S. Bakshi P. Krishna N. Vaidya D. K. Pradhan "Improving Performance of TCP over Wireless Networks."
[3] Ajay V. Bakre and B.R. Badrinath, "Implementation and Performance Evaluation of Indirect TCP."
[4]Tom Goff, James Moronski and D. S. Phatak "Freeze-TCP: A true end-to-end TCP enhancement mechanism for mobile environments."
[5] Bikram S. Bakshi, P. Krishna, N.H. Vaidya, D.K. Pradhan, "Providing Seamless Communication over Mobile Wireless Networks."
[6] S. Biaz, M. Mehta, S. West and N. H. Vaidya, "TCP over Wireless Networks Using Multiple Acknowledgements."
[7] D.E. Comer and D.L. Stevens. Internetworking with TCP/IP Volume II. Prentice Hall.
[8] K. Keeton, B.A. Mah, S. Seshan, R.H.Katz, and D. Ferrari. "Providing Connection-oriented Service to Mobile Hosts."
[9] Bakre and B.R. Badrinath, "Handoff and System Support for Indirect TCP/IP."
[10] Bikram S. Bakshi, P. Krishna, N.H. Vaidya, D.K. Pradhan, "Performance of TCP over Wireless Networks," Tech Report.
[11] Postel, J. eds, RFC 793: Transmission Control Protocol.
[12] Raj Yavatkar and Namrata Bhagawat, "Improving end-to-end performance of tcp over mobile internetworks."
[13] Jeonghoon Mo, Richard J. La, Venkat Anantharam, and Jean Walrand, "Analysis and Comparison of TCP Reno and Vegas."
[14] V. Jacobson. Congestion avoidance and control.
[15] Yavatkar, R. and Bhagwat, N. "Improving End-to-End Performance of TCP over Mobile Internetworks."
[16] A. Bakre, "Design and Implementation of Indirect Protocols for Mobile Wireless Environments,"
[17] B.R. Badrinath, A. Bakre, T. Imeilinski, and R. Marantz, "Handling Mobile Clients: A Case for Indirect Interaction."
[18] Kevin Brown, Suresh Singh , " M-TCP: TCP for Mobile Cellular Networks ".
[19] Ashish Natani, Jagannadha Jakilinki, Mansoor Mohsin, Vijay Sharma, "TCP for Wireless Networks."
[20] Vaidya N. and Mehta M., "Delayed Duplicate Acknowledgements: A TCP-Unaware Approach to Improve Performance of TCP over Wireless Links."
Relevant
Links:(top)
RFC 793 : Transmission Control Protocol.
RFC 2581 TCP Congestion Control
RFC 2001 : TCP Slow Start, Congestion Avoidance, Fast Retransmit and Fast Recovery Algorithms.
RFC 2582 : The NewReno modification to TCP's Fast Recovery Algorithm.
RFC 2018 : TCP Selective Acknowledgement options.
Research
Groups: (top)
Mobile computing and networking group. www.crhc.uiuc.edu/~nhv/old_pubs.html
Scope of the
Paper (top)
The scope of this paper is to present an overview of the research going
on in the field of TCP for mobile environments. This paper doesn't
provide a complete study of any particular implementation. The survey
only gives a brief overview and compares and contrasts the existing TCP
variants. This paper aims at providing a good comprehensive comparison
of TCP variants for mobile and wireless environments, which is useful
for people who are interested to pursue research in this field.