RFC 2488

Enhancing TCP Over Satellite Channels using Standard Mechanisms

📅 published January 1999, from ietf

Enhancing TCP Over Satellite Channels using Standard Mechanisms ✨

📄 Okay bestie, this is RFC 2488, a Best Current Practice (BCP 28) from the Network Working Group, dropped in January 1999. The authors are M. Allman (NASA Lewis/Sterling Software), D. Glover (NASA Lewis), and L. Sanchez (BBN). Its category is Best Current Practice, and the title block doesn't list anything it obsoletes or updates. 🎀

Status of this Memo

This document is an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions to make it better 🫶 Distribution of this memo is unlimited, so share away!

Copyright Notice

Abstract

TCP gives you reliable delivery of data across any network path, and that includes paths with satellite channels in them 🛰️ TCP does work over satellites, but there are several IETF standardized mechanisms that help it use the network path's available capacity way better. This doc walks through some of those TCP mitigations. Right now, every mitigation covered here is an IETF standards track mechanism (or is compliant with IETF standards), so no sketchy experimental stuff 💅

1. Introduction ✨

Satellite channel characteristics can affect how transport protocols, like the Transmission Control Protocol (TCP) [Pos81], behave 🧚 When protocols like TCP perform poorly, channel utilization is low, and that's a sad girl moment 😭 Transport performance matters, but it's not the only thing to think about when you're building a network with satellite links. For example, the data link protocol, the application protocol, router buffer size, queueing discipline, and proxy location are all considerations that must be taken into account. This document, though, is focused on improving TCP in the satellite environment, and the non-TCP considerations are left for another document 📚 There have also been a ton of satellite mitigations proposed and studied by the research community. These might prove useful and safe for shared networks down the road, but this document only looks at TCP mechanisms that are currently well understood and on the IETF standards track (or are compliant with IETF standards). Very specific, very intentional 🎯

Here's how the doc is laid out 🗺️ Section 2 gives a quick outline of satellite network characteristics. Section 3 outlines two non-TCP mechanisms that help TCP use the available bandwidth more effectively. Section 4 covers the TCP mechanisms defined by the IETF that may benefit satellite networks. Finally, Section 5 sums up what modern TCP implementations should include to be considered "satellite friendly" 🌸

2. Satellite Characteristics 🛰️

There's an inherent delay when a message travels over a satellite link, and it comes from the finite speed of light plus how high communications satellites are orbiting 🌙

Lots of communications satellites sit in Geostationary Orbit (GSO) at an altitude of approximately 36,000 km [Sta94]. At that altitude, the orbit period matches the Earth's rotation period, so each ground station can always "see" the orbiting satellite at the same spot in the sky 👀 The propagation time for a radio signal to travel twice that distance (which is what you get with a ground station directly below the satellite) is 239.6 milliseconds (ms) [Mar78]. For ground stations at the edge of the satellite's view area, the distance traveled is 2 x 41,756 km, for a total propagation delay of 279.0 ms [Mar78]. These delays are for one ground station-to-satellite-to-ground station route (or "hop"). So the propagation delay for a message and its reply (one round-trip time, or RTT) could be at least 558 ms 😩 The RTT isn't based only on satellite propagation time, though. Other factors in the network also raise it, like the transmission time and propagation time of other links in the network path, and queueing delay in gateways. Also, the satellite propagation delay will be longer if the link includes multiple hops or if intersatellite links are used. And as satellites get more complex and include on-board processing of signals, additional delay may get added too 🤏

Other orbits are possible for communications satellites, including Low Earth Orbit (LEO) [Stu95] [Mon98] and Medium Earth Orbit (MEO) [Mar78]. Lower orbits need constellations of satellites for constant coverage. So, as one satellite leaves a ground station's sight, another satellite appears on the horizon and the channel switches over to it 🔄 The propagation delay to a LEO orbit ranges from several milliseconds when you're talking to a satellite directly overhead, up to as much as 80 ms when the satellite is on the horizon. These systems are more likely to use intersatellite links, and their path delay can vary depending on how the traffic gets routed through the network 🌀

Satellite channels are dominated by two fundamental characteristics, as described below 👑

NOISE - The strength of a radio signal falls in proportion to the square of the distance traveled. For a satellite link, the distance is large, so the signal gets weak before it reaches its destination. This results in a low signal-to-noise ratio. Some frequencies are especially susceptible to atmospheric effects like rain attenuation. For mobile applications, satellite channels are particularly susceptible to multi-path distortion and shadowing (e.g., blockage by buildings) 🏢 Typical bit error rates (BER) for a satellite link today are on the order of 1 error per 10 million bits (1 x 10^-7) or less frequent. Advanced error control coding (e.g., Reed Solomon) can be added to existing satellite services, and lots of services are using it right now 💪 Satellite error performance approaching fiber will become more common as advanced error control coding is used in new systems. However, many legacy satellite systems will keep showing a higher BER than newer satellite systems and terrestrial channels 😬

BANDWIDTH - The radio spectrum is a limited natural resource, so only a restricted amount of bandwidth is available to satellite systems, and it's typically controlled by licenses 🎫 This scarcity makes it hard to trade bandwidth to solve other design problems. Typical carrier frequencies for current, point-to-point, commercial satellite services are 6 GHz (uplink) and 4 GHz (downlink), also known as C band, and 14/12 GHz (Ku band). A new service at 30/20 GHz (Ka band) will be emerging over the next few years ✨ Satellite-based radio repeaters are known as transponders. Traditional C band transponder bandwidth is typically 36 MHz, enough for one color television channel (or 1200 voice channels). Ku band transponders are typically around 50 MHz. And one satellite may carry a few dozen transponders 📡

Bandwidth is limited by nature, and on top of that, the allocations for commercial communications are limited by international agreements, so this scarce resource can be shared fairly by many different applications 🌍

Satellites have certain disadvantages compared to fiber channels (e.g., they can't be easily repaired, rain fades, etc.), but they also have certain advantages over terrestrial links 🌤️ First, satellites have a natural broadcast capability, which gives them an advantage for multicast applications 📣 Next, satellites can reach geographically remote areas or countries that have little terrestrial infrastructure. A related advantage is that satellite links can reach mobile users 🚐

Satellite channels have several characteristics that differ from most terrestrial channels, and these characteristics may degrade the performance of TCP 😤 They include:

Long feedback loop - Because of the propagation delay of some satellite channels (e.g., approximately 250 ms over a geosynchronous satellite), it may take a long time for a TCP sender to figure out whether a packet has been successfully received at the final destination 🐢 This delay hurts interactive applications such as telnet, as well as some of the TCP congestion control algorithms (see section 4).

Large delay*bandwidth product - The delay*bandwidth product (DBP) defines the amount of data a protocol should have "in flight" (data that has been transmitted but not yet acknowledged) at any one time to fully use the available channel capacity 🪣 The delay in this equation is the RTT, and the bandwidth is the capacity of the bottleneck link in the network path. Because the delay in some satellite environments is large, TCP will need to keep a large number of packets "in flight" (that is, sent but not yet acknowledged) 📦

Transmission errors - Satellite channels exhibit a higher bit-error rate (BER) than typical terrestrial networks. TCP uses all packet drops as signals of network congestion and reduces its window size in an attempt to ease the congestion 🚦 Without knowing why a packet was dropped (congestion or corruption), TCP must assume the drop was due to network congestion to avoid congestion collapse [Jac88] [FF98]. So packets dropped due to corruption cause TCP to shrink its sliding window, even though those drops don't signal congestion in the network 😭

Asymmetric use - Because the equipment used to send data to satellites is expensive, asymmetric satellite networks are often built 🧾 For example, a host connected to a satellite network might send all outgoing traffic over a slow terrestrial link (such as a dialup modem channel) and receive incoming traffic via the satellite channel. Another common situation is when both incoming and outgoing traffic use a satellite link, but the uplink has less available capacity than the downlink, because the transmitter needed for a high bandwidth back channel is expensive. This asymmetry may have an impact on TCP performance 🙃

Variable Round Trip Times - In some satellite environments, such as low-Earth orbit (LEO) constellations, the propagation delay to and from the satellite changes over time. Whether or not this has an impact on TCP performance is currently an open question 🤔

Intermittent connectivity - In non-GSO satellite orbit configurations, TCP connections must be transferred from one satellite to another, or from one ground station to another, from time to time. This handoff may cause packet loss if it isn't properly performed 🫣

Most satellite channels only exhibit a subset of the above characteristics. Also, satellite networks aren't the only environments where these characteristics show up. However, satellite networks do tend to exhibit more of these problems, or the problems get worse in the satellite environment 💀 The mechanisms outlined in this document should benefit most networks, especially those with one or more of the above characteristics (e.g., gigabit networks have large delay*bandwidth products) 🦋

3. Lower Level Mitigations ✨

okay so bestie, it is recommended that anyone using satellite channels in their networks should use two non-TCP mechanisms that can boost TCP performance 🫶 They're Path MTU Discovery and forward error correction (FEC), and we'll unpack both in the next two sections 💅

The data link layer protocol on a satellite channel can seriously change how well the higher layer protocols perform 😭 Making that work is out of scope for this doc, but if you're building satellite networks you should tune those protocols properly so the data link protocol doesn't end up limiting TCP performance. Data link layers often have a flow control window and retransmission mechanisms, and when the link level window is too small, performance suffers the same way it would if the TCP window were too small (see section 4.3 for a discussion of appropriate window sizes) 🙈 The impact link level retransmissions have on TCP transfers is not currently well understood, and how TCP retransmissions and link level retransmissions interact is a subject for further research 🔬

3.1 Path MTU Discovery 🎀

Path MTU discovery [MD90] is how you figure out the biggest packet a connection can use on a given network path without getting hit with IP fragmentation 🧚 The sender sends a packet sized for its own local network (for example, 1500 bytes on an Ethernet) and sets the IP "don't fragment" (DF) bit. If the packet is too big to go out over some channel along the path without being fragmented, the gateway that would normally fragment it and forward the pieces will send an ICMP message back to the packet's originator instead. That ICMP message says the original segment couldn't be transmitted without fragmenting, and it also includes the size of the largest packet that gateway can forward. More info from the IESG about Path MTU discovery is in [Kno93] 📚

Path MTU Discovery lets TCP use the largest packet size possible without paying the cost of fragmentation and reassembly, and that's a big deal 💖 Large packets are more efficient because you get more data bytes for each overhead byte. As section 4 explains, TCP's congestion window grows per segment rather than per byte, so bigger segments let TCP senders grow the congestion window faster in terms of bytes than smaller segments do ✨

The downside of Path MTU Discovery is that it can delay when TCP is able to start sending data 🥺 Say a packet goes out with the DF bit set and one of the gateways in the middle (G1) sends back an ICMP message saying it can't forward the segment. The sending host shrinks the packet to the size G1 asked for and sends another packet with the DF bit set. G1 will forward that one, but that doesn't guarantee every later gateway on the path can handle it either. If a second gateway (G2) can't forward the segment, it sends its own ICMP message back to the transmitting host and the whole process repeats 🔁 So path MTU discovery can eat up a lot of time figuring out the maximum allowable packet size between sender and receiver. Satellite delays can make this worse (think about the case where the channel between G1 and G2 is a satellite link) 🛰️ That said, in practice Path MTU Discovery doesn't take a huge amount of time, thanks to wide support of common MTU values. Caching MTU values might also get rid of discovery time in lots of cases, although how to implement that and how to age the cached values is still an open problem 🌈

The relationship between BER and segment size will probably vary depending on the error characteristics of the channel. That relationship deserves more study, but with good forward error correction (see section 3.2), larger segments should give better performance, same as with any network [MSMO97] 💅 The exact method for picking the best MTU for a satellite link is outside the scope of this document, but using Path MTU Discovery is recommended so TCP can use the largest possible MTU over the satellite channel 👑

3.2 Forward Error Correction 💜

A loss event in TCP is always read as a sign of congestion, and it always makes TCP shrink its congestion window size 😩 The congestion window grows based on returning acknowledgments (see section 4), so when you're on a satellite network, TCP spends a long time recovering from loss. When packet loss comes from corruption instead of congestion, TCP doesn't actually need to shrink its congestion window. The catch is that detecting corruption loss is still a research issue right now 🙈

So if TCP is going to run efficiently, the channel should be set up so that nearly all loss comes from network congestion. Forward error correction coding (FEC) should be used on a satellite link to improve the bit-error rate (BER) of the channel 🦋 Reducing BER isn't always possible in satellite environments, though. TCP takes forever to recover from lost packets because the long propagation delay of a satellite link slows down feedback from the receiver [PS97], so the link should be as clean as possible to keep TCP connections from getting false congestion signals 🧊 This document doesn't make a specific BER recommendation for TCP beyond saying it should be as low as possible 📉

FEC should not be expected to fix every problem with noisy satellite links 🥲 There are situations where FEC can't be expected to solve the noise problem (such as military jamming, deep space missions, noise caused by rain fade, etc.). Link outages can also cause problems in satellite systems that don't happen as often in terrestrial networks. And FEC isn't free: it needs extra hardware, it uses some of the available bandwidth, and it can add delay and timing jitter because of the processing time of the coder/decoder 💸

More research is needed into mechanisms that let TCP tell congestion-induced drops apart from drops caused by corruption 🔍 That kind of mechanism would let TCP respond to congestion appropriately, and also repair corruption-induced loss without reducing the transmission rate. Until something like that exists, though, packet loss has to be assumed to mean congestion, so the network stays stable. If you misread loss as corruption and don't reduce the transmission rate to match, you can end up in congestive collapse [Jac88] [FF98] 🚨

4. Standard TCP Mechanisms 🌸

This section walks through TCP mechanisms that may be needed in satellite or hybrid satellite/terrestrial networks to make better use of the link's available capacity 🛰️ These mechanisms may also be needed to fully use fast terrestrial channels. And these mechanisms don't fundamentally hurt performance in a shared terrestrial network, so no drama there ✨ Each of the sections below covers one mechanism and why it might be needed.

4.1 Congestion Control 🦋

To avoid sending an inappropriate amount of network traffic for the current network conditions, TCP uses four congestion control mechanisms during a connection [Jac88] [Jac90] [Ste97] 🧠 They're slow start, congestion avoidance, fast retransmit, and fast recovery. These algorithms adjust how much unacknowledged data can be injected into the network, and they retransmit segments the network dropped 🔄

TCP senders use two state variables for congestion control 🎀 The first is the congestion window (cwnd). It's an upper bound on how much data the sender can inject into the network before it gets an acknowledgment (ACK). The value of cwnd is limited to the receiver's advertised window. The congestion window goes up or down during the transfer based on how much congestion the network seems to have. The second is the slow start threshold (ssthresh), which decides which algorithm is used to increase cwnd. If cwnd is less than ssthresh, slow start is used to increase cwnd. But if cwnd is greater than or equal to ssthresh (or just greater than, in some TCP implementations), congestion avoidance is used instead 💅 The initial value of ssthresh is the receiver's advertised window size, and ssthresh gets set whenever congestion is detected 😤

The four congestion control algorithms are outlined below, followed by a quick look at how satellite environments affect them 👑

4.1.1 Slow Start and Congestion Avoidance 💖

When a host starts sending data on a TCP connection, it has no idea what the network between itself and the receiver looks like right now 🫠 To avoid blasting an inappropriately large burst of traffic, the data sender is required to use slow start at the beginning of a transfer [Jac88] [Bra89] [Ste97]. Slow start begins by setting cwnd to 1 segment (although an IETF experimental mechanism would bump the initial window up to roughly 4 Kbytes [AFP98]) and ssthresh to the receiver's advertised window. That forces TCP to send one segment and then wait for its ACK 🐢 For every ACK received during slow start, cwnd goes up by 1 segment. For example, after the first ACK comes in, cwnd will be 2 segments, so the sender can send 2 data packets. This keeps going until cwnd meets or exceeds ssthresh (or, in some implementations, when cwnd equals ssthresh), or until loss is detected 📈

When cwnd is greater than or equal to ssthresh (or equal to it in certain implementations), congestion avoidance is used to increase cwnd [Jac88] [Bra89] [Ste97]. This algorithm grows cwnd more slowly than slow start does 🌙 Congestion avoidance is there to slowly probe the network for extra capacity. During congestion avoidance, cwnd goes up by 1/cwnd for each incoming ACK. So if one ACK comes back for every data segment, cwnd grows by roughly 1 segment per round-trip time (RTT) ⏱️

Slow start and congestion control can force poor use of the available channel bandwidth over long-delay satellite networks [All97] 😩 Take this example: transmission starts with one segment. After that first segment goes out, the sender has to sit there waiting for its ACK. On a GSO satellite, this leads to an idle time of roughly 500 ms where no useful work gets done 💀 So slow start takes more real time over GSO satellites than it does on typical terrestrial channels, and congestion avoidance has the same problem [All97]. This is exactly why Path MTU Discovery is such an important algorithm 🫶 The number of segments we send is decided by the congestion control algorithms, but the size of those segments is not.

Therefore, using larger packets lets TCP send more data per segment, which gives better channel utilization 🌟

4.1.2 Fast Retransmit and Fast Recovery 💅

okay so TCP's default way to notice a dropped segment is a timeout [Pos81] 🙈 If the sender doesn't get an ACK for a packet in the expected amount of time, it just resends that segment. The retransmission timeout (RTO) is built from observations of the RTT ⏱️ But TCP doesn't only resend when the RTO expires. It also treats that lost segment as a sign of congestion in the network 🚦 So it sets ssthresh to half of cwnd and drops cwnd down to 1 segment. That kicks off slow start, which grows cwnd back up until it reaches half of what it was when congestion was detected. After slow start, congestion avoidance takes over and probes the network for extra capacity 🦋

TCP ACKs always acknowledge the highest in-order segment that has arrived, so an ACK for segment X also effectively ACKs all segments < X ✨ Here's the tea: if a segment shows up out of order, the ACK it triggers covers the highest in-order segment, not the one that just arrived 👀 For example, say segment 11 got dropped somewhere in the network and segment 12 reaches the receiver. The receiver is going to send a duplicate ACK covering segment 10 (and all the segments before it) 🫶

The fast retransmit algorithm uses those duplicate ACKs to spot lost segments 🔥 If 3 duplicate ACKs arrive at the data originator, TCP assumes a segment got lost and retransmits the missing one without waiting for the RTO to expire. Then the fast recovery algorithm adjusts the congestion window 💖 First, ssthresh is set to half of the value of cwnd. Next, cwnd is halved. Finally, cwnd is artificially increased by 1 segment for each duplicate ACK that has arrived. That inflation is totally legit because each duplicate ACK represents 1 segment that has left the network 🧚 When cwnd permits, TCP can send new data, so data keeps flowing through the network at half the rate it was at when loss was detected. When an ACK for the retransmitted packet arrives, cwnd gets reduced back to ssthresh (half the value of cwnd when the congestion was detected) 🌸

Generally, fast retransmit can only resend one segment per window of data 🙃 When multiple segments are lost in the same window, one of them gets resent via fast retransmit, and the rest usually have to wait for the RTO to expire. That makes TCP revert to slow start 😭

TCP's response to congestion depends on how the congestion was detected 💅 If the retransmission timer causes a packet to be resent, TCP drops ssthresh to half the current cwnd and reduces cwnd to 1 segment, which triggers slow start. But if a segment is resent via fast retransmit, both ssthresh and cwnd are set to half the current value of cwnd, and congestion avoidance is used to send new data. The difference is that when retransmitting because of duplicate ACKs, TCP knows packets are still flowing through the network, so it can infer that the congestion isn't that bad 🌈 When resending because the retransmission timer expired, TCP can't infer anything about the state of the network, so it has to be conservative and send new data using the slow start algorithm 🥺

Note that the fast retransmit/fast recovery algorithms, as discussed above, can lead to a phenomenon that allows multiple fast retransmits per window of data [Flo94] ⚠️ That can reduce the size of the congestion window multiple times in response to a single "loss event". The problem is especially noticeable on connections with large congestion windows, since those connections can inject enough new segments into the network during recovery to trigger the multiple fast retransmits. Reducing cwnd multiple times for a single loss event may hurt performance [GJKFV98] 💀

The best way to improve the fast retransmit/fast recovery algorithms is to use a selective acknowledgment (SACK) based algorithm for loss recovery 👑 As discussed below, these algorithms are generally able to quickly recover from multiple lost segments without needlessly reducing the value of cwnd. In the absence of SACKs, the fast retransmit and fast recovery algorithms should be used. Fixing these algorithms to achieve better performance in the face of multiple fast retransmissions is beyond the scope of this document. Therefore, TCP implementers are advised to implement the current version of fast retransmit/fast recovery outlined in RFC 2001 [Ste97] or subsequent versions of RFC 2001 🎀

4.1.3 Congestion Control in Satellite Environment 🛰️

The above algorithms can hurt the performance of an individual TCP connection 🥲 They slowly probe the network for additional capacity, which in turn wastes bandwidth. This is especially true over long-delay satellite channels, because the sender needs a lot of time to get feedback from the receiver [All97] [AHKO97]. However, the algorithms are necessary to prevent congestive collapse in a shared network [Jac88]. So the negative impact on a given connection is more than offset by the benefit to the entire network 🫶✨

4.2 Large TCP Windows 🪟

The standard maximum TCP window size (65,535 bytes) isn't enough for a single TCP connection to use the entire bandwidth available on some satellite channels 😩 TCP throughput is limited by the following formula [Pos81]:

throughput = window size / RTT

So, using the maximum window size of 65,535 bytes and a geosynchronous satellite channel RTT of 560 ms [Kru95], the maximum throughput is limited to:

throughput = 65,535 bytes / 560 ms = 117,027 bytes/second

Therefore, a single standard TCP connection can't fully use, for example, T1 rate (approximately 192,000 bytes/second) GSO satellite channels 🙈 Good news, though: TCP has been extended to support larger windows [JBB92]. The window scaling options outlined in [JBB92] should be used in satellite environments, along with the companion algorithms PAWS (Protection Against Wrapped Sequence space) and RTTM (Round-Trip Time Measurements) 💜

It's worth noting that for a satellite link shared among many flows, large windows may not be necessary 🌸 For instance, two long-lived TCP connections each using a window of 65,535 bytes, as in the example above, can fully utilize a T1 GSO satellite channel.

Using large windows often means both client and server applications or TCP stacks have to be hand tuned (usually by an expert) 🧑‍🔧 Research into operating system mechanisms that can adjust buffer capacity to match current network conditions is underway [SMM98]. That will let stock TCP implementations and applications make better use of the capacity the underlying network provides 🍓

4.3 Acknowledgment Strategies 🧾

There are two standard methods that TCP receivers can use to generate acknowledgments 🌈 The method outlined in [Pos81] generates an ACK for each incoming segment. [Bra89] states that hosts SHOULD use "delayed acknowledgments" 🦋 With this algorithm, an ACK is generated for every second full-sized segment, or if a second full-size segment doesn't arrive within a given timeout (which must not exceed 500 ms). The congestion window grows based on the number of incoming ACKs, and delayed ACKs reduce how many ACKs the receiver sends. So cwnd growth is much slower with delayed ACKs than when the receiver ACKs each incoming segment [All98] 🐢

A tempting "fix" for the problem caused by delayed ACKs is to just turn the mechanism off and let the receiver ACK each incoming segment 🙅‍♀️ However, this is not recommended. First, [Bra89] says that a TCP receiver SHOULD generate delayed ACKs. And second, increasing the number of ACKs by a factor of two in a shared network may have consequences that aren't yet understood 🤔 So disabling delayed ACKs is still a research issue, and at this time TCP receivers should keep generating delayed ACKs, per [Bra89] ✨

4.4 Selective Acknowledgments 🎯

Selective acknowledgments (SACKs) [MMFR96] let TCP receivers tell TCP senders exactly which packets have arrived 💖 SACKs help TCP recover more quickly from lost segments, and they avoid needless retransmissions. Iconic behavior 👑

The fast retransmit algorithm can generally only repair one loss per window of data 😤 When multiple losses happen, the sender usually has to rely on a timeout to figure out which segment needs to be retransmitted next. While it waits for that timeout, the data segments and their acknowledgments drain from the network. Without incoming ACKs to clock new segments into the network, the sender has to use the slow start algorithm to restart transmission. As discussed above, slow start can be time consuming over satellite channels 🥶 When SACKs are employed, the sender is generally able to work out which segments need to be retransmitted in the first RTT following loss detection. That lets the sender keep transmitting segments (retransmissions and new segments, if appropriate) at an appropriate rate, which sustains the ACK clock and avoids a costly slow start period after multiple lost segments 🙌 Generally, SACK is able to retransmit all dropped segments within the first RTT following loss detection 🏃‍♀️

[MM96] and [FF96] discuss specific congestion control algorithms that rely on SACK information to determine which segments need to be retransmitted and when it's appropriate to send them 🧠 Both of these algorithms follow the basic principles of congestion control outlined in [Jac88] and reduce the window by half when congestion is detected 💅🌸

5. Mitigation Summary ✨

okay so Table 1 is basically the cheat sheet 📋💖 it sums up every mechanism we've been yapping about in this doc. The ones marked "Recommended" are IETF standards track mechanisms the authors actually suggest for networks that have satellite channels 🛰️, and the ones marked "Required" are things the IETF has already defined as required for hosts on the shared Internet [Bra89]. Next to each mechanism we also say where it needs to be implemented 🎀. The last column uses three codes: "S" for the data sender, "R" for the data receiver, and "L" for the satellite link 🧚

   Mechanism                 Use          Section      Where
   +------------------------+-------------+------------+--------+
   | Path-MTU Discovery     | Recommended | 3.1        | S      |
   | FEC                    | Recommended | 3.2        | L      |
   | TCP Congestion Control |             |            |        |
   |   Slow Start           | Required    | 4.1.1      | S      |
   |   Congestion Avoidance | Required    | 4.1.1      | S      |
   |   Fast Retransmit      | Recommended | 4.1.2      | S      |
   |   Fast Recovery        | Recommended | 4.1.2      | S      |
   | TCP Large Windows      |             |            |        |
   |   Window Scaling       | Recommended | 4.2        | S,R    |
   |   PAWS                 | Recommended | 4.2        | S,R    |
   |   RTTM                 | Recommended | 4.2        | S,R    |
   | TCP SACKs              | Recommended | 4.4        | S,R    |
   +------------------------+-------------+------------+--------+
                                Table 1

satellite users, you should check with your TCP vendors (the implementors 🛠️) to make sure the recommended mechanisms are supported in your stack, in current and/or future versions 💅. Or, if you want a shortcut, the Pittsburgh Supercomputer Center tracks which TCP implementations support which extensions, and they also give tuning guidance for different TCP implementations [PSC] 🌸

research into making TCP more efficient over satellite channels is still ongoing 🔥 and it'll get summarized in a planned memo, along with other stuff like satellite network architectures 🦋

6. Security Considerations 🔒

okay this part is serious bestie, so read it properly 🫶 The authors believe the recommendations in this memo do not change the security implications of TCP. BUT when you use a broadcast medium like satellite links to move user data and/or network control traffic, you should be aware of the built-in security implications of that tech 👀

eavesdropping on a network link is a form of passive attack 😭 If it works, it could reveal critical traffic control information and jeopardize the proper functioning of the network. It can also make the network worse at delivering data efficiently. Eavesdroppers can also compromise the privacy of user data, especially if end-to-end security mechanisms aren't in use 💀 Passive monitoring can happen on any network, but the wireless broadcast nature of satellite links lets someone receive signals without a physical connection to the network, so monitoring can happen without detection 🙈 That said, it should be noted that the resources needed to monitor a satellite link are non-trivial 🧐

data encryption at the physical and/or link layers can give you secure communication over satellite channels ✨ However, this still leaves traffic vulnerable to eavesdropping on the networks before and after it crosses the satellite link. So, end-to-end security mechanisms should be considered 🎀 This document does not make any recommendations about which security mechanisms to use. Instead, those operating and using satellite networks should survey the currently available network security mechanisms and choose the ones that meet their security requirements 💜

Acknowledgments 🫶

this document has benefited from comments from members of the TCP Over Satellite Working Group 🌈 In particular, the authors want to thank Aaron Falk, Matthew Halsey, Hans Kruse, Matt Mathis, Greg Nakanishi, Vern Paxson, Jeff Semke, Bill Sepmeier and Eric Travis for their useful comments about this document 💖

References 📚

[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.

[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, and Shawn Ostermann. TCP Performance Over Satellite Links. In Proceedings of the 5th International Conference on Telecommunication Systems, March 1997.

[All97] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.

[All98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.

[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.

[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996.

[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking.

[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical report, October 1994. ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.

[GJKFV98] Rohit Goyal, Raj Jain, Shiv Kalyanaraman, Sonia Fahmy, Bobby Vandalore, Improving the Performance of TCP over the ATM-UBR service, 1998. Sumbitted to Computer Communications.

[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical Report, LBL, April 1990.

[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.

[Jac88] Van Jacobson. Congestion Avoidance and Control. In ACM SIGCOMM, 1988.

[Kno93] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.

[Mar78] James Martin. Communications Satellite Systems. Prentice Hall, 1978.

[MD90] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.

[MM96] Matt Mathis and Jamshid Mahdavi. Forward Acknowledgment: Refining TCP Congestion Control. In ACM SIGCOMM, 1996.

[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.

[Mon98] M. J. Montpetit. TELEDESIC: Enabling The Global Community Interaccess. In Proc. of the International Wireless Symposium, May 1998.

[MSMO97] M. Mathis, J. Semke, J. Mahdavi, T. Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communication Review, volume 27, number3, July 1997. available from http://www.psc.edu/networking/papers/papers.html.

[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[PS97] Craig Partridge and Tim Shepard. TCP Performance Over Satellite Links. IEEE Network, 11(5), September/October 1997.

[PSC] Jamshid Mahdavi. Enabling High Performance Data Transfers on Hosts. http://www.psc.edu/networking/perf_tune.html.

[SMM98] Jeff Semke, Jamshid Mahdavi and Matt Mathis. Automatic TCP Buffer Tuning. In ACM SIGCOMM, August 1998. To appear.

[Sta94] William Stallings. Data and Computer Communications. MacMillian, 4th edition, 1994.

[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001,January 1997.

[Stu95] M. A. Sturza. Architecture of the TELEDESIC Satellite System. In Proceedings of the International Mobile Satellite Conference, 1995.

Authors' Addresses 📮

Mark Allman
NASA Lewis Research Center/Sterling Software
21000 Brookpark Rd.  MS 54-2
Cleveland, OH  44135

Phone: +1 216 433 6586
EMail: mallman@lerc.nasa.gov
http://roland.lerc.nasa.gov/~mallman


Daniel R. Glover
NASA Lewis Research Center
21000 Brookpark Rd.
Cleveland, OH  44135

Phone: +1 216 433 2847
EMail: Daniel.R.Glover@lerc.nasa.gov


Luis A. Sanchez
BBN Technologies
GTE Internetworking
10 Moulton Street
Cambridge, MA  02140
USA

Phone: +1 617 873 3351
EMail: lsanchez@ir.bbn.com

Full Copyright Statement ⚖️

Copyright (C) The Internet Society (1999).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

📦 where this page comes from

ietf: rfc2488 1999-01
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms