idnits 2.17.1 draft-montenegro-pilc-ltn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 49 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 781: '... This violates a SHOULD in [RFC2581]: delayed acknowledgements...' RFC 2119 keyword, line 782: '... SHOULD be used by a TCP receiver....' RFC 2119 keyword, line 1569: '...ssion using zlib SHOULD be implemented...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 969 has weird spacing: '...n which the o...' == Line 1449 has weird spacing: '... window with ...' == Line 1482 has weird spacing: '... system can s...' == Line 1525 has weird spacing: '...ression for l...' == Line 1709 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 (October 19, 1999) is 8957 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 1821, but no explicit reference was found in the text == Unused Reference: 'BV98' is defined on line 1825, but no explicit reference was found in the text == Unused Reference: 'MTCP' is defined on line 1959, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. 'ACKSPACING' ** Downref: Normative reference to an Informational draft: draft-ietf-tcpsat-res-issues (ref. 'ADGGHOSSTT98') -- 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. 'BPK99' -- 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. 'BW97' -- Possible downref: Non-RFC (?) normative reference: ref. 'CB96' -- Possible downref: Non-RFC (?) normative reference: ref. 'CDMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'CDPD' == Outdated reference: A later version (-03) exists of draft-balakrishnan-cm-00 -- Possible downref: Normative reference to a draft: ref. 'CM' -- Possible downref: Non-RFC (?) normative reference: ref. 'CTCSM97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Demers90' ** Obsolete normative reference: RFC 2481 (ref. 'ECN') (Obsoleted by RFC 3168) -- Possible downref: Non-RFC (?) normative reference: ref. 'Floyd95' -- Possible downref: Non-RFC (?) normative reference: ref. 'FSS98' -- Possible downref: Non-RFC (?) normative reference: ref. 'GPRS' -- Possible downref: Non-RFC (?) normative reference: ref. 'GSM' -- Possible downref: Non-RFC (?) normative reference: ref. 'HL96' -- Possible downref: Non-RFC (?) normative reference: ref. 'HTTP-PERF' ** Obsolete normative reference: RFC 2393 (ref. 'IPPCP') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 2509 (ref. 'IPHC-PPP') (Obsoleted by RFC 3544) -- Possible downref: Non-RFC (?) normative reference: ref. 'ITCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jain89' -- Possible downref: Non-RFC (?) normative reference: ref. 'Karn93' -- Possible downref: Non-RFC (?) normative reference: ref. 'KRLKA97' -- Possible downref: Non-RFC (?) normative reference: ref. 'LAKLR95' -- Possible downref: Non-RFC (?) normative reference: ref. 'LHKR96' -- 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. 'M-TCP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MV97' -- Possible downref: Normative reference to a draft: ref. 'NETBLT' -- Possible downref: Non-RFC (?) normative reference: ref. 'Paxson97' ** Obsolete normative reference: RFC 2309 (ref. 'RED') (Obsoleted by RFC 7567) -- Possible downref: Non-RFC (?) normative reference: ref. 'RLP' ** 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 2002 (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational RFC: RFC 2188 ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2414 (Obsoleted by RFC 3390) ** Downref: Normative reference to an Informational RFC: RFC 2415 ** Downref: Normative reference to an Informational RFC: RFC 2416 ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2582 (Obsoleted by RFC 3782) -- Possible downref: Non-RFC (?) normative reference: ref. 'SNOOP' -- Possible downref: Non-RFC (?) normative reference: ref. 'Stevens94' ** Obsolete normative reference: RFC 1323 (ref. 'TCPHP') (Obsoleted by RFC 7323) -- Possible downref: Non-RFC (?) normative reference: ref. 'TCPSATMIN' ** Obsolete normative reference: RFC 2140 (ref. 'Touch97') (Obsoleted by RFC 9040) -- Possible downref: Non-RFC (?) normative reference: ref. 'Vaidya99' -- 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: 28 errors (**), 0 flaws (~~), 13 warnings (==), 50 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force G. Montenegro 2 INTERNET DRAFT Sun Microsystems, Inc. 3 S. Dawkins 4 Nortel Networks 5 M. Kojo 6 University of Helsinki 7 V. Magret 8 Alcatel 9 N. Vaidya 10 Texas A&M University 11 October 19, 1999 12 Long Thin Networks 13 draft-montenegro-pilc-ltn-03.txt 15 Status of This Memo 17 This document is an Internet-Draft and is in full conformance 18 with all provisions of Section 10 of RFC2026. 20 This document is an individual submission to the Internet 21 Engineering Task Force (IETF). Comments should be submitted to the 22 authors or to the PILC mailing list at pilc@grc.nasa.gov. 24 Distribution of this memo is unlimited. 26 This document is an Internet-Draft. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF), its areas, 28 and its working groups. Note that other groups may also distribute 29 working documents as Internet-Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as ``work in 35 progress.'' 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 Abstract 45 In view of the unpredictable and problematic nature of long thin 46 networks (for example, wireless WANs), arriving at an optimized 47 transport is a daunting task. We have reviewed the existing 48 proposals along with future research items. Based on this 49 overview, we also recommend mechanisms for implementation in long 50 thin networks. 52 Our goal is to identify a TCP that works for all users, including 53 users of long thin networks. We started from the working 54 recommendations of the IETF TCP Over Satellite Links (tcpsat) 55 working group with this end in mind. 57 We recognize that not every tcpsat recommendation will be 58 required for long thin networks as well, and work toward a set 59 of TCP recommendations that are 'benign' in environments that 60 do not require them. 62 Table of Contents 64 1 Introduction .................................................... 5 65 1.1 Network Architecture ....................................... 7 66 1.2 Assumptions about the Radio Link ........................... 8 67 2 Should it be IP or Not? ........................................ 9 68 2.1 Underlying Network Error Characteristics ................... 10 69 2.2 Non-IP Alternatives ........................................ 11 70 2.2.1 WAP ................................................... 11 71 2.2.2 Deploying Non-IP Alternatives ......................... 11 72 2.3 IP-based Considerations .................................... 12 73 2.3.1 Choosing the MTU [Stevens94, RFC1144] ................. 12 74 2.3.2 Path MTU Discovery [RFC1191] .......................... 12 75 2.3.3 Non-TCP Proposals ..................................... 13 76 3 The Case for TCP ................................................ 13 77 4 Candidate Optimizations ......................................... 14 78 4.1 TCP: Current Mechanisms .................................... 15 79 4.1.1 Slow Start and Congestion Avoidance ................... 15 80 4.1.2 Fast Retransmit and Fast Recovery ..................... 15 81 4.2 Connection Setup with T/TCP [RFC1397, RFC1644] ............. 16 82 4.3 Slow Start Proposals ....................................... 17 83 4.3.1 Larger Initial Window ................................. 17 84 4.3.2 Growing the Window during Slow Start .................. 18 85 4.3.2.1 ACK Counting ..................................... 18 86 4.3.2.2 ACK-every-segment ................................ 19 87 4.3.3 Terminating Slow Start ................................ 20 88 4.3.4 Generating ACKs during Slow Start ..................... 20 89 4.4 ACK Spacing ................................................ 20 90 4.5 Delayed Duplicate Acknowlegements .......................... 21 91 4.6 Selective Acknowledgements [RFC2018] ....................... 22 92 4.7 Detecting Corruption Loss .................................. 22 93 4.7.1 Without Explicit Notification ......................... 22 94 4.7.2 With Explicit Notifications ........................... 23 95 4.8 Active Queue Management .................................... 24 96 4.9 Scheduling Algorithms ...................................... 25 97 4.10 Split TCP and Performance-Enhancing Proxies (PEPs) ........ 26 98 4.10.1 Split TCP Approaches ................................. 27 99 4.10.2 Application Level Proxies ............................ 30 100 4.10.3 Snoop and its Derivatives ............................ 31 101 4.10.4 PEPs to handle Periods of Disconnection .............. 33 102 4.11 Header Compression Alternatives ........................... 34 103 4.12 Payload Compression ....................................... 35 104 4.13 TCP Control Block Interdependence [Touch97] ............... 36 105 5 Summary of Recommended Optimizations ............................ 37 106 6 Conclusion ...................................................... 39 107 7 Acknowledgements ................................................ 39 108 8 Security Considerations ......................................... 39 109 9 References ...................................................... 41 110 Authors' addresses ................................................ 48 111 1 Introduction 113 Optimized wireless networking is one of the major hurdles that 114 Mobile Computing must solve if it is to enable ubiquitous access 115 to networking resources. However, current data networking 116 protocols have been optimized primarily for wired networks. 117 Wireless environments have very different characteristics in terms 118 of latency, jitter, and error rate as compared to wired networks. 119 Accordingly, traditional protocols are ill-suited to this medium. 121 Mobile Wireless networks can be grouped in W-LANs (for example, 122 802.11 compliant networks) and W-WANs (for example, CDPD [CDPD], 123 Ricochet, CDMA [CDMA], PHS, DoCoMo, GSM [GSM] to name a few). 124 W-WANs present the most serious challenge, given that the length 125 of the wireless link (expressed as the delay*bandwidth product) is 126 typically 4 to 5 times as long as that of its W-LAN counterparts. 127 For example, for an 802.11 network, assuming the delay (round-trip 128 time) is about 3 ms. and the bandwidth is 1.5 Mbps, the 129 delay*bandwidth product is 4500 bits. For a W-WAN such as 130 Ricochet, a typical round-trip time may be around 500 ms. (the 131 best is about 230 ms.), and the sustained bandwidth is about 24 132 Kbps. This yields a delay*bandwidth product roughly equal to 1.5 133 KB. In the near future, 3rd Generation wireless services will 134 offer 384Kbps and more. Assuming a 200 ms round-trip, the 135 delay*bandwidth product in this case is 76.8 Kbits (9.6 KB). This 136 value is larger than the default 8KB buffer space used by many TCP 137 implementations. This means that, whereas for W-LANs the default 138 buffer space is enough, future W-WANs will operate inefficiently 139 (that is, they will not be able to fill the pipe) unless they 140 override the default value. A 3rd Generation wireless service 141 offering 2 Mbps with 200-millisecond latency requires a 50 KB 142 buffer. 144 Most importantly, latency across a link adversely affects 145 throughput. For example, [MSMO97] derives an upper bound on TCP 146 throughput. Indeed, the resultant expression is inversely related 147 to the round-trip time. 149 The long latencies also push the limits (and commonly transgress 150 them) for what is acceptable to users of interactive 151 applications. 153 As a quick glance to our list of references will reveal, there is 154 a wealth of proposals that attempt to solve the wireless 155 networking problem. In this document, we survey the different 156 solutions available or under investigation, and issue the 157 corresponding recommendations. 159 There is a large body of work on the subject of improving TCP 160 performance over satellite links. The documents under development 161 by the tcpsat working group of the IETF [AGS98, ADGGHOSSTT98] are 162 very relevant. In both cases, it is essential to start by 163 improving the characteristics of the medium by using forward error 164 correction (FEC) at the link layer to reduce the BER (bit error 165 rate) from values as high as 10-3 to 10-6 or better. This makes 166 the BER manageable. Once in this realm, retransmission schemes 167 like ARQ (automatic repeat request) may be used to bring it down 168 even further. Notice that sometimes it may be desireable to forgo ARQ 169 because of the additional delay it implies. In particular, time 170 sensitive traffic (video, audio) must be delivered within a 171 certain time limit beyond which the data is obsolete. Exhaustive 172 retransmissions in this case merely succeed in wasting time in 173 order to deliver data that will be discarded once it arrives at 174 its destination. This indicates the desireability of augmenting 175 the protocol stack implementation on devices such that the upper 176 protocol layers can inform the link and MAC layer when to avoid 177 such costly retransmission schemes. 179 Networks that include satellite links are examples of "long fat 180 networks" (LFNs or "elephants"). They are "long" networks because 181 their round-trip time is quite high (for example, 0.5 sec and 182 higher for geosynchronous satellites). Not all satellite links 183 fall within the LFN regime. In particular, round-trip times in a 184 low-earth orbiting (LEO) satellite network may be as little as a 185 few milliseconds (and never extend beyond 160 to 200 ms). W-WANs 186 share the "L" with LFNs. However, satellite networks are also 187 "fat" in the sense that they may have high bandwidth. Satellite 188 networks may often have a delay*bandwidth product above 64 KBytes, 189 in which case they pose additional problems to TCP [TCPHP]. W-WANs 190 do not generally exhibit this behavior. Accordingly, this document 191 only deals with links that are "long thin pipes", and the networks 192 that contain them: "long thin networks". We call these "LTNs". 194 This document does not give an overview of the API used to access 195 the underlying transport. We believe this is an orthogonal issue, 196 even though some of the proposals below have been put forth 197 assuming a given interface. It is possible, for example, to 198 support the traditional socket semantics without fully relying on 199 TCP/IP transport [MOWGLI]. 201 Our focus is on the on-the-wire protocols. We try to include the 202 most relevant ones and briefly (given that we provide the 203 references needed for further study) mention their most salient 204 points. 206 1.1 Network Architecture 208 One significant difference between LFNs and LTNs is that we assume 209 the W-WAN link is the last hop to the end user. This allows us to 210 assume that a single intermediate node sees all packets 211 transferred between the wireless mobile device and the rest of 212 the Internet. This is only one of the topologies considered by 213 the TCP Satellite community. 215 Given our focus on mobile wireless applications, we only consider 216 a very specific architecture that includes: 218 - a wireless mobile device, connected via 220 - a wireless link (which may, in fact comprise several hops 221 at the link layer), to 223 - an intermediate node (sometimes referred to as a base 224 station) connected via 226 - a wireline link, which in turn interfaces with 228 - the landline Internet and millions of legacy servers and web 229 sites. 231 Specifically, we are not as concerned with paths that include two 232 wireless segments separated by a wired one. This may occur, for 233 example, if one mobile device connects across its immediate 234 wireless segment via an intermediate node to the Internet, and 235 then via a second wireless segment to another mobile device. 236 Quite often, mobile devices connect to a legacy server on the 237 wired Internet. 239 Typically, the endpoints of the wireless segment are the 240 intermediate node and the mobile device. However, the latter may 241 be a wireless router to a mobile network. This is also important 242 and has applications in, for example, disaster recovery. 244 Our target architecture has implications which concern the 245 deployability of candidate solutions. In particular, an important 246 requirement is that we cannot alter the networking stack on the 247 legacy servers. It would be preferable to only change the 248 networking stack at the intermediate node, although changing it 249 at the mobile devices is certainly an option and perhaps a 250 necessity. 252 We envision mobile devices that can use the wireless medium very 253 efficiently, but overcome some of its traditional constraints. 255 That is, full mobility implies that the devices have the 256 flexibility and agility to use whichever happens to be the best 257 network connection available at any given point in time or space. 258 Accordingly, devices could switch from a wired office LAN and hand 259 over their ongoing connections to continue on, say, a wireless 260 WAN. This type of agility also requires Mobile IP [RFC2002]. 262 1.2 Assumptions about the Radio Link 264 The system architecture described above assumes at most one 265 wireless link (perhaps comprising more than one wireless hop). 266 However, this is not enough to characterize a wireless link. 267 Additional considerations are: 269 - What are the error characteristics of the wireless medium? 270 The link may present a higher BER than a wireline 271 network due to burst errors and disconnections. The 272 techniques below usually do not address all the types of 273 errors. Accordingly, a complete solution should combine the 274 best of all the proposals. Nevertheless, in this document 275 we are more concerned with (and give preference to solving) 276 the most typical case: (1) higher BER due to random errors 277 (which implies longer and more variable delays due to 278 link-layer error corrections and retransmissions) rather 279 than (2) an interruption in service due to a handoff or 280 a disconnection. The latter are also important and we 281 do include relevant proposals in this survey. 283 - Is the wireless service datagram oriented, or is it a 284 virtual circuit? Currently, switched virtual circuits are 285 more common, but packet networks are starting to appear, 286 for example, Metricom's Starmode [CB96], CDPD [CDPD] and 287 General Packet Radio Service (GPRS) [GPRS],[BW97] in GSM. 289 - What kind of reliability does the link provide? Wireless 290 services typically retransmit a packet (frame) until it has 291 been acknowledged by the target. They may allow the user to 292 turn off this behavior. For example, GSM allows RLP [RLP] 293 (Radio Link Protocol) to be turned off. Metricom has 294 a similar "lightweight" mode. In GSM RLP, a frame is 295 retransmitted until the maximum number of retransmissions 296 (protocol parameter) is reached. What happens when this 297 limit is reached is determined by the telecom operator: 298 the physical link connection is either disconnected or 299 a link reset is enforced where the sequence numbers are 300 resynchronized and the transmit and receive buffers are 301 flushed resulting in lost data. Some wireless services, 302 like CDMA IS95-RLP [CDMA, Karn93], limit the latency 303 on the wireless link by retransmitting a frame only a 304 couple of times. This decreases the residual frame error 305 rate significantly, but does not provide fully reliable 306 link service. 308 - Does the mobile device transmit and receive at the same 309 time? Doing so increases the cost of the electronics on 310 the mobile device. Typically, this is not the case. We 311 assume in this document that mobile devices do not transmit 312 and receive simultaneously. 314 - Does the mobile device directly address more than one peer 315 on the wireless link? Packets to each different peer may 316 traverse spatially distinct wireless paths. Accordingly, 317 the path to each peer may exhibit very different 318 characteristics. Quite commonly, the mobile device 319 addresses only one peer (the intermediate node) at any 320 given point in time. When this is not the case, techniques 321 such as Channel-State Dependent Packet Scheduling come into 322 play (see the section "Packet Scheduling" below). 324 2 Should it be IP or Not? 326 The first decision is whether to use IP as the underlying network 327 protocol or not. In particular, some data protocols evolved from 328 wireless telephony are not always -- though at times they may be 329 -- layered on top of IP [MOWGLI, WAP]. These proposals are based 330 on the concept of proxies that provide adaptation services between 331 the wireless and wireline segments. 333 This is a reasonable model for mobile devices that always 334 communicate through the proxy. However, we expect many wireless 335 mobile devices to utilize wireline networks whenever they are 336 available. This model closely follows current laptop usage 337 patterns: devices typically utilize LANs, and only resort to 338 dial-up access when "out of the office." 340 For these devices, an architecture that assumes IP is the best 341 approach, because it will be required for communications that do 342 not traverse the intermediate node (for example, upon 343 reconnection to a W-LAN or a 10BaseT network at the office). 345 2.1 Underlying Network Error Characteristics 347 Using IP as the underlying network protocol requires a certain 348 (low) level of link robustness that is expected of wireless 349 links. 351 IP, and the protocols that are carried in IP packets, are 352 protected end-to-end by checksums that are relatively weak 353 [Stevens94, Paxson97] (and, in some cases, optional). For much 354 of the Internet, these checksums are sufficient; in wireless 355 environments, the error characteristics of the raw wireless link 356 are much less robust than the rest of the end-to-end path. 357 Hence for paths that include wireless links, exclusively relying 358 on end-to-end mechanisms to detect and correct transmission 359 errors is undesireable. These should be complemented by local 360 link-level mechanisms. Otherwise, damaged IP packets are 361 propagated through the network only to be discarded at the 362 destination host. For example, intermediate routers are required 363 to check the IP header checksum, but not the UDP or TCP 364 checksums. Accordingly, when the payload of an IP packet is 365 corrupted, this is not detected until the packet arrives at its 366 ultimate destination. 368 A better approach is to use link-layer mechanisms such as FEC, 369 retransmissions, and so on in order to improve the characteristics 370 of the wireless link and present a much more reliable service to 371 IP. This approach has been taken by CDPD, Ricochet and CDMA. 373 This approach is roughly analogous to the successful deployment of 374 Point-to-Point Protocol (PPP), with robust framing and 16-bit 375 checksumming, on wireline networks as a replacement for the Serial 376 Line Interface Protocol (SLIP), with only a single framing byte 377 and no checksumming. 379 [AGS98] recommends the use of FEC in satellite environments. 381 Notice that the link-layer could adapt its frame size to the 382 prevalent BER. It would perform its own fragmentation and 383 reassembly so that IP could still enjoy a large enough MTU size 384 [LS98]. 386 A common concern for using IP as a transport is the header 387 overhead it implies. Typically, the underlying link-layer 388 appears as PPP [RFC1661] to the IP layer above. This allows for 389 header compression schemes [IPHC, IPHC-RTP, IPHC-PPP] which 390 greatly alleviate the problem. 392 2.2 Non-IP Alternatives 394 A number of non-IP alternatives aimed at wireless environments 395 have been proposed. One representative proposal is discussed 396 here. 398 2.2.1 WAP 400 The Wireless Application Protocol (WAP) specifies an application 401 framework and network protocols for wireless devices such as 402 mobile telephones, pagers, and PDAs [WAP]. The architecture 403 requires a proxy between the mobile device and the server. The WAP 404 protocol stack is layered over a datagram transport service. Such 405 a service is provided by most wireless networks; for example, 406 IS-136, GSM SMS/USSD, and UDP in IP networks like CDPD and GSM 407 GPRS. The core of the WAP protocols is a binary HTTP/1.1 protocol 408 with additional features such as header caching between requests 409 and a shared state between client and server. 411 2.2.2 Deploying Non-IP Alternatives 413 IP is such a fundamental element of the Internet that non-IP 414 alternatives face substantial obstacles to deployment, because 415 they do not exploit the IP infrastructure. Any non-IP alternative 416 that is used to provide gatewayed access to the Internet must map 417 between IP addresses and non-IP addresses, must terminate IP-level 418 security at a gateway, and cannot use IP-oriented discovery 419 protocols (Dynamic Host Configuration Protocol, Domain Name 420 Services, Lightweight Directory Access Protocol, Service Location 421 Protocol, etc.) without translation at a gateway. 423 A further complexity occurs when a device supports both wireless 424 and wireline operation. If the device uses IP for wireless 425 operation, uninterrupted operation when the device is connected to 426 a wireline network is possible (using Mobile IP). If a non-IP 427 alternative is used, this switchover is more difficult to 428 accomplish. 430 Non-IP alternatives face the burden of proof that IP is so 431 ill-suited to a wireless environment that it is not a viable 432 technology. 434 2.3 IP-based Considerations 436 Given its worldwide deployment, IP is an obvious choice for the 437 underlying network technology. Optimizations implemented at this 438 level benefit traditional Internet application protocols as well 439 as new ones layered on top of IP or UDP. 441 2.3.1 Choosing MTU [Stevens94, RFC1144] 443 In slow networks, the time required to transmit the largest 444 possible packet may be considerable. Interactive response time 445 should not exceed the well-known human factors limit of 100 to 446 200 ms. This should be considered the maximum time budget to (1) 447 send a packet and (2) obtain a response. In most networking 448 stack implementations, (1) is highly dependent on the maximum 449 transmission unit (MTU). In the worst case, a small packet from 450 an interactive application may have to wait for a large packet 451 from a bulk transfer application before being sent. Hence, a 452 good rule of thumb is to choose an MTU such that its 453 transmission time is less than (or not much larger than) 200 454 ms. 456 Of course, compression and type-of-service queuing (whereby 457 interactive data packets are given a higher priority) may 458 alleviate this problem. In particular, the latter may reduce the 459 average wait time to about half the MTU's transmission time. 461 2.3.2 Path MTU Discovery [RFC1191] 463 Path MTU discovery benefits any protocol built on top of IP. It 464 allows a sender to determine what the maximum end-to-end 465 transmission unit is to a given destination. Without Path MTU 466 discovery, the default IPv4 MTU size is 576. The benefits of 467 using a larger MTU are: 469 - Smaller ratio of header overhead to data 471 - Allows TCP to grow its congestion window faster, since 472 it increases in units of segments. 474 Of course, for a given BER, a larger MTU has a correspondingly 475 larger probability of error within any given segment. The BER may 476 be reduced using lower level techniques like FEC and link-layer 477 retransmissions. The issue is that now delays may become a problem 478 due to the additional retransmissions, and the fact that packet 479 transmission time increases with a larger MTU. 481 Recommendation: Path MTU discovery is recommended. [AGS98] 482 already recommends its use in satellite environments. 484 2.3.3 Non-TCP Proposals 486 Other proposals assume an underlying IP datagram service, and 487 implement an optimized transport either directly on top of IP 488 [NETBLT] or on top of UDP [MNCP]. Not relying on TCP is a bold 489 move, given the wealth of experience and research related to it. 490 It could be argued that the Internet has not collapsed because its 491 main protocol, TCP, is very careful in how it uses the network, 492 and generally treats it as a black box assuming all packet losses 493 are due to congestion and prudently backing off. This avoids 494 further congestion. 496 However, in the wireless medium, packet losses may also be due to 497 corruption due to high BER, fading, and so on. Here, the right 498 approach is to try harder, instead of backing off. Alternative 499 transport protocols are: 501 - NETBLT [NETBLT, RFC1986, RFC1030] 503 - MNCP [MNCP] 505 - ESRO [RFC2188] 507 - RDP [RFC908, RFC1151] 509 - VMTP [VMTP] 511 3 The Case for TCP 513 This is one of the most hotly debated issues in the wireless 514 arena. Here are some arguments against it: 516 - It is generally recognized that TCP does not perform well 517 in the presence of significant levels of non-congestion 518 loss. TCP detractors argue that the wireless medium is 519 one such case, and that it is hard enough to fix TCP. They 520 argue that it is easier to start from scratch. 522 - TCP has too much header overhead. 524 - By the time the mechanisms are in place to fix it, TCP 525 is very heavy, and ill-suited for use by lightweight, 526 portable devices. 528 and here are some in support of TCP: 530 - It is preferrable to continue using the same protocol 531 that the rest of the Internet uses for compatibility 532 reasons. Any extensions specific to the wireless link 533 may be negotiated. 535 - Legacy mechanisms may be reused (for example three-way 536 handshake). 538 - Link-layer FEC and ARQ can reduce the BER such that any 539 losses TCP does see are, in fact, caused by congestion 540 (or a sustained interruption of link connectivity). Modern 541 W-WAN technologies do this (CDPD, US-TDMA, CDMA, GSM), 542 thus improving TCP throughput. 544 - Handoffs among different technologies are made possible 545 by Mobile IP [RFC2002], but only if the same protocols, 546 namely TCP/IP, are used throughout. 548 - Given TCP's wealth of research and experience, 549 alternative protocols are relatively immature, and the 550 full implications of their widespread deployment not 551 clearly understood. 553 Overall, we feel that the performance of TCP over long-thin 554 networks can be improved significantly. Mechanisms to do so are 555 discussed in the next sections. 557 4 Candidate Optimizations 559 There is a large volume of work on the subject of optimizing TCP 560 for operation over wireless media. Even though satellite networks 561 generally fall in the LFN regime, our current LTN focus has much 562 to benefit from it. For example, the work of the 563 TCP-over-Satellite working group of the IETF has been extremely 564 helpful in preparing this section [AGS98, ADGGHOSSTT98]. 566 4.1 TCP: Current Mechanisms 568 A TCP sender adapts its use of bandwidth based on feedback 569 from the receiver. The high latency characteristic of LTNs 570 implies that TCP's adaptation is correspondingly slower than 571 on networks with shorter delays. Similarly, delayed ACKs 572 exacerbate the perceived latency on the link. Given that TCP 573 grows its congestion window in units of segments, small MTUs 574 may slow adaptation even further. 576 4.1.1 Slow Start and Congestion Avoidance 578 Slow Start and Congestion Avoidance [RFC2581] are essential 579 the Internet's stability. However there are two reasons why 580 the wireless medium adversely affects them: 582 - Whenever TCP's retransmission timer expires, the sender 583 assumes that the network is congested and invokes slow 584 start. This is why it is important to minimize the 585 losses caused by corruption, leaving only those caused 586 by congestion (as expected by TCP). 588 - The sender increases its window based on the number of ACKs 589 received. Their rate of arrival, of course, is dependent 590 on the RTT (round-trip-time) between sender and receiver, 591 which implies long ramp-up times in high latency links 592 like LTNs. The dependency lasts until the pipe is filled. 594 - During slow start, the sender increases its window in units 595 of segments. This is why it is important to use an 596 appropriately large MTU which, in turn, requires requires 597 link layers with low loss. 599 4.1.2 Fast Retransmit and Fast Recovery 601 When a TCP sender receives several duplicate ACKs, fast 602 retransmit [RFC2581] allows it to infer that a segment was lost. 603 The sender retransmits what it considers to be this lost 604 segment without waiting for the full timeout, thus saving time. 606 After a fast retransmit, a sender invokes the fast recovery 607 [RFC2581] algorithm. Fast recovery allows the sender to transmit 608 at half its previous rate (regulating the growth of its window 609 based on congestion avoidance), rather than having to begin 610 a slow start. This also saves time. 612 In general, TCP can increase its window beyond the 613 delay-bandwidth product. However, in LTN links the congestion 614 window may remain rather small, less than four segments, 615 for long periods of time due to any of the following reasons: 617 1. Typical "file size" to be transferred over a connection 618 is relatively small (Web requests, Web document objects, 619 email messages, files, etc.) In particular, users of 620 LTNs are not very willing to carry out large transfers 621 as the response time is so long. 623 2. If the link has high BER, the congestion window tends 624 to stay small 626 3. When an LTN is combined with a highly congested wireline 627 Internet path, congestion losses on the Internet have 628 the same effect as 2. 630 4. Commonly, ISPs/operators configure only a small number 631 of buffers (even as few as for 3 packets) per user in 632 their dial-up routers 634 5. Often small socket buffers are recommended with LTNs in 635 order to prevent the RTO from inflating and to diminish 636 the amount of packets with competing traffic. 638 A small window effectively prevents the sender from taking 639 advantage of Fast Retransmits. Moreover, efficient recovery from 640 multiple losses within a single window requires adoption of new 641 proposals (NewReno [RFC2582]). In addition, on slow paths with 642 no packet reordering waiting for three duplicate ACKs to arrive 643 postpones retransmission unnecessarily. 645 Recommendation: Implement Fast Retransmit and Fast Recovery at 646 this time. This is a widely-implemented optimization and is 647 currently at Proposed Standard level. [AGS98] recommends 648 implementation of Fast Retransmit/Fast Recovery in satellite 649 environments. NewReno [RFC2582] apparently does help a sender 650 better handle partial ACKs and multiple losses in a single 651 window, but at this point is not recommended due to its 652 experimental nature. Instead, SACK [RFC2018] is the preferred 653 mechanism. 655 4.2 Connection Setup with T/TCP [RFC1397, RFC1644] 657 TCP engages in a "three-way handshake" whenever a new connection 658 is set up. Data transfer is only possible after this phase has 659 completed successfuly. T/TCP allows data to be exchanged in 660 parallel with the connection set up, saving valuable time for 661 short transactions on long-latency networks. 663 Recommendation: T/TCP is not recommended, for these reasons: 665 - It is an Experimental RFC. 667 - It is not widely deployed, and it has to be deployed at both 668 ends of a connection. 670 - Security concerns have been raised that T/TCP is more vulnerable 671 to address-spoofing attacks than TCP itself. 673 - At least some of the benefits of T/TCP (eliminating three-way 674 handshake on subsequent query-response transactions, for 675 instance) are also available with persistent connections on 676 HTTP/1.1, which is more widely deployed. 678 [ADGGHOSSTT98] does not have a recommendation on T/TCP in 679 satellite environments. 681 4.3 Slow Start Proposals 683 Because slow start dominates the network response seen by 684 interactive users at the beginning of a TCP connection, 685 a number of proposals have been made to modify or eliminate 686 slow start in long latency environments. 688 Stability of the Internet is paramount, so these proposals must 689 demonstrate that they will not adversely affect Internet 690 congestion levels in significant ways. 692 4.3.1 Larger Initial Window 694 Traditional slow start, with an initial window of one segment, 695 is a time-consuming bandwidth adaptation procedure over 696 LTNs. Studies on an initial window larger than one segment 697 [RFC2414, AHO98] resulted in the TCP standard supporting 698 a maximum value of 2 [RFC2581]. Higher values are still 699 experimental in nature. 701 In simulations with an increased initial window of three packets 702 [RFC2415], this proposal does not contribute significantly to 703 packet drop rates, and it has the added benefit of improving 704 initial response times when the peer device delays 705 acknowledgements during slow start (see next proposal). 707 [RFC2416] addresses situations where the initial window exceeds 708 the number of buffers available to TCP and indicates that this 709 situation is no different from the case where the congestion 710 window grows beyond the number of buffers available. 712 We expect the IETF tcp-impl working group to recommend allowing an 713 initial window of at least two segments, and perhaps as many as 714 four, in the near future, in environments where this significantly 715 improves performance (LFNs and LTNs). 717 Recommendation: Implement this on devices now. The research on 718 this optimization indicates that 3 segments is a safe initial 719 setting, and is centering on choosing between 2, 3, and 4. For 720 now, use 2 (following RFC2581), which at least allows clients 721 running query-response applications to get an initial ACK from 722 unmodified servers without waiting for a typical delayed ACK 723 timeout of 200 milliseconds, and saves two round-trips. An 724 initial window of 3 [RFC2415] looks promising and may be 725 adopted in the future pending further research and experience. 727 4.3.2 Growing the Window during Slow Start 729 The sender increases its window based on the flow of ACKs coming 730 back from the receiver. Particularly during slow start, this flow 731 is very important. A couple of the proposals that have been 732 studied are (1) ACK counting and (2) ACK-every-segment. 734 4.3.2.1 ACK Counting 736 The main idea behing ACK counting is: 738 - Make each ACK count to its fullest by growing the window 739 based on the data being acknowledged (byte counting) 740 instead of the number of ACKs (ACK counting). This has been 741 shown to cause bursts which lead to congestion. [Allman98] 742 shows that Limited Byte Counting (LBC), in which the 743 window growth is limited to 2 segments, does not lead to 744 as much burstiness, and offers some performance gains. 746 Recommendation: Unlimited byte counting is not recommended. Van 747 Jacobson cautions against byte counting [TCPSATMIN] because it 748 leads to burstiness, and recommends ACK spacing [ACKSPACING] 749 instead. 751 ACK spacing requires ACKs to consistently pass through a single 752 ACK-spacing router. This requirement works well for W-WAN 753 environments if the ACK-spacing router is also the intermediate 754 node. 756 Limited byte counting warrants further investigation before we can 757 recommend this proposal, but it shows promise. 759 4.3.2.2 ACK-every-segment 761 The main idea behind ACK-every-segment is: 763 - Keep a constant stream of ACKs coming back by turning off 764 delayed ACKs [RFC1122] during slow start. ACK-every-segment 765 must be limited to slow start, in order to avoid penalizing 766 asymmetric-bandwidth configurations. For instance, a low 767 bandwidth link carrying acknowledgements back to the 768 sender, hinders the growth of the congestion window, even 769 if the link toward the client has a greater bandwidth 770 [BPK99]. 772 Even though simulations confirm its promise (it allows 773 receivers to receive the second segment from unmodified 774 senders without waiting for a typical delayed ACK timeout 775 of 200 milliseconds), for this technique to be practical the 776 receiver must acknowledge every segment only when the sender 777 is in slow start. Continuing to do so when the sender is in 778 congestion avoidance may have adverse effects on the mobile 779 device's battery consumption and on traffic in the network. 781 This violates a SHOULD in [RFC2581]: delayed acknowledgements 782 SHOULD be used by a TCP receiver. 784 "Disabling Delayed ACKs During Slow Start" is technically 785 unimplementable, as the receiver has no way of knowing when the 786 sender crosses ssthresh (the "slow start threshold") and begins 787 using the congestion avoidance algorithm. If receivers follow 788 recommendations for increased initial windows, disabling delayed 789 ACKs during an increased initial window would open the TCP 790 window more rapidly without doubling ACK traffic in general. 791 However, this scheme might double ACK traffic if most 792 connections remain in slow-start. 794 Recommendation: ACK only the first segment on a new connection 795 with no delay. 797 4.3.3 Terminating Slow Start 799 New mechanisms [ADGGHOSSTT98] are being proposed to improve 800 TCP's adaptive properties such that the available bandwidth is 801 better utilized while reducing the possibility of congesting the 802 network. This results in the closing of the congestion window to 803 1 segment (which precludes fast retransmit), and the subsequent 804 slow start phase. 806 Theoretically, an optimum value for slow-start threshold 807 (ssthresh) allows connection bandwidth utilization to ramp up as 808 aggressively as possible without "overshoot" (using so much 809 bandwidth that packets are lost and congestion avoidance 810 procedures are invoked). 812 Recommendation: Estimating the slow start threshold is not 813 recommended. Although this would be helpful if we knew how to do 814 it, rough consensus on the tcp-impl and tcp-sat mailing lists is 815 that in non-trivial operational networks there is no reliable 816 method to probe during TCP startup and estimate the bandwidth 817 available. 819 4.3.4 Generating ACKs during Slow Start 821 Mitigations that inject additional ACKs (whether 822 "ACK-first-segment" or "ACK-every-segment-during-slow-start") 823 beyond what today's conformant TCPs inject are only applicable 824 during the slow-start phases of a connection. After an initial 825 exchange, the connection usually completes slow-start, so TCPs 826 only inject additional ACKs when (1) the connection is closed, 827 and a new connection is opened, or (2) the TCPs handle idle 828 connection restart correctly by performing slow start. 830 Item (1) is typical when using HTTP/1.0, in which each 831 request-response transaction requires a new connection. 832 Persistent connections in HTTP/1.1 help in maintaining a 833 connection in congestion avoidance instead of constantly 834 reverting to slow-start. Because of this, these optimizations 835 which are only enabled during slow-start do not get as much 836 of a chance to act. Item (2), of course, is independent of 837 HTTP version. 839 4.4 ACK Spacing 841 During slow start, the sender responds to the incoming ACK 842 stream by transmitting N+1 segments for each ACK, where N is the 843 number of new segments acknowledged by the incoming ACK. This 844 results in data being sent at twice the speed at which it can be 845 processed by the network. Accordingly, queues will form, and 846 due to insufficient buffering at the bottleneck router, packets 847 may get dropped before the link's capacity is full. 849 Spacing out the ACKs effectively controls the rate at which the 850 sender will transmit into the network, and may result in little 851 or no queueing at the bottleneck router [ACKSPACING]. 852 Furthermore, ack spacing reduces the size of the bursts. 854 Recommendation: No recommendation at this time. Continue 855 monitoring research in this area. 857 4.5 Delayed Duplicate Acknowlegements 859 As was mentioned above, link-layer retransmissions may decrease 860 the BER enough that congestion accounts for most of packet 861 losses; still, nothing can be done about interruptions due to 862 handoffs, moving beyond wireless coverage, etc. In this 863 scenario, it is imperative to prevent interaction between 864 link-layer retransmission and TCP retransmission as these layers 865 duplicate each other's efforts. In such an environment it may 866 make sense to delay TCP's efforts so as to give the link-layer a 867 chance to recover. With this in mind, the Delayed Dupacks [MV97, 868 Vaidya99] scheme selectively delays duplicate acknowledgements 869 at the receiver. It is preferrable to allow a local mechanism 870 to resolve a local problem, instead of invoking TCP's end-to-end 871 mechanism and incurring the associated costs, both in terms of 872 wasted bandwidth and in terms of its effect on TCP's window 873 behavior. 875 The Delayed Dupacks scheme can be used despite IP encryption 876 since the intermediate node does not need to examine the TCP 877 headers. 879 Currently, it is not well understood how long the receiver 880 should delay the duplicate acknowledgments. In particular, the 881 impact of wireless medium access control (MAC) protocol on the 882 choice of delay parameter needs to be studied. The MAC 883 protocol may affect the ability to choose the appropriate 884 delay (either statically or dynamically). In general, 885 significant variabilities in link-level retransmission times 886 can have an adverse impact on the performance of the Delayed 887 Dupacks scheme. Furthermore, as discussed later in section 888 4.10.3, Delayed Dupacks and some other schemes (such as Snoop 889 [SNOOP]) are only beneficial in certain types of network 890 links. 892 Recommendation: Delaying duplicate acknowledgements may be 893 useful in specific network topologies, but a general 894 recommendation requires further research and experience. 896 4.6 Selective Acknowledgements [RFC2018] 898 SACK may not be useful in many LTNs, according to Section 1.1 of 899 [TCPHP]. In particular, SACK is more useful in the LFN regime, 900 especially if large windows are being used, because there is a 901 considerable probability of multiple segment losses per window. In 902 the LTN regime, TCP windows are much smaller, and burst errors 903 must be much longer in duration in order to damage multiple 904 segments. 906 Accordingly, the complexity of SACK may not be justifiable, unless 907 there is a high probability of burst errors and congestion on the 908 wireless link. A desire for compatibility with TCP recommendations 909 for non-LTN environments may dictate LTN support for SACK anyway. 911 [AGS98] recommends use of SACK with Large TCP Windows in satellite 912 environments, and notes that this implies support for PAWS 913 (Protection Against Wrapped Sequence space) and RTTM (Round Trip 914 Time Measurement) as well. 916 Berkeley's SNOOP protocol research [SNOOP] indicates that SACK 917 does improve throughput for SNOOP when multiple segments are 918 lost per window [BPSK96]. SACK allows SNOOP to recover from 919 multi-segment losses in one round-trip. In this case, the mobile 920 device needs to implement some form of selective 921 acknowledgements. If SACK is not used, TCP may enter congestion 922 avoidance as the time needed to retransmit the lost segments 923 may be greater than the retranmission timer. 925 Recommendation: Implement SACK now for compatibility with other 926 TCPs and improved performance with SNOOP. 928 4.7 Detecting Corruption Loss 930 4.7.1 Without Explicit Notification 932 In the absence of explicit notification from the network, some 933 researchers have suggested statistical methods for congestion 934 avoidance [Jain89, WC91, VEGAS]. A natural extension of these 935 heuristics would enable a sender to distinguish between losses 936 caused by congestion and other causes. The research results on 937 the reliability of sender-based heuristics is unfavorable [BV97, 938 BV98]. [BV98a] reports better results in constrained environments 939 using packet inter-arrival times measured at the receiver, but 940 highly-variable delay - of the type encountered in wireless 941 environments during intercell handoff - confounds these 942 heuristics. 944 Recommendation: No recommendation at this time - continue to 945 monitor research results. 947 4.7.2 With Explicit Notifications 949 With explicit notification from the network it is possible to 950 determine when a loss is due to congestion. Several proposals 951 along these lines include: 953 - Explicit Loss Notification (ELN) [BPSK96] 955 - Explicit Bad State Notification (EBSN) [BBKVP96] 957 - Explicit Loss Notification to the Receiver (ELNR), and 958 Explicit Delayed Dupack Activation Notification (EDDAN) 959 (notifications to mobile receiver) [MV97] 961 - Explicit Congestion Notification (ECN) [ECN] 963 Of these proposals, Explicit Congestion Notification (ECN) 964 seems closest to deployment on the Internet, and will provide 965 some benefit for TCP connections on long thin networks (as well 966 as for all other TCP connections). 968 Recommendation: No recommendation at this time. Schemes like 969 ELNR and EDDAN [MV97], in which the only systems that need to 970 be modified are the intermediate node and the mobile device, are 971 slated for adoption pending further research. However, this 972 solution has some limitations. Since the intermediate node must 973 have access to the TCP headers, the IP payload must not be 974 encrypted. 976 ECN uses the TOS byte in the IP header to carry congestion 977 information (ECN-capable and Congestion-encountered). This byte 978 is not encrypted in IPSEC, so ECN can be used on TCP connections 979 that are encrypted using IPSEC. 981 Recommendation: Implement ECN. In spite of this, mechanisms 982 for explicit corruption notification are still relevant and 983 should be tracked. 985 Note: ECN provides useful information to avoid deteriorating 986 further a bad situation, but has some limitations for wireless 987 applications. Absence of packets marked with ECN should not be 988 interpreted by ECN-capable TCP connections as a green light for 989 aggressive retransmissions. On the contrary, during periods of 990 extreme network congestion routers may drop packets marked with 991 explicit notification because their buffers are exhausted - 992 exactly the wrong time for a host to begin retransmitting 993 aggressively. 995 4.8 Active Queue Management 997 As has been pointed out above, TCP responds to congestion by 998 closing down the window and invoking slow start. Long-delay 999 networks take a particularly long time to recover from this 1000 condition. Accordingly, it is imperative to avoid congestion in 1001 LTNs. To remedy this, active queue management techniques have been 1002 proposed as enhancements to routers throughout the Internet [RED]. 1003 The primary motivation for deployment of these mechanisms is to 1004 prevent "congestion collapse" (a severe degradation in service) by 1005 controlling the average queue size at the routers. As the average 1006 queue length grows, Random Early Detection [RED] increases the 1007 possibility of dropping packets. 1009 The benefits are: 1011 - Reduce packet drops in routers. By dropping a few packets 1012 before severe congestion sets in, RED avoids dropping 1013 bursts of packets. In other words, the objective is to 1014 drop m packets early to prevent n drops later on, where 1015 m is less than n. 1017 - Provide lower delays. This follows from the smaller queue 1018 sizes, and is particularly important for interactive 1019 applications, for which the inherent delays of wireless 1020 links already push the user experience to the limits of 1021 the non-acceptable. 1023 - Avoid lock-outs. Lack of resources in a router (and the 1024 resultant packet drops) may, in effect, obliterate 1025 throughput on certain connections. Because of active queue 1026 management, it is more probable for an incoming packet to 1027 find available buffer space at the router. 1029 Active Queue Management has two components: (1) routers detect 1030 congestion before exhausting their resources, and (2) they 1031 provide some form of congestion indication. Dropping packets 1032 via RED is only one example of the latter. Another way to 1033 indicate congestion is to use ECN [ECN] as discussed above under 1034 "Detecting Corruption Loss: With Explicit Notifications." 1036 Recommendation: RED is currently being deployed in the Internet, 1037 and LTNs should follow suit. ECN deployment should complement RED's. 1039 4.9 Scheduling Algorithms 1041 Active queue management helps control the length of the queues. 1042 Additionally, a general solution requires replacing FIFO with 1043 other scheduling algorithms that improve: 1045 1. Fairness (by policing how different packet streams utilize 1046 the available bandwidth), and 1048 2. Throughput (by improving the transmitter's radio channel 1049 utilization). 1051 For example, fairness is necessary for interactive applications 1052 (like telnet or web browsing) to coexist with bulk transfer 1053 sessions. Proposals here include: 1055 - Fair Queueing (FQ) [Demers90] 1057 - Class-based Queueing (CBQ) [Floyd95] 1059 Even if they are only implemented over the wireless link portion 1060 of the communication path, these proposals are attractive in 1061 wireless LTN environments, because new connections for interactive 1062 applications can have difficulty starting when a bulk TCP transfer 1063 has already stabilized using all available bandwidth. 1065 In our base architecture described above, the mobile device 1066 typically communicates directly with only one wireless peer at a 1067 given time: the intermediate node. In some W-WANs, it is 1068 possible to directly address other mobiles within the same 1069 cell. Direct communication with each such wireless peer may 1070 traverse a spatially distinct path, each of which may exhibit 1071 statistically independent radio link characteristics. Channel 1072 State Dependent Packet Scheduling (CSDP) [BBKT96] tracks the 1073 state of the various radio links (as defined by the target 1074 devices), and gives preferential treatment to packets destined 1075 for radio links in a "good" state. This avoids attempting to 1076 transmit to (and expect acknowledgements from) a peer on a "bad" 1077 radio link, thus improving throughput. 1079 A further refinement of this idea suggests that both fairness and 1080 throughput can be improved by combining a wireless-enhanced CBQ 1081 with CSDP [FSS98]. 1083 Recommendation: No recommendation at this time, pending further 1084 study. 1086 4.10 Split TCP and Performance-Enhancing Proxies (PEPs) 1088 Given the dramatic differences between the wired and the 1089 wireless links, a very common approach is to provide some 1090 impedance matching where the two different technologies meet: at 1091 the intermediate node. 1093 The idea is to replace an end-to-end TCP connection with two 1094 clearly distinct connections: one across the wireless link, the 1095 other across its wireline counterpart. Each of the two resulting 1096 TCP sessions operates under very different networking 1097 characteristics, and may adopt the policies best suited to its 1098 particular medium. For example, in a specific LTN topology it may 1099 be desirable to modify TCP Fast Retransmit to resend after 1100 the first duplicate ack and Fast Recovery to not shrink the 1101 congestion window if the LTN link has an extremely long 1102 RTT, is known to not reorder packets, and is not subject 1103 to congestion. Moreover, on a long-delay link or on a link 1104 with a relatively high bandwidth-delay product it may be 1105 desirable to "slow-start" with a relatively large initial 1106 window, even larger than four segments. While these kinds 1107 of TCP modifications can be negotiated to be employed over 1108 the LTN link, they would not be deployed end-to-end over 1109 the global Internet. In LTN topologies where the underlying 1110 link characteristics are known, a various similar types of 1111 performance enhancements can be employed without endangering 1112 operations over the global Internet. 1114 In some proposals, in addition to a PEP mechanism at the 1115 intermediate node, custom protocols are used on the wireless 1116 link (for example, [WAP], [YB94] or [MOWGLI]). 1118 Even if the gains from using non-TCP protocols are moderate or 1119 better, the wealth of research on optimizing TCP for wireless, and 1120 compatibility with the Internet are compelling reasons to adopt 1121 TCP on the wireless link (enhanced as suggested in section 5 1122 below). 1124 4.10.1 Split TCP Approaches 1126 Split-TCP proposals include schemes like I-TCP [ITCP] and MTCP 1127 [YB94] which achieve performance improvements by abandoning 1128 end-to-end semantics. 1130 The Mowgli architecture [MOWGLI] proposes a split approach with 1131 support for various enhancements at all the protocol layers, not 1132 only at the transport layer. Mowgli provides an option to 1133 replace the TCP/IP core protocols on the LTN link with a custom 1134 protocol that is tuned for LTN links [KRLKA97]. In addition, 1135 the protocol provides various features that are useful with 1136 LTNs. For example, it provides priority-based multiplexing of 1137 concurrent connections together with shared flow control, thus 1138 offering link capacity to interactive applications in a timely 1139 manner even if there are bandwidth-intensive background 1140 transfers. Also with this option, Mowgli preserves the socket 1141 semantics on the mobile device so that legacy applications can 1142 be run unmodified. 1144 Employing split TCP approaches have several benefits as well as 1145 drawbacks. Benefits related to split TCP approaches include the 1146 following: 1148 - Splitting the end-to-end TCP connection into two parts is a 1149 straightforward way to shield the problems of the wireless 1150 link from the wireline Internet path, and vice versa. Thus, 1151 a split TCP approach enables applying local solutions to 1152 the local problems on the wireless link. For example, it 1153 automatically solves the problem of distinguishing congestion 1154 related packet losses on the wireline Internet and packet 1155 losses due to transmission error on the wireless link as these 1156 occur on separate TCP connections. Even if both segments 1157 experience congestion, it may be of a different nature and 1158 may be treated as such. Moreover, temporary disconnections 1159 of the wireless link can be effectively shielded from the 1160 wireline Internet. 1162 - When one of the TCP connections crosses only a single hop 1163 wireless link or a very limited number of hops, some or all 1164 link characteristics for the wireless TCP path are known. For 1165 example, with a particular link we may know that the link 1166 provides reliable delivery of packets, packets are not 1167 delivered out of order, or the link is not subject to 1168 congestion. Having this information for the TCP path one could 1169 expect that defining the TCP mitigations to be employed 1170 becomes a significantly easier task. In addition, several 1171 mitigations that cannot be employed safely over the global 1172 Internet, can be successfully employed over the wireless link. 1174 - Splitting one TCP connection into two separate ones allows 1175 much earlier deployment of various recent proposals to improve 1176 TCP performance over wireless links; only the TCP 1177 implementations of the mobile device and intermediate node 1178 need to be modified, thus allowing the vast number of Internet 1179 hosts to continue running the legacy TCP implementations 1180 unmodified. Any mitigations that would require modification of 1181 TCP in these wireline hosts may take far too long to become 1182 widely deployed. 1184 - Allows exploitation of various application level enhancements 1185 which may give significant performance gains (see section 1186 4.10.2). 1188 Drawbacks related to split TCP approaches include the 1189 following: 1191 - One of the main criticisms against the split TCP approaches is 1192 that it breaks TCP end-to-end semantics. This has various 1193 drawbacks some of which are more severe than others. The most 1194 detrimental drawback is probably that splitting the TCP 1195 connection disables end-to-end usage of IP layer security 1196 mechanisms, precluding the application of IPSec to achieve 1197 end-to-end security. Still, IPSec could be employed separately 1198 in each of the two parts, thus requiring the intermediate node 1199 to become a party to the security association between the 1200 mobile device and the remote host. This, however, is an 1201 undesireable or unacceptable alternative in most cases. Other 1202 security mechanisms above the transport layer, like TLS 1203 [RFC2246] or SOCKS [RFC1928], should be employed for 1204 end-to-end security. 1206 - Another drawback of breaking end-to-end semantics is that 1207 crashes of the intermediate node become unrecoverable 1208 resulting in termination of the TCP connections. Whether this 1209 should be considered a severe problem depends on the expected 1210 frequency of such crashes. 1212 - In many occasions claims have been stated that if TCP 1213 end-to-end semantics is broken, applications relying on TCP to 1214 provide reliable data delivery become more vulnerable. This, 1215 however, is an overstatement as a well-designed application 1216 should never fully rely on TCP in achieving end-to-end 1217 reliability at the application level. First, current APIs to 1218 TCP, such as the Berkeley socket interface, do not allow 1219 applications to know when an TCP acknowledgement for 1220 previously sent user data arrives at TCP sender. Second, even 1221 if the application is informed of the TCP acknowledgements, 1222 the sending application cannot know whether the receiving 1223 application has received the data: it only knows that the data 1224 reached the TCP receive buffer at the receiving end. Finally, 1225 in order to achieve end-to-end reliability at the application 1226 level an application level acknowledgement is required to 1227 confirm that the receiver has taken the appropriate actions on 1228 the data it received. 1230 - When a mobile device moves, it is subject to handovers by the 1231 serving base station. If the base station acts as the 1232 intermediate node for the split TCP connection, the state of 1233 both TCP endpoints on the previous intermediate node must be 1234 transferred to the new intermediate node to ensure continued 1235 operation over the split TCP connection. This requires extra 1236 work and causes overhead. However, in most of the W-WAN 1237 wireless networks, unlike in W-LANs, the W-WAN base station 1238 does not provide the mobile device with the connection point 1239 to the wireline Internet (such base stations may not even have 1240 an IP stack). Instead, the W-WAN network takes care of the 1241 mobility and retains the connection point to the wireline 1242 Internet unchanged while the mobile device moves. Thus, TCP 1243 state handover is not required in most W-WANs. 1245 - The packets traversing through all the protocol layers up to 1246 transport layer and again down to the link layer result in 1247 extra overhead at the intermediate node. In case of LTNs with 1248 low bandwidth, this extra overhead does not cause serious 1249 additional performance problems unlike with W-LANs that 1250 typically have much higher bandwidth. 1252 - Split TCP proposals are not applicable to networks with 1253 asymmetric routing. Deploying a split TCP approach requires 1254 that traffic to and from the mobile device be routed through 1255 the intermediate node. With some networks, this cannot be 1256 accomplished, or it requires that the intermediate node is 1257 located several hops away from the wireless network edge which 1258 in turn is unpractical in many cases and may result in 1259 non-optimal routing. 1261 - Split TCP, as the name implies, does not address problems 1262 related to UDP. 1264 It should noted that using split TCP does not necessarily 1265 exclude simultaneous usage of IP for end-to-end connectivity. 1266 Correct usage of split TCP should be managed per application or 1267 per connection and should be under the end-user control so that 1268 the user can decide whether a particular TCP connection or 1269 application makes use of split TCP or whether it operates 1270 end-to-end directly over IP. 1272 Recommendation: Split TCP proposals that alter TCP semantics are 1273 not recommended. Deploying custom protocols on the wireless 1274 link, such as MOWGLI proposes is not recommended, because this 1275 note gives preference to (1) improving TCP instead of designing 1276 a custom protocol and (2) allowing end-to-end sessions at all 1277 times. 1279 4.10.2 Application Level Proxies 1281 Nowadays, application level proxies are widely used in the 1282 Internet. Such proxies include Web proxy caches, relay MTAs 1283 (Mail Transfer Agents), and secure transport proxies (e.g., 1284 SOCKS). In effect, employing an application level proxy results 1285 in a "split TCP connection" with the proxy as the intermediary. 1286 Hence, some of the problems present with wireless links, such as 1287 combining of a congested wide-area Internet path with a wireless 1288 LTN link, are automatically alleviated to some extent. 1290 The application protocols often employ plenty of (unnecessary) 1291 round trips, lots of headers and inefficient encoding. Even 1292 unnecessary data may get delivered over the wireless link in 1293 regular application protocol operation. In many cases a 1294 significant amount of this overhead can be reduced by simply 1295 running an application level proxy on the intermediate node. 1296 With LTN links, significant additional improvement can be 1297 achieved by introducing application level proxies with 1298 application-specific enhancements. Such a proxy may employ an 1299 enhanced version of the application protocol over the wireless 1300 link. In an LTN environment enhancements at the application 1301 layer may provide much more notable performance improvements 1302 than any transport level enhancements. 1304 The Mowgli system provides full support for adding application 1305 level agent-proxy pairs between the client and the server, the 1306 agent on the mobile device and the proxy on the intermediate 1307 node. Such a pair may be either explicit or fully transparent to 1308 the applications, but it is, at all times, under the end-user 1309 control. Good examples of enhancements achieved with 1310 application-specific proxies include Mowgli WWW [LAKLR95], 1311 [LHKR96] and WebExpress [HL96], [CTCSM97]. 1313 Recommendation: Usage of application level proxies is 1314 conditionally recommended: an application must be proxy enabled 1315 and the decision of employing a proxy for an application must be 1316 under the user control at all times. 1318 4.10.3 Snoop and its Derivatives 1320 Berkeley's SNOOP protocol [SNOOP] is a hybrid scheme mixing 1321 link-layer reliability mechanisms with the split connection 1322 approach. It is an improvement over split TCP approaches in that 1323 end-to-end semantics are retained. SNOOP does two things: 1325 1. Locally (on the wireless link) retransmit lost packets, 1326 instead of allowing TCP to do so end-to-end. 1328 2. Suppress the duplicate acks on their way from the receiver 1329 back to the sender, thus avoiding fast retransmit and 1330 congestion avoidance at the latter. 1332 Thus, the Snoop protocol is designed to avoid unnecessary fast 1333 retransmits by the TCP sender, when the wireless link layer 1334 retransmits a packet locally. Consider a system that does not 1335 use the Snoop agent. Consider a TCP sender S that sends packets 1336 to receiver R via an intermediate node IN. Assume that the 1337 sender sends packet A, B, C, D, E (in that order) which are 1338 forwarded by IN to the wireless receiver R. Assume that the 1339 intermediate node then retransmits B subsequently, because the 1340 first transmission of packet B is lost due to errors on the 1341 wireless link. In this case, receiver R receives packets A, C, 1342 D, E and B (in that order). Receipt of packets C, D and E 1343 triggers duplicate acknowledgements. When the TCP sender 1344 receives three duplicate acknowledgements, it triggers fast 1345 retransmit (which results in a retransmission, as well as 1346 reduction of congestion window). The fast retransmit occurs 1347 despite the link level retransmit on the wireless link, 1348 degrading throughput. 1350 SNOOP [SNOOP] deals with this problem by dropping TCP dupacks 1351 appropriately (at the intermediate node). The Delayed Dupacks 1352 (see section 4.5) attempts to approximate Snoop without 1353 requiring modifications at the intermediate node. Such schemes 1354 are needed only if the possibility of a fast retransmit due to 1355 wireless errors is non-negligible. In particular, if the 1356 wireless link uses a stop-and-go protocol (or otherwise delivers 1357 packets in-order), then these schemes are not very beneficial. 1358 Also, if the bandwidth-delay product of the wireless link is 1359 smaller than four segments, the probability that the 1360 intermediate node will have an opportunity to send three new 1361 packets before a lost packet is retransmitted is small. Since 1362 at least three dupacks are needed to trigger a fast retransmit, 1363 with a wireless bandwidth-delay product less than four packets, 1364 schemes such as Snoop and Delayed Dupacks would not be necessary 1365 (unless the link layer is not designed properly). Conversely, 1366 when the wireless bandwidth-delay product is large enough, Snoop 1367 can provide significant performance improvement (compared with 1368 standard TCP). For further discussion on these topics, please 1369 refer to [Vaidya99]. 1371 The Delayed Dupacks scheme tends to provide performance benefit 1372 in environments where Snoop performs well. In general, 1373 performance improvement achieved by the Delayed Dupacks scheme 1374 is a function of packet loss rates due to congestion and 1375 transmission errors. When congestion-related losses occur, the 1376 Delayed Dupacks scheme unnecessarily delays retransmission. 1377 Thus, in the presence of congestion losses, the Delayed Dupacks 1378 scheme cannot achieve the same performance improvement as Snoop. 1379 However, simulation results [Vaidya99] indicate that the Delayed 1380 Dupacks can achieve a significant improvement in performance 1381 despite moderate congestion losses. 1383 WTCP [WTCP] is similar to SNOOP in that it preserves end-to-end 1384 semantics. In WTCP, the intermediate node uses a complex scheme 1385 to hide the time it spends recovering from local errors across 1386 the wireless link (this typically includes retransmissions due 1387 to error recovery, but may also include time spent dealing with 1388 congestion). The idea is for the sender to derive a smooth 1389 estimate of round-trip time. In order to work effectively, it 1390 assumes that the TCP endpoints implement the Timestamps option 1391 in RFC 1323 [TCPHP]. Unfortunately, support for RFC 1323 in TCP 1392 implementations is not yet widespread. Beyond this, WTCP 1393 requires changes only at the intermediate node. 1395 SNOOP and WTCP require the intermediate node to examine and 1396 operate on the traffic between the portable wireless device and 1397 the TCP server on the wired Internet. SNOOP and WTCP do not work 1398 if the IP traffic is encrypted, unless, of course, the 1399 intermediate node shares the security association between the 1400 mobile device and its end-to-end peer. They also require that 1401 both the data and the corresponding ACKs traverse the same 1402 intermediate node. Furthermore, if the intermediate node 1403 retransmits packets at the transport layer across the wireless 1404 link, this may duplicate efforts by the link-layer. SNOOP has 1405 been described by its designers as a TCP-aware link-layer. This 1406 is the right approach: the link and network layers can be much 1407 more aware of each other than traditional OSI layering 1408 suggests. 1410 Encryption of IP packets via IPSEC's ESP header (in either 1411 transport or tunnel mode) renders the TCP header and payload 1412 unintelligible to the intermediate node. This precludes SNOOP 1413 (and WTCP) from working, because it needs to examine the TCP 1414 headers in both directions. Possible solutions involve: 1416 - making the SNOOP (or WTCP) intermediate node a party to the 1417 security association between the client and the server 1419 - IPSEC tunneling mode, terminated at the SNOOPing intermediate 1420 node 1422 However, these techniques require that users trust intermediate 1423 nodes. Users valuing both privacy and performance should use 1424 SSL or SOCKS for end-to-end security. These, however, are 1425 implemented above the transport layer, and are not as resistant 1426 to some security attacks (for example, those based on guessing 1427 TCP sequence numbers) as IPSEC. 1429 Recommendation: Implement SNOOP on intermediate nodes now. 1430 Research results are encouraging, and it is an "invisible" 1431 optimization in that neither the client nor the server needs to 1432 change, only the intermediate node (for basic SNOOP without 1433 SACK). However, as discussed above there is little or no benefit 1434 from implementing SNOOP if: 1436 1. The wireless link provides reliable, in-order packet 1437 delivery, or, 1439 2. The bandwidth-delay product of the wireless link is 1440 smaller than four segments. 1442 4.10.4 PEPs to handle Periods of Disconnection 1444 Periods of disconnection are very common in wireless networks, 1445 either during handoff, due to lack of resources (dropped 1446 connections) or natural obstacles. During these periods, a TCP 1447 sender does not receive the expected acknowledgements. Upon 1448 expiration of the retransmit timer, this causes TCP to close its 1449 congestion window with all the related drawbacks. 1450 Re-transmitting packets is useless since the connection is 1451 broken. [M-TCP] aims at enabling TCP to better handle handoffs 1452 and periods of disconnection, while preserving end-to-end 1453 semantics. M-TCP adds an element: supervisor host (SH-TCP) at 1454 the edge of the wireless network. 1456 This intermediate node monitors the traffic coming from the 1457 sender to the mobile device. It does not break end-to-end 1458 semantics because the ACKs sent from the intermediate node to 1459 the sender are effectively the ones sent by the mobile node. The 1460 principle is to generally leave the last byte unacknowledged. 1461 Hence, SH-TCP could shut down the sender's window by sending 1462 the ACK for the last byte with a window set to zero. Thus the 1463 sender will go to persist mode. 1465 The second optimization is done on both the intermediate node 1466 and the mobile host. On the latter, TCP is aware of the current 1467 state of the connection. In the event of a disconnection, it is 1468 capable of freezing all timers. Upon reconnection, the mobile 1469 sends a specially marked ACK with the number of the highest byte 1470 received. The intermediate node assumes that the mobile is 1471 disconnected because it monitors the flow on the wireless link, 1472 so in the absence of acknowledgments from the mobile, it will 1473 inform SH-TCP, which will send the ACK closing the sender window 1474 as described in the previous paragraph. The intermediate node 1475 learns that the mobile is again connected when it receives a 1476 duplicate acknowledgment marked as reconnected. At this point 1477 it sends a duplicate ACK to the sender and grows the window. 1478 The sender exits persist mode and resumes transmitting at 1479 the same rate as before. It begins by retransmitting any data 1480 previously unacknowledged by the mobile node. Non overlapping 1481 or non soft handoffs are lightweight because the previous 1482 intermediate system can shrink the window, and the new one 1483 modifies it as soon as it has received an indication from 1484 the mobile. 1486 Recommendation: M-TCP is not slated for adoption at this moment, 1487 because of the higly experimental nature of the proposal, and 1488 the uncertainty that TCP/IP implementations handle zero window 1489 updates correctly. Continue tracking developments in this space. 1491 4.11 Header Compression Alternatives 1493 Because Long Thin Networks are bandwidth-constrained, compressing 1494 every byte out of over-the-air segments is worth while. 1496 Mechanisms for TCP and IP header compression defined in 1497 [RFC1144, IPHC, IPHC-RTP, IPHC-PPP] provide the following 1498 benefits: 1500 - Improve interactive response time 1502 - Allow using small packets for bulk data with good line 1503 efficiency 1505 - Allow using small packets for delay sensitive low 1506 data-rate traffic 1508 - Decrease header overhead (for a common TCP segment size of 1509 512 the header overhead of IPv4/TCP within a Mobile IP 1510 tunnel can decrease from 11.7 to less than 1 per cent. 1512 - Reduce packet loss rate over lossy links (because of the 1513 smaller cross-section of compressed packets). 1515 Van Jacobson (VJ) header compression [RFC1144] describes a 1516 Proposed Standard for TCP Header compression that is widely 1517 deployed. It uses TCP timeouts to detect a loss of 1518 synchronization between the compressor and decompressor. [IPHC] 1519 includes an explicit request for transmission of uncompressed 1520 headers to allow resynchronization without waiting for a TCP 1521 timeout (and executing congestion avoidance procedures). 1523 Recommendation: Implement [IPHC], in particular as it relates 1524 to IP-in-IP [RFC2003] and Minimal Encapsulation [RFC2004] for 1525 Mobile IP, as well as TCP header compression for lossy links 1526 and links that reorder packets. PPP capable devices should 1527 implement [IPHC-PPP]. VJ header compression may optionally 1528 be implemented as it is a widely deployed Proposed Standard. 1529 However, it should only be enabled when operating over 1530 reliable LTNs, because even a single bit error most probably 1531 would result in a full TCP window being dropped, followed by 1532 a costly recovery via slow-start. 1534 4.12 Payload Compression 1536 Compression of IP payloads is also desirable. "IP Payload 1537 Compression Protocol (IPComp)" [IPPCP] defines a framework where 1538 common compression algorithms can be applied to arbitrary IP 1539 segment payloads. IP payload compression is something of a niche 1540 optimization. It is necessary because IP-level security converts 1541 IP payloads to random bitstreams, defeating commonly-deployed 1542 link-layer compression mechanisms which are faced with payloads 1543 that have no redundant "information" that can be more compactly 1544 represented. 1546 However, many IP payloads are already compressed (images, audio, 1547 video, "zipped" files being FTPed), or are already encrypted above 1548 the IP layer (SSL/TLS, etc.). These payloads will not "compress" 1549 further, limiting the benefit of this optimization. 1551 HTTP/1.1 already supports compression of the message body. 1553 For example, to use zlib compression the relevant directives 1554 are: "Content-Encoding: deflate" and "Accept-Encoding: 1555 deflate" [HTTP-PERF]. 1557 HTTP-NG is considering supporting compression of resources at the 1558 HTTP level, which would provide equivalent benefits for common 1559 compressible MIME types like text/html. This will reduce the need 1560 for IPComp. If IPComp is deployed more rapidly than HTTP-NG, 1561 IPComp compression of HTML and MIME headers would be beneficial. 1563 In general, application-level compression can often outperform 1564 IPComp, because of the opportunity to use compression dictionaries 1565 based on knowledge of the specific data being compressed. 1567 Recommendation: IPComp may optionally be implemented. Track 1568 HTTP-NG standardization and deployment for now. HTTP/1.1 1569 compression using zlib SHOULD be implemented. 1571 4.13 TCP Control Block Interdependence [Touch97] 1573 TCP maintains per-connection information such as connection state, 1574 current round-trip time, congestion control or maximum segment 1575 size. Sharing information between two consecutive connections or 1576 when creating a new connection while the first is still 1577 active to the same host may improve performance of the latter 1578 connection. The principle could easily be extended to sharing 1579 information amongst systems in a LAN not just within a given 1580 system. [Touch97] describes cache update for both cases. 1582 Users of W-WAN devices frequently request connections to the same 1583 servers or set of servers. For example, in order to read their 1584 email or to initiate connections to other servers, the devices may 1585 be configured to always use the same email server or WWW proxy. 1586 The main advantage of this proposal is that it relieves the 1587 application of the burden of optimizing the transport layer. In 1588 order to improve the performance of TCP connections, this 1589 mechanism only requires changes at the wireless device. 1591 In general, this scheme should improve the dynamism of connection 1592 setup without increasing the cost of the implementation. 1594 Recommendation: This mechanism is recommended, although HTTP/1.1 1595 with its persistent connections may partially achieve the same 1596 effect without it. Other applications (even HTTP/1.0) may find 1597 it useful. Continue monitoring research on this. In particular, 1598 work on a "Congestion Manager" [CM] may generalize this concept 1599 of sharing information among protocols and applications with 1600 a view to making them more adaptable to network conditions. 1602 5 Summary of Recommended Optimizations 1604 The table below summarizes our recommendations with regards to the 1605 main proposals mentioned above. 1607 The first column, "Stability of the Proposal," refers to the 1608 maturity of the mechanism in question. Some proposals are 1609 being pursued within the IETF in a somewhat open fashion. An 1610 IETF proposal is either an Internet Drafts (I-D) or a Request 1611 for Comments (RFC). The former is a preliminary version. There 1612 are several types of RFCs. A Draft Standards (DS) is standards 1613 track, and carries more weight than a Proposed Standard (PS), 1614 which may still undergo revisions. Informational or Experimental 1615 RFCs do not specify a standard. Other proposals are isolated 1616 efforts with little or no public review, and unknown chances 1617 of garnering industry backing. 1619 "Implemented at" indicates which participant in a TCP session 1620 must be modified to implement the proposal. Legacy servers 1621 typically cannot be modified, so this column indicates whether 1622 implementation happens at either or both of the two nodes under 1623 some control: mobile device and intermediate node. The symbols 1624 used are: WS (wireless sender, that is, the mobile device's TCP 1625 send operation must be modified), WR (wireless receiver, that 1626 is, the mobile device's TCP receive operation must be modified), 1627 WD (wireless device, that is, modifications at the mobile device 1628 are not specific to either TCP send or receive), IN 1629 (intermediate node) and NI (network infrastructure). These 1630 entities are to be understood within the context of Section 1.1 1631 ("Network Architecture"). NA simply means "not applicable." 1633 The "Recommendation" column captures our suggestions. 1634 Some mechanisms are endorsed for immediate adoption, others 1635 need more evidence and research, and others are not recommended. 1637 Name Stability of Implemented Recommendation 1638 the Proposal at 1639 ==================== ============= =========== ================= 1641 Increased Initial RFC 2581 (PS) WS Yes 1642 Window (initial_window=2) 1644 Disable delayed ACKs NA WR When stable 1645 during slow start 1647 Byte counting NA WS No 1648 instead of ACK 1649 counting 1651 TCP Header RFC 1144 (PS) WD Yes 1652 compression for PPP IN (see 4.11) 1654 IP Payload RFC 2393 (PS) WD Yes 1655 Compression (simultaneously 1656 (IPComp) needed on Server) 1658 Header RFC 2507 (PS), WD Yes 1659 Compression RFC 2509 (PS) IN (For IPv4, TCP and 1660 Mobile IP, PPP) 1662 SNOOP plus SACK In limited use IN Yes 1663 WD (for SACK) 1665 Fast retransmit/fast RFC 2581 (PS) WD Yes (should be 1666 recovery there already) 1668 Transaction/TCP RFC 1644 WD No 1669 (Experimental) (simultaneously 1670 needed on Server) 1672 Estimating Slow NA WS No 1673 Start Threshold 1674 (ssthresh) 1676 Delayed Duplicate Not stable WR When stable 1677 Acknowledgements IN (for 1678 notifications) 1680 Class-based Queuing NA WD When stable 1681 on End Systems 1683 Explicit Congestion RFC 2481 (EXP) WD Yes 1684 Notification NI 1686 TCP Control Block RFC 2140 WD Yes 1687 Interdependence (Informational) (Track research) 1689 Of all the optimizations in the table above, only SNOOP plus SACK 1690 and Delayed duplicate acknowledgements are currently being 1691 proposed only for wireless networks. The others are being 1692 considered even for non-wireless applications. Their more general 1693 applicability attracts more attention and analysis from the 1694 research community. 1696 Of the above mechanisms, only Header Compression (for IP and TCP) 1697 and "SNOOP plus SACK" cease to work in the presence of IPSec. 1699 6 Conclusion 1701 In view of the unpredictable and problematic nature of long thin 1702 networks, arriving at an optimized transport is a daunting task. We 1703 have reviewed the existing proposals along with future research 1704 items. Based on this overview, we also recommend mechanisms for 1705 implementation in long thin networks (LTNs). 1707 7 Acknowledgements 1709 The authors are deeply indebted to the IETF tcpsat and tcpimpl 1710 working groups. The following individuals have also provided 1711 valuable feedback: Mark Allman (NASA), Vern Paxson (ACIRI), 1712 Raphi Rom (Technion/Sun), Charlie Perkins (Nokia), Peter Stark 1713 (Phone.com). 1715 8 Security Considerations 1717 The mechanisms discussed and recommended in this document have 1718 been proposed in previous publications. The security 1719 considerations outlined in the original discussions apply here 1720 as well. Several security issues are also discussed throughout 1721 this document. Additionally, we present below a non-exhaustive 1722 list of the most salient issues concerning our recommended 1723 mechanisms: 1725 - Larger Initial TCP Window Size 1727 No known security issues [RFC2414, RFC2581]. 1729 - Header Compression 1731 May be open to some denial of service attacks. But any 1732 attacker in a position to launch these attacks would have 1733 much stronger attacks at his disposal [IPHC, IPHC-RTP]. 1735 - Congestion Control, Fast Retransmit/Fast Recovery 1737 An attacker may force TCP connections to grind to a halt, 1738 or, more dangerously, behave more aggressively. The latter 1739 possibility may lead to congestion collapse, at least in 1740 some regions of the network [RFC2581]. 1742 - Explicit Congestion Notification 1744 It does not appear to increase the vulnerabilities in the 1745 network. On the contrary, it may reduce them by aiding in 1746 the identification of flows unresponsive to or non-compliant 1747 with TCP congestion control [ECN]. 1749 - Sharing of Network Performance Information (TCP Control Block 1750 Sharing and Congestion Manager module) 1752 Some information should not be shared. For example, TCP 1753 sequence numbers are used to protect against spoofing attacks. 1754 Even limiting the sharing to performance values leaves open 1755 the possibility of denial-of-service attacks [Touch97]. 1757 - Performance Enhancing Proxies 1759 These systems are men-in-the-middle from the point of view of 1760 their security vulnerabilities. Accordingly, they must be used 1761 with extreme care so as to prevent their being hijacked and 1762 misused. 1764 This last point is not to be underestimated: there is a general 1765 security concern whenever an intermediate node performs 1766 operations different from those carried out in an end-to-end 1767 basis. This is not specific to performance-enhancing proxies. 1768 In particular, there may be a tendency to forgo IPSEC-based 1769 privacy in order to allow, for example, a SNOOP module, header 1770 compression (TCP, UDP, RTP, etc), or HTTP proxies to work. 1772 Adding end-to-end security at higher layers (for example via RTP 1773 encryption, or via TLS encryption of the TCP payload) alleviates 1774 the problem. However, this still leaves protocol headers in the 1775 clear, and these may be exploited for traffic analysis and 1776 denial-of-service attacks. 1778 9 References 1780 [ACKSPACING] Partridge, C., "ACK Spacing for High Delay-Bandwidth 1781 Paths with Insufficient Buffering," September 1998. Internet-Draft 1782 draft-rfced-info-partridge-01.txt (work in progress). 1784 [ADGGHOSSTT98] Mark Allman, Spencer Dawkins, Dan Glover, Jim 1785 Griner, Tom Henderson, John Heidemann, Hans Kruse, Shawn 1786 Osterman, Keith Scott, Jeffrey Semke, Joe Touch, Diepchi Tran. 1787 Ongoing TCP Research Related to Satellites, October 1999. 1788 Internet-Draft draft-ietf-tcpsat-res-issues-12.txt (work in 1789 progress). 1791 [AGS98] Mark Allman, Dan Glover, Luis Sanchez. "Enhancing TCP 1792 Over Satellite Channels using Standard Mechanisms," RFC 2488 1793 (BCP 28), January 1999. 1795 [Allman98] Mark Allman. On the Generation and Use of TCP 1796 Acknowledgments. ACM Computer Communication Review, 28(5), 1797 October 1998. 1799 [AHO98] Allman, M., Hayes, C., Ostermann, S., "An Evaluation of 1800 TCP with Larger Initial Windows," Computer Communication Review, 1801 28(3), July 1998. 1803 [BBKT96] Bhagwat, P., Bhattacharya, P., Krishna, A., Tripathi, S., 1804 "Enhancing Throughput over Wireless LANs Using Channel State 1805 Dependent Packet Scheduling," in Proc. IEEE INFOCOM'96, pp. 1806 1133-40, March 1996. 1808 [BBKVP96] Bakshi, B., P., Krishna, N., Vaidya, N., Pradhan, D.K., 1809 "Improving Performance of TCP over Wireless Networks," Technical 1810 Report 96-014, Texas A&M University, 1996. 1812 [BPSK96] Balakrishnan, H., Padmanabhan, V., Seshan, S., Katz, R., 1813 "A Comparison of Mechanisms for Improving TCP Performance over 1814 Wireless Links," in ACM SIGCOMM, Stanford, California, August 1815 1996. 1817 [BPK99] Blakrishnan, H., Padmanabhan, V., Katz, R., "The 1818 effects of asymmetry on TCP performance", ACM Mobile Networks 1819 and Applications (MONET), 1999 (to appear). 1821 [BV97] Biaz, S., Vaidya, N., "Using End-to-end Statistics to 1822 Distinguish Congestion and Corruption Lossses: A Negative Result," 1823 Texas A&M University, Technical Report 97-009, August 18, 1997. 1825 [BV98] Biaz, S., Vaidya, N., "Sender-Based heuristics for 1826 Distinguishing Congestion Losses from Wireless Transmission 1827 Losses," Texas A&M University, Technical Report 98-013, June 1828 1998. 1830 [BV98a] Biaz, S., Vaidya, N., "Discriminating Congestion Losses 1831 from Wireless Losses using Inter-Arrival Times at the Receiver," 1832 Texas A&M University, Technical Report 98-014, June 1998. 1834 [BW97] Brasche, G., Walke, B., "Concepts, Services, and Protocols 1835 of the New GSM Phase 2+ general Packet Radio Service," IEEE 1836 Communications Magazine, Vol. 35, No. 8, August 1997. 1838 [CB96] Cheshire, S., Baker, M., "Experiences with a Wireless 1839 Network in MosquitoNet," IEEE Micro, February 1996. Available 1840 online as: 1841 http://rescomp.stanford.edu/~cheshire/papers/wireless.ps. 1843 [CDMA] Electronic Industry Alliance(EIA)/Telecommunications 1844 Industry Association (TIA), IS-95: Mobile Station-Base Station 1845 Compatibility Standard for Dual-Mode Wideband Spread Spectrum 1846 Cellular System, 1993. 1848 [CDPD] Wireless Data Forum, CDPD System Specification, Release 1849 1.1, 1995. 1851 [CM] Hari Balakrishnan and Srinivasan Seshan, "The Congestion 1852 Manager Network Computing Protocol," June 1999. Internet-Draft 1853 draft-balakrishnan-cm-00.txt (work in progress). 1855 [CTCSM97] Chang, H., Tait, C., Cohen, N., Shapiro, M., Mastrianni, 1856 S., Floyd, R., Housel, B., Lindquist, D., "Web Browsing in a 1857 Wireless Environment: Disconnected and Asynchronous Operation in 1858 ARTour Web Express," in Proc. MobiCom'97, Budapest, Hungary, 1859 September 1997. 1861 [Demers90] Demers, A., Keshav, S., and Shenker, S., Analysis and 1862 Simulation of a Fair Queueing Algorithm, Internetworking: Research 1863 and Experience, Vol. 1, 1990, pp. 3-26. 1865 [ECN] Ramakrishnan, K.K., Floyd, S., "A Proposal to add Explicit 1866 Congestion Notification (ECN) to IP", RFC 2481, January 1999. 1868 [Floyd95] Floyd, S., and Jacobson, V., Link-sharing and Resource 1869 Management Models for Packet Networks. IEEE/ACM Transactions on 1870 Networking, Vol. 3 No. 4, pp. 365-386, August 1995. 1872 [FSS98] Fragouli, C., Sivaraman, V., Srivastava, M., "Controlled 1873 Multimedia Wireless Link Sharing via Enhanced Class-Based Queueing 1874 with Channel-State-Dependent Packet Scheduling," Proc. IEEE 1875 INFOCOM'98, April 1998. 1877 [GPRS] ETSI, "General Packet Radio Service (GPRS): Service 1878 Description, Stage 2," GSM03.60, v.6.1.1 August 1998. 1880 [GSM] Rahnema, M., "Overview of the GSM system and protocol 1881 architecture," IEEE Communications Magazine, vol. 31, pp 92-100, 1882 April 1993. 1884 [HL96] Hausel, B., Lindquist, D., "WebExpress: A System for 1885 Optimizing Web Browsing in a Wireless Environment," in Proc. 1886 MobiCom'96, Rye, New York, USA, November 1996. 1888 [HTTP-PERF] Henrik Frystyk Nielsen (W3C, MIT), Jim Gettys 1889 (W3C, Digital), Anselm Baird-Smith (W3C, INRIA), Eric 1890 Prud'hommeaux (W3C, MIT), H�kon Lie (W3C, INRIA), Chris Lilley 1891 (W3C, INRIA), "Network Performance Effects of HTTP/1.1, CSS1, 1892 and PNG," ACM SIGCOMM '97, Cannes, France, September 1997. 1893 Available at: 1894 http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html. 1896 [IPPCP] A. Shacham, R. Monsour, R. Pereira, M. Thomas, "IP 1897 Payload Compression Protocol (IPComp)," RFC 2393, December 1898 1998. 1900 [IPHC] Mikael Degermark, Bjorn Nordgren, Stephen Pink. "IP 1901 Header Compression," RFC 2507, February 1999. 1903 [IPHC-RTP] S. Casner, V. Jacobson. "Compressing IP/UDP/RTP 1904 Headers for Low-Speed Serial Links," RFC 2508, February 1999. 1906 [IPHC-PPP] Mathias Engan, S. Casner, C. Bormann. "IP Header 1907 Compression over PPP," RFC 2509, February 1999. 1909 [ITCP] Bakre, A., Badrinath, B.R., "Handoff and Systems Support 1910 for Indirect TCP/IP. In Proceedings of the Second USENIX Symposium 1911 on Mobile and Location-Independent Computing, Ann Arbor, Michigan, 1912 April 10-11, 1995. 1914 [Jain89] Jain, R., "A Delay-Based Approach for Congestion 1915 Avoidance in Interconnected Heterogeneous Computer Networks," 1916 Digital Equipment Corporation, Technical Report DEC-TR-566, April 1917 1989. 1919 [Karn93] Karn, P., "The Qualcomm CDMA Digital Cellular System" 1920 Proc. USENIX Mobile and Location-Independent Computing 1921 Symposium, USENIX Association, August 1993. 1923 [KRLKA97] Kojo, M., Raatikainen, K., Liljeberg, M., Kiiskinen, 1924 J., Alanko, T., "An Efficient Transport Service for Slow Wireless 1925 Telephone Links," in IEEE Journal on Selected Areas of 1926 Communication, volume 15, number 7, September 1997. 1928 [LAKLR95] Liljeberg, M., Alanko, T., Kojo, M., Laamanen, H., 1929 Raatikainen, K., "Optimizing World-Wide Web for Weakly-Connected 1930 Mobile Workstations: An Indirect Approach," in Proc. 2nd Int. 1931 Workshop on Services in Distributed and Networked Environments, 1932 Whistler, Canada, pp. 132-139, June 1995. 1934 [LHKR96] Liljeberg, M., Helin, H., Kojo, M., Raatikainen, K., 1935 "Mowgli WWW Software: Improved Usability of WWW in Mobile WAN 1936 Environments," in Proc. IEEE Global Internet 1996 Conference, 1937 London, UK, November 1996. 1939 [LS98] Lettieri, P., Srivastava, M., "Adaptive Frame Length 1940 Control for Improving Wireless Link Throughput, Range, and Energy 1941 Efficiency," Proc. IEEE INFOCOM'98, April 1998. 1943 [MNCP] Piscitello, D., Phifer, L., Wang, Y., Hovey, R., Mobile 1944 Network Computing Protocol (MNCP), August 1997. Internet-Draft 1945 draft-piscitello-mncp-00.txt (work in progress). 1947 [MOWGLI] Kojo, M., Raatikainen, K., Alanko, T., "Connecting Mobile 1948 Workstations to the Internet over a Digital Cellular Telephone 1949 Network," in Proc. Workshop on Mobile and Wireless Information 1950 Systems (MOBIDATA), Rutgers University, NJ, November 1994. 1951 Available at: http://www.cs.Helsinki.FI/research/mowgli/. Revised 1952 version published in Mobile Computing, pp. 253-270, Kluwer, 1996. 1954 [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The 1955 Macroscopic Behavior of the TCP Congestion Avoidance Algorithm," 1956 in Computer Communications Review, a publication of ACM SIGCOMM, 1957 volume 27, number 3, July 1997. 1959 [MTCP] Brown, K. Singh, S., "A Network Architecture for Mobile 1960 Computing," Proc. IEEE INFOCOM'96, pp. 1388-1396, March 1996. 1961 Available at 1962 ftp://ftp.ece.orst.edu/pub/singh/papers/transport.ps.gz. 1964 [M-TCP] Brown, K. Singh, S., "M-TCP: TCP for Mobile Cellular 1965 Networks," ACM Computer Communications Review Vol. 27(5), 1997. 1966 Available at ftp://ftp.ece.orst.edu/pub/singh/papers/mtcp.ps.gz 1968 [MV97] Mehta, M., Vaidya, N., "Delayed 1969 Duplicate-Acknowledgements: A Proposal to Improve Performance of 1970 TCP on Wireless Links," Texas A&M University, December 24, 1997. 1972 Available at http://www.cs.tamu.edu/faculty/vaidya/mobile.html 1974 [NETBLT] John C. White, NETBLT (Network Block Transfer Protocol), 1975 draft-white-protocol-stack-00.txt, April 1997 - work in progress. 1977 [Paxson97] V. Paxson, "End-to-End Internet Packet Dynamics," 1978 Proc. SIGCOMM '97. Available at 1979 ftp://ftp.ee.lbl.gov/papers/vp-pkt-dyn-sigcomm97.ps.Z 1981 [RED] Braden, B. Clark, D., Crowcroft, J., Davie, B., Deering, S., 1982 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., 1983 Peterson, L., Ramakrishnan, K.K., Shenker, S., Wroclawski, J., 1984 Zhang, L., "Recommendations on Queue Management and Congestion 1985 Avoidance in the Internet," RFC 2309, April 1998. 1987 [RLP] ETSI, "Radio Link Protocol for Data and Telematic Services 1988 on the Mobile Station - Base Station System (MS-BSS) interface 1989 and the Base Station System - Mobile Switching Center (BSS-MSC) 1990 interface," GSM Specification 04.22, Version 3.7.0, February 1991 1992. 1993 [RFC908] Velten, D., Hinden, R., Sax, J., "Reliable Data 1994 Protocol", RFC 908, July 1984. 1996 [RFC1030] Lambert, M., "On Testing the NETBLT Protocol over Divers 1997 Networks", RFC 1030, November 1987. 1999 [RFC1122] Braden, R., Requirements for Internet Hosts -- 2000 Communication Layers, October 1989. 2002 [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for 2003 Low-Speed Serial Links," RFC 1144, February 1990. 2005 [RFC1151] Partridge, C., Hinden, R., Version 2 of the Reliable 2006 Data Protocol (RDP), RFC 1151, April 1990. 2008 [RFC1191] Jeff Mogul and Steve Deering. Path MTU Discovery, 2009 November 1990. RFC 1191. 2011 [RFC1397] Braden, R., Extending TCP for Transactions -- Concepts, 2012 November 1992. 2014 [RFC1644] Braden, R., T/TCP -- TCP Extensions for Transactions 2015 Functional Specification, July 1994. 2017 [RFC1661] Simpson, W., ed., "The Point-To-Point Protocol (PPP)", 2018 RFC 1661, July 1994. 2020 [RFC1928] M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, 2021 L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996. 2023 [RFC1986] Polites, W., Wollman, W., Woo, D., Langan, R., 2024 "Experiments with a Simple File Transfer Protocol for Radio Links 2025 using Enhanced Trivial File Transfer Protocol (ETFTP)", RFC 1986, 2026 August 1996. 2028 [RFC2002] Perkins, C., Editor, "IP Mobility Support," RFC 2002, 2029 October 1996. 2031 [RFC2003] Perkins, C., Editor, "IP Encapsulation within IP," 2032 RFC 2003, October 1996. 2034 [RFC2004] Perkins, C., Editor, "Minimal Encapsulation within 2035 IP," RFC 2004, October 1996. 2037 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., 2038 "TCP Selective Acknowledgment Options," October, 1996. 2040 [RFC2188] Banan, M., Taylor, M., Cheng, J., "AT&T/Neda's 2041 Efficient Short Remote Operations (ESRO) Protocol Specification 2042 Version 1.2," RFC 2188, September 1997. 2044 [RFC2246] T. Dierk, E. Allen, "TLS Protocol Version 1", RFC 2045 2246, January 1999. 2047 [RFC2414] Mark Allman, Sally Floyd, Craig Partridge. "Increasing 2048 TCP's Initial Window," September 1998. RFC 2414. 2050 [RFC2415] Poduri, K., Nichols, K. "Simulation Studies of 2051 Increased Initial TCP Window Size," September 1998. RFC 2415. 2053 [RFC2416] Tim Shepard and Craig Partridge. "When TCP Starts 2054 Up With Four Packets Into Only Three Buffers," September 2055 1998. RFC 2416. 2057 [RFC2581] M. Allman, V. Paxson, W. Stevens, "TCP Congestion 2058 Control," April 1999. RFC 2581. 2060 [RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to 2061 TCP's Fast Recovery Algorithm," April 1999. RFC 2582. 2063 [SNOOP] Balakrishnan, H., Seshan, S., Amir, E., Katz, R., 2064 "Improving TCP/IP Performance over Wireless Networks," Proc. 1st 2065 ACM Conf. on Mobile Computing and Networking (Mobicom), Berkeley, 2066 CA, November 1995. 2068 [Stevens94] R. Stevens, "TCP/IP Illustrated, Volume 1," 2069 Addison-Wesley, 1994 (section 2.10 for MTU size considerations 2070 and section 11.3 for weak checksums). 2072 [TCPHP] Van Jacobson, Robert Braden, and David Borman. TCP 2073 Extensions for High Performance, May 1992. RFC 1323. 2075 [TCPSATMIN] TCPSAT Minutes, August, 1997. Available at: 2076 http://tcpsat.lerc.nasa.gov/tcpsat/meetings/munich-minutes.txt. 2078 [Touch97] Touch, T., "TCP Control Block Interdependence," RFC 2079 2140, April 1997. 2081 [Vaidya99] N. H. Vaidya, M. Mehta, C. Perkins, G. Montenegro, 2082 "Delayed Duplicate Acknowledgements: A TCP-Unaware Approach to 2083 Improve Performance of TCP over Wireless," Technical Report 2084 99-003, Computer Science Dept., Texas A&M University, February 2085 1999. 2087 [VEGAS] Brakmo, L., O'Malley, S., "TCP Vegas, New Techniques for 2088 Congestion Detection and Avoidance," SIGCOMM'94, London, pp 24-35, 2089 October 1994. 2091 [VMTP] Cheriton, D., "VMTP: Versatile Message Transaction 2092 Protocol", RFC 1045, February 1988. 2094 [WAP] Wireless Application Protocol Forum. 2095 http://www.wapforum.org/ 2097 [WC91] Wang, Z., Crowcroft, J., "A New Congestion Control Scheme: 2098 Slow Start and Search," ACM Computer Communication Review, vol 21, 2099 pp 32-43, January 1991. 2101 [WTCP] Ratnam, K., Matta, I., "WTCP: An Efficient Transmission 2102 Control Protocol for Networks with Wireless Links," Technical 2103 Report NU-CCS-97-11, Northeastern University, July 1997. Available 2104 at: http://www.ece.neu.edu/personal/karu/papers/WTCP-NU.ps.gz 2106 [YB94] Yavatkar, R., Bhagawat, N., "Improving End-to-End 2107 Performance of TCP over Mobile Internetworks," Proc. Workshop on 2108 Mobile Computing Systems and Applications, IEEE Computer Society 2109 Press, Los Alamitos, California, 1994. 2111 Authors' addresses 2113 Questions about this document may be directed at: 2115 Gabriel E. Montenegro 2116 Sun Labs Networking and Security Group 2117 Sun Microsystems, Inc. 2118 901 San Antonio Road 2119 Mailstop UMPK 15-214 2120 Mountain View, California 94303 2122 Voice: +1-650-786-6288 2123 Fax: +1-650-786-6445 2124 E-Mail: gab@sun.com 2126 Spencer Dawkins 2127 Nortel Networks 2128 P.O. Box 833805 2129 Richardson, Texas 75083-3805 2131 Voice: +1-972-684-4827 2132 Fax: +1-972-685-3292 2133 E-Mail: sdawkins@nortel.com 2135 Markku Kojo 2136 University of Helsinki/Department of Computer Science 2137 P.O. Box 26 (Teollisuuskatu 23) 2138 FIN-00014 HELSINKI 2139 Finland 2141 Voice: +358-9-7084-4179 2142 Fax: +358-9-7084-4441 2143 E-Mail: kojo@cs.helsinki.fi 2144 Vincent Magret 2145 Corporate Research Center 2146 Alcatel Network Systems, Inc 2147 1201 Campbell 2148 Mail stop 446-310 2149 Richardson Texas 75081 USA 2150 M/S 446-310 2152 Voice: +1-972-996-2625 2153 Fax: +1-972-996-5902 2154 E-mail: vincent.magret@aud.alcatel.com 2156 Nitin Vaidya 2157 Dept. of Computer Science 2158 Texas A&M University 2159 College Station, TX 77843-3112 2160 Phone: 409-845-0512 2161 Fax: 409-847-8578 2162 Email: vaidya@cs.tamu.edu