Network Working Group M. Allman, Editor
Request for Comments: 2760 NASA Glenn Research Center/BBN Technologies
Category: Informational S. Dawkins
Nortel
D. Glover
J. Griner
D. Tran
NASA Glenn Research Center
T. Henderson
University of California at Berkeley
J. Heidemann
J. Touch
University of Southern California/ISI
H. Kruse
S. Ostermann
Ohio University
K. Scott
The MITRE Corporation
J. Semke
Pittsburgh Supercomputing Center
February 2000
Network Working Group M. Allman, Editor
Request for Comments: 2760 NASA Glenn Research Center/BBN Technologies
Category: Informational S. Dawkins
Nortel
D. Glover
J. Griner
D. Tran
NASA Glenn Research Center
T. Henderson
University of California at Berkeley
J. Heidemann
J. Touch
University of Southern California/ISI
H. Kruse
S. Ostermann
Ohio University
K. Scott
The MITRE Corporation
J. Semke
Pittsburgh Supercomputing Center
February 2000
Ongoing TCP Research Related to Satellites
正在进行的与卫星有关的TCP研究
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
This document outlines possible TCP enhancements that may allow TCP to better utilize the available bandwidth provided by networks containing satellite links. The algorithms and mechanisms outlined have not been judged to be mature enough to be recommended by the IETF. The goal of this document is to educate researchers as to the current work and progress being done in TCP research related to satellite networks.
本文档概述了可能的TCP增强功能，使TCP能够更好地利用包含卫星链路的网络提供的可用带宽。所概述的算法和机制尚未被判断为足够成熟，无法被IETF推荐。本文件的目的是向研究人员介绍与卫星网络相关的TCP研究的当前工作和进展。
Table of Contents
目录
1 Introduction. . . . . . . . . . . . . . . . . . . . 2
2 Satellite Architectures . . . . . . . . . . . . . . 3
2.1 Asymmetric Satellite Networks . . . . . . . . . . . 3
2.2 Satellite Link as Last Hop. . . . . . . . . . . . . 3
2.3 Hybrid Satellite Networks . . . . . . . . . . . 4
2.4 Point-to-Point Satellite Networks . . . . . . . . . 4
2.5 Multiple Satellite Hops . . . . . . . . . . . . . . 4
3 Mitigations . . . . . . . . . . . . . . . . . . . . 4
3.1 TCP For Transactions. . . . . . . . . . . . . . . . 4
3.2 Slow Start. . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Larger Initial Window . . . . . . . . . . . . . . . 6
3.2.2 Byte Counting . . . . . . . . . . . . . . . . . . . 7
3.2.3 Delayed ACKs After Slow Start . . . . . . . . . . . 9
3.2.4 Terminating Slow Start. . . . . . . . . . . . . . . 11
3.3 Loss Recovery . . . . . . . . . . . . . . . . . . . 12
3.3.1 Non-SACK Based Mechanisms . . . . . . . . . . . . . 12
3.3.2 SACK Based Mechanisms . . . . . . . . . . . . . . . 13
3.3.3 Explicit Congestion Notification. . . . . . . . . . 16
3.3.4 Detecting Corruption Loss . . . . . . . . . . . . . 18
3.4 Congestion Avoidance. . . . . . . . . . . . . . . . 21
3.5 Multiple Data Connections . . . . . . . . . . . . . 22
3.6 Pacing TCP Segments . . . . . . . . . . . . . . . . 24
3.7 TCP Header Compression. . . . . . . . . . . . . . . 26
3.8 Sharing TCP State Among Similar Connections . . . . 29
3.9 ACK Congestion Control. . . . . . . . . . . . . . . 32
3.10 ACK Filtering . . . . . . . . . . . . . . . . . . . 34
4 Conclusions . . . . . . . . . . . . . . . . . . . . 36
5 Security Considerations . . . . . . . . . . . . . . 36
6 Acknowledgments . . . . . . . . . . . . . . . . . . 37
7 References. . . . . . . . . . . . . . . . . . . . . 37
8 Authors' Addresses. . . . . . . . . . . . . . . . . 43
9 Full Copyright Statement. . . . . . . . . . . . . . 46
1 Introduction. . . . . . . . . . . . . . . . . . . . 2
2 Satellite Architectures . . . . . . . . . . . . . . 3
2.1 Asymmetric Satellite Networks . . . . . . . . . . . 3
2.2 Satellite Link as Last Hop. . . . . . . . . . . . . 3
2.3 Hybrid Satellite Networks . . . . . . . . . . . 4
2.4 Point-to-Point Satellite Networks . . . . . . . . . 4
2.5 Multiple Satellite Hops . . . . . . . . . . . . . . 4
3 Mitigations . . . . . . . . . . . . . . . . . . . . 4
3.1 TCP For Transactions. . . . . . . . . . . . . . . . 4
3.2 Slow Start. . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Larger Initial Window . . . . . . . . . . . . . . . 6
3.2.2 Byte Counting . . . . . . . . . . . . . . . . . . . 7
3.2.3 Delayed ACKs After Slow Start . . . . . . . . . . . 9
3.2.4 Terminating Slow Start. . . . . . . . . . . . . . . 11
3.3 Loss Recovery . . . . . . . . . . . . . . . . . . . 12
3.3.1 Non-SACK Based Mechanisms . . . . . . . . . . . . . 12
3.3.2 SACK Based Mechanisms . . . . . . . . . . . . . . . 13
3.3.3 Explicit Congestion Notification. . . . . . . . . . 16
3.3.4 Detecting Corruption Loss . . . . . . . . . . . . . 18
3.4 Congestion Avoidance. . . . . . . . . . . . . . . . 21
3.5 Multiple Data Connections . . . . . . . . . . . . . 22
3.6 Pacing TCP Segments . . . . . . . . . . . . . . . . 24
3.7 TCP Header Compression. . . . . . . . . . . . . . . 26
3.8 Sharing TCP State Among Similar Connections . . . . 29
3.9 ACK Congestion Control. . . . . . . . . . . . . . . 32
3.10 ACK Filtering . . . . . . . . . . . . . . . . . . . 34
4 Conclusions . . . . . . . . . . . . . . . . . . . . 36
5 Security Considerations . . . . . . . . . . . . . . 36
6 Acknowledgments . . . . . . . . . . . . . . . . . . 37
7 References. . . . . . . . . . . . . . . . . . . . . 37
8 Authors' Addresses. . . . . . . . . . . . . . . . . 43
9 Full Copyright Statement. . . . . . . . . . . . . . 46
1 Introduction
1导言
This document outlines mechanisms that may help the Transmission Control Protocol (TCP) [Pos81] better utilize the bandwidth provided by long-delay satellite environments. These mechanisms may also help in other environments or for other protocols. The proposals outlined in this document are currently being studied throughout the research community. Therefore, these mechanisms are not mature enough to be recommended for wide-spread use by the IETF. However, some of these mechanisms may be safely used today. It is hoped that this document will stimulate further study into the described mechanisms. If, at
本文件概述了可帮助传输控制协议（TCP）[Pos81]更好地利用长延迟卫星环境提供的带宽的机制。这些机制在其他环境或其他协议中也有帮助。本文件中概述的建议目前正在整个研究界进行研究。因此，这些机制还不够成熟，建议IETF广泛使用。然而，其中一些机制今天可以安全使用。希望本文件将促进对所述机制的进一步研究。如果，在
some point, the mechanisms discussed in this memo prove to be safe and appropriate to be recommended for general use, the appropriate IETF documents will be written.
在某一点上，本备忘录中讨论的机制被证明是安全的，适合推荐用于一般用途，将编写适当的IETF文件。
It should be noted that non-TCP mechanisms that help performance over satellite links do exist (e.g., application-level changes, queueing disciplines, etc.). However, outlining these non-TCP mitigations is beyond the scope of this document and therefore is left as future work. Additionally, there are a number of mitigations to TCP's performance problems that involve very active intervention by gateways along the end-to-end path from the sender to the receiver. Documenting the pros and cons of such solutions is also left as future work.
应该注意的是，确实存在有助于卫星链路性能的非TCP机制（例如，应用程序级更改、排队规则等）。但是，概述这些非TCP缓解措施超出了本文档的范围，因此将留作将来的工作。此外，还有许多缓解TCP性能问题的措施，这些措施涉及网关沿从发送方到接收方的端到端路径进行非常积极的干预。记录这些解决方案的利弊也是未来的工作。
2 Satellite Architectures
2卫星体系结构
Specific characteristics of satellite links and the impact these characteristics have on TCP are presented in RFC 2488 [AGS99]. This section discusses several possible topologies where satellite links may be integrated into the global Internet. The mitigation outlined in section 3 will include a discussion of which environment the mechanism is expected to benefit.
RFC 2488[AGS99]中介绍了卫星链路的具体特征以及这些特征对TCP的影响。本节讨论了几种可能的拓扑结构，其中卫星链路可以集成到全球互联网中。第3节中概述的缓解措施将包括对该机制预期受益的环境的讨论。
Some satellite networks exhibit a bandwidth asymmetry, a larger data rate in one direction than the reverse direction, because of limits on the transmission power and the antenna size at one end of the link. Meanwhile, some other satellite systems are unidirectional and use a non-satellite return path (such as a dialup modem link). The nature of most TCP traffic is asymmetric with data flowing in one direction and acknowledgments in opposite direction. However, the term asymmetric in this document refers to different physical capacities in the forward and return links. Asymmetry has been shown to be a problem for TCP [BPK97,BPK98].
由于链路一端的传输功率和天线尺寸受到限制，一些卫星网络表现出带宽不对称，一个方向的数据速率大于反向。同时，其他一些卫星系统是单向的，并且使用非卫星返回路径（例如拨号调制解调器链路）。大多数TCP流量的性质是不对称的，数据在一个方向上流动，而确认在相反的方向上流动。然而，本文件中的术语不对称指的是转发和返回链路中的不同物理容量。不对称性已被证明是TCP的一个问题[BPK97，BPK98]。
Satellite links that provide service directly to end users, as opposed to satellite links located in the middle of a network, may allow for specialized design of protocols used over the last hop. Some satellite providers use the satellite link as a shared high speed downlink to users with a lower speed, non-shared terrestrial link that is used as a return link for requests and acknowledgments. Many times this creates an asymmetric network, as discussed above.
直接向终端用户提供服务的卫星链路，而不是位于网络中间的卫星链路，可以允许对最后一跳使用的协议进行专门设计。一些卫星提供商使用卫星链路作为共享高速下行链路，向具有低速、非共享地面链路的用户发送，该链路用作请求和确认的返回链路。很多时候，这会创建一个不对称的网络，如上所述。
In the more general case, satellite links may be located at any point in the network topology. In this case, the satellite link acts as just another link between two gateways. In this environment, a given connection may be sent over terrestrial links (including terrestrial wireless), as well as satellite links. On the other hand, a connection could also travel over only the terrestrial network or only over the satellite portion of the network.
在更一般的情况下，卫星链路可以位于网络拓扑中的任何点。在这种情况下，卫星链路充当两个网关之间的另一条链路。在这种环境中，可以通过地面链路（包括地面无线）以及卫星链路发送给定的连接。另一方面，连接也可以仅通过地面网络或仅通过网络的卫星部分传输。
In point-to-point satellite networks, the only hop in the network is over the satellite link. This pure satellite environment exhibits only the problems associated with the satellite links, as outlined in [AGS99]. Since this is a private network, some mitigations that are not appropriate for shared networks can be considered.
在点对点卫星网络中，网络中的唯一跃点是通过卫星链路。如[AGS99]中所述，这种纯卫星环境仅表现出与卫星链路相关的问题。由于这是一个专用网络，因此可以考虑一些不适用于共享网络的缓解措施。
In some situations, network traffic may traverse multiple satellite hops between the source and the destination. Such an environment aggravates the satellite characteristics described in [AGS99].
在某些情况下，网络流量可能会穿越源和目标之间的多个卫星跃点。这种环境加剧了[AGS99]中所述的卫星特性。
3 Mitigations
3缓解措施
The following sections will discuss various techniques for mitigating the problems TCP faces in the satellite environment. Each of the following sections will be organized as follows: First, each mitigation will be briefly outlined. Next, research work involving the mechanism in question will be briefly discussed. Next the implementation issues of the mechanism will be presented (including whether or not the particular mechanism presents any dangers to shared networks). Then a discussion of the mechanism's potential with regard to the topologies outlined above is given. Finally, the relationships and possible interactions with other TCP mechanisms are outlined. The reader is expected to be familiar with the TCP terminology used in [AGS99].
以下各节将讨论缓解TCP在卫星环境中面临的问题的各种技术。以下各节将按如下方式组织：首先，将简要概述各缓解措施。接下来，将简要讨论涉及该机制的研究工作。接下来将介绍该机制的实现问题（包括特定机制是否会对共享网络造成任何危险）。然后讨论了该机制在上述拓扑结构方面的潜力。最后，概述了与其他TCP机制的关系和可能的交互。读者应熟悉[AGS99]中使用的TCP术语。
TCP uses a three-way handshake to setup a connection between two hosts [Pos81]. This connection setup requires 1-1.5 round-trip times (RTTs), depending upon whether the data sender started the connection actively or passively. This startup time can be eliminated by using TCP extensions for transactions (T/TCP) [Bra94]. After the first
TCP使用三方握手在两台主机之间建立连接[Pos81]。此连接设置需要1-1.5个往返时间（RTT），具体取决于数据发送方是主动还是被动启动连接。通过使用TCP事务扩展（T/TCP）[Bra94]可以消除此启动时间。第一次之后
connection between a pair of hosts is established, T/TCP is able to bypass the three-way handshake, allowing the data sender to begin transmitting data in the first segment sent (along with the SYN). This is especially helpful for short request/response traffic, as it saves a potentially long setup phase when no useful data is being transmitted.
在一对主机之间建立连接后，T/TCP能够绕过三方握手，允许数据发送方开始传输发送的第一段数据（连同SYN）。这对于短请求/响应流量特别有用，因为当没有传输有用数据时，它可以节省可能很长的设置阶段。
T/TCP is outlined and analyzed in [Bra92,Bra94].
[Bra92，Bra94]对T/TCP进行了概述和分析。
T/TCP requires changes in the TCP stacks of both the data sender and the data receiver. While T/TCP is safe to implement in shared networks from a congestion control perspective, several security implications of sending data in the first data segment have been identified [ddKI99].
T/TCP要求更改数据发送方和数据接收方的TCP堆栈。虽然从拥塞控制的角度来看，T/TCP在共享网络中实现是安全的，但在第一个数据段中发送数据的几个安全含义已经确定[ddKI99]。
It is expected that T/TCP will be equally beneficial in all environments outlined in section 2.
预计T/TCP在第2节所述的所有环境中都同样有益。
T/TCP allows data transfer to start more rapidly, much like using a larger initial congestion window (see section 3.2.1), delayed ACKs after slow start (section 3.2.3) or byte counting (section 3.2.2).
T/TCP允许数据传输更快地开始，就像使用更大的初始拥塞窗口（见第3.2.1节）、缓慢启动后的延迟确认（第3.2.3节）或字节计数（第3.2.2节）一样。
The slow start algorithm is used to gradually increase the size of TCP's congestion window (cwnd) [Jac88,Ste97,APS99]. The algorithm is an important safe-guard against transmitting an inappropriate amount of data into the network when the connection starts up. However, slow start can also waste available network capacity, especially in long-delay networks [All97a,Hay97]. Slow start is particularly inefficient for transfers that are short compared to the delay*bandwidth product of the network (e.g., WWW transfers).
慢启动算法用于逐渐增加TCP拥塞窗口（cwnd）的大小[Jac88，Ste97，APS99]。该算法是一种重要的安全防护措施，可防止在连接启动时向网络传输不适当数量的数据。然而，慢启动也会浪费可用的网络容量，特别是在长延迟网络中[All97a，Hay97]。与网络的延迟*带宽乘积（例如，WWW传输）相比，对于较短的传输而言，慢启动效率特别低。
Delayed ACKs are another source of wasted capacity during the slow start phase. RFC 1122 [Bra89] suggests data receivers refrain from ACKing every incoming data segment. However, every second full-sized segment should be ACKed. If a second full-sized segment does not arrive within a given timeout, an ACK must be generated (this timeout cannot exceed 500 ms). Since the data sender increases the size of cwnd based on the number of arriving ACKs, reducing the number of
延迟的ACK是缓慢启动阶段浪费容量的另一个来源。RFC1122[Bra89]建议数据接收器避免确认每个传入数据段。但是，每秒钟都应确认一次全尺寸段。如果第二个全尺寸段未在给定超时内到达，则必须生成ACK（此超时不能超过500毫秒）。因为数据发送方根据到达的ack数量增加了cwnd的大小，从而减少了
ACKs slows the cwnd growth rate. In addition, when TCP starts sending, it sends 1 segment. When using delayed ACKs a second segment must arrive before an ACK is sent. Therefore, the receiver is always forced to wait for the delayed ACK timer to expire before ACKing the first segment, which also increases the transfer time.
ACKs会减慢cwnd的增长速度。此外，当TCP开始发送时，它会发送1段。当使用延迟确认时，第二段必须在发送确认之前到达。因此，在确认第一段之前，接收器总是被迫等待延迟的确认计时器过期，这也增加了传输时间。
Several proposals have suggested ways to make slow start less time consuming. These proposals are briefly outlined below and references to the research work given.
有几项建议提出了使慢启动减少时间消耗的方法。下文简要概述了这些建议，并给出了对研究工作的参考。
One method that will reduce the amount of time required by slow start (and therefore, the amount of wasted capacity) is to increase the initial value of cwnd. An experimental TCP extension outlined in [AFP98] allows the initial size of cwnd to be increased from 1 segment to that given in equation (1).
一种减少慢启动所需时间（从而减少浪费容量）的方法是增加cwnd的初始值。[AFP98]中概述的实验TCP扩展允许cwnd的初始大小从1段增加到等式（1）中给出的长度。
min (4*MSS, max (2*MSS, 4380 bytes)) (1)
最小值（4*MSS，最大值（2*MSS，4380字节））（1）
By increasing the initial value of cwnd, more packets are sent during the first RTT of data transmission, which will trigger more ACKs, allowing the congestion window to open more rapidly. In addition, by sending at least 2 segments initially, the first segment does not need to wait for the delayed ACK timer to expire as is the case when the initial size of cwnd is 1 segment (as discussed above). Therefore, the value of cwnd given in equation 1 saves up to 3 RTTs and a delayed ACK timeout when compared to an initial cwnd of 1 segment.
通过增加cwnd的初始值，在数据传输的第一个RTT期间发送更多的数据包，这将触发更多的ACK，从而允许更快速地打开拥塞窗口。此外，通过最初发送至少2个段，第一段不需要像cwnd的初始大小为1段时那样等待延迟ACK定时器到期（如上所述）。因此，与1段的初始cwnd相比，等式1中给出的cwnd值最多可节省3个RTT和延迟的ACK超时。
Also, we note that RFC 2581 [APS99], a standards-track document, allows a TCP to use an initial cwnd of up to 2 segments. This change is highly recommended for satellite networks.
此外，我们注意到RFC2581[APS99]，一个标准跟踪文档，允许TCP使用最多2段的初始cwnd。强烈建议对卫星网络进行此更改。
Several researchers have studied the use of a larger initial window in various environments. [Nic97] and [KAGT98] show a reduction in WWW page transfer time over hybrid fiber coax (HFC) and satellite links respectively. Furthermore, it has been shown that using an initial cwnd of 4 segments does not negatively impact overall performance over dialup modem links with a small number of buffers [SP98]. [AHO98] shows an improvement in transfer time for 16 KB files across the Internet and dialup modem links when using a larger initial value for cwnd. However, a slight increase in dropped
一些研究人员研究了在各种环境中使用较大的初始窗口。[Nic97]和[KAGT98]分别显示混合光纤同轴电缆（HFC）和卫星链路上的WWW页面传输时间缩短。此外，已经证明，使用4段的初始cwnd不会对具有少量缓冲区的拨号调制解调器链路的总体性能产生负面影响[SP98]。[AHO98]显示，当使用较大的cwnd初始值时，通过Internet和拨号调制解调器链路传输16 KB文件的传输时间有所缩短。然而，这一数字略有上升
segments was also shown. Finally, [PN98] shows improved transfer time for WWW traffic in simulations with competing traffic, in addition to a small increase in the drop rate.
还显示了片段。最后，[PN98]在模拟竞争流量时显示WWW流量的传输时间有所改善，此外丢弃率略有增加。
The use of a larger initial cwnd value requires changes to the sender's TCP stack. Using an initial congestion window of 2 segments is allowed by RFC 2581 [APS99]. Using an initial congestion window of 3 or 4 segments is not expected to present any danger of congestion collapse [AFP98], however may degrade performance in some networks.
使用较大的初始cwnd值需要更改发送方的TCP堆栈。RFC 2581[APS99]允许使用2段的初始拥塞窗口。使用3段或4段的初始拥塞窗口预计不会出现任何拥塞崩溃的危险[AFP98]，但是可能会降低某些网络的性能。
It is expected that the use of a large initial window would be equally beneficial to all network architectures outlined in section 2.
预计使用较大的初始窗口将对第2节中概述的所有网络架构同样有益。
Using a fixed larger initial congestion window decreases the impact of a long RTT on transfer time (especially for short transfers) at the cost of bursting data into a network with unknown conditions. A mechanism that mitigates bursts may make the use of a larger initial congestion window more appropriate (e.g., limiting the size of line-rate bursts [FF96] or pacing the segments in a burst [VH97a]).
使用固定的较大初始拥塞窗口可以减少长RTT对传输时间（尤其是短传输）的影响，但代价是将数据突发到未知条件下的网络中。缓解突发的机制可使使用更大的初始拥塞窗口更合适（例如，限制线速率突发的大小[FF96]或在突发中调整段的速度[VH97a]）。
Also, using delayed ACKs only after slow start (as outlined in section 3.2.3) offers an alternative way to immediately ACK the first segment of a transfer and open the congestion window more rapidly. Finally, using some form of TCP state sharing among a number of connections (as discussed in 3.8) may provide an alternative to using a fixed larger initial window.
此外，仅在慢速启动后使用延迟确认（如第3.2.3节所述）提供了一种替代方法，可以立即确认传输的第一段并更快地打开拥塞窗口。最后，在多个连接之间使用某种形式的TCP状态共享（如3.8中所述）可以提供一种替代方法，以代替使用固定的较大初始窗口。
As discussed above, the wide-spread use of delayed ACKs increases the time needed by a TCP sender to increase the size of the congestion window during slow start. This is especially harmful to flows traversing long-delay GEO satellite links. One mechanism that has been suggested to mitigate the problems caused by delayed ACKs is the use of "byte counting", rather than standard ACK counting [All97a,All98]. Using standard ACK counting, the congestion window is increased by 1 segment for each ACK received during slow start. However, using byte counting the congestion window increase is based
如上所述，延迟ack的广泛使用增加了TCP发送方在慢启动期间增加拥塞窗口大小所需的时间。这对穿越长延迟GEO卫星链路的流尤其有害。一种缓解延迟确认引起的问题的机制是使用“字节计数”，而不是标准确认计数[All97a，All98]。使用标准的ACK计数，在慢启动期间，对于接收到的每个ACK，拥塞窗口增加1段。然而，使用字节计数，拥塞窗口的增加是基于
on the number of previously unacknowledged bytes covered by each incoming ACK, rather than on the number of ACKs received. This makes the increase relative to the amount of data transmitted, rather than being dependent on the ACK interval used by the receiver.
取决于每个传入ACK覆盖的以前未确认的字节数，而不是接收到的确认数。这使得相对于发送的数据量增加，而不是取决于接收机使用的ACK间隔。
Two forms of byte counting are studied in [All98]. The first is unlimited byte counting (UBC). This mechanism simply uses the number of previously unacknowledged bytes to increase the congestion window each time an ACK arrives. The second form is limited byte counting (LBC). LBC limits the amount of cwnd increase to 2 segments. This limit throttles the size of the burst of data sent in response to a "stretch ACK" [Pax97]. Stretch ACKs are acknowledgments that cover more than 2 segments of previously unacknowledged data. Stretch ACKs can occur by design [Joh95] (although this is not standard), due to implementation bugs [All97b,PADHV99] or due to ACK loss. [All98] shows that LBC prevents large line-rate bursts when compared to UBC, and therefore offers fewer dropped segments and better performance. In addition, UBC causes large bursts during slow start based loss recovery due to the large cumulative ACKs that can arrive during loss recovery. The behavior of UBC during loss recovery can cause large decreases in performance and [All98] strongly recommends UBC not be deployed without further study into mitigating the large bursts.
[All98]研究了两种形式的字节计数。第一种是无限字节计数（UBC）。此机制仅使用以前未确认的字节数来增加每次ACK到达时的拥塞窗口。第二种形式是有限字节计数（LBC）。LBC将cwnd增加量限制为2段。此限制限制了响应“拉伸确认”发送的数据突发的大小[Pax97]。拉伸确认是覆盖2段以上以前未确认数据的确认。由于实现错误[All97b，PADHV99]或由于ACK丢失，设计[Joh95]（尽管这不是标准）可能会发生拉伸ACK。[All98]表明，与UBC相比，LBC可以防止较大的线速率突发，因此可以提供更少的丢弃段和更好的性能。此外，由于在丢失恢复期间可能会出现大量累积ACK，因此在基于慢速启动的丢失恢复期间，UBC会导致大量突发。在丢失恢复期间，UBC的行为可能会导致性能大幅下降，[All98]强烈建议在未进一步研究缓解大突发的情况下，不要部署UBC。
Note: The standards track RFC 2581 [APS99] allows a TCP to use byte counting to increase cwnd during congestion avoidance, however not during slow start.
注：标准轨道RFC 2581[APS99]允许TCP在避免拥塞期间使用字节计数来增加cwnd，但在慢速启动期间不允许。
Using byte counting, as opposed to standard ACK counting, has been shown to reduce the amount of time needed to increase the value of cwnd to an appropriate size in satellite networks [All97a]. In addition, [All98] presents a simulation comparison of byte counting and the standard cwnd increase algorithm in uncongested networks and networks with competing traffic. This study found that the limited form of byte counting outlined above can improve performance, while also increasing the drop rate slightly.
与标准ACK计数相比，使用字节计数可以减少卫星网络中将cwnd值增加到适当大小所需的时间[All97a]。此外，[All98]还对未阻塞网络和具有竞争流量的网络中的字节计数和标准cwnd增加算法进行了模拟比较。这项研究发现，上面概述的有限形式的字节计数可以提高性能，同时也略微增加了丢弃率。
[BPK97,BPK98] also investigated unlimited byte counting in conjunction with various ACK filtering algorithms (discussed in section 3.10) in asymmetric networks.
[BPK97，BPK98]还研究了非对称网络中的无限字节计数以及各种ACK过滤算法（在第3.10节中讨论）。
Changing from ACK counting to byte counting requires changes to the data sender's TCP stack. Byte counting violates the algorithm for increasing the congestion window outlined in RFC 2581 [APS99] (by making congestion window growth more aggressive during slow start) and therefore should not be used in shared networks.
从ACK计数更改为字节计数需要更改数据发送方的TCP堆栈。字节计数违反了RFC 2581[APS99]中概述的增加拥塞窗口的算法（通过在慢启动期间使拥塞窗口增长更剧烈），因此不应在共享网络中使用。
It has been suggested by some (and roundly criticized by others) that byte counting will allow TCP to provide uniform cwnd increase, regardless of the ACKing behavior of the receiver. In addition, byte counting also mitigates the retarded window growth provided by receivers that generate stretch ACKs because of the capacity of the return link, as discussed in [BPK97,BPK98]. Therefore, this change is expected to be especially beneficial to asymmetric networks.
有人建议（也有人严厉批评）字节计数将允许TCP提供统一的cwnd增加，而不管接收器的应答行为如何。此外，字节计数还减轻了由于返回链路的容量而产生拉伸ack的接收器所提供的延迟窗口增长，如[BPK97，BPK98]中所述。因此，这种变化预计对不对称网络特别有利。
Unlimited byte counting should not be used without a method to mitigate the potentially large line-rate bursts the algorithm can cause. Also, LBC may send bursts that are too large for the given network conditions. In this case, LBC may also benefit from some algorithm that would lessen the impact of line-rate bursts of segments. Also note that using delayed ACKs only after slow start (as outlined in section 3.2.3) negates the limited byte counting algorithm because each ACK covers only one segment during slow start. Therefore, both ACK counting and byte counting yield the same increase in the congestion window at this point (in the first RTT).
如果没有一种方法来缓解算法可能导致的潜在大行速率突发，则不应使用无限字节计数。此外，LBC可能会发送对于给定网络条件而言过大的突发。在这种情况下，LBC还可能受益于一些算法，这些算法将减少段的线速率突发的影响。还请注意，仅在慢启动后使用延迟ACK（如第3.2.3节所述）会否定有限字节计数算法，因为在慢启动期间，每个ACK仅覆盖一个段。因此，ACK计数和字节计数在此时（在第一个RTT中）产生相同的拥塞窗口增加。
As discussed above, TCP senders use the number of incoming ACKs to increase the congestion window during slow start. And, since delayed ACKs reduce the number of ACKs returned by the receiver by roughly half, the rate of growth of the congestion window is reduced. One proposed solution to this problem is to use delayed ACKs only after the slow start (DAASS) phase. This provides more ACKs while TCP is aggressively increasing the congestion window and less ACKs while TCP is in steady state, which conserves network resources.
如上所述，TCP发送方使用传入ACK的数量来增加慢启动期间的拥塞窗口。而且，由于延迟的ack将接收器返回的ack数量减少了大约一半，因此拥塞窗口的增长率也降低了。对此问题提出的一个解决方案是仅在慢速启动（DAASS）阶段之后使用延迟ACK。这在TCP积极增加拥塞窗口时提供更多的ACK，在TCP处于稳定状态时提供更少的ACK，从而节省网络资源。
[All98] shows that in simulation, using delayed ACKs after slow start (DAASS) improves transfer time when compared to a receiver that always generates delayed ACKs. However, DAASS also slightly increases the loss rate due to the increased rate of cwnd growth.
[All98]表明，在模拟中，与总是生成延迟ACK的接收器相比，在慢启动后使用延迟ACK（DAASS）可以缩短传输时间。然而，由于cwnd增长率的增加，DAASS也略微增加了损失率。
The major problem with DAASS is in the implementation. The receiver has to somehow know when the sender is using the slow start algorithm. The receiver could implement a heuristic that attempts to watch the change in the amount of data being received and change the ACKing behavior accordingly. Or, the sender could send a message (a flipped bit in the TCP header, perhaps) indicating that it was using slow start. The implementation of DAASS is, therefore, an open issue.
DAASS的主要问题在于实现。接收方必须知道发送方何时使用慢启动算法。接收器可以实现一种启发式，尝试观察接收的数据量的变化，并相应地改变应答行为。或者，发送方可以发送一条消息（可能是TCP头中的一个翻转位），指示它正在使用慢启动。因此，DAASS的实施是一个悬而未决的问题。
Using DAASS does not violate the TCP congestion control specification [APS99]. However, the standards (RFC 2581 [APS99]) currently recommend using delayed acknowledgments and DAASS goes (partially) against this recommendation.
使用DAASS不会违反TCP拥塞控制规范[APS99]。然而，标准（RFC 2581[APS99]）目前建议使用延迟确认，DAASS（部分）反对该建议。
DAASS should work equally well in all scenarios presented in section 2. However, in asymmetric networks it may aggravate ACK congestion in the return link, due to the increased number of ACKs (see sections 3.9 and 3.10 for a more detailed discussion of ACK congestion).
DAASS应在第2节中介绍的所有场景中都同样有效。然而，在非对称网络中，由于ACK数量的增加，可能会加剧返回链路中的ACK拥塞（有关ACK拥塞的更详细讨论，请参见第3.9节和第3.10节）。
DAASS has several possible interactions with other proposals made in the research community. DAASS can aggravate congestion on the path between the data receiver and the data sender due to the increased number of returning acknowledgments. This can have an especially adverse effect on asymmetric networks that are prone to experiencing ACK congestion. As outlined in sections 3.9 and 3.10, several mitigations have been proposed to reduce the number of ACKs that are passed over a low-bandwidth return link. Using DAASS will increase the number of ACKs sent by the receiver. The interaction between DAASS and the methods for reducing the number of ACKs is an open research question. Also, as noted in section 3.2.1.5 above, DAASS provides some of the same benefits as using a larger initial congestion window and therefore it may not be desirable to use both mechanisms together. However, this remains an open question. Finally, DAASS and limited byte counting are both used to increase
DAASS与研究界提出的其他提案有几种可能的互动。由于返回确认的数量增加，DAASS会加剧数据接收方和数据发送方之间路径上的拥塞。这可能对容易出现ACK拥塞的非对称网络产生特别不利的影响。如第3.9节和第3.10节所述，已提出若干缓解措施，以减少通过低带宽返回链路传递的ACK数量。使用DAASS将增加接收器发送的ACK数量。DAASS和减少ACK数量的方法之间的相互作用是一个开放的研究问题。此外，如上文第3.2.1.5节所述，DAASS提供了一些与使用较大初始拥塞窗口相同的好处，因此可能不希望同时使用这两种机制。然而，这仍然是一个悬而未决的问题。最后，DAASS和有限字节计数都用于增加
the rate at which the congestion window is opened. The DAASS algorithm substantially reduces the impact limited byte counting has on the rate of congestion window increase.
拥塞窗口打开的速率。DAASS算法大大减少了有限字节计数对拥塞窗口增加速率的影响。
The initial slow start phase is used by TCP to determine an appropriate congestion window size for the given network conditions [Jac88]. Slow start is terminated when TCP detects congestion, or when the size of cwnd reaches the size of the receiver's advertised window. Slow start is also terminated if cwnd grows beyond a certain size. The threshold at which TCP ends slow start and begins using the congestion avoidance algorithm is called "ssthresh" [Jac88]. In most implementations, the initial value for ssthresh is the receiver's advertised window. During slow start, TCP roughly doubles the size of cwnd every RTT and therefore can overwhelm the network with at most twice as many segments as the network can handle. By setting ssthresh to a value less than the receiver's advertised window initially, the sender may avoid overwhelming the network with twice the appropriate number of segments. Hoe [Hoe96] proposes using the packet-pair algorithm [Kes91] and the measured RTT to determine a more appropriate value for ssthresh. The algorithm observes the spacing between the first few returning ACKs to determine the bandwidth of the bottleneck link. Together with the measured RTT, the delay*bandwidth product is determined and ssthresh is set to this value. When TCP's cwnd reaches this reduced ssthresh, slow start is terminated and transmission continues using congestion avoidance, which is a more conservative algorithm for increasing the size of the congestion window.
TCP使用初始慢启动阶段确定给定网络条件下合适的拥塞窗口大小[Jac88]。当TCP检测到拥塞时，或当cwnd的大小达到接收器播发窗口的大小时，慢启动终止。如果cwnd增长超过一定大小，慢启动也会终止。TCP结束慢速启动并开始使用拥塞避免算法的阈值称为“ssthresh”[Jac88]。在大多数实现中，ssthresh的初始值是接收方的公告窗口。在慢启动期间，TCP大约会在每个RTT中将cwnd的大小增加一倍，因此可以用最多两倍于网络所能处理的网段来覆盖网络。通过最初将ssthresh设置为小于接收者的广告窗口的值，发送者可以避免用两倍于适当数量的段压倒网络。Hoe[Hoe96]建议使用分组对算法[Kes91]和测量的RTT来确定ssthresh的更合适值。该算法通过观察前几个返回ack之间的间隔来确定瓶颈链路的带宽。与测量的RTT一起，确定延迟*带宽乘积，并将ssthresh设置为该值。当TCP的cwnd达到这个减少的ssthresh时，慢启动被终止，传输继续使用拥塞避免，这是一种更保守的增加拥塞窗口大小的算法。
It has been shown that estimating ssthresh can improve performance and decrease packet loss in simulations [Hoe96]. However, obtaining an accurate estimate of the available bandwidth in a dynamic network is very challenging, especially attempting to do so on the sending side of the TCP connection [AP99]. Therefore, before this mechanism is widely deployed, bandwidth estimation must be studied in a more detail.
仿真表明，估计ssthresh可以提高性能并减少数据包丢失[Hoe96]。然而，在动态网络中获得可用带宽的准确估计是非常具有挑战性的，尤其是在TCP连接的发送端尝试这样做[AP99]。因此，在广泛部署该机制之前，必须更详细地研究带宽估计。
As outlined in [Hoe96], estimating ssthresh requires changes to the data sender's TCP stack. As suggested in [AP99], bandwidth estimates may be more accurate when taken by the TCP receiver, and therefore both sender and receiver changes would be required. Estimating
如[Hoe96]所述，估计ssthresh需要更改数据发送方的TCP堆栈。正如[AP99]中所建议的，当TCP接收器进行带宽估计时，带宽估计可能更准确，因此需要更改发送方和接收方。估计
ssthresh is safe to implement in production networks from a congestion control perspective, as it can only make TCP more conservative than outlined in RFC 2581 [APS99] (assuming the TCP implementation is using an initial ssthresh of infinity as allowed by [APS99]).
从拥塞控制的角度来看，ssthresh可以安全地在生产网络中实现，因为它只能使TCP比RFC 2581[APS99]中概述的更保守（假设TCP实现使用[APS99]允许的无限初始ssthresh）。
It is expected that this mechanism will work equally well in all symmetric topologies outlined in section 2. However, asymmetric links pose a special problem, as the rate of the returning ACKs may not be the bottleneck bandwidth in the forward direction. This can lead to the sender setting ssthresh too low. Premature termination of slow start can hurt performance, as congestion avoidance opens cwnd more conservatively. Receiver-based bandwidth estimators do not suffer from this problem.
预计该机制将在第2节中概述的所有对称拓扑中同样有效。然而，非对称链路带来了一个特殊问题，因为返回ack的速率可能不是前进方向的瓶颈带宽。这可能导致发送器将ssthresh设置得过低。过早终止慢启动可能会损害性能，因为避免拥塞会更加保守地打开cwnd。基于接收机的带宽估计器不会遇到这个问题。
Terminating slow start at the right time is useful to avoid multiple dropped segments. However, using a selective acknowledgment-based loss recovery scheme (as outlined in section 3.3.2) can drastically improve TCP's ability to quickly recover from multiple lost segments Therefore, it may not be as important to terminate slow start before a large loss event occurs. [AP99] shows that using delayed acknowledgments [Bra89] reduces the effectiveness of sender-side bandwidth estimation. Therefore, using delayed ACKs only during slow start (as outlined in section 3.2.3) may make bandwidth estimation more feasible.
在正确的时间终止慢速启动有助于避免多个断开的段。但是，使用基于选择性确认的丢失恢复方案（如第3.3.2节所述）可以显著提高TCP从多个丢失段快速恢复的能力。因此，在发生大的丢失事件之前终止慢启动可能并不重要。[AP99]表明使用延迟确认[Bra89]会降低发送方带宽估计的有效性。因此，仅在慢启动期间使用延迟ack（如第3.2.3节所述）可能使带宽估计更可行。
Several similar algorithms have been developed and studied that improve TCP's ability to recover from multiple lost segments in a window of data without relying on the (often long) retransmission timeout. These sender-side algorithms, known as NewReno TCP, do not depend on the availability of selective acknowledgments (SACKs) [MMFR96].
已经开发和研究了几种类似的算法，这些算法提高了TCP在不依赖（通常很长的）重传超时的情况下从数据窗口中的多个丢失段中恢复的能力。这些发送方算法称为NewReno TCP，不依赖于选择性确认（SACK）的可用性[MMFR96]。
These algorithms generally work by updating the fast recovery algorithm to use information provided by "partial ACKs" to trigger retransmissions. A partial ACK covers some new data, but not all data outstanding when a particular loss event starts. For instance, consider the case when segment N is retransmitted using the fast
这些算法通常通过更新快速恢复算法来工作，以使用“部分ack”提供的信息来触发重传。当特定丢失事件开始时，部分确认覆盖一些新数据，但不是所有未完成的数据。例如，考虑分段N使用快速重传的情况。
retransmit algorithm and segment M is the last segment sent when segment N is resent. If segment N is the only segment lost, the ACK elicited by the retransmission of segment N would be for segment M. If, however, segment N+1 was also lost, the ACK elicited by the retransmission of segment N will be N+1. This can be taken as an indication that segment N+1 was lost and used to trigger a retransmission.
重传算法，M段是重新发送N段时发送的最后一段。如果N段是唯一丢失的段，则N段重传引发的ACK将用于M段。但是，如果N+1段也丢失，则N段重传引发的ACK将为N+1。这可被视为段N+1丢失的指示，并用于触发重传。
Hoe [Hoe95,Hoe96] introduced the idea of using partial ACKs to trigger retransmissions and showed that doing so could improve performance. [FF96] shows that in some cases using partial ACKs to trigger retransmissions reduces the time required to recover from multiple lost segments. However, [FF96] also shows that in some cases (many lost segments) relying on the RTO timer can improve performance over simply using partial ACKs to trigger all retransmissions. [HK99] shows that using partial ACKs to trigger retransmissions, in conjunction with SACK, improves performance when compared to TCP using fast retransmit/fast recovery in a satellite environment. Finally, [FH99] describes several slightly different variants of NewReno.
Hoe[Hoe95，Hoe96]提出了使用部分ACK触发重传的想法，并表明这样做可以提高性能。[FF96]表明，在某些情况下，使用部分ACK触发重传可以减少从多个丢失的段中恢复所需的时间。然而，[FF96]还表明，在某些情况下（许多丢失的段），依靠RTO计时器可以提高性能，而不仅仅是使用部分ACK来触发所有重传。[HK99]表明，与在卫星环境中使用快速重传/快速恢复的TCP相比，使用部分ACK触发重传以及SACK可提高性能。最后，[FH99]描述了几种稍微不同的NewReno变体。
Implementing these fast recovery enhancements requires changes to the sender-side TCP stack. These changes can safely be implemented in production networks and are allowed by RFC 2581 [APS99].
实现这些快速恢复增强功能需要更改发送方端TCP堆栈。这些更改可以安全地在生产网络中实施，并且RFC 2581[APS99]允许这些更改。
It is expected that these changes will work well in all environments outlined in section 2.
预计这些更改将在第2节中概述的所有环境中正常工作。
See section 3.3.2.2.5.
见第3.3.2.2.5节。
Fall and Floyd [FF96] describe a conservative extension to the fast recovery algorithm that takes into account information provided by selective acknowledgments (SACKs) [MMFR96] sent by the receiver. The algorithm starts after fast retransmit triggers the resending of a
Fall和Floyd[FF96]描述了快速恢复算法的保守扩展，该算法考虑了接收机发送的选择性确认（SACK）[MMFR96]提供的信息。该算法在快速重传触发重新发送数据后启动
segment. As with fast retransmit, the algorithm cuts cwnd in half when a loss is detected. The algorithm keeps a variable called "pipe", which is an estimate of the number of outstanding segments in the network. The pipe variable is decremented by 1 segment for each duplicate ACK that arrives with new SACK information. The pipe variable is incremented by 1 for each new or retransmitted segment sent. A segment may be sent when the value of pipe is less than cwnd (this segment is either a retransmission per the SACK information or a new segment if the SACK information indicates that no more retransmits are needed).
段与快速重传一样，当检测到丢失时，该算法将cwnd减半。该算法保留一个名为“pipe”的变量，该变量是对网络中未完成段数的估计。对于带有新SACK信息的每个重复ACK，管道变量递减1段。对于发送的每个新的或重新传输的段，管道变量递增1。当pipe的值小于cwnd时，可以发送一个段（该段是每个SACK信息的重传，或者如果SACK信息指示不再需要重传，则为新段）。
This algorithm generally allows TCP to recover from multiple segment losses in a window of data within one RTT of loss detection. Like the forward acknowledgment (FACK) algorithm described below, the SACK information allows the pipe algorithm to decouple the choice of when to send a segment from the choice of what segment to send.
该算法通常允许TCP在丢失检测的一个RTT内从一个数据窗口中的多个段丢失中恢复。与下面描述的前向确认（FACK）算法一样，SACK信息允许管道算法将何时发送段的选择与发送什么段的选择分离。
[APS99] allows the use of this algorithm, as it is consistent with the spirit of the fast recovery algorithm.
[APS99]允许使用该算法，因为它符合快速恢复算法的精神。
[FF96] shows that the above described SACK algorithm performs better than several non-SACK based recovery algorithms when 1--4 segments are lost from a window of data. [AHKO97] shows that the algorithm improves performance over satellite links. Hayes [Hay97] shows the in certain circumstances, the SACK algorithm can hurt performance by generating a large line-rate burst of data at the end of loss recovery, which causes further loss.
[FF96]表明，当一个数据窗口丢失1-4个数据段时，上述SACK算法的性能优于几种非SACK恢复算法。[AHKO97]表明，该算法提高了卫星链路的性能。Hayes[Hay97]指出，在某些情况下，SACK算法会在丢失恢复结束时生成大量线速率的数据突发，从而影响性能，从而导致进一步的丢失。
This algorithm is implemented in the sender's TCP stack. However, it relies on SACK information generated by the receiver. This algorithm is safe for shared networks and is allowed by RFC 2581 [APS99].
该算法在发送方的TCP堆栈中实现。但是，它依赖于接收方生成的SACK信息。该算法对于共享网络是安全的，RFC 2581[APS99]允许该算法。
It is expected that the pipe algorithm will work equally well in all scenarios presented in section 2.
预计pipe算法将在第2节中介绍的所有场景中同样有效。
See section 3.3.2.2.5.
见第3.3.2.2.5节。
The Forward Acknowledgment (FACK) algorithm [MM96a,MM96b] was developed to improve TCP congestion control during loss recovery. FACK uses TCP SACK options to glean additional information about the congestion state, adding more precise control to the injection of data into the network during recovery. FACK decouples the congestion control algorithms from the data recovery algorithms to provide a simple and direct way to use SACK to improve congestion control. Due to the separation of these two algorithms, new data may be sent during recovery to sustain TCP's self-clock when there is no further data to retransmit.
前向确认（FACK）算法[MM96a，MM96b]被开发用于改进丢失恢复期间的TCP拥塞控制。FACK使用TCP SACK选项收集有关拥塞状态的附加信息，从而在恢复过程中对数据注入网络进行更精确的控制。FACK将拥塞控制算法与数据恢复算法分离，提供了一种简单直接的方法来使用SACK改进拥塞控制。由于这两种算法的分离，在恢复过程中可能会发送新数据，以在没有其他数据可重传时维持TCP的自时钟。
The most recent version of FACK is Rate-Halving [MM96b], in which one packet is sent for every two ACKs received during recovery. Transmitting a segment for every-other ACK has the result of reducing the congestion window in one round trip to half of the number of packets that were successfully handled by the network (so when cwnd is too large by more than a factor of two it still gets reduced to half of what the network can sustain). Another important aspect of FACK with Rate-Halving is that it sustains the ACK self-clock during recovery because transmitting a packet for every-other ACK does not require half a cwnd of data to drain from the network before transmitting, as required by the fast recovery algorithm [Ste97,APS99].
FACK的最新版本是速率减半[MM96b]，在该版本中，恢复期间每收到两个ACK，就发送一个数据包。每隔一次ACK发送一个段，其结果是将一次往返中的拥塞窗口减少到网络成功处理的数据包数量的一半（因此，当cwnd太大超过两倍时，它仍然会减少到网络能够承受的数据包数量的一半）。具有减半速率的FACK的另一个重要方面是，它在恢复期间维持ACK自时钟，因为按照快速恢复算法[Ste97，APS99]的要求，每发送一个ACK的数据包不需要在发送之前从网络中排出半个cwnd的数据。
In addition, the FACK with Rate-Halving implementation provides Thresholded Retransmission to each lost segment. "Tcprexmtthresh" is the number of duplicate ACKs required by TCP to trigger a fast retransmit and enter recovery. FACK applies thresholded retransmission to all segments by waiting until tcprexmtthresh SACK blocks indicate that a given segment is missing before resending the segment. This allows reasonable behavior on links that reorder segments. As described above, FACK sends a segment for every second ACK received during recovery. New segments are transmitted except when tcprexmtthresh SACK blocks have been observed for a dropped segment, at which point the dropped segment is retransmitted.
此外，具有速率减半实现的FACK向每个丢失的段提供阈值重传。“Tcprexmtthresh”是TCP触发快速重传并进入恢复所需的重复ACK数。FACK通过等待tcprexmtthresh SACK块在重新发送段之前指示给定段丢失，将阈值重传应用于所有段。这允许对重新排序段的链接进行合理的行为。如上所述，FACK为恢复期间接收到的每秒钟ACK发送一段。传输新段时，除非已观察到丢弃段的tcprexmtthresh SACK块，此时将重新传输丢弃段。
[APS99] allows the use of this algorithm, as it is consistent with the spirit of the fast recovery algorithm.
[APS99]允许使用该算法，因为它符合快速恢复算法的精神。
The original FACK algorithm is outlined in [MM96a]. The algorithm was later enhanced to include Rate-Halving [MM96b]. The real-world performance of FACK with Rate-Halving was shown to be much closer to
原始FACK算法在[MM96a]中概述。该算法后来得到了改进，包括速率减半[MM96b]。FACK在减半速率情况下的实际性能更接近实际情况
the theoretical maximum for TCP than either TCP Reno or the SACK-based extensions to fast recovery outlined in section 3.3.2.1 [MSMO97].
TCP的理论最大值大于TCP Reno或第3.3.2.1节[MSMO97]中概述的基于SACK的快速恢复扩展。
In order to use FACK, the sender's TCP stack must be modified. In addition, the receiver must be able to generate SACK options to obtain the full benefit of using FACK. The FACK algorithm is safe for shared networks and is allowed by RFC 2581 [APS99].
为了使用FACK，必须修改发送方的TCP堆栈。此外，接收器必须能够生成SACK选项，以获得使用FACK的全部好处。FACK算法对于共享网络是安全的，RFC 2581[APS99]允许该算法。
FACK is expected to improve performance in all environments outlined in section 2. Since it is better able to sustain its self-clock than TCP Reno, it may be considerably more attractive over long delay paths.
FACK有望在第2节概述的所有环境中提高性能。由于它比TCP-Reno更好地维持其自身时钟，因此它在长延迟路径上可能更具吸引力。
Both SACK based loss recovery algorithms described above (the fast recovery enhancement and the FACK algorithm) are similar in that they attempt to effectively repair multiple lost segments from a window of data. Which of the SACK-based loss recovery algorithms to use is still an open research question. In addition, these algorithms are similar to the non-SACK NewReno algorithm described in section 3.3.1, in that they attempt to recover from multiple lost segments without reverting to using the retransmission timer. As has been shown, the above SACK based algorithms are more robust than the NewReno algorithm. However, the SACK algorithm requires a cooperating TCP receiver, which the NewReno algorithm does not. A reasonable TCP implementation might include both a SACK-based and a NewReno-based loss recovery algorithm such that the sender can use the most appropriate loss recovery algorithm based on whether or not the receiver supports SACKs. Finally, both SACK-based and non-SACK-based versions of fast recovery have been shown to transmit a large burst of data upon leaving loss recovery, in some cases [Hay97]. Therefore, the algorithms may benefit from some burst suppression algorithm.
上述两种基于SACK的丢失恢复算法（快速恢复增强算法和FACK算法）的相似之处在于，它们试图从一个数据窗口有效修复多个丢失的数据段。使用哪种基于SACK的损失恢复算法仍然是一个悬而未决的研究问题。此外，这些算法与第3.3.1节中描述的非SACK-NewReno算法相似，因为它们试图从多个丢失的段中恢复，而无需恢复到使用重传计时器。如图所示，上述基于SACK的算法比NewReno算法更健壮。然而，SACK算法需要一个协作的TCP接收器，而NewReno算法则不需要。合理的TCP实现可能包括基于SACK和基于NewReno的丢失恢复算法，以便发送方可以根据接收方是否支持SACK使用最合适的丢失恢复算法。最后，在某些情况下，基于SACK和非SACK的快速恢复版本在离开丢失恢复时都可以传输大量数据[Hay97]。因此，这些算法可能受益于某些突发抑制算法。
Explicit congestion notification (ECN) allows routers to inform TCP senders about imminent congestion without dropping segments. Two major forms of ECN have been studied. A router employing backward ECN (BECN), transmits messages directly to the data originator
显式拥塞通知（ECN）允许路由器向TCP发送方通知即将发生的拥塞，而无需丢弃数据段。已经研究了两种主要的ECN形式。采用反向ECN（BECN）的路由器直接向数据发起人发送消息
informing it of congestion. IP routers can accomplish this with an ICMP Source Quench message. The arrival of a BECN signal may or may not mean that a TCP data segment has been dropped, but it is a clear indication that the TCP sender should reduce its sending rate (i.e., the value of cwnd). The second major form of congestion notification is forward ECN (FECN). FECN routers mark data segments with a special tag when congestion is imminent, but forward the data segment. The data receiver then echos the congestion information back to the sender in the ACK packet. A description of a FECN mechanism for TCP/IP is given in [RF99].
通知它交通堵塞。IP路由器可以通过ICMP源猝灭消息来实现这一点。BECN信号的到达可能意味着TCP数据段已被丢弃，也可能不意味着TCP数据段已被丢弃，但这清楚地表明TCP发送方应降低其发送速率（即cwnd的值）。拥塞通知的第二种主要形式是前向ECN（FECN）。当即将发生拥塞时，FECN路由器用特殊标签标记数据段，但转发数据段。然后，数据接收器在ACK数据包中将拥塞信息回显给发送者。[RF99]中给出了TCP/IP的FECN机制的描述。
As described in [RF99], senders transmit segments with an "ECN-Capable Transport" bit set in the IP header of each packet. If a router employing an active queueing strategy, such as Random Early Detection (RED) [FJ93,BCC+98], would otherwise drop this segment, an "Congestion Experienced" bit in the IP header is set instead. Upon reception, the information is echoed back to TCP senders using a bit in the TCP header. The TCP sender adjusts the congestion window just as it would if a segment was dropped.
如[RF99]所述，发送方在每个数据包的IP报头中设置了一个“支持ECN传输”位来传输数据段。如果采用主动排队策略（如随机早期检测（RED）[FJ93，BCC+98]的路由器将丢弃此段，则在IP报头中设置“拥塞经历”位。接收到信息后，使用TCP报头中的一个位将信息回显到TCP发送方。TCP发送方将调整拥塞窗口，就像丢弃某个段时一样。
The implementation of ECN as specified in [RF99] requires the deployment of active queue management mechanisms in the affected routers. This allows the routers to signal congestion by sending TCP a small number of "congestion signals" (segment drops or ECN messages), rather than discarding a large number of segments, as can happen when TCP overwhelms a drop-tail router queue.
[RF99]中规定的ECN实现需要在受影响的路由器中部署活动队列管理机制。这允许路由器通过向TCP发送少量“拥塞信号”（段丢弃或ECN消息）来发出拥塞信号，而不是丢弃大量段，当TCP压倒掉掉尾路由器队列时可能会发生这种情况。
Since satellite networks generally have higher bit-error rates than terrestrial networks, determining whether a segment was lost due to congestion or corruption may allow TCP to achieve better performance in high BER environments than currently possible (due to TCP's assumption that all loss is due to congestion). While not a solution to this problem, adding an ECN mechanism to TCP may be a part of a mechanism that will help achieve this goal. See section 3.3.4 for a more detailed discussion of differentiating between corruption and congestion based losses.
由于卫星网络通常比地面网络具有更高的误码率，因此确定某个网段是否因拥塞或损坏而丢失，可以使TCP在高BER环境中获得比当前更好的性能（因为TCP假设所有丢失都是由于拥塞）。虽然不是这个问题的解决方案，但向TCP添加ECN机制可能是有助于实现此目标的机制的一部分。请参阅第3.3.4节，了解关于区分腐败和基于拥塞的损失的更详细讨论。
[Flo94] shows that ECN is effective in reducing the segment loss rate which yields better performance especially for short and interactive TCP connections. Furthermore, [Flo94] also shows that ECN avoids some unnecessary, and costly TCP retransmission timeouts. Finally, [Flo94] also considers some of the advantages and disadvantages of various forms of explicit congestion notification.
[Flo94]表明，ECN在降低段丢失率方面是有效的，这会产生更好的性能，尤其是对于短的交互式TCP连接。此外，[Flo94]还表明，ECN避免了一些不必要且代价高昂的TCP重传超时。最后，[Flo94]还考虑了各种形式的显式拥塞通知的一些优缺点。
Deployment of ECN requires changes to the TCP implementation on both sender and receiver. Additionally, deployment of ECN requires deployment of some active queue management infrastructure in routers. RED is assumed in most ECN discussions, because RED is already identifying segments to drop, even before its buffer space is exhausted. ECN simply allows the delivery of "marked" segments while still notifying the end nodes that congestion is occurring along the path. ECN is safe (from a congestion control perspective) for shared networks, as it maintains the same TCP congestion control principles as are used when congestion is detected via segment drops.
部署ECN需要更改发送方和接收方的TCP实现。此外，部署ECN需要在路由器中部署一些主动队列管理基础设施。在大多数ECN讨论中都假定为RED，因为RED已经在标识要删除的段，甚至在其缓冲区空间耗尽之前。ECN只允许传递“标记”的段，同时仍然通知终端节点沿路径发生拥塞。ECN对于共享网络是安全的（从拥塞控制的角度来看），因为它保持了与通过段丢弃检测到拥塞时使用的相同TCP拥塞控制原则。
It is expected that none of the environments outlined in section 2 will present a bias towards or against ECN traffic.
预计第2节中概述的任何环境都不会对ECN流量产生偏见。
Note that some form of active queueing is necessary to use ECN (e.g., RED queueing).
请注意，使用ECN需要某种形式的活动排队（例如，红色排队）。
Differentiating between congestion (loss of segments due to router buffer overflow or imminent buffer overflow) and corruption (loss of segments due to damaged bits) is a difficult problem for TCP. This differentiation is particularly important because the action that TCP should take in the two cases is entirely different. In the case of corruption, TCP should merely retransmit the damaged segment as soon as its loss is detected; there is no need for TCP to adjust its congestion window. On the other hand, as has been widely discussed above, when the TCP sender detects congestion, it should immediately reduce its congestion window to avoid making the congestion worse.
区分拥塞（由于路由器缓冲区溢出或即将发生的缓冲区溢出导致的段丢失）和损坏（由于位损坏导致的段丢失）对于TCP来说是一个难题。这种区别尤其重要，因为TCP在这两种情况下应该采取的行动完全不同。在损坏的情况下，TCP只应在检测到损坏段丢失时重新传输损坏段；TCP不需要调整其拥塞窗口。另一方面，如上所述，当TCP发送方检测到拥塞时，它应该立即减少其拥塞窗口，以避免使拥塞恶化。
TCP's defined behavior, as motivated by [Jac88,Jac90] and defined in [Bra89,Ste97,APS99], is to assume that all loss is due to congestion and to trigger the congestion control algorithms, as defined in [Ste97,APS99]. The loss may be detected using the fast retransmit algorithm, or in the worst case is detected by the expiration of TCP's retransmission timer.
根据[Jac88，Jac90]和[Bra89，Ste97，APS99]中的定义，TCP的定义行为是假设所有损失都是由于拥塞造成的，并触发[Ste97，APS99]中定义的拥塞控制算法。可以使用快速重传算法检测丢失，或者在最坏的情况下，通过TCP的重传计时器过期来检测丢失。
TCP's assumption that loss is due to congestion rather than corruption is a conservative mechanism that prevents congestion collapse [Jac88,FF98]. Over satellite networks, however, as in many wireless environments, loss due to corruption is more common than on terrestrial networks. One common partial solution to this problem is
TCP关于丢失是由于拥塞而不是损坏的假设是防止拥塞崩溃的保守机制[Jac88，FF98]。然而，在卫星网络上，如同在许多无线环境中一样，由于损坏而造成的损失比在地面网络上更为常见。这个问题的一个常见部分解决方案是
to add Forward Error Correction (FEC) to the data that's sent over the satellite/wireless link. A more complete discussion of the benefits of FEC can be found in [AGS99]. However, given that FEC does not always work or cannot be universally applied, other mechanisms have been studied to attempt to make TCP able to differentiate between congestion-based and corruption-based loss.
向通过卫星/无线链路发送的数据添加前向纠错（FEC）。有关FEC好处的更完整讨论，请参见[AGS99]。然而，鉴于FEC并不总是有效或不能普遍应用，已经研究了其他机制，试图使TCP能够区分基于拥塞和基于损坏的丢失。
TCP segments that have been corrupted are most often dropped by intervening routers when link-level checksum mechanisms detect that an incoming frame has errors. Occasionally, a TCP segment containing an error may survive without detection until it arrives at the TCP receiving host, at which point it will almost always either fail the IP header checksum or the TCP checksum and be discarded as in the link-level error case. Unfortunately, in either of these cases, it's not generally safe for the node detecting the corruption to return information about the corrupt packet to the TCP sender because the sending address itself might have been corrupted.
当链路级校验和机制检测到传入帧有错误时，已损坏的TCP段通常会被中间路由器丢弃。有时，包含错误的TCP段在到达TCP接收主机之前可能不会被检测到，在这一点上，它几乎总是会使IP报头校验和或TCP校验和失败，并像在链路级错误的情况下一样被丢弃。不幸的是，在这两种情况下，检测到损坏的节点将有关损坏数据包的信息返回给TCP发送方通常都不安全，因为发送地址本身可能已损坏。
Because the probability of link errors on a satellite link is relatively greater than on a hardwired link, it is particularly important that the TCP sender retransmit these lost segments without reducing its congestion window. Because corrupt segments do not indicate congestion, there is no need for the TCP sender to enter a congestion avoidance phase, which may waste available bandwidth. Simulations performed in [SF98] show a performance improvement when TCP can properly differentiate between between corruption and congestion of wireless links.
由于卫星链路上的链路错误概率相对大于硬连线链路上的链路错误概率，因此TCP发送方在不减少其拥塞窗口的情况下重新传输这些丢失的段尤其重要。由于损坏的段并不表示拥塞，因此TCP发送方无需进入拥塞避免阶段，这可能会浪费可用带宽。在[SF98]中进行的仿真表明，当TCP能够正确区分无线链路的损坏和拥塞时，性能得到了改善。
Perhaps the greatest research challenge in detecting corruption is getting TCP (a transport-layer protocol) to receive appropriate information from either the network layer (IP) or the link layer. Much of the work done to date has involved link-layer mechanisms that retransmit damaged segments. The challenge seems to be to get these mechanisms to make repairs in such a way that TCP understands what happened and can respond appropriately.
检测损坏的最大研究挑战可能是让TCP（传输层协议）从网络层（IP）或链路层接收适当的信息。迄今为止所做的大部分工作涉及重新传输受损段的链路层机制。挑战似乎是让这些机制以这样的方式进行修复，使TCP能够理解发生了什么，并能够做出适当的响应。
Research into corruption detection to date has focused primarily on making the link level detect errors and then perform link-level retransmissions. This work is summarized in [BKVP97,BPSK96]. One of the problems with this promising technique is that it causes an effective reordering of the segments from the TCP receiver's point of view. As a simple example, if segments A B C D are sent across a noisy link and segment B is corrupted, segments C and D may have already crossed the link before B can be retransmitted at the link
迄今为止，对损坏检测的研究主要集中在使链路级检测错误，然后执行链路级重传。这项工作总结在[BKVP97，BPSK96]中。这种有前途的技术的一个问题是，从TCP接收方的角度来看，它会导致段的有效重新排序。作为一个简单的例子，如果段a、B、C、D在有噪声的链路上发送，并且段B被破坏，则段C和D可能在B可以在链路上重新传输之前已经穿过链路
level, causing them to arrive at the TCP receiver in the order A C D B. This segment reordering would cause the TCP receiver to generate duplicate ACKs upon the arrival of segments C and D. If the reordering was bad enough, the sender would trigger the fast retransmit algorithm in the TCP sender, in response to the duplicate ACKs. Research presented in [MV98] proposes the idea of suppressing or delaying the duplicate ACKs in the reverse direction to counteract this behavior. Alternatively, proposals that make TCP more robust in the face of re-ordered segment arrivals [Flo99] may reduce the side effects of the re-ordering caused by link-layer retransmissions.
级别，导致它们以A C D B的顺序到达TCP接收器。此段重新排序将导致TCP接收器在段C和D到达时生成重复的确认。如果重新排序足够糟糕，则发送方将触发TCP发送方中的快速重传算法，以响应重复的确认。[MV98]中的研究提出了抑制或延迟反向重复ACK的想法，以抵消这种行为。或者，使TCP在面对重新排序的段到达时更加健壮的建议[Flo99]可以减少由链路层重新传输引起的重新排序的副作用。
A more high-level approach, outlined in the [DMT96], uses a new "corruption experienced" ICMP error message generated by routers that detect corruption. These messages are sent in the forward direction, toward the packet's destination, rather than in the reverse direction as is done with ICMP Source Quench messages. Sending the error messages in the forward direction allows this feedback to work over asymmetric paths. As noted above, generating an error message in response to a damaged packet is problematic because the source and destination addresses may not be valid. The mechanism outlined in [DMT96] gets around this problem by having the routers maintain a small cache of recent packet destinations; when the router experiences an error rate above some threshold, it sends an ICMP corruption-experienced message to all of the destinations in its cache. Each TCP receiver then must return this information to its respective TCP sender (through a TCP option). Upon receiving an ACK with this "corruption-experienced" option, the TCP sender assumes that packet loss is due to corruption rather than congestion for two round trip times (RTT) or until it receives additional link state information (such as "link down", source quench, or additional "corruption experienced" messages). Note that in shared networks, ignoring segment loss for 2 RTTs may aggravate congestion by making TCP unresponsive.
[DMT96]中概述了一种更高级的方法，它使用由检测损坏的路由器生成的新的“有损坏经验的”ICMP错误消息。这些消息是朝着数据包目的地的正向发送的，而不是像ICMP源消息那样朝着相反的方向发送。正向发送错误消息允许此反馈在非对称路径上工作。如上所述，由于源地址和目标地址可能无效，因此生成错误消息以响应损坏的分组是有问题的。[DMT96]中概述的机制通过让路由器维护最近数据包目的地的小型缓存来解决这个问题；当路由器遇到高于某个阈值的错误率时，它会向其缓存中的所有目的地发送一条ICMP损坏消息。然后，每个TCP接收器必须将此信息返回到其各自的TCP发送者（通过TCP选项）。TCP发送方在收到带有此“有损坏经历”选项的ACK时，会假定数据包丢失是由于两个往返时间（RTT）的损坏而不是拥塞造成的，或者直到它收到额外的链路状态信息（例如“链路断开”、“源猝灭”或额外的“有损坏经历”消息）。请注意，在共享网络中，忽略2个RTT的段丢失可能会使TCP无响应，从而加剧拥塞。
All of the techniques discussed above require changes to at least the TCP sending and receiving stacks, as well as intermediate routers. Due to the concerns over possibly ignoring congestion signals (i.e., segment drops), the above algorithm is not recommended for use in shared networks.
以上讨论的所有技术至少需要更改TCP发送和接收堆栈以及中间路由器。由于担心可能忽略拥塞信号（即段丢弃），不建议在共享网络中使用上述算法。
It is expected that corruption detection, in general would be beneficial in all environments outlined in section 2. It would be particularly beneficial in the satellite/wireless environment over which these errors may be more prevalent.
一般来说，腐败检测在第2节概述的所有环境中都是有益的。在卫星/无线环境中，这些错误可能更普遍，这将特别有益。
SACK-based loss recovery algorithms (as described in 3.3.2) may reduce the impact of corrupted segments on mostly clean links because recovery will be able to happen more rapidly (and without relying on the retransmission timer). Note that while SACK-based loss recovery helps, throughput will still suffer in the face of non-congestion related packet loss.
基于SACK的丢失恢复算法（如3.3.2所述）可以减少损坏段对大部分干净链路的影响，因为恢复将能够更快地进行（并且不依赖于重传计时器）。请注意，尽管基于SACK的丢失恢复有帮助，但在面对非拥塞相关的数据包丢失时，吞吐量仍将受到影响。
During congestion avoidance, in the absence of loss, the TCP sender adds approximately one segment to its congestion window during each RTT [Jac88,Ste97,APS99]. Several researchers have observed that this policy leads to unfair sharing of bandwidth when multiple connections with different RTTs traverse the same bottleneck link, with the long RTT connections obtaining only a small fraction of their fair share of the bandwidth.
在避免拥塞期间，在没有丢失的情况下，TCP发送方在每个RTT期间向其拥塞窗口添加大约一个段[Jac88、Ste97、APS99]。一些研究人员观察到，当具有不同RTT的多个连接穿过同一瓶颈链路时，这种策略会导致不公平的带宽共享，长RTT连接只获得其公平带宽共享的一小部分。
One effective solution to this problem is to deploy fair queueing and TCP-friendly buffer management in network routers [Sut98]. However, in the absence of help from the network, other researchers have investigated changes to the congestion avoidance policy at the TCP sender, as described in [Flo91,HK98].
解决这个问题的一个有效方法是在网络路由器中部署公平排队和TCP友好的缓冲区管理[Sut98]。然而，在没有网络帮助的情况下，其他研究人员调查了TCP发送方拥塞避免策略的变化，如[Flo91，HK98]所述。
The "Constant-Rate" increase policy has been studied in [Flo91,HK98]. It attempts to equalize the rate at which TCP senders increase their sending rate during congestion avoidance. Both [Flo91] and [HK98] illustrate cases in which the "Constant-Rate" policy largely corrects the bias against long RTT connections, although [HK98] presents some evidence that such a policy may be difficult to incrementally deploy in an operational network. The proper selection of a constant (for the constant rate of increase) is an open issue.
[Flo91，HK98]研究了“固定利率”增长政策。它试图均衡TCP发送方在避免拥塞期间增加其发送速率的速率。[Flo91]和[HK98]都说明了“固定费率”政策在很大程度上纠正了对长RTT连接的偏见的情况，尽管[HK98]提供了一些证据，表明这种政策可能难以在运营网络中逐步部署。正确选择常数（对于恒定增长率）是一个悬而未决的问题。
The "Increase-by-K" policy can be selectively used by long RTT connections in a heterogeneous environment. This policy simply changes the slope of the linear increase, with connections over a given RTT threshold adding "K" segments to the congestion window every RTT, instead of one. [HK98] presents evidence that this policy, when used with small values of "K", may be successful in reducing the unfairness while keeping the link utilization high, when a small number of connections share a bottleneck link. The selection of the constant "K," the RTT threshold to invoke this policy, and performance under a large number of flows are all open issues.
异构环境中的长RTT连接可以有选择地使用“按K增加”策略。此策略只是改变线性增加的斜率，超过给定RTT阈值的连接会在每个RTT向拥塞窗口添加“K”个段，而不是一个。[HK98]表明，当与较小的“K”值一起使用时，当少量连接共享瓶颈链路时，此策略可以成功减少不公平性，同时保持链路利用率高。常数“K”的选择、调用此策略的RTT阈值以及大量流下的性能都是公开的问题。
Implementation of either the "Constant-Rate" or "Increase-by-K" policies requires a change to the congestion avoidance mechanism at the TCP sender. In the case of "Constant-Rate," such a change must be implemented globally. Additionally, the TCP sender must have a reasonably accurate estimate of the RTT of the connection. The algorithms outlined above violate the congestion avoidance algorithm as outlined in RFC 2581 [APS99] and therefore should not be implemented in shared networks at this time.
“恒定速率”或“按K递增”策略的实施需要更改TCP发送方的拥塞避免机制。在“固定利率”的情况下，这种变化必须在全球范围内实施。此外，TCP发送方必须对连接的RTT有一个合理准确的估计。上述算法违反RFC 2581[APS99]中概述的拥塞避免算法，因此目前不应在共享网络中实施。
These solutions are applicable to all satellite networks that are integrated with a terrestrial network, in which satellite connections may be competing with terrestrial connections for the same bottleneck link.
这些解决方案适用于与地面网络集成的所有卫星网络，其中卫星连接可能与地面连接竞争相同的瓶颈链路。
As shown in [PADHV99], increasing the congestion window by multiple segments per RTT can cause TCP to drop multiple segments and force a retransmission timeout in some versions of TCP. Therefore, the above changes to the congestion avoidance algorithm may need to be accompanied by a SACK-based loss recovery algorithm that can quickly repair multiple dropped segments.
如[PADHV99]所示，在某些版本的TCP中，将拥塞窗口增加每个RTT多个段可能会导致TCP丢弃多个段并强制重新传输超时。因此，对拥塞避免算法的上述更改可能需要伴随基于SACK的丢失恢复算法，该算法可以快速修复多个丢弃的段。
One method that has been used to overcome TCP's inefficiencies in the satellite environment is to use multiple TCP flows to transfer a given file. The use of N TCP connections makes the sender N times more aggressive and therefore can improve throughput in some situations. Using N multiple TCP connections can impact the transfer and the network in a number of ways, which are listed below.
在卫星环境中，用来克服TCP效率低下的一种方法是使用多个TCP流来传输给定的文件。使用N个TCP连接使发送方的攻击性提高了N倍，因此在某些情况下可以提高吞吐量。使用多个TCP连接可能会以多种方式影响传输和网络，如下所示。
1. The transfer is able to start transmission using an effective congestion window of N segments, rather than a single segment as one TCP flow uses. This allows the transfer to more quickly increase the effective cwnd size to an appropriate size for the given network. However, in some circumstances an initial window of N segments is inappropriate for the network conditions. In this case, a transfer utilizing more than one connection may aggravate congestion.
1. 传输能够使用N个段的有效拥塞窗口开始传输，而不是像TCP流使用的单个段。这允许传输更快地将有效cwnd大小增加到给定网络的适当大小。然而，在某些情况下，N段的初始窗口不适合网络条件。在这种情况下，使用多个连接的传输可能会加剧拥塞。
2. During the congestion avoidance phase, the transfer increases the effective cwnd by N segments per RTT, rather than the one segment per RTT increase that a single TCP connection provides. Again, this can aid the transfer by more rapidly increasing the effective cwnd to an appropriate point. However, this rate of increase can also be too aggressive for the network conditions. In this case, the use of multiple data connections can aggravate congestion in the network.
2. 在拥塞避免阶段，传输会将有效cwnd每RTT增加N个段，而不是单个TCP连接提供的每RTT增加一个段。同样，这可以通过更快速地将有效cwnd增加到适当的点来帮助传输。然而，对于网络条件而言，这种增长率也可能过于激进。在这种情况下，使用多个数据连接会加剧网络中的拥塞。
3. Using multiple connections can provide a very large overall congestion window. This can be an advantage for TCP implementations that do not support the TCP window scaling extension [JBB92]. However, the aggregate cwnd size across all N connections is equivalent to using a TCP implementation that supports large windows.
3. 使用多个连接可以提供非常大的整体拥塞窗口。这对于不支持TCP窗口扩展[JBB92]的TCP实现来说是一个优势。但是，跨所有N个连接的聚合cwnd大小相当于使用支持大型窗口的TCP实现。
4. The overall cwnd decrease in the face of dropped segments is reduced when using N parallel connections. A single TCP connection reduces the effective size of cwnd to half when a single segment loss is detected. When utilizing N connections each using a window of W bytes, a single drop reduces the window to:
4. 当使用N个并行连接时，下降段表面的总cwnd减少量减少。当检测到单个网段丢失时，单个TCP连接会将cwnd的有效大小减少一半。当使用N个连接（每个连接使用一个W字节的窗口）时，一次拖放可将窗口缩短为：
(N * W) - (W / 2)
(N * W) - (W / 2)
Clearly this is a less dramatic reduction in the effective cwnd size than when using a single TCP connection. And, the amount by which the cwnd is decreased is further reduced by increasing N.
显然，与使用单个TCP连接时相比，有效cwnd大小的减少不太明显。并且，通过增加N，cwnd的减少量进一步减少。
The use of multiple data connections can increase the ability of non-SACK TCP implementations to quickly recover from multiple dropped segments without resorting to a timeout, assuming the dropped segments cross connections.
使用多个数据连接可以提高非SACK TCP实现从多个丢弃的段中快速恢复的能力，而无需诉诸超时（假设丢弃的段交叉连接）。
The use of multiple parallel connections makes TCP overly aggressive for many environments and can contribute to congestive collapse in shared networks [FF99]. The advantages provided by using multiple TCP connections are now largely provided by TCP extensions (larger windows, SACKs, etc.). Therefore, the use of a single TCP connection is more "network friendly" than using multiple parallel connections. However, using multiple parallel TCP connections may provide performance improvement in private networks.
多个并行连接的使用使得TCP在许多环境中过于激进，并可能导致共享网络中的拥塞崩溃[FF99]。使用多个TCP连接提供的优势现在主要由TCP扩展（较大的窗口、SACK等）提供。因此，使用单个TCP连接比使用多个并行连接更“网络友好”。然而，使用多个并行TCP连接可以提高专用网络的性能。
Research on the use of multiple parallel TCP connections shows improved performance [IL92,Hah94,AOK95,AKO96]. In addition, research has shown that multiple TCP connections can outperform a single modern TCP connection (with large windows and SACK) [AHKO97]. However, these studies did not consider the impact of using multiple TCP connections on competing traffic. [FF99] argues that using multiple simultaneous connections to transfer a given file may lead to congestive collapse in shared networks.
对使用多个并行TCP连接的研究表明，性能有所提高[IL92、Hah94、AOK95、AKO96]。此外，研究表明，多个TCP连接的性能优于单个现代TCP连接（具有大窗口和SACK）[AHKO97]。然而，这些研究没有考虑使用多个TCP连接对竞争流量的影响。[FF99]认为，使用多个同时连接传输给定文件可能会导致共享网络中的拥塞崩溃。
To utilize multiple parallel TCP connections a client application and the corresponding server must be customized. As outlined in [FF99] using multiple parallel TCP connections is not safe (from a congestion control perspective) in shared networks and should not be used.
要利用多个并行TCP连接，必须自定义客户端应用程序和相应的服务器。如[FF99]中所述，在共享网络中使用多个并行TCP连接是不安全的（从拥塞控制的角度来看），因此不应使用。
As stated above, [FF99] outlines that the use of multiple parallel connections in a shared network, such as the Internet, may lead to congestive collapse. However, the use of multiple connections may be safe and beneficial in private networks. The specific topology being used will dictate the number of parallel connections required. Some work has been done to determine the appropriate number of connections on the fly [AKO96], but such a mechanism is far from complete.
如上所述，[FF99]概述了在共享网络（如互联网）中使用多个并行连接可能导致拥塞崩溃。然而，在专用网络中使用多个连接可能是安全和有益的。所使用的特定拓扑将决定所需的并行连接数。已经做了一些工作来确定动态连接的适当数量[AKO96]，但这样的机制还远未完成。
Using multiple concurrent TCP connections enables use of a large congestion window, much like the TCP window scaling option [JBB92]. In addition, a larger initial congestion window is achieved, similar to using [AFP98] or TCB sharing (see section 3.8).
使用多个并发TCP连接可以使用较大的拥塞窗口，很像TCP窗口缩放选项[JBB92]。此外，与使用[AFP98]或TCB共享类似，实现了更大的初始拥塞窗口（见第3.8节）。
Slow-start takes several round trips to fully open the TCP congestion window over routes with high bandwidth-delay products. For short TCP connections (such as WWW traffic with HTTP/1.0), the slow-start overhead can preclude effective use of the high-bandwidth satellite links. When senders implement slow-start restart after a TCP connection goes idle (suggested by Jacobson and Karels [JK92]),
慢启动需要多次往返才能在具有高带宽延迟产品的路由上完全打开TCP拥塞窗口。对于短TCP连接（如HTTP/1.0的WWW流量），缓慢的启动开销可能会妨碍有效使用高带宽卫星链路。当发送方在TCP连接空闲后执行慢速启动重启时（由Jacobson和Karels[JK92]建议），
performance is reduced in long-lived (but bursty) connections (such as HTTP/1.1, which uses persistent TCP connections to transfer multiple WWW page elements) [Hei97a].
长寿命（但突发性）连接（如HTTP/1.1，它使用持久TCP连接传输多个WWW页面元素）会降低性能[Hei97a]。
Rate-based pacing (RBP) is a technique, used in the absence of incoming ACKs, where the data sender temporarily paces TCP segments at a given rate to restart the ACK clock. Upon receipt of the first ACK, pacing is discontinued and normal TCP ACK clocking resumes. The pacing rate may either be known from recent traffic estimates (when restarting an idle connection or from recent prior connections), or may be known through external means (perhaps in a point-to-point or point-to-multipoint satellite network where available bandwidth can be assumed to be large).
基于速率的调整（RBP）是一种技术，在没有传入ACK的情况下使用，其中数据发送方以给定速率临时调整TCP段的速度，以重新启动ACK时钟。收到第一个ACK后，停止起搏，恢复正常TCP ACK时钟。可以通过最近的流量估计（当重新启动空闲连接时或通过最近的先前连接时）了解速度，也可以通过外部手段了解速度（可能在可用带宽较大的点对点或点对多点卫星网络中）。
In addition, pacing data during the first RTT of a transfer may allow TCP to make effective use of high bandwidth-delay links even for short transfers. However, in order to pace segments during the first RTT a TCP will have to be using a non-standard initial congestion window and a new mechanism to pace outgoing segments rather than send them back-to-back. Determining an appropriate size for the initial cwnd is an open research question. Pacing can also be used to reduce bursts in general (due to buggy TCPs or byte counting, see section 3.2.2 for a discussion on byte counting).
此外，在传输的第一个RTT期间对数据进行调整可以允许TCP有效地利用高带宽延迟链路，即使对于短传输也是如此。然而，为了在第一次RTT期间调整段的速度，TCP必须使用非标准的初始拥塞窗口和一种新机制来调整传出段的速度，而不是将它们背靠背发送。确定初始cwnd的合适大小是一个开放的研究问题。通常情况下，也可以使用起搏来减少突发（由于TCP或字节计数有问题，有关字节计数的讨论，请参见第3.2.2节）。
Simulation studies of rate-paced pacing for WWW-like traffic have shown reductions in router congestion and drop rates [VH97a]. In this environment, RBP substantially improves performance compared to slow-start-after-idle for intermittent senders, and it slightly improves performance over burst-full-cwnd-after-idle (because of drops) [VH98]. More recently, pacing has been suggested to eliminate burstiness in networks with ACK filtering [BPK97].
对类似WWW流量的速率起搏的模拟研究表明，路由器拥塞和丢包率降低[VH97a]。在这种环境下，对于间歇发送器，RBP与空闲后的慢速启动相比，显著提高了性能，并且在空闲后的突发全cwnd上，RBP略微提高了性能（因为下降）[VH98]。最近，有人建议通过ACK过滤消除网络中的突发性[BPK97]。
RBP requires only sender-side changes to TCP. Prototype implementations of RBP are available [VH97b]. RBP requires an additional sender timer for pacing. The overhead of timer-driven data transfer is often considered too high for practical use. Preliminary experiments suggest that in RBP this overhead is minimal because RBP only requires this timer for one RTT of transmission [VH98]. RBP is expected to make TCP more conservative in sending bursts of data after an idle period in hosts that do not revert to slow start after an idle period. On the other hand, RBP makes TCP more aggressive if the sender uses the slow start algorithm to start the ACK clock after a long idle period.
RBP只需要对TCP进行发送方更改。RBP的原型实现可用[VH97b]。RBP需要一个额外的发送方计时器进行起搏。计时器驱动的数据传输的开销通常被认为对于实际使用来说过高。初步实验表明，在RBP中，这种开销是最小的，因为RBP只需要一个RTT传输的计时器[VH98]。RBP预计将使TCP在空闲期后发送突发数据时更加保守，因为在空闲期后主机不会恢复为慢速启动。另一方面，如果发送方在长时间空闲后使用慢启动算法启动ACK时钟，RBP会使TCP更具攻击性。
RBP could be used to restart idle TCP connections for all topologies in Section 2. Use at the beginning of new connections would be restricted to topologies where available bandwidth can be estimated out-of-band.
RBP可用于重新启动第2节中所有拓扑的空闲TCP连接。新连接开始时的使用将仅限于可以估计带外可用带宽的拓扑。
Pacing segments may benefit from sharing state amongst various flows between two hosts, due to the time required to determine the needed information. Additionally, pacing segments, rather than sending back-to-back segments, may make estimating the available bandwidth (as outlined in section 3.2.4) more difficult.
由于确定所需信息所需的时间，两台主机之间的各种流之间共享状态可能会使起搏段受益。此外，起搏段（而不是发送背靠背段）可能会使估计可用带宽（如第3.2.4节所述）更加困难。
The TCP and IP header information needed to reliably deliver packets to a remote site across the Internet can add significant overhead, especially for interactive applications. Telnet packets, for example, typically carry only a few bytes of data per packet, and standard IPv4/TCP headers add at least 40 bytes to this; IPv6/TCP headers add at least 60 bytes. Much of this information remains relatively constant over the course of a session and so can be replaced by a short session identifier.
通过Internet将数据包可靠地传送到远程站点所需的TCP和IP报头信息可能会增加大量开销，尤其是对于交互式应用程序。例如，Telnet数据包通常每个数据包只携带几个字节的数据，而标准的IPv4/TCP报头至少为此添加了40个字节；IPv6/TCP标头至少添加60个字节。大部分信息在会话过程中保持相对恒定，因此可以用短会话标识符替换。
Many fields in the TCP and IP headers either remain constant during the course of a session, change very infrequently, or can be inferred from other sources. For example, the source and destination addresses, as well as the IP version, protocol, and port fields generally do not change during a session. Packet length can be deduced from the length field of the underlying link layer protocol provided that the link layer packet is not padded. Packet sequence numbers in a forward data stream generally change with every packet, but increase in a predictable manner.
TCP和IP头中的许多字段要么在会话过程中保持不变，要么很少更改，或者可以从其他来源推断。例如，源地址和目标地址以及IP版本、协议和端口字段在会话期间通常不会更改。如果链路层数据包没有填充，则可以从底层链路层协议的长度字段推断数据包长度。前向数据流中的数据包序列号通常随每个数据包而变化，但以可预测的方式增加。
The TCP/IP header compression methods described in [DNP99,DENP97,Jac90] reduce the overhead of TCP sessions by replacing the data in the TCP and IP headers that remains constant, changes slowly, or changes in a predictable manner with a short "connection number". Using this method, the sender first sends a full TCP/IP header, including in it a connection number that the sender will use to reference the connection. The receiver stores the full header and uses it as a template, filling in some fields from the limited
[DNP99、DENP97、Jac90]中描述的TCP/IP报头压缩方法通过将TCP和IP报头中保持不变、变化缓慢或以可预测方式变化的数据替换为短“连接号”来减少TCP会话的开销。使用此方法，发送方首先发送完整的TCP/IP头，其中包括发送方将用于引用连接的连接号。接收者存储完整的标题并将其用作模板，从有限的标题中填充一些字段
information contained in later, compressed headers. This compression can reduce the size of an IPv4/TCP headers from 40 to as few as 3 to 5 bytes (3 bytes for some common cases, 5 bytes in general).
稍后压缩的标题中包含的信息。这种压缩可以将IPv4/TCP报头的大小从40个字节减少到3到5个字节（在某些常见情况下为3个字节，通常为5个字节）。
Compression and decompression generally happen below the IP layer, at the end-points of a given physical link (such as at two routers connected by a serial line). The hosts on either side of the physical link must maintain some state about the TCP connections that are using the link.
压缩和解压缩通常发生在IP层之下，在给定物理链路的端点（例如通过串行线连接的两个路由器）。物理链路两侧的主机必须保持使用该链路的TCP连接的某些状态。
The decompresser must pass complete, uncompressed packets to the IP layer. Thus header compression is transparent to routing, for example, since an incoming packet with compressed headers is expanded before being passed to the IP layer.
解压器必须将完整的未压缩数据包传递到IP层。因此，报头压缩对路由是透明的，例如，因为具有压缩报头的传入数据包在被传递到IP层之前被扩展。
A variety of methods can be used by the compressor/decompressor to negotiate the use of header compression. For example, the PPP serial line protocol allows for an option exchange, during which time the compressor/decompressor agree on whether or not to use header compression. For older SLIP implementations, [Jac90] describes a mechanism that uses the first bit in the IP packet as a flag.
压缩器/解压缩器可以使用多种方法来协商标头压缩的使用。例如，PPP串行线协议允许选项交换，在此期间，压缩器/解压缩器就是否使用报头压缩达成一致。对于较旧的SLIP实现，[Jac90]描述了一种使用IP数据包中的第一位作为标志的机制。
The reduction in overhead is especially useful when the link is bandwidth-limited such as terrestrial wireless and mobile satellite links, where the overhead associated with transmitting the header bits is nontrivial. Header compression has the added advantage that for the case of uniformly distributed bit errors, compressing TCP/IP headers can provide a better quality of service by decreasing the packet error probability. The shorter, compressed packets are less likely to be corrupted, and the reduction in errors increases the connection's throughput.
当链路是带宽受限的（例如地面无线和移动卫星链路）时，开销的减少尤其有用，其中与发送报头比特相关联的开销是不平凡的。报头压缩的另一个优点是，对于均匀分布的比特错误，压缩TCP/IP报头可以通过降低分组错误概率来提供更好的服务质量。较短的压缩数据包不太可能被破坏，错误的减少增加了连接的吞吐量。
Extra space is saved by encoding changes in fields that change relatively slowly by sending only their difference from their values in the previous packet instead of their absolute values. In order to decode headers compressed this way, the receiver keeps a copy of each full, reconstructed TCP header after it is decoded, and applies the delta values from the next decoded compressed header to the reconstructed full header template.
对字段中的更改进行编码可以节省额外的空间，这些字段的更改相对较慢，只发送它们与上一个数据包中的值的差异，而不是绝对值。为了解码以这种方式压缩的报头，接收器在解码后保留每个完整的重构TCP报头的副本，并将来自下一个解码的压缩报头的增量值应用于重构的完整报头模板。
A disadvantage to using this delta encoding scheme where values are encoded as deltas from their values in the previous packet is that if a single compressed packet is lost, subsequent packets with compressed headers can become garbled if they contain fields which depend on the lost packet. Consider a forward data stream of packets with compressed headers and increasing sequence numbers. If packet N is lost, the full header of packet N+1 will be reconstructed at the receiver using packet N-1's full header as a template. Thus the
使用这种增量编码方案的缺点是，如果单个压缩数据包丢失，则具有压缩头的后续数据包如果包含依赖于丢失的数据包的字段，则可能会变得混乱，在这种情况下，值被编码为前一个数据包中值的增量。考虑具有压缩报头和增加序列号的分组的前向数据流。如果分组N丢失，则分组N+1的完整报头将在接收器处使用分组N-1的完整报头作为模板来重构。因此
sequence number, which should have been calculated from packet N's header, will be wrong, the checksum will fail, and the packet will be discarded. When the sending TCP times out and retransmits a packet with a full header is forwarded to re-synchronize the decompresser.
根据数据包N的报头计算出的序列号将是错误的，校验和将失败，数据包将被丢弃。当发送TCP超时并重新传输具有完整报头的数据包时，将转发该数据包以重新同步解压器。
It is important to note that the compressor does not maintain any timers, nor does the decompresser know when an error occurred (only the receiving TCP knows this, when the TCP checksum fails). A single bit error will cause the decompresser to lose sync, and subsequent packets with compressed headers will be dropped by the receiving TCP, since they will all fail the TCP checksum. When this happens, no duplicate acknowledgments will be generated, and the decompresser can only re-synchronize when it receives a packet with an uncompressed header. This means that when header compression is being used, both fast retransmit and selective acknowledgments will not be able correct packets lost on a compressed link. The "twice" algorithm, described below, may be a partial solution to this problem.
需要注意的是，压缩器不维护任何计时器，解压器也不知道何时发生错误（当TCP校验和失败时，只有接收TCP知道这一点）。一个位错误将导致解压器失去同步，随后带有压缩头的数据包将被接收TCP丢弃，因为它们都将使TCP校验和失败。发生这种情况时，不会生成重复的确认，并且解压器只能在接收到带有未压缩头的数据包时重新同步。这意味着，当使用报头压缩时，快速重传和选择性确认将无法纠正压缩链路上丢失的数据包。下面描述的“两次”算法可能是该问题的部分解决方案。
[DNP99] and [DENP97] describe TCP/IPv4 and TCP/IPv6 compression algorithms including compressing the various IPv6 extension headers as well as methods for compressing non-TCP streams. [DENP97] also augments TCP header compression by introducing the "twice" algorithm. If a particular packet fails to decompress properly, the twice algorithm modifies its assumptions about the inferred fields in the compressed header, assuming that a packet identical to the current one was dropped between the last correctly decoded packet and the current one. Twice then tries to decompress the received packet under the new assumptions and, if the checksum passes, the packet is passed to IP and the decompresser state has been re-synchronized. This procedure can be extended to three or more decoding attempts. Additional robustness can be achieved by caching full copies of packets which don't decompress properly in the hopes that later arrivals will fix the problem. Finally, the performance improvement if the decompresser can explicitly request a full header is discussed. Simulation results show that twice, in conjunction with the full header request mechanism, can improve throughput over uncompressed streams.
[DNP99]和[DENP97]描述了TCP/IPv4和TCP/IPv6压缩算法，包括压缩各种IPv6扩展头以及压缩非TCP流的方法。[DENP97]还通过引入“两次”算法来增强TCP报头压缩。如果特定数据包未能正确解压缩，则两次算法修改其关于压缩报头中推断字段的假设，假设与当前数据包相同的数据包在最后一个正确解码的数据包和当前数据包之间被丢弃。然后两次尝试在新的假设下解压缩接收到的数据包，如果校验和通过，则数据包被传递到IP，并且解压缩器状态已重新同步。此过程可以扩展到三次或更多解码尝试。通过缓存未正确解压缩的数据包的完整副本，可以实现额外的健壮性，希望稍后到达的数据包能够解决问题。最后，讨论了如果解压器可以显式地请求完整的报头，那么性能的改进。仿真结果表明，两次加上全报头请求机制，可以提高未压缩流的吞吐量。
[Jac90] outlines a simple header compression scheme for TCP/IP.
[Jac90]概述了一个简单的TCP/IP报头压缩方案。
In [DENP97] the authors present the results of simulations showing that header compression is advantageous for both low and medium bandwidth links. Simulations show that the twice algorithm, combined with an explicit header request mechanism, improved throughput by 10-15% over uncompressed sessions across a wide range of bit error rates.
在[DENP97]中，作者给出了模拟结果，表明报头压缩对于低带宽和中等带宽链路都是有利的。仿真结果表明，两次算法与显式报头请求机制相结合，在大范围的误码率下，在未压缩会话上提高了10-15%的吞吐量。
Much of this improvement may have been due to the twice algorithm quickly re-synchronizing the decompresser when a packet is lost. This is because the twice algorithm, applied one or two times when the decompresser becomes unsynchronized, will re-sync the decompresser in between 83% and 99% of the cases examined. This means that packets received correctly after twice has resynchronized the decompresser will cause duplicate acknowledgments. This re-enables the use of both fast retransmit and SACK in conjunction with header compression.
这种改进很大程度上可能是由于两次算法在数据包丢失时快速重新同步解压器。这是因为当解压器变得不同步时，两次算法应用一次或两次，将在83%到99%的检查案例中重新同步解压器。这意味着两次重新同步解压器后正确接收的数据包将导致重复确认。这重新启用了快速重传和SACK与报头压缩的结合使用。
Implementing TCP/IP header compression requires changes at both the sending (compressor) and receiving (decompresser) ends of each link that uses compression. The twice algorithm requires very little extra machinery over and above header compression, while the explicit header request mechanism of [DENP97] requires more extensive modifications to the sending and receiving ends of each link that employs header compression. Header compression does not violate TCP's congestion control mechanisms and therefore can be safely implemented in shared networks.
实现TCP/IP报头压缩需要在使用压缩的每个链路的发送（压缩器）和接收（解压缩器）端进行更改。除了报头压缩之外，二次算法只需要很少的额外机器，而[DENP97]的显式报头请求机制需要对采用报头压缩的每个链路的发送端和接收端进行更广泛的修改。报头压缩不会违反TCP的拥塞控制机制，因此可以在共享网络中安全地实现。
TCP/IP header compression is applicable to all of the environments discussed in section 2, but will provide relatively more improvement in situations where packet sizes are small (i.e., overhead is large) and there is medium to low bandwidth and/or higher BER. When TCP's congestion window size is large, implementing the explicit header request mechanism, the twice algorithm, and caching packets which fail to decompress properly becomes more critical.
TCP/IP报头压缩适用于第2节中讨论的所有环境，但在数据包大小较小（即开销较大）且存在中低带宽和/或更高BER的情况下，将提供相对更多的改进。当TCP的拥塞窗口较大时，实现显式报头请求机制、二次算法和缓存无法正确解压缩的数据包变得更为关键。
As discussed above, losing synchronization between a sender and receiver can cause many packet drops. The frequency of losing synchronization and the effectiveness of the twice algorithm may point to using a SACK-based loss recovery algorithm to reduce the impact of multiple lost segments. However, even very robust SACK-based algorithms may not work well if too many segments are lost.
如上所述，发送方和接收方之间的同步丢失可能会导致许多数据包丢失。失去同步的频率和二次算法的有效性可能表明使用基于SACK的丢失恢复算法来减少多个丢失段的影响。然而，如果丢失太多的数据段，即使是非常健壮的基于SACK的算法也可能无法很好地工作。
Persistent TCP state information can be used to overcome limitations in the configuration of the initial state, and to automatically tune TCP to environments using satellite links and to coordinate multiple TCP connections sharing a satellite link.
持久TCP状态信息可用于克服初始状态配置中的限制，并自动将TCP调整到使用卫星链路的环境中，以及协调共享卫星链路的多个TCP连接。
TCP includes a variety of parameters, many of which are set to initial values which can severely affect the performance of TCP connections traversing satellite links, even though most TCP parameters are adjusted later after the connection is established. These parameters include initial size of cwnd and initial MSS size. Various suggestions have been made to change these initial conditions, to more effectively support satellite links. However, it is difficult to select any single set of parameters which is effective for all environments.
TCP包含多种参数，其中许多参数设置为初始值，这会严重影响通过卫星链路的TCP连接的性能，即使大多数TCP参数在连接建立后会进行调整。这些参数包括cwnd的初始尺寸和MSS的初始尺寸。人们提出了各种各样的建议来改变这些初始条件，以便更有效地支持卫星链路。然而，很难选择任何一组对所有环境都有效的参数。
An alternative to attempting to select these parameters a-priori is sharing state across TCP connections and using this state when initializing a new connection. For example, if all connections to a subnet result in extended congestion windows of 1 megabyte, it is probably more efficient to start new connections with this value, than to rediscover it by requiring the cwnd to increase using slow start over a period of dozens of round-trip times.
尝试预先选择这些参数的另一种方法是跨TCP连接共享状态，并在初始化新连接时使用此状态。例如，如果到子网的所有连接都会导致1兆字节的拥塞窗口延长，则使用此值启动新连接可能比通过要求cwnd在数十次往返时间内使用慢速启动来增加以重新发现它更有效。
Sharing state among connections brings up a number of questions such as what information to share, with whom to share, how to share it, and how to age shared information. First, what information is to be shared must be determined. Some information may be appropriate to share among TCP connections, while some information sharing may be inappropriate or not useful. Next, we need to determine with whom to share information. Sharing may be appropriate for TCP connections sharing a common path to a given host. Information may be shared among connections within a host, or even among connections between different hosts, such as hosts on the same LAN. However, sharing information between connections not traversing the same network may not be appropriate. Given the state to share and the parties that share it, a mechanism for the sharing is required. Simple state, like MSS and RTT, is easy to share, but congestion window information can be shared a variety of ways. The sharing mechanism determines priorities among the sharing connections, and a variety of fairness criteria need to be considered. Also, the mechanisms by which information is aged require further study. See RFC 2140 for a discussion of the security issues in both sharing state within a single host and sharing state among hosts on a subnet. Finally, the security concerns associated with sharing a piece of information need
在连接之间共享状态会带来许多问题，例如共享什么信息、与谁共享、如何共享以及如何对共享信息进行老化。首先，必须确定共享哪些信息。有些信息可能适合在TCP连接之间共享，而有些信息共享可能不合适或没有用处。接下来，我们需要确定与谁共享信息。共享可能适用于共享到给定主机的公共路径的TCP连接。信息可以在主机内的连接之间共享，甚至在不同主机之间的连接之间共享，例如在同一局域网上的主机。但是，在不穿越同一网络的连接之间共享信息可能不合适。鉴于分享的国家和分享的各方，需要一种分享机制。简单状态，如MSS和RTT，很容易共享，但拥塞窗口信息可以通过多种方式共享。共享机制决定了共享连接之间的优先级，需要考虑各种公平性标准。此外，信息老化的机制还需要进一步研究。有关单个主机内共享状态和子网上主机间共享状态的安全问题的讨论，请参阅RFC 2140。最后，与共享信息相关的安全问题需要
to be carefully considered before introducing such a mechanism. Many of these open research questions must be answered before state sharing can be widely deployed.
在引入这一机制之前必须仔细考虑。在广泛部署状态共享之前，必须回答许多这些开放性研究问题。
The opportunity for such sharing, both among a sequence of connections, as well as among concurrent connections, is described in more detail in [Tou97]. The state management itself is largely an implementation issue, however what information should be shared and the specific ways in which the information should be shared is an open question.
[97]中更详细地描述了在连接序列之间以及在并发连接之间进行这种共享的机会。国家管理本身在很大程度上是一个实施问题，但是应该共享哪些信息以及共享信息的具体方式是一个悬而未决的问题。
Sharing parts of the TCB state was originally documented in T/TCP [Bra92], and is used there to aggregate RTT values across connection instances, to provide meaningful average RTTs, even though most connections are expected to persist for only one RTT. T/TCP also shares a connection identifier, a sequence number separate from the window number and address/port pairs by which TCP connections are typically distinguished. As a result of this shared state, T/TCP allows a receiver to pass data in the SYN segment to the receiving application, prior to the completion of the three-way handshake, without compromising the integrity of the connection. In effect, this shared state caches a partial handshake from the previous connection, which is a variant of the more general issue of TCB sharing.
TCB状态的共享部分最初记录在T/TCP[Bra92]中，并在那里用于跨连接实例聚合RTT值，以提供有意义的平均RTT，即使大多数连接预计只会持续一个RTT。T/TCP还共享一个连接标识符，一个与窗口号和地址/端口对分离的序列号，TCP连接通常通过该序列号和地址/端口对进行区分。作为这种共享状态的结果，T/TCP允许接收器在完成三向握手之前将SYN段中的数据传递给接收应用程序，而不会影响连接的完整性。实际上，此共享状态缓存来自上一个连接的部分握手，这是TCB共享更一般问题的变体。
Sharing state among connections (including transfers using non-TCP protocols) is further investigated in [BRS99].
[BRS99]进一步研究了连接之间的共享状态（包括使用非TCP协议的传输）。
Sharing TCP state across connections requires changes to the sender's TCP stack, and possibly the receiver's TCP stack (as in the case of T/TCP, for example). Sharing TCP state may make a particular TCP connection more aggressive. However, the aggregate traffic should be more conservative than a group of independent TCP connections. Therefore, sharing TCP state should be safe for use in shared networks. Note that state sharing does not present any new security problems within multiuser hosts. In such a situation, users can steal network resources from one another with or without state sharing.
跨连接共享TCP状态需要更改发送方的TCP堆栈，可能还需要更改接收方的TCP堆栈（例如T/TCP）。共享TCP状态可能会使特定TCP连接更具攻击性。但是，聚合流量应该比一组独立的TCP连接更加保守。因此，在共享网络中使用共享TCP状态应该是安全的。请注意，状态共享不会在多用户主机中出现任何新的安全问题。在这种情况下，用户可以通过状态共享或不通过状态共享相互窃取网络资源。
It is expected that sharing state across TCP connections may be useful in all network environments presented in section 2.
在第2节中介绍的所有网络环境中，跨TCP连接共享状态都是有用的。
The state sharing outlined above is very similar to the Congestion Manager proposal [BRS99] that attempts to share congestion control information among both TCP and UDP flows between a pair of hosts.
上述状态共享与拥塞管理器方案[BRS99]非常相似，后者试图在一对主机之间的TCP和UDP流之间共享拥塞控制信息。
In highly asymmetric networks, a low-speed return link can restrict the performance of the data flow on a high-speed forward link by limiting the flow of acknowledgments returned to the data sender. For example, if the data sender uses 1500 byte segments, and the receiver generates 40 byte acknowledgments (IPv4, TCP without options), the reverse link will congest with ACKs for asymmetries of more than 75:1 if delayed ACKs are used, and 37:1 if every segment is acknowledged. For a 1.5 Mb/second data link, ACK congestion will occur for reverse link speeds below 20 kilobits/sec. These levels of asymmetry will readily occur if the reverse link is shared among multiple satellite receivers, as is common in many VSAT satellite networks. If a terrestrial modem link is used as a reverse link, ACK congestion is also likely, especially as the speed of the forward link is increased. Current congestion control mechanisms are aimed at controlling the flow of data segments, but do not affect the flow of ACKs.
在高度不对称的网络中，低速返回链路可以通过限制返回给数据发送方的确认流来限制高速前向链路上数据流的性能。例如，如果数据发送方使用1500字节的段，而接收方生成40字节的确认（IPv4、TCP，不带选项），则反向链路将拥塞，如果使用延迟确认，则不对称性超过75:1，如果每个段都得到确认，则不对称性超过37:1。对于1.5 Mb/秒的数据链路，反向链路速度低于20千比特/秒时将发生ACK拥塞。如果反向链路在多个卫星接收机之间共享，这些不对称程度将很容易发生，这在许多VSAT卫星网络中很常见。如果地面调制解调器链路用作反向链路，则也可能出现ACK拥塞，尤其是当正向链路的速度增加时。当前的拥塞控制机制旨在控制数据段的流量，但不影响ack的流量。
In [KVR98] the authors point out that the flow of acknowledgments can be restricted on the low-speed link not only by the bandwidth of the link, but also by the queue length of the router. The router may limit its queue length by counting packets, not bytes, and therefore begin discarding ACKs even if there is enough bandwidth to forward them.
在[KVR98]中，作者指出，在低速链路上，确认流不仅受到链路带宽的限制，还受到路由器队列长度的限制。路由器可能通过计算数据包而不是字节来限制其队列长度，因此，即使有足够的带宽转发ACK，也会开始丢弃ACK。
ACK Congestion Control extends the concept of flow control for data segments to acknowledgment segments. In the method described in [BPK97], any intermediate router can mark an acknowledgment with an Explicit Congestion Notification (ECN) bit once the queue occupancy in the router exceeds a given threshold. The data sender (which receives the acknowledgment) must "echo" the ECN bit back to the data receiver (see section 3.3.3 for a more detailed discussion of ECN). The proposed algorithm for marking ACK segments with an ECN bit is Random Early Detection (RED) [FJ93]. In response to the receipt of ECN marked data segments, the receiver will dynamically reduce the rate of acknowledgments using a multiplicative backoff. Once segments without ECN are received, the data receiver speeds up acknowledgments using a linear increase, up to a rate of either 1 (no
ACK拥塞控制将数据段的流量控制概念扩展到确认段。在[BPK97]中描述的方法中，一旦路由器中的队列占用超过给定阈值，任何中间路由器都可以使用显式拥塞通知（ECN）位标记确认。数据发送方（接收确认）必须将ECN位“回送”回数据接收方（有关ECN的更详细讨论，请参阅第3.3.3节）。提出的用ECN位标记ACK段的算法是随机早期检测（RED）[FJ93]。为了响应ECN标记数据段的接收，接收器将使用乘法退避动态降低确认率。一旦接收到不带ECN的段，数据接收器将使用线性增加来加快确认速度，最大速率为1（否
delayed ACKs) or 2 (normal delayed ACKs) data segments per ACK. The authors suggest that an ACK be generated at least once per window, and ideally a few times per window.
延迟确认）或每个确认2个（正常延迟确认）数据段。作者建议每个窗口至少生成一次ACK，最好是每个窗口生成几次。
As in the RED congestion control mechanism for data flow, the bottleneck gateway can randomly discard acknowledgments, rather than marking them with an ECN bit, once the queue fills beyond a given threshold.
与数据流的RED拥塞控制机制一样，一旦队列填充超过给定阈值，瓶颈网关可以随机丢弃确认，而不是用ECN位标记它们。
[BPK97] analyze the effect of ACK Congestion Control (ACC) on the performance of an asymmetric network. They note that the use of ACC, and indeed the use of any scheme which reduces the frequency of acknowledgments, has potential unwanted side effects. Since each ACK will acknowledge more than the usual one or two data segments, the likelihood of segment bursts from the data sender is increased. In addition, congestion window growth may be impeded if the receiver grows the window by counting received ACKs, as mandated by [Ste97,APS99]. The authors therefore combine ACC with a series of modifications to the data sender, referred to as TCP Sender Adaptation (SA). SA combines a limit on the number of segments sent in a burst, regardless of window size. In addition, byte counting (as opposed to ACK counting) is employed for window growth. Note that byte counting has been studied elsewhere and can introduce side-effects, as well [All98].
[BPK97]分析ACK拥塞控制（ACC）对非对称网络性能的影响。他们注意到，使用ACC，甚至使用任何减少确认频率的方案，都有潜在的不必要的副作用。由于每个ACK将确认多于通常的一个或两个数据段，因此来自数据发送方的段突发的可能性增加。此外，如果按照[Ste97，APS99]的规定，接收机通过计算接收到的ACK来增加窗口，则拥塞窗口的增长可能会受到阻碍。因此，作者将ACC与对数据发送方的一系列修改结合起来，称为TCP发送方自适应（SA）。SA结合了对突发发送的段数的限制，而与窗口大小无关。此外，字节计数（与ACK计数相反）用于窗口增长。请注意，字节计数已经在其他地方进行了研究，并且可能会引入副作用[All98]。
The results presented in [BPK97] indicate that using ACC and SA will reduce the bursts produced by ACK losses in unmodified (Reno) TCP. In cases where these bursts would lead to data loss at an intermediate router, the ACC and SA modification significantly improve the throughput for a single data transfer. The results further suggest that the use of ACC and SA significantly improve fairness between two simultaneous transfers.
[BPK97]中给出的结果表明，在未修改（Reno）TCP中，使用ACC和SA将减少因ACK丢失而产生的突发。在这些突发将导致中间路由器上的数据丢失的情况下，ACC和SA修改将显著提高单个数据传输的吞吐量。结果进一步表明，使用ACC和SA可以显著提高两次同时传输之间的公平性。
ACC is further reported to prevent the increase in round trip time (RTT) that occurs when an unmodified TCP fills the reverse router queue with acknowledgments.
进一步报告ACC可防止未经修改的TCP用确认信息填充反向路由器队列时出现的往返时间（RTT）增加。
In networks where the forward direction is expected to suffer losses in one of the gateways, due to queue limitations, the authors report at best a very slight improvement in performance for ACC and SA, compared to unmodified Reno TCP.
在网络中，由于队列限制，前向预计会在其中一个网关中遭受损失，作者报告，与未经修改的Reno TCP相比，ACC和SA的性能最多只略有改善。
Both ACC and SA require modification of the sending and receiving hosts, as well as the bottleneck gateway. The current research suggests that implementing ACC without the SA modifications results in a data sender which generates potentially disruptive segment bursts. It should be noted that ACC does require host modifications if it is implemented in the way proposed in [BPK97]. The authors note that ACC can be implemented by discarding ACKs (which requires only a gateway modification, but no changes in the hosts), as opposed to marking them with ECN. Such an implementation may, however, produce bursty data senders if it is not combined with a burst mitigation technique. ACC requires changes to the standard ACKing behavior of a receiving TCP and therefore is not recommended for use in shared networks.
ACC和SA都需要修改发送和接收主机以及瓶颈网关。当前的研究表明，在没有SA修改的情况下实施ACC会导致数据发送方产生潜在的中断性分段突发。应注意，如果按照[BPK97]中建议的方式实施，则ACC确实需要修改主机。作者指出，ACC可以通过丢弃ACK（只需要修改网关，但不需要更改主机）来实现，而不是用ECN标记它们。然而，如果这种实现没有与突发缓解技术相结合，则可能产生突发数据发送器。ACC要求更改接收TCP的标准确认行为，因此不建议在共享网络中使用。
Neither ACC nor SA require the storage of state in the gateway. These schemes should therefore be applicable for all topologies, provided that the hosts using the satellite or hybrid network can be modified. However, these changes are expected to be especially beneficial to networks containing asymmetric satellite links.
ACC和SA都不需要在网关中存储状态。因此，这些方案应适用于所有拓扑，前提是可以修改使用卫星或混合网络的主机。然而，这些变化预计对包含不对称卫星链路的网络特别有利。
Note that ECN is a pre-condition for using ACK congestion control. Additionally, the ACK Filtering algorithm discussed in the next section attempts to solve the same problem as ACC. Choosing between the two algorithms (or another mechanism) is currently an open research question.
注意，ECN是使用ACK拥塞控制的先决条件。此外，下一节讨论的ACK滤波算法试图解决与ACC相同的问题。在两种算法（或另一种机制）之间进行选择目前是一个开放的研究问题。
ACK Filtering (AF) is designed to address the same ACK congestion effects described in 3.9. Contrary to ACC, however, AF is designed to operate without host modifications.
ACK过滤（AF）旨在解决3.9中描述的相同ACK拥塞影响。然而，与ACC相反，AF设计为在不修改主机的情况下运行。
AF takes advantage of the cumulative acknowledgment structure of TCP. The bottleneck router in the reverse direction (the low speed link) must be modified to implement AF. Upon receipt of a segment which represents a TCP acknowledgment, the router scans the queue for redundant ACKs for the same connection, i.e. ACKs which acknowledge portions of the window which are included in the most recent ACK. All of these "earlier" ACKs are removed from the queue and discarded.
AF利用TCP的累积确认结构。反向（低速链路）的瓶颈路由器必须进行修改，以实现AF。在收到表示TCP确认的段后，路由器扫描队列，寻找同一连接的冗余确认，即确认最近确认中包括的窗口部分的确认。所有这些“早期”ACK都将从队列中删除并丢弃。
The router does not store state information, but does need to implement the additional processing required to find and remove segments from the queue upon receipt of an ACK.
路由器不存储状态信息，但需要执行在收到ACK后从队列中查找和删除段所需的附加处理。
[BPK97] analyzes the effects of AF. As is the case in ACC, the use of ACK filtering alone would produce significant sender bursts, since the ACKs will be acknowledging more previously-unacknowledged data. The SA modifications described in 3.9.2 could be used to prevent those bursts, at the cost of requiring host modifications. To prevent the need for modifications in the TCP stack, AF is more likely to be paired with the ACK Reconstruction (AR) technique, which can be implemented at the router where segments exit the slow reverse link.
[BPK97]分析AF的影响。与ACC的情况一样，单独使用ACK过滤将产生显著的发送方突发，因为应答将确认更多以前未确认的数据。3.9.2中描述的SA修改可用于防止这些突发，但需要修改主机。为了防止需要修改TCP堆栈，AF更可能与ACK重建（AR）技术配对，该技术可在段退出慢速反向链路的路由器上实现。
AR inspects ACKs exiting the link, and if it detects large "gaps" in the ACK sequence, it generates additional ACKs to reconstruct an acknowledgment flow which more closely resembles what the data sender would have seen had ACK Filtering not been introduced. AR requires two parameters; one parameter is the desired ACK frequency, while the second controls the spacing, in time, between the release of consecutive reconstructed ACKs.
AR检查退出链路的确认，如果它在确认序列中检测到较大的“间隙”，它将生成额外的确认，以重建确认流，该确认流与数据发送方在没有引入确认过滤的情况下所看到的更为相似。AR需要两个参数；一个参数是期望的ACK频率，而第二个参数控制连续重构ACK的释放之间的时间间隔。
In [BPK97], the authors show the combination of AF and AR to increase throughput, in the networks studied, over both unmodified TCP and the ACC/SA modifications. Their results also strongly suggest that the use of AF alone, in networks where congestion losses are expected, decreases performance (even below the level of unmodified TCP Reno) due to sender bursting.
在[BPK97]中，作者展示了在所研究的网络中，通过未修改的TCP和ACC/SA修改，AF和AR的组合可以提高吞吐量。他们的结果还强烈表明，在预期会出现拥塞损失的网络中，单独使用AF会由于发送方崩溃而降低性能（甚至低于未修改的TCP Reno水平）。
AF delays acknowledgments from arriving at the receiver by dropping earlier ACKs in favor of later ACKs. This process can cause a slight hiccup in the transmission of new data by the TCP sender.
AF通过放弃较早的确认而支持较晚的确认，从而延迟确认到达接收器。此过程可能会导致TCP发送方在传输新数据时出现轻微故障。
Both ACK Filtering and ACK Reconstruction require only router modification. However, the implementation of AR requires some storage of state information in the exit router. While AF does not require storage of state information, its use without AR (or SA) could produce undesired side effects. Furthermore, more research is required regarding appropriate ranges for the parameters needed in AR.
ACK滤波和ACK重建都只需要修改路由器。然而，AR的实现需要在出口路由器中存储一些状态信息。虽然AF不需要存储状态信息，但在没有AR（或SA）的情况下使用AF可能会产生不希望的副作用。此外，关于AR所需参数的适当范围，还需要进行更多的研究。
AF and AR appear applicable to all topologies, assuming that the storage of state information in AR does not prove to be prohibitive for routers which handle large numbers of flows. The fact that TCP stack modifications are not required for AF/AR makes this approach attractive for hybrid networks and networks with diverse types of hosts. These modifications, however, are expected to be most beneficial in asymmetric network paths.
AF和AR似乎适用于所有拓扑，假设AR中的状态信息存储对于处理大量流的路由器来说并不是禁止的。AF/AR不需要修改TCP堆栈，这一事实使得这种方法对于混合网络和具有不同类型主机的网络具有吸引力。然而，这些修改预计在不对称网络路径中最为有利。
On the other hand, the implementation of AF/AR requires the routers to examine the TCP header, which prohibits their use in secure networks where IPSEC is deployed. In such networks, AF/AR can be effective only inside the security perimeter of a private, or virtual private network, or in private networks where the satellite link is protected only by link-layer encryption (as opposed to IPSEC). ACK Filtering is safe to use in shared networks (from a congestion control point-of-view), as the number of ACKs can only be reduced, which makes TCP less aggressive. However, note that while TCP is less aggressive, the delays that AF induces (outlined above) can lead to larger bursts than would otherwise occur.
另一方面，AF/AR的实现要求路由器检查TCP报头，这禁止它们在部署IPSEC的安全网络中使用。在此类网络中，AF/AR只能在专用或虚拟专用网络的安全外围内有效，或者在专用网络中有效，其中卫星链路仅通过链路层加密（与IPSEC相反）进行保护。ACK过滤在共享网络中使用是安全的（从拥塞控制的角度来看），因为ACK的数量只能减少，这使得TCP的攻击性降低。但是，请注意，虽然TCP攻击性较小，但AF引起的延迟（如上所述）可能导致比其他情况下更大的突发。
ACK Filtering attempts to solve the same problem as ACK Congestion Control (as outlined in section 3.9). Which of the two algorithms is more appropriate is currently an open research question.
ACK过滤试图解决与ACK拥塞控制相同的问题（如第3.9节所述）。这两种算法中哪一种更合适是目前一个开放的研究问题。
4 Conclusions
4结论
This document outlines TCP items that may be able to mitigate the performance problems associated with using TCP in networks containing satellite links. These mitigations are not IETF standards track mechanisms and require more study before being recommended by the IETF. The research community is encouraged to examine the above mitigations in an effort to determine which are safe for use in shared networks such as the Internet.
本文档概述了能够缓解在包含卫星链路的网络中使用TCP相关性能问题的TCP项目。这些缓解措施不是IETF标准跟踪机制，需要在IETF推荐之前进行更多研究。鼓励研究界研究上述缓解措施，以确定在共享网络（如互联网）中使用哪些措施是安全的。
5 Security Considerations
5安全考虑
Several of the above sections noted specific security concerns which a given mitigation aggravates.
上述几节指出了特定缓解措施加剧的具体安全问题。
Additionally, any form of wireless communication link is more susceptible to eavesdropping security attacks than standard wire-based links due to the relative ease with which an attacker can watch the network and the difficultly in finding attackers monitoring the network.
此外，任何形式的无线通信链路都比标准的基于有线的链路更容易受到窃听安全攻击，因为攻击者可以相对轻松地监视网络，并且很难找到监视网络的攻击者。
6 Acknowledgments
6致谢
Our thanks to Aaron Falk and Sally Floyd, who provided very helpful comments on drafts of this document.
我们感谢Aaron Falk和Sally Floyd，他们对本文件草案提供了非常有用的意见。
7 References
7参考文献
[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月。
[AGS99] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[AGS99]Allman，M.，Glover，D.和L.Sanchez，“使用标准机制增强卫星信道上的TCP”，BCP 28，RFC 2488，1999年1月。
[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann. TCP Performance Over Satellite Links. In Proceedings of the 5th International Conference on Telecommunication Systems, March 1997.
[AHKO97]马克·奥尔曼、克里斯·海斯、汉斯·克鲁斯、肖恩·奥斯特曼。卫星链路上的TCP性能。1997年3月第五届国际电信系统会议记录。
[AHO98] Mark Allman, Chris Hayes, Shawn Ostermann. An Evaluation of TCP with Larger Initial Windows. Computer Communication Review, 28(3), July 1998.
[AHO98]马克·奥尔曼、克里斯·海斯、肖恩·奥斯特曼。具有较大初始窗口的TCP评估。《计算机通信评论》，1998年7月28日（3）。
[AKO96] Mark Allman, Hans Kruse, Shawn Ostermann. An Application-Level Solution to TCP's Satellite Inefficiencies. In Proceedings of the First International Workshop on Satellite-based Information Services (WOSBIS), November 1996.
[AKO96]马克·奥尔曼，汉斯·克鲁斯，肖恩·奥斯特曼。TCP卫星效率低下的应用程序级解决方案。1996年11月，第一届卫星信息服务国际研讨会论文集。
[All97a] Mark Allman. Improving TCP Performance Over Satellite Channels. Master's thesis, Ohio University, June 1997.
马克·奥尔曼。提高卫星信道上的TCP性能。俄亥俄大学硕士论文，1997年6月。
[All97b] Mark Allman. Fixing Two BSD TCP Bugs. Technical Report CR-204151, NASA Lewis Research Center, October 1997.
马克·奥尔曼。修复两个BSD TCP错误。技术报告CR-204151，美国宇航局刘易斯研究中心，1997年10月。
[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月。
[AOK95] Mark Allman, Shawn Ostermann, Hans Kruse. Data Transfer Efficiency Over Satellite Circuits Using a Multi-Socket Extension to the File Transfer Protocol (FTP). In Proceedings of the ACTS Results Conference, NASA Lewis Research Center, September 1995.
[AOK95]马克·奥尔曼、肖恩·奥斯特曼、汉斯·克鲁斯。使用文件传输协议（FTP）的多套接字扩展的卫星电路上的数据传输效率。1995年9月，美国宇航局刘易斯研究中心ACTS成果会议记录。
[AP99] Mark Allman, Vern Paxson. On Estimating End-to-End Network Path Properties. ACM SIGCOMM, September 1999.
[AP99]马克·奥尔曼，弗恩·帕克森。关于估计端到端网络路径属性。ACM SIGCOMM，1999年9月。
[APS99] Allman, M., Paxson, V. and W. Richard Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[APS99]Allman，M.，Paxson，V.和W.Richard Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[BCC+98] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, J. and L. Zhang, "Recommendations on Queue Management and Congestion Avoidance in the Internet", RFC 2309, April 1998.
[BCC+98]Braden，B.，Clark，D.，Crowcroft，J.，Davie，B.，Deering，S.，Estrin，D.，Floyd，S.，Jacobson，V.，Minshall，G.，Partridge，C.，Peterson，L.，Ramakrishnan，K.，Shenker，S.，Wroclawski，J.和L.Zhang，“关于互联网中队列管理和拥塞避免的建议”，RFC 2309，1998年4月。
[BKVP97] B. Bakshi and P. Krishna and N. Vaidya and D. Pradham, "Improving Performance of TCP over Wireless Networks", 17th International Conference on Distributed Computing Systems (ICDCS), May 1997.
[BKVP97]B.Bakshi和P.Krishna、N.Vaidya和D.Pradham，“改进无线网络上TCP的性能”，第17届分布式计算系统（ICDC）国际会议，1997年5月。
[BPK97] Hari Balakrishnan, Venkata N. Padmanabhan, and Randy H. Katz. The Effects of Asymmetry on TCP Performance. In Proceedings of the ACM/IEEE Mobicom, Budapest, Hungary, ACM. September, 1997.
[BPK97]哈里·巴拉克里希南、文卡塔·帕德马纳班和兰迪·H·卡茨。不对称性对TCP性能的影响。ACM/IEEE Mobicom会议记录，匈牙利布达佩斯，ACM。1997年9月。
[BPK98] Hari Balakrishnan, Venkata Padmanabhan, Randy H. Katz. The Effects of Asymmetry on TCP Performance. ACM Mobile Networks and Applications (MONET), 1998 (to appear).
[BPK98]哈里·巴拉克里希南，文卡塔·帕德马纳汉，兰迪·H·卡茨。不对称性对TCP性能的影响。ACM移动网络和应用（莫奈），1998年（即将出版）。
[BPSK96] H. Balakrishnan and V. Padmanabhan and S. Sechan and R. Katz, "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links", ACM SIGCOMM, August 1996.
[BPSK96]H.Balakrishnan和V.Padmanabhan和S.Sechan和R.Katz，“无线链路上改进TCP性能的机制比较”，ACM SIGCOMM，1996年8月。
[Bra89] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[Bra89]Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[Bra92] Braden, R., "Transaction TCP -- Concepts", RFC 1379, September 1992.
[Bra92]Braden，R.，“事务TCP——概念”，RFC 13791992年9月。
[Bra94] Braden, R., "T/TCP -- TCP Extensions for Transactions: Functional Specification", RFC 1644, July 1994.
[Bra94]Braden，R.，“T/TCP——事务的TCP扩展：功能规范”，RFC 16441994年7月。
[BRS99] Hari Balakrishnan, Hariharan Rahul, and Srinivasan Seshan. An Integrated Congestion Management Architecture for Internet Hosts. ACM SIGCOMM, September 1999.
[BRS99]哈里巴拉克里希南、哈里哈兰·拉胡尔和斯利尼瓦桑·塞尚。一种用于Internet主机的集成拥塞管理体系结构。ACM SIGCOMM，1999年9月。
[ddKI99] M. deVivo, G.O. deVivo, R. Koeneke, G. Isern. Internet Vulnerabilities Related to TCP/IP and T/TCP. Computer Communication Review, 29(1), January 1999.
[ddKI99]M.deVivo，G.O.deVivo，R.Koeneke，G.Isern。与TCP/IP和T/TCP相关的Internet漏洞。《计算机通信评论》，29（1），1999年1月。
[DENP97] Mikael Degermark, Mathias Engan, Bjorn Nordgren, Stephen Pink. Low-Loss TCP/IP Header Compression for Wireless Networks. ACM/Baltzer Journal on Wireless Networks, vol.3, no.5, p. 375-87.
[DENP97]米凯尔·德格马克、马蒂亚斯·恩根、比约恩·诺德格伦、斯蒂芬·平克。无线网络的低损耗TCP/IP报头压缩。ACM/Baltzer无线网络杂志，第3卷，第5期，第页。375-87.
[DMT96] R. C. Durst and G. J. Miller and E. J. Travis, "TCP Extensions for Space Communications", Mobicom 96, ACM, USA, 1996.
[DMT96]R.C.Durst和G.J.Miller以及E.J.Travis，“空间通信的TCP扩展”，Mobicom 96，ACM，美国，1996年。
[DNP99] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[DNP99]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[FF96] Kevin Fall, Sally Floyd. Simulation-based Comparisons of Tahoe, Reno, and SACK TCP. Computer Communication Review, V. 26 N. 3, July 1996, pp. 5-21.
[FF96]凯文·法尔，萨利·弗洛伊德。基于模拟的Tahoe、Reno和SACK TCP比较。《计算机通信评论》，第26卷第3期，1996年7月，第5-21页。
[FF99] Sally Floyd, Kevin Fall. Promoting the Use of End-to-End Congestion Control in the Internet, IEEE/ACM Transactions on Networking, August 1999.
萨莉·弗洛伊德，凯文·法尔。促进互联网端到端拥塞控制的使用，IEEE/ACM网络事务，1999年8月。
[FH99] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[FH99]Floyd，S.和T.Henderson，“TCP快速恢复算法的NewReno修改”，RFC 25821999年4月。
[FJ93] Sally Floyd and Van Jacobson. Random Early Detection Gateways for Congestion Avoidance, IEEE/ACM Transactions on Networking, V. 1 N. 4, August 1993.
萨莉·弗洛伊德和范·雅各布森。避免拥塞的随机早期检测网关，IEEE/ACM网络事务，第1卷第4期，1993年8月。
[Flo91] Sally Floyd. Connections with Multiple Congested Gateways in Packet-Switched Networks, Part 1: One-way Traffic. ACM Computer Communications Review, V. 21, N. 5, October 1991.
萨莉·弗洛伊德。分组交换网络中多个拥塞网关的连接，第1部分：单向通信。《ACM计算机通信评论》，第21卷，第5期，1991年10月。
[Flo94] Sally Floyd. TCP and Explicit Congestion Notification, ACM Computer Communication Review, V. 24 N. 5, October 1994.
萨莉·弗洛伊德。TCP和显式拥塞通知，《ACM计算机通信评论》，第24卷第5期，1994年10月。
[Flo99] Sally Floyd. "Re: TCP and out-of-order delivery", email to end2end-interest mailing list, February, 1999.
萨莉·弗洛伊德。“Re:TCP和无序交付”，电子邮件至end2end interest邮件列表，1999年2月。
[Hah94] Jonathan Hahn. MFTP: Recent Enhancements and Performance Measurements. Technical Report RND-94-006, NASA Ames Research Center, June 1994.
[Hah94]乔纳森·哈恩。MFTP：最近的增强和性能度量。技术报告RND-94-006，美国宇航局艾姆斯研究中心，1994年6月。
[Hay97] Chris Hayes. Analyzing the Performance of New TCP Extensions Over Satellite Links. Master's Thesis, Ohio University, August 1997.
[Hayes]克里斯·海斯。分析卫星链路上新TCP扩展的性能。俄亥俄大学硕士论文，1997年8月。
[HK98] Tom Henderson, Randy Katz. On Improving the Fairness of TCP Congestion Avoidance. Proceedings of IEEE Globecom `98 Conference, 1998.
[HK98]汤姆·亨德森，兰迪·卡茨。提高TCP拥塞避免的公平性。IEEE Globecom'98会议记录，1998年。
[HK99] Tim Henderson, Randy Katz. Transport Protocols for Internet-Compatible Satellite Networks, IEEE Journal on Selected Areas of Communications, February, 1999.
[HK99]蒂姆·亨德森，兰迪·卡茨。互联网兼容卫星网络的传输协议，IEEE选定通信领域杂志，1999年2月。
[Hoe95] J. Hoe, Startup Dynamics of TCP's Congestion Control and Avoidance Schemes. Master's Thesis, MIT, 1995.
[Hoe95]J.Hoe，TCP拥塞控制和避免方案的启动动力学。硕士论文，麻省理工学院，1995年。
[Hoe96] Janey Hoe. Improving the Startup Behavior of a Congestion Control Scheme for TCP. In ACM SIGCOMM, August 1996.
珍尼·霍。改进TCP拥塞控制方案的启动行为。在ACM SIGCOMM，1996年8月。
[IL92] David Iannucci and John Lakashman. MFTP: Virtual TCP Window Scaling Using Multiple Connections. Technical Report RND-92-002, NASA Ames Research Center, January 1992.
[IL92]大卫·伊安努奇和约翰·拉卡什曼。MFTP：使用多个连接进行虚拟TCP窗口缩放。技术报告RND-92-002，NASA艾姆斯研究中心，1992年1月。
[Jac88] Van Jacobson. Congestion Avoidance and Control. In Proceedings of the SIGCOMM '88, ACM. August, 1988.
范雅各布森。拥塞避免和控制。在1988年的SIGCOMM会议记录中。1988年8月。
[Jac90] Jacobson, V., "Compressing TCP/IP Headers", RFC 1144, February 1990.
[Jac90]Jacobson，V.，“压缩TCP/IP头”，RFC 11441990年2月。
[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月。
[JK92] Van Jacobson and Mike Karels. Congestion Avoidance and Control. Originally appearing in the proceedings of SIGCOMM '88 by Jacobson only, this revised version includes an additional appendix. The revised version is available at ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992.
[JK92]范·雅各布森和迈克·卡勒斯。拥塞避免和控制。最初仅由雅各布森在SIGCOMM'88会议记录中发表，本修订版包括一个附加附录。修订版可于ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992
[Joh95] Stacy Johnson. Increasing TCP Throughput by Using an Extended Acknowledgment Interval. Master's Thesis, Ohio University, June 1995.
斯泰西·约翰逊。通过使用延长的确认间隔来提高TCP吞吐量。俄亥俄大学硕士论文，1995年6月。
[KAGT98] Hans Kruse, Mark Allman, Jim Griner, Diepchi Tran. HTTP Page Transfer Rates Over Geo-Stationary Satellite Links. March 1998. Proceedings of the Sixth International Conference on Telecommunication Systems.
[KAGT98]汉斯·克鲁斯，马克·奥尔曼，吉姆·格林纳，陈迪普奇。地球静止卫星链路上的HTTP页面传输速率。1998年3月。第六届国际电信系统会议记录。
[Kes91] Srinivasan Keshav. A Control Theoretic Approach to Flow Control. In ACM SIGCOMM, September 1991.
[Kes91]Srinivasan Keshav。流量控制的控制理论方法。在ACM SIGCOMM，1991年9月。
[KM97] S. Keshav, S. Morgan. SMART Retransmission: Performance with Overload and Random Losses. Proceeding of Infocom. 1997.
[KM97]S.Keshav，S.Morgan。智能重传：具有过载和随机损耗的性能。Infocom会议记录。1997
[KVR98] Lampros Kalampoukas, Anujan Varma, and K. K.Ramakrishnan. Improving TCP Throughput Over Two-Way Asymmetric Links: Analysis and Solutions. Measurement and Modeling of Computer Systems, 1998, Pages 78-89.
[KVR98]兰普罗斯·卡兰普卡斯、阿努扬·瓦尔马和K·K·罗摩克里希南。提高双向非对称链路上的TCP吞吐量：分析和解决方案。《计算机系统的测量和建模》，1998年，第78-89页。
[MM96a] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining
TCP Congestion Control," Proceedings of SIGCOMM'96, August,
1996, Stanford, CA. Available from
http://www.psc.edu/networking/papers/papers.html
[MM96a] M. Mathis, J. Mahdavi, "Forward Acknowledgment: Refining
TCP Congestion Control," Proceedings of SIGCOMM'96, August,
1996, Stanford, CA. Available from
http://www.psc.edu/networking/papers/papers.html
[MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding Parameters" Available from http://www.psc.edu/networking/papers/FACKnotes/current.
[MM96b]M.Mathis，J.Mahdavi，“带边界参数的TCP速率减半”，可从http://www.psc.edu/networking/papers/FACKnotes/current.
[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月。
[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
[MV98] Miten N. Mehta and Nitin H. Vaidya. Delayed Duplicate-Acknowledgments: A Proposal to Improve Performance of TCP on Wireless Links. Technical Report 98-006, Department of Computer Science, Texas A&M University, February 1998.
[MV98]米坦N.梅塔和尼廷H.瓦迪亚。延迟重复确认：一种改进无线链路上TCP性能的建议。技术报告98-006，德克萨斯农工大学计算机科学系，1998年2月。
[Nic97] Kathleen Nichols. Improving Network Simulation with Feedback. Com21, Inc. Technical Report. Available from http://www.com21.com/pages/papers/068.pdf.
凯瑟琳·尼科尔斯。利用反馈改进网络仿真。Com21公司技术报告。可从http://www.com21.com/pages/papers/068.pdf.
[PADHV99] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[PADHV99]Paxson，V.，Allman，M.，Dawson，S.，天堂，I.和B.Volz，“已知的TCP实现问题”，RFC 25251999年3月。
[Pax97] Vern Paxson. Automated Packet Trace Analysis of TCP Implementations. In Proceedings of ACM SIGCOMM, September 1997.
[Pax97]弗恩·帕克森。TCP实现的自动数据包跟踪分析。在ACM SIGCOMM会议记录中，1997年9月。
[PN98] Poduri, K. and K. Nichols, "Simulation Studies of Increased Initial TCP Window Size", RFC 2415, September 1998.
[PN98]Poduri，K.和K.Nichols，“增加初始TCP窗口大小的模拟研究”，RFC 2415，1998年9月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[Pos81]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RF99] Ramakrishnan, K. and S. Floyd, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 2481, January 1999.
[RF99]Ramakrishnan，K.和S.Floyd，“向IP添加明确拥塞通知（ECN）的提案”，RFC 2481，1999年1月。
[SF98] Nihal K. G. Samaraweera and Godred Fairhurst, "Reinforcement of TCP error Recovery for Wireless Communication", Computer Communication Review, volume 28, number 2, April 1998.
[SF98]Nihal K.G.Samaraweera和Godred Fairhurst，“加强无线通信的TCP错误恢复”，《计算机通信评论》，第28卷，第2期，1998年4月。
[SP98] Shepard, T. and C. Partridge, "When TCP Starts Up With Four Packets Into Only Three Buffers", RFC 2416, September 1998.
[SP98]Shepard，T.和C.Partridge，“当TCP启动时，只有四个数据包进入三个缓冲区”，RFC 2416，1998年9月。
[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月。
[Sut98] B. Suter, T. Lakshman, D. Stiliadis, and A. Choudhury. Design Considerations for Supporting TCP with Per-flow Queueing. Proceedings of IEEE Infocom `98 Conference, 1998.
[Sut98]B.Suter、T.Lakshman、D.Stiliadis和A.Choudhury。支持TCP每流排队的设计考虑事项。IEEE Infocom'98会议记录，1998年。
[Tou97] Touch, J., "TCP Control Block Interdependence", RFC 2140, April 1997.
[Tou97]Touch，J.，“TCP控制块相互依赖”，RFC 2140，1997年4月。
[VH97a] Vikram Visweswaraiah and John Heidemann. Improving Restart of Idle TCP Connections. Technical Report 97-661, University of Southern California, 1997.
[VH97a]维克拉姆·维斯瓦莱亚和约翰·海德曼。改进空闲TCP连接的重新启动。技术报告997—661，南加州大学，1997。
[VH97b] Vikram Visweswaraiah and John Heidemann. Rate-based pacing Source Code Distribution, Web page: http://www.isi.edu/lsam/publications/rate_based_pacing/README.html November, 1997.
[VH97b]维克拉姆·维斯瓦莱亚和约翰·海德曼。基于速率的起搏源代码分发，网页：http://www.isi.edu/lsam/publications/rate_based_pacing/README.html 1997年11月。
[VH98] Vikram Visweswaraiah and John Heidemann. Improving Restart of Idle TCP Connections (revised). Submitted for publication.
[VH98]维克拉姆·维斯瓦莱亚和约翰·海德曼。改进空闲TCP连接的重新启动（修订版）。提交出版。
8 Authors' Addresses
8作者地址
Mark Allman NASA Glenn Research Center/BBN Technologies Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
马克·奥尔曼美国宇航局格伦研究中心/BBN技术刘易斯场俄亥俄州克利夫兰市布鲁克公园路21000号，邮编：44135
EMail: mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman
EMail: mallman@grc.nasa.gov
http://roland.grc.nasa.gov/~mallman
Spencer Dawkins Nortel P.O.Box 833805 Richardson, TX 75083-3805
德克萨斯州理查森市斯宾塞·道金斯北电邮政信箱833805号，邮编75083-3805
EMail: Spencer.Dawkins.sdawkins@nt.com
EMail: Spencer.Dawkins.sdawkins@nt.com
Dan Glover NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 3-6 Cleveland, OH 44135
丹格洛弗美国宇航局格伦研究中心刘易斯菲尔德21000布鲁克公园路3-6号俄亥俄州克利夫兰44135
EMail: Daniel.R.Glover@grc.nasa.gov
http://roland.grc.nasa.gov/~dglover
EMail: Daniel.R.Glover@grc.nasa.gov
http://roland.grc.nasa.gov/~dglover
Jim Griner NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
吉姆格林纳美国宇航局格伦研究中心刘易斯菲尔德21000布鲁克公园路54-2号俄亥俄州克利夫兰44135
EMail: jgriner@grc.nasa.gov
http://roland.grc.nasa.gov/~jgriner
EMail: jgriner@grc.nasa.gov
http://roland.grc.nasa.gov/~jgriner
Diepchi Tran NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-2 Cleveland, OH 44135
俄亥俄州克利夫兰市布鲁克公园路21000号，美国宇航局格伦研究中心，邮编：44135
EMail: dtran@grc.nasa.gov
EMail: dtran@grc.nasa.gov
Tom Henderson University of California at Berkeley Phone: +1 (510) 642-8919
汤姆亨德森加州大学伯克利分校电话：+ 1（510）64至8919
EMail: tomh@cs.berkeley.edu
URL: http://www.cs.berkeley.edu/~tomh/
EMail: tomh@cs.berkeley.edu
URL: http://www.cs.berkeley.edu/~tomh/
John Heidemann University of Southern California/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6695
约翰海德曼南加州大学/信息科学研究所4676海军路玛丽娜德雷，CA9022-695
EMail: johnh@isi.edu
EMail: johnh@isi.edu
Joe Touch University of Southern California/Information Sciences Institute 4676 Admiralty Way Marina del Rey, CA 90292-6601 USA
乔触摸南加州大学/信息科学研究所4676海军陆路码头德雷伊，CA 9022-6601美国
Phone: +1 310-448-9151
Fax: +1 310-823-6714
URL: http://www.isi.edu/touch
EMail: touch@isi.edu
Phone: +1 310-448-9151
Fax: +1 310-823-6714
URL: http://www.isi.edu/touch
EMail: touch@isi.edu
Hans Kruse J. Warren McClure School of Communication Systems Management Ohio University 9 S. College Street Athens, OH 45701
汉斯·克鲁斯J.沃伦·麦克卢尔俄亥俄大学通信系统管理学院俄亥俄州雅典南学院街9号，邮编：45701
Phone: 740-593-4891
Fax: 740-593-4889
EMail: hkruse1@ohiou.edu
http://www.csm.ohiou.edu/kruse
Phone: 740-593-4891
Fax: 740-593-4889
EMail: hkruse1@ohiou.edu
http://www.csm.ohiou.edu/kruse
Shawn Ostermann School of Electrical Engineering and Computer Science Ohio University 416 Morton Hall Athens, OH 45701
俄亥俄大学肖恩·奥斯特曼电气工程与计算机科学学院，俄亥俄州雅典莫顿大厅416号，邮编：45701
Phone: (740) 593-1234 EMail: ostermann@cs.ohiou.edu
电话：（740）593-1234电子邮件：ostermann@cs.ohiou.edu
Keith Scott The MITRE Corporation M/S W650 1820 Dolley Madison Blvd. McLean VA 22102-3481
基思·斯科特米特尔公司，位于多利麦迪逊大道西650号1820号。麦克莱恩弗吉尼亚州22102-3481
EMail: kscott@mitre.org
EMail: kscott@mitre.org
Jeffrey Semke Pittsburgh Supercomputing Center 4400 Fifth Ave. Pittsburgh, PA 15213
宾夕法尼亚州匹兹堡第五大道4400号杰弗里·塞姆克匹兹堡超级计算中心，邮编15213
EMail: semke@psc.edu
http://www.psc.edu/~semke
EMail: semke@psc.edu
http://www.psc.edu/~semke
9 Full Copyright Statement
9完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。