idnits 2.17.1 draft-ietf-tcpsat-stand-mech-04.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-25) 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 60 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 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 (May 1, 1998) is 9491 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 521, 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. 'FF96' -- Possible downref: Non-RFC (?) normative reference: ref. 'FF98' -- 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'MM96' ** 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. 'PSC' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMM98' -- Possible downref: Non-RFC (?) normative reference: ref. 'Sta94' ** Obsolete normative reference: RFC 2001 (ref. 'Ste97') (Obsoleted by RFC 2581) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 14 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-04.txt Dan Glover 5 NASA Lewis 6 May 1, 1998 7 Expires: Novemeber 1, 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 view the entire list of current Internet-Drafts, please check the 26 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 28 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 29 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 31 Abstract 33 The Transmission Control Protocol (TCP) provides reliable delivery 34 of data across any network path, including network paths containing 35 satellite channels. While TCP works over satellite channels there 36 are several IETF standardized mechanisms that enable TCP to more 37 effectively utilize the available capacity of the network path. 38 This draft outlines some of these TCP mitigations. At this time, 39 all mitigations discussed in this draft are IETF standards track 40 mechanisms (or are compliant with IETF standards). 42 1. Introduction 44 Satellite channel characteristics have an effect on the way 45 transport protocols, such as the Transmission Control Protocol (TCP) 46 [Pos81], behave. When protocols, such as TCP, perform poorly, 47 channel utilization is low. While the performance of a transport 48 protocol is important, it is not the only consideration when 49 constructing a network containing satellite links. For example, 50 data link protocol, application protocol, router buffer size, 51 queueing discipline and proxy location are some of the considerations 52 that must be taken into account. However, this document focuses on 53 improving TCP in the satellite environment and non-TCP 54 considerations are left for another document. Finally, there have 55 been many satellite mitigations proposed and studied by the research 56 community. While these mitigations may prove useful and safe for 57 shared networks in the future, this document only considers TCP 58 mechanisms which are currently well understood and on the IETF 59 standards track (or are compliant with IETF standards). 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 at the same position in the sky. The propagation 81 time for a radio signal to travel twice that distance (corresponding 82 to a ground station directly below the satellite) is 239.6 83 milliseconds (ms) [Mar78]. For ground stations at the edge of the 84 view area of the satellite, the distance traveled is 2 x 41,756 km 85 for a total propagation delay of 279.0 ms [Mar78]. These delays are 86 for one ground station-to-satellite-to-ground station route (or 87 "hop"). Therefore, the propagation delay for a message and the 88 corresponding reply (one round-trip time or RTT) would be no more 89 than 558 ms. The RTT is not based solely on satellite propagation 90 time. The RTT can be increased by other factors in the network, 91 such as the transmission time and propagation time of other links in 92 the network path and queueing delay in gateways. Furthermore, the 93 satellite propagation delay will be proportionately longer if the 94 link includes multiple hops or if intersatellite links are used. As 95 satellites become more complex and include on-board processing of 96 signals, additional delay may be added. 98 Other orbits are possible for use by communications satellites 99 including Low Earth Orbit (LEO) and Medium Earth Orbit (MEO) 100 [Mar78]. The lower orbits require the use of constellations of 101 satellites for constant coverage. In other words, as one satellite 102 leaves the ground station's sight, another satellite appears on the 103 horizon and the channel is switched to it. The propagation delay to 104 a LEO orbit ranges from several milliseconds when communicating with 105 a satellite directly overhead, to as much as 80 ms when the 106 satellite is on the horizon. These systems are more likely to use 107 intersatellite links and have variable path delay depending on 108 routing through the network. 110 Satellite channels are dominated by two fundamental characteristics, 111 as described below: 113 NOISE - The strength of a radio signal falls in proportion to 114 the square of the distance traveled. For a satellite link the 115 distance is large and so the signal becomes weak before reaching 116 its destination. This results in a low signal-to-noise ratio. 117 Some frequencies are particularly susceptible to atmospheric 118 effects such as rain attenuation. For mobile applications, 119 satellite channels are especially susceptible to multi-path 120 distortion and shadowing (e.g., blockage by buildings). Typical 121 bit error rates for a satellite link today are on the order of 1 122 error per 10 million bits (1 x 10^-7) or better. Advanced error 123 control coding (e.g., Reed Solomon) can be added to existing 124 satellite services and is currently being used by many services. 125 Satellite error performance approaching fiber will become more 126 common as advanced error control coding is used in new systems. 127 However, many legacy satellite systems will continue to exhibit 128 higher BER than newer satellite systems and terrestrial 129 channels. 131 BANDWIDTH - The radio spectrum is a limited natural resource, 132 hence there is a restricted amount of bandwidth available to 133 satellite systems which is typically controlled by licenses. 134 This scarcity makes it difficult to trade bandwidth to solve 135 other design problems. Typical carrier frequencies for current, 136 point-to-point, commercial, satellite services are 6 GHz 137 (uplink) and 4 GHz (downlink), also known as C band, and 14/12 138 GHz (Ku band). A new service at 30/20 GHz (Ka band) will be 139 emerging over the next few years. Satellite-based radio 140 repeaters are known as transponders. Traditional C band 141 transponder bandwidth is typically 36 MHz to accommodate one 142 color television channel (or 1200 voice channels). Ku band 143 transponders are typically around 50 MHz. Furthermore, one 144 satellite may carry a few dozen transponders. 146 Not only is bandwidth limited by nature, but the allocations for 147 commercial communications are limited by international agreements so 148 that this scarce resource can be used fairly by many different 149 applications. 151 Although satellites have certain disadvantages when compared to 152 fiber channels, they also have certain advantages over terrestrial 153 links. First, satellites have a natural broadcast capability. This 154 gives satellites a natural advantage for multicast applications. 155 Next, satellites can reach geographically remote areas or countries 156 that have little terrestrial infrastructure. A related advantage is 157 the ability of satellite links to reach mobile users. 159 Satellite channels have several characteristics that differ from 160 most terrestrial channels. These characteristics can degrade the 161 performance of TCP. These characteristics include: 163 Long feedback loop 165 Due to the propagation delay of some satellite channels (e.g., 166 approximately 250 ms over a geosynchronous satellite) it may 167 take a long time for a TCP sender to determine whether or not a 168 packet has been successfully received at the final destination. 169 This delay hurts interactive applications such as telnet, as 170 well as some of the TCP congestion control algorithms (see 171 section 4). 173 Large delay*bandwidth product 175 The delay*bandwidth product (DBP) defines the amount of data a 176 protocol should have "in flight" (data that has been 177 transmitted, but not yet acknowledged) at any one time to fully 178 utilize the available channel capacity. The delay used in this 179 equation is the RTT and the bandwidth is the capacity of the 180 bottleneck link in the network path. Because the delay in some 181 satellite environments is large, TCP will need to keep a large 182 amount of data "in flight". 184 Transmission errors 186 Satellite channels exhibit a higher bit-error rate (BER) than 187 typical terrestrial networks. TCP uses all packet drops as 188 signals of network congestion and reduces its window size in an 189 attempt to alleviate the congestion. In the absence of 190 knowledge about why a packet was dropped (congestion or 191 corruption), TCP must assume the drop was due to network 192 congestion to avoid congestion collapse [FF98]. Therefore, 193 packets dropped due to corruption cause TCP to reduce the size 194 of its sliding window, even though these packet drops do not 195 signal congestion in the network. 197 Asymmetric use 199 Due to the expense of the equipment used to send data to 200 satellites, asymmetric satellite networks are often constructed. 201 For example, a host connected to a satellite network will send 202 all outgoing traffic over a slow terrestrial link (such as a 203 dialup modem channel) and receive incoming traffic via the 204 satellite channel. Another common situation arises when both 205 the incoming and outgoing traffic are sent using a satellite 206 link, but the uplink has less available capacity than the 207 downlink. This asymmetry can have an impact on TCP performance. 209 Variable Round Trip Times 211 In some satellite environments, such as low-Earth orbit (LEO) 212 constellations, the propagation delay to and from the satellite 213 varies over time. This can have a negative impact on TCP's 214 ability to accurately set retransmission timeouts and determine 215 the appropriate window size. 217 Intermittent connectivity 219 In non-GSO satellite orbit configurations, TCP connections must 220 be transferred from one satellite to another or from one ground 221 station to another from time to time. This handoff can cause 222 packet loss. 224 Most satellite channels only exhibit a subset of the above 225 characteristics. Furthermore, satellite networks are not the only 226 environments where the above characteristics are found. However, 227 satellite networks do tend to exhibit more of the above problems or 228 the above problems are aggravated in the satellite environment. The 229 mechanisms outlined in this document should benefit most networks, 230 especially those with one or more of the above characteristics. 232 3. Lower Level Mitigations 234 It is recommended that those utilizing satellite channels in their 235 networks should use the following two non-TCP mechanisms which can 236 increase TCP performance. These mechanisms are Path MTU Discovery 237 and forward error correction (FEC) and are outlined in the following 238 two sections. 240 The data link layer protocol employed over a satellite channel can 241 have a large impact on performance of higher layer protocols. While 242 beyond the scope of this document, those constructing satellite 243 networks should tune these protocols in an appropriate manner to 244 ensure that the data link protocol does not limit TCP performance. 245 In particular, data link layer protocols often implement a flow 246 control window and retransmission mechanisms. When the link level 247 window size is too small, performance will suffer just as when the 248 TCP window size is too small (see section 4.3 for a discussion of 249 appropriate window sizes). The impact link level retransmissions 250 have on TCP transfers is not currently well understood. The 251 interaction between TCP retransmissions and link level 252 retransmissions is a subject for further research. 254 3.1 Path MTU Discovery 256 Path MTU discovery [MD90] is used to determine the maximum packet 257 size a connection can use on a given network path without being 258 subjected to IP packet fragmentation. The sender transmits a packet 259 that is the appropriate size for the local network to which it is 260 connected (e.g., 1500 bytes on an Ethernet) and sets the IP "don't 261 fragment" (DF) bit. If the packet is too large to be forwarded 262 without being fragmented to a given channel along the network path, 263 the gateway that would normally fragment the packet and forward the 264 fragments will return an ICMP message to the originator of the 265 packet. The ICMP message will indicate that the original segment 266 could not be transmitted without being fragmented and will also 267 contain the size of the largest packet that can be forwarded by the 268 gateway. Additional information from the IESG on Path MTU discovery 269 is available in [Kno93]. 271 Path MTU Discovery allows TCP to use the largest possible packet 272 size, without incurring the cost of fragmentation and reassembly. 273 Large packets reduce the packet overhead by sending more data bytes 274 per overhead byte. As outlined in section 4, increasing TCP's 275 congestion window is segment based, rather than byte based and 276 therefore, larger segments enable TCP senders to increase the 277 congestion window more rapidly than smaller segments. 279 The disadvantage of Path MTU Discovery is that it may cause a long 280 pause before TCP is able to start sending data. For example, assume 281 a packet is sent with the DF bit set and one of the intervening 282 gateways (G1) returns an ICMP message indicating that it cannot 283 forward the segment. At this point, the sending host reduces the 284 packet size per the ICMP message returned by G1 and sends another 285 packet with the DF bit set. The packet will be forwarded by G1, 286 however this does not ensure all subsequent gateways in the network 287 path will be able to forward the segment. If a second gateway (G2) 288 cannot forward the segment it will return an ICMP message to the 289 transmitting host and the process will be repeated. Therefore, path 290 MTU discovery can waste a large amount of time determining the 291 maximum allowable packet size on the network path between the sender 292 and receiver. Satellite delays can aggravate this problem (consider 293 the case when the channel between G1 and G2 is a satellite link). 294 However, in practice, Path MTU Discovery does not consume a large 295 amount of time due to wide support of common MTU values. 297 The relationship between BER and segment size is likely to vary 298 depending on the error characteristics of the given channel. This 299 relationship deserves further study, however with the use of good 300 forward error correction (see section 3.2) larger segments should 301 provide better performance in most cases and therefore Path MTU 302 Discovery is recommended. 304 Choosing the maximum packet size to be used on the satellite link 305 should be based on the characteristics of the channels and the 306 amount and type of forward error correction employed. The exact 307 method of choosing the satellite link's MTU is outside the scope of 308 this document. However, it is recommended that TCP use the largest 309 MTU possible on a given network path. 311 3.2 Forward Error Correction 313 A loss event in TCP is always interpreted as an indication of 314 congestion and always causes TCP to reduce its window size. Since 315 window growth is based on returning acknowledgments (see section 4), 316 TCP spends a long time recovering from loss when operating in 317 satellite networks. When packet loss is due to corruption, rather 318 than congestion, TCP does not need to reduce its window size. 319 However, at the present time there is no accepted method for 320 detecting corruption loss. 322 Therefore, for TCP to operate efficiently, the channel 323 characteristics should be such that nearly all loss is due to 324 network congestion. The use of forward error correction coding 325 (FEC) on a satellite link should be used to improve the bit-error 326 rate (BER) of the satellite channel. Reducing the BER is not always 327 possible in satellite environments. However, since TCP takes a long 328 time to recover from lost packets because the long propagation delay 329 imposed by a satellite link delays feedback from the receiver 330 [PS97] the link should be made as clean as possible to prevent TCP 331 connections from receiving false congestion signals. 333 FEC should not be expected to fix all problems associated with noisy 334 satellite links. There are some situations where FEC cannot be 335 expected to solve the noise problem (such as military jamming, deep 336 space missions, noise caused by rain fade, etc.). In addition, link 337 outages can also cause problems in satellite systems that do not 338 occur as frequently in terrestrial networks. Furthermore, TCP has 339 an end-to-end feedback loop; therefore, noise in other parts of a 340 high delay connection will cause problems even if the satellite link 341 portion is error-free. Finally, FEC is not without cost. FEC 342 requires additional hardware and uses some of the available 343 bandwidth. It can add delay and timing jitter due to the processing 344 time of the coder/decoder. 346 Further research is needed into mechanisms that allows TCP to 347 differentiate between congestion induced drops and those caused by 348 corruption. Such a mechanism would allow TCP to respond to 349 congestion in an appropriate manner, as well as repairing corruption 350 induced loss without reducing the transmission rate. However, in 351 the absence of such a mechanism packet loss must be assumed to 352 indicate congestion to preserve network stability. Incorrectly 353 interpreting loss as caused by corruption and not reducing the 354 transmission rate accordingly can lead to congestive collapse 355 [FF98]. 357 4. Standard TCP Mechanisms 359 This section includes an outline of the mechanisms that may be 360 necessary in satellite or hybrid satellite/terrestrial networks to 361 better utilize the available capacity of the link. These mechanisms 362 may also be needed to fully utilize fast terrestrial channels. 363 Furthermore, these mechanisms do not fundamentally hurt performance 364 in a shared terrestrial network. Each of the following sections 365 outlines one mechanism and why that mechanism may be needed. 367 4.1 Congestion Control 369 To avoid generating an inappropriate amount of network traffic for 370 the current network conditions, during a connection, TCP employs 371 four congestion control mechanisms [JK88] [Jac90] [Ste97]. These 372 algorithms are slow start, congestion avoidance, fast retransmit and 373 fast recovery. These algorithms are used to adjust the amount of 374 unacknowledged data that can be injected into the network and to 375 retransmit segments dropped by the network. 377 TCP uses two variables to accomplish congestion control. The first 378 variable is the congestion window (cwnd). This is an upper bound on 379 the amount of data the sender can inject into the network before 380 receiving an acknowledgment (ACK). The value of cwnd is limited to 381 the receiver's advertised window. The congestion window is 382 increased or decreased during the transfer based on the inferred 383 amount of congestion present in the network. The second variable is 384 the slow start threshold (ssthresh). This variable determines which 385 algorithm is being used to increase the value of cwnd. If cwnd is 386 less than ssthresh the slow start algorithm is used to increase the 387 value of cwnd. However, if cwnd is greater than or equal to 388 ssthresh the congestion avoidance algorithm is used. The initial 389 value of ssthresh is the receiver's advertised window size. 390 Furthermore, the value of ssthresh is reduced when congestion is 391 detected. 393 The four congestion control algorithms are outlined below, followed 394 by a brief discussion of the impact of satellite environments on 395 these algorithms. 397 4.1.1 Slow Start and Congestion Avoidance 399 When a host begins sending data on a TCP connection the host has no 400 knowledge of the current state of the network between itself and the 401 data receiver. In order to avoid transmitting an inappropriately 402 large burst of traffic, the data sender is required to use the slow 403 start algorithm at the beginning of a transfer [JK88] [Bra89] 404 [Ste97]. Slow start begins by initializing cwnd to 1 segment. This 405 forces TCP to transmit one segment and wait for the corresponding 406 ACK. For each ACK that is received, the value of cwnd is increased 407 by 1 segment. For example, after the first ACK is received cwnd 408 will be 2 segments and the sender will be allowed to transmit 2 data 409 packets. This continues until cwnd meets or exceeds ssthresh, or 410 loss is detected. 412 When the value of cwnd is greater than or equal to ssthresh the 413 congestion avoidance algorithm is used to increase cwnd [JK88] 414 [Bra89] [Ste97]. This algorithm increases the size of cwnd more 415 slowly than does slow start. Congestion avoidance is used to probe 416 the network for any additional capacity. During congestion 417 avoidance, cwnd is increased by 1/cwnd for each incoming ACK. 418 Therefore, if one ACK is received for every data segment, cwnd will 419 increase by 1 segment per round-trip time (RTT). 421 The slow start and congestion control algorithms can force poor 422 utilization of the available channel bandwidth when using long-delay 423 satellite networks [All97]. For example, transmission begins with 424 the transmission of one segment. After the first segment is 425 transmitted the data sender is forced to wait for the corresponding 426 ACK. When using a GSO satellite this leads to an idle time of 427 roughly 500 ms when no useful work is being accomplished. 429 Therefore, slow start takes more real time over GSO satellites than 430 on typical terrestrial channels. This holds for congestion 431 avoidance, as well [All97]. This is precisely why Path MTU 432 Discovery is an important algorithm. While the number of segments 433 we transmit is determined by the congestion control algorithms, the 434 size of these segments is not. Therefore, using larger packets will 435 enable TCP to send more data per segment which yields better channel 436 utilization. 438 4.1.2 Fast Retransmit and Fast Recovery 440 TCP's default mechanism to detect dropped segments is a timeout 441 [Pos81]. In other words, if the sender does not receive an ACK for 442 a given packet within the expected amount of time the segment will 443 be retransmitted. The retransmission timeout (RTO) is based on 444 observations of the RTT. In addition to retransmitting a segment 445 when the RTO expires, TCP also uses the lost segment as an 446 indication of congestion in the network. In response to the 447 congestion, the value of ssthresh is set to half of the cwnd and the 448 value of cwnd is then reduced to 1 segment. This triggers the use 449 of the slow start algorithm to increase cwnd until the value of cwnd 450 reaches half of its value when congestion was detected. After the 451 slow start phase, the congestion avoidance algorithm is used to 452 probe the network for additional capacity. 454 TCP ACKs always acknowledge the highest in-order segment that has 455 arrived. Therefore an ACK for segment X also effectively ACKs all 456 segments < X. Furthermore, if a segment arrives out-of-order the 457 ACK triggered will be for the highest in-order segment, rather than 458 the segment that just arrived. For example, assume segment 11 has 459 been dropped somewhere in the network and segment 12 arrives at the 460 receiver. The receiver is going to send a duplicate ACK covering 461 segment 10 (and all previous segments). 463 The fast retransmit algorithm uses these duplicate ACKs to detect 464 lost segments. If 3 duplicate ACKs arrive at the data originator, 465 TCP assumes that a segment has been lost and retransmits the missing 466 segment without waiting for the RTO to expire. After a segment is 467 resent using fast retransmit, the fast recovery algorithm is used to 468 adjust the congestion window. First, the value of ssthresh is set 469 to half of the value of cwnd. Next, the value of cwnd is halved. 470 Finally, the value of cwnd is artificially increased by 1 segment 471 for each duplicate ACK that has arrived. The artificial inflation 472 can be done because each duplicate ACK represents 1 segment that has 473 left the network. When the cwnd permits, TCP is able to transmit 474 new data. This allows TCP to keep data flowing through the network 475 at half the rate it was when loss was detected. When an ACK for the 476 retransmitted packet arrives, the value of cwnd is reduced back to 477 ssthresh (half the value of cwnd when the congestion was detected). 479 Fast retransmit can resend only one segment per window of data sent. 480 When multiple segments are lost in a given window of data, one of 481 the segments will be resent using fast retransmit and the rest of 482 the dropped segments must wait for the RTO to expire, which causes 483 TCP to revert to slow start. 485 TCP's response to congestion differs based on the way the congestion 486 was detected. If the retransmission timer causes a packet to be 487 resent, TCP drops ssthresh to half the current cwnd and reduces the 488 value of cwnd to 1 segment (thus triggering slow start). However, 489 if a segment is resent via fast retransmit both ssthresh and cwnd 490 are set to half the current value of cwnd and congestion avoidance 491 is used to send new data. The difference is that when 492 retransmitting due to duplicate ACKs, TCP knows that packets are 493 still flowing through the network and can therefore infer that the 494 congestion is not that bad. However, when resending a packet due to 495 the expiration of the retransmission timer, TCP cannot infer 496 anything about the state of the network and therefore must proceed 497 conservatively by sending new data using the slow start algorithm. 499 4.1.3 Congestion Control in Satellite Environment 501 The above algorithms have a negative impact on the performance of 502 individual TCP connection's performance because the algorithms 503 slowly probe the network for addition capacity, which in turn wastes 504 bandwidth. This is especially true over long-delay satellite 505 channels because of the large amount of time required for the sender 506 to obtain feedback from the receiver [All97] [AHKO97]. However, the 507 algorithms are necessary to prevent congestive collapse in a shared 508 network [JK88]. Therefore, the negative impact on a given 509 connection is more than offset by the benefit to the entire network. 511 4.2 Large TCP Windows 513 The standard TCP window size (65,535 bytes) is not adequate to allow 514 a single TCP connection to utilize the entire bandwidth available on 515 some satellite channels. TCP throughput is limited by the following 516 formula [Pos81]: 518 throughput = window size / RTT 520 Therefore, using the maximum window size of 65,535 bytes and a 521 geosynchronous satellite channel RTT of 560 ms [Kru95] the maximum 522 throughput is limited to: 524 throughput = 65,535 bytes / 560 ms = 117,027 bytes/second 526 Therefore, a single standard TCP connection cannot fully utilize, 527 for example, T1 rate (approximately 192,000 bytes/second) GSO 528 satellite channels. However, TCP has been extended to support 529 larger windows [JBB92]. The window scaling options outlined in 530 [JBB92] should be used in satellite environments, as well as the 531 companion algorithms PAWS (Protection Against Wrapped Sequence 532 space) and RTTM (Round-Trip Time Measurements). 534 It should be noted that for a satellite link shared among many 535 flows, large windows may not be necessary. For instance, two 536 long-lived TCP connections each using a window of 65,535 bytes, as 537 in the above example, can fully utilize a T1 GSO satellite channel. 539 Using large windows requires applications or TCP stacks to be hand 540 tuned (usually by an expert) to utilize large windows. Research 541 into operating system mechanisms that are able to adjust the buffer 542 capacity as needed is currently underway [SMM98]. This will better 543 allow stock TCP implementations and applications to better utilize 544 the capacity provided by the underlying network. 546 4.3 Selective Acknowledgments 548 Selective acknowledgments (SACKs) [MMFR96] allow TCP receivers to 549 inform TCP senders exactly which packets have arrived. SACKs allow 550 TCP to recover more quickly from lost segments, as well as avoiding 551 needless retransmissions. 553 The fast retransmit algorithm can generally only repair one loss per 554 window of data. When multiple losses occur, the sender generally 555 must rely on a timeout to determine which segment needs to be 556 retransmitted next. While waiting for a timeout, the data segments 557 and their acknowledgments drain from the network. In the absence of 558 incoming ACKs to clock new segments into the network, the sender 559 must use the slow start algorithm to restart transmission. As 560 discussed above, the slow start algorithm can be time consuming over 561 satellite channels. When SACKs are employed, the sender is 562 generally able to determine which segments need to be retransmitted 563 in the first RTT following loss detection. This allows the sender 564 to continue to transmit segments (retransmissions and new segments, 565 if appropriate) at an appropriate rate and therefore sustain the ACK 566 clock. This avoids a costly slow start period following multiple 567 lost segments. Generally SACK is able to retransmit all dropped 568 segments within the first RTT following the loss detection. [MM96] 569 and [FF96] discuss specific congestion control algorithms that rely 570 on SACK information to determine which segments need to be 571 retransmitted and when it is appropriate to transmit those segments. 572 Both these algorithms follow the basic principles of congestion 573 control outlined in [JK88] and reduce the window by half when 574 congestion is detected. 576 TCP senders that do not use SACKs must infer which segments have not 577 arrived and retransmit accordingly. This can lead to unnecessary 578 retransmissions, in the case when the sender infers incorrectly. 579 When utilizing SACKs, the sender does not need to guess which 580 segments have not arrived, thus eliminating the majority of 581 unnecessary retransmissions. Furthermore, when SACKs are used, the 582 sender gets information about which segments need to be 583 retransmitted more rapidly (within the first RTT following the loss) 584 than without SACKs. 586 Some satellite channels require the use of large TCP windows to 587 fully utilize the available capacity, as discussed above. With the 588 use of large windows, the likelihood of losing multiple segments in 589 a given window of data increases (either due to congestion or 590 corruption). When multiple segments are lost, SACKs will ensure the 591 data sender retransmits only those segments that were dropped and 592 not those that arrived at the receiver. Furthermore, the 593 retransmission of these segments will happen more quickly than 594 relying on a timeout. 596 5. Mitigation Summary 598 Table 1 summarizes the mechanisms that have been discussed in this 599 document. Those mechanisms denoted "Recommended" are IETF standards 600 track mechanisms that are recommended by the authors for use in 601 networks containing satellite channels. Those mechanisms marked 602 "Required" have been defined by the IETF as required for hosts using 603 the shared Internet [Bra89]. Along with the section of this 604 document containing the discussion of each mechanism, we note where 605 the mechanism needs to be implemented. The codes listed in the last 606 column are defined as follows: ``S'' for the data sender, ``R'' for 607 the data receiver and ``L'' for the satellite link. 609 Mechanism Use Section Where 610 +------------------------+-------------+------------+--------+ 611 | Path-MTU Discovery | Recommended | 3.1 | S | 612 | FEC | Recommended | 3.2 | L | 613 | TCP Congestion Control | | | | 614 | Slow Start | Required | 4.1.1 | S | 615 | Congestion Avoidance | Required | 4.1.1 | S | 616 | Fast Retransmit | Recommended | 4.1.2 | S | 617 | Fast Recovery | Recommended | 4.1.2 | S | 618 | TCP Large Windows | | | | 619 | Window Scaling | Recommended | 4.2 | S,R | 620 | PAWS | Recommended | 4.2 | S,R | 621 | RTTM | Recommended | 4.2 | S,R | 622 | TCP SACKs | Recommended | 4.3 | S,R | 623 +------------------------+-------------+------------+--------+ 624 Table 1 626 Satellite users should check with their TCP vendors (implementors) 627 to ensure the recommended mechanisms are supported in their stack in 628 current and/or future versions. Alternatively, the Pittsburgh 629 Supercomputer Center tracks TCP implementations and which extensions 630 they support, as well as providing guidance on tuning various TCP 631 implementations [PSC]. 633 Research into improving the efficiency of TCP over satellite 634 channels is ongoing and will be summarized in a planned memo along 635 with other considerations, such as satellite network architectures. 637 6. Security Considerations 639 The authors believe that the recommendations contained in this memo 640 do not alter the security implications of TCP. However, when using 641 a broadcast medium such as satellites links to transfer user data 642 and/or network control traffic, one should be aware of the intrinsic 643 security implications of such technology. 645 Eavesdropping on network links is a form of passive attack that, if 646 performed successfully, could reveal critical traffic control 647 information that would jeopardize the proper functioning of the 648 network. These attacks could reduce the ability of the network to 649 provide data transmission services efficiently. Eavesdroppers could 650 also compromise the privacy of user data, especially if end to end 651 security mechanisms are not in use. While passive monitoring can 652 occur on any network, the wireless broadcast nature of satellite 653 links allows reception of signals without physical connection to the 654 network which enables monitoring to be conducted without detection. 655 However, it should be noted that the resources needed to monitor a 656 satellite link are non-trivial. 658 Data encryption at the physical and/or link layers can provide 659 secure communication over satellite channels. However, this still 660 leaves traffic vulnerable to eavesdropping on networks before and 661 after traversing the satellite link. Therefore, end-to-end security 662 mechanisms should be considered. This document does not make any 663 recommendations as to which security mechanisms should be employed. 664 However, those operating and using satellite networks should survey 665 the currently available network security mechanisms and choose those 666 that meet their security requirements. 668 Acknowledgments 670 This document has benefited from comments from the members of the 671 TCP Over Satellite Working Group. In particular, we would like to 672 thank Aaron Falk, Matthew Halsey, Hans Kruse, Matt Mathis, Greg 673 Nakanishi, Jeff Semke, Bill Sepmeier and Eric Travis for their 674 useful comments about this document. Finally, we are indebted to 675 Luis Sanchez for providing much needed guidance on security section. 677 References 679 [AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann. 680 TCP Performance Over Satellite Links. In Proceedings of the 5th 681 International Conference on Telecommunication Systems, March 682 1997. 684 [All97] Mark Allman. Improving TCP Performance Over Satellite 685 Channels. Master's thesis, Ohio University, June 1997. 687 [Bra89] Robert Braden. Requirements for Internet Hosts -- 688 Communication Layers, October 1989. RFC 1122. 690 [FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of 691 Tahoe, Reno and SACK TCP. Computer Communication Review, July 692 1996. 694 [FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End 695 Congestion Control in the Internet. Submitted to IEEE 696 Transactions on Networking. 698 [Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. 699 Technical Report, LBL, April 1990. 701 [JBB92] Van Jacobson, Robert Braden, and David Borman. TCP 702 Extensions for High Performance, May 1992. RFC 1323. 704 [JK88] Van Jacobson and Michael Karels. Congestion Avoidance and 705 Control. In ACM SIGCOMM, 1988. 707 [Kno93] Steve Knowles. IESG Advice from Experience with Path MTU 708 Discovery, March 1993. RFC 1435. 710 [Mar78] James Martin. Communications Satellite Systems. Prentice 711 Hall, 1978. 713 [MD90] Jeff Mogul and Steve Deering. Path MTU Discovery, November 714 1990. RFC 1191. 716 [MM96] Matt Mathis and Jamshid Mahdavi. Forward Acknowledgment: 717 Refining TCP Congestion Control. In ACM SIGCOMM, 1996. 719 [MMFR96] Matt Mathis, Jamshid Mahdavi, Sally Floyd, and Allyn 720 Romanow. TCP Selective Acknowledgment Options, October 1996. 721 RFC 2018. 723 [Pos81] Jon Postel. Transmission Control Protocol, September 1981. 724 RFC 793. 726 [PS97] Craig Partridge and Tim Shepard. TCP Performance Over 727 Satellite Links. IEEE Network, 11(5), September/October 1997. 729 [PSC] Jamshid Mahdavi. Enabling High Performance Data Transfers on 730 Hosts. http://www.psc.edu/networking/perf_tune.html. 732 [SMM98] Jeff Semke, Jamshid Mahdavi and Matt Mathis. Automatic TCP 733 Buffer Tuning. In ACM SIGCOMM, August 1998. To appear. 735 [Sta94] William Stallings. Data and Computer Communications. 736 MacMillian, 4th edition, 1994. 738 [Ste97] W. Richard Stevens. TCP Slow Start, Congestion Avoidance, 739 Fast Retransmit, and Fast Recovery Algorithms, January 1997. 740 RFC 2001. 742 Author's Addresses: 744 Mark Allman 745 NASA Lewis Research Center/Sterling Software 746 21000 Brookpark Rd. MS 54-2 747 Cleveland, OH 44135 748 mallman@lerc.nasa.gov 749 http://gigahertz.lerc.nasa.gov/~mallman 751 Dan Glover 752 NASA Lewis Research Center 753 21000 Brookpark Rd. MS 54-2 754 Cleveland, OH 44135 755 Daniel.R.Glover@lerc.nasa.gov