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





Abstract. TCP is a reliable protocol, which performs well with networks that are physically linked, and the hosts are stationary. Networks with wireless links and mobile hosts are not compatible with the current TCP/IP specifications as they violate the existing assumptions made by TCP. This paper identifies the technical difficulties that conventional TCP faces in mobile and wireless environment and will provide a survey on the research that aimed at improving the performance of TCP for wireless and mobile networks, by making small but nontrivial changes to the existing version. There are various methods that make TCP an efficient protocol over wireless networks and will see them as the paper progresses.

[Keyword]: mobile, Maximum Transmission Unit (MTU).



Table of Contents:

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.

  1. A conventional TCP connection between Fixed Host and the Base Station
  2. A wireless connection between Base Station and Mobile Host.

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

  1. A new packet from the FH. The snoop function adds the packet to the BS cache and does conventional routing.
  2. An out of sequence packet that has already been cached. This means that there must be a timeout that occurred at the FH. The local retransmission scheme deals with the delivery of that packet and set the retransmission count to 0.
  3. An out of sequence packet that has not yet been cached. There are two possibilities that this could happen. The packet must have been delivered out of order by the network or it might have been lost due to congestion on the wired network. This packet is marked as having experienced congestion loss. This is useful for snoop_input( ) for dealing with TCP acknowledgements.

 

                                              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.

  1. A spurious acknowledgement, which is not in the ascending order of TCP. This type of acknowledgement is discarded because TCP always follows cumulative acknowledgements.
  2. A duplicate acknowledgement. This can be understood as the next packet not being received by MH. In this case any of the following three actions can be implemented.
    1. If the desired packed is not cached in the snoop then it is routed to the FH. This in turn invokes the congestion control algorithm and the packet is resent.
    2. If the BS is not expecting such a duplicate acknowledgement the packet is retransmitted to MH. This information can also be used to update the state and set the timer of retransmission to 0.
    3. If a duplicate acknowledgement is expected for that packet then the duplicate acknowledgement is discarded.
  3. A new acknowledgement. This signifies that the packet has reached the destination safely. This acknowledge can be used for calculating the RTT estimate and the state of the snoop_input( ) is updated by freeing the space of the acknowledged packet from its buffer.

 

                                              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.

  1. A transport layer connection is implemented as two separate connections-one for each medium, wired and wireless. The intermediate node for these two connections is the BS
  2. Whenever a handover occurs in the I-TCP the intermediate point is changed to the new BS.
  3. The FH is unaware of the two connections and is not affected even at the time of handovers (when switching cells or BSs).
  4. There are various benefits in using a level of indirection in establishing a connection. Flow control and congestion control mechanisms are dealt separately over the different communication medium, which is desired. Having indirection makes it easy to handle mobility faster. It provides some measures to ensure reliability over wireless links. Indirect protocol provides backward compatibility with the conventional networks, which obviates the accommodation of mobile hosts. The mobile host need not run TCP/IP to communicate with the wired networks that run on TCP. Any communication protocol, which communicates with the BS, is enough to establish a reliable connection with FH.

     

                                                  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.

    1. The main consideration must be that it should be inter-operable. It must be compatible to the existing infrastructure. That means approaches that spilt the connection into two are not very effective. SNOOP, I-TCP and MTCP needs major changes in the BS which doesn't make it inter-operable.
    2. Another major consideration is maintaining true end-to-end semantics. I-TCP and MTCP doesn't maintain end-to-end semantics. Snoop maintains end-to-end semantics but relies heavily on an intermediary node. This also ensures the encrypted traffic to be handled without making any special changes. iTCP Delayed Dupacks and Freeze-TCP can handle encrypted traffic because they maintain true end-to-end nature of TCP.
    3. Finally the complexity of the protocol is compared. The protocol has to be simple and it should not create a bottleneck. I-TCP, MTCP and Snoop are all computation costly. They require an intermediary node that may become a bottleneck because of the exhaustive storing and computation they need. iTCP and Freeze-TCP are simple and induce fewer overheads into the network.
    4. Interactivity is a rapidly evolving field that gives the application an intervention to control the network activity. This means that the application is aware of the network bandwidth and hence adapts itself accordingly. This kind of application and network integration would yield tremendously good results as suggested by iTCP. There is no much work done in this field as yet except for iTCP.
    5. 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.