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