Internet Engineering Task Force G. Montenegro INTERNET DRAFT Sun Microsystems, Inc. S. Dawkins Nortel August 7, 1998 Wireless Networking for the MNCRS draft-montenegro-mncrs-00.txt Status of This Memo This document is an individual submission to the Internet Engineering Task Force (IETF). Comments should be submitted to the authors. Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract In view of the unpredictable and problematic nature of wireless networks, arriving at an optimized wireless transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks. Montenegro,Dawkins Expires February 12, 1999 [Page 1] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 Table of Contents 1 Introduction .................................................... 3 1.1 Architecture ............................................... 5 1.2 Assumptions about the Radio Link ........................... 6 2 Should it be IP or Not? ........................................ 7 2.1 Underlying Network Error Characteristics ................... 7 2.2 Non-IP Alternatives ........................................ 8 2.2.1 WAP ................................................... 8 2.2.2 MOWGLI ................................................ 9 2.2.3 Deploying Non-IP Alternatives ......................... 9 2.3 IP-based Alternatives ...................................... 9 2.3.1 Path MTU Discovery .................................... 9 2.3.2 Non-TCP Proposals ..................................... 10 3 TCP or Not ...................................................... 10 4 Optimizing TCP .................................................. 11 4.1 TCP: Current Mechanisms .................................... 11 4.1.1 Slow Start and Congestion Avoidance ................... 11 4.1.2 Fast Retransmit and Fast Recovery ..................... 12 4.2 Connection Setup with T/TCP [RFC1397, RFC1644] ............. 12 4.3 Slow Start Proposals ....................................... 13 4.3.1 Larger Initial Window ................................. 13 4.3.2 Handling Acknowledgments During Slow Start ............ 13 4.3.3 Terminating Slow Start ................................ 14 4.4 ACK Spacing ................................................ 14 4.5 Delayed Duplicate Acknowlegements .......................... 14 4.6 Selective Acknowledgements [RFC2018] ....................... 14 4.7 Detecting Corruption Loss .................................. 15 4.7.1 Without Explicit Notification ......................... 15 4.7.2 With Explicit Notification ............................ 15 4.8 Active Queue Management .................................... 15 4.9 Scheduling Algorithms ...................................... 16 4.10 Spoofing, Split TCP and Performance-Enhancing Proxies (PEPs) ............................................................ 17 4.11 Header Compression Alternatives ........................... 19 4.12 IP Payload Compression .................................... 19 5 Candidate TCP Optimizations for MNCRS Devices ................... 20 6 Conclusion ...................................................... 25 7 Acknowledgements ................................................ 25 8 References ...................................................... 25 Author address .................................................... 30 Montenegro,Dawkins Expires February 12, 1999 [Page 2] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 1 Introduction Optimized wireless networking is one of the major hurdles that Mobile Computing must solve if it is to enable ubiquitous access to networking resources. However, current data networking protocols have been optimized primarily for wired networks. Wireless environments have very different characteristics in terms of latency, jitter, and error rate as compared to wired networks. Accordingly, traditional protocols are ill-suited to this medium. Mobile Wireless networks can be grouped in W-LANs (for example, 802.11 compliant networks) and W-WANs (for example, CDPD, Ricochet, CDMA, PHS, DoCoMo, GSM to name a few). W-WANs present the most serious challenge given that the length of the wireless link (expressed as the delay*bandwidth product) is typically 4 to 5 times as long as that of its W-LAN counterparts. For example, for an 802.11 network, assuming the delay (round-trip time) is about 2 ms. and the bandwidth is 1 Mbps, the delay*bandwidth product is 2000 bits. For a W-WAN such as Ricochet, a typical round-trip time may be around 500 ms. (the best is about 230 ms.), and the bandwidth is about 20 Kbps. This yields a delay*bandwidth product roughly equal to 10000 bits. This value is larger than the default 8KB buffer space used by many TCP implementations. This means that, whereas for W-LANs the default buffer space is enough, W-WANs will operate inefficiently (that is, they will not be able to fill the pipe) unless they override the default value. Most importantly, latency across a link adversely affects throughput. For example, [MSMO97] derives an upper bound on TCP throughput. Indeed, the resultant expression is inversely related to the round-trip time. The long latencies also push the limits (and commonly transgress them) for what is acceptable to users of interactive applications. As a quick glance to our list of references will reveal, there is a wealth of proposals that attempt to solve the wireless networking problem. In this document, we survey the different solutions available or under investigation, and issue the corresponding recommendations. The subsequent sections include solutions: - unrelated to IP - built on top of IP Montenegro,Dawkins Expires February 12, 1999 [Page 3] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 - built on top of UDP - built on top of TCP (modifying TCP) There is a large body of work on the subject of improving TCP performance over satellite links. The documents that the tcpsat working group of the IETF is working on [AG98, AGGHSSTT98] are very relevant. In both cases, it is essential to start by improving the characteristics of the medium by using forward error correction (FEC) at the link layer to reduce the BER (bit error rate) from values as high as 10-3 to 10-6 or better. This makes the BER manageable. Once in this realm, retransmissions schemes (ARQ) may be used to bring it down to zero. Notice that sometimes it may be desireable to forgo ARQ because of the additional delay it implies. In particular, time sensitive traffic (video, audio) must be delivered within a certain time limit beyond which the data is obsolete. Exhaustive retransmissions in this case merely succeed in wasting time in order to deliver data that will be discarded once it arrives at its destination. This points at the desireability of augmenting the protocol stack implementation on devices such that the upper protocol layers can inform the lower link and MAC layer when to avoid such costly retransmission schemes. Networks that include satellite links are examples of "long fat networks" (LFNs or "elephants"). They are "long" networks because their round-trip time is quite high (for example, 0.5 sec and higher for geosynchronous satellites). Not all satellite links fall within the LFN regime. In particular, round-trip times in a low-earth orbiting (LEO) satellite network may be as little as a few milliseconds (and never extend beyond 160 to 200 ms). W-WANs share the "L" with LFNs. However, satellite networks are also "fat". In the sense that they may have high bandwidth. Satellite networks may often have a delay*bandwidth product above 64 KBytes, in which case they pose additional problems to TCP [TCPHP]. W-WANs do not generally exhibit this behavior. Accordingly, this document only deals with wireless links that are "long, thin pipes", and the networks that contain them: "long, thin networks". We call these "LTNs". Strictly speaking, LTNs do not necessarily imply wireless. However, in this document, the term LTN is used as a synonym of "long, thin wireless networks". This document does not give an overview of the API used to access the underlying transport. We believe this is an orthogonal issue, even though some of the proposals below have been put forth assuming a given interface. Nevertheless, it is possible, for example, to support the traditional socket semantics without Montenegro,Dawkins Expires February 12, 1999 [Page 4] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 relying on an underlying IP network [MOWGLI]. Our focus is on the on-the-wire protocols. We try to include the most relevant ones and briefly (given that we provide the references needed for further study) mention their most salient points. Our objective is to specify a collection of mechanisms for implementation by MNCRS devices. Given that the MNCRS is an industry consortium, the primary concern is that the recommendations be practical, well understood, that they limit modifications to only those devices under MNCRS control (mobile devices and the base station or proxy), that they cover the most common cases, and, most importantly, that they (at least an effective subset) be deployable within the near term (6 months or so). 1.1 Architecture Given our focus on mobile wireless applications, we only consider a very specific architecture that includes: - a wireless mobile device, connected via - a wireless link (which may, in fact comprise several hops at the link layer), to - a base station (sometimes referred to as an intermediate agent) connected via - a wireline link, which in turn interfaces with - the landline internet and millions of legacy servers and web sites. Specifically, we are not as concerned with paths that include two wireless segments separated by a wired one. This may occur, for example, if one mobile device connects across its immediate wireless segment via a base station to the internet, and then via a second wireless segment to another mobile device. Most often, mobile devices connect to a legacy server on the wired internet. Typically, the endpoints of the wireless segment are the base station and the mobile device. However, the latter may be a wireless router to a mobile network. This is also important and has applications in, for example, disaster recovery. Our target architecture has implications which concern the deployability of candidate solutions. In particular, an important Montenegro,Dawkins Expires February 12, 1999 [Page 5] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 requirement is that we cannot alter the networking stack on the legacy servers. It would be preferrable to only change the networking stack at the base station, although changing it at the mobile devices is certainly an option and perhaps a necessity. We envision mobile devices that can use the wireless medium very efficiently, but are not constrained by it. That is, full mobility implies that the devices have the flexibility and agility to use whichever happens to be the best network connection available at any given point in time or space. Accordingly, devices could switch from a wired office LAN and hand over their ongoing connections to continue on, say, a wireless WAN. (This type of agility also requires Mobile IP [RFC2002].) 1.2 Assumptions about the Radio Link The system architecture described above assumes at most one wireless link (perhaps comprising more than one wireless hop). However, this is not enough to characterize a wireless link. Given that this has Additional considerations are: - What are the error characteristics of the wireless medium? The link may present a higher BER than a wireline network in the form of random errors. It may also have burst errors and disconnections. The techniques below usually do not address all the issues. Accordingly, a complete solution should combine the best of all the proposals. Nevertheless, in this document we are more concerned with, and give preference to solving the most typical case: higher BER due to random errors (and higher delays due to link-layer error corrections and retransmissions) rather than an interruption in service due to a handoff or a disconnection. Nevertheless, these are also important and we do include relevant proposals in this survey. - Is the wireless service datagram oriented, or is it a virtual circuit? Currently, switched virtual circuits are more common, but packet networks are starting to appear (for example, Metricom's Starmode [CB96], CDPD, and in the future, GSM's GPRS. - What kind of reliability does the link provide? Wireless services typically retransmit a packet until it has been acknowledged by the target. They may allow the user to turn off this behavior. For example, GSM allows RLP (Reliable Link Protocol) to be turned off. Metricom has a similar "lightweight" mode. Montenegro,Dawkins Expires February 12, 1999 [Page 6] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 - Does the mobile device transmit and receive at the same time? Doing so increases the cost of the electronics on the mobile device. Typically, this is not the case. We assume so in this document. - Does the mobile device directly address more than one peer on the wireless link? Packets to each different peer traverse spatially distinct wireless paths. Accordingly, the path to each peer may exhibit very different characteristics. Quite commonly, the mobile device addresses only one peer (the base station) at any given point in time. When this is not the case, techniques such as Channel-State Dependent Packet Scheduling come into play (see the section "Packet Scheduling" below). 2 Should it be IP or Not? The first decision is whether to use IP as the underlying network protocol or not. In particular, some data protocols evolved from wireless telephony are not layered on top of IP [MOWGLI, WAP]. This might make sense if the mobile device is guaranteed to talk always through the base station. However, we expect many wireless mobile devices to utilize wireline networks when they are available. This model closely follows current laptop usage patterns, where devices utilize dial-up access when "out of the office", but utilize LANs when they are available. For these devices, an architecture that assumes IP is the best approach, because it will be required for communications that do not traverse the base station (for example, upon reconnection to a W-LAN or a 10BaseT network at the office). 2.1 Underlying Network Error Characteristics The decision to use IP as the underlying network protocol implies a certain (low) level of link robustness that is expected of wireless links. IP, and the protocols that are carried in IP packets, are protected end-to-end by checksums that are relatively weak (and, in some cases, optional). For much of the internet, these checksums are sufficient; in wireless environments, the error characteristics of the raw wireless link are much less robust than the rest of the end-to-end path. This makes end-to-end detection of network errors undesirable, because damaged IP packets are Montenegro,Dawkins Expires February 12, 1999 [Page 7] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 propagated through the network only to be discarded at the destination host, and suggests that link-level mechanisms should be used to detect and correct transmission errors over these links. The right approach is to use link-layer mechanisms such as FEC, retransmissions, and so on in order to improve the characteristics of the wireless link and present a much more reliable service to IP. This approach has been taken by CDPD, Ricochet and CDMA. This approach is roughly analogous to the successful deployment of Point-to-Point Protocol (PPP), with robust framing and 16-bit checksumming, on wireline networks as a replacement for the Serial Line Interface Protocol (SLIP), with only a single framing byte and no checksumming. Notice that the link-layer could adapt its frame size to the prevalent BER. It would perform its own fragmentation and reassembly so that IP could still enjoy a large enough MTU size [LS98]. A common concern for using IP as a transport is the header overhead it implies. Typically, the underlying link-layer appears as PPP [RFC1661] to the IP layer above. This allows for header compression schemes [IPHC, IPHC-PPP] which greatly alleviate the problem. 2.2 Non-IP Alternatives A number of non-IP alternatives aimed at wireless environments have been proposed. Two representative proposals are discussed here. 2.2.1 WAP WAP [WAP] is an architecture designed by and primarily oriented towards data-enabled wireless telephony devices. Instead of IP or HTTP, WAP has alternate optimized protocols and relies on the base station or intermediate agent to provide the impedance matching with the internet. It currently seems to be tied primarily to GSM, even though there is an intent to specify its operation over other technologies such as CDMA, CDPD and US-TDMA). Since, it requires the use of a WAP proxy, if the device switches to a legacy lan (for example, on 10BaseT) and connects directly to a legacy server, it would have to do so over TCP/IP. Montenegro,Dawkins Expires February 12, 1999 [Page 8] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 2.2.2 MOWGLI MOWGLI [MOWGLI] was an earlier research project, aimed at higher-end devices than WAP targets. (The "MOW" in MOWGLI stands for "Mobile Office Workstations".) MOWGLI also specifies its own underlying transport, but it does seek to preserve the socket semantics. 2.2.3 Deploying Non-IP Alternatives IP is such a fundamental element of the internet that non-IP alternatives face substantial obstacles to deployment, because they do not exploit the IP infrastructure. Any non-IP alternative that is used to provide gatewayed access to the internet must map between IP addresses and non-IP addresses, must terminate IP-level security at a gateway, and cannot use IP-oriented discovery protocols (Dynamic Host Configuration Protocol, Domain Name Services, Lightweight Directory Access Protocol, etc.) without translation at a gateway. Non-IP alternatives face the burden of proof that IP is so ill-suited to a wireless environment that it is not a viable technology. 2.3 IP-based Alternatives Given its worldwide deployment, IP is an obvious choice for the underlying network technology. Optimizations implemented at this level benefit traditional internet application protocols as well as new ones layered on top of IP or UDP. 2.3.1 Path MTU Discovery Path MTU discovery benefits any protocol built on top of IP. It allows a sender to determine what the maximum end-to-end transmission unit is to a given destination. Withouth Path MTU discovery, the default MTU size is 512. The benefits of using a larger MTU are: - Smaller ratio of header overhead to data - Allows TCP to grow its congestion window faster, since it increases in units of segments. Of course, for a given BER, a larger MTU has a correspondingly Montenegro,Dawkins Expires February 12, 1999 [Page 9] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 larger probability of error within any given segment. The BER may be reduced using lower level techniques like FEC and link-layer retransmissions. The issue is that now delays may become a problem due to the additional retransmissions, and the fact that packet transmission time increases with a larger MTU. 2.3.2 Non-TCP Proposals Other proposals assume an underlying IP datagram service, and implement an optimized transport either directly on top of IP [NETBLT] or on top of UDP [MNCP]. Not relying on TCP is a bold move, given the wealth of experience and research related to it. It could be argued that the internet has not collapsed because its main protocol, TCP, is very careful in how it uses the network, and generally treats it as a black box assuming all packet losses are due to congestion and prudently backing off. This avoids further congestion. However, in the wireless medium, packet losses may also be due to corruption due to high BER, fading, and so on. Here, the right approach is to try harder, instead of backing off. Alternative transport protocols are: - NETBLT [NETBLT, RFC1986, RFC1030] - MNCP [MNCP] - ESRO [RFC2188] - RDP [RFC908, RFC1151] - VMTP [VMTP] 3 TCP or Not This is one of the most hotly debated issues in the wireless arena. Here are some arguments against it: - It is generally recognized that TCP does not perform well in the presence of significant levels of non-congestion loss. TCP detractors argue that the wireless medium is one such case, and that it is hard enough to fix TCP. They argue that it is easier to start from scratch. - TCP has too much header overhead. Montenegro,Dawkins Expires February 12, 1999 [Page 10] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 - By the time the mechanisms are in place to fix it, TCP is very heavy, and ill-suited for use by lightweight, portable devices. and here are some in support of TCP: - It is preferrable to continue using the same protocol that the rest of the Internet uses because of compatibility reasons. Any extensions specific to the wireless link may be negotiated. - Legacy mechanisms may be reused (for example congestion control) - Link-layer FEC and ARQ can reduce the BER such that any losses TCP does see are, in fact, caused by congestion. Modern W-WAN technologies do this (CDPD, US-TDMA, CDMA, GSM), thus improving TCP throughput. - Handoffs among different technologies are made possible by Mobile IP [RFC2002], but only if the same protocols, namely TCP/IP, are used throughout. - Given TCP's wealth of research and experience, alternative protocols are relatively immature, and the full implications of their widespread deployment, not clearly understood. 4 Optimizing TCP There is a large volume of work on the subject of optimizing TCP for operation over wireless media. Even though satellite networks generally fall in the LFN regime, our current LTN focus has much to benefit from it. For example, the work of the TCP-over-Satellite working group of the IETF has been extremely helpful in preparing this section [AG98, AGGHSSTT98]. 4.1 TCP: Current Mechanisms A TCP sender adapts its use of bandwidth based on feedback from the receiver. The high latency characteristic of LTNs implies that adaptation is correspondingly slower. 4.1.1 Slow Start and Congestion Avoidance Slow Start and Congestion Avoidance [RFC2001] are the basis for Montenegro,Dawkins Expires February 12, 1999 [Page 11] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 TCP's successful deployment throughout the internet. However there are two reasons why the wireless medium adversely affects them: - Slow start is invoked whenever a loss is detected, assuming the network is congested. This is why it is important to minimize the losses caused by corruption, leaving only those that TCP expects. - The sender increases its window based on the number of ACKs received. This rate, of course, is dependent on the RTT (round-trip-time) between sender and receiver, which implies long delays in high latency links like LTNs. - During slow start, the sender increases its window in units of segments. This is why it is important to use an appropriately large MTU. 4.1.2 Fast Retransmit and Fast Recovery Fast retransmit [RFC2001] allows the receiver to inform the sender (by sending several duplicate ACKs) of a lost segment. The sender retransmits what it considers to be this lost segment without waiting for the full timeout. This saves time. After a fast retransmit, a sender invokes the fast recovery [RFC2001] algorithm, whereby it invokes congestion avoidance, but not slow start. This also saves time. 4.2 Connection Setup with T/TCP [RFC1397, RFC1644] TCP engages in a "three-way handshake" whenever a new connection is set up. Data transfer is only possible after this phase has completed successfuly. T/TCP allows data to be exchanged in parallel with the connection set up, saving valuable time for long delay networks. T/TCP clearly has benefits in some environments. We believe T/TCP would not provide significant benefits in the environments we are designing for because: - Bypassing the TCP three-way handshake is only possible after the first time a client host has connected to a server host. - If the applications running on the mobile host are HTTP-based, many of the benefits of T/TCP are also available in HTTP/1.1 with persistent connections. Montenegro,Dawkins Expires February 12, 1999 [Page 12] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 4.3 Slow Start Proposals Because slow start dominates the network response seen by interactive users at the beginning of a TCP connection, a number of proposals have been made to modify or or eliminate slow start in long latency environments. Stability of the internet is paramount, so these proposals must demonstrate that they will not adversely affect internet congestion levels in significant ways. The needs of the many outweigh the needs of the few. 4.3.1 Larger Initial Window Full slow start, with an initial window of one segment, is a time-consuming bandwidth adaptation procedure over LTNs. Recent proposals suggest starting off with an initial window larger than one segment [FAP98, SP97, AHO98]. In current simulations with an initial window of two segments, this proposal does not contribute significantly to packet drop rates, and it has the added benefit of improving initial response times when the peer device delays acknowledgements during slow start (see next proposal). We expect the IETF tcp-impl working group to recommend allowing an initial window of at least two segments, and perhaps as many as four, in the near future, in environments where this significantly improves performance (LFNs and LTNs). 4.3.2 Handling Acknowledgments During Slow Start The sender increases its window based on the flow of ACKs coming back from the receiver. Particularly during slow- start, this flow is very important. A couple of the proposals that have been studied are [Allman98]: - Make each ACK count to its fullest by growing the window based on the data being acknowledged (byte counting) instead of the number of ACKs (ACK counting). This has been shown to cause bursts which lead to congestion. [Allman98] shows that Limited Byte Counting (LBC), in which the window growth is limited to 2 segments, does not lead to burstiness, and offers some performance gains. - Keep a constant stream of ACKs coming back by turning off Montenegro,Dawkins Expires February 12, 1999 [Page 13] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 delayed ACKs [RFC1122], at least during slow-start. 4.3.3 Terminating Slow Start New mechanisms [AGGHSSTT98] are being proposed to improve TCP's adaptive properties such that the available bandwidth is better utilized and at the same time reducing the possibility of congesting the network. The latter leads to the closing of the congestion window to 1 segment, and the subsequent slow-start phase. 4.4 ACK Spacing During slow-start, the sender responds to the incoming ACK stream by transmitting two new segment for each ACK received. This results in data being sent at twice the speed at which it can be processed by the network. Accordingly, queues will form, and due to lack of sufficient buffering at the bottleneck router, packets may get dropped before the link's capacity is full. Spacing out the ACKs effectively controls the rate at which the sender will transmit into the network, and may result in little or no queueing at the bottleneck router [ACKSPACING]. 4.5 Delayed Duplicate Acknowlegements As was mentioned above, link-layer retransmissions may raise the BER such that congestion accounts for most of the packet losses (still, nothing can be done about interruptions due to handoffs, moving beyond wireless coverage, etc). In this scenario, it is imperative to prevent interaction between link-layer retransmission and TCP retransmission as these layers duplicate each other's efforts. In such an environment it may make sense to delay TCP's efforts so as to give the link-layer a chance to recover [MV97]. It is preferrable to allow a local mechanism to resolve a local problem, instead of invoking TCP's end-to-end mechanism and incurring the associated costs, both in terms of wasted bandwidth and in terms of its effect on TCP's window. 4.6 Selective Acknowledgements [RFC2018] The applicability of SACK is suspect, according to Section 1.1 of [TCPHP]. In particular, SACK may be useful in the LFN regime, specially if large windows are being used, because there is a considerable probability of multiple segment losses per window. In Montenegro,Dawkins Expires February 12, 1999 [Page 14] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 the LTN regime, windows are not larger than the usual, and single-segment losses will be, by far, the most common. Accordingly, the complexity of SACK may not be justifiable, unless there is a high probability of burst errors and congestion on the wireless link. Berkeley's Snoop protocol research [SNOOP] indicates that SACK does improve throughput for Snoop when multiple segments are lost per window [BPSK96]. 4.7 Detecting Corruption Loss 4.7.1 Without Explicit Notification In the absence of explicit notification from the network, some researchers have suggested statistical methods for congestion avoidance [Jain89, WC91, VEGAS]. A natural extension of these heuristics would enable a sender to distinguish between losses caused by congestion and other causes. Unfortunately, it does not seem like these sender-based heuristics are at all reliable [BV97, BV98]. Fortunately, under selected conditions recent results using packet inter-arrival times measured at the receiver are encouraging [BV98a]. 4.7.2 With Explicit Notification Explicit notification from the network can make it very easy to determine when a loss is not due to congestion, so as to avoid invoking TCP's costly recovery mechanism. Several proposals along these lines include: - ELN [BPSK96] - EBSN [BBKVP96] - ELNR, and EDDAN (notifications to mobile receiver) [MV97] - ECN [ECN] 4.8 Active Queue Management As has been pointed out above, TCP responds to congestion by Montenegro,Dawkins Expires February 12, 1999 [Page 15] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 closing down the window and invoking slow-start. Long-delay networks take a particularly long time to recover from this condition. Accordingly, it is imperative to avoid congestion in LTNs. To remedy this, active queue management techniques have been proposed as enhancements to routers throughout the Internet [RED]. The primary motivation for deployment of these mechanisms is to prevent "congestion collapse" (a severe degradation in service) by controlling the average queue size at the routers. As the average queue length grows, Random Early Detection [RED] increases the possibility of dropping packets. The benefits are: - Reduce packet drops in routers. By dropping a few packets before severe congestion sets in, RED avoids dropping bursts of packets. - Provide lower delays. This follows from the smaller queue sizes, and is particularly important for interactive applications, for which the inherent delays of wireless links already push the user experience to the limits of the non-acceptable. - Avoid lock-outs. Packets from over-agressive flows can get dropped with the same probability as other packets. 4.9 Scheduling Algorithms Active queue management helps control the length of the queues. Additionally, a general solution requires replacing FIFO with other scheduling algorithms that improve: 1. Fairness (by policing how different packet streams utilize the available bandwidth), and 2. Throughput (by improving the transmitter's radio channel utilization). For example, fairness is necessary for interactive applications (like telnet or web browsing) to coexist with bulk transfer sessions. Proposals here include: - Fair Queueing (FQ) [Demers90] - Class-based Queueing (CBQ) [Floyd95] These proposals may be attractive in wireless LTN environments, Montenegro,Dawkins Expires February 12, 1999 [Page 16] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 even if they are only implemented over the wireless link portion of the communication path, because new connections for interactive applications can have difficulty starting when a bulk TCP transfer has already stabilized using all available bandwidth. In our base architecture described above, the mobile device typically communicates directly with only one wireless peer at a given time: the base station. However, it is possible to directly address other mobiles within the same cell. Direct communication with each such wireless peer traverses a spatially distinct path, each of which exhibits statistically independent radio link characteristics. Channel State Dependent Packet Scheduling (CSDP) [BBKT96] tracks the state of the various radio links (as defined by the target devices), and gives preferential treatment to packets destined for radio links in a "good" state. This avoids attempting to transmit to (and to elicit acknowledgements from) a peer on a "bad" radio link, thus improving throughput. A further refinement of this idea suggests that both fairness and throughput can be achieved by combining a wireless-enhanced CBQ with CSDP [FSS98]. 4.10 Spoofing, Split TCP and Performance-Enhancing Proxies (PEPs) Given the dramatic differences between the wired and the wireless links, a very common approach is to provide some impedance matching where the two different technologies meet: at the base station. The idea is to replace an end-to-end TCP connection with two clearly distinct connections: one across the wireless link, the other across its wireline counterpart. Each of the two resulting TCP sessions operates under very different networking characteristics, and may adopt the policies best suited to its particular medium. For example, in an extreme case it may be desirable to turn off Fast Retransmission and Fast Recovery only on the wireless TCP link, because on this portion of the connection path, losses may be caused almost exclusively by corruption instead of congestion. Spoofing proposals include schemes like I-TCP [ITCP] which achieves performance improvements by relinquishing end-to-end semantics. [MTCP] alleviates this problem somewhat, but does not entirely solve it. Berkeley's Snoop protocol [SNOOP] is a hybrid scheme mixing link-layer reliability mechanisms with the split connection Montenegro,Dawkins Expires February 12, 1999 [Page 17] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 approach. It is an improvement over I-TCP in that end-to-end semantics are retained as well as in terms of performance. Snoop does two things: 1. Locally (on the wireless link) retransmit lost packets, instead of allowing TCP to do so end-to-end. 2. Suppress the duplicate acks on their way from the receiver back to the sender, thus avoiding fast retransmit and congestion avoidance at the latter. WTCP [WTCP] is similar to Snoop in that it preserves end-to-end semantics. In WTCP, the base station uses a complex scheme to hide the time it spends moving packets across the wireless link (this typically includes retransmissions due to error recovery, but may also include time spent dealing with congestion). In order to work effectively, it assumes that the TCP endpoints implement the Timestamps option in RFC 1323 [TCPHP]. Unfortunately, support for RFC 1323 in TCP implementations is not yet widespread. Beyond this, WTCP requires changes only at the base station. All of these schemes require the base station to examine and operate on the traffic between the portable wireless device and the TCP server on the wired Internet. None of these work if the IP traffic is encrypted, unless, of course, the base station is privy to the security association between the mobile device and its end-to-end peer. They also require that both the data and the corresponding ACKs traverse the same base station. Furthermore, if the base station retransmits packets at the transport layer across the wireless link, this may duplicate efforts by the link-layer. Snoop has been described by its designers as a TCP-aware link-layer. This is the right approach: layers 2 and 3 should be integrated much more tightly than traditional OSI layering suggests. Often, in addition to the PEP mechanism at the base station, a custom protocol is used on the wireless link (for example, [WAP] or [MOWGLI]). However, there is evidence that the performance gains are due to the fact that a proxy serves as a coupling device between the wireless and wireline worlds, and that using a custom protocol on the wireless link only affords limited benefits [YB94]. Even if the gains were moderate or better, the wealth of research on optimizing TCP for wireless, and compatibility with the Internet are overwhelmingly compelling reasons to adopt TCP on the wireless link (of course, enhanced as suggested in section 5 below). Montenegro,Dawkins Expires February 12, 1999 [Page 18] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 4.11 Header Compression Alternatives Because Long Thin Networks are bandwidth-constrained, every byte that can be compressed out of over-the-air segments is worth compressing. Van Jacobson header compression [RFC1144] describes a Proposed Standard for TCP Header compression that is widely deployed. Mechanisms for TCP and IP header compression defined in [IPHC, IPHC-PPP] provide the following benefits: - Improve interactive response time - Allow using small packets for bulk data with good line efficiency - Allow using small packets for delay sensitive low data-rate traffic - Decrease header overhead (for the smallest MTU of 512 the header overhead of TCP over IP falls from 11.7 to less than 1 per cent. - Reduce packet loss rate over lossy links. 4.12 IP Payload Compression Compression of IP segment payloads is also desirable. "IP Payload Compression Protocol (IPComp)" [IPCOMP] defines a framework where common compression algorithms can be applied to arbitrary IP segment payloads. IP payload compression is something of a niche optimization. It is necessary because IP-level security converts IP payloads to random bitstreams, defeating commonly-deployed link-layer compression mechanisms which are faced with payloads that have no redundant "information" that can be more compactly represented. However, many IP payloads are already compressed (images, audio, video, "zipped" files being FTPed), or are already encrypted above the IP layer (SSL/TLS, etc.). These payloads will not "compress" further, limiting the benefit of this optimization. For now, IPCOMP compression of HTML and MIME headers is an obvious benefit. Montenegro,Dawkins Expires February 12, 1999 [Page 19] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 5 Candidate TCP Optimizations for MNCRS Devices The table below summarizes our recommendations with regards to the main proposals mentioned above. The first column, "Stability of the Proposal", refers to the maturity of the mechanism in question. Some proposals are being pursued within the IETF in a somewhat open fashion. IETF proposals are either Drafts (preliminary versions) or RFCs. There are several types of RFCs. Proposed Standards (PS) are standards track, and carry more weight than Informational. Other proposals are isolated efforts with little or no public review, and little chance of garnering industry backing. "Implemented at" gives an indication of which participant in a TCP session must be modified to implement the proposal. Of course, legacy servers cannot be modified, so this column merely indicates whether implementation happens at either or both of the two nodes under MNCRS control: mobile device and base station. The symbols used are: WS (wireless sender, that is, the mobile device's TCP send operation must be modified), WR (wireless receiver, that is, the mobile device's TCP receive operation must be modified), WD (wireless device, that is, modifications at the mobile device are not specific to either TCP send or receive), BS (base station) and NI (network infrastructure). The End-to-end IPSec column indicates if a given mechanism works in the presence of IPSec encrypted traffic between the mobile device and the server. MNCRS Adoption captures the MNCRS recommendation. Some mechanisms are endorsed for immediate adoption, others need more evidence and research, and others are discarded. Montenegro,Dawkins Expires February 12, 1999 [Page 20] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 Name Stability of Implemented MNCRS Adoption the Proposal at ==================== ============= =========== ================= Increased Initial IETF Draft WS Yes Congestion Window (initial_window=2) Disable delayed ACKs NA WR When stable during slow-start Byte counting NA WS No instead of ACK counting TCP Header RFC 1144 (PS) WD Yes compression for PPP BS IP Payload IETF Draft WD Yes Compression (Approved as (simultaneously PS) needed on Server) IP Header IETF Draft WD Mobile IP only Compression BS (includes IP-IP) for PPP Snoop plus SACK In limited use BS Yes WD (for SACK) Fast retransmit/fast RFC 2001 (PS) WD Yes (should be recovery there already) Transaction/TCP RFC 1644 WD No (Experimental) (simultaneously needed on Server) Estimating Slow NA WS No Start Threshold (ssthresh) Delayed Duplicate Not stable WR When stable Acknowledgements BS (for notifications) Class-based Queuing NA WD When stable on End Systems Montenegro,Dawkins Expires February 12, 1999 [Page 21] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 Explicit Congestion IETF Draft WD When stable Notification NI Of all the candidate optimizations in the table above, only Snoop plus SACK and Delayed duplicate acknowledgements are currently being proposed only for wireless networks. The others are being considered even for non-wireless applications. Their more general applicability has the benefit of drawing more attention and analysis from the research community. Of the above mechanisms, only Header Compression (for IP and TCP) and "Snoop plus SACK" cease to work in the presence of IPSec. Increased Initial Congestion Window Implement this on MNCRS devices now. The research on this optimization indicates that 2 is a safe initial setting and is centering on choosing between 2, 3, and 4. For now, use 2, which at least allows clients running query-response applications to get an initial ACK from unmodified servers without waiting for a delayed ACK timeout of 200-500 milliseconds. Many of the benefits of this optimization are also available (after the first request-response exchange) when clients and servers both implement HTTP/1.1. This optimization works with older servers that implement only HTTP/1.0. Disable delayed ACKs during slow start Implement this on MNCRS pending further investigation. Even though simulations confirm its promise (it allows receivers to get the second segment from unmodified senders without waiting for a delayed ACK timeout of 200-500 milliseconds), for this technique to be practical the receiver must acknowledge every segment only when the sender is in slow-start. Continuing to do so when the sender is in congestion avoidance may have adverse effects on the mobile device's battery consumption and on traffic in the network. For now, the recommendation is to conservative ACK only the first segment on a new connection with no delay. Again, many of the benefits of this optimization are also available after the first request-response exchange when clients and servers both implement HTTP/1.1. This optimization works with older servers that implement only HTTP/1.0. Montenegro,Dawkins Expires February 12, 1999 [Page 22] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 Byte Counting instead of ACK Counting Unlimited byte counting is not recommended. In http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt, Van Jacobson says that byte counting is a bad thing because it leads to burstiness, and recommends ACK spacing instead. Limited byte counting warrants further investigation before deciding, but it shows promise. TCP Header Compression for PPP Implement this on MNCRS devices now. It is a widely-implemented Proposed Standard. IP Payload Compression Recommended, as the IETF has approved it as a proposed standard. Notes on this optimization: - Some payloads are already compressed, and won't be compressed further (JPEG, GIF). - Payloads must be compressed before encryption (encrypted payloads won't compress). - HTTP-NG is considering supporting compression of resources at the HTTP level, which would provide the same benefits for common compressible MIME types like text/html. IP Header Compression (includes IP-IP) for PPP Implement this on MNCRS devices when the Internet-Draft becomes stable. SNOOP plus SACK Implement this on MNCRS-capable base stations now. Research results are encouraging, and it's an "invisible" optimization - neither the client nor the server needs to change, only the base station (for base SNOOP). SNOOP benefits from selective acknowledgements in order to recover from multi-segment losses in one round-trip. In this Montenegro,Dawkins Expires February 12, 1999 [Page 23] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 case, the mobile device needs to implement some form of selective acknowledgements. If selective acknowledgments are not used, recovery from multi-segment losses takes so long that TCP enters congestion avoidance anyway. Encryption of IP packets via IPSEC's ESP header (in either transport or tunnel mode) renders the TCP header and payload unintelligible to the base station. This precludes SNOOP from working, because it needs to examine the TCP headers in both directions. Possible solutions involve: - making the SNOOPing base station a party to the security association between the client and the server - IPSEC tunneling mode, terminated at the SNOOPing base station - and so on. However, at this time these are not well understood so MNCRS users valuing both privacy and performance should use SSL or SOCKS for end-to-end security. Fast Retransmit/Fast Recovery Implement on MNCRS devices at this time. It is a widely-implemented optimization and is currently at Proposed Standard level. Transaction TCP (T/TCP) Not recommended at this time, for these reasons: - It's an Experimental RFC, and has not been advanced. - It's not widely deployed, and it has to be deployed at both ends of a connection. - At least some of the benefits of T/TCP (eliminating three-way handshake on subsequent query-response transactions, for instance) are also available with persistent connections on HTTP/1.1, which is more widely deployed. Estimating Slow Start Threshold (ssthresh) Not recommended. Montenegro,Dawkins Expires February 12, 1999 [Page 24] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 Rough consensus on the tcp-impl and tcp-sat mailing lists is that there is no good way to probe during TCP startup and estimate bandwidth available. Delayed Duplicate Acknowledgements Recommended, pending further research and experience. Class-based queuing on end systems No recommendation at this time. Explicit Notifications No recommendation at this time. Schemes like ELNR and EDDAN [MV97], in which the only systems that need to be modified are the base station and the mobile device are slated for adoption pending further research. However, the requirement that the base station be able to examine the TCP headers flying through it poses the previously stated issues with respect to IPSEC-encrypted packets. ECN is slated for adoption when and if the IETF finalizes the specification. 6 Conclusion In view of the unpredictable and problematic nature of wireless networks, arriving at an optimized wireless transport is a daunting task. We have reviewed the existing proposals along with future research items. Based on this overview, we also recommend mechanisms for implementation in long thin networks. 7 Acknowledgements The authors are deeply indebted to the IETF tcpsat and tcpimpl working groups, and to Prof. Nitin Vaidya (Texas A&M) whose many insightful comments have proved invaluable in our attempt at improving this note. The following individuals have also provided valuable feedback: Mark Allman (NASA), Raphi Rom (Technion/Sun). 8 References [ACKSPACING] Partridge, C., "ACK Spacing for High Delay-Bandwidth Paths with Insufficient Buffering," July 1997. Internet-Draft Montenegro,Dawkins Expires February 12, 1999 [Page 25] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 draft-partridge-e2e-ackspacing-00.txt (work in progress). [AG98] Mark Allman, Dan Glover. Enhancing TCP Over Satellite Channels using Standard Mechanisms, May 1998. Internet-Draft draft-ietf-tcpsat-stand-mech-04.txt (work in progress). [AGGHSSTT98] Mark Allman, Dan Glover, Jim Griner, John Heidemann, Keith Scott, Jeffrey Semke, Joe Touch, Diepchi Tran. Ongoing TCP Research Related to Satellites, May 1998. Internet-Draft draft-ietf-tcpsat-res-issues-03.txt (work in progress). [Allman98] Allman, M., "On the Generation and Use of TCP Acknowledgments," July, 1998. Submitted to ACM Computer Communication Review. [AHO98] Allman, M., Hayes, C., Ostermann, S., "An Evaluation of TCP with Larger Initial Windows," Computer Communication Review, 28(3), July 1998. [BBKT96] Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S., "Enhancing Throughput over Wireless LANs Using Channel State Dependent Packet Scheduling," in Proc. IEEE INFOCOM'96, pp. 1133-40, March 1996. [BBKVP96] Bakshi, B., P., Krishna, N., Vaidya, N., Pradhan, D.K., "Improving Performance of TCP over Wireless Networks," Technical Report 96-014, Texas A&M University, 1996. [BPSK96] Balakrishnan, H., Padmanabhan, V., Seshan, S., Katz, R., "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links," in ACM SIGCOMM, Stanford, California, August 1996. [BV97] Biaz, S., Vaidya, N., "Using End-to-end Statistics to Distinguish Congestion and Corruption Lossses: A Negative Result," Texas A&M University, Technical Report 97-009, August 18, 1997. [BV98] Biaz, S., Vaidya, N., "Sender-Based heuristics for Distinguishing Congestion Losses from Wireless Transmission Losses," Texas A&M University, Technical Report 98-013, June 1998. [BV98a] Biaz, S., Vaidya, N., "Discriminating Congestion Losses from Wireless Losses using Inter-Arrival Times at the Receiver," Texas A&M University, Technical Report 98-014, June 1998. [CB96] Cheshire, S., Baker, M., "Experiences with a Wireless Network in MosquitoNet," IEEE Micro, February 1996. Available Montenegro,Dawkins Expires February 12, 1999 [Page 26] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 online as: http://rescomp.stanford.edu/~cheshire/papers/wireless.ps. [Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and Simulation of a Fair Queueing Algorithm, Internetworking: Research and Experience, Vol. 1, 1990, pp. 3-26. [ECN] Ramakrishnan, K.K., Floyd, S., "A Proposal to add Explicit Congestion Notification (ECN) to IPv6 and to TCP", November 1997. Internet-Draft draft-kksjf-ecn-00.txt (work in progress). [FAP98] Mark Allman, Sally Floyd, Craig Partridge. Increasing TCP's Initial Window, May 1998. Internet-Draft draft-floyd-incr-init-win-03.txt (work in progress). [Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource Management Models for Packet Networks. IEEE/ACM Transactions on Networking, Vol. 3 No. 4, pp. 365-386, August 1995. [FSS98] Fragouli, C., Sivaraman, V., Srivastava, M., "Controlled Multimedia Wireless Link Sharing via Enhanced Class-Based Queueing with Channel-State-Dependent Packet Scheduling," Proc. IEEE INFOCOM'98, April 1998. [GSM] Rahnema, M., "Overview of the GSM system and protocol architecture," IEEE Communications Magazine, vol. 31, pp 92-100, April 1993. [IPCOMP] A. Shacham, R. Monsour, R. Pereira, M. Thomas, IP Payload Compression Protocol (IPComp), May 1998. Internet-Draft draft-ietf-ippcp-protocol-06.txt (work in progress). [IPHC] Mikael Degermark, Bjorn Nordgren,Stephen Pink. IP Header Compression, December 1997. Internet-Draft draft-degermark-ipv6-hc-05.txt (work in progress). [IPHC-PPP] Mathias Engan, S. Casner, C. Bormann. IP Header Compression over PPP, December 1997. Internet-Draft draft-engan-ip-compress-02.txt (work in progress). [ITCP] Bakre, A., Badrinath, B.R., "Handoff and Systems Support for Indirect TCP/IP. In Proceedings of the Second USENIX Symposium on Mobile and Location-Independent Computing, Ann Arbor, Michigan, April 10-11, 1995. [Jain89] Jain, R., "A Delay-Based Approach for Congestion Avoidance in Interconnected Heterogeneous Computer Networks," Digital Equipment Corporation, Technical Report DEC-TR-566, April Montenegro,Dawkins Expires February 12, 1999 [Page 27] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 1989. [LS98] Lettieri, P., Srivastava, M., "Adaptive Frame Length Control for Improving Wireless Link Throughput, Range, and Energy Efficiency," Proc. IEEE INFOCOM'98, April 1998. [MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R., Mobile Network Computing Protocol (MNCP), August 1997. Internet-Draft draft-piscitello-mncp-00.txt (work in progress). [MOWGLI] An Efficient Transport Service for Slow Wireless Telephone Links, http://www.cs.Helsinki.FI/research/mowgli/ [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm," in Computer Communications Review, a publication of ACM SIGCOMM, volume 27, number 3, July 1997. [MTCP] Brown, K. Singh, S., "A Network Architecture for Mobile Computing," Proc. IEEE INFOCOM'96, pp. 1388-1396, March 1996. Available as ftp://ftp.ece.orst.edu/pub/singh/papers/transport.ps.gz. [MV97] Mehta, M., Vaidya, N., "Delayed Duplicate-Acknowledgements: A Proposal to Improve Performance of TCP on Wireless Links," Texas A&M University, December 24, 1997. Available as http://www.cs.tamu.edu/faculty/vaidya/mobile.html [NETBLT] John C. White, NETBLT (Network Block Transfer Protocol), draft-white-protocol-stack-00.txt, April 1997 - work in progress. [RED] Braden, B. Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K.K., Shenker, S., Wroclawski, J., Zhang, L., Recommendations on Queue Management and Congestion Avoidance in the Internet, February 17, 1998. Internet-Draft draft-irtf-e2e-queue-mgt-01.txt (work in progress). [RFC908] Velten, D., Hinden, R., Sax, J., "Reliable Data Protocol", RFC 908, July 1984. [RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers Networks", RFC 1030, November 1987. [RFC1122] Braden, R., Requirements for Internet Hosts -- Communication Layers, October 1989. [RFC1144] Jacobson, V., Compressing TCP/IP Headers for Low-Speed Montenegro,Dawkins Expires February 12, 1999 [Page 28] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 Serial Links, RFC 1144, February 1990. [RFC1151] Partridge, C., Hinden, R., Version 2 of the Reliable Data Protocol (RDP), RFC 1151, April 1990. [RFC1191] Jeff Mogul and Steve Deering. Path MTU Discovery, November 1990. RFC 1191. [RFC1397] Braden, R., Extending TCP for Transactions -- Concepts, November 1992. [RFC1644] Braden, R., T/TCP -- TCP Extensions for Transactions Functional Specification, July 1994. [RFC1661] Simpson, W., ed., "The Point-To-Point Protocol (PPP)", RFC 1661, July 1994. [RFC1986] Polites, W., Wollman, W., Woo, D., Langan, R., "Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP)", RFC 1986, August 1996. [RFC2001] W. Richard Stevens. TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms, January 1997. RFC 2001. [RFC2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002, October 1996. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., "TCP Selective Acknowledgment Options", October, 1996. [RFC2188] Banan, M., Taylor, M., Cheng, J., "AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2", RFC 2188, September 1997. [SNOOP] Balakrishnan, H., Seshan, S., Amir, E., Katz, R., "Improving TCP/IP Performance over Wireless Networks," Proc. 1st ACM Conf. on Mobile Computing and Networking (Mobicom), Berkeley, CA, November 1995. [SP97] Tim Shepard and Craig Partridge. When TCP Starts Up With Four Packets Into Only Three Buffers, July 1997. Internet-Draft draft-shepard-TCP-4-packets-3-buff-00.txt (work in progress). [TCPHP] Van Jacobson, Robert Braden, and David Borman. TCP Extensions for High Performance, May 1992. RFC 1323. Montenegro,Dawkins Expires February 12, 1999 [Page 29] INTERNET DRAFT Wireless Networking for the MNCRS August 1998 [VEGAS] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques for Congestion Detection and Avoidance," SIGCOMM'94, London, pp 24-35, October 1994. [VMTP] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, February 1988. [WAP] Wireless Application Protocol Forum. http://www.wapforum.org/ [WC91] Wang, Z., Crowcroft, J., "A New Congestion Control Scheme: Slow Start and Search," ACM Computer Communication Review, vol 21, pp 32-43, January 1991. [WTCP] Ratnam, K., Matta, I., "WTCP: An Efficient Transmission Control Protocol for Networks with Wireless Links," Technical Report NU-CCS-97-11, Northeastern University, July 1997. Available at: http://www.ece.neu.edu/personal/karu/papers/WTCP-NU.ps.gz [YB94] Yavatkar, R., Bhagawat, N., "Improving End-to-End Performance of TCP over Mobile Internetworks," Proc. Workshop on Mobile Computing Systems and Applications, IEEE Computer Society Press, Los Alamitos, California, 1994. Authors' addresses Questions about this document may be directed at: Gabriel E. Montenegro Sun Microsystems, Inc. 901 San Antonio Road Mailstop UMPK 15-214 Mountain View, California 94303 Voice: +1-650-786-6288 Fax: +1-650-786-6445 E-Mail: gabriel.montenegro@eng.sun.com Spencer Dawkins Nortel P.O. Box 833805 Richardson, Texas 75083-3805 Voice: +1-972-684-4827 Fax: +1-972-685-3292 E-Mail: sdawkins@nortel.com Montenegro,Dawkins Expires February 12, 1999 [Page 30]