See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/220200947
`
`The design and performance of Mobile TCP for wireless networks
`
`Article  in  Journal of High Speed Networks January 2001
`
`Source: DBLP
`
`CITATIONS
`5
`
`2 authors, including:
`
`Haas J. Zygmunt
`Cornell University
`
`325 PUBLICATIONS   23,230 CITATIONS   
`
`SEE PROFILE
`
`READS
`4,358
`
`Some of the authors of this publication are also working on these related projects:
`
`Green Microgrids View project
`
`Zone Routing Protocol View project
`
`All content following this page was uploaded by Haas J. Zygmunt on 22 September 2014.
`
`The user has requested enhancement of the downloaded file.
`
`Smart Mobile Technologies LLC, Exhibit 2009
`Page 1 of 22
`
`

`

`Journal of High Speed Networks 10 (2001) 187–207
`IOS Press
`
`187
`
`The design and performance of Mobile TCP
`for wireless networks
`
`Zygmunt J. Haas and Abhijit Warkhedi
`School of Electrical Engineering, Cornell University, Ithaca, NY 14853-2801, USA
`E-mail: haas@ece.cornell.edu, warkhedi@cisco.com
`
`Abstract. In this paper, we propose a novel approach to reduce the wireless communication overhead associated with the transport layer.
`Portability is a key element of mobile computing. As mobile devices shrink in terms of size and weight, their computing capabilities are also
`reduced, constrained by battery capacity. To sustain a good performance level of mobile applications, we devise a solution that reduces the
`processing complexity on computing-limited mobile devices. Additionally, we aim to minimize the use of wireless resources to further improve
`performance. Specifically, we develop a streamlined protocol architecture, Mobile TCP (MTCP), that achieves the elimination of IP processing
`on the wireless segment of the TCP connection. MTCP operates over a single hop wireless link, and, consequently, it eliminates the unnecessary
`overhead placed on mobile devices, such as the TCP congestion control mechanisms. In addition, we investigate the impact of streamlining the
`socket layer on offloading the processing overhead. Our experimental results indicate a substantial improvement in the efficiency of protocol
`processing. For instance, results show that the MTCP processing time per packet is approximately only one fourth that of TCP and the use
`of CPU resources is reduced by up to 50%. Furthermore, the protocol incorporates various robust, yet simple, loss recovery techniques to
`considerably improve the throughput in lossy wireless conditions.
`
`1. Introduction
`
`The vision behind mobile computing [1,2] is to support ubiquitous access to various forms of information, such
`as data, voice and video. Integration of mobile devices into the existing internetwork consisting of stationary hosts
`has played a critical role in bringing the state-of-the-art a step closer to realizing this vision. At the same time,
`continued use of legacy technology in conjunction with wireless networks has given rise to certain problems due
`to the requirements of the portable mobile devices and the special characteristics of the wireless link.
`Portability is an important element of mobile computing. As mobile devices shrink in physical parameters (size
`and weight), their computing and power capabilities are also reduced, constrained by battery capacity. Unfortu-
`nately, battery technology has been improving only at a modest pace in terms of increased capacity per unit weight
`and volume [3]. To maintain a constant level of performance of mobile applications, there is a need to minimize
`processing load on portable mobile devices [4].
`The primary focus of our work is the design of transport protocols in computing-limited wireless environments.
`We devise a lightweight protocol architecture, Mobile TCP (MTCP), that allows the emulation of TCP functional-
`ity between a mobile host and a stationary host, in a way that reduces the processing load on the mobile host and
`minimizes the use of the wireless medium. Most of our protocol enhancements stem from the fact that the commu-
`nication between the mobile host and the basestation is over a single link. Thus, the design of MTCP resembles that
`of a link-layer protocol. Consequently, as we see in this paper, many functions can be either simplified or totally
`eliminated in the wireless segment of the TCP connection, leading to a lean protocol code on the mobile machine.
`Furthermore, our implementation streamlines the protocol stack to additionally offload processing from the mobile
`devices.
`Our protocol implementation is based on the split-connection model, where the connection between the mobile
`host and the basestation is split into two connections: the connection between the fixed host and the basestation, and
`the connection between the basestation and the mobile host. The first connection is called the wired segment, while
`the second portion is the wireless segment. The division, by itself, is not a new idea and was already employed in
`
`0926-6801/01/$8.00  2001 – IOS Press. All rights reserved
`
`Smart Mobile Technologies LLC, Exhibit 2009
`Page 2 of 22
`
`

`

`188
`
`Z.J. Haas and A. Warkhedi / The design and performance of Mobile TCP
`
`previous studies [5,6]. We chose to employ the split-connection approach because it provides a convenient proxy-
`style model to enable the development of a new lightweight protocol on the wireless segment. It should be noted,
`however, that MTCP could be implemented using other approaches as well. We address this point in Section 6.
`In addition to reducing the communication overhead, MTCP incorporates various robust yet simple techniques
`to combat heavy losses over the wireless link. Losses are prevalent on networks with wireless links due to various
`factors, such as noise, interference, channel fading, and user mobility. It has been identified that TCP performs
`poorly in wireless networks, since it assumes all losses occur as a result of congestion problems in the network. In
`response to a loss, TCP [7,8] takes various steps to throttle its transmission rate to alleviate congestion. However,
`this leads to a degraded performance in networks that exhibit non-congestive losses [9]. Several studies have been
`proposed in an effort to alleviate the effects of non-congestion-related losses on TCP performance in wireless or
`similar high loss links [6,10–12]. The split-connection model, which is the basis of our implementation, addresses
`this issue by separating loss recovery on the wireless segment from the wired segment. Thus, in this paper, our aim
`is not to solve the congestion issue, but rather to improve loss recovery on the wireless segment.
`In accordance with the goals of our research, we evaluate the performance of MTCP in terms of its ability to
`offload processing from mobile devices, as well as its ability to improve throughput in lossy conditions. Our mea-
`surements, which are based on metrics such as throughput, protocol latency, CPU-usage, CPU energy consumption,
`and inter-buffer delay, indicate that our protocol is indeed effective in addressing both of these goals.
`The rest of this paper is organized as follows. Section 2 briefly summarizes some previously conducted work
`on energy conserving protocols for portable devices. This section also outlines some solutions that have been
`proposed to address the performance issues of TCP over networks with wireless links. In Section 3, we present the
`design of MTCP followed by some implementation details. Section 4 describes our experimental testbed, including
`the error model and performance metrics for evaluating the protocols. Section 5 presents the performance results
`and analysis of several experiments. In Section 6, we propose some alternative approaches that can be used to
`implement MTCP. We discuss our future plans in Section 7 and conclude with a summary in Section 8.
`
`2. Related work
`
`Considerable research work in the past has focused on improving the performance of TCP over wireless and
`other lossy links, as it is the most dominant protocol in the Internet today. Some work has also been undertaken
`in developing energy efficient protocols and techniques for portable devices. In this section, we present a brief
`overview of each area of research.
`
`2.1. Energy efficient protocols and techniques
`
`Many portable devices today are equipped with power-saving components. Two such components are the proces-
`sor and the wireless communication device [3]. Processors typically offer two types of power saving features. One
`power-saving feature is the ability to slow down the clock rate. Energy consumption (E) is essentially proportional
`to the switching capacitance (C), and the square of the voltage (V ) (E ∝ CV 2). Consequently, energy consump-
`tion can be reduced with a decrease in clock rate or by a reduction in voltage. Various software techniques can be
`employed to dynamically change the speed of the clock [13,14]. The general strategy is to dynamically adjust the
`CPU clock depending on the processor utilization during a particular time interval. Another power-saving feature
`of the processor is the ability to shutdown the processor when the system is idle and turn it back on when the next
`interrupt occurs. A well-designed operating system can deduce whether the system is idle using the current state of
`all processes. Whenever all the processes are blocked, the processor is turned off and subsequently restarted upon
`the occurrence of an interrupt [15–17]. Examples of operating systems that use this strategy are Windows [18,19]
`and UNIX. Wireless communication devices also provide similar power-saving features that enable the devices to
`enter low-power consumption mode during periods of inactivity.
`From protocol design standpoint, general strategies to promote the transition of processors and communications
`devices into energy conserving modes can be stated as the following: minimize the processing complexity of
`
`Smart Mobile Technologies LLC, Exhibit 2009
`Page 3 of 22
`
`

`

`Z.J. Haas and A. Warkhedi / The design and performance of Mobile TCP
`
`189
`
`protocols, and decrease the overall use of the network device [3,20] without sacrificing any functionality. Various
`power-saving techniques have been proposed at different layers of the protocol stack.
`A link-layer error control scheme, proposed by [21], conserves energy by reducing the data transmission rate
`when the channel is impaired, so that the number of unnecessary transmissions is minimized. While the channel
`is presumed to be impaired, short probe packets are continuously sent until some feedback is received for these
`packets. The protocol proceeds with the transmission of data packets upon the receipt of the first feedback packet
`indicating an improvement in the link quality. This scheme has been shown to be more energy efficient, however,
`with a slight loss in throughput.
`Another link-layer scheme, proposed by Lettieri et al. [22], follows an adaptive error control strategy that uses
`Forward Error Correction (FEC) and Automatic Repeat reQuest (ARQ) to minimize energy consumption. ARQ
`mechanisms, such as Go-Back-N (GBN) and Selective Repeat (SRP), achieve reliability by retransmitting lost
`packets. Although ARQ mechanisms are relatively simple, they can cause a significant number of retransmissions
`when losses are excessive. FEC, on the other hand, reduces retransmissions by correcting erroneously received
`packets, however, at the cost of greater computational load, latency, and overhead in the form of additional bits.
`The adaptive error control scheme investigates the tradeoff between ARQ and FEC, and concludes that optimum
`energy savings can be achieved through an adaptive adjustment of the two mechanisms.
`AIRMAIL [23] is a reliable link-layer protocol, which uses asymmetric protocol design to reduce processing
`load on the mobile device, while placing much of the complexity on the basestation. This protocol also minimizes
`the amount of data transmitted over the wireless channel by combining several acknowledgments into a single
`one, thus conserving power at the cost of increased latency. In addition, AIRMAIL employs FEC to minimize the
`energy expended on retransmissions in highly lossy conditions.
`Another approach to minimizing the utilization of the communication device is to use header compression.
`In [24], the authors propose a low-loss header compression technique for TCP/IP, which significantly improves
`throughput performance of TCP. Their study also indicates that Van Jacobson header compression algorithm [25]
`can cause throughput degradation in lossy conditions due to inconsistencies in the compression-state.
`Another energy conserving strategy is to use a medium access protocol that dictates in advance when each
`wireless device may receive data. This allows each device to sleep when no data is to be received. Variations of this
`technique are employed in 802.11 LAN standard [26], LPMAC [27], POCSAG protocol, and Motorola’s FLEXTM
`protocol [28].
`Considerable work has also been done in the area of lightweight transport protocols. This work is motivated by
`the need to provide a low overhead protocol, without performance bottleneck for high-speed networks. To minimize
`processing bottlenecks, lightweight protocols employ various techniques, such as smaller header sizes, simpler flow
`and congestion control strategies, and partial or complete implementation of the protocol in hardware. Similar ideas
`can be applied for reducing the energy consumption and the processing overhead on mobile devices. Examples of
`experimental lightweight protocols include VMTP [29], LNTP [30], high-speed transport protocol [31], Delta-
`t [32], and XTP [33].
`
`2.2. Wireless TCP optimizations
`
`Figure 1 shows a typical network model for wireless networks. There are fundamentally three different ap-
`proaches to improving TCP performance in the presence of non-congestive losses, such as those on wireless
`links [34]. The first approach is to use a reliable link-layer protocol on the wireless link in order to hide wire-
`less losses from the TCP sender. Link-layer solutions recover from losses either by retransmitting lost packets
`(ARQ) or by correcting erroneously received packets (FEC). Although link-layer protocols fit well into the layered
`structure of network protocols, they can cause adverse interactions with the error recovery mechanisms of higher
`layer protocols, such as TCP. Specifically, competing retransmissions between the link-layer and the transport-
`layer caused by incompatible timer settings can result in redundant retransmissions [35]. Another concern is that
`error recovery mechanisms (such as ARQ, FEC, checksums) are duplicated at both the layers to provide reliabil-
`ity. This duplication of effort can impose a greater processing demand on mobile devices. TCP-aware link-layer
`
`Smart Mobile Technologies LLC, Exhibit 2009
`Page 4 of 22
`
`

`

`190
`
`Z.J. Haas and A. Warkhedi / The design and performance of Mobile TCP
`
`solutions, such as Snoop [11], solve some these problems. Snoop introduces an agent at the basestation to cache
`TCP segments sent across the link. The agent detects losses by leveraging upon acknowledgments sent by TCP.
`This way it avoids additional control exchanges to perform error recovery. Upon detecting a packet loss, the Snoop
`agent retransmits the lost packet from the local cache and suppresses any duplicate acknowledgements heading
`toward the TCP sender in order to shield it from non-congestive losses.
`The second approach is to split the end-to-end TCP connection into two connections: one instance of TCP
`operates over the wired segment and another instance of TCP or a different protocol operates over the wireless
`segment. A transport layer proxy (referred to here as the Redirector) at the basestation bridges the two segments
`together. An important consequence of the split-connection model is the separation of loss recovery on the wireless
`segment from the wired segment. As a result, losses over the wireless link can be recovered locally, while shielding
`the TCP sender on the fixed host from such losses. Indirect TCP (I-TCP) [5,10] is a split-connection solution that
`uses standard TCP over the wireless segment. The design of I-TCP is particularly intended for shielding TCP
`from packet losses during handoffs. I-TCP exploits the fact that lost packets are buffered at the basestation in the
`split-connection model. As part of the handing off process, I-TCP transparently moves the state of all connections
`(including send/receive buffers) associated the mobile from the old basestation to the new one. This is followed
`by an immediate retransmission and recovery of unacknowledged packets in the connection buffers, without the
`knowledge of the TCP sender on the fixed host. Studies, however, show that I-TCP is ineffective at recovering from
`wireless losses due to its choice of standard TCP for the connection over the wireless links [34]. Alternatively, a
`transport protocol with faster recovery mechanisms can be substituted, as in [6]. One problem with the split-
`connection model is that end-to-end semantics of TCP acknowledgments (ACKs) are not preserved. Specifically,
`ACKs for segments can now reach the source even before packets are delivered to the mobile host. However,
`proponents of this approach argue that most applications using TCP also have some kind of support for application-
`layer acknowledgments and error recovery [10]. In [12], the authors develop a protocol that does not violate the
`end-to-end semantics of split-connection approach by taking advantage of the persist state in TCP. Specifically,
`the source is completely throttled by shrinking the advertised window when the mobile host is disconnected, and
`activity is resumed as soon as connectivity is restored. Another technique called TCP splicing [36] preserves
`semantics by designing the transport proxy in such a way that ACKs (destined to the source) are not generated
`until the receiver acknowledges the forwarded data.
`The third class of solutions, the end-to-end schemes, improve TCP performance by distinguishing between
`congestive and non-congestive losses [34]. Specifically, an agent residing on the basestation marks all duplicate
`ACKs corresponding to lost packets in order to explicitly notify the sender of non-congestion losses. The sender
`uses this information to decide whether to invoke congestion control mechanisms or not. One problem with the
`end-to-end schemes is that they are often slow to detect and recover from losses, since recovery is not performed
`locally. This results in considerable throughput degradation in WAN environment, where the round-trip delays are
`much greater than in a LAN [10,34]. Another major problem with the end-to-end approach is the need to modify
`the existing TCP implementations on the fixed host, making the solution impractical for wide scale deployment.
`
`Fig. 1. Wireless network model.
`
`Smart Mobile Technologies LLC, Exhibit 2009
`Page 5 of 22
`
`

`

`Z.J. Haas and A. Warkhedi / The design and performance of Mobile TCP
`
`191
`
`3. Mobile TCP (MTCP)
`
`3.1. Protocol description
`
`Much of the previous research work deals with reducing processing and communication overhead at lower-
`layers of the protocol stack. The general strategies applied are reduction in code complexity, minimization of
`retransmissions, and header compression. Our approach is to focus on minimizing the protocol processing overhead
`at the upper layers of the protocol stack, specifically the transport and the network layer, where much of the protocol
`complexity exists.
`In this paper, we propose a streamlined protocol architecture for TCP that reduces the communication load on
`mobile devices. Our approach employs the split-connection model, in which the end-to-end TCP connection is split
`into the TCP connection over the wired segment and the MTCP connection over the wireless segment. It should be
`noted that we use the split-connection model to design a new lightweight protocol (MTCP) on the mobile device,
`rather than to address the congestion issue. The split-connection model is not the central point of our work, and we
`provide some alternative implementation techniques in Section 3.6.
`MTCP is based on our previous work in this area, as described in [4]. The key idea influencing our protocol
`design is the fact that MTCP operates over a single link, the wireless segment. Thus, in many aspects, the design
`of MTCP resembles that of a link-layer protocol. Furthermore, since the protocol executes over a single hop, all
`packets arrive in order and all losses on the wireless segment are non-congestion related. As a consequence, the
`design of MTCP can be greatly simplified and optimized, resulting in a significant reduction in processing and
`communication load over the wireless link. In addition, MTCP is tuned for quick recovery from losses on the
`wireless channel in order to improve the end-to-end TCP performance. The features of MTCP can be outlined as
`follows:
`
`Elimination of IP processing: Because MTCP connection operates over a single link, there is no need for routing
`functionality provided by the IP layer. Addressing and multiplexing features of the TCP/IP stack are incorporated
`into MTCP. Note that we do not eliminate the IP layer, since it is still required for UDP and other IP-based
`protocols. However, IP processing is eliminated from protocol processing path for mobile applications that rely on
`TCP for reliable data transport. The MTCP protocol architecture is shown in Fig. 2.
`
`Fig. 2. Mobile-TCP protocol stack.
`
`Smart Mobile Technologies LLC, Exhibit 2009
`Page 6 of 22
`
`

`

`192
`
`Z.J. Haas and A. Warkhedi / The design and performance of Mobile TCP
`
`Eliminate all congestion control mechanisms: All losses over the wireless link are non-congestion related. This
`allows us to design MTCP without congestion control mechanisms. As a result, the flow control problem simply
`transforms into the problem of matching the rate of data flow with the receiver in order to prevent buffer overflow.
`A sliding-window flow control protocol is adopted to provide a simple and an efficient solution.
`Loss-less header compression: We reduce the size of packet header primarily by eliminating the IP header
`and by compressing the source and the destination IP addresses (including port numbers) into unique connection
`identifiers.
`Optimized loss recovery techniques: All packets on the wireless segment arrive in order. Our error recovery
`techniques are designed to be simple and effective in recovering from multiple packet losses. These techniques
`include selective acknowledgments (SACKs) designed for burst losses, explicit retransmission requests, and fast
`recovery from retransmission failures.
`
`We now proceed with the detailed description of MTCP design. The next few sections deal with the connec-
`tion control, flow control, and error control mechanisms of the protocol. In Section 3.7, we present some key
`implementation details of MTCP, focusing on the reduction of protocol complexity.
`
`3.2. Connection control
`
`MTCP uses a three-way handshake protocol, similar to TCP, in order to perform setup and tear down of con-
`nections. Under TCP, a host can initiate a connection with another host (called an active open) or can listen for
`and accept connections from other host (called a passive open). In the split-connection model, the Redirector on
`the basestation (BS) acts as an intermediary, coordinating connection setup between the mobile host (MH) and the
`fixed host (FH). When the MH executes an active open, it communicates to the BS the identity of the destination,
`as well as a set of parameters that will govern the operation of the connection between the MH and the BS. The MH
`conveys this information using a connection control packet shown in Fig. 3a. The BS then proceeds with setting
`up the connection with the FH using the destination IP address and port number specified by the MH. Similarly,
`when a MH executes a passive open, it informs the BS that it is prepared to accept connections. This allows the BS
`to accept or reject connection requests from FHs without communicating a priori with the MH. Similar technique
`is used at the BS for connections initiated by fixed hosts.
`A consequence of eliminating IP headers is that MTCP has to subsume IP addressing functionality into its own
`packet headers. Instead of sending the full source and destination addresses (including TCP port numbers), we use a
`simple loss-less compression technique to reduce the amount of wirelessly transmitted data. Since all packets from
`the MH travel through the BS, we fold the IP addresses and the port numbers into unique connection identifiers.
`Specifically, at the time of connection establishment, a connection ID (CID) is assigned in each direction and is
`
`Fig. 3a. Connection control packet.
`
`Fig. 3b. Data packet.
`
`Smart Mobile Technologies LLC, Exhibit 2009
`Page 7 of 22
`
`

`

`Z.J. Haas and A. Warkhedi / The design and performance of Mobile TCP
`
`193
`
`used in subsequent exchanges of data over the wireless segment. (CIDMH represents the CID from MH to BS
`and CIDMG is the CID in the reverse direction). The result is a much smaller user data packet header, as shown
`in Fig. 3b. Note that the first bit is used to distinguish between the data and the connection packet formats. MTCP
`uses the three-way handshake to establish connections and exchange unique connection identifiers between the MH
`and the BS. The bindings between CIDs and IP addresses are cached at both ends of the connection. When sending
`a packet from the mobile to the network, the destination IP address is translated into the corresponding CIDMH at
`the MH. At the BS, the CIDMH is expanded back into the destination IP address, which is used on the wireline
`segment of the connection. Similar operation is performed in the reverse direction. In practice, the Redirector,
`which sits above the transport-layer and is responsible for forwarding data from the source to the destination, only
`has to maintain a table of bindings between the MTCP and the TCP socket descriptors.
`We follow similar implementation strategies as in I-TCP to seamlessly establish an indirect connection such that
`full compatibility is ensured with the existing TCP/IP stack on the fixed host. The problem in the case of I-TCP,
`however, is that it requires applications on the mobile host to use new socket calls for the purpose of connection
`establishment. We argue that this is unnecessary in our case, since this functionality can be transparently embedded
`into MTCP. We address the issue of application re-linking on the mobile host in Section 3.6.
`
`3.3. Flow control
`
`The flow-control problem in MTCP is much simpler than the generic problem that needs to be addressed by TCP.
`Since there is no congestion on the wireless segment of the connection, flow-control in MTCP simplifies into the
`problem of matching the rate of data flow with the receiver rate to avoid buffer overflows. Thus, congestion-control
`mechanisms [7,8] that are applied to TCP flow-control can be entirely excluded from MTCP.
`Our design strategy is to develop a simple yet an efficient flow-control scheme for MTCP. Overflow of the
`receive-buffer can adversely affect performance by unnecessarily causing coarse-timeouts, wasteful retransmis-
`sions, and greater use of the CPU resources. The effects are more pronounced in the mobile environment, which is
`limited in terms of power, CPU, and bandwidth. Flow control in MTCP is achieved by using the sliding-window
`technique. The flow-control scheme is identical to the one used by TCP, except that congestion control mecha-
`nisms are not implemented. As a consequence, the flow-control window size is entirely controlled by the receiving
`end and the maximum size of the window is limited by the size of the MTCP receiver buffer. An optimal buffer
`size should be as large as the bandwidth-delay product of the connection. A buffer size that is smaller than the
`bandwidth-delay product can cause the wireless link to be underutilized, while larger than optimal size can result
`in greater buffering requirements on the link-layer protocol drivers. In multi-hop networks, large windows can also
`lead to severe congestion and traffic problems, resulting in the loss of packets. However, this does not pose a prob-
`lem in a point-to-point configuration, such as the one we are addressing here. In fact, in our experience, reasonably
`large windows significantly improve the chances of detecting packet losses without resorting to coarse timeouts.
`Nevertheless, due to the various factors involved in choosing the receive-buffer size, which are not necessarily in
`the realm of transport protocols, we have made it a configurable parameter, as in TCP. We reserve this issue of
`dynamically choosing the optimal buffer size for our future research.
`We note that the sliding-window protocol has been employed in lightweight protocols, such as eXpress Transport
`Protocol (XTP) [33], where the design of protocol features is governed by the feasibility of VLSI implementation.
`Thus, sliding-window protocol can not only be considered as an effective scheme, but also one that is of sufficiently
`low complexity.
`
`3.4. Error control
`
`Error control in TCP is implemented at the sender as well as the receiver. Specifically, the TCP receiver’s
`main objective is to perform error detection by the means of checksums and missed sequence numbers. When
`the receiver detects an error, it signals the sender of the loss using a duplicate acknowledgment (ACK). In turn,
`the sender identifies losses either by the arrival of three duplicate ACKs or by the absence of an ACK within an
`
`Smart Mobile Technologies LLC, Exhibit 2009
`Page 8 of 22
`
`

`

`194
`
`Z.J. Haas and A. Warkhedi / The design and performance of Mobile TCP
`
`Fig. 4. MTCP SACK.
`
`estimated timeout period. Upon identifying a packet loss, the TCP sender retransmits the lost packet and invokes
`various congestion control mechanisms, which throttle the transmission rate. In essence, TCP takes a conservative
`approach to loss recovery by assuming that only a single packet is lost. This technique is well suited for networks
`that experience light congestion, but too slow to recover in environments with heavy losses.
`The error-control strategy in MTCP differs from that of TCP in a few key aspects that make it far more robust
`in recovering from highly lossy conditions. These differences can be stated as the following:
`
`(1) Explicit retransmission request (RRQ) – All packets on the wireless segment arrive in order. Therefore, the
`first notification of loss in form of a duplicate ACK is sufficient for MTCP to trigger a retransmission, instead
`of waiting for three duplicates. We refer to this as explicit retransmission request, because each duplicate
`ACK unambiguously signals the loss of one or more packets.
`(2) Selective acknowledgments (SACKs) designed for burst losses – Losses on wireless links typically occur
`in bursts. MTCP adopts a simple error recovery technique based on selective acknowledgments (SACKs)
`proposed in RFC 2018 [37]. In MTCP, every duplicate ACK contains the sequence of the next in-order
`segment (NIS), which conveys the size of the burst loss to the sender. Since this information is repeated in
`every duplicate ACK, the MTCP sender obtains an accurate knowledge of burst losses even if some ACKs
`are lost. Figure 4 illustrates this technique. In this example, the receiver generates three requests for the
`retransmission of packets 2 and 3. Two of these requests are corrupted or lost. Upon receiving the third
`request, the sender retransmits packets 2 and 3. Our performance results indicate that this scheme is quite
`effective in combating burst losses.
`(3) Fast recovery from retransmission losses – Since losses are very common on the wireless segment, MTCP
`tries to take every step to quickly recover from them. The same applies to packets lost during retransmission.
`When an MTCP sender receives a request for retransmission of a packet that was just retransmitted, the
`sender is unable to resolve whether the request is for the retransmitted packet or for the previously failed
`transmission. The situation is best illustrated in Fig. 5a. The key to differentiating between the two requests
`is for the sender to somehow know that the request was in response to the retransmission. In Fig. 5a, the
`retransmission requests (RRQs – same as duplicate ACKs) triggered by packets 5 and 6 are indistinguishable
`from the RRQ triggered by packet 7. Ideally, the sender should respond with the retransmission of packet 3,
`when it gets the RRQ due to packet 7 and ignore the rest. However, the request packet does not contain
`adequate information for the sender to differentiate between the RRQs. One possible solution is to use
`SMART-style [38] sequence