idnits 2.17.1 draft-ietf-tcpsat-stand-mech-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (January 14, 1998) is 9596 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) == Missing Reference: 'Kru95' is mentioned on line 451, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'AHKO97' -- Possible downref: Non-RFC (?) normative reference: ref. 'All97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jac90' ** Obsolete normative reference: RFC 1323 (ref. 'JBB92') (Obsoleted by RFC 7323) -- Possible downref: Non-RFC (?) normative reference: ref. 'JK88' ** Downref: Normative reference to an Informational RFC: RFC 1435 (ref. 'Kno93') -- Possible downref: Non-RFC (?) normative reference: ref. 'Mar78' ** Obsolete normative reference: RFC 793 (ref. 'Pos81') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'PS97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sta94' ** Obsolete normative reference: RFC 2001 (ref. 'Ste97') (Obsoleted by RFC 2581) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Mark Allman 2 INTERNET DRAFT NASA Lewis/Sterling Software 3 File: draft-ietf-tcpsat-stand-mech-02.txt Dan Glover 4 NASA Lewis 5 January 14, 1998 6 Expires: July 14, 1998 8 Enhancing TCP Over Satellite Channels 9 using Standard Mechanisms 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite them other than as ``work in 22 progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 26 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Abstract 32 The Transmission Control Protocol (TCP) provides reliable delivery 33 of data across any network path, including network paths containing 34 satellite channels. While TCP works over satellite channels there 35 are several mechanisms that enable TCP to more effectively utilize 36 the available capacity of the network path. This draft outlines 37 some of these TCP mitigations. At this time, all mitigations 38 discussed in this draft are IETF standards track mechanisms. 40 1. Introduction 42 Satellite channel characteristics have an effect on the way 43 transport protocols, such as the Transmission Control Protocol (TCP) 44 [Pos81], behave. When protocols such as TCP perform poorly, channel 45 utilization is low. While the performance of a transport protocol, 46 such as TCP, is important, it is not the only consideration when 47 constructing a network containing satellite links. However, this 48 document focuses on improving TCP in the satellite environment. 50 This draft is divided up as follows: Section 2 provides a brief 51 outline of the characteristics of satellite networks. Section 3 52 outlines two non-TCP mechanisms that enable TCP to more effectively 53 utilize the available bandwidth. Section 4 outlines the TCP 54 mechanisms defined by the IETF that benefit satellite networks. 55 Finally, Section 5 provides a summary of what modern TCP 56 implementations should include to be considered "satellite 57 friendly". 59 2. Satellite Characteristics 61 There is an inherent delay in the delivery of a message over a 62 satellite link due to the finite speed of light and the altitude of 63 communications satellites. 65 Many communications satellites are located at Geostationary Orbit 66 (GSO) with an altitude of approximately 36,000 km [Sta94]. At this 67 altitude the orbit period is the same as the Earth's rotation 68 period. Therefore, each ground station is always able to "see" the 69 orbiting satellite at the same position in the sky. The propagation 70 time for a radio signal to travel twice that distance (corresponding 71 to a ground station directly below the satellite) is 239.6 72 milliseconds (ms) [Mar78]. For ground stations at the edge of the 73 view area of the satellite, the distance traveled is 2 x 41,756 km 74 for a total propagation delay of 279.0 ms [Mar78]. These delays are 75 for one ground station-to-satellite-to-ground station route (or 76 "hop"). Therefore, the propagation delay for a message and its 77 reply (one round-trip time or RTT) would be no more than 558 ms. 78 The delay will be proportionately longer if the link includes 79 multiple hops or if intersatellite links are used. As satellites 80 become more complex and include on-board processing of signals, 81 additional delay may be added. 83 Other orbits are possible for use by communications satellites 84 including Low Earth Orbit (LEO) and Medium Earth Orbit (MEO) 85 [Mar78]. The lower orbits require the use of constellations of 86 satellites for constant coverage. In other words, as one satellite 87 leaves the ground station's sight, another satellite appears on the 88 horizon and the channel is switched to it. The propagation delay to 89 a LEO orbit ranges from several milliseconds when communicating with 90 a satellite directly overhead, to as much as 80 ms when the 91 satellite is on the horizon. These systems are more likely to use 92 intersatellite links and have variable path delay depending on 93 routing through the network. 95 Satellite channels are dominated by two fundamental characteristics, 96 as described below: 98 NOISE - The strength of a radio signal falls in proportion to 99 the square of the distance traveled. For a satellite link the 100 distance is large and so the signal becomes weak before reaching 101 its destination. This results in a low signal-to-noise ratio. 102 Typical bit error rates for a satellite link today are on the 103 order of 1 error per 10 million bits (1 x 10^-7) or better. 104 Advanced error control coding (e.g., Reed Solomon) can be added 105 to existing satellite services and is currently being used by 106 many services. Satellite error performance equivalent to fiber 107 will become common as advanced error control coding is used in 108 new systems. However, many current satellite systems do not 109 provide error free service. 111 BANDWIDTH - The radio spectrum is a limited natural resource, 112 hence the bandwidth available to satellite systems is limited. 113 Typical carrier frequencies for current, point-to-point, 114 commercial, satellite services are 6 GHz (uplink) and 4 GHz 115 (downlink), also known as C band, and 14/12 GHz (Ku band). A 116 new service at 30/20 GHz (Ka band) will be emerging over the 117 next few years. Satellite-based radio repeaters are known as 118 transponders. Traditional C band transponder bandwidth is 119 typically 36 MHz to accommodate one color television channel (or 120 1200 voice channels). Ku band transponders are typically around 121 50 MHz. Furthermore, one satellite may carry a few dozen 122 transponders. 124 Not only is bandwidth limited by nature, but the allocations for 125 commercial communications are limited by international agreements so 126 that this scarce resource can be used fairly by many different 127 applications. 129 Although satellites have certain disadvantages when compared to 130 fiber channels, they also have certain advantages over terrestrial 131 links. First, satellites have a natural broadcast capability. This 132 gives satellites a natural advantage for multicast applications. 133 Next, satellites can reach geographically remote areas or countries 134 that have little terrestrial infrastructure. A related advantage is 135 the ability of satellite links is to reach mobile users. 137 Satellite channels have several characteristics that differ from 138 most terrestrial channels. These characteristics can degrade the 139 performance of TCP. These characteristics include: 141 Long feedback loop 143 Due to the propagation delay of some satellite channels (e.g., 144 approximately 250 ms over a geosynchronous satellite) it takes a 145 large amount of time for a TCP sender to determine whether or 146 not a packet has been successfully received at the final 147 destination. This delay hurts interactive applications such as 148 telnet, as well as some of the TCP congestion control algorithms 149 (see section 4). 151 Large delay*bandwidth product 153 The delay*bandwidth product (DBP) defines the amount of data a 154 protocol should have "in flight" (data that has been 155 transmitted, but not yet acknowledged) at any one time to fully 156 utilize the available channel capacity. The delay used in this 157 equation is the RTT, in practice. Because the delay in some 158 satellite environments is large, TCP will need to keep a large 159 amount of data "in flight". 161 Transmission errors 163 Some satellite channels exhibit a higher bit-error rate (BER) 164 than typical terrestrial networks. TCP uses all packet drops as 165 signals of congestion and reduces the sending rate, because TCP 166 cannot figure out why a packet was dropped. Therefore, packets 167 dropped due to corruption cause TCP to reduce the size of the 168 its sliding window, even though these packet drops do not signal 169 congestion in the network. 171 Asymmetric use 173 Due to the expense of the equipment used to send data to 174 satellites, asymmetric satellite networks are often constructed. 175 For example, a host connected to such a network will send all 176 outgoing traffic over a slow terrestrial link (such as a dialup 177 modem channel) and receive incoming traffic via the satellite 178 channel. Another common situation arises when both the incoming 179 and outgoing traffic are sent using a satellite link, but the 180 uplink has less available capacity than the downlink. This 181 asymmetry can have a large impact on TCP performance. 183 Variable Round Trip Times 185 In some satellite environments, such as low-Earth orbit (LEO) 186 constellations, the propagation delay to and from the satellite 187 varies over time. This can have a negative impact on TCP's 188 ability to accurately set retransmission timeouts and determine 189 the appropriate window size. 191 Intermittent connectivity 193 In non-GSO satellite orbit configurations, TCP connections must 194 be transferred from one satellite to another or from one ground 195 station to another from time to time. This handoff can cause 196 packet loss. 198 Most satellite channels only exhibit a subset of the above 199 characteristics. In addition, some terrestrial networks exhibit 200 some of the above characteristics, as well. The mechanisms 201 outlined in this document should benefits most networks, 202 especially those with one of the above characteristics. 204 3. Lower Level Mitigations 206 It is recommended that those utilizing satellite channels in their 207 networks should use the following two non-TCP mechanisms which can 208 increase TCP performance. These mechanisms are Path MTU Discovery 209 and forward error correction (FEC) and are outlined in the following 210 two sections. 212 3.1 Path MTU Discovery 214 Path MTU discovery [MD90] is used to determine the maximum packet 215 size a connection can use on a given network path without being 216 subjected to IP packet fragmentation. The sender transmits a packet 217 that is the appropriate size for the local network with which it is 218 connected (e.g., 1500 bytes on an Ethernet) and sets the IP "don't 219 fragment" (DF) bit. If the packet is too large for a channel along 220 the network path, the gateway that would normally fragment the 221 packet and forward the fragments will return an ICMP message to the 222 originator of the packet. The ICMP message will indicate that the 223 original segment could not be transmitted without being fragmented 224 and will also contain the maximum size that can be forwarded by the 225 gateway. Additional information from the IESG on Path MTU discovery 226 is available in [Kno93]. 228 This allows TCP to use the largest possible packet size, without 229 incurring the cost of fragmentation and reassembly. Large packets 230 reduce the packet overhead by sending more data bytes per overhead 231 byte. As outlined in section 4, increasing TCP's congestion window 232 is segment based, rather than byte based. Therefore, larger 233 segments enable TCP senders to increase the congestion window more 234 rapidly than smaller segments. 236 The disadvantage of Path MTU Discovery is that it may cause a long 237 pause before TCP is able to start sending data. For example, assume 238 a packet is sent with the DF bit set and one of the intervening 239 gateways (G1) returns an ICMP message indicating that it cannot 240 forward the segment. At this point, the sending host reduces the 241 packet size to the size returned by G1 and sends another packet with 242 the DF bit set. The packet will be forwarded by G1, however this 243 does not ensure all subsequent gateways in the network path will be 244 able to forward the segment. If a second gateway (G2) cannot 245 forward the segment it will return an ICMP message to the 246 transmitting host and the process will be repeated. Therefore, path 247 MTU discovery can waste a large amount of time determining the 248 maximum allowable packet size on the network path between the sender 249 and receiver. Satellite delays can aggravate this problem (consider 250 the case when the channel between G1 and G2 is a satellite link). 251 However, in practice, Path MTU Discovery is not that time consuming 252 due to wide support of common MTU values. 254 The use of large segments may pose a problem on links with a high 255 BER. In such an environment, the probability that a segment will 256 incur a bit error increases with the size of the segment. 257 Therefore, using smaller segments may ensure that more segments are 258 delivered and less data is retransmitted over high BER channels. 260 The relationship between BER and segment size is likely to vary 261 depending on the error characteristics of the given channel. This 262 relationship deserves further study, however with the use of good 263 forward error correction (see section 3.2) larger segments should 264 provide better performance and therefore Path MTU Discovery is 265 recommended. 267 3.2 Forward Error Correction 269 A loss event in TCP is always interpreted as an indication of 270 congestion and always causes TCP to reduce the window size. When 271 loss occurs during slow start, then slow start is terminated and TCP 272 enters congestion avoidance. Premature termination of slow start 273 and entry into congestion avoidance due to losses other than 274 congestion losses will cause needless inefficiency in channel 275 utilization. Furthermore, drops due to corruption causes TCP to 276 needlessly reduce the amount of data being injected into the 277 network. 279 For TCP to operate efficiently, the channel characteristics should 280 be such that nearly all loss is due to network congestion. The use 281 of forward error correction coding (FEC) on a satellite link should 282 be used to bring the performance of the link to at least fiber 283 quality. Because of the effect of long RTT, the time needed to 284 recover from errors on a satellite link is longer than for a 285 terrestrial network with shorter RTT [PS97]. There are some 286 applications, such as military jamming, where FEC cannot be expected 287 to solve the noise problem. 289 4. Standard TCP Mechanisms 291 This section includes an outline of the mechanisms that may be 292 necessary in satellite or hybrid satellite/terrestrial networks to 293 better utilize the available capacity of the link. These mechanisms 294 may also be needed to fully utilize fast terrestrial channels. 295 Furthermore, these mechanisms do not fundamentally hurt performance 296 in a shared terrestrial network. Each of the following sections 297 outlines one mechanism and why that mechanism may be needed. 299 4.1 Congestion Control 301 To avoid generating an inappropriate amount of network traffic for 302 the current network conditions TCP employs four congestion control 303 mechanisms [JK88] [Jac90] [Ste97]. These algorithms are slow start, 304 congestion avoidance, fast retransmit and fast recovery. These 305 algorithms are used to adjust the amount of unacknowledged data that 306 can be injected into the network and to retransmit segments dropped 307 by the network. 309 TCP uses two variables to accomplish congestion control. The first 310 variable is the congestion window (cwnd). This is an upper bound on 311 the amount of data the sender can inject into the network before 312 receiving an acknowledgment (ACK). The value of cwnd is limited to 313 the receiver's advertised window. The congestion window is 314 increased or decreased during the transfer based on the inferred 315 amount of congestion present in the network. The second variable is 316 the slow start threshold (ssthresh). This variable determines which 317 algorithm is being used to increase the value of cwnd. If cwnd is 318 less than ssthresh the slow start algorithm is used to increase the 319 value of cwnd. However, if cwnd is greater than or equal to 320 ssthresh the congestion avoidance algorithm is used. The initial 321 value of ssthresh is the receiver's advertised window size. 322 Furthermore, the value of ssthresh is reduced when congestion is 323 detected. 325 The four congestion control algorithms are outlined below, followed 326 by a brief discussion of the impact of satellite environments on 327 these algorithms. 329 4.1.1 Slow Start and Congestion Avoidance 331 When a host begins sending data on a TCP connection the host has no 332 knowledge of the current state of the network between itself and the 333 data receiver. In order to avoid transmitting an inappropriately 334 large burst of traffic, the data sender is required to use the slow 335 start algorithm at the beginning of a transfer [JK88] [Bra89] 336 [Ste97]. Slow start begins by initializing cwnd to 1 segment. This 337 forces TCP to transmit one segment and wait for the corresponding 338 ACK. For each ACK that is received, the value of cwnd is increased 339 by 1 segment. For example, after the first ACK is received cwnd 340 will be 2 segments and the sender will be allowed to transmit 2 data 341 packets. This continues until cwnd meets or exceeds ssthresh, or 342 loss is detected. 344 When the value of cwnd is greater than or equal to ssthresh the 345 congestion avoidance algorithm is used to increase cwnd [JK88] 346 [Bra89] [Ste97]. This algorithm increases the size of cwnd more 347 slowly than does slow start. Congestion avoidance is used to probe 348 the network for any additional capacity. During congestion 349 avoidance, cwnd is increased by 1/cwnd for each incoming ACK. 350 Therefore, if one ACK is received for every data segment, cwnd will 351 increase by 1 segment per round-trip time (RTT). 353 Long-delay satellite networks force poor utilization of the 354 available channel bandwidth when using the slow start and congestion 355 control algorithms [All97]. For example, transmission begins with 356 the transmission of one segment. After the first segment is 357 transmitted the data sender is forced to wait for the corresponding 358 ACK. When using a GSO satellite this leads to an idle time of 359 roughly 500 ms when no useful work is being accomplished. 360 Therefore, slow start takes more real time over GSO satellites than 361 on typical terrestrial channels. This holds for congestion 362 avoidance, as well [All97]. This is precisely why Path MTU Discovery 363 is an important algorithm. While the number of segments we transmit 364 is determined by the congestion control algorithms, the size of 365 these segments is not. Therefore, using larger packets will enable 366 TCP to send more data per segment which yields better channel 367 utilization. 369 4.1.2 Fast Retransmit and Fast Recovery 371 TCP's default mechanism to detect dropped segments is a timeout 372 [Pos81]. In other words, if the sender does not receive an ACK for 373 a given packet within the expected amount of time the segment will 374 be retransmitted. The retransmission timeout (RTO) is based on 375 observations of the RTT. In addition to retransmitting a segment 376 when the RTO expires, TCP also uses the lost segment as an 377 indication of congestion in the network. In response to the 378 congestion, the value of ssthresh is set to half of the cwnd and the 379 value of cwnd is then reduced to 1 segment. This triggers the use 380 of the slow start algorithm to increase cwnd until the value of cwnd 381 reaches half of its value when congestion was detected. After the 383 slow start phase, the congestion avoidance algorithm is used to 384 probe the network for additional capacity. 386 TCP ACKs always acknowledge the highest in-order segment that has 387 arrived. Therefore an ACK for segment X also effectively ACKs all 388 segments < X. Furthermore, if a segment arrives out-of-order the 389 ACK triggered will be for the highest in-order segment, rather than 390 the segment that just arrived. For example, assume segment 11 has 391 been dropped somewhere in the network and segment 12 arrives at the 393 receiver. The receiver is going to send a duplicate ACK covering 394 segment 10 (and all previous segments). 396 The fast retransmit algorithm uses these duplicate ACKs to detect 397 lost segments. If 3 duplicate ACKs arrive at the data originator, 398 TCP assumes that a segment has been lost and retransmits the missing 399 segment without waiting for the RTO to expire. After a segment is 400 resent using fast retransmit, the fast recovery algorithm is used to 401 adjust the congestion window. First, the value of ssthresh is set 402 to half of the value of cwnd. Next, the value of cwnd is halved. 403 Finally, the value of cwnd is artificially increased by 1 segment 404 for each duplicate ACK that has arrived. The artificial inflation 405 can be done because each duplicate ACK represents 1 segment that has 406 left the network. When the cwnd permits, TCP is able to transmit 407 new data. This allows TCP to keep data flowing through the network 408 at half the rate it was when loss was detected. When an ACK for the 409 retransmitted packet arrives, the value of cwnd is reduced back to 410 ssthresh (half the value of cwnd when the congestion was detected). 412 Fast retransmit can resend only one segment per window of data sent. 413 When multiple segments are lost in a given window of data, one of 414 the segments will be resent using fast retransmit and the rest of 415 the dropped segments must wait for the RTO to expire, which causes 416 TCP to revert to slow start. 418 TCP's response to congestion differs based on the way the congestion 419 was detected. If the retransmission timer causes a packet to be 420 resent, TCP drops ssthresh to half the current cwnd and reduces the 421 value of cwnd to 1 segment (thus triggering slow start). However, 422 if a segment is resent via fast retransmit both ssthresh and cwnd 423 are set to half the current value of cwnd and congestion avoidance 424 is used to send new data. The difference is that when 425 retransmitting due to duplicate ACKs, TCP knows that packets are 426 still flowing through the network and can therefore infer that the 427 congestion is not that bad. However, when resending a packet due to 428 a the expiration of the retransmission timer, TCP cannot infer 429 anything about the state of the network and therefore must proceed 430 conservatively by sending new data using the slow start algorithm. 432 4.1.3 Congestion Control in Satellite Environment 434 The above algorithms have a negative impact on the performance of 435 individual TCP connection's performance, especially over long-delay 436 satellite channels [All97] [AHKO97]. However, the algorithms are 437 necessary to prevent congestive collapse in a shared network [JK88]. 438 Therefore, the negative impact on a given connection is more than 439 offset by the benefit to the entire network. 441 4.2 Large TCP Windows 443 The standard TCP window size (65,535 bytes) is not adequate to allow 444 a single TCP connection to utilize the entire bandwidth available on 445 some satellite channels. TCP throughput is limited by the following 446 formula [Pos81]: 448 throughput = window size / RTT 450 Therefore, using the maximum window size of 65,535 bytes and a 451 geosynchronous satellite channel RTT of 560 ms [Kru95] the maximum 452 throughput is limited to: 454 throughput = 65,535 bytes / 560 ms = 117,027 bytes/second 456 Therefore, a single standard TCP connection cannot fully utilize, 457 for example, T1 rate (192,000 bytes/second) GSO satellite channels. 458 However, TCP has been extended to support larger windows [JBB92]. 459 The window scaling options outlined in [JBB92] should be used in 460 satellite environments, as well as the companion algorithms PAWS 461 (Protection Against Wrapped Sequence space) and RTTM (Round-Trip 462 Time Measurements). 464 4.3 Selective Acknowledgments 466 Selective acknowledgments (SACKs) [MMFR96] allow TCP receivers to 467 inform TCP senders exactly which packets have arrived. TCP senders 468 that do not use SACKs must infer which segments have not arrived and 469 retransmit accordingly. This can lead to needless retransmissions, 470 in the case when the sender infers incorrectly. When utilizing 471 SACKs, the sender does not need to guess which segments have not 472 arrived. 474 Some satellite channels require the use of large TCP windows to 475 fully utilize the available capacity, as discussed above. With the 476 use of large windows, the likelihood of losing multiple segments in 477 a given window of data increases. When multiple segments are lost, 478 SACKs will ensure the data sender retransmits only those segments 479 that were dropped and not those that safely arrived at the 480 receiver. 482 5. Mitigation Summary 484 Table 1 summarizes the mechanisms that have been discussed in this 485 document. Those mechanisms denoted "Recommended" are IETF standards 486 track mechanisms that are recommended by the authors for use in 487 networks containing satellite channels. Those mechanisms marked 488 "Required" have been defined by the IETF as required for hosts using 489 the shared Internet [Bra89]. Along with the section of this 490 document containing the discussion of each mechanism, we note where 491 the mechanism needs to be implemented. The codes listed in the last 492 column are defined as follows: "S" for the data sender, "R" for the 493 data receiver and "GS" for the satellite ground station. 495 Mechanism Use Section Where 496 +------------------------+-------------+------------+--------+ 497 | Path-MTU Discovery | Recommended | 3.1 | S | 498 | FEC | Recommended | 3.2 | GS | 499 | TCP Congestion Control | | | | 500 | Slow Start | Required | 4.1.1 | S | 501 | Congestion Avoidance | Required | 4.1.1 | S | 502 | Fast Retransmit | Recommended | 4.1.2 | S | 503 | Fast Recovery | Recommended | 4.1.2 | S | 504 | TCP Large Windows | | | | 505 | Window Scaling | Recommended | 4.2 | S,R | 506 | PAWS | Recommended | 4.2 | S,R | 507 | RTTM | Recommended | 4.2 | S,R | 508 | TCP SACKs | Recommended | 4.3 | S,R | 509 +------------------------+-------------+------------+--------+ 510 Table 1 512 Satellite users should check with their TCP vendors (implementors) 513 to ensure the recommended mechanisms are supported in their stack in 514 current and/or future versions. 516 Work on improving the efficiency of TCP over satellite channels is 517 ongoing and will be summarized in a planned memo along with other 518 considerations, such as network architectures. 520 6. Security 522 The recommendations contained in this memo do not alter the security 523 implications of TCP. 525 References 527 [AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann. 528 TCP Performance Over Satellite Links. In Proceedings of the 5th 529 International Conference on Telecommunication Systems, March 530 1997. 532 [All97] Mark Allman. Improving TCP Performance Over Satellite 533 Channels. Master's thesis, Ohio University, June 1997. 535 [Bra89] Robert Braden. Requirements for Internet Hosts -- 536 Communication Layers, October 1989. RFC 1122. 538 [Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. 539 Technical Report, LBL, April 1990. 541 [JBB92] Van Jacobson, Robert Braden, and David Borman. TCP 542 Extensions for High Performance, May 1992. RFC 1323. 544 [JK88] Van Jacobson and Michael Karels. Congestion Avoidance and 545 Control. In ACM SIGCOMM, 1988. 547 [Kno93] Steve Knowles. IESG Advice from Experience with Path MTU 548 Discovery, March 1993. RFC 1435. 550 [Mar78] James Martin. Communications Satellite Systems. Prentice 551 Hall, 1978. 553 [MD90] Jeff Mogul and Steve Deering. Path MTU Discovery, November 554 1990. RFC 1191. 556 [MMFR96] Matt Mathis, Jamshid Mahdavi, Sally Floyd, and Allyn 557 Romanow. TCP Selective Acknowledgment Options, October 1996. 558 RFC 2018. 560 [Pos81] Jon Postel. Transmission Control Protocol, September 1981. 561 RFC 793. 563 [PS97] Craig Partridge and Tim Shepard. TCP Performance Over 564 Satellite Links. IEEE Network, 11(5), September/October 1997. 566 [Sta94] William Stallings. Data and Computer Communications. 567 MacMillian, 4th edition, 1994. 569 [Ste97] W. Richard Stevens. TCP Slow Start, Congestion Avoidance, 570 Fast Retransmit, and Fast Recovery Algorithms, January 1997. 571 RFC 2001. 573 Author's Addresses: 575 Mark Allman 576 NASA Lewis Research Center/Sterling Software 577 21000 Brookpark Rd. MS 54-2 578 Cleveland, OH 44135 579 mallman@lerc.nasa.gov 580 http://gigahertz.lerc.nasa.gov/~mallman 582 Dan Glover 583 NASA Lewis Research Center 584 21000 Brookpark Rd. MS 54-2 585 Cleveland, OH 44135 586 Daniel.R.Glover@lerc.nasa.gov