idnits 2.17.1 draft-montenegro-mncrs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 895 has weird spacing: '...doption captu...' == Line 1050 has weird spacing: '...eeds to exami...' == Line 1105 has weird spacing: '...n which the o...' == Line 1125 has weird spacing: '...sat and tcpim...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 7, 1998) is 9393 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BV97' is defined on line 1168, but no explicit reference was found in the text == Unused Reference: 'BV98' is defined on line 1172, but no explicit reference was found in the text == Unused Reference: 'GSM' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'RFC1191' is defined on line 1284, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'ACKSPACING' == Outdated reference: A later version (-06) exists of draft-ietf-tcpsat-stand-mech-04 == Outdated reference: A later version (-12) exists of draft-ietf-tcpsat-res-issues-03 ** Downref: Normative reference to an Informational draft: draft-ietf-tcpsat-res-issues (ref. 'AGGHSSTT98') -- Possible downref: Non-RFC (?) normative reference: ref. 'Allman98' -- Possible downref: Non-RFC (?) normative reference: ref. 'AHO98' -- Possible downref: Non-RFC (?) normative reference: ref. 'BBKT96' -- Possible downref: Non-RFC (?) normative reference: ref. 'BBKVP96' -- Possible downref: Non-RFC (?) normative reference: ref. 'BPSK96' -- Possible downref: Non-RFC (?) normative reference: ref. 'BV97' -- Possible downref: Non-RFC (?) normative reference: ref. 'BV98' -- Possible downref: Non-RFC (?) normative reference: ref. 'BV98a' -- Possible downref: Non-RFC (?) normative reference: ref. 'CB96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Demers90' == Outdated reference: A later version (-03) exists of draft-kksjf-ecn-00 ** Downref: Normative reference to an Experimental draft: draft-kksjf-ecn (ref. 'ECN') -- Unexpected draft version: The latest known version of draft-floyd-incr-init-win is -02, but you're referring to -03. ** Downref: Normative reference to an Experimental draft: draft-floyd-incr-init-win (ref. 'FAP98') -- Possible downref: Non-RFC (?) normative reference: ref. 'Floyd95' -- Possible downref: Non-RFC (?) normative reference: ref. 'FSS98' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM' -- Unexpected draft version: The latest known version of draft-ietf-ippcp-protocol is -05, but you're referring to -06. == Outdated reference: A later version (-08) exists of draft-degermark-ipv6-hc-05 -- Possible downref: Non-RFC (?) normative reference: ref. 'ITCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jain89' -- Possible downref: Non-RFC (?) normative reference: ref. 'LS98' -- Possible downref: Normative reference to a draft: ref. 'MNCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MOWGLI' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSMO97' -- Possible downref: Non-RFC (?) normative reference: ref. 'MTCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MV97' -- Possible downref: Normative reference to a draft: ref. 'NETBLT' -- Unexpected draft version: The latest known version of draft-irtf-e2e-queue-mgt is -00, but you're referring to -01. ** Downref: Normative reference to an Informational draft: draft-irtf-e2e-queue-mgt (ref. 'RED') ** Downref: Normative reference to an Experimental RFC: RFC 908 ** Downref: Normative reference to an Unknown state RFC: RFC 1030 ** Downref: Normative reference to an Experimental RFC: RFC 1151 ** Downref: Normative reference to an Historic RFC: RFC 1397 ** Obsolete normative reference: RFC 1644 (Obsoleted by RFC 6247) ** Downref: Normative reference to an Experimental RFC: RFC 1986 ** Obsolete normative reference: RFC 2001 (Obsoleted by RFC 2581) ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational RFC: RFC 2188 -- Possible downref: Non-RFC (?) normative reference: ref. 'SNOOP' -- No information found for draft-shepard-TCP-4-packets-3-buff - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'SP97' ** Obsolete normative reference: RFC 1323 (ref. 'TCPHP') (Obsoleted by RFC 7323) -- Possible downref: Non-RFC (?) normative reference: ref. 'VEGAS' ** Downref: Normative reference to an Experimental RFC: RFC 1045 (ref. 'VMTP') -- Possible downref: Non-RFC (?) normative reference: ref. 'WAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'WC91' -- Possible downref: Non-RFC (?) normative reference: ref. 'WTCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'YB94' Summary: 25 errors (**), 0 flaws (~~), 13 warnings (==), 36 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Montenegro 3 INTERNET DRAFT Sun Microsystems, Inc. 4 S. Dawkins 5 Nortel 6 August 7, 1998 8 Wireless Networking for the MNCRS 9 draft-montenegro-mncrs-00.txt 11 Status of This Memo 13 This document is an individual submission to the Internet 14 Engineering Task Force (IETF). Comments should be submitted to the 15 authors. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as ``work in 28 progress.'' 30 To view the entire list of current Internet-Drafts, please check 31 the "1id-abstracts.txt" listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 33 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 34 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 35 (US West Coast). 37 Abstract 39 In view of the unpredictable and problematic nature of wireless 40 networks, arriving at an optimized wireless transport is a 41 daunting task. We have reviewed the existing proposals along with 42 future research items. Based on this overview, we also recommend 43 mechanisms for implementation in long thin networks. 45 Table of Contents 47 1 Introduction .................................................... 3 48 1.1 Architecture ............................................... 5 49 1.2 Assumptions about the Radio Link ........................... 6 50 2 Should it be IP or Not? ........................................ 7 51 2.1 Underlying Network Error Characteristics ................... 7 52 2.2 Non-IP Alternatives ........................................ 8 53 2.2.1 WAP ................................................... 8 54 2.2.2 MOWGLI ................................................ 9 55 2.2.3 Deploying Non-IP Alternatives ......................... 9 56 2.3 IP-based Alternatives ...................................... 9 57 2.3.1 Path MTU Discovery .................................... 9 58 2.3.2 Non-TCP Proposals ..................................... 10 59 3 TCP or Not ...................................................... 10 60 4 Optimizing TCP .................................................. 11 61 4.1 TCP: Current Mechanisms .................................... 11 62 4.1.1 Slow Start and Congestion Avoidance ................... 11 63 4.1.2 Fast Retransmit and Fast Recovery ..................... 12 64 4.2 Connection Setup with T/TCP [RFC1397, RFC1644] ............. 12 65 4.3 Slow Start Proposals ....................................... 13 66 4.3.1 Larger Initial Window ................................. 13 67 4.3.2 Handling Acknowledgments During Slow Start ............ 13 68 4.3.3 Terminating Slow Start ................................ 14 69 4.4 ACK Spacing ................................................ 14 70 4.5 Delayed Duplicate Acknowlegements .......................... 14 71 4.6 Selective Acknowledgements [RFC2018] ....................... 14 72 4.7 Detecting Corruption Loss .................................. 15 73 4.7.1 Without Explicit Notification ......................... 15 74 4.7.2 With Explicit Notification ............................ 15 75 4.8 Active Queue Management .................................... 15 76 4.9 Scheduling Algorithms ...................................... 16 77 4.10 Spoofing, Split TCP and Performance-Enhancing Proxies 78 (PEPs) ............................................................ 17 79 4.11 Header Compression Alternatives ........................... 19 80 4.12 IP Payload Compression .................................... 19 81 5 Candidate TCP Optimizations for MNCRS Devices ................... 20 82 6 Conclusion ...................................................... 25 83 7 Acknowledgements ................................................ 25 84 8 References ...................................................... 25 85 Author address .................................................... 30 86 1 Introduction 88 Optimized wireless networking is one of the major hurdles that 89 Mobile Computing must solve if it is to enable ubiquitous access 90 to networking resources. However, current data networking 91 protocols have been optimized primarily for wired networks. 92 Wireless environments have very different characteristics in terms 93 of latency, jitter, and error rate as compared to wired networks. 94 Accordingly, traditional protocols are ill-suited to this medium. 96 Mobile Wireless networks can be grouped in W-LANs (for example, 97 802.11 compliant networks) and W-WANs (for example, CDPD, 98 Ricochet, CDMA, PHS, DoCoMo, GSM to name a few). W-WANs present 99 the most serious challenge given that the length of the wireless 100 link (expressed as the delay*bandwidth product) is typically 4 to 101 5 times as long as that of its W-LAN counterparts. For example, 102 for an 802.11 network, assuming the delay (round-trip time) is 103 about 2 ms. and the bandwidth is 1 Mbps, the delay*bandwidth 104 product is 2000 bits. For a W-WAN such as Ricochet, a typical 105 round-trip time may be around 500 ms. (the best is about 230 ms.), 106 and the bandwidth is about 20 Kbps. This yields a delay*bandwidth 107 product roughly equal to 10000 bits. This value is larger than the 108 default 8KB buffer space used by many TCP implementations. This 109 means that, whereas for W-LANs the default buffer space is enough, 110 W-WANs will operate inefficiently (that is, they will not be able 111 to fill the pipe) unless they override the default value. 113 Most importantly, latency across a link adversely affects 114 throughput. For example, [MSMO97] derives an upper bound on TCP 115 throughput. Indeed, the resultant expression is inversely related 116 to the round-trip time. 118 The long latencies also push the limits (and commonly transgress 119 them) for what is acceptable to users of interactive 120 applications. 122 As a quick glance to our list of references will reveal, there is 123 a wealth of proposals that attempt to solve the wireless 124 networking problem. In this document, we survey the different 125 solutions available or under investigation, and issue the 126 corresponding recommendations. 128 The subsequent sections include solutions: 130 - unrelated to IP 132 - built on top of IP 133 - built on top of UDP 135 - built on top of TCP (modifying TCP) 137 There is a large body of work on the subject of improving TCP 138 performance over satellite links. The documents that the tcpsat 139 working group of the IETF is working on [AG98, AGGHSSTT98] are 140 very relevant. In both cases, it is essential to start by 141 improving the characteristics of the medium by using forward error 142 correction (FEC) at the link layer to reduce the BER (bit error 143 rate) from values as high as 10-3 to 10-6 or better. This makes 144 the BER manageable. Once in this realm, retransmissions schemes 145 (ARQ) may be used to bring it down to zero. Notice that sometimes 146 it may be desireable to forgo ARQ because of the additional delay 147 it implies. In particular, time sensitive traffic (video, audio) 148 must be delivered within a certain time limit beyond which the 149 data is obsolete. Exhaustive retransmissions in this case merely 150 succeed in wasting time in order to deliver data that will be 151 discarded once it arrives at its destination. This points at the 152 desireability of augmenting the protocol stack implementation on 153 devices such that the upper protocol layers can inform the lower 154 link and MAC layer when to avoid such costly retransmission 155 schemes. 157 Networks that include satellite links are examples of "long fat 158 networks" (LFNs or "elephants"). They are "long" networks because 159 their round-trip time is quite high (for example, 0.5 sec and 160 higher for geosynchronous satellites). Not all satellite links 161 fall within the LFN regime. In particular, round-trip times in a 162 low-earth orbiting (LEO) satellite network may be as little as a 163 few milliseconds (and never extend beyond 160 to 200 ms). W-WANs 164 share the "L" with LFNs. However, satellite networks are also 165 "fat". In the sense that they may have high bandwidth. Satellite 166 networks may often have a delay*bandwidth product above 64 KBytes, 167 in which case they pose additional problems to TCP [TCPHP]. W-WANs 168 do not generally exhibit this behavior. Accordingly, this document 169 only deals with wireless links that are "long, thin pipes", and 170 the networks that contain them: "long, thin networks". We call 171 these "LTNs". Strictly speaking, LTNs do not necessarily imply 172 wireless. However, in this document, the term LTN is used as a 173 synonym of "long, thin wireless networks". 175 This document does not give an overview of the API used to access 176 the underlying transport. We believe this is an orthogonal issue, 177 even though some of the proposals below have been put forth 178 assuming a given interface. Nevertheless, it is possible, for 179 example, to support the traditional socket semantics without 180 relying on an underlying IP network [MOWGLI]. 182 Our focus is on the on-the-wire protocols. We try to include the 183 most relevant ones and briefly (given that we provide the 184 references needed for further study) mention their most salient 185 points. Our objective is to specify a collection of mechanisms for 186 implementation by MNCRS devices. Given that the MNCRS is an 187 industry consortium, the primary concern is that the 188 recommendations be practical, well understood, that they limit 189 modifications to only those devices under MNCRS control (mobile 190 devices and the base station or proxy), that they cover the most 191 common cases, and, most importantly, that they (at least an 192 effective subset) be deployable within the near term (6 months or 193 so). 195 1.1 Architecture 197 Given our focus on mobile wireless applications, we only consider 198 a very specific architecture that includes: 200 - a wireless mobile device, connected via 202 - a wireless link (which may, in fact comprise several hops at 203 the link layer), to 205 - a base station (sometimes referred to as an intermediate 206 agent) connected via 208 - a wireline link, which in turn interfaces with 210 - the landline internet and millions of legacy servers and web 211 sites. 213 Specifically, we are not as concerned with paths that include two 214 wireless segments separated by a wired one. This may occur, for 215 example, if one mobile device connects across its immediate 216 wireless segment via a base station to the internet, and then via 217 a second wireless segment to another mobile device. Most often, 218 mobile devices connect to a legacy server on the wired internet. 220 Typically, the endpoints of the wireless segment are the base 221 station and the mobile device. However, the latter may be a 222 wireless router to a mobile network. This is also important and 223 has applications in, for example, disaster recovery. 225 Our target architecture has implications which concern the 226 deployability of candidate solutions. In particular, an important 227 requirement is that we cannot alter the networking stack on the 228 legacy servers. It would be preferrable to only change the 229 networking stack at the base station, although changing it at the 230 mobile devices is certainly an option and perhaps a necessity. 232 We envision mobile devices that can use the wireless medium very 233 efficiently, but are not constrained by it. That is, full mobility 234 implies that the devices have the flexibility and agility to use 235 whichever happens to be the best network connection available at 236 any given point in time or space. Accordingly, devices could 237 switch from a wired office LAN and hand over their ongoing 238 connections to continue on, say, a wireless WAN. (This type of 239 agility also requires Mobile IP [RFC2002].) 241 1.2 Assumptions about the Radio Link 243 The system architecture described above assumes at most one 244 wireless link (perhaps comprising more than one wireless hop). 245 However, this is not enough to characterize a wireless link. Given 246 that this has Additional considerations are: 248 - What are the error characteristics of the wireless medium? 249 The link may present a higher BER than a wireline network in 250 the form of random errors. It may also have burst errors and 251 disconnections. The techniques below usually do not address 252 all the issues. Accordingly, a complete solution should 253 combine the best of all the proposals. Nevertheless, in this 254 document we are more concerned with, and give preference to 255 solving the most typical case: higher BER due to random 256 errors (and higher delays due to link-layer error corrections 257 and retransmissions) rather than an interruption in service 258 due to a handoff or a disconnection. Nevertheless, these are 259 also important and we do include relevant proposals in this 260 survey. 262 - Is the wireless service datagram oriented, or is it a virtual 263 circuit? Currently, switched virtual circuits are more 264 common, but packet networks are starting to appear (for 265 example, Metricom's Starmode [CB96], CDPD, and in the future, 266 GSM's GPRS. 268 - What kind of reliability does the link provide? Wireless 269 services typically retransmit a packet until it has been 270 acknowledged by the target. They may allow the user to turn 271 off this behavior. For example, GSM allows RLP (Reliable Link 272 Protocol) to be turned off. Metricom has a similar 273 "lightweight" mode. 275 - Does the mobile device transmit and receive at the same time? 276 Doing so increases the cost of the electronics on the mobile 277 device. Typically, this is not the case. We assume so in this 278 document. 280 - Does the mobile device directly address more than one peer on 281 the wireless link? Packets to each different peer traverse 282 spatially distinct wireless paths. Accordingly, the path to 283 each peer may exhibit very different characteristics. Quite 284 commonly, the mobile device addresses only one peer (the base 285 station) at any given point in time. When this is not the 286 case, techniques such as Channel-State Dependent Packet 287 Scheduling come into play (see the section "Packet 288 Scheduling" below). 290 2 Should it be IP or Not? 292 The first decision is whether to use IP as the underlying network 293 protocol or not. In particular, some data protocols evolved from 294 wireless telephony are not layered on top of IP [MOWGLI, WAP]. 296 This might make sense if the mobile device is guaranteed to talk 297 always through the base station. However, we expect many wireless 298 mobile devices to utilize wireline networks when they are 299 available. This model closely follows current laptop usage 300 patterns, where devices utilize dial-up access when "out of the 301 office", but utilize LANs when they are available. 303 For these devices, an architecture that assumes IP is the best 304 approach, because it will be required for communications that do 305 not traverse the base station (for example, upon reconnection to a 306 W-LAN or a 10BaseT network at the office). 308 2.1 Underlying Network Error Characteristics 310 The decision to use IP as the underlying network protocol implies 311 a certain (low) level of link robustness that is expected of 312 wireless links. 314 IP, and the protocols that are carried in IP packets, are 315 protected end-to-end by checksums that are relatively weak (and, 316 in some cases, optional). For much of the internet, these 317 checksums are sufficient; in wireless environments, the error 318 characteristics of the raw wireless link are much less robust than 319 the rest of the end-to-end path. This makes end-to-end detection 320 of network errors undesirable, because damaged IP packets are 321 propagated through the network only to be discarded at the 322 destination host, and suggests that link-level mechanisms should 323 be used to detect and correct transmission errors over these 324 links. 326 The right approach is to use link-layer mechanisms such as FEC, 327 retransmissions, and so on in order to improve the characteristics 328 of the wireless link and present a much more reliable service to 329 IP. This approach has been taken by CDPD, Ricochet and CDMA. 331 This approach is roughly analogous to the successful deployment of 332 Point-to-Point Protocol (PPP), with robust framing and 16-bit 333 checksumming, on wireline networks as a replacement for the Serial 334 Line Interface Protocol (SLIP), with only a single framing byte 335 and no checksumming. 337 Notice that the link-layer could adapt its frame size to the 338 prevalent BER. It would perform its own fragmentation and 339 reassembly so that IP could still enjoy a large enough MTU size 340 [LS98]. 342 A common concern for using IP as a transport is the header 343 overhead it implies. Typically, the underlying link-layer appears 344 as PPP [RFC1661] to the IP layer above. This allows for header 345 compression schemes [IPHC, IPHC-PPP] which greatly alleviate the 346 problem. 348 2.2 Non-IP Alternatives 350 A number of non-IP alternatives aimed at wireless environments 351 have been proposed. Two representative proposals are discussed 352 here. 354 2.2.1 WAP 356 WAP [WAP] is an architecture designed by and primarily oriented 357 towards data-enabled wireless telephony devices. Instead of IP or 358 HTTP, WAP has alternate optimized protocols and relies on the base 359 station or intermediate agent to provide the impedance matching 360 with the internet. It currently seems to be tied primarily to GSM, 361 even though there is an intent to specify its operation over other 362 technologies such as CDMA, CDPD and US-TDMA). Since, it requires 363 the use of a WAP proxy, if the device switches to a legacy lan 364 (for example, on 10BaseT) and connects directly to a legacy 365 server, it would have to do so over TCP/IP. 367 2.2.2 MOWGLI 369 MOWGLI [MOWGLI] was an earlier research project, aimed at 370 higher-end devices than WAP targets. (The "MOW" in MOWGLI stands 371 for "Mobile Office Workstations".) MOWGLI also specifies its own 372 underlying transport, but it does seek to preserve the socket 373 semantics. 375 2.2.3 Deploying Non-IP Alternatives 377 IP is such a fundamental element of the internet that non-IP 378 alternatives face substantial obstacles to deployment, because 379 they do not exploit the IP infrastructure. Any non-IP alternative 380 that is used to provide gatewayed access to the internet must map 381 between IP addresses and non-IP addresses, must terminate IP-level 382 security at a gateway, and cannot use IP-oriented discovery 383 protocols (Dynamic Host Configuration Protocol, Domain Name 384 Services, Lightweight Directory Access Protocol, etc.) without 385 translation at a gateway. 387 Non-IP alternatives face the burden of proof that IP is so 388 ill-suited to a wireless environment that it is not a viable 389 technology. 391 2.3 IP-based Alternatives 393 Given its worldwide deployment, IP is an obvious choice for the 394 underlying network technology. Optimizations implemented at this 395 level benefit traditional internet application protocols as well 396 as new ones layered on top of IP or UDP. 398 2.3.1 Path MTU Discovery 400 Path MTU discovery benefits any protocol built on top of IP. It 401 allows a sender to determine what the maximum end-to-end 402 transmission unit is to a given destination. Withouth Path MTU 403 discovery, the default MTU size is 512. The benefits of using a 404 larger MTU are: 406 - Smaller ratio of header overhead to data 408 - Allows TCP to grow its congestion window faster, since it 409 increases in units of segments. 411 Of course, for a given BER, a larger MTU has a correspondingly 412 larger probability of error within any given segment. The BER may 413 be reduced using lower level techniques like FEC and link-layer 414 retransmissions. The issue is that now delays may become a problem 415 due to the additional retransmissions, and the fact that packet 416 transmission time increases with a larger MTU. 418 2.3.2 Non-TCP Proposals 420 Other proposals assume an underlying IP datagram service, and 421 implement an optimized transport either directly on top of IP 422 [NETBLT] or on top of UDP [MNCP]. Not relying on TCP is a bold 423 move, given the wealth of experience and research related to it. 424 It could be argued that the internet has not collapsed because its 425 main protocol, TCP, is very careful in how it uses the network, 426 and generally treats it as a black box assuming all packet losses 427 are due to congestion and prudently backing off. This avoids 428 further congestion. 430 However, in the wireless medium, packet losses may also be due to 431 corruption due to high BER, fading, and so on. Here, the right 432 approach is to try harder, instead of backing off. Alternative 433 transport protocols are: 435 - NETBLT [NETBLT, RFC1986, RFC1030] 437 - MNCP [MNCP] 439 - ESRO [RFC2188] 441 - RDP [RFC908, RFC1151] 443 - VMTP [VMTP] 445 3 TCP or Not 447 This is one of the most hotly debated issues in the wireless 448 arena. Here are some arguments against it: 450 - It is generally recognized that TCP does not perform well in 451 the presence of significant levels of non-congestion loss. 452 TCP detractors argue that the wireless medium is one such 453 case, and that it is hard enough to fix TCP. They argue that 454 it is easier to start from scratch. 456 - TCP has too much header overhead. 458 - By the time the mechanisms are in place to fix it, TCP is 459 very heavy, and ill-suited for use by lightweight, portable 460 devices. 462 and here are some in support of TCP: 464 - It is preferrable to continue using the same protocol that 465 the rest of the Internet uses because of compatibility 466 reasons. Any extensions specific to the wireless link may be 467 negotiated. 469 - Legacy mechanisms may be reused (for example congestion 470 control) 472 - Link-layer FEC and ARQ can reduce the BER such that any 473 losses TCP does see are, in fact, caused by congestion. 474 Modern W-WAN technologies do this (CDPD, US-TDMA, CDMA, GSM), 475 thus improving TCP throughput. 477 - Handoffs among different technologies are made possible by 478 Mobile IP [RFC2002], but only if the same protocols, namely 479 TCP/IP, are used throughout. 481 - Given TCP's wealth of research and experience, alternative 482 protocols are relatively immature, and the full implications 483 of their widespread deployment, not clearly understood. 485 4 Optimizing TCP 487 There is a large volume of work on the subject of optimizing TCP 488 for operation over wireless media. Even though satellite networks 489 generally fall in the LFN regime, our current LTN focus has much 490 to benefit from it. For example, the work of the 491 TCP-over-Satellite working group of the IETF has been extremely 492 helpful in preparing this section [AG98, AGGHSSTT98]. 494 4.1 TCP: Current Mechanisms 496 A TCP sender adapts its use of bandwidth based on feedback from 497 the receiver. The high latency characteristic of LTNs implies that 498 adaptation is correspondingly slower. 500 4.1.1 Slow Start and Congestion Avoidance 502 Slow Start and Congestion Avoidance [RFC2001] are the basis for 503 TCP's successful deployment throughout the internet. However there 504 are two reasons why the wireless medium adversely affects them: 506 - Slow start is invoked whenever a loss is detected, assuming 507 the network is congested. This is why it is important to 508 minimize the losses caused by corruption, leaving only those 509 that TCP expects. 511 - The sender increases its window based on the number of ACKs 512 received. This rate, of course, is dependent on the RTT 513 (round-trip-time) between sender and receiver, which implies 514 long delays in high latency links like LTNs. 516 - During slow start, the sender increases its window in units 517 of segments. This is why it is important to use an 518 appropriately large MTU. 520 4.1.2 Fast Retransmit and Fast Recovery 522 Fast retransmit [RFC2001] allows the receiver to inform the sender 523 (by sending several duplicate ACKs) of a lost segment. The sender 524 retransmits what it considers to be this lost segment without 525 waiting for the full timeout. This saves time. 527 After a fast retransmit, a sender invokes the fast recovery 528 [RFC2001] algorithm, whereby it invokes congestion avoidance, but 529 not slow start. This also saves time. 531 4.2 Connection Setup with T/TCP [RFC1397, RFC1644] 533 TCP engages in a "three-way handshake" whenever a new connection 534 is set up. Data transfer is only possible after this phase has 535 completed successfuly. T/TCP allows data to be exchanged in 536 parallel with the connection set up, saving valuable time for long 537 delay networks. 539 T/TCP clearly has benefits in some environments. We believe T/TCP 540 would not provide significant benefits in the environments we are 541 designing for because: 543 - Bypassing the TCP three-way handshake is only possible after 544 the first time a client host has connected to a server host. 546 - If the applications running on the mobile host are 547 HTTP-based, many of the benefits of T/TCP are also available 548 in HTTP/1.1 with persistent connections. 550 4.3 Slow Start Proposals 552 Because slow start dominates the network response seen by 553 interactive users at the beginning of a TCP connection, a number 554 of proposals have been made to modify or or eliminate slow start 555 in long latency environments. 557 Stability of the internet is paramount, so these proposals must 558 demonstrate that they will not adversely affect internet 559 congestion levels in significant ways. The needs of the many 560 outweigh the needs of the few. 562 4.3.1 Larger Initial Window 564 Full slow start, with an initial window of one segment, is a 565 time-consuming bandwidth adaptation procedure over LTNs. Recent 566 proposals suggest starting off with an initial window larger than 567 one segment [FAP98, SP97, AHO98]. 569 In current simulations with an initial window of two segments, 570 this proposal does not contribute significantly to packet drop 571 rates, and it has the added benefit of improving initial response 572 times when the peer device delays acknowledgements during slow 573 start (see next proposal). 575 We expect the IETF tcp-impl working group to recommend allowing an 576 initial window of at least two segments, and perhaps as many as 577 four, in the near future, in environments where this significantly 578 improves performance (LFNs and LTNs). 580 4.3.2 Handling Acknowledgments During Slow Start 582 The sender increases its window based on the flow of ACKs coming 583 back from the receiver. Particularly during slow- start, this flow 584 is very important. A couple of the proposals that have been 585 studied are [Allman98]: 587 - Make each ACK count to its fullest by growing the window 588 based on the data being acknowledged (byte counting) instead 589 of the number of ACKs (ACK counting). This has been shown to 590 cause bursts which lead to congestion. [Allman98] shows that 591 Limited Byte Counting (LBC), in which the window growth is 592 limited to 2 segments, does not lead to burstiness, and 593 offers some performance gains. 595 - Keep a constant stream of ACKs coming back by turning off 596 delayed ACKs [RFC1122], at least during slow-start. 598 4.3.3 Terminating Slow Start 600 New mechanisms [AGGHSSTT98] are being proposed to improve TCP's 601 adaptive properties such that the available bandwidth is better 602 utilized and at the same time reducing the possibility of 603 congesting the network. The latter leads to the closing of the 604 congestion window to 1 segment, and the subsequent slow-start 605 phase. 607 4.4 ACK Spacing 609 During slow-start, the sender responds to the incoming ACK stream 610 by transmitting two new segment for each ACK received. This 611 results in data being sent at twice the speed at which it can be 612 processed by the network. Accordingly, queues will form, and due 613 to lack of sufficient buffering at the bottleneck router, packets 614 may get dropped before the link's capacity is full. Spacing out 615 the ACKs effectively controls the rate at which the sender will 616 transmit into the network, and may result in little or no queueing 617 at the bottleneck router [ACKSPACING]. 619 4.5 Delayed Duplicate Acknowlegements 621 As was mentioned above, link-layer retransmissions may raise the 622 BER such that congestion accounts for most of the packet losses 623 (still, nothing can be done about interruptions due to handoffs, 624 moving beyond wireless coverage, etc). In this scenario, it is 625 imperative to prevent interaction between link-layer 626 retransmission and TCP retransmission as these layers duplicate 627 each other's efforts. In such an environment it may make sense to 628 delay TCP's efforts so as to give the link-layer a chance to 629 recover [MV97]. It is preferrable to allow a local mechanism to 630 resolve a local problem, instead of invoking TCP's end-to-end 631 mechanism and incurring the associated costs, both in terms of 632 wasted bandwidth and in terms of its effect on TCP's window. 634 4.6 Selective Acknowledgements [RFC2018] 636 The applicability of SACK is suspect, according to Section 1.1 of 637 [TCPHP]. In particular, SACK may be useful in the LFN regime, 638 specially if large windows are being used, because there is a 639 considerable probability of multiple segment losses per window. In 640 the LTN regime, windows are not larger than the usual, and 641 single-segment losses will be, by far, the most common. 642 Accordingly, the complexity of SACK may not be justifiable, unless 643 there is a high probability of burst errors and congestion on the 644 wireless link. 646 Berkeley's Snoop protocol research [SNOOP] indicates that SACK 647 does improve throughput for Snoop when multiple segments are lost 648 per window [BPSK96]. 650 4.7 Detecting Corruption Loss 652 4.7.1 Without Explicit Notification 654 In the absence of explicit notification from the network, some 655 researchers have suggested statistical methods for congestion 656 avoidance [Jain89, WC91, VEGAS]. A natural extension of these 657 heuristics would enable a sender to distinguish between losses 658 caused by congestion and other causes. Unfortunately, it does not 659 seem like these sender-based heuristics are at all reliable [BV97, 660 BV98]. 662 Fortunately, under selected conditions recent results using packet 663 inter-arrival times measured at the receiver are encouraging 664 [BV98a]. 666 4.7.2 With Explicit Notification 668 Explicit notification from the network can make it very easy to 669 determine when a loss is not due to congestion, so as to avoid 670 invoking TCP's costly recovery mechanism. Several proposals along 671 these lines include: 673 - ELN [BPSK96] 675 - EBSN [BBKVP96] 677 - ELNR, and EDDAN (notifications to mobile receiver) [MV97] 679 - ECN [ECN] 681 4.8 Active Queue Management 683 As has been pointed out above, TCP responds to congestion by 684 closing down the window and invoking slow-start. Long-delay 685 networks take a particularly long time to recover from this 686 condition. Accordingly, it is imperative to avoid congestion in 687 LTNs. To remedy this, active queue management techniques have been 688 proposed as enhancements to routers throughout the Internet [RED]. 689 The primary motivation for deployment of these mechanisms is to 690 prevent "congestion collapse" (a severe degradation in service) by 691 controlling the average queue size at the routers. As the average 692 queue length grows, Random Early Detection [RED] increases the 693 possibility of dropping packets. 695 The benefits are: 697 - Reduce packet drops in routers. By dropping a few packets 698 before severe congestion sets in, RED avoids dropping bursts 699 of packets. 701 - Provide lower delays. This follows from the smaller queue 702 sizes, and is particularly important for interactive 703 applications, for which the inherent delays of wireless links 704 already push the user experience to the limits of the 705 non-acceptable. 707 - Avoid lock-outs. Packets from over-agressive flows can get 708 dropped with the same probability as other packets. 710 4.9 Scheduling Algorithms 712 Active queue management helps control the length of the queues. 713 Additionally, a general solution requires replacing FIFO with 714 other scheduling algorithms that improve: 716 1. Fairness (by policing how different packet streams utilize 717 the available bandwidth), and 719 2. Throughput (by improving the transmitter's radio channel 720 utilization). 722 For example, fairness is necessary for interactive applications 723 (like telnet or web browsing) to coexist with bulk transfer 724 sessions. Proposals here include: 726 - Fair Queueing (FQ) [Demers90] 728 - Class-based Queueing (CBQ) [Floyd95] 730 These proposals may be attractive in wireless LTN environments, 731 even if they are only implemented over the wireless link portion 732 of the communication path, because new connections for interactive 733 applications can have difficulty starting when a bulk TCP transfer 734 has already stabilized using all available bandwidth. 736 In our base architecture described above, the mobile device 737 typically communicates directly with only one wireless peer at a 738 given time: the base station. However, it is possible to directly 739 address other mobiles within the same cell. Direct communication 740 with each such wireless peer traverses a spatially distinct path, 741 each of which exhibits statistically independent radio link 742 characteristics. Channel State Dependent Packet Scheduling (CSDP) 743 [BBKT96] tracks the state of the various radio links (as defined 744 by the target devices), and gives preferential treatment to 745 packets destined for radio links in a "good" state. This avoids 746 attempting to transmit to (and to elicit acknowledgements from) a 747 peer on a "bad" radio link, thus improving throughput. 749 A further refinement of this idea suggests that both fairness and 750 throughput can be achieved by combining a wireless-enhanced CBQ 751 with CSDP [FSS98]. 753 4.10 Spoofing, Split TCP and Performance-Enhancing Proxies (PEPs) 755 Given the dramatic differences between the wired and the wireless 756 links, a very common approach is to provide some impedance 757 matching where the two different technologies meet: at the base 758 station. 760 The idea is to replace an end-to-end TCP connection with two 761 clearly distinct connections: one across the wireless link, the 762 other across its wireline counterpart. Each of the two resulting 763 TCP sessions operates under very different networking 764 characteristics, and may adopt the policies best suited to its 765 particular medium. For example, in an extreme case it may be 766 desirable to turn off Fast Retransmission and Fast Recovery only 767 on the wireless TCP link, because on this portion of the 768 connection path, losses may be caused almost exclusively by 769 corruption instead of congestion. 771 Spoofing proposals include schemes like I-TCP [ITCP] which 772 achieves performance improvements by relinquishing end-to-end 773 semantics. [MTCP] alleviates this problem somewhat, but does not 774 entirely solve it. 776 Berkeley's Snoop protocol [SNOOP] is a hybrid scheme mixing 777 link-layer reliability mechanisms with the split connection 778 approach. It is an improvement over I-TCP in that end-to-end 779 semantics are retained as well as in terms of performance. Snoop 780 does two things: 782 1. Locally (on the wireless link) retransmit lost packets, 783 instead of allowing TCP to do so end-to-end. 785 2. Suppress the duplicate acks on their way from the receiver 786 back to the sender, thus avoiding fast retransmit and 787 congestion avoidance at the latter. 789 WTCP [WTCP] is similar to Snoop in that it preserves end-to-end 790 semantics. In WTCP, the base station uses a complex scheme to 791 hide the time it spends moving packets across the wireless link 792 (this typically includes retransmissions due to error recovery, 793 but may also include time spent dealing with congestion). In order 794 to work effectively, it assumes that the TCP endpoints implement 795 the Timestamps option in RFC 1323 [TCPHP]. Unfortunately, support 796 for RFC 1323 in TCP implementations is not yet widespread. Beyond 797 this, WTCP requires changes only at the base station. 799 All of these schemes require the base station to examine and 800 operate on the traffic between the portable wireless device and 801 the TCP server on the wired Internet. None of these work if the IP 802 traffic is encrypted, unless, of course, the base station is privy 803 to the security association between the mobile device and its 804 end-to-end peer. They also require that both the data and the 805 corresponding ACKs traverse the same base station. Furthermore, 806 if the base station retransmits packets at the transport layer 807 across the wireless link, this may duplicate efforts by the 808 link-layer. Snoop has been described by its designers as a 809 TCP-aware link-layer. This is the right approach: layers 2 and 3 810 should be integrated much more tightly than traditional OSI 811 layering suggests. 813 Often, in addition to the PEP mechanism at the base station, a 814 custom protocol is used on the wireless link (for example, [WAP] 815 or [MOWGLI]). However, there is evidence that the performance 816 gains are due to the fact that a proxy serves as a coupling device 817 between the wireless and wireline worlds, and that using a custom 818 protocol on the wireless link only affords limited benefits 819 [YB94]. Even if the gains were moderate or better, the wealth of 820 research on optimizing TCP for wireless, and compatibility with 821 the Internet are overwhelmingly compelling reasons to adopt TCP on 822 the wireless link (of course, enhanced as suggested in section 5 823 below). 825 4.11 Header Compression Alternatives 827 Because Long Thin Networks are bandwidth-constrained, every byte 828 that can be compressed out of over-the-air segments is worth 829 compressing. 831 Van Jacobson header compression [RFC1144] describes a Proposed 832 Standard for TCP Header compression that is widely deployed. 834 Mechanisms for TCP and IP header compression defined in [IPHC, 835 IPHC-PPP] provide the following benefits: 837 - Improve interactive response time 839 - Allow using small packets for bulk data with good line 840 efficiency 842 - Allow using small packets for delay sensitive low data-rate 843 traffic 845 - Decrease header overhead (for the smallest MTU of 512 the 846 header overhead of TCP over IP falls from 11.7 to less than 1 847 per cent. 849 - Reduce packet loss rate over lossy links. 851 4.12 IP Payload Compression 853 Compression of IP segment payloads is also desirable. "IP Payload 854 Compression Protocol (IPComp)" [IPCOMP] defines a framework where 855 common compression algorithms can be applied to arbitrary IP 856 segment payloads. IP payload compression is something of a niche 857 optimization. It is necessary because IP-level security converts 858 IP payloads to random bitstreams, defeating commonly-deployed 859 link-layer compression mechanisms which are faced with payloads 860 that have no redundant "information" that can be more compactly 861 represented. 863 However, many IP payloads are already compressed (images, audio, 864 video, "zipped" files being FTPed), or are already encrypted above 865 the IP layer (SSL/TLS, etc.). These payloads will not "compress" 866 further, limiting the benefit of this optimization. 868 For now, IPCOMP compression of HTML and MIME headers is an obvious 869 benefit. 871 5 Candidate TCP Optimizations for MNCRS Devices 873 The table below summarizes our recommendations with regards to the 874 main proposals mentioned above. The first column, "Stability of 875 the Proposal", refers to the maturity of the mechanism in 876 question. Some proposals are being pursued within the IETF in a 877 somewhat open fashion. IETF proposals are either Drafts 878 (preliminary versions) or RFCs. There are several types of RFCs. 879 Proposed Standards (PS) are standards track, and carry more weight 880 than Informational. Other proposals are isolated efforts with 881 little or no public review, and little chance of garnering 882 industry backing. "Implemented at" gives an indication of which 883 participant in a TCP session must be modified to implement the 884 proposal. Of course, legacy servers cannot be modified, so this 885 column merely indicates whether implementation happens at either 886 or both of the two nodes under MNCRS control: mobile device and 887 base station. The symbols used are: WS (wireless sender, that is, 888 the mobile device's TCP send operation must be modified), WR 889 (wireless receiver, that is, the mobile device's TCP receive 890 operation must be modified), WD (wireless device, that is, 891 modifications at the mobile device are not specific to either TCP 892 send or receive), BS (base station) and NI (network 893 infrastructure). The End-to-end IPSec column indicates if a given 894 mechanism works in the presence of IPSec encrypted traffic between 895 the mobile device and the server. MNCRS Adoption captures the 896 MNCRS recommendation. Some mechanisms are endorsed for immediate 897 adoption, others need more evidence and research, and others are 898 discarded. 900 Name Stability of Implemented MNCRS Adoption 901 the Proposal at 902 ==================== ============= =========== ================= 904 Increased Initial IETF Draft WS Yes 905 Congestion Window (initial_window=2) 907 Disable delayed ACKs NA WR When stable 908 during slow-start 910 Byte counting NA WS No 911 instead of ACK 912 counting 914 TCP Header RFC 1144 (PS) WD Yes 915 compression for PPP BS 917 IP Payload IETF Draft WD Yes 918 Compression (Approved as (simultaneously 919 PS) needed on Server) 921 IP Header IETF Draft WD Mobile IP only 922 Compression BS 923 (includes IP-IP) for 924 PPP 926 Snoop plus SACK In limited use BS Yes 927 WD (for SACK) 929 Fast retransmit/fast RFC 2001 (PS) WD Yes (should be 930 recovery there already) 932 Transaction/TCP RFC 1644 WD No 933 (Experimental) (simultaneously 934 needed on Server) 936 Estimating Slow NA WS No 937 Start Threshold 938 (ssthresh) 940 Delayed Duplicate Not stable WR When stable 941 Acknowledgements BS (for 942 notifications) 944 Class-based Queuing NA WD When stable 945 on End Systems 946 Explicit Congestion IETF Draft WD When stable 947 Notification NI 949 Of all the candidate optimizations in the table above, only Snoop 950 plus SACK and Delayed duplicate acknowledgements are currently 951 being proposed only for wireless networks. The others are being 952 considered even for non-wireless applications. Their more general 953 applicability has the benefit of drawing more attention and 954 analysis from the research community. 956 Of the above mechanisms, only Header Compression (for IP and TCP) 957 and "Snoop plus SACK" cease to work in the presence of IPSec. 959 Increased Initial Congestion Window 961 Implement this on MNCRS devices now. The research on this 962 optimization indicates that 2 is a safe initial setting and is 963 centering on choosing between 2, 3, and 4. For now, use 2, 964 which at least allows clients running query-response 965 applications to get an initial ACK from unmodified servers 966 without waiting for a delayed ACK timeout of 200-500 967 milliseconds. 969 Many of the benefits of this optimization are also available 970 (after the first request-response exchange) when clients and 971 servers both implement HTTP/1.1. This optimization works with 972 older servers that implement only HTTP/1.0. 974 Disable delayed ACKs during slow start 976 Implement this on MNCRS pending further investigation. Even 977 though simulations confirm its promise (it allows receivers to 978 get the second segment from unmodified senders without waiting 979 for a delayed ACK timeout of 200-500 milliseconds), for this 980 technique to be practical the receiver must acknowledge every 981 segment only when the sender is in slow-start. Continuing to 982 do so when the sender is in congestion avoidance may have 983 adverse effects on the mobile device's battery consumption and 984 on traffic in the network. 986 For now, the recommendation is to conservative ACK only the 987 first segment on a new connection with no delay. 989 Again, many of the benefits of this optimization are also 990 available after the first request-response exchange when 991 clients and servers both implement HTTP/1.1. This optimization 992 works with older servers that implement only HTTP/1.0. 994 Byte Counting instead of ACK Counting 996 Unlimited byte counting is not recommended. 998 In 999 http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt, 1000 Van Jacobson says that byte counting is a bad thing because it 1001 leads to burstiness, and recommends ACK spacing instead. 1003 Limited byte counting warrants further investigation before 1004 deciding, but it shows promise. 1006 TCP Header Compression for PPP 1008 Implement this on MNCRS devices now. It is a widely-implemented 1009 Proposed Standard. 1011 IP Payload Compression 1013 Recommended, as the IETF has approved it as a proposed 1014 standard. 1016 Notes on this optimization: 1018 - Some payloads are already compressed, and won't be 1019 compressed further (JPEG, GIF). 1021 - Payloads must be compressed before encryption (encrypted 1022 payloads won't compress). 1024 - HTTP-NG is considering supporting compression of resources 1025 at the HTTP level, which would provide the same benefits 1026 for common compressible MIME types like text/html. 1028 IP Header Compression (includes IP-IP) for PPP 1030 Implement this on MNCRS devices when the Internet-Draft becomes 1031 stable. 1033 SNOOP plus SACK 1035 Implement this on MNCRS-capable base stations now. Research 1036 results are encouraging, and it's an "invisible" optimization - 1037 neither the client nor the server needs to change, only the 1038 base station (for base SNOOP). 1040 SNOOP benefits from selective acknowledgements in order to 1041 recover from multi-segment losses in one round-trip. In this 1042 case, the mobile device needs to implement some form of 1043 selective acknowledgements. If selective acknowledgments are 1044 not used, recovery from multi-segment losses takes so long that 1045 TCP enters congestion avoidance anyway. 1047 Encryption of IP packets via IPSEC's ESP header (in either 1048 transport or tunnel mode) renders the TCP header and payload 1049 unintelligible to the base station. This precludes SNOOP from 1050 working, because it needs to examine the TCP headers in both 1051 directions. Possible solutions involve: 1053 - making the SNOOPing base station a party to the security 1054 association between the client and the server 1056 - IPSEC tunneling mode, terminated at the SNOOPing base 1057 station 1059 - and so on. 1061 However, at this time these are not well understood so MNCRS 1062 users valuing both privacy and performance should use SSL or 1063 SOCKS for end-to-end security. 1065 Fast Retransmit/Fast Recovery 1067 Implement on MNCRS devices at this time. It is a 1068 widely-implemented optimization and is currently at Proposed 1069 Standard level. 1071 Transaction TCP (T/TCP) 1073 Not recommended at this time, for these reasons: 1075 - It's an Experimental RFC, and has not been advanced. 1077 - It's not widely deployed, and it has to be deployed at 1078 both ends of a connection. 1080 - At least some of the benefits of T/TCP (eliminating 1081 three-way handshake on subsequent query-response 1082 transactions, for instance) are also available with 1083 persistent connections on HTTP/1.1, which is more widely 1084 deployed. 1086 Estimating Slow Start Threshold (ssthresh) 1088 Not recommended. 1090 Rough consensus on the tcp-impl and tcp-sat mailing lists is 1091 that there is no good way to probe during TCP startup and 1092 estimate bandwidth available. 1094 Delayed Duplicate Acknowledgements 1096 Recommended, pending further research and experience. 1098 Class-based queuing on end systems 1100 No recommendation at this time. 1102 Explicit Notifications 1104 No recommendation at this time. Schemes like ELNR and EDDAN 1105 [MV97], in which the only systems that need to be modified are 1106 the base station and the mobile device are slated for adoption 1107 pending further research. However, the requirement that the 1108 base station be able to examine the TCP headers flying through 1109 it poses the previously stated issues with respect to 1110 IPSEC-encrypted packets. 1112 ECN is slated for adoption when and if the IETF finalizes the 1113 specification. 1115 6 Conclusion 1117 In view of the unpredictable and problematic nature of wireless 1118 networks, arriving at an optimized wireless transport is a 1119 daunting task. We have reviewed the existing proposals along with 1120 future research items. Based on this overview, we also recommend 1121 mechanisms for implementation in long thin networks. 1123 7 Acknowledgements 1125 The authors are deeply indebted to the IETF tcpsat and tcpimpl 1126 working groups, and to Prof. Nitin Vaidya (Texas A&M) whose many 1127 insightful comments have proved invaluable in our attempt at 1128 improving this note. The following individuals have also provided 1129 valuable feedback: Mark Allman (NASA), Raphi Rom (Technion/Sun). 1131 8 References 1133 [ACKSPACING] Partridge, C., "ACK Spacing for High Delay-Bandwidth 1134 Paths with Insufficient Buffering," July 1997. Internet-Draft 1135 draft-partridge-e2e-ackspacing-00.txt (work in progress). 1137 [AG98] Mark Allman, Dan Glover. Enhancing TCP Over Satellite 1138 Channels using Standard Mechanisms, May 1998. Internet-Draft 1139 draft-ietf-tcpsat-stand-mech-04.txt (work in progress). 1141 [AGGHSSTT98] Mark Allman, Dan Glover, Jim Griner, John Heidemann, 1142 Keith Scott, Jeffrey Semke, Joe Touch, Diepchi Tran. Ongoing TCP 1143 Research Related to Satellites, May 1998. Internet-Draft 1144 draft-ietf-tcpsat-res-issues-03.txt (work in progress). 1146 [Allman98] Allman, M., "On the Generation and Use of TCP 1147 Acknowledgments," July, 1998. Submitted to ACM Computer 1148 Communication Review. 1150 [AHO98] Allman, M., Hayes, C., Ostermann, S., "An Evaluation of 1151 TCP with Larger Initial Windows," Computer Communication Review, 1152 28(3), July 1998. 1154 [BBKT96] Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S., 1155 "Enhancing Throughput over Wireless LANs Using Channel State 1156 Dependent Packet Scheduling," in Proc. IEEE INFOCOM'96, pp. 1157 1133-40, March 1996. 1159 [BBKVP96] Bakshi, B., P., Krishna, N., Vaidya, N., Pradhan, D.K., 1160 "Improving Performance of TCP over Wireless Networks," Technical 1161 Report 96-014, Texas A&M University, 1996. 1163 [BPSK96] Balakrishnan, H., Padmanabhan, V., Seshan, S., Katz, R., 1164 "A Comparison of Mechanisms for Improving TCP Performance over 1165 Wireless Links," in ACM SIGCOMM, Stanford, California, August 1166 1996. 1168 [BV97] Biaz, S., Vaidya, N., "Using End-to-end Statistics to 1169 Distinguish Congestion and Corruption Lossses: A Negative Result," 1170 Texas A&M University, Technical Report 97-009, August 18, 1997. 1172 [BV98] Biaz, S., Vaidya, N., "Sender-Based heuristics for 1173 Distinguishing Congestion Losses from Wireless Transmission 1174 Losses," Texas A&M University, Technical Report 98-013, June 1175 1998. 1177 [BV98a] Biaz, S., Vaidya, N., "Discriminating Congestion Losses 1178 from Wireless Losses using Inter-Arrival Times at the Receiver," 1179 Texas A&M University, Technical Report 98-014, June 1998. 1181 [CB96] Cheshire, S., Baker, M., "Experiences with a Wireless 1182 Network in MosquitoNet," IEEE Micro, February 1996. Available 1183 online as: 1184 http://rescomp.stanford.edu/~cheshire/papers/wireless.ps. 1186 [Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and 1187 Simulation of a Fair Queueing Algorithm, Internetworking: Research 1188 and Experience, Vol. 1, 1990, pp. 3-26. 1190 [ECN] Ramakrishnan, K.K., Floyd, S., "A Proposal to add Explicit 1191 Congestion Notification (ECN) to IPv6 and to TCP", November 1997. 1192 Internet-Draft draft-kksjf-ecn-00.txt (work in progress). 1194 [FAP98] Mark Allman, Sally Floyd, Craig Partridge. Increasing 1195 TCP's Initial Window, May 1998. Internet-Draft 1196 draft-floyd-incr-init-win-03.txt (work in progress). 1198 [Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource 1199 Management Models for Packet Networks. IEEE/ACM Transactions on 1200 Networking, Vol. 3 No. 4, pp. 365-386, August 1995. 1202 [FSS98] Fragouli, C., Sivaraman, V., Srivastava, M., "Controlled 1203 Multimedia Wireless Link Sharing via Enhanced Class-Based Queueing 1204 with Channel-State-Dependent Packet Scheduling," Proc. IEEE 1205 INFOCOM'98, April 1998. 1207 [GSM] Rahnema, M., "Overview of the GSM system and protocol 1208 architecture," IEEE Communications Magazine, vol. 31, pp 92-100, 1209 April 1993. 1211 [IPCOMP] A. Shacham, R. Monsour, R. Pereira, M. Thomas, IP Payload 1212 Compression Protocol (IPComp), May 1998. Internet-Draft 1213 draft-ietf-ippcp-protocol-06.txt (work in progress). 1215 [IPHC] Mikael Degermark, Bjorn Nordgren,Stephen Pink. IP Header 1216 Compression, December 1997. Internet-Draft 1217 draft-degermark-ipv6-hc-05.txt (work in progress). 1219 [IPHC-PPP] Mathias Engan, S. Casner, C. Bormann. IP Header 1220 Compression over PPP, December 1997. Internet-Draft 1221 draft-engan-ip-compress-02.txt (work in progress). 1223 [ITCP] Bakre, A., Badrinath, B.R., "Handoff and Systems Support 1224 for Indirect TCP/IP. In Proceedings of the Second USENIX Symposium 1225 on Mobile and Location-Independent Computing, Ann Arbor, Michigan, 1226 April 10-11, 1995. 1228 [Jain89] Jain, R., "A Delay-Based Approach for Congestion 1229 Avoidance in Interconnected Heterogeneous Computer Networks," 1230 Digital Equipment Corporation, Technical Report DEC-TR-566, April 1231 1989. 1233 [LS98] Lettieri, P., Srivastava, M., "Adaptive Frame Length 1234 Control for Improving Wireless Link Throughput, Range, and Energy 1235 Efficiency," Proc. IEEE INFOCOM'98, April 1998. 1237 [MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R., Mobile 1238 Network Computing Protocol (MNCP), August 1997. Internet-Draft 1239 draft-piscitello-mncp-00.txt (work in progress). 1241 [MOWGLI] An Efficient Transport Service for Slow Wireless 1242 Telephone Links, http://www.cs.Helsinki.FI/research/mowgli/ 1244 [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The 1245 Macroscopic Behavior of the TCP Congestion Avoidance Algorithm," 1246 in Computer Communications Review, a publication of ACM SIGCOMM, 1247 volume 27, number 3, July 1997. 1249 [MTCP] Brown, K. Singh, S., "A Network Architecture for Mobile 1250 Computing," Proc. IEEE INFOCOM'96, pp. 1388-1396, March 1996. 1251 Available as 1252 ftp://ftp.ece.orst.edu/pub/singh/papers/transport.ps.gz. 1254 [MV97] Mehta, M., Vaidya, N., "Delayed 1255 Duplicate-Acknowledgements: A Proposal to Improve Performance of 1256 TCP on Wireless Links," Texas A&M University, December 24, 1997. 1257 Available as http://www.cs.tamu.edu/faculty/vaidya/mobile.html 1259 [NETBLT] John C. White, NETBLT (Network Block Transfer Protocol), 1260 draft-white-protocol-stack-00.txt, April 1997 - work in progress. 1262 [RED] Braden, B. Clark, D., Crowcroft, J., Davie, B., Deering, S., 1263 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., 1264 Peterson, L., Ramakrishnan, K.K., Shenker, S., Wroclawski, J., 1265 Zhang, L., Recommendations on Queue Management and Congestion 1266 Avoidance in the Internet, February 17, 1998. Internet-Draft 1267 draft-irtf-e2e-queue-mgt-01.txt (work in progress). 1269 [RFC908] Velten, D., Hinden, R., Sax, J., "Reliable Data 1270 Protocol", RFC 908, July 1984. 1272 [RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers 1273 Networks", RFC 1030, November 1987. 1275 [RFC1122] Braden, R., Requirements for Internet Hosts -- 1276 Communication Layers, October 1989. 1278 [RFC1144] Jacobson, V., Compressing TCP/IP Headers for Low-Speed 1279 Serial Links, RFC 1144, February 1990. 1281 [RFC1151] Partridge, C., Hinden, R., Version 2 of the Reliable 1282 Data Protocol (RDP), RFC 1151, April 1990. 1284 [RFC1191] Jeff Mogul and Steve Deering. Path MTU Discovery, 1285 November 1990. RFC 1191. 1287 [RFC1397] Braden, R., Extending TCP for Transactions -- Concepts, 1288 November 1992. 1290 [RFC1644] Braden, R., T/TCP -- TCP Extensions for Transactions 1291 Functional Specification, July 1994. 1293 [RFC1661] Simpson, W., ed., "The Point-To-Point Protocol (PPP)", 1294 RFC 1661, July 1994. 1296 [RFC1986] Polites, W., Wollman, W., Woo, D., Langan, R., 1297 "Experiments with a Simple File Transfer Protocol for Radio Links 1298 using Enhanced Trivial File Transfer Protocol (ETFTP)", RFC 1986, 1299 August 1996. 1301 [RFC2001] W. Richard Stevens. TCP Slow Start, Congestion 1302 Avoidance, Fast Retransmit, and Fast Recovery Algorithms, January 1303 1997. RFC 2001. 1305 [RFC2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002, 1306 October 1996. 1308 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., 1309 "TCP Selective Acknowledgment Options", October, 1996. 1311 [RFC2188] Banan, M., Taylor, M., Cheng, J., "AT&T/Neda's Efficient 1312 Short Remote Operations (ESRO) Protocol Specification Version 1313 1.2", RFC 2188, September 1997. 1315 [SNOOP] Balakrishnan, H., Seshan, S., Amir, E., Katz, R., 1316 "Improving TCP/IP Performance over Wireless Networks," Proc. 1st 1317 ACM Conf. on Mobile Computing and Networking (Mobicom), Berkeley, 1318 CA, November 1995. 1320 [SP97] Tim Shepard and Craig Partridge. When TCP Starts Up With 1321 Four Packets Into Only Three Buffers, July 1997. Internet-Draft 1322 draft-shepard-TCP-4-packets-3-buff-00.txt (work in progress). 1324 [TCPHP] Van Jacobson, Robert Braden, and David Borman. TCP 1325 Extensions for High Performance, May 1992. RFC 1323. 1327 [VEGAS] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques for 1328 Congestion Detection and Avoidance," SIGCOMM'94, London, pp 24-35, 1329 October 1994. 1331 [VMTP] Cheriton, D., "VMTP: Versatile Message Transaction 1332 Protocol", RFC 1045, February 1988. 1334 [WAP] Wireless Application Protocol Forum. 1335 http://www.wapforum.org/ 1337 [WC91] Wang, Z., Crowcroft, J., "A New Congestion Control Scheme: 1338 Slow Start and Search," ACM Computer Communication Review, vol 21, 1339 pp 32-43, January 1991. 1341 [WTCP] Ratnam, K., Matta, I., "WTCP: An Efficient Transmission 1342 Control Protocol for Networks with Wireless Links," Technical 1343 Report NU-CCS-97-11, Northeastern University, July 1997. Available 1344 at: http://www.ece.neu.edu/personal/karu/papers/WTCP-NU.ps.gz 1346 [YB94] Yavatkar, R., Bhagawat, N., "Improving End-to-End 1347 Performance of TCP over Mobile Internetworks," Proc. Workshop on 1348 Mobile Computing Systems and Applications, IEEE Computer Society 1349 Press, Los Alamitos, California, 1994. 1351 Authors' addresses 1353 Questions about this document may be directed at: 1355 Gabriel E. Montenegro 1356 Sun Microsystems, Inc. 1357 901 San Antonio Road 1358 Mailstop UMPK 15-214 1359 Mountain View, California 94303 1361 Voice: +1-650-786-6288 1362 Fax: +1-650-786-6445 1364 E-Mail: gabriel.montenegro@eng.sun.com 1366 Spencer Dawkins 1367 Nortel 1368 P.O. Box 833805 1369 Richardson, Texas 75083-3805 1371 Voice: +1-972-684-4827 1372 Fax: +1-972-685-3292 1374 E-Mail: sdawkins@nortel.com