Network Working Group M. Allman
Request for Comments: 2488 NASA Lewis/Sterling Software
BCP: 28 D. Glover
Category: Best Current Practice NASA Lewis
L. Sanchez
BBN
January 1999
Network Working Group M. Allman
Request for Comments: 2488 NASA Lewis/Sterling Software
BCP: 28 D. Glover
Category: Best Current Practice NASA Lewis
L. Sanchez
BBN
January 1999
Enhancing TCP Over Satellite Channels using Standard Mechanisms
使用标准机制增强卫星信道上的TCP
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
The Transmission Control Protocol (TCP) provides reliable delivery of data across any network path, including network paths containing satellite channels. While TCP works over satellite channels there are several IETF standardized mechanisms that enable TCP to more effectively utilize the available capacity of the network path. This document outlines some of these TCP mitigations. At this time, all mitigations discussed in this document are IETF standards track mechanisms (or are compliant with IETF standards).
传输控制协议（TCP）通过任何网络路径（包括包含卫星信道的网络路径）提供可靠的数据传输。虽然TCP在卫星信道上工作，但有几种IETF标准化机制使TCP能够更有效地利用网络路径的可用容量。本文档概述了其中一些TCP缓解措施。目前，本文件中讨论的所有缓解措施均为IETF标准跟踪机制（或符合IETF标准）。
Satellite channel characteristics may have an effect on the way transport protocols, such as the Transmission Control Protocol (TCP) [Pos81], behave. When protocols, such as TCP, perform poorly, channel utilization is low. While the performance of a transport protocol is important, it is not the only consideration when constructing a network containing satellite links. For example, data link protocol, application protocol, router buffer size, queueing discipline and proxy location are some of the considerations that must be taken into account. However, this document focuses on improving TCP in the satellite environment and non-TCP considerations are left for another document. Finally, there have been many satellite mitigations proposed and studied by the research community. While these mitigations may prove useful and safe for shared networks in the future, this document only considers TCP mechanisms which are
卫星信道特性可能会影响传输协议（如传输控制协议（TCP）[Pos81]）的行为方式。当协议（如TCP）性能较差时，通道利用率较低。虽然传输协议的性能很重要，但在构建包含卫星链路的网络时，它不是唯一的考虑因素。例如，必须考虑数据链路协议、应用程序协议、路由器缓冲区大小、排队规则和代理位置。但是，本文档重点介绍如何在卫星环境中改进TCP，非TCP方面的注意事项将留待另一文档讨论。最后，研究界提出并研究了许多卫星缓解措施。虽然这些缓解措施在将来可能对共享网络有用且安全，但本文档仅考虑以下TCP机制：
currently well understood and on the IETF standards track (or are compliant with IETF standards).
目前已被充分理解并处于IETF标准轨道上（或符合IETF标准）。
This document is divided up as follows: Section 2 provides a brief outline of the characteristics of satellite networks. Section 3 outlines two non-TCP mechanisms that enable TCP to more effectively utilize the available bandwidth. Section 4 outlines the TCP mechanisms defined by the IETF that may benefit satellite networks. Finally, Section 5 provides a summary of what modern TCP implementations should include to be considered "satellite friendly".
本文件分为以下几部分：第2节简要概述了卫星网络的特点。第3节概述了使TCP能够更有效地利用可用带宽的两种非TCP机制。第4节概述了IETF定义的可能有益于卫星网络的TCP机制。最后，第5节总结了现代TCP实现应包括哪些内容以被视为“卫星友好”。
There is an inherent delay in the delivery of a message over a satellite link due to the finite speed of light and the altitude of communications satellites.
由于光速和通信卫星的高度有限，通过卫星链路传送信息存在固有的延迟。
Many communications satellites are located at Geostationary Orbit (GSO) with an altitude of approximately 36,000 km [Sta94]. At this altitude the orbit period is the same as the Earth's rotation period. Therefore, each ground station is always able to "see" the orbiting satellite at the same position in the sky. The propagation time for a radio signal to travel twice that distance (corresponding to a ground station directly below the satellite) is 239.6 milliseconds (ms) [Mar78]. For ground stations at the edge of the view area of the satellite, 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"). Therefore, the propagation delay for a message and the corresponding reply (one round-trip time or RTT) could be at least 558 ms. The RTT is not based solely on satellite propagation time. The RTT will be increased by other factors in the network, such as the transmission time and propagation time of other links in the network path and queueing delay in gateways. Furthermore, the satellite propagation delay will be longer if the link includes multiple hops or if intersatellite links are used. As satellites become more complex and include on-board processing of signals, additional delay may be added.
许多通信卫星位于地球静止轨道（GSO），高度约为36000公里[Sta94]。在这个高度上，轨道周期与地球自转周期相同。因此，每个地面站总是能够“看到”在天空中相同位置的轨道卫星。无线电信号传播两倍于该距离（对应于卫星正下方的地面站）的传播时间为239.6毫秒（ms）[Mar78]。对于位于卫星视场边缘的地面站，移动距离为2 x 41756 km，总传播延迟为279.0 ms[Mar78]。这些延迟适用于一条地面站到卫星到地面站的路线（或“hop”）。因此，消息和相应回复的传播延迟（一个往返时间或RTT）可以至少为558 ms。RTT不完全基于卫星传播时间。网络中的其他因素会增加RTT，例如网络路径中其他链路的传输时间和传播时间以及网关中的排队延迟。此外，如果链路包括多个跳或如果使用卫星间链路，则卫星传播延迟将更长。随着卫星变得更加复杂，并包括信号的星上处理，可能会增加额外的延迟。
Other orbits are possible for use by communications satellites including Low Earth Orbit (LEO) [Stu95] [Mon98] and Medium Earth Orbit (MEO) [Mar78]. The lower orbits require the use of constellations of satellites for constant coverage. In other words, as one satellite leaves the ground station's sight, another satellite appears on the horizon and the channel is switched to it. The propagation delay to a LEO orbit ranges from several milliseconds when communicating with a satellite directly overhead, to as much as 80 ms when the satellite is on the horizon. These systems are more
其他轨道也可供通信卫星使用，包括低地球轨道（LEO）[Stu95][Mon98]和中地球轨道（MEO）[Mar78]。较低的轨道需要使用卫星星座进行持续覆盖。换句话说，当一颗卫星离开地面站的视线时，另一颗卫星出现在地平线上，频道切换到它。到低轨轨道的传播延迟从直接在头顶与卫星通信时的几毫秒到卫星在地平线上时的80毫秒不等。这些系统更加复杂
likely to use intersatellite links and have variable path delay depending on routing 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 and so the signal becomes weak before reaching its destination. This results in a low signal-to-noise ratio. Some frequencies are particularly susceptible to atmospheric effects such as rain attenuation. For mobile applications, satellite channels are especially 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 is currently being used by many services. 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 continue to exhibit higher BER than newer satellite systems and terrestrial channels.
噪声-无线电信号的强度与行驶距离的平方成比例下降。对于卫星链路，距离很大，因此信号在到达目的地之前变得很弱。这导致低信噪比。有些频率特别容易受到大气影响，如降雨衰减。对于移动应用，卫星信道特别容易受到多径失真和阴影的影响（例如，建筑物堵塞）。目前卫星链路的典型误比特率（BER）约为每1000万比特1个错误（1 x 10^-7）或更低的频率。先进的差错控制编码（如Reed Solomon）可以添加到现有的卫星服务中，目前正被许多服务使用。随着新系统采用先进的差错控制编码，接近光纤的卫星差错性能将变得更加普遍。然而，许多传统卫星系统将继续表现出比较新的卫星系统和地面信道更高的误码率。
BANDWIDTH - The radio spectrum is a limited natural resource, hence there is a restricted amount of bandwidth available to satellite systems which is typically controlled by licenses. This scarcity makes it difficult 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 to accommodate one color television channel (or 1200 voice channels). Ku band transponders are typically around 50 MHz. Furthermore, one satellite may carry a few dozen transponders.
带宽-无线电频谱是一种有限的自然资源，因此卫星系统的可用带宽有限，通常由许可证控制。这种稀缺性使得很难通过交换带宽来解决其他设计问题。当前、点对点、商业和卫星服务的典型载波频率为6GHz（上行链路）和4GHz（下行链路），也称为C波段和14/12GHz（Ku波段）。未来几年将出现30/20GHz（Ka频段）的新业务。基于卫星的无线电中继器被称为转发器。传统的C波段转发器带宽通常为36 MHz，以容纳一个彩色电视频道（或1200个语音频道）。Ku波段转发器通常在50 MHz左右。此外，一颗卫星可能携带几十个转发器。
Not only is bandwidth limited by nature, but the allocations for commercial communications are limited by international agreements so that this scarce resource can be used fairly by many different applications.
带宽不仅受到自然条件的限制，而且商业通信的分配也受到国际协议的限制，因此这种稀缺资源可以被许多不同的应用程序公平使用。
Although satellites have certain disadvantages when compared to fiber channels (e.g., cannot be easily repaired, rain fades, etc.), they also have certain advantages over terrestrial links. First, satellites have a natural broadcast capability. This gives satellites an advantage for multicast applications. Next, satellites can reach geographically remote areas or countries that have little terrestrial infrastructure. A related advantage is the ability of satellite links to reach mobile users.
尽管与光纤信道相比，卫星具有某些缺点（例如，不易修复、降雨减弱等），但与地面链路相比，卫星也具有某些优势。首先，卫星具有天然的广播能力。这为卫星多播应用提供了优势。其次，卫星可以到达地理上偏远的地区或几乎没有地面基础设施的国家。一个相关的优势是卫星链路能够到达移动用户。
Satellite channels have several characteristics that differ from most terrestrial channels. These characteristics may degrade the performance of TCP. These characteristics include:
卫星频道有几个不同于大多数地面频道的特点。这些特性可能会降低TCP的性能。这些特点包括：
Long feedback loop
长反馈回路
Due to 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 determine whether or not 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).
由于某些卫星信道的传播延迟（例如，在地球同步卫星上大约250 ms），TCP发送方可能需要很长时间来确定是否在最终目的地成功接收到数据包。这种延迟会损害交互式应用程序，如telnet，以及一些TCP拥塞控制算法（参见第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 utilize the available channel capacity. The delay used 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) .
延迟*带宽乘积（DBP）定义了协议在任何时候应具有“飞行中”（已传输但尚未确认的数据）的数据量，以充分利用可用信道容量。该等式中使用的延迟是RTT，带宽是网络路径中瓶颈链路的容量。由于某些卫星环境中的延迟较大，TCP将需要保持大量数据包“飞行”（即，已发送但尚未确认）。
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 alleviate the congestion. In the absence of knowledge about why a packet was dropped (congestion or corruption), TCP must assume the drop was due to network congestion to avoid congestion collapse [Jac88] [FF98]. Therefore, packets dropped due to corruption cause TCP to reduce the size of its sliding window, even though these packet drops do not signal congestion in the network.
卫星信道表现出比典型地面网络更高的误码率（BER）。TCP使用所有丢包作为网络拥塞的信号，并减少其窗口大小以试图缓解拥塞。在不了解数据包为何被丢弃（拥塞或损坏）的情况下，TCP必须假定丢弃是由于网络拥塞造成的，以避免拥塞崩溃[Jac88][FF98]。因此，由于损坏而丢弃的数据包会导致TCP减小其滑动窗口的大小，即使这些数据包丢弃不会发出网络拥塞的信号。
Asymmetric use
不对称使用
Due to the expense of the equipment used to send data to satellites, asymmetric satellite networks are often constructed. For example, a host connected to a satellite network will 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 arises when both the incoming and outgoing traffic are sent using a satellite link, but the uplink has less available capacity than the downlink due to the expense of the transmitter required to provide a high bandwidth back channel. This asymmetry may have an impact on TCP performance.
由于用于向卫星发送数据的设备的费用，通常会构建非对称卫星网络。例如，连接到卫星网络的主机将通过慢速地面链路（如拨号调制解调器信道）发送所有传出流量，并通过卫星信道接收传入流量。当使用卫星链路发送传入和传出业务时，出现另一种常见情况，但是上行链路的可用容量小于下行链路，这是由于提供高带宽反向信道所需的发射机的费用。这种不对称性可能会影响TCP性能。
Variable Round Trip Times
可变往返时间
In some satellite environments, such as low-Earth orbit (LEO) constellations, the propagation delay to and from the satellite varies over time. Whether or not this will have an impact on TCP performance is currently an open question.
在某些卫星环境中，如低地球轨道（LEO）星座，往返卫星的传播延迟随时间而变化。这是否会对TCP性能产生影响目前是一个悬而未决的问题。
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 not properly performed.
在非GSO卫星轨道配置中，TCP连接必须不时地从一颗卫星传输到另一颗卫星，或从一个地面站传输到另一个地面站。如果未正确执行，此切换可能会导致数据包丢失。
Most satellite channels only exhibit a subset of the above characteristics. Furthermore, satellite networks are not the only environments where the above characteristics are found. However, satellite networks do tend to exhibit more of the above problems or the above problems are aggravated 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).
大多数卫星频道仅显示上述特征的一个子集。此外，卫星网络不是发现上述特征的唯一环境。然而，卫星网络确实倾向于表现出更多上述问题，或者上述问题在卫星环境中加剧。本文件中概述的机制应使大多数网络受益，尤其是具有上述一个或多个特征的网络（例如，千兆网络具有大延迟*带宽产品）。
It is recommended that those utilizing satellite channels in their networks should use the following two non-TCP mechanisms which can increase TCP performance. These mechanisms are Path MTU Discovery and forward error correction (FEC) and are outlined in the following two sections.
建议在其网络中使用卫星信道的用户使用以下两种非TCP机制，这两种机制可以提高TCP性能。这些机制是路径MTU发现和前向纠错（FEC），将在以下两部分中概述。
The data link layer protocol employed over a satellite channel can have a large impact on performance of higher layer protocols. While beyond the scope of this document, those constructing satellite
卫星信道上采用的数据链路层协议对更高层协议的性能有很大影响。在本文件的范围之外，建造卫星的
networks should tune these protocols in an appropriate manner to ensure that the data link protocol does not limit TCP performance. In particular, data link layer protocols often implement a flow control window and retransmission mechanisms. When the link level window size is too small, performance will suffer just as when the TCP window size is too small (see section 4.3 for a discussion of appropriate window sizes). The impact that link level retransmissions have on TCP transfers is not currently well understood. The interaction between TCP retransmissions and link level retransmissions is a subject for further research.
网络应以适当的方式调整这些协议，以确保数据链路协议不会限制TCP性能。特别地，数据链路层协议通常实现流控制窗口和重传机制。当链路级窗口大小太小时，性能将受到影响，就像TCP窗口大小太小一样（有关适当窗口大小的讨论，请参阅第4.3节）。链路级重传对TCP传输的影响目前尚不清楚。TCP重传和链路级重传之间的相互作用是一个有待进一步研究的课题。
Path MTU discovery [MD90] is used to determine the maximum packet size a connection can use on a given network path without being subjected to IP fragmentation. The sender transmits a packet that is the appropriate size for the local network to which it is connected (e.g., 1500 bytes on an Ethernet) and sets the IP "don't fragment" (DF) bit. If the packet is too large to be forwarded without being fragmented to a given channel along the network path, the gateway that would normally fragment the packet and forward the fragments will instead return an ICMP message to the originator of the packet. The ICMP message will indicate that the original segment could not be transmitted without being fragmented and will also contain the size of the largest packet that can be forwarded by the gateway. Additional information from the IESG regarding Path MTU discovery is available in [Kno93].
路径MTU发现[MD90]用于确定连接在给定网络路径上可以使用的最大数据包大小，而不受IP碎片的影响。发送方传输适合其所连接的本地网络大小的数据包（例如，以太网上的1500字节），并设置IP“不分段”（DF）位。如果数据包太大，无法在不沿网络路径分段到给定通道的情况下进行转发，则通常会对数据包进行分段并转发分段的网关将向数据包的发起人返回ICMP消息。ICMP消息将指示原始段在不分段的情况下无法传输，并且还将包含可由网关转发的最大数据包的大小。[Kno93]中提供了IESG关于路径MTU发现的其他信息。
Path MTU Discovery allows TCP to use the largest possible packet size, without incurring the cost of fragmentation and reassembly. Large packets reduce the packet overhead by sending more data bytes per overhead byte. As outlined in section 4, increasing TCP's congestion window is segment based, rather than byte based and therefore, larger segments enable TCP senders to increase the congestion window more rapidly, in terms of bytes, than smaller segments.
Path MTU发现允许TCP使用尽可能大的数据包大小，而不会产生碎片和重新组装的成本。大数据包通过每个开销字节发送更多的数据字节来减少数据包开销。如第4节所述，增加TCP的拥塞窗口是基于段的，而不是基于字节的，因此，较大的段使TCP发送方能够比较小的段更快地增加拥塞窗口（以字节计）。
The disadvantage of Path MTU Discovery is that it may cause a delay before TCP is able to start sending data. For example, assume a packet is sent with the DF bit set and one of the intervening gateways (G1) returns an ICMP message indicating that it cannot forward the segment. At this point, the sending host reduces the packet size per the ICMP message returned by G1 and sends another packet with the DF bit set. The packet will be forwarded by G1, however this does not ensure all subsequent gateways in the network path will be able to forward the segment. If a second gateway (G2) cannot forward the segment it will return an ICMP message to the transmitting host and the process will be repeated. Therefore, path
路径MTU发现的缺点是，在TCP能够开始发送数据之前，它可能会导致延迟。例如，假设发送数据包时设置了DF位，并且其中一个中间网关（G1）返回一条ICMP消息，指示它无法转发该段。此时，发送主机根据G1返回的ICMP消息减小数据包大小，并发送另一个设置了DF位的数据包。数据包将由G1转发，但这并不能确保网络路径中的所有后续网关都能转发该段。如果第二个网关（G2）无法转发该段，它将向传输主机返回ICMP消息，并且该过程将重复。因此，路径
MTU discovery can spend a large amount of time determining the maximum allowable packet size on the network path between the sender and receiver. Satellite delays can aggravate this problem (consider the case when the channel between G1 and G2 is a satellite link). However, in practice, Path MTU Discovery does not consume a large amount of time due to wide support of common MTU values. Additionally, caching MTU values may be able to eliminate discovery time in many instances, although the exact implementation of this and the aging of cached values remains an open problem.
MTU发现会花费大量时间确定发送方和接收方之间网络路径上允许的最大数据包大小。卫星延迟会加剧此问题（考虑G1和G2之间的信道为卫星链路时的情况）。然而，在实践中，由于通用MTU值的广泛支持，路径MTU发现不会占用大量时间。此外，在许多情况下，缓存MTU值可能能够消除发现时间，尽管这一点的确切实现和缓存值的老化仍然是一个公开问题。
The relationship between BER and segment size is likely to vary depending on the error characteristics of the given channel. This relationship deserves further study, however with the use of good forward error correction (see section 3.2) larger segments should provide better performance, as with any network [MSMO97]. While the exact method for choosing the best MTU for a satellite link is outside the scope of this document, the use of Path MTU Discovery is recommended to allow TCP to use the largest possible MTU over the satellite channel.
BER和段大小之间的关系可能会根据给定信道的错误特性而变化。这种关系值得进一步研究，但是，通过使用良好的前向纠错（见第3.2节），与任何网络一样，较大的网段应提供更好的性能[MSMO97]。虽然为卫星链路选择最佳MTU的确切方法不在本文档范围内，但建议使用路径MTU发现，以允许TCP在卫星信道上使用尽可能最大的MTU。
A loss event in TCP is always interpreted as an indication of congestion and always causes TCP to reduce its congestion window size. Since the congestion window grows based on returning acknowledgments (see section 4), TCP spends a long time recovering from loss when operating in satellite networks. When packet loss is due to corruption, rather than congestion, TCP does not need to reduce its congestion window size. However, at the present time detecting corruption loss is a research issue.
TCP中的丢失事件总是被解释为拥塞的指示，并且总是导致TCP减小其拥塞窗口大小。由于拥塞窗口基于返回的确认而增长（参见第4节），TCP在卫星网络中运行时需要花费很长时间从丢失中恢复。当数据包丢失是由于损坏而非拥塞造成时，TCP不需要减小其拥塞窗口大小。然而，目前腐败损失的检测是一个研究课题。
Therefore, for TCP to operate efficiently, the channel characteristics should be such that nearly all loss is due to network congestion. The use of forward error correction coding (FEC) on a satellite link should be used to improve the bit-error rate (BER) of the satellite channel. Reducing the BER is not always possible in satellite environments. However, since TCP takes a long time to recover from lost packets because the long propagation delay imposed by a satellite link delays feedback from the receiver [PS97], the link should be made as clean as possible to prevent TCP connections from receiving false congestion signals. This document does not make a specific BER recommendation for TCP other than it should be as low as possible.
因此，为了使TCP有效地运行，信道特性应确保几乎所有的损失都是由于网络拥塞造成的。在卫星链路上使用前向纠错编码（FEC）可以提高卫星信道的误比特率（BER）。在卫星环境中，降低误码率并不总是可能的。然而，由于TCP需要很长时间才能从丢失的数据包中恢复，因为卫星链路施加的长传播延迟延迟了来自接收器的反馈[PS97]，因此链路应尽可能干净，以防止TCP连接接收到错误的拥塞信号。除了尽可能低的误码率外，本文件没有针对TCP提出具体的误码率建议。
FEC should not be expected to fix all problems associated with noisy satellite links. There are some situations where FEC cannot be expected to solve the noise problem (such as military jamming, deep space missions, noise caused by rain fade, etc.). In addition, link
FEC不应被期望解决与嘈杂的卫星链路相关的所有问题。有些情况下，FEC无法解决噪声问题（如军事干扰、深空任务、雨衰引起的噪声等）。此外，链接
outages can also cause problems in satellite systems that do not occur as frequently in terrestrial networks. Finally, FEC is not without cost. FEC requires additional hardware and uses some of the available bandwidth. It can add delay and timing jitter due to the processing time of the coder/decoder.
中断还可能导致卫星系统出现问题，而这些问题在地面网络中并不常见。最后，FEC并非没有成本。FEC需要额外的硬件并使用一些可用带宽。由于编码器/解码器的处理时间，它会增加延迟和定时抖动。
Further research is needed into mechanisms that allow TCP to differentiate between congestion induced drops and those caused by corruption. Such a mechanism would allow TCP to respond to congestion in an appropriate manner, as well as repairing corruption induced loss without reducing the transmission rate. However, in the absence of such a mechanism packet loss must be assumed to indicate congestion to preserve network stability. Incorrectly interpreting loss as caused by corruption and not reducing the transmission rate accordingly can lead to congestive collapse [Jac88] [FF98].
需要进一步研究使TCP能够区分由拥塞引起的丢包和由损坏引起的丢包的机制。这种机制将允许TCP以适当的方式响应拥塞，并在不降低传输速率的情况下修复由损坏引起的丢失。然而，在缺乏这种机制的情况下，必须假设数据包丢失指示拥塞，以保持网络稳定性。错误地将损失解释为腐败造成的损失，而不相应地降低传输速率，可能会导致充血性崩溃[Jac88][FF98]。
This section outlines TCP mechanisms that may be necessary in satellite or hybrid satellite/terrestrial networks to better utilize the available capacity of the link. These mechanisms may also be needed to fully utilize fast terrestrial channels. Furthermore, these mechanisms do not fundamentally hurt performance in a shared terrestrial network. Each of the following sections outlines one mechanism and why that mechanism may be needed.
本节概述了卫星或混合卫星/地面网络中可能需要的TCP机制，以更好地利用链路的可用容量。为了充分利用快速地面信道，也可能需要这些机制。此外，这些机制不会从根本上影响共享地面网络的性能。以下各节概述了一种机制以及可能需要该机制的原因。
To avoid generating an inappropriate amount of network traffic for the current network conditions, during a connection TCP employs four congestion control mechanisms [Jac88] [Jac90] [Ste97]. These algorithms are slow start, congestion avoidance, fast retransmit and fast recovery. These algorithms are used to adjust the amount of unacknowledged data that can be injected into the network and to retransmit segments dropped by the network.
为了避免在当前网络条件下产生不适当的网络流量，TCP在连接期间采用了四种拥塞控制机制[Jac88][Jac90][Ste97]。这些算法具有慢启动、避免拥塞、快速重传和快速恢复等特点。这些算法用于调整可注入网络的未确认数据量，以及重新传输网络丢弃的数据段。
TCP senders use two state variables to accomplish congestion control. The first variable is the congestion window (cwnd). This is an upper bound on the amount of data the sender can inject into the network before receiving an acknowledgment (ACK). The value of cwnd is limited to the receiver's advertised window. The congestion window is increased or decreased during the transfer based on the inferred amount of congestion present in the network. The second variable is the slow start threshold (ssthresh). This variable determines which algorithm is used to increase the value of cwnd. If cwnd is less than ssthresh the slow start algorithm is used to increase the value of cwnd. However, if cwnd is greater than or equal to (or just greater than in some TCP implementations) ssthresh the congestion
TCP发送方使用两个状态变量来完成拥塞控制。第一个变量是拥塞窗口（cwnd）。这是发送方在收到确认（ACK）之前可以注入网络的数据量的上限。cwnd的值仅限于接收者的广告窗口。在传输过程中，根据网络中存在的推测拥塞量增加或减少拥塞窗口。第二个变量是慢启动阈值（ssthresh）。此变量确定用于增加cwnd值的算法。如果cwnd小于ssthresh，则使用慢启动算法增加cwnd的值。但是，如果cwnd大于或等于（或仅大于某些TCP实现中的值），则ssthresh会消除拥塞
avoidance algorithm is used. The initial value of ssthresh is the receiver's advertised window size. Furthermore, the value of ssthresh is set when congestion is detected.
采用回避算法。ssthresh的初始值是接收器的广告窗口大小。此外，当检测到拥塞时，设置ssthresh的值。
The four congestion control algorithms are outlined below, followed by a brief discussion of the impact of satellite environments on these algorithms.
下面概述四种拥塞控制算法，然后简要讨论卫星环境对这些算法的影响。
When a host begins sending data on a TCP connection the host has no knowledge of the current state of the network between itself and the data receiver. In order to avoid transmitting an inappropriately large burst of traffic, the data sender is required to use the slow start algorithm at the beginning of a transfer [Jac88] [Bra89] [Ste97]. Slow start begins by initializing cwnd to 1 segment (although an IETF experimental mechanism would increase the size of the initial window to roughly 4 Kbytes [AFP98]) and ssthresh to the receiver's advertised window. This forces TCP to transmit one segment and wait for the corresponding ACK. For each ACK that is received during slow start, the value of cwnd is increased by 1 segment. For example, after the first ACK is received cwnd will be 2 segments and the sender will be allowed to transmit 2 data packets. This continues until cwnd meets or exceeds ssthresh (or, in some implementations when cwnd equals ssthresh), or loss is detected.
当主机开始在TCP连接上发送数据时，主机不知道自己和数据接收器之间的网络的当前状态。为了避免传输不适当的大流量突发，要求数据发送方在传输开始时使用慢启动算法[Jac88][Bra89][Ste97]。慢启动首先将cwnd初始化为1段（尽管IETF实验机制会将初始窗口的大小增加到大约4 KB[AFP98]），并将ssthresh设置为接收器的播发窗口。这将强制TCP传输一个段并等待相应的ACK。对于慢启动期间接收到的每个ACK，cwnd的值增加1段。例如，在接收到第一个ACK之后，cwnd将是2个段，并且发送方将被允许发送2个数据包。直到cwnd达到或超过ssthresh（或者，在某些实现中，cwnd等于ssthresh），或者检测到丢失为止。
When the value of cwnd is greater than or equal to (or equal to in certain implementations) ssthresh the congestion avoidance algorithm is used to increase cwnd [Jac88] [Bra89] [Ste97]. This algorithm increases the size of cwnd more slowly than does slow start. Congestion avoidance is used to slowly probe the network for additional capacity. During congestion avoidance, cwnd is increased by 1/cwnd for each incoming ACK. Therefore, if one ACK is received for every data segment, cwnd will increase by roughly 1 segment per round-trip time (RTT).
当cwnd的值大于或等于（或在某些实现中等于）ssthresh时，拥塞避免算法用于增加cwnd[Jac88][Bra89][Ste97]。该算法增加cwnd大小的速度比慢速启动慢。拥塞避免用于缓慢探测网络以获得额外容量。在拥塞避免期间，对于每个传入的ACK，cwnd增加1/cwnd。因此，如果每个数据段接收一个ACK，则cwnd将在每个往返时间（RTT）增加大约1个段。
The slow start and congestion control algorithms can force poor utilization of the available channel bandwidth when using long-delay satellite networks [All97]. For example, transmission begins with the transmission of one segment. After the first segment is transmitted the data sender is forced to wait for the corresponding ACK. When using a GSO satellite this leads to an idle time of roughly 500 ms when no useful work is being accomplished. Therefore, slow start takes more real time over GSO satellites than on typical terrestrial channels. This holds for congestion avoidance, as well [All97]. This is precisely why Path MTU Discovery is an important algorithm. While the number of segments we transmit is determined by the congestion control algorithms, the size of these segments is not.
使用长延迟卫星网络时，慢启动和拥塞控制算法可能会导致可用信道带宽利用率低下[All97]。例如，传输从一个段的传输开始。在发送第一段后，数据发送方被迫等待相应的ACK。当使用GSO卫星时，当没有完成任何有用的工作时，这将导致大约500 ms的空闲时间。因此，与典型的地面信道相比，GSO卫星上的慢启动需要更多的实时性。这也适用于避免拥塞[All97]。这正是路径MTU发现是一种重要算法的原因。虽然我们传输的段数是由拥塞控制算法决定的，但这些段的大小不是。
Therefore, using larger packets will enable TCP to send more data per segment which yields better channel utilization.
因此，使用较大的数据包将使TCP能够在每个段发送更多的数据，从而提高信道利用率。
TCP's default mechanism to detect dropped segments is a timeout [Pos81]. In other words, if the sender does not receive an ACK for a given packet within the expected amount of time the segment will be retransmitted. The retransmission timeout (RTO) is based on observations of the RTT. In addition to retransmitting a segment when the RTO expires, TCP also uses the lost segment as an indication of congestion in the network. In response to the congestion, the value of ssthresh is set to half of the cwnd and the value of cwnd is then reduced to 1 segment. This triggers the use of the slow start algorithm to increase cwnd until the value of cwnd reaches half of its value when congestion was detected. After the slow start phase, the congestion avoidance algorithm is used to probe the network for additional capacity.
TCP检测丢弃段的默认机制是超时[Pos81]。换句话说，如果发送方在预期的时间内没有收到给定分组的ACK，则该段将被重新传输。重传超时（RTO）基于对RTT的观察。除了在RTO过期时重新传输段外，TCP还使用丢失的段作为网络拥塞的指示。作为对拥塞的响应，ssthresh的值被设置为cwnd的一半，然后cwnd的值被减少到1段。这会触发使用慢启动算法增加cwnd，直到检测到拥塞时cwnd的值达到其值的一半。在慢启动阶段之后，使用拥塞避免算法来探测网络的额外容量。
TCP ACKs always acknowledge the highest in-order segment that has arrived. Therefore an ACK for segment X also effectively ACKs all segments < X. Furthermore, if a segment arrives out-of-order the ACK triggered will be for the highest in-order segment, rather than the segment that just arrived. For example, assume segment 11 has been dropped somewhere in the network and segment 12 arrives at the receiver. The receiver is going to send a duplicate ACK covering segment 10 (and all previous segments).
TCP确认始终确认已到达的最高顺序段。因此，段X的ACK也有效地确认所有<X的段。此外，如果一个段无序到达，则触发的ACK将是顺序最高的段，而不是刚刚到达的段。例如，假设段11已被丢弃在网络中的某个地方，并且段12到达接收器。接收机将发送一个覆盖段10（和所有先前段）的重复ACK。
The fast retransmit algorithm uses these duplicate ACKs to detect lost segments. If 3 duplicate ACKs arrive at the data originator, TCP assumes that a segment has been lost and retransmits the missing segment without waiting for the RTO to expire. After a segment is resent using fast retransmit, the fast recovery algorithm is used to adjust the congestion window. First, the value of ssthresh is set to half of the value of cwnd. Next, the value of cwnd is halved. Finally, the value of cwnd is artificially increased by 1 segment for each duplicate ACK that has arrived. The artificial inflation can be done because each duplicate ACK represents 1 segment that has left the network. When the cwnd permits, TCP is able to transmit new data. This allows TCP to keep data flowing through the network at half the rate it was when loss was detected. When an ACK for the retransmitted packet arrives, the value of cwnd is reduced back to ssthresh (half the value of cwnd when the congestion was detected).
快速重传算法使用这些重复的ack来检测丢失的段。如果3个重复的ACK到达数据发起者，TCP假定某个段已丢失，并在不等待RTO过期的情况下重新传输丢失的段。在使用快速重传重新传输段后，使用快速恢复算法调整拥塞窗口。首先，将ssthresh的值设置为cwnd值的一半。接下来，将cwnd的值减半。最后，对于已经到达的每个重复ACK，cwnd的值被人为地增加1段。可以进行人工充气，因为每个重复的ACK代表离开网络的一个段。当cwnd允许时，TCP能够传输新数据。这使得TCP能够使数据以检测到丢失时的一半速率通过网络。当重新传输的数据包的ACK到达时，cwnd的值减小回ssthresh（检测到拥塞时cwnd值的一半）。
Generally, fast retransmit can resend only one segment per window of data sent. When multiple segments are lost in a given window of data, one of the segments will be resent using fast retransmit and the rest of the dropped segments must usually wait for the RTO to expire, which causes TCP to revert to slow start.
通常，快速重传只能在每个发送的数据窗口中重新发送一段。当多个数据段在给定的数据窗口中丢失时，其中一个数据段将使用快速重传重新传输，而其余被丢弃的数据段通常必须等待RTO过期，这将导致TCP恢复为慢速启动。
TCP's response to congestion differs based on the way the congestion is detected. If the retransmission timer causes a packet to be resent, TCP drops ssthresh to half the current cwnd and reduces the value of cwnd to 1 segment (thus triggering slow start). However, 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 due to duplicate ACKs, TCP knows that packets are still flowing through the network and can therefore infer that the congestion is not that bad. However, when resending a packet due to the expiration of the retransmission timer, TCP cannot infer anything about the state of the network and therefore must proceed conservatively by sending new data using the slow start algorithm.
TCP对拥塞的响应因检测拥塞的方式而异。如果重传计时器导致重新发送数据包，TCP会将ssthresh降至当前cwnd的一半，并将cwnd的值降至1段（从而触发慢速启动）。但是，如果通过快速重传重新发送段，则ssthresh和cwnd都将设置为cwnd当前值的一半，并使用拥塞避免发送新数据。不同之处在于，当由于重复的ACK而重新传输时，TCP知道数据包仍在网络中流动，因此可以推断拥塞没有那么严重。但是，当由于重传计时器过期而重新发送数据包时，TCP无法推断任何有关网络状态的信息，因此必须通过使用慢启动算法发送新数据保守地进行。
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]. This can reduce the size of the congestion window multiple times in response to a single "loss event". The problem is particularly noticeable in connections that utilize large congestion windows, since these connections are able to 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].
请注意，如上所述的快速重传/快速恢复算法可能导致一种现象，即每个数据窗口允许多次快速重传[Flo94]。这可以多次减小拥塞窗口的大小，以响应单个“丢失事件”。这个问题在使用大拥塞窗口的连接中特别明显，因为这些连接能够在恢复期间向网络注入足够多的新段以触发多次快速重传。对于单个丢失事件多次减少cwnd可能会影响性能[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.
改进快速重传/快速恢复算法的最佳方法是使用基于选择性确认（SACK）的丢失恢复算法。如下所述，这些算法通常能够从多个丢失的段中快速恢复，而不会不必要地降低cwnd的值。在没有SACK的情况下，应使用快速重传和快速恢复算法。修复这些算法以在面临多个快速重传时获得更好的性能超出了本文档的范围。因此，建议TCP实施者实施RFC 2001[Ste97]或RFC 2001后续版本中概述的当前版本的快速重传/快速恢复。
The above algorithms have a negative impact on the performance of individual TCP connection's performance because the algorithms slowly probe the network for additional capacity, which in turn wastes bandwidth. This is especially true over long-delay satellite
上述算法对单个TCP连接的性能有负面影响，因为这些算法缓慢地探测网络以获得额外的容量，这反过来又浪费了带宽。在长延迟卫星上尤其如此
channels because of the large amount of time required for the sender to obtain feedback from the receiver [All97] [AHKO97]. However, the algorithms are necessary to prevent congestive collapse in a shared network [Jac88]. Therefore, the negative impact on a given connection is more than offset by the benefit to the entire network.
由于发送方需要大量时间才能从接收方获得反馈[All97][AHKO97]，因此需要使用多个通道。然而，这些算法对于防止共享网络中的拥塞崩溃是必要的[Jac88]。因此，对给定连接的负面影响被整个网络的好处所抵消。
The standard maximum TCP window size (65,535 bytes) is not adequate to allow a single TCP connection to utilize the entire bandwidth available on some satellite channels. TCP throughput is limited by the following formula [Pos81]:
标准最大TCP窗口大小（65535字节）不足以允许单个TCP连接利用某些卫星通道上的全部可用带宽。TCP吞吐量受以下公式[Pos81]的限制：
throughput = window size / RTT
throughput = window size / RTT
Therefore, 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:
因此，使用65535字节的最大窗口大小和560 ms[Kru95]的地球同步卫星信道RTT，最大吞吐量限制为：
throughput = 65,535 bytes / 560 ms = 117,027 bytes/second
throughput = 65,535 bytes / 560 ms = 117,027 bytes/second
Therefore, a single standard TCP connection cannot fully utilize, for example, T1 rate (approximately 192,000 bytes/second) GSO satellite channels. However, TCP has been extended to support larger windows [JBB92]. The window scaling options outlined in [JBB92] should be used in satellite environments, as well as the companion algorithms PAWS (Protection Against Wrapped Sequence space) and RTTM (Round-Trip Time Measurements).
因此，单个标准TCP连接无法充分利用T1速率（约192000字节/秒）GSO卫星信道。但是，TCP已经扩展到支持更大的窗口[JBB92]。[JBB92]中概述的窗口缩放选项应在卫星环境中使用，以及配套算法PAWS（包裹序列空间保护）和RTTM（往返时间测量）。
It should be noted 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 above example, can fully utilize a T1 GSO satellite channel.
应该注意的是，对于多个流之间共享的卫星链路，可能不需要大窗口。例如，如上例所示，两个长寿命TCP连接（每个连接使用65535字节的窗口）可以完全利用T1 GSO卫星信道。
Using large windows often requires both client and server applications or TCP stacks to be hand tuned (usually by an expert) to utilize large windows. Research into operating system mechanisms that are able to adjust the buffer capacity as dictated by the current network conditions is currently underway [SMM98]. This will allow stock TCP implementations and applications to better utilize the capacity provided by the underlying network.
使用大窗口通常需要手动调整客户端和服务器应用程序或TCP堆栈（通常由专家）以利用大窗口。目前正在研究能够根据当前网络条件调整缓冲区容量的操作系统机制[SMM98]。这将允许库存TCP实现和应用程序更好地利用底层网络提供的容量。
There are two standard methods that can be used by TCP receivers to generated acknowledgments. The method outlined in [Pos81] generates an ACK for each incoming segment. [Bra89] states that hosts SHOULD use "delayed acknowledgments". Using this algorithm, an ACK is
TCP接收器可以使用两种标准方法来生成确认。[Pos81]中概述的方法为每个传入段生成一个ACK。[Bra89]指出主机应使用“延迟确认”。使用此算法，可以生成一个ACK
generated for every second full-sized segment, or if a second full-size segment does not arrive within a given timeout (which must not exceed 500 ms). The congestion window is increased based on the number of incoming ACKs and delayed ACKs reduce the number of ACKs being sent by the receiver. Therefore, cwnd growth occurs much more slowly when using delayed ACKs compared to the case when the receiver ACKs each incoming segment [All98].
为每秒钟的全尺寸段生成，或者如果第二个全尺寸段未在给定的超时（不得超过500毫秒）内到达，则生成。拥塞窗口根据传入ack的数量增加，延迟ack减少了接收方发送的ack数量。因此，与接收器确认每个传入段的情况相比，使用延迟确认时，cwnd增长要慢得多[All98]。
A tempting "fix" to the problem caused by delayed ACKs is to simply 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 are not yet understood. Therefore, disabling delayed ACKs is still a research issue and thus, at this time TCP receivers should continue to generate delayed ACKs, per [Bra89].
对于延迟确认引起的问题，一个诱人的“修复”方法是简单地关闭该机制，让接收器确认每个传入段。但是，不建议这样做。首先，[Bra89]说TCP接收器应该生成延迟的ACK。其次，将共享网络中的ACK数量增加两倍可能会产生尚未理解的后果。因此，禁用延迟ACK仍然是一个研究问题，因此，根据[Bra89]，此时TCP接收器应继续生成延迟ACK。
Selective acknowledgments (SACKs) [MMFR96] allow TCP receivers to inform TCP senders exactly which packets have arrived. SACKs allow TCP to recover more quickly from lost segments, as well as avoiding needless retransmissions.
选择性确认（SACK）[MMFR96]允许TCP接收方准确地通知TCP发送方哪些数据包已经到达。SACK允许TCP更快地从丢失的数据段中恢复，并避免不必要的重新传输。
The fast retransmit algorithm can generally only repair one loss per window of data. When multiple losses occur, the sender generally must rely on a timeout to determine which segment needs to be retransmitted next. While waiting for a timeout, the data segments and their acknowledgments drain from the network. In the absence of incoming ACKs to clock new segments into the network, the sender must use the slow start algorithm to restart transmission. As discussed above, the slow start algorithm can be time consuming over satellite channels. When SACKs are employed, the sender is generally able to determine which segments need to be retransmitted in the first RTT following loss detection. This allows the sender to continue to transmit segments (retransmissions and new segments, if appropriate) at an appropriate rate and therefore sustain the ACK clock. This avoids a costly slow start period following multiple lost segments. Generally SACK is able to retransmit all dropped segments within the first RTT following the 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 is appropriate to transmit those segments. Both these algorithms follow the basic principles of congestion control outlined in [Jac88] and reduce the window by half when congestion is detected.
快速重传算法通常只能修复每个数据窗口的一次丢失。当发生多个丢失时，发送方通常必须依赖超时来确定下一个需要重新传输的段。等待超时时，数据段及其确认将从网络中排出。在没有传入的ACK将新的数据段时钟输入网络的情况下，发送方必须使用慢启动算法重新启动传输。如上所述，慢启动算法在卫星信道上可能非常耗时。当使用SACK时，发送方通常能够确定在检测到丢失后的第一个RTT中需要重新传输哪些段。这允许发送方以适当的速率继续传输段（重新传输和新段，如果合适），从而维持ACK时钟。这避免了在多个丢失段之后出现成本高昂的缓慢启动期。通常，SACK能够在丢失检测后的第一个RTT内重新传输所有丢弃的段。[MM96]和[FF96]讨论了特定的拥塞控制算法，这些算法依赖于SACK信息来确定哪些段需要重新传输，以及何时适合传输这些段。这两种算法都遵循[Jac88]中概述的拥塞控制基本原则，并在检测到拥塞时将窗口减少一半。
Table 1 summarizes the mechanisms that have been discussed in this document. Those mechanisms denoted "Recommended" are IETF standards track mechanisms that are recommended by the authors for use in networks containing satellite channels. Those mechanisms marked "Required' have been defined by the IETF as required for hosts using the shared Internet [Bra89]. Along with the section of this document containing the discussion of each mechanism, we note where the mechanism needs to be implemented. The codes listed in the last column are defined as follows: "S" for the data sender, "R" for the data receiver and "L" for the satellite link.
表1总结了本文件中讨论的机制。表示为“推荐”的机制是IETF标准跟踪机制，由作者推荐用于包含卫星信道的网络。IETF已将标记为“必需”的机制定义为使用共享互联网的主机所需的机制[Bra89]。在本文档中包含对每种机制的讨论的部分中，我们注意到需要在何处实现该机制。最后一列中列出的代码定义如下：“S”表示数据发送方，“R”数据接收器为“L”，卫星链路为“L”。
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
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 should check with their TCP vendors (implementors) to ensure the recommended mechanisms are supported in their stack in current and/or future versions. Alternatively, the Pittsburgh Supercomputer Center tracks TCP implementations and which extensions they support, as well as providing guidance on tuning various TCP implementations [PSC].
卫星用户应与其TCP供应商（实施者）进行检查，以确保在当前和/或未来版本的堆栈中支持推荐的机制。此外，匹兹堡超级计算机中心还跟踪TCP实现及其支持的扩展，并提供有关调整各种TCP实现[PSC]的指导。
Research into improving the efficiency of TCP over satellite channels is ongoing and will be summarized in a planned memo along with other considerations, such as satellite network architectures.
关于通过卫星信道提高TCP效率的研究正在进行中，并将在计划备忘录中与其他考虑因素（如卫星网络体系结构）一起进行总结。
The authors believe that the recommendations contained in this memo do not alter the security implications of TCP. However, when using a broadcast medium such as satellites links to transfer user data and/or network control traffic, one should be aware of the intrinsic security implications of such technology.
作者认为，本备忘录中的建议不会改变TCP的安全含义。然而，当使用诸如卫星链路之类的广播媒体来传输用户数据和/或网络控制流量时，人们应当意识到这种技术的内在安全含义。
Eavesdropping on network links is a form of passive attack that, if performed successfully, could reveal critical traffic control information that would jeopardize the proper functioning of the network. These attacks could reduce the ability of the network to provide data transmission services efficiently. Eavesdroppers could also compromise the privacy of user data, especially if end-to-end security mechanisms are not in use. While passive monitoring can occur on any network, the wireless broadcast nature of satellite links allows reception of signals without physical connection to the network which enables monitoring to be conducted without detection. However, 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 provide secure communication over satellite channels. However, this still leaves traffic vulnerable to eavesdropping on networks before and after traversing the satellite link. Therefore, end-to-end security mechanisms should be considered. This document does not make any recommendations as to which security mechanisms should be employed. However, those operating and using satellite networks should survey the currently available network security mechanisms and choose those that meet their security requirements.
物理层和/或链路层的数据加密可通过卫星信道提供安全通信。然而，这仍然使流量在穿越卫星链路之前和之后容易被网络窃听。因此，应考虑端到端安全机制。本文件未就应采用何种安全机制提出任何建议。但是，运营和使用卫星网络的人应调查目前可用的网络安全机制，并选择符合其安全要求的机制。
Acknowledgments
致谢
This document has benefited from comments from the members of the TCP Over Satellite Working Group. In particular, we would like 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.
本文件得益于TCP Over Satellite工作组成员的评论。特别是，我们要感谢亚伦·福克、马修·哈尔西、汉斯·克鲁斯、马特·马蒂斯、格雷格·纳卡尼希、弗恩·帕克森、杰夫·塞姆克、比尔·塞普梅尔和埃里克·特拉维斯对本文件的有益评论。
References
工具书类
[AFP98] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's Initial Window", RFC 2414, September 1998.
[AFP98]Allman，M.，Floyd，S.和C.Partridge，“增加TCP的初始窗口”，RFC 2414，1998年9月。
[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.
[AHKO97]马克·奥尔曼、克里斯·海斯、汉斯·克鲁斯和肖恩·奥斯特曼。卫星链路上的TCP性能。1997年3月第五届国际电信系统会议记录。
[All97] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
马克·奥尔曼。提高卫星信道上的TCP性能。俄亥俄大学硕士论文，1997年6月。
[All98] Mark Allman. On the Generation and Use of TCP Acknowledgments. ACM Computer Communication Review, 28(5), October 1998.
马克·奥尔曼。关于TCP确认的生成和使用。ACM计算机通信评论，28（5），1998年10月。
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89]Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996.
[FF96]凯文·法尔和萨莉·弗洛伊德。基于模拟的Tahoe、Reno和SACK TCP比较。《计算机通信评论》，1996年7月。
[FF98] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet. Submitted to IEEE Transactions on Networking.
萨莉·弗洛伊德，凯文·法尔。促进互联网端到端拥塞控制的使用。提交给IEEE网络事务。
[Flo94] S. Floyd, TCP and Successive Fast Retransmits. Technical report, October 1994. ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[Flo94]S.Floyd、TCP和连续快速重传。技术报告，1994年10月。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.
[GJKFV98]Rohit Goyal，Raj Jain，Shiv Kalyanaraman，Sonia Fahmy，Bobby Vandalore，通过ATM-UBR服务改进TCP的性能，1998年。萨姆比特开始使用计算机通信。
[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical Report, LBL, April 1990.
范雅各布森。改进的TCP拥塞避免算法。技术报告，LBL，1990年4月。
[JBB92] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[JBB92]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[Jac88] Van Jacobson. Congestion Avoidance and Control. In ACM SIGCOMM, 1988.
范雅各布森。拥塞避免和控制。在ACM SIGCOMM中，1988年。
[Kno93] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[Kno93]Knowles，S.，“从Path MTU发现的经验中得出的IESG建议”，RFC 1435，1993年3月。
[Mar78] James Martin. Communications Satellite Systems. Prentice Hall, 1978.
詹姆斯·马丁。通信卫星系统。普伦蒂斯大厅，1978年。
[MD90] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[MD90]Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[MM96] Matt Mathis and Jamshid Mahdavi. Forward Acknowledgment: Refining TCP Congestion Control. In ACM SIGCOMM, 1996.
Matt Mathis和Jamshid Mahdavi。转发确认：优化TCP拥塞控制。在ACM SIGCOMM，1996年。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[MMFR96]Mathis，M.，Mahdavi，J.，Floyd，S.和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[Mon98] M. J. Montpetit. TELEDESIC: Enabling The Global Community Interaccess. In Proc. of the International Wireless Symposium, May 1998.
[星期一]M.J.蒙佩蒂。TELEDESIC：使全球社区能够相互访问。在过程中。国际无线研讨会，1998年5月。
[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.
[MSMO97]M.Mathis，J.Semke，J.Mahdavi，T.Ott，“TCP拥塞避免算法的宏观行为”，《计算机通信评论》，第27卷，第3期，1997年7月。可从http://www.psc.edu/networking/papers/papers.html.
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Pos81]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[PS97] Craig Partridge and Tim Shepard. TCP Performance Over Satellite Links. IEEE Network, 11(5), September/October 1997.
克雷格·帕特里奇和蒂姆·谢泼德。卫星链路上的TCP性能。IEEE网络，11（5），1997年9月/10月。
[PSC] Jamshid Mahdavi. Enabling High Performance Data Transfers on Hosts. http://www.psc.edu/networking/perf_tune.html.
贾姆希德·马赫达维。在主机上实现高性能数据传输。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.
[SMM98]杰夫·塞姆克、贾姆希德·马赫达维和马特·马蒂斯。自动TCP缓冲区调整。在ACM SIGCOMM，1998年8月。出现。
[Sta94] William Stallings. Data and Computer Communications. MacMillian, 4th edition, 1994.
[Sta94]威廉·斯泰林斯。数据和计算机通信。麦克米利安，第四版，1994年。
[Ste97] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms", RFC 2001,January 1997.
[Ste97]Stevens，W.“TCP慢启动、拥塞避免、快速重传和快速恢复算法”，RFC 2001，1997年1月。
[Stu95] M. A. Sturza. Architecture of the TELEDESIC Satellite System. In Proceedings of the International Mobile Satellite Conference, 1995.
[Stu95]M.A.斯图扎。TELEDESIC卫星系统的结构。《国际移动卫星会议记录》，1995年。
Authors' Addresses
作者地址
Mark Allman NASA Lewis Research Center/Sterling Software 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
美国宇航局刘易斯研究中心/斯特林软件公司俄亥俄州克利夫兰布鲁克帕克路21000号，邮编：44135
Phone: +1 216 433 6586
EMail: mallman@lerc.nasa.gov
http://roland.lerc.nasa.gov/~mallman
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
俄亥俄州克利夫兰布鲁克公园路21000号丹尼尔·R·格洛弗美国宇航局刘易斯研究中心，邮编：44135
Phone: +1 216 433 2847
EMail: Daniel.R.Glover@lerc.nasa.gov
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
美国马萨诸塞州剑桥莫尔顿街10号Luis A.Sanchez BBN Technologies GTE互联网
Phone: +1 617 873 3351
EMail: lsanchez@ir.bbn.com
Phone: +1 617 873 3351
EMail: lsanchez@ir.bbn.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。