idnits 2.17.1 draft-ietf-tcpsat-stand-mech-03.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-20) 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 (February 18, 1998) is 9558 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 454, 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-03.txt Dan Glover 4 NASA Lewis 5 February 18, 1998 6 Expires: August 18, 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 Some frequencies are particularly susceptible to atmospheric 103 effects such as rain attenuation. For mobile applications, 104 satellite channels are especially susceptible to multi-path 105 distortion and shadowing (e.g., blockage by buildings). Typical 106 bit error rates for a satellite link today are on the order of 1 107 error per 10 million bits (1 x 10^-7) or better. Advanced error 108 control coding (e.g., Reed Solomon) can be added to existing 109 satellite services and is currently being used by many services. 110 Satellite error performance equivalent to fiber will become 111 common as advanced error control coding is used in new systems. 112 However, many current satellite systems do not provide error 113 free service. 115 BANDWIDTH - The radio spectrum is a limited natural resource, 116 hence the bandwidth available to satellite systems is limited. 117 Typical carrier frequencies for current, point-to-point, 118 commercial, satellite services are 6 GHz (uplink) and 4 GHz 119 (downlink), also known as C band, and 14/12 GHz (Ku band). A 120 new service at 30/20 GHz (Ka band) will be emerging over the 121 next few years. Satellite-based radio repeaters are known as 122 transponders. Traditional C band transponder bandwidth is 123 typically 36 MHz to accommodate one color television channel (or 124 1200 voice channels). Ku band transponders are typically around 125 50 MHz. Furthermore, one satellite may carry a few dozen 126 transponders. 128 Not only is bandwidth limited by nature, but the allocations for 129 commercial communications are limited by international agreements so 130 that this scarce resource can be used fairly by many different 131 applications. 133 Although satellites have certain disadvantages when compared to 134 fiber channels, they also have certain advantages over terrestrial 135 links. First, satellites have a natural broadcast capability. This 136 gives satellites a natural advantage for multicast applications. 137 Next, satellites can reach geographically remote areas or countries 138 that have little terrestrial infrastructure. A related advantage is 139 the ability of satellite links is to reach mobile users. 141 Satellite channels have several characteristics that differ from 142 most terrestrial channels. These characteristics can degrade the 143 performance of TCP. These characteristics include: 145 Long feedback loop 147 Due to the propagation delay of some satellite channels (e.g., 148 approximately 250 ms over a geosynchronous satellite) it takes a 149 large amount of time for a TCP sender to determine whether or 150 not a packet has been successfully received at the final 151 destination. This delay hurts interactive applications such as 152 telnet, as well as some of the TCP congestion control algorithms 153 (see section 4). 155 Large delay*bandwidth product 157 The delay*bandwidth product (DBP) defines the amount of data a 158 protocol should have "in flight" (data that has been 159 transmitted, but not yet acknowledged) at any one time to fully 160 utilize the available channel capacity. The delay used in this 161 equation is the RTT, in practice. Because the delay in some 162 satellite environments is large, TCP will need to keep a large 163 amount of data "in flight". 165 Transmission errors 167 Some satellite channels exhibit a higher bit-error rate (BER) 168 than typical terrestrial networks. TCP uses all packet drops as 169 signals of congestion and reduces the sending rate, because TCP 170 cannot figure out why a packet was dropped. Therefore, packets 171 dropped due to corruption cause TCP to reduce the size of the 172 its sliding window, even though these packet drops do not signal 173 congestion in the network. 175 Asymmetric use 177 Due to the expense of the equipment used to send data to 178 satellites, asymmetric satellite networks are often constructed. 179 For example, a host connected to such a network will send all 180 outgoing traffic over a slow terrestrial link (such as a dialup 181 modem channel) and receive incoming traffic via the satellite 182 channel. Another common situation arises when both the incoming 183 and outgoing traffic are sent using a satellite link, but the 184 uplink has less available capacity than the downlink. This 185 asymmetry can have a large impact on TCP performance. 187 Variable Round Trip Times 189 In some satellite environments, such as low-Earth orbit (LEO) 190 constellations, the propagation delay to and from the satellite 191 varies over time. This can have a negative impact on TCP's 192 ability to accurately set retransmission timeouts and determine 193 the appropriate window size. 195 Intermittent connectivity 197 In non-GSO satellite orbit configurations, TCP connections must 198 be transferred from one satellite to another or from one ground 199 station to another from time to time. This handoff can cause 200 packet loss. 202 Most satellite channels only exhibit a subset of the above 203 characteristics. In addition, some terrestrial networks exhibit 204 some of the above characteristics, as well. The mechanisms 205 outlined in this document should benefits most networks, 206 especially those with one of the above characteristics. 208 3. Lower Level Mitigations 210 It is recommended that those utilizing satellite channels in their 211 networks should use the following two non-TCP mechanisms which can 212 increase TCP performance. These mechanisms are Path MTU Discovery 213 and forward error correction (FEC) and are outlined in the following 214 two sections. 216 3.1 Path MTU Discovery 218 Path MTU discovery [MD90] is used to determine the maximum packet 219 size a connection can use on a given network path without being 220 subjected to IP packet fragmentation. The sender transmits a packet 221 that is the appropriate size for the local network with which it is 222 connected (e.g., 1500 bytes on an Ethernet) and sets the IP "don't 223 fragment" (DF) bit. If the packet is too large for a channel along 224 the network path, the gateway that would normally fragment the 225 packet and forward the fragments will return an ICMP message to the 226 originator of the packet. The ICMP message will indicate that the 227 original segment could not be transmitted without being fragmented 228 and will also contain the maximum size that can be forwarded by the 229 gateway. Additional information from the IESG on Path MTU discovery 230 is available in [Kno93]. 232 This allows TCP to use the largest possible packet size, without 233 incurring the cost of fragmentation and reassembly. Large packets 234 reduce the packet overhead by sending more data bytes per overhead 235 byte. As outlined in section 4, increasing TCP's congestion window 236 is segment based, rather than byte based. Therefore, larger 237 segments enable TCP senders to increase the congestion window more 238 rapidly than smaller segments. 240 The disadvantage of Path MTU Discovery is that it may cause a long 241 pause before TCP is able to start sending data. For example, assume 242 a packet is sent with the DF bit set and one of the intervening 243 gateways (G1) returns an ICMP message indicating that it cannot 244 forward the segment. At this point, the sending host reduces the 245 packet size to the size returned by G1 and sends another packet with 246 the DF bit set. The packet will be forwarded by G1, however this 247 does not ensure all subsequent gateways in the network path will be 248 able to forward the segment. If a second gateway (G2) cannot 249 forward the segment it will return an ICMP message to the 250 transmitting host and the process will be repeated. Therefore, path 251 MTU discovery can waste a large amount of time determining the 252 maximum allowable packet size on the network path between the sender 253 and receiver. Satellite delays can aggravate this problem (consider 254 the case when the channel between G1 and G2 is a satellite link). 255 However, in practice, Path MTU Discovery is not that time consuming 256 due to wide support of common MTU values. 258 The use of large segments may pose a problem on links with a high 259 BER. In such an environment, the probability that a segment will 260 incur a bit error increases with the size of the segment. 261 Therefore, using smaller segments may ensure that more segments are 262 delivered and less data is retransmitted over high BER channels. 264 The relationship between BER and segment size is likely to vary 265 depending on the error characteristics of the given channel. This 266 relationship deserves further study, however with the use of good 267 forward error correction (see section 3.2) larger segments should 268 provide better performance and therefore Path MTU Discovery is 269 recommended. 271 3.2 Forward Error Correction 273 A loss event in TCP is always interpreted as an indication of 274 congestion and always causes TCP to reduce the window size. When 275 loss occurs during slow start, then slow start is terminated and TCP 276 enters congestion avoidance. Premature termination of slow start 277 and entry into congestion avoidance due to losses other than 278 congestion losses will cause needless inefficiency in channel 279 utilization. Furthermore, drops due to corruption causes TCP to 280 needlessly reduce the amount of data being injected into the 281 network. 283 For TCP to operate efficiently, the channel characteristics should 284 be such that nearly all loss is due to network congestion. The use 285 of forward error correction coding (FEC) on a satellite link should 286 be used to bring the performance of the link to at least fiber 287 quality. Because of the effect of long RTT, the time needed to 288 recover from errors on a satellite link is longer than for a 289 terrestrial network with shorter RTT [PS97]. There are some 290 applications, such as military jamming, where FEC cannot be expected 291 to solve the noise problem. 293 4. Standard TCP Mechanisms 295 This section includes an outline of the mechanisms that may be 296 necessary in satellite or hybrid satellite/terrestrial networks to 297 better utilize the available capacity of the link. These mechanisms 298 may also be needed to fully utilize fast terrestrial channels. 299 Furthermore, these mechanisms do not fundamentally hurt performance 300 in a shared terrestrial network. Each of the following sections 301 outlines one mechanism and why that mechanism may be needed. 303 4.1 Congestion Control 305 To avoid generating an inappropriate amount of network traffic for 306 the current network conditions TCP employs four congestion control 307 mechanisms [JK88] [Jac90] [Ste97]. These algorithms are slow start, 308 congestion avoidance, fast retransmit and fast recovery. These 309 algorithms are used to adjust the amount of unacknowledged data that 310 can be injected into the network and to retransmit segments dropped 311 by the network. 313 TCP uses two variables to accomplish congestion control. The first 314 variable is the congestion window (cwnd). This is an upper bound on 315 the amount of data the sender can inject into the network before 316 receiving an acknowledgment (ACK). The value of cwnd is limited to 317 the receiver's advertised window. The congestion window is 318 increased or decreased during the transfer based on the inferred 319 amount of congestion present in the network. The second variable is 320 the slow start threshold (ssthresh). This variable determines which 321 algorithm is being used to increase the value of cwnd. If cwnd is 322 less than ssthresh the slow start algorithm is used to increase the 323 value of cwnd. However, if cwnd is greater than or equal to 324 ssthresh the congestion avoidance algorithm is used. The initial 325 value of ssthresh is the receiver's advertised window size. 326 Furthermore, the value of ssthresh is reduced when congestion is 327 detected. 329 The four congestion control algorithms are outlined below, followed 330 by a brief discussion of the impact of satellite environments on 331 these algorithms. 333 4.1.1 Slow Start and Congestion Avoidance 335 When a host begins sending data on a TCP connection the host has no 336 knowledge of the current state of the network between itself and the 337 data receiver. In order to avoid transmitting an inappropriately 338 large burst of traffic, the data sender is required to use the slow 339 start algorithm at the beginning of a transfer [JK88] [Bra89] 340 [Ste97]. Slow start begins by initializing cwnd to 1 segment. This 341 forces TCP to transmit one segment and wait for the corresponding 342 ACK. For each ACK that is received, the value of cwnd is increased 343 by 1 segment. For example, after the first ACK is received cwnd 344 will be 2 segments and the sender will be allowed to transmit 2 data 345 packets. This continues until cwnd meets or exceeds ssthresh, or 346 loss is detected. 348 When the value of cwnd is greater than or equal to ssthresh the 349 congestion avoidance algorithm is used to increase cwnd [JK88] 350 [Bra89] [Ste97]. This algorithm increases the size of cwnd more 351 slowly than does slow start. Congestion avoidance is used to probe 352 the network for any additional capacity. During congestion 353 avoidance, cwnd is increased by 1/cwnd for each incoming ACK. 354 Therefore, if one ACK is received for every data segment, cwnd will 355 increase by 1 segment per round-trip time (RTT). 357 Long-delay satellite networks force poor utilization of the 358 available channel bandwidth when using the slow start and congestion 359 control algorithms [All97]. For example, transmission begins with 360 the transmission of one segment. After the first segment is 361 transmitted the data sender is forced to wait for the corresponding 362 ACK. When using a GSO satellite this leads to an idle time of 363 roughly 500 ms when no useful work is being accomplished. 364 Therefore, slow start takes more real time over GSO satellites than 365 on typical terrestrial channels. This holds for congestion 366 avoidance, as well [All97]. This is precisely why Path MTU Discovery 367 is an important algorithm. While the number of segments we transmit 368 is determined by the congestion control algorithms, the size of 369 these segments is not. Therefore, using larger packets will enable 370 TCP to send more data per segment which yields better channel 371 utilization. 373 4.1.2 Fast Retransmit and Fast Recovery 374 TCP's default mechanism to detect dropped segments is a timeout 375 [Pos81]. In other words, if the sender does not receive an ACK for 376 a given packet within the expected amount of time the segment will 377 be retransmitted. The retransmission timeout (RTO) is based on 378 observations of the RTT. In addition to retransmitting a segment 379 when the RTO expires, TCP also uses the lost segment as an 380 indication of congestion in the network. In response to the 381 congestion, the value of ssthresh is set to half of the cwnd and the 382 value of cwnd is then reduced to 1 segment. This triggers the use 383 of the slow start algorithm to increase cwnd until the value of cwnd 384 reaches half of its value when congestion was detected. After the 386 slow start phase, the congestion avoidance algorithm is used to 387 probe the network for additional capacity. 389 TCP ACKs always acknowledge the highest in-order segment that has 390 arrived. Therefore an ACK for segment X also effectively ACKs all 391 segments < X. Furthermore, if a segment arrives out-of-order the 392 ACK triggered will be for the highest in-order segment, rather than 393 the segment that just arrived. For example, assume segment 11 has 394 been dropped somewhere in the network and segment 12 arrives at the 396 receiver. The receiver is going to send a duplicate ACK covering 397 segment 10 (and all previous segments). 399 The fast retransmit algorithm uses these duplicate ACKs to detect 400 lost segments. If 3 duplicate ACKs arrive at the data originator, 401 TCP assumes that a segment has been lost and retransmits the missing 402 segment without waiting for the RTO to expire. After a segment is 403 resent using fast retransmit, the fast recovery algorithm is used to 404 adjust the congestion window. First, the value of ssthresh is set 405 to half of the value of cwnd. Next, the value of cwnd is halved. 406 Finally, the value of cwnd is artificially increased by 1 segment 407 for each duplicate ACK that has arrived. The artificial inflation 408 can be done because each duplicate ACK represents 1 segment that has 409 left the network. When the cwnd permits, TCP is able to transmit 410 new data. This allows TCP to keep data flowing through the network 411 at half the rate it was when loss was detected. When an ACK for the 412 retransmitted packet arrives, the value of cwnd is reduced back to 413 ssthresh (half the value of cwnd when the congestion was detected). 415 Fast retransmit can resend only one segment per window of data sent. 416 When multiple segments are lost in a given window of data, one of 417 the segments will be resent using fast retransmit and the rest of 418 the dropped segments must wait for the RTO to expire, which causes 419 TCP to revert to slow start. 421 TCP's response to congestion differs based on the way the congestion 422 was detected. If the retransmission timer causes a packet to be 423 resent, TCP drops ssthresh to half the current cwnd and reduces the 424 value of cwnd to 1 segment (thus triggering slow start). However, 425 if a segment is resent via fast retransmit both ssthresh and cwnd 426 are set to half the current value of cwnd and congestion avoidance 427 is used to send new data. The difference is that when 428 retransmitting due to duplicate ACKs, TCP knows that packets are 429 still flowing through the network and can therefore infer that the 430 congestion is not that bad. However, when resending a packet due to 431 a the expiration of the retransmission timer, TCP cannot infer 432 anything about the state of the network and therefore must proceed 433 conservatively by sending new data using the slow start algorithm. 435 4.1.3 Congestion Control in Satellite Environment 437 The above algorithms have a negative impact on the performance of 438 individual TCP connection's performance, especially over long-delay 439 satellite channels [All97] [AHKO97]. However, the algorithms are 440 necessary to prevent congestive collapse in a shared network [JK88]. 441 Therefore, the negative impact on a given connection is more than 442 offset by the benefit to the entire network. 444 4.2 Large TCP Windows 446 The standard TCP window size (65,535 bytes) is not adequate to allow 447 a single TCP connection to utilize the entire bandwidth available on 448 some satellite channels. TCP throughput is limited by the following 449 formula [Pos81]: 451 throughput = window size / RTT 453 Therefore, using the maximum window size of 65,535 bytes and a 454 geosynchronous satellite channel RTT of 560 ms [Kru95] the maximum 455 throughput is limited to: 457 throughput = 65,535 bytes / 560 ms = 117,027 bytes/second 459 Therefore, a single standard TCP connection cannot fully utilize, 460 for example, T1 rate (approximately 192,000 bytes/second) GSO 461 satellite channels. However, TCP has been extended to support 462 larger windows [JBB92]. The window scaling options outlined in 463 [JBB92] should be used in satellite environments, as well as the 464 companion algorithms PAWS (Protection Against Wrapped Sequence 465 space) and RTTM (Round-Trip Time Measurements). 467 It should be noted that for a satellite link shared among many 468 flows, large windows may not be necessary. For instance, two 469 long-lived TCP connections each using a window of 65,535 bytes, as 470 in the above example, can fully utilize a T1 GSO satellite channel. 472 4.3 Selective Acknowledgments 474 Selective acknowledgments (SACKs) [MMFR96] allow TCP receivers to 475 inform TCP senders exactly which packets have arrived. TCP senders 476 that do not use SACKs must infer which segments have not arrived and 477 retransmit accordingly. This can lead to needless retransmissions, 478 in the case when the sender infers incorrectly. When utilizing 479 SACKs, the sender does not need to guess which segments have not 480 arrived. 482 Some satellite channels require the use of large TCP windows to 483 fully utilize the available capacity, as discussed above. With the 484 use of large windows, the likelihood of losing multiple segments in 485 a given window of data increases. When multiple segments are lost, 486 SACKs will ensure the data sender retransmits only those segments 487 that were dropped and not those that safely arrived at the 488 receiver. 490 5. Mitigation Summary 492 Table 1 summarizes the mechanisms that have been discussed in this 493 document. Those mechanisms denoted "Recommended" are IETF standards 494 track mechanisms that are recommended by the authors for use in 495 networks containing satellite channels. Those mechanisms marked 496 "Required" have been defined by the IETF as required for hosts using 497 the shared Internet [Bra89]. Along with the section of this 498 document containing the discussion of each mechanism, we note where 499 the mechanism needs to be implemented. The codes listed in the last 500 column are defined as follows: "S" for the data sender, "R" for the 501 data receiver and "GS" for the satellite ground station. 503 Mechanism Use Section Where 504 +------------------------+-------------+------------+--------+ 505 | Path-MTU Discovery | Recommended | 3.1 | S | 506 | FEC | Recommended | 3.2 | GS | 507 | TCP Congestion Control | | | | 508 | Slow Start | Required | 4.1.1 | S | 509 | Congestion Avoidance | Required | 4.1.1 | S | 510 | Fast Retransmit | Recommended | 4.1.2 | S | 511 | Fast Recovery | Recommended | 4.1.2 | S | 512 | TCP Large Windows | | | | 513 | Window Scaling | Recommended | 4.2 | S,R | 514 | PAWS | Recommended | 4.2 | S,R | 515 | RTTM | Recommended | 4.2 | S,R | 516 | TCP SACKs | Recommended | 4.3 | S,R | 517 +------------------------+-------------+------------+--------+ 518 Table 1 520 Satellite users should check with their TCP vendors (implementors) 521 to ensure the recommended mechanisms are supported in their stack in 522 current and/or future versions. 524 Work on improving the efficiency of TCP over satellite channels is 525 ongoing and will be summarized in a planned memo along with other 526 considerations, such as network architectures. 528 6. Security 530 The recommendations contained in this memo do not alter the security 531 implications of TCP. 533 Acknowledgments 535 This document has benefited from comments from the members of the 536 TCP Over Satellite Working Group. In particular, we would like to 537 thank Aaron Falk, Matthew Halsey and Greg Nakanishi. 539 References 541 [AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann. 542 TCP Performance Over Satellite Links. In Proceedings of the 5th 543 International Conference on Telecommunication Systems, March 544 1997. 546 [All97] Mark Allman. Improving TCP Performance Over Satellite 547 Channels. Master's thesis, Ohio University, June 1997. 549 [Bra89] Robert Braden. Requirements for Internet Hosts -- 550 Communication Layers, October 1989. RFC 1122. 552 [Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. 553 Technical Report, LBL, April 1990. 555 [JBB92] Van Jacobson, Robert Braden, and David Borman. TCP 556 Extensions for High Performance, May 1992. RFC 1323. 558 [JK88] Van Jacobson and Michael Karels. Congestion Avoidance and 559 Control. In ACM SIGCOMM, 1988. 561 [Kno93] Steve Knowles. IESG Advice from Experience with Path MTU 562 Discovery, March 1993. RFC 1435. 564 [Mar78] James Martin. Communications Satellite Systems. Prentice 565 Hall, 1978. 567 [MD90] Jeff Mogul and Steve Deering. Path MTU Discovery, November 568 1990. RFC 1191. 570 [MMFR96] Matt Mathis, Jamshid Mahdavi, Sally Floyd, and Allyn 571 Romanow. TCP Selective Acknowledgment Options, October 1996. 572 RFC 2018. 574 [Pos81] Jon Postel. Transmission Control Protocol, September 1981. 575 RFC 793. 577 [PS97] Craig Partridge and Tim Shepard. TCP Performance Over 578 Satellite Links. IEEE Network, 11(5), September/October 1997. 580 [Sta94] William Stallings. Data and Computer Communications. 581 MacMillian, 4th edition, 1994. 583 [Ste97] W. Richard Stevens. TCP Slow Start, Congestion Avoidance, 584 Fast Retransmit, and Fast Recovery Algorithms, January 1997. 585 RFC 2001. 587 Author's Addresses: 589 Mark Allman 590 NASA Lewis Research Center/Sterling Software 591 21000 Brookpark Rd. MS 54-2 592 Cleveland, OH 44135 593 mallman@lerc.nasa.gov 594 http://gigahertz.lerc.nasa.gov/~mallman 596 Dan Glover 597 NASA Lewis Research Center 598 21000 Brookpark Rd. MS 54-2 599 Cleveland, OH 44135 600 Daniel.R.Glover@lerc.nasa.gov