TCP for Wireless Networks

Transcription

1 TCP for Wireless Networks Arathi Shamakumar,Ravi Kiran Kundeti,Srinivasan Krishnamurthy, and Srinivasa Rao Segu {arathi, kundeti, ksrini, Department of Computer Science University of Texas at Dallas November 2001 Abstract: TCP is a reliable end-to-end transport protocol tuned to perform well in traditional wired networks where the packet losses are primarily due to congestion. However, networks with wireless links show a marked increase in losses because of higher bit error rates (BER) and handoffs. If TCP is applied to such networks without any modification, it interprets these transmission losses as congestion losses and invokes congestion control mechanisms that unnecessarily decrease the network throughput. In this paper, we have discussed various approaches for improved TCP performance over networks with wireless links. 1. INTRODUCTION Mobile computing has seen explosive growth in recent years. In an era where mobility is the catchword, users need to be able to access electronic data and services anywhere, anytime using portable and affordable computing devices. If recent activity in mobile computing and wireless networks is any indication, mobile computers and their wireless communication links will be an integral part of future internetworks. Unfortunately, low bandwidths, high bit-error rates (BER), and frequent disconnections characterize these wireless links. These characteristics are highly divergent from those observed on wired networks. The problem is further compounded by packet losses and long delays in communication introduced into wireless networks due to the mobility of users and the resultant need for hand-offs. Hence, it is essential that protocols that cater to the specific characteristics of wireless communication be developed. There are two approaches to solving the problem-either develop a protocol from scratch that takes care of the above issues or modify existing protocols so that they provide a scalable solution to the problem. Existing Transport Protocols like TCP [1, 2, 3] are well tuned to the traditional networks made up of wired links and fixed hosts. TCP provides reliable end-to-end delivery of packets between hosts in packet-switched computer communication networks [1]. It provides reliability by maintaining a running average of estimated round trip delay and mean deviation, and re-transmitting packets that are either not delivered within a certain timeout interval - computed as the sum of smoothed round trip delay and four times the mean deviation - or upon arrival of duplicate acknowledgements [1, 2]. Because of the relatively low error rates (of the order of for optical networks) on wired network, TCP correctly attributes these losses to congestion in the network. TCP reacts to packet losses by dropping the transmission (congestion) window at the sender and initiating congestion control mechanisms like slow start that reduce the load on the network [1, 2]. In a network comprising wireless links characterized by high bit-error rates, intermittent connectivity and handoff related losses, TCP reacts to packet losses by dropping its window size, and initiating congestion control or avoidance mechanisms. This is because it has no means of distinguishing between transmission related losses and losses due to congestion. Such a TCP reaction results in an avoidable reduction in the link bandwidth utilization and consequently, a significant degradation in performance in the form of poor throughput and high interactive delays [23]. Various schemes have been proposed to improve the performance of TCP over wireless links. In this paper, we have discussed approaches that address the issue of extending TCP to wireless links. Section 2 gives a brief overview of TCP and its mechanisms to familiarize the readers of the issues being dealt with by the proposed extensions to TCP. Readers familiar with concepts of TCP may skip this ` 1

2 section without any loss of continuity. In Section 3, we have presented an overview of the splitconnection [6, 7, 8, 9, 11] approaches to solving the problem and have discussed their merits and drawbacks. Sections 4 and 5 talk about the TCP-aware [12, 13, 14, 15] and TCP-unaware [16] approaches respectively. Section 6 summarizes various Explicit Notification mechanisms [18, 5, 19]. In Sections 7 and 8, we discuss generic approaches that distinguish between congestion losses and transmission losses by using two connections [20] and receiver-based heuristics [21] respectively. Section 9 handles a link-layer mechanism [22] to improving TCP performance. We then move on to schemes that exclusively deal with mobility and hand-off related losses in Section 10 [10, 23, 24, 25, 26, 27]. Section 11 discusses Mobile Ad Hoc Networks [28, 29, 30], their unique characteristics and approaches that have been developed to address wireless related losses in these networks. We conclude our paper with a brief summary and comparison of the different schemes in Section A BRIEF DISCUSSION ON TCP Transport Control Protocol (TCP) [1] is a transport protocol that guarantees reliable ordered delivery of data packets over wired networks. It achieves reliability by means of retransmissions if necessary. It is an end-to-end protocol in the sense that acknowledgements for data are sent only after data has reached the receiver. The receipt of an acknowledgement confirms to the sender, delivery of corresponding data packet at the receiver. TCP employs cumulative acknowledgements that acknowledge receipt of all packets that were sent before the present data packet. A sequence number uniquely identifies each data packet. TCP maintains two windows viz., Congestion window and Transmission window for each connection, at all times. Transmission window s lower edge indicates the highest numbered segment acknowledged by the destination. Congestion window indicates the maximum number of segments that the source can transmit without receiving any acknowledgements from the receiver. TCP uses a sliding window protocol to implement flow control. The window size is determined as the minimum of the receiver s advertised window (available buffer size at the receiver) and congestion window (determined by the sender on the basis of feedback from the network). TCP uses duplicate acknowledgements (dupacks) to detect data packet losses. A dupack is generated whenever an out-of-order segment (identified on the basis of sequence numbers) arrives at the receiver. An out-of-order delivery usually implies a packet loss. TCP may also use a retransmission timeout (RTO) value-dynamically computed based on estimated round-trip time (RTT) and its mean deviation- to detect a packet loss. Large variations in RTT increase the deviation leading to larger RTO. As a result, sender may take too long to timeout. To initiate early retransmission, TCP uses what is known as fast retransmission mechanism. If the sender receives three dupacks consecutively, it assumes packet loss and undertakes retransmission. There are basically two approaches to congestion avoidance and control in TCP. In the slow start mechanism, the initial window size (cwnd) is set to 1 MSS (maximum segment size) and is incremented by 1 MSS on each new acknowledgement. After cwnd reaches a preset threshold value (ssthresh), it is increased linearly. On timeout, congestion window is reduced to 1 MSS and slow start mechanism is started. In the alternate approach, fast retransmit is followed by fast recovery wherein the cwnd is reduced to half the present window size and is increased linearly from then on. This avoids loss in throughput due to dramatic reduction of window size in the case of slow start. Later modifications to TCP [3] have suggested the use of Selective Acknowledgements (SACK) to further improve error recovery. Here, apart from informing the sender of packet loss, SACK in the form of a bitmap specifies the identity of the exact packets lost. This helps in recovery of multiple packet losses per RTT. 3. SPLIT-CONNECTION APPROACHES The fundamental idea behind split-connection approaches is as follows: Whenever an interaction between two hosts on a network involves communication over radically different media, we split such an ` 2

3 interaction into two distinct interactions-one for each kind of communication medium [7]. Split- Connection approaches split each TCP connection between fixed sender and mobile destination into two connections at the base station that connects the mobile host to the network. The first connection is between the wired source and the base station while the second is the connection between the base station and the wireless destination. The two connections may both use TCP or specialized protocols suitable for wireless networks may be used over the wireless links. Even if TCP is used over both connections, flow/error control mechanisms, packet sizes and timeouts may be different for each connection. Consequently, there are various flavors of split-connection approach to extending TCP to wireless networks and they are discussed in the following sections I-TCP/Indirect-TCP This is the classical split-connection approach proposed by Bakre et al [6]. In this approach, standard TCP is used over the wireless link too. The idea is to shield the TCP sender from the wireless link by separating loss recovery in the wireless link from that across wireline network. The base station that connects the wireless host to the network is referred to as the Mobile Support Router (MSR). A transport layer connection between a Wireless Host (WH) and Fixed Host (FH) is established as two separate connections - one between wireless medium and another over fixed network with the current MSR acting as the intermediate point. If the WH moves to another cell during the lifetime of the TCP connection, the old MSR will handover the responsibility of maintaining connectivity of the MH with the network to the new MSR responsible for that cell. The FH is completely oblivious to this indirection and is unaware of any switching that might take place among the MSRs. [7] discusses the I-TCP components, connection set-up and the signaling mechanisms used for hand-off etc. Figure-1 shows the connection set-up process and hand-off process for an I-TCP connection. WH Move WH Wireless TCP MSR-1 I-TCP handoff Standard TCP MSR-2 <mhaddr, mhport, msr1addr, msr1port> <mhaddr, mhport, msr2addr, msr2port> <msr1addr, msr1port, mhaddr, mhport> FH <msr2addr, msr2port, mhaddr, mhport> <mhaddr, mhport, fhaddr, fhport> Fig.1 <mhaddr, mhport, fhaddr, fhport> ` 3

4 When the wireless host (WH) wishes to establish a connection with a fixed host (FH), it sends a request to its Mobile Station Router (MSR-1). MSR-1 establishes a TCP connection with FH while communicating with the WH on a separate connection. If the WH moves to a different cell with a base station MSR-2, the state information is transferred from MSR-1 to MSR-2. The end-points remain fixed and hence the redirection is transparent to the fixed host Selective Repeat Protocol TCP by nature is not well tuned for lossy links, the TCP sender at the base station can time-out often and as a result, stalling the original fixed sender. So, Yavatkar et al [8] have proposed and compared the use of an alternative specialized transport protocol in place of TCP over the wireless link. The Selective Repeat Protocol (SRP) employed over the wireless hop uses its own flow and error control mechanisms designed and optimized specifically to tackle the lossy and erratic delay characteristics of the wireless link. The intermediate agent at the base station retains the transparency of the connection by hiding the details of the SRP from the fixed host and provides the same application interface as TCP. In [31], the authors have reported that the use of such a protocol is indeed advantageous compared to using TCP over the wireless link too. The protocol attempts to use smaller MTU over the low bandwidth wireless links. The authors of [8] have identified intermittent connectivity over a wireless link as transient errors over transport level connection that the protocol software must protect applications from. Thus, a new session layer protocol called Mobile Host protocol (MHP) that explicitly includes mechanisms for recovering from errors over the wireless link, in keeping with the ISO reference model, which assigns the responsibility of recovery and re-synchronization in data transfer to the session layer has been developed. Fig. 2 illustrates the protocol hierarchy assumed by the authors at the base station and mobile host [8]. Socket MHP (Session Layer) TCP/UDP IP Fig. 2 The MHP at the mobile host (MH) intercepts any connection request and requests a transport level connection with its peer at the current base station (BS). The MHP peer at the BS sets up a surrogate MHP agent on behalf of the requested connection, which in turn establishes a TCP connection with the fixed host (FH). The surrogate agent acts as a relay for the traffic between the two hosts in both directions. The connection establishment for a connection request from stationary host to mobile host or between two mobile hosts follows the same pattern. During data transfer, the MHP at the MH sends data in small segments to match the smaller Maximum Transmission Unit (MTU) over the wireless link. The surrogate MHP agent at the BS buffers these data packets and assembles them into larger TCP segments before forwarding them on the wired network. Similarly, when data has to be transferred to the MH, the surrogate MHP agent at the base station breaks the received TCP segment into smaller data segments and then forwards them to the MH. The MHP layer also maintains state information on segments in transit to and from the wireless link, and other connection parameters to recover from hand-off related losses. The MHP employs the specialized SRP for swift error recovery when packet losses are experienced over the wireless link. SRP uses a selective repeat algorithm based on a Selective Acknowledgment (SACK) strategy. When an out of sequence segment is received at the receiver, it returns a SACK that specifies the missing sequence using a bitmap, the sequence number of latest ` 4

5 segment received, and the last segment received in sequence. The sender retransmits all the missing segments specified in the SACK when it receives the SACK. Hence, multiple segment losses in one round trip time (RTT) can be recovered using this approach, which naturally increases throughput. Hand-offs are also handled by the two surrogate MHP agents - the agent at the current base station and the agent at the base station of the new cell the mobile has moved into. Any data segments lost during hand-offs are recovered by transport layer re-transmissions Mobile-TCP: Mobile-TCP [11] aims at reducing the computing and communicating power needed for the operation of the mobile host. The connection is split into the connection between the mobile host (the source) and the Mobile-Gateway (local fixed host to which the src is connected) and the connection between the Mobile-Gateway and the corresponding host (the destination). This protocol differs from I- TCP in that it uses an asymmetric transport layer protocol on the wireless link to reduce communication and computational complexities. The asymmetric design is used so that codes of different complexities can be executed on either side of the link. We can ensure that the more powerful Mobile-Gateway handles the more intense work while the mobile host handles the less intense work. Note: M-TCP refers to Mobile-TCP Fig. 3 The protocol stack for Mobile-TCP is shown in Fig. 3. The Mobile-Gateway does the function of the MSR in I-TCP [6]. The Mobile-Gateway maintains a one hop wireless Mobile-TCP connection with the mobile host and a TCP connection with the corresponding host. As can be seen from the diagram, Mobile-TCP is used only for one hop. The Mobile-Gateway has a regular TCP connection with the corresponding host. The Mobile IP layer handles the routing on the link between the Mobile-Gateway and the corresponding host. In normal TCP, a host can initiate connection as well as wait for connection from other hosts. In Mobile-TCP these features are handled by the Mobile-Gateway. When a host wants to start an active ` 5

6 conversation, it informs the Mobile-Gateway about the identity of the destination and the connection parameters. The Mobile Gateway then sets up the connection with the destination. At the same time, when a host is ready to receive calls it informs the Mobile-Gateway. This allows the Mobile-Gateway to accept or reject connection requests for the host without asking the host again. Mobile-TCP employs a technique similar to the Van Jacobson s header compression [4] to reduce the amount of wireless transmission. During connection establishment stage, two Connection ID s (CID) are assigned for communication over the wireless links, one in each direction. The mobile host communicates with the Mobile-Gateway using the CID MH, whereas the Mobile-Gateway uses CID MG to communicate with the mobile host. The CID s contain the source and destinations IP addresses and port numbers. CID s are used to reduce the overhead of communicating the whole TCP header each time over the wireless link. Once the connection has been setup, the mobile host communicates by sending the CID along with the payload. The Mobile-Gateway translates the CID into the corresponding TCP header based on the information it cached during the connection establishment phase. In TCP a timer is set each time a packet is sent. Once the timeout for the acknowledgment (ACK) expires, over, the source retransmits the packet. As the number of packets increase the number of timers created also increase, resulting in heavy load on the battery of the source. To overcome this the Mobile-TCP uses Go-back-N and Selective Reject schemes. The transmission from the Mobile-Gateway to the mobile host uses Go-Back-N scheme. The mobile host upon reception of a packet sends an ACK to the Mobile-Gateway. The Mobile-Gateway upon reception of the ACK deletes the packet from the buffer. When a packet is lost, the mobile host sends a retransmission request with the sequence number of the lost packet. Upon reception of this lost request the Mobile-Gateway starts retransmission of packets staring from the sequence number requested. Generally, loss of packets at the mobile host occurs due to fading of the signal. Consequently the loss is bursty with loss of continuous sequence of packets. By using the Go-Back-N we ensure that the mobile host need not request retransmission for each lost packet in the continuous sequence. Instead, it only needs to request for the first packet in the sequence. Although this means wastage of bandwidth, as all the packets are retransmitted even if they reach successfully, this method is preferred as it reduces the transmission load on the mobile host, thereby reducing the power consumed at the mobile host. The transmission from the mobile host to the Mobile-Gateway uses the Selective Reject scheme. Upon receipt of a packet, the Mobile-Gateway sends an ACK to the mobile host. When a packet is lost the Mobile-Gateway requests for the retransmission of that packet alone. The Selective Reject scheme helps in reducing the amount of transmission to be made by the mobile host thereby reducing the power consumed. The error control at the mobile host is implemented using the standard CRC-16 (Cyclic Redundancy Check) polynomial calculation, which only detects an error. Using this technique, the processing delay at the mobile host decreases. The error control at the Mobile-Gateway has a complicated procedure, which can identify the location of the error bit and can correct it. This helps in reducing the number of retransmission requests for the mobile host. A Mobile-TCP daemon is setup at every Mobile-Gateway. When a handoff occurs at the mobile host, the lower layers of the Mobile-Gateway inform the daemon about the hand-off. The daemon then sets up a normal TCP connection with the new Mobile-Gateway and sends the information about all the Mobile-TCP connections of the mobile host to the new Mobile-Gateway. The connections are then deleted from the old Gateway. The connection ID used by the old gateway may already be in use in the new Mobile-Gateway, so the Mobile-Gateway sends control packets to set the new CID s for each connection of the mobile host. This completes the handoff in Mobile-TCP. Mobile-TCP, even though based on I-TCP, maintains end-to-end semantics of TCP by delaying the acknowledgment sent by the Mobile-Gateway, till it receives an acknowledgment from the corresponding host Mobile-End Transport Protocol ` 6

7 Wireless links have limited bandwidth and wireless hosts are impaired by limited resources such as memory, disk space, and power supply. Hence, employing TCP/IP with its large header and overheads for wireless links further stretches these limited resources. Also, losses over wireless links tend to be bursty and frequent because of their vulnerability to interference and host mobility. The TCP sender assumes these data losses are due to congestion in the network and backs off resulting in performance degradation. To overcome these problems, Wang et al [9] have proposed a split-connection approach called Mobile-End Transport Protocol (METP). The protocol replaces TCP/IP over wireless link with a simpler protocol that uses smaller headers provided that the wireless link happens to be the last hop in the connection. Thus, the functionalities needed for communication with an Internet host are shifted to the base station from the wireless host. The protocol tries to take advantage of the base station support and the fact that functions of mobile devices are limited. Shifting the majority of the network protocols to the base station has the advantage of delegating some work of the wireless host to the more powerful base station and hiding the communication between the base station and mobile host to the external network. The protocol also exploits link-layer acknowledgements and retransmissions for quick recovery from losses over the wireless link, which distinguishes it from other split-connection approaches like I-TCP, SRP, and Mobile-TCP. Scalability may be an issue to consider when shifting the functionalities from the mobile hosts to the base station as the base station may be overwhelmed if it has to serve a large number of mobile hosts with multiple network connections. However, the authors [9] have argued that such an eventuality is highly unlikely because of the observed pattern of usage of mobile computing resources. METP eliminates TCP and IP layers from the mobile hosts and therefore, the TCP/IP headers from the packets transmitted over the wireless link. The mobile host only has a simple multiplexing and demultiplexing mechanism. The TCP/IP header in the data packets is replaced with demultiplex keys (port numbers) and IP addresses of the source and destination. Under this scheme, the base station handles all Internet traffic. To an external machine, the communication between the base station and mobile host resembles an interaction between an application process and transport layer protocol. METP does away with the IP layer in the wireless link by taking advantage of the fact that the hop between the base station and mobile host is the first or last in the connection. Thus, the METP at the base station accepts an IP packet destined for the mobile hosts as if it were meant for itself, strips its IP header, and delivers it to the higher layer. The header check sum is replaced by the link-layer Cyclic Redundancy Check (CRC) because there is only one hop between the mobile host and base station. The METP at the base station handles any TCP connection involving the mobile host. The base station uses send buffer to temporarily store packets sent by the mobile host, before they are forwarded by METP to the wired network. Similarly, data packets meant for the mobile host are received at the base station, stored in the receive buffer, and then forwarded to the mobile host. An acknowledgment is sent to the fixed sender as soon as data arrives in the receive buffer, which is not freed until the data it contains is sent to the receiver. Any problems that arise in the wireless link are intimated to the fixed sender indirectly. If data packets are not sent to the mobile host due to some reason (say, a temporary link failure), free receiving space in the receive buffer at the base station decreases and the allowed window at the sender shrinks consequently. When the link comes back, the sender window will soon jump to its normal size. In a way, the mobile host now resides in the base station, and migrates from base station to base station during hand-offs. As a result, the mobile host becomes more dependent on the base station and any failure in the base station will adversely affect the status of the mobile host as seen from the external world. So, appropriate failure recovery mechanisms have to be set forth for the base stations. Retransmission mechanisms at the link level use CSMA/CA with priority acknowledgements. If the CRC frame of a received packet is found to be correct, the receiver immediately sends an acknowledgment. If no acknowledgment is received within a time-out period, the sender retransmits the packet. The upper layer is informed accordingly. This mechanism also ensures reliable delivery of the data packets. To avoid packet losses due to buffer overflow at the receiver, the receiver sends periodic coarse acknowledgements that intimate the sender of the available buffer space. ` 7

8 The header used for the wireless link only contains the source and destination port numbers and IP addresses which reduces its size to 12 bytes from the standard 40 bytes for the TCP/IP header. Using various header compression techniques may further reduce the header size. During handoffs, all information pertaining to the TCP connections established on behalf of the mobile hosts, current sending and receiving windows, the data in the send and receive buffers, etc. are handed over to the new base station. The new base station buffers any packets it receives for the mobile host before the hand-off process is completed. The fixed host is transparent to the hand-off process. The authors [9] believe that the hand-off latencies that may arise because of the shift in responsibility to the base station will be outweighed by the performance improvements especially for a system with wellconnected base stations and few connections on a mobile at any given time. Applications that use TCP are compatible with METP and need not be modified because the socket interface between the application and system is retained in METP and hence, provides an illusion to the application that it is talking to a traditional TCP/IP stack. Advantages and Disadvantages of split-connection approaches: The advantage of split-connection approaches is that they separate the flow control and congestion control functionality on the wireless link from that on fixed network, which is extremely useful because of their vastly different bandwidth and error characteristics. Furthermore, the indirection allows the base station to manage much of the communication overhead thus reducing the workload on the wireless host. This approach also allows the use of varying but optimal Maximum Transmission Units (MTU) over both the wired and wireless networks. Indirection at the base station helps in faster reaction to mobility and wireless related events as opposed to a non-split approach. A separate transport protocol for wireless link can support notification of events like disconnections and available bandwidth to the higher layers, which may be fruitfully used by link-aware and location-aware mobile applications. No modifications are needed at the fixed hosts, as indirect protocols are backward compatible with existing wired networks. These approaches also provide a measure of reliability to the wireless link for applications that prefer to use unreliable transport over fixed network. In general, split-connection approaches violate end-to-end semantics of TCP acknowledgements. An acknowledgment may be delivered to the sender even before the data actually reaches the destination. This might not be a problem for applications that do not rely on TCP to provide end-to-end semantics. For example, ftp uses application layer acknowledgements in addition to the end-to-end acknowledgements provided by TCP. However, failure of the base station will lead to the disruption of an I-TCP connection while a normal end-to-end TCP connection would survive. So, I-TCP might be better suited for applications like ftp and mosaic that allow user or higher layer protocol to retry and re-establish a connection in case of a base station failure, which is expected to be rare in the first place [7]. In addition, the packets have to incur the overhead of going through the TCP protocol stack twice at the base station as against the zero times for a non-split connection. Split-connection approaches also suffer from other drawbacks like high latency involved in transfer of state information during hand-offs, need for large buffer size at the base station particularly if the wireless link is slower than the wired network, and unnecessary reduction in the congestion window at the base station (BS) for the wireless link even for non-congestion errors. Further, the copying of data from the FH-BS socket buffer to BS-WH socket buffer tends to increase end-to-end latency. 4. TCP AWARE LINK LAYER As the name suggests, the following schemes address the issue of improving TCP performnce over wireless links by making the link layer aware of the overlying TCP Snoop Protocol ` 8

9 The primary motivation behind this protocol was to effectively use TCP for wireless links without sacrificing its end-to-end semantics and with minimum modifications to the existing TCP implementations. The snoop protocol [12, 13, 14] makes modifications only to the routing code at the base stations. The base station routing code is modified by the addition of a module, called the snoop agent. The agent monitors communication across the connection in either direction and caches packets that have not been acknowledged by the receiver. A packet loss is detected by the arrival of a small number of duplicate acknowledgements (dupacks) from the receiver or by local timeout at the base station. The snoop agent retransmits the lost packet if it is available in the cache and hides the loss from the sender by not propagating the duplicate acknowledgements (dupacks) to the fixed host. In this manner, temporary disconnections of the mobile host (MH) and transient states of low communication quality over the wireless link are hidden from the fixed host (FH). The snoop module is composed of two linked procedures, snoop_data() and snoop_ack(). Snoop_data() processes and caches packets meant for the MH while snoop_data() processes the acknowledgements coming from the MH and initiates local retransmissions at the base station. The algorithms run by these procedures is shown schematically in Fig. 4 and Fig. 5. Packet arrives ACK arrives Sender retransmission New packet? No Forward packet Reset local retransmit counter New ACK? Yes Free buffers Update RTT estimate Propagate ACK to sender Yes No In sequence No Mark as congestion loss Forward packet Duplicate ACK? No Common case Discard Yes Congestion loss Yes Spurious ACK Cache Packet Forward to mobile First One? No Yes Retransmit lost packet with high priority Common case Fig. 4 Flowchart for snoop_data() Next packet lost Discard Later dupacks for lost packet Fig.5 Flowchart for snoop_ack() Snoop_data() is responsible for the packets arriving from the fixed host (FH). TCP uses sequence numbers to uniquely identify TCP packets. The snoop module at the base station keeps track of the last sequence number seen for the connection. If a new packet arrives in the normal TCP sequence, it adds the packet to the snoop cache and forwards the packet to the mobile. One packet per transmission window is time-stamped to facilitate RTT estimation. If an already cached packet arrives out-of-sequence, different ` 9

10 actions are taken based on the sequence number value. If the sequence number is found to be greater than the last seen acknowledgment, it is likely that the packet has not been received by the receiver and hence, is forwarded. On the other hand, if the sequence number is lesser than the last seen acknowledgment, it probably means that the original ACK with the same sequence number was lost in transit. In order to bring the sender to the current state, the snoop sends an ACK acknowledging the last packet seen by it. If an out-of-sequence that has not been cached earlier arrives, it implies that either the packet was lost in the wired network due to congestion or has arrived out of order. This packet is forwarded to the MH and marked as having been retransmitted by the sender. Snoop_ack() handles the acknowledgements (ACKs) sent by the MH. When a new ACK arrives, all acknowledged packets in the snoop cache are purged and the RTT estimate is also updated. The ACK is forwarded to the FH. If the received ACK is less than the last seen ACK, it is considered to be spurious and discarded by the snoop module. If the received ACK is a duplicate ACK (dupack), the snoop checks if the packet is available in the cache. If it is not available in the cache and has been marked as having been retransmitted by the sender, the dupack is forwarded to the FH, which initiates congestion control mechanisms if necessary. If the packet is available in the snoop cache, the packet is retransmitted with higher priority. The snoop module estimates the number of dupacks it can receive for a given packet by counting the number of packets that were transmitted after the first packet loss. The dupacks that arrive later and are within this count value are discarded. Retransmission of lost packets at a higher priority ensures that they reach the MH sooner and hence reduce the number of dupacks generated. Snoop also performs retransmissions based on timeouts. This caching scheme on its own cannot be very effective in improving TCP performance over wireless links because the bulk of the packet losses are likely to be from the MH to the base station (BS) and there is no way for the mobile to determine if the packet was lost in the wireless link or elsewhere in the network owing to congestion. Hence, the authors [13] have suggested a slight modification to the TCP code at the MH. The base station determines what packets were lost in a transmitted window and sends negative acknowledgements (NACKs) to the MH for these packets. NACKs are encoded as bit vectors to ensure that they do not overload the sparse wireless bandwidth. The MH uses these NACKs to selectively retransmit lost packets. The idea of using NACKs is based on the Selective Acknowledgment (SACK) scheme suggested for improving error recovery in TCP. The authors have discussed strategies to handle mobility related losses in [14]. In this scheme, hand-offs are mobile initiated and occur when the MH discovers a BS with a stronger signal than the present one. Based on the signal strength measurements, the MH determines which BS has to forward packets while the other just buffers the packets. This smooth transition of control is achieved by the involvement of the mobile host s Home Agent (HA), which routes the packets to the correct BS. When the hand-off is completed, the new BS begins forwarding packets to the MH after synchronizing its buffer. The advance routing of packets minimizes the actual duration and amount of data loss during hand-offs. However, this kind of hand-off requires that the base stations engage in some sort of transfer of state information so that continuity of the connection is maintained. This scheme achieves this by allowing mirroring of state information at the new BS while hand-off is in progress. Any data packet losses due to the non-uniformity of buffering action at the two base stations is not very significant and can be recovered quickly. The primary advantage of snoop protocol is that it retains end-to-end semantics of TCP while achieving a very high throughput. The snoop protocol is closely coupled to TCP, and hence, does not perform redundant retransmissions, which might be the case with link-level mechanisms like those discussed in [5]. Further, fast retransmits are not triggered at the sender despite out-of-order link layer delivery. Snoop protocol also allows local recovery from wireless losses keeping the fixed host unaware of the same. Snoop protocol suffers from the disadvantage that the link layer at the base station needs to be TCP-aware for proper implementation. The snoop approach may not completely shield the sender from wireless losses. Snoop protocol cannot be used if the data packets are encrypted or if the TCP data and TCP acknowledgements follow different paths (i.e.) they do not go through the base station. ` 10

11 4.2. WTCP: Split-connection approaches [6, 7, 8, 9, 11] in general do not retain the end-to-end semantics of TCP even though they shield the fixed host from the losses over wireless links. M-TCP [24] follows a completely different set of semantics. Approaches like Fast Retransmits [23] require modification to the TCP code at the sender or mobile host. WTCP [15] is a transmission control protocol, which maintains the end-to-end semantics of TCP without needing modifications in the TCP code at the hosts. The only modification that is needed is done at the base station. The protocol is somewhat similar to the snoop protocol [13]. The drawback with snoop protocol is that it does not guarantee complete shielding of the fixed host from wireless losses. In WTCP, the base station buffers packets destined to the mobile host and upon detection of lost packets retransmits them after receiving duplicate acknowledgements from the mobile host. This scheme hides the time spent by the base station in local recovery so that the source s round trip time (RTT) estimate is not affected which is critical in detection of congestion in the wireline network and is the main feature that distinguishes this approach from snoop protocol. Fig. 6 illustrates the conceptual view of the WTCP approach. Fixed Host Base Station Mobile Host TCP Chapter 3 T CP WTCP Fig. 6 Chapter 2 T CP IP IP IP IP TCP WTCP Arrival of a packet for the mobile host is detected by the network layer protocol running in the base station and the packet is sent to the WTCP buffer. A separate receive array maintains a series of sequence numbers for the segments received. Provided the expected segment is same as the arrived segment, it is stored in the buffer along with its arrival time and the receive array is updated. In addition, the sequence number of the next expected segment is increased by the number of bytes received (packet size). If an out-of-sequence packet with a larger sequence number is received, it is buffered, the arrival time is recorded and the receive array is updated. No change is made to the sequence number of the expected segment. If the out-of-sequence packet has a segment number smaller than the expected value, the packet is discarded. WTCP maintains state information for the wireless connection separately including the sequence number of the last segment sent to the mobile host and the sequence number of the last acknowledgment received. It transmits all the segments, which fall within the wireless link transmission window. The timestamp of the segment in the WTCP buffer is incremented by the amount of time the segment spent in the WTCP buffer (resident time) after each retransmission. When a segment is sent to the mobile host, the base station schedules a new timeout if there is no other timeout pending. TCP end-to-end semantics is maintained as the base station acknowledges the source only after receiving the acknowledgment from the mobile host. The round trip time seen by the source does not include the packet s resident time at the base station. Retransmissions are performed in case of timeout or on receipt of duplicate acknowledgements. If a timeout occurs, the transmission window for the wireless TCP IP ` 11

12 link is reduced to one segment as the base station interprets it as a likely burst loss on the wireless link. Quick reduction in the transmission window helps in avoidance of wasteful wireless transmission and interference. There is no need for any modification in the TCP code at the source. In normal TCP, the arrival of duplicate acknowledgements is understood to be due to congestion and the congestion window is scaled down. WTCP avoids this unnecessary scaling down of congestion window due to wireless losses by assuming that the duplicate acknowledgements does not indicate congestion in the network and retransmits the lost segment. Hence, the transmission of packets through the transmission window remains unaffected. WTCP improves the utilization of the wireless channel by avoiding more than one duplicate acknowledgment. This protocol uses a 10 ms clock granularity to accurately maintain the round trip time and to trigger the timeouts in millisecond range. The authors point out that throughput, which is the average number of successful transmissions to the mobile host in a second is not a good measure of performance of these protocols as improved throughput leads to poor utilization. Goodput defined as the ratio of the number of bytes transmitted over wireless link to the total number of bytes transmitted (new and retransmitted bytes) is used as a figure of merit. Simulation studies done by the authors indicate that WTCP outperforms other protocols when both throughput and goodput are considered in tandem. In less reliable wireless link, throughput of WTCP is better than other protocols because of its retransmission policy on the wireless links. An advantage of WTCP protocol over the Snoop protocol is that the latter yields low throughput when the wireless link is error prone for long durations. Another advantage of this scheme is that it maintains smooth calculation of RTT estimates at the source, as this calculation will not include the resident time at the base station. WTCP suffers from additional overheads introduced due to the need for maintaining timestamps. Also, WTCP in its present format does not address the issue of mobility related losses. It is likely that the advantages of WTCP may be fully realized only if retransmission times are large. 5. TCP UNAWARE LINK LAYER - DELAYED DUPLICATE ACKNOWLEDGEMENTS: Delayed Duplicate Acknowledgements [16] is a TCP-Unaware approach to improve the performance of TCP over wireless without taking TCP-specific actions at the intermediate nodes. The proposed scheme behaves similar to Snoop protocol [13]. The base station performs link level retransmissions for packets that are lost on the wireless link due to transmission errors. However, the link level retransmissions do not guarantee in-order delivery of packets. Link level retransmissions are triggered by link level acknowledgements thus making the base station TCP-Unaware. Making the receiver delay the third and subsequent dupacks for some interval (say, d), reduces interference between TCP retransmissions and link level retransmissions. When the receiver receives out-of-order packets, it sends dupacks for the first two packets immediately, while the third and consecutive dupacks are delayed for duration d. Thus, if the next in-sequence packet is received within the interval d, the delayed dupacks are not sent. If no in-sequence packet is received in this interval, these delayed dupacks are sent. Considering the cases where transmission errors occur on the wireless link, the value of d if chosen appropriately would give sufficient time for link level retransmissions of the lost packet from the base station. On receiving the retransmitted packet within this interval d, the receiver will acknowledge all the in-sequence packets including the retransmitted packet. Thus the sender, which does not receive the third and consecutive dupacks, will not invoke fast retransmit mechanisms. However, for packet losses due to congestion, delaying the dupacks would degrade the performance of TCP. Delayed Duplicate Acknowledgment scheme improves the performance of TCP in networks that suffer from transmission errors. On the other hand, if the packet losses are due to congestion, this approach could be detrimental. Advantage of this scheme over other approaches is that it works even when the packets are encrypted, since the base stations need not view the TCP headers of these packets. Moreover, any link level retransmission scheme could be used along with the proposed Delayed Dupacks scheme. ` 12

13 6. EXPLICIT NOTIFICATION: Explicit notification schemes have been proposed to avoid unnecessary time-outs at the source during local recovery at base-stations. A general approach in these schemes is to explicitly notify the source about the cause of packet losses Explicit Congestion Notification (ECN): In ECN based protocols [18], the source node is explicitly notified about the cause of packet loss, which helps in preventing unnecessary invocation of congestion control schemes by the source. The motivation behind this approach is that a transport protocol, which is aware of the wireless link, can coexist with the underlying link layer schemes to achieve good performance. Poor queue management strategies like Drop Tail queuing which drop newly arrived packets if the buffer is full result in low overall throughput and utilization. A better queue management scheme is Random Early Detection (RED) queue management scheme where two levels called minimum threshold and maximum threshold are maintained and packets are dropped probabilistically. In RED, blocking probability of the packets is a function of queue size. If queue size increases beyond minimum threshold, blocking probability increases linearly with it until size reaches the maximum threshold where the blocking probability will be one. ECN [18] has been proposed as an extension to RED. When the queue size lies between minimum threshold and maximum threshold the arriving packets are marked. ECN capable transport bit is set by the sender end systems if both the end systems are ECN capable. The bit used by the hosts is ECT (ECN Capable Transport) whereas the router uses the CE (Congestion Experienced) bit to notify the destination that a packet has experienced congestion. The receiver sets the ECN-echo flag to inform the source that network is congested. The source acknowledges the report of congestion by the receiver by setting the CWR (Congestion Window Reduced) flag, which informs the receiver that necessary congestion control mechanisms have been initiated. If many packets are received at the receiver following a set of duplicate acknowledgements transmitted the CE bit will be the OR of all data packets being acknowledged. Consequently receiver has to set ECN echo flag even if one of the packets has reported congestion. To maintain robustness the TCP receiver must set ECN echo flags in a series of acknowledgements. The authors [18] of this approach suggest an extension of this scheme to wireless networks. In case of packet loss on wireless links the source will not receive any acknowledgements with ECN-echo flag set, as a result the source would avoid invocation of any congestion control mechanisms. Hence the source would reduce the window size and recover fast as the connection is good again Partial Acknowledgements: Cobb et al [5] have proposed a partial acknowledgment strategy that aims at enabling the TCP source distinguish between congestion related losses and transmission losses due to the presence of wireless links. The sender invokes TCP congestion control schemes only when it detects congestion in the network and retains its original congestion window if losses are determined to be due to the wireless links in the connection. They have suggested that their scheme may even be suitable for dealing with hand-off related losses. As with most of the schemes dealing with extending TCP to wireless networks, this scheme also implicitly assumes that only the links at the extremities in the route are wireless and the rest of the route is wired. The basic idea is to introduce a two-step acknowledgment scheme. For a communication from a fixed host to a mobile host, the base station/router that is connected to the destination host by a wireless link sends a last hop acknowledgment (lhack) for every message it receives which implies that there was no congestion related loss in the wired part of the route. The sender then waits for an acknowledgment from the destination (dack). If sender receives lhack but no dack for a message it sent, it identifies the loss to have occurred in the wireless part of the network. Hence, it does not reduce its window size and ` 13

14 continues to transmit at the same rate. Of course, the unacknowledged packet is re-transmitted. However, if the sender receives neither lhack nor dack, the message was probably lost due to congestion at an intermediate node and consequently, the source initiates congestion control by reducing its window size. Now, we consider the case of a mobile host sending messages to a fixed host. The paper [5] introduces another acknowledgment called the first hop acknowledgment (fhack) to deal with this case. If the mobile host doesn t receive fhack from the base station/router for a message it sends, it identifies it as a loss due to wireless network and re-transmits the message. If the source receives the fhack but not dack from the fixed destination, then the loss is probably due to congestion in the wired segment of the network and so the source scales down its window size. In both cases, it may so happen that the dack was sent by the destination and it was lost in the wireless network. However, since dacks are cumulative, the loss of a single or even a few dacks does not adversely affect the sender. For a mobile host to mobile host connection, the source receives both lhack and fhack for every message it sends. The source may come to an erroneous conclusion if it receives fhack, the message is lost in the destination network (implying no dack was sent), and the lhack is lost in the source network, as it will assume that message loss occurred due to congestion. The authors [5] have argued that the probability of this happening is very small and so will not affect the sender unfavorably. They have also suggested that the mobile hosts should set up connections with an intermediate fixed host to tide over the problem. Hence, for each data message, two/three acknowledgements have to be sent thus increasing the communication overheads. The authors defend this by saying that the acknowledgements are small relative to the data message and should not significantly affect the systems throughput. They also suggest an optimization to their scheme in the form of reduced number of dacks sent by the destination utilizing the cumulative nature of dacks. The source invokes the slow start and fast re-transmit approaches used in standard TCP only when lhacks are not received before the time-out period set for every message sent. The sender maintains its current throughput when re-transmitting packets if lhacks are received correctly. It is also possible that messages may be lost during hand-offs due to the mobility of hosts. Even in this case, the lhacks will be received by the source even if messages are lost during hand-off and consequently, there will be no reduction in sending rate as the loss is not due to congestion. Wireless Source Base Station Wired Network Base Station fhack lhack dack Fig. 7 Wireless Destination Fig. 7 illustrates the origin of the various acknowledgements. Variations to this scheme include local buffering and re-transmission by the base station. This is similar to the approach in snoop protocol discussed earlier Multiple Acknowledgements: TCP over Wireless using Multiple Acknowledgements is a solution proposed by Biaz et al [19] for improving the TCP performance in heterogeneous networks by making the TCP layer aware of high bit error rates on wireless link and reducing the load on the wired network. The protocol distinguishes the losses on the wired portion from the losses on the wireless link by using two types of acknowledgements, partial acknowledgment and complete acknowledgment. The base station is responsible for retransmissions on the wireless link. It sends a partial acknowledgment to the sender if it experiences ` 14