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