Network Working Group H. Balakrishnan
Request for Comments: 3449 MIT LCS
BCP: 69 V. N. Padmanabhan
Category: Best Current Practice Microsoft Research
G. Fairhurst
M. Sooriyabandara
University of Aberdeen, U.K.
December 2002
Network Working Group H. Balakrishnan
Request for Comments: 3449 MIT LCS
BCP: 69 V. N. Padmanabhan
Category: Best Current Practice Microsoft Research
G. Fairhurst
M. Sooriyabandara
University of Aberdeen, U.K.
December 2002
TCP Performance Implications of Network Path Asymmetry
网络路径不对称对TCP性能的影响
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document describes TCP performance problems that arise because of asymmetric effects. These problems arise in several access networks, including bandwidth-asymmetric networks and packet radio subnetworks, for different underlying reasons. However, the end result on TCP performance is the same in both cases: performance often degrades significantly because of imperfection and variability in the ACK feedback from the receiver to the sender.
本文档描述了由于不对称效应而产生的TCP性能问题。由于不同的根本原因，这些问题出现在几种接入网络中，包括带宽不对称网络和分组无线电子网。然而，在这两种情况下，TCP性能的最终结果是相同的：由于从接收方到发送方的ACK反馈的不完善性和可变性，性能通常会显著下降。
The document details several mitigations to these effects, which have either been proposed or evaluated in the literature, or are currently deployed in networks. These solutions use a combination of local link-layer techniques, subnetwork, and end-to-end mechanisms, consisting of: (i) techniques to manage the channel used for the upstream bottleneck link carrying the ACKs, typically using header compression or reducing the frequency of TCP ACKs, (ii) techniques to handle this reduced ACK frequency to retain the TCP sender's acknowledgment-triggered self-clocking and (iii) techniques to schedule the data and ACK packets in the reverse direction to improve performance in the presence of two-way traffic. Each technique is described, together with known issues, and recommendations for use. A summary of the recommendations is provided at the end of the document.
该文件详细说明了针对这些影响的几种缓解措施，这些措施已在文献中提出或评估，或目前已部署在网络中。这些解决方案使用本地链路层技术、子网和端到端机制的组合，包括：（i）管理用于承载ack的上游瓶颈链路的信道的技术，通常使用报头压缩或降低TCP ack的频率，（ii）处理此减少的ACK频率以保留TCP发送方的应答触发自时钟的技术，以及（iii）反向调度数据和ACK分组以在存在双向通信的情况下提高性能的技术。介绍了每种技术，以及已知问题和使用建议。文件末尾提供了建议摘要。
Table of Contents
目录
1. Conventions used in this Document ...............................3
2. Motivation ....................................................4
2.1 Asymmetry due to Differences in Transmit
and Receive Capacity .........................................4
2.2 Asymmetry due to Shared Media in the Reverse Direction .......5
2.3 The General Problem ..........................................5
3. How does Asymmetry Degrade TCP Performance? .....................5
3.1 Asymmetric Capacity ..........................................5
3.2 MAC Protocol Interactions ....................................7
3.3 Bidirectional Traffic ........................................8
3.4 Loss in Asymmetric Network Paths ............................10
4. Improving TCP Performance using Host Mitigations ...............10
4.1 Modified Delayed ACKs .......................................11
4.2 Use of Large MSS ............................................12
4.3 ACK Congestion Control ......................................13
4.4 Window Prediction Mechanism .................................14
4.5 Acknowledgement based on Cwnd Estimation. ...................14
4.6 TCP Sender Pacing ...........................................14
4.7 TCP Byte Counting ...........................................15
4.8 Backpressure ................................................16
5. Improving TCP performance using Transparent Modifications ......17
5.1 TYPE 0: Header Compression ..................................18
5.1.1 TCP Header Compression ..................................18
5.1.2 Alternate Robust Header Compression Algorithms ..........19
5.2 TYPE 1: Reverse Link Bandwidth Management ...................19
5.2.1 ACK Filtering ...........................................20
5.2.2 ACK Decimation ..........................................21
5.3 TYPE 2: Handling Infrequent ACKs ............................22
5.3.1 ACK Reconstruction ......................................23
5.3.2 ACK Compaction and Companding ...........................25
5.3.3 Mitigating TCP packet bursts generated by
Infrequent ACKs .........................................26
5.4 TYPE 3: Upstream Link Scheduling ............................27
5.4.1 Per-Flow queuing at the Upstream Bottleneck Link ........27
5.4.2 ACKs-first Scheduling ...................................28
6. Security Considerations ........................................29
7. Summary ........................................................30
8. Acknowledgments ................................................32
9. References .....................................................32
10. IANA Considerations ...........................................37
Appendix: Examples of Subnetworks Exhibiting Network Path
Asymmetry ...............................................38
Authors' Addresses ................................................40
Full Copyright Statement ..........................................41
1. Conventions used in this Document ...............................3
2. Motivation ....................................................4
2.1 Asymmetry due to Differences in Transmit
and Receive Capacity .........................................4
2.2 Asymmetry due to Shared Media in the Reverse Direction .......5
2.3 The General Problem ..........................................5
3. How does Asymmetry Degrade TCP Performance? .....................5
3.1 Asymmetric Capacity ..........................................5
3.2 MAC Protocol Interactions ....................................7
3.3 Bidirectional Traffic ........................................8
3.4 Loss in Asymmetric Network Paths ............................10
4. Improving TCP Performance using Host Mitigations ...............10
4.1 Modified Delayed ACKs .......................................11
4.2 Use of Large MSS ............................................12
4.3 ACK Congestion Control ......................................13
4.4 Window Prediction Mechanism .................................14
4.5 Acknowledgement based on Cwnd Estimation. ...................14
4.6 TCP Sender Pacing ...........................................14
4.7 TCP Byte Counting ...........................................15
4.8 Backpressure ................................................16
5. Improving TCP performance using Transparent Modifications ......17
5.1 TYPE 0: Header Compression ..................................18
5.1.1 TCP Header Compression ..................................18
5.1.2 Alternate Robust Header Compression Algorithms ..........19
5.2 TYPE 1: Reverse Link Bandwidth Management ...................19
5.2.1 ACK Filtering ...........................................20
5.2.2 ACK Decimation ..........................................21
5.3 TYPE 2: Handling Infrequent ACKs ............................22
5.3.1 ACK Reconstruction ......................................23
5.3.2 ACK Compaction and Companding ...........................25
5.3.3 Mitigating TCP packet bursts generated by
Infrequent ACKs .........................................26
5.4 TYPE 3: Upstream Link Scheduling ............................27
5.4.1 Per-Flow queuing at the Upstream Bottleneck Link ........27
5.4.2 ACKs-first Scheduling ...................................28
6. Security Considerations ........................................29
7. Summary ........................................................30
8. Acknowledgments ................................................32
9. References .....................................................32
10. IANA Considerations ...........................................37
Appendix: Examples of Subnetworks Exhibiting Network Path
Asymmetry ...............................................38
Authors' Addresses ................................................40
Full Copyright Statement ..........................................41
FORWARD DIRECTION: The dominant direction of data transfer over an asymmetric network path. It corresponds to the direction with better characteristics in terms of capacity, latency, error rate, etc. Data transfer in the forward direction is called "forward transfer". Packets travelling in the forward direction follow the forward path through the IP network.
正向：通过非对称网络路径进行数据传输的主要方向。它对应于在容量、延迟、错误率等方面具有更好特性的方向。向前方向上的数据传输称为“向前传输”。沿前向移动的数据包沿着IP网络的前向路径移动。
REVERSE DIRECTION: The direction in which acknowledgments of a forward TCP transfer flow. Data transfer could also happen in this direction (and is termed "reverse transfer"), but it is typically less voluminous than that in the forward direction. The reverse direction typically exhibits worse characteristics than the forward direction. Packets travelling in the reverse direction follow the reverse path through the IP network.
反向：前向TCP传输流的确认的方向。数据传输也可以在这个方向上发生（称为“反向传输”），但其容量通常小于正向传输。反向通常表现出比正向更差的特性。反向传输的数据包沿着反向路径通过IP网络。
UPSTREAM LINK: The specific bottleneck link that normally has much less capability than the corresponding downstream link. Congestion is not confined to this link alone, and may also occur at any point along the forward and reverse directions (e.g., due to sharing with other traffic flows).
上游链路：通常比相应的下游链路容量小得多的特定瓶颈链路。拥塞不仅限于此链路，还可能发生在沿正向和反向的任何点上（例如，由于与其他交通流共享）。
DOWNSTREAM LINK: A link on the forward path, corresponding to the upstream link.
下行链路：前向路径上的链路，对应于上行链路。
ACK: A cumulative TCP acknowledgment [RFC791]. In this document, this term refers to a TCP segment that carries a cumulative acknowledgement (ACK), but no data.
确认：累积TCP确认[RFC791]。在本文档中，该术语指的是携带累积确认（ACK）但无数据的TCP段。
DELAYED ACK FACTOR, d: The number of TCP data segments acknowledged by a TCP ACK. The minimum value of d is 1, since at most one ACK should be sent for each data packet [RFC1122, RFC2581].
延迟确认系数d：TCP确认的TCP数据段数。d的最小值为1，因为每个数据包最多应发送一个ACK[RFC1122，RFC2581]。
STRETCH ACK: Stretch ACKs are acknowledgements that cover more than 2 segments of previously unacknowledged data (d>2) [RFC2581]. Stretch ACKs can occur by design (although this is not standard), due to implementation bugs [All97b, RFC2525], or due to ACK loss [RFC2760].
拉伸确认：拉伸确认是覆盖2段以上以前未确认数据（d>2）的确认[RFC2581]。由于实现错误[All97b，RFC2525]或由于确认丢失[RFC2760]，拉伸确认可以通过设计（尽管这不是标准）发生。
NORMALIZED BANDWIDTH RATIO, k: The ratio of the raw bandwidth (capacity) of the forward direction to the return direction, divided by the ratio of the packet sizes used in the two directions [LMS97].
归一化带宽比，k：前向和返回方向的原始带宽（容量）之比除以两个方向中使用的分组大小之比[LMS97]。
SOFTSTATE: Per-flow state established in a network device that is used by the protocol [Cla88]. The state expires after a period of time (i.e., is not required to be explicitly deleted when a session
SOFTSTATE：在协议使用的网络设备中建立的每个流状态[Cla88]。该状态在一段时间后过期（即，会话启动时不需要显式删除）
expires), and is continuously refreshed while a flow continues (i.e., lost state may be reconstructed without needing to exchange additional control messages).
过期），并在流继续时持续刷新（即，可以在不需要交换额外控制消息的情况下重建丢失状态）。
Asymmetric characteristics are exhibited by several network technologies, including cable data networks, (e.g., DOCSIS cable TV networks [DS00, DS01]), direct broadcast satellite (e.g., an IP service using Digital Video Broadcast, DVB, [EN97] with an interactive return channel), Very Small Aperture satellite Terminals (VSAT), Asymmetric Digital Subscriber Line (ADSL) [ITU02, ANS01], and several packet radio networks. These networks are increasingly being deployed as high-speed Internet access networks, and it is therefore highly desirable to achieve good TCP performance. However, the asymmetry of the network paths often makes this challenging. Examples of some networks that exhibit asymmetry are provided in the Appendix.
一些网络技术表现出不对称特征，包括有线数据网络（如DOCSIS有线电视网络[DS00，DS01]）、直接广播卫星（如使用数字视频广播的IP服务、DVB[EN97]和交互式返回信道）、甚小孔径卫星终端（VSAT），非对称数字用户线（ADSL）[ITU02，ANS01]和几种分组无线网络。这些网络越来越多地被部署为高速互联网接入网络，因此，实现良好的TCP性能是非常理想的。然而，网络路径的不对称性往往使这一点具有挑战性。附录中提供了一些不对称网络的示例。
Asymmetry may manifest itself as a difference in transmit and receive capacity, an imbalance in the packet loss rate, or differences between the transmit and receive paths [RFC3077]. For example, when capacity is asymmetric, such that there is reduced capacity on reverse path used by TCP ACKs, slow or infrequent ACK feedback degrades TCP performance in the forward direction. Similarly, asymmetry in the underlying Medium Access Control (MAC) and Physical (PHY) protocols could make it expensive to transmit TCP ACKs (disproportionately to their size), even when capacity is symmetric.
不对称可能表现为发送和接收容量的差异、分组丢失率的不平衡或发送和接收路径之间的差异[RFC3077]。例如，当容量不对称时，例如TCP ACK使用的反向路径上的容量减少，缓慢或不频繁的ACK反馈会降低TCP在正向上的性能。类似地，底层媒体访问控制（MAC）和物理（PHY）协议中的不对称性可能会导致传输TCP ACK的成本高昂（与其大小不成比例），即使容量是对称的。
Network paths may be asymmetric because the upstream and downstream links operate at different rates and/or are implemented using different technologies.
网络路径可能是不对称的，因为上游和下游链路以不同的速率运行和/或使用不同的技术实现。
The asymmetry in capacity may be substantially increased when best effort IP flows carrying TCP ACKs share the available upstream capacity with other traffic flows, e.g., telephony, especially flows that have reserved upstream capacity. This includes service guarantees at the IP layer (e.g., the Guaranteed Service [RFC2212]) or at the subnet layer (e.g., support of Voice over IP [ITU01] using the Unsolicited Grant service in DOCSIS [DS01], or CBR virtual connections in ATM over ADSL [ITU02, ANS01]).
当承载TCP ack的尽力而为IP流与其他业务流（例如，电话，尤其是具有保留的上游容量的流）共享可用的上游容量时，容量的不对称性可能显著增加。这包括IP层的服务保证（例如，保证服务[RFC2212]）或子网层的服务保证（例如，使用DOCSIS[DS01]中的非请求授权服务支持IP语音[ITU01]，或通过ADSL[ITU02，ANS01]的ATM中的CBR虚拟连接）。
When multiple upstream links exist the asymmetry may be reduced by dividing upstream traffic between a number of available upstream links.
当存在多个上游链路时，可以通过在多个可用上游链路之间划分上游业务来减少不对称性。
In networks employing centralized multiple access control, asymmetry may be a fundamental consequence of the hub-and-spokes architecture of the network (i.e., a single base node communicating with multiple downstream nodes). The central node often incurs less transmission overhead and does not incur latency in scheduling its own downstream transmissions. In contrast, upstream transmission is subject to additional overhead and latency (e.g., due to guard times between transmission bursts, and contention intervals). This can produce significant network path asymmetry.
在采用集中式多址控制的网络中，不对称性可能是网络的集线器和辐条架构（即，单个基本节点与多个下游节点通信）的基本结果。中心节点通常会产生较少的传输开销，并且在调度其自己的下游传输时不会产生延迟。相反，上行传输受到额外开销和延迟的影响（例如，由于传输突发和争用间隔之间的保护时间）。这会产生显著的网络路径不对称。
Upstream capacity may be further limited by the requirement that each node must first request per-packet bandwidth using a contention MAC protocol (e.g., DOCSIS 1.0 MAC restricts each node to sending at most a single packet in each upstream time-division interval [DS00]). A satellite network employing dynamic Bandwidth on Demand (BoD), also consumes MAC resources for each packet sent (e.g., [EN00]). In these schemes, the available uplink capacity is a function of the MAC algorithm. The MAC and PHY schemes also introduce overhead per upstream transmission which could be so significant that transmitting short packets (including TCP ACKs) becomes as costly as transmitting MTU-sized data packets.
上游容量可进一步受到以下要求的限制：每个节点必须首先使用争用MAC协议请求每个分组的带宽（例如，DOCSIS 1.0 MAC限制每个节点在每个上游时分间隔[DS00]中最多发送一个分组）。采用动态按需带宽（BoD）的卫星网络也会为每个发送的数据包（例如[EN00]）消耗MAC资源。在这些方案中，可用上行链路容量是MAC算法的函数。MAC和PHY方案还引入了每个上行传输的开销，这可能非常重要，以至于传输短分组（包括TCP ack）变得与传输MTU大小的数据分组一样昂贵。
Despite the technological differences between capacity-dependent and MAC-dependent asymmetries, both kinds of network path suffer reduced TCP performance for the same fundamental reason: the imperfection and variability of ACK feedback. This document discusses the problem in detail and describes several techniques that may reduce or eliminate the constraints.
尽管与容量相关和与MAC相关的不对称性之间存在技术差异，但这两种网络路径都因相同的根本原因而降低了TCP性能：ACK反馈的不完善性和可变性。本文档详细讨论了该问题，并描述了几种可能减少或消除约束的技术。
This section describes the implications of network path asymmetry on TCP performance. The reader is referred to [BPK99, Bal98, Pad98, FSS01, Sam99] for more details and experimental results.
本节介绍网络路径不对称对TCP性能的影响。读者可参考[BPK99、Bal98、Pad98、FSS01、Sam99]了解更多细节和实验结果。
The problems that degrade unidirectional transfer performance when the forward and return paths have very different capacities depend on the characteristics of the upstream link. Two types of situations arise for unidirectional traffic over such network paths: when the upstream bottleneck link has sufficient queuing to prevent packet (ACK) losses, and when the upstream bottleneck link has a small buffer. Each is considered in turn.
当前向和返回路径具有非常不同的容量时，降低单向传输性能的问题取决于上游链路的特性。这种网络路径上的单向流量会出现两种情况：当上游瓶颈链路有足够的队列来防止数据包（ACK）丢失时，以及当上游瓶颈链路有一个小缓冲区时。每一个都是依次考虑的。
If the upstream bottleneck link has deep queues, so that this does not drop ACKs in the reverse direction, then performance is a strong function of the normalized bandwidth ratio, k. For example, for a 10 Mbps downstream link and a 50 Kbps upstream link, the raw capacity ratio is 200. With 1000-byte data packets and 40-byte ACKs, the ratio of the packet sizes is 25. This implies that k is 200/25 = 8. Thus, if the receiver acknowledges more frequently than one ACK every 8 (k) data packets, the upstream link will become saturated before the downstream link, limiting the throughput in the forward direction. Note that, the achieved TCP throughput is determined by the minimum of the receiver advertised window or TCP congestion window, cwnd [RFC2581].
如果上游瓶颈链路具有深队列，因此不会反向丢弃ack，那么性能是标准化带宽比k的一个强大函数。例如，对于10Mbps下行链路和50Kbps上行链路，原始容量比为200。对于1000字节的数据包和40字节的ACK，数据包大小的比率为25。这意味着k是200/25=8。因此，如果接收机每8（k）个数据分组更频繁地确认多于一个ACK，则上游链路将在下游链路之前饱和，从而限制前向的吞吐量。注意，实现的TCP吞吐量由接收器播发窗口或TCP拥塞窗口的最小值cwnd[RFC2581]确定。
If ACKs are not dropped (at the upstream bottleneck link) and k > 1 or k > 0.5 when delayed ACKs are used [RFC1122], TCP ACK-clocking breaks down. Consider two data packets transmitted by the sender in quick succession. En route to the receiver, these packets get spaced apart according to the capacity of the smallest bottleneck link in the forward direction. The principle of ACK clocking is that the ACKs generated in response to receiving these data packets reflects this temporal spacing all the way back to the sender, enabling it to transmit new data packets that maintain the same spacing [Jac88]. ACK clocking with delayed ACKs, reflects the spacing between data packets that actually trigger ACKs. However, the limited upstream capacity and queuing at the upstream bottleneck router alters the inter-ACK spacing of the reverse path, and hence that observed at the sender. When ACKs arrive at the upstream bottleneck link at a faster rate than the link can support, they get queued behind one another. The spacing between them when they emerge from the link is dilated with respect to their original spacing, and is a function of the upstream bottleneck capacity. Thus the TCP sender clocks out new data packets at a slower rate than if there had been no queuing of ACKs. The performance of the connection is no longer dependent on the downstream bottleneck link alone; instead, it is throttled by the rate of arriving ACKs. As a side effect, the sender's rate of cwnd growth also slows down.
如果在使用延迟ACK时（在上游瓶颈链路处）没有丢弃ACK且k>1或k>0.5[RFC1122]，TCP ACK时钟将中断。考虑快速发送者发送的两个数据包。在发送到接收器的过程中，这些数据包根据前向最小瓶颈链路的容量被隔开。ACK时钟的原理是，响应于接收这些数据包而生成的ACK将此时间间隔一直反射回发送方，使其能够传输保持相同间隔的新数据包[Jac88]。带有延迟ACK的ACK时钟，反映实际触发ACK的数据包之间的间隔。然而，有限的上行容量和在上行瓶颈路由器处的排队改变了反向路径的ACK间隔，从而改变了在发送方处观察到的间隔。当ack到达上游瓶颈链路的速度快于链路所能支持的速度时，它们就会排在后面排队。当它们从链路中出现时，它们之间的间距相对于其原始间距扩大，并且是上游瓶颈容量的函数。因此，TCP发送方以比没有ACK排队时更慢的速率发出新数据包。连接的性能不再仅仅依赖于下游瓶颈链路；相反，它受到到达ack的速率的限制。作为一种副作用，发送者的cwnd增长速度也会减慢。
A second side effect arises when the upstream bottleneck link on the reverse path is saturated. The saturated link causes persistent queuing of packets, leading to an increasing path Round Trip Time (RTT) [RFC2998] observed by all end hosts using the bottleneck link. This can impact the protocol control loops, and may also trigger false time out (underestimation of the path RTT by the sending host).
当反向路径上的上游瓶颈链路饱和时，会产生第二个副作用。饱和链路导致数据包持续排队，导致使用瓶颈链路的所有终端主机观察到的路径往返时间（RTT）[RFC2998]增加。这可能会影响协议控制循环，还可能触发错误超时（发送主机低估路径RTT）。
A different situation arises when the upstream bottleneck link has a relatively small amount of buffer space to accommodate ACKs. As the transmission window grows, this queue fills, and ACKs are dropped. If the receiver were to acknowledge every packet, only one of every k
当上游瓶颈链路具有相对较小的缓冲空间来容纳ack时，会出现不同的情况。随着传输窗口的增长，此队列将填满，ACK将被丢弃。如果接收器要确认每个数据包，则每k个数据包中只有一个
ACKs would get through to the sender, and the remaining (k-1) are dropped due to buffer overflow at the upstream link buffer (here k is the normalized bandwidth ratio as before). In this case, the reverse bottleneck link capacity and slow ACK arrival rate are not directly responsible for any degraded performance. However, the infrequency of ACKs leads to three reasons for degraded performance:
ack将传递给发送方，剩余的（k-1）由于上游链路缓冲区的缓冲区溢出而被丢弃（这里k是之前的标准化带宽比）。在这种情况下，反向瓶颈链路容量和缓慢的ACK到达率不会直接导致性能下降。但是，ACK的不频繁导致性能下降的三个原因：
1. The sender transmits data in large bursts of packets, limited only by the available cwnd. If the sender receives only one ACK in k, it transmits data in bursts of k (or more) packets because each ACK shifts the sliding window by at least k (acknowledged) data packets (TCP data segments). This increases the likelihood of data packet loss along the forward path especially when k is large, because routers do not handle large bursts of packets well.
1. 发送方以大量数据包的形式传输数据，仅受可用cwnd的限制。如果发送方在k中仅接收到一个ACK，则它以k个（或多个）包的突发方式发送数据，因为每个ACK将滑动窗口移动至少k个（已确认的）数据包（TCP数据段）。这增加了沿前向路径丢失数据包的可能性，特别是当k较大时，因为路由器不能很好地处理大数据包突发。
2. Current TCP sender implementations increase their cwnd by counting the number of ACKs they receive and not by how much data is actually acknowledged by each ACK. The later approach, also known as byte counting (section 4.7), is a standard implementation option for cwnd increase during the congestion avoidance period [RFC2581]. Thus fewer ACKs imply a slower rate of growth of the cwnd, which degrades performance over long-delay connections.
2. 当前的TCP发送方实现通过计算接收的ACK数量而不是每个ACK实际确认的数据量来增加其cwnd。后一种方法也称为字节计数（第4.7节），是拥塞避免期间cwnd增加的标准实现选项[RFC2581]。因此，更少的ACK意味着cwnd的增长速度较慢，这会降低长延迟连接的性能。
3. The sender TCP's Fast Retransmission and Fast Recovery algorithms [RFC2581] are less effective when ACKs are lost. The sender may possibly not receive the threshold number of duplicate ACKs even if the receiver transmits more than the DupACK threshold (> 3 DupACKs) [RFC2581]. Furthermore, the sender may possibly not receive enough duplicate ACKs to adequately inflate its cwnd during Fast Recovery.
3. 当ACK丢失时，发送方TCP的快速重传和快速恢复算法[RFC2581]的效率较低。发送方可能无法接收到重复ack的阈值数量，即使接收方发送的数据超过了重复ack阈值（>3个重复ack）[RFC2581]。此外，发送方可能没有收到足够的重复ack，无法在快速恢复期间充分膨胀其cwnd。
The interaction of TCP with MAC protocols may degrade end-to-end performance. Variable round-trip delays and ACK queuing are the main symptoms of this problem.
TCP与MAC协议的交互可能会降低端到端性能。可变往返延迟和ACK排队是该问题的主要症状。
One example is the impact on terrestrial wireless networks [Bal98]. A high per-packet overhead may arise from the need for communicating link nodes to first synchronise (e.g., via a Ready To Send / Clear to Send (RTS/CTS) protocol) before communication and the significant turn-around time for the wireless channel. This overhead is variable, since the RTS/CTS exchange may need to back-off exponentially when the remote node is busy (e.g., engaged in a conversation with a different node). This leads to large and variable communication latencies in packet-radio networks.
一个例子是对地面无线网络的影响[Bal98]。每个分组的高开销可能是由于通信链路节点需要在通信之前首先同步（例如，通过准备发送/清除发送（RTS/CTS）协议）以及无线信道的重要周转时间。此开销是可变的，因为当远程节点忙时（例如，与不同节点进行对话），RTS/CTS交换可能需要以指数方式退避。这导致分组无线网络中存在较大且可变的通信延迟。
An asymmetric workload (more downstream than upstream traffic) may cause ACKs to be queued in some wireless nodes (especially in the end host modems), exacerbating the variable latency. Queuing may also occur in other shared media, e.g., cable modem uplinks, BoD access systems often employed on shared satellite channels.
非对称工作负载（下游流量大于上游流量）可能会导致ACK在某些无线节点（尤其是在终端主机调制解调器中）中排队，从而加剧可变延迟。排队也可能发生在其他共享媒体中，例如电缆调制解调器上行链路、通常用于共享卫星信道的BoD接入系统。
Variable latency and ACK queuing reduces the smoothness of the TCP data flow. In particular, ACK traffic can interfere with the flow of data packets, increasing the traffic load of the system.
可变延迟和ACK队列会降低TCP数据流的平滑度。尤其是，ACK通信量会干扰数据包的流，从而增加系统的通信量负载。
TCP measures the path RTT, and from this calculates a smoothed RTT estimate (srtt) and a linear deviation, rttvar. These are used to estimate a path retransmission timeout (RTO) [RFC2988], set to srtt + 4*rttvar. For most wired TCP connections, the srtt remains constant or has a low linear deviation. The RTO therefore tracks the path RTT, and the TCP sender will respond promptly when multiple losses occur in a window. In contrast, some wireless networks exhibit a high variability in RTT, causing the RTO to significantly increase (e.g., on the order of 10 seconds). Paths traversing multiple wireless hops are especially vulnerable to this effect, because this increases the probability that the intermediate nodes may already be engaged in conversation with other nodes. The overhead in most MAC schemes is a function of both the number and size of packets. However, the MAC contention problem is a significant function of the number of packets (e.g., ACKs) transmitted rather than their size. In other words, there is a significant cost to transmitting a packet regardless of packet size.
TCP测量路径RTT，并由此计算平滑RTT估计（srtt）和线性偏差rttvar。这些用于估计路径重传超时（RTO）[RFC2988]，设置为srtt+4*rttvar。对于大多数有线TCP连接，srtt保持不变或具有较低的线性偏差。因此，RTO跟踪路径RTT，当窗口中发生多个丢失时，TCP发送方将立即响应。相反，一些无线网络表现出RTT的高度可变性，导致RTO显著增加（例如，大约10秒）。穿过多个无线跳的路径特别容易受到这种影响，因为这增加了中间节点可能已经与其他节点进行对话的可能性。在大多数MAC方案中，开销是数据包数量和大小的函数。然而，MAC争用问题是传输的分组（例如，ack）的数量而不是其大小的重要函数。换句话说，无论数据包大小如何，传输数据包都会带来巨大的成本。
Experiments conducted on the Ricochet packet radio network in 1996 and 1997 demonstrated the impact of radio turnarounds and the corresponding increased RTT variability, resulting in degraded TCP performance. It was not uncommon for TCP connections to experience timeouts of 9 - 12 seconds, with the result that many connections were idle for a significant fraction of their lifetime (e.g., sometimes 35% of the total transfer time). This leads to under-utilization of the available capacity. These effects may also occur in other wireless subnetworks.
1996年和1997年在Ricochet分组无线电网络上进行的实验证明了无线电周转的影响和相应增加的RTT可变性，导致TCP性能下降。TCP连接出现9-12秒超时的情况并不少见，这导致许多连接在其生命周期的很大一部分时间内处于空闲状态（例如，有时占总传输时间的35%）。这导致可用容量利用率不足。这些影响也可能发生在其他无线子网中。
Bidirectional traffic arises when there are simultaneous TCP transfers in the forward and reverse directions over an asymmetric network path, e.g., a user who sends an e-mail message in the reverse direction while simultaneously receiving a web page in the forward direction. To simplify the discussion, only one TCP connection in each direction is considered. In many practical cases, several simultaneous connections need to share the available capacity, increasing the level of congestion.
当通过非对称网络路径在正向和反向同时进行TCP传输时，例如，在反向发送电子邮件的用户同时在正向接收网页时，就会产生双向流量。为了简化讨论，每个方向只考虑一个TCP连接。在许多实际情况下，多个同时连接需要共享可用容量，从而增加拥塞程度。
Bidirectional traffic makes the effects discussed in section 3.1 more pronounced, because part of the upstream link bandwidth is consumed by the reverse transfer. This effectively increases the degree of bandwidth asymmetry. Other effects also arise due to the interaction between data packets of the reverse transfer and ACKs of the forward transfer. Suppose at the time the forward TCP connection is initiated, the reverse TCP connection has already saturated the bottleneck upstream link with data packets. There is then a high probability that many ACKs of the new forward TCP connection will encounter a full upstream link buffer and hence get dropped. Even after these initial problems, ACKs of the forward connection could get queued behind large data packets of the reverse connection. The larger data packets may have correspondingly long transmission times (e.g., it takes about 280 ms to transmit a 1 Kbyte data packet over a 28.8 kbps line). This causes the forward transfer to stall for long periods of time. It is only at times when the reverse connection loses packets (due to a buffer overflow at an intermediate router) and slows down, that the forward connection gets the opportunity to make rapid progress and build up its cwnd.
双向通信使第3.1节中讨论的影响更加明显，因为反向传输消耗了部分上行链路带宽。这有效地增加了带宽不对称的程度。由于反向传输的数据包和正向传输的ack之间的交互，也会产生其他影响。假设在前向TCP连接启动时，反向TCP连接已经用数据包饱和了瓶颈上游链路。然后，新的前向TCP连接的许多ACK很可能会遇到完整的上游链路缓冲区，因此被丢弃。即使在这些初始问题之后，前向连接的ACK也可能在反向连接的大数据包后面排队。较大的数据分组可具有相应长的传输时间（例如，通过28.8kbps线路传输1kbyte数据分组需要约280ms）。这会导致前向传输长时间失速。只有在反向连接丢失数据包（由于中间路由器的缓冲区溢出）并速度减慢时，前向连接才有机会取得快速进展并建立其cwnd。
When ACKs are queued behind other traffic for appreciable periods of time, the burst nature of TCP traffic and self-synchronizing effects can result in an effect known as ACK Compression [ZSC91], which reduces the throughput of TCP. It occurs when a series of ACKs, in one direction are queued behind a burst of other packets (e.g., data packets traveling in the same direction) and become compressed in time. This results in an intense burst of data packets in the other direction, in response to the burst of compressed ACKs arriving at the server. This phenomenon has been investigated in detail for bidirectional traffic, and recent analytical work [LMS97] has predicted ACK Compression may also result from bi-directional transmission with asymmetry, and was observed in practical asymmetric satellite subnetworks [FSS01]. In the case of extreme asymmetry (k>>1), the inter-ACK spacing can increase due to queuing (section 3.1), resulting in ACK dilation.
当ACK在相当长的一段时间内排在其他通信量之后时，TCP通信量的突发性和自同步效应会导致一种称为ACK压缩[ZSC91]的效应，这会降低TCP的吞吐量。当一个方向上的一系列ack在其他数据包（例如，在同一方向上移动的数据包）的突发之后排队并在时间上被压缩时，就会发生这种情况。这会导致另一个方向的数据包密集爆发，以响应到达服务器的压缩ack的爆发。这一现象已针对双向通信量进行了详细研究，最近的分析工作[LMS97]预测，ACK压缩也可能由不对称的双向传输引起，并在实际不对称卫星子网[FSS01]中观察到。在极端不对称的情况下（k>>1），由于排队（第3.1节），ACK间隔可能增加，从而导致ACK膨胀。
In summary, sharing of the upstream bottleneck link by multiple flows (e.g., IP flows to the same end host, or flows to a number of end hosts sharing a common upstream link) increases the level of ACK Congestion. The presence of bidirectional traffic exacerbates the constraints introduced by bandwidth asymmetry because of the adverse interaction between (large) data packets of a reverse direction connection and the ACKs of a forward direction connection.
总之，通过多个流共享上游瓶颈链路（例如，到同一终端主机的IP流，或到共享公共上游链路的多个终端主机的流）会增加ACK拥塞的级别。由于反向连接的（大）数据分组与正向连接的ack之间的不利交互，双向业务的存在加剧了带宽不对称所引入的约束。
Loss may occur in either the forward or reverse direction. For data transfer in the forward direction this results respectively in loss of data packets and ACK packets. Loss of ACKs is less significant than loss of data packets, because it generally results in stretch ACKs [CR98, FSS01].
损失可能发生在正向或反向。对于正向的数据传输，这分别导致数据分组和ACK分组的丢失。ACK的丢失不如数据包的丢失重要，因为它通常会导致拉伸ACK[CR98，FSS01]。
In the case of long delay paths, a slow upstream link [RFC3150] can lead to another complication when the end host uses TCP large windows [RFC1323] to maximize throughput in the forward direction. Loss of data packets on the forward path, due to congestion, or link loss, common for some wireless links, will generate a large number of back-to-back duplicate ACKs (or TCP SACK packets [RFC2018]), for each correctly received data packet following a loss. The TCP sender employs Fast Retransmission and Recovery [RFC2581] to recover from the loss, but even if this is successful, the ACK to the retransmitted data segment may be significantly delayed by other duplicate ACKs still queued at the upstream link buffer. This can ultimately lead to a timeout [RFC2988] and a premature end to the TCP Slow Start [RFC2581]. This results in poor forward path throughput. Section 5.3 describes some mitigations to counter this.
在长延迟路径的情况下，当终端主机使用TCP大窗口[RFC1323]来最大化前进方向的吞吐量时，缓慢的上游链路[RFC3150]可能会导致另一个复杂性。由于拥塞或链路丢失导致的前向路径上的数据包丢失（对于某些无线链路来说很常见）将在丢失后为每个正确接收的数据包生成大量背对背的重复ACK（或TCP SACK数据包[RFC2018]）。TCP发送方采用快速重传和恢复[RFC2581]来从丢失中恢复，但即使这是成功的，到重传数据段的ACK可能会因仍在上游链路缓冲区排队的其他重复ACK而显著延迟。这最终会导致超时[RFC2988]和提前结束TCP慢速启动[RFC2581]。这会导致较差的前向路径吞吐量。第5.3节描述了一些应对措施。
There are two key issues that need to be addressed to improve TCP performance over asymmetric networks. The first is to manage the capacity of the upstream bottleneck link, used by ACKs and possibly other traffic. A number of techniques exist which work by reducing the number of ACKs that flow in the reverse direction. This has the side effect of potentially destroying the desirable self-clocking property of the TCP sender where transmission of new data packets is triggered by incoming ACKs. Thus, the second issue is to avoid any adverse impact of infrequent ACKs.
为了提高非对称网络上的TCP性能，需要解决两个关键问题。第一个是管理上游瓶颈链路的容量，由ack和可能的其他流量使用。存在许多技术，它们通过减少反向流动的ack数量来工作。这具有潜在破坏TCP发送方所需的自时钟特性的副作用，其中新数据包的传输由传入的ACK触发。因此，第二个问题是避免不频繁ACK的任何不利影响。
Each of these issues can be handled by local link-layer solutions and/or by end-to-end techniques. This section discusses end-to-end modifications. Some techniques require TCP receiver changes (sections 4.1 4.4, 4.5), some require TCP sender changes (sections 4.6, 4.7), and a pair requires changes to both the TCP sender and receiver (sections 4.2, 4.3). One technique requires a sender modification at the receiving host (section 4.8). The techniques may be used independently, however some sets of techniques are complementary, e.g., pacing (section 4.6) and byte counting (section 4.7) which have been bundled into a single TCP Sender Adaptation scheme [BPK99].
这些问题中的每一个都可以通过本地链路层解决方案和/或端到端技术来处理。本节讨论端到端修改。有些技术需要更改TCP接收方（第4.1节、第4.4节、第4.5节），有些技术需要更改TCP发送方（第4.6节、第4.7节），一对技术需要更改TCP发送方和接收方（第4.2节、第4.3节）。一种技术要求在接收主机上修改发送方（第4.8节）。这些技术可以独立使用，但是一些技术集是互补的，例如，起搏（第4.6节）和字节计数（第4.7节），它们被捆绑到一个TCP发送方自适应方案中[BPK99]。
It is normally envisaged that these changes would occur in the end hosts using the asymmetric path, however they could, and have, been used in a middle-box or Protocol Enhancing Proxy (PEP) [RFC3135] employing split TCP. This document does not discuss the issues concerning PEPs. Section 4 describes several techniques, which do not require end-to-end changes.
通常设想，这些更改将在使用非对称路径的终端主机中发生，但是它们可以并且已经在使用拆分TCP的中间盒或协议增强代理（PEP）[RFC3135]中使用。本文件不讨论政治公众人物相关问题。第4节描述了几种不需要端到端更改的技术。
There are two standard methods that can be used by TCP receivers to generate acknowledgments. The method outlined in [RFC793] generates an ACK for each incoming data segment (i.e., d=1). [RFC1122] states that hosts should use "delayed acknowledgments". Using this algorithm, an ACK is generated for at least every second full-sized segment (d=2), or if a second full-sized segment does not arrive within a given timeout (which must not exceed 500 ms [RFC1122], and is typically less than 200 ms). Relaxing the latter constraint (i.e., allowing d>2) may generate Stretch ACKs [RFC2760]. This provides a possible mitigation, which reduces the rate at which ACKs are returned by the receiver. An implementer should only deviate from this requirement after careful consideration of the implications [RFC2581].
TCP接收器可以使用两种标准方法来生成确认。[RFC793]中概述的方法为每个传入数据段（即d=1）生成ACK。[RFC1122]规定主机应使用“延迟确认”。使用该算法，至少每秒钟生成一个全尺寸段（d=2），或者如果第二个全尺寸段没有在给定的超时内到达（该超时不得超过500毫秒[RFC1122]，并且通常小于200毫秒），则生成一个ACK。放松后一个约束（即，允许d>2）可能会生成拉伸确认[RFC2760]。这提供了一种可能的缓解措施，降低了接收机返回ack的速率。只有在仔细考虑影响后，实施者才能偏离此要求[RFC2581]。
Reducing the number of ACKs per received data segment has a number of undesirable effects including:
减少每个接收到的数据段的ack数会产生许多不良影响，包括：
(i) Increased path RTT (ii) Increased time for TCP to open the cwnd (iii) Increased TCP sender burst size, since cwnd opens in larger steps
(i) 增加的路径RTT（ii）增加了TCP打开cwnd的时间（iii）增加了TCP发送方突发大小，因为cwnd以更大的步长打开
In addition, a TCP receiver is often unable to determine an optimum setting for a large d, since it will normally be unaware of the details of the properties of the links that form the path in the reverse direction.
此外，TCP接收器通常无法确定大d的最佳设置，因为它通常不知道形成反向路径的链路属性的细节。
RECOMMENDATION: A TCP receiver must use the standard TCP algorithm for sending ACKs as specified in [RFC2581]. That is, it may delay sending an ACK after it receives a data segment [RFC1122]. When ACKs are delayed, the receiver must generate an ACK within 500 ms and the ACK should be generated for at least every second full sized segment (MSS) of received data [RFC2581]. This will result in an ACK delay factor (d) that does not exceed a value of 2. Changing the algorithm would require a host modification to the TCP receiver and awareness by the receiving host that it is using a connection with an asymmetric path. Such a change has many drawbacks in the general case and is currently not recommended for use within the Internet.
建议：TCP接收器必须使用[RFC2581]中规定的标准TCP算法发送ACK。也就是说，它可以在接收到数据段[RFC1122]之后延迟发送ACK。当ACK延迟时，接收器必须在500 ms内生成ACK，并且至少每秒钟为接收数据的全尺寸段（MSS）生成一次ACK[RFC2581]。这将导致ACK延迟因子（d）不超过2的值。更改算法将需要对TCP接收器进行主机修改，并要求接收主机意识到它正在使用具有非对称路径的连接。这种改变在一般情况下有许多缺点，目前不建议在互联网中使用。
A TCP sender that uses a large Maximum Segment Size (MSS) reduces the number of ACKs generated per transmitted byte of data.
使用较大最大段大小（MSS）的TCP发送方可以减少每个传输数据字节生成的ACK数。
Although individual subnetworks may support a large MTU, the majority of current Internet links employ an MTU of approx 1500 bytes (that of Ethernet). By setting the Don't Fragment (DF) bit in the IP header, Path MTU (PMTU) discovery [RFC1191] may be used to determine the maximum packet size (and hence MSS) a sender can use on a given network path without being subjected to IP fragmentation, and provides a way to automatically select a suitable MSS for a specific path. This also guarantees that routers will not perform IP fragmentation of normal data packets.
尽管单个子网可能支持一个大型MTU，但当前大多数互联网链路使用约1500字节的MTU（以太网的MTU）。通过在IP报头中设置不分段（DF）位，路径MTU（PMTU）发现[RFC1191]可用于确定发送方在给定网络路径上可以使用的最大数据包大小（因此MSS），而不受IP分段的影响，并提供一种为特定路径自动选择合适MSS的方法。这还保证路由器不会对正常数据包执行IP分段。
By electing not to use PMTU Discovery, an end host may choose to use IP fragmentation by routers along the path in the forward direction [RFC793]. This allows an MSS larger than smallest MTU along the path. However, this increases the unit of error recovery (TCP segment) above the unit of transmission (IP packet). This is not recommended, since it can increase the number of retransmitted packets following loss of a single IP packet, leading to reduced efficiency, and potentially aggravating network congestion [Ken87]. Choosing an MSS larger than the forward path minimum MTU also permits the sender to transmit more initial packets (a burst of IP fragments for each TCP segment) when a session starts or following RTO expiry, increasing the aggressiveness of the sender compared to standard TCP [RFC2581]. This can adversely impact other standard TCP sessions that share a network path.
通过选择不使用PMTU发现，终端主机可以选择通过路由器沿正向路径使用IP分段[RFC793]。这允许MSS大于路径上的最小MTU。但是，这会将错误恢复单元（TCP段）增加到传输单元（IP数据包）之上。不建议这样做，因为这样会在丢失单个IP数据包后增加重传数据包的数量，导致效率降低，并可能加剧网络拥塞[Ken87]。选择大于前向路径最小MTU的MSS还允许发送方在会话开始时或RTO到期后发送更多初始数据包（每个TCP段的IP片段突发），与标准TCP相比，增加发送方的攻击性[RFC2581]。这可能会对共享网络路径的其他标准TCP会话产生不利影响。
RECOMMENDATION:
建议：
A larger forward path MTU is desirable for paths with bandwidth asymmetry. Network providers may use a large MTU on links in the forward direction. TCP end hosts using Path MTU discovery may be able to take advantage of a large MTU by automatically selecting an appropriate larger MSS, without requiring modification. The use of Path MTU discovery [RFC1191] is therefore recommended.
对于带宽不对称的路径，需要更大的前向路径MTU。网络提供商可以在正向链路上使用大型MTU。使用路径MTU发现的TCP终端主机可以通过自动选择适当的较大MSS来利用较大的MTU，而无需修改。因此，建议使用路径MTU发现[RFC1191]。
Increasing the unit of error recovery and congestion control (MSS) above the unit of transmission and congestion loss (the IP packet) by using a larger end host MSS and IP fragmentation in routers is not recommended.
不建议通过在路由器中使用更大的终端主机MSS和IP碎片将错误恢复和拥塞控制（MSS）的单位增加到传输和拥塞丢失（IP数据包）的单位以上。
ACK Congestion Control (ACC) is an experimental technique that operates end to end. ACC extends congestion control to ACKs, since they may make non-negligible demands on resources (e.g., packet buffers, and MAC transmission overhead) at an upstream bottleneck link. It has two parts: (a) a network mechanism indicating to the receiver that the ACK path is congested, and (b) the receiver's response to such an indication.
ACK拥塞控制（ACC）是一种端到端操作的实验技术。ACC将拥塞控制扩展到ACK，因为它们可能对上游瓶颈链路的资源（例如，数据包缓冲区和MAC传输开销）产生不可忽略的需求。它有两个部分：（a）向接收机指示ACK路径拥塞的网络机制，和（b）接收机对这种指示的响应。
A router feeding an upstream bottleneck link may detect incipient congestion, e.g., using an algorithm based on RED (Random Early Detection) [FJ93]. This may track the average queue size over a time window in the recent past. If the average exceeds a threshold, the router may select a packet at random. If the packet IP header has the Explicit Congestion Notification Capable Transport (ECT) bit set, the router may mark the packet, i.e., sets an Explicit Congestion Notification (ECN) [RFC3168] bit(s) in the IP header, otherwise the packet is normally dropped. The ECN notification received by the end host is reflected back to the sending TCP end host, to trigger congestion avoidance [RFC3168]. Note that routers implementing RED with ECN, do not eliminate packet loss, and may drop a packet (even when the ECT bit is set). It is also possible to use an algorithm other than RED to decide when to set the ECN bit.
向上游瓶颈链路馈电的路由器可检测初始拥塞，例如，使用基于RED（随机早期检测）的算法[FJ93]。这可能会跟踪最近一段时间内的平均队列大小。如果平均值超过阈值，路由器可以随机选择数据包。如果分组IP报头设置了显式拥塞通知能力传输（ECT）位，则路由器可以标记分组，即，在IP报头中设置显式拥塞通知（ECN）[RFC3168]位，否则分组通常被丢弃。终端主机接收到的ECN通知被反射回发送TCP的终端主机，以触发拥塞避免[RFC3168]。请注意，使用ECN实现RED的路由器不会消除数据包丢失，并且可能会丢弃数据包（即使设置了ECT位）。也可以使用RED以外的算法来决定何时设置ECN位。
ACC extends ECN so that both TCP data packets and ACKs set the ECT bit and are thus candidates for being marked with an ECN bit. Therefore, upon receiving an ACK with the ECN bit set [RFC3168], a TCP receiver reduces the rate at which it sends ACKs. It maintains a dynamically varying delayed-ACK factor, d, and sends one ACK for every d data packets received. When it receives a packet with the ECN bit set, it increases d multiplicatively, thereby multiplicatively decreasing the frequency of ACKs. For each subsequent RTT (e.g., determined using the TCP RTTM option [RFC1323]) during which it does not receive an ECN, it linearly decreases the factor d, increasing the frequency of ACKs. Thus, the receiver mimics the standard congestion control behavior of TCP senders in the manner in which it sends ACKs.
ACC扩展了ECN，因此TCP数据包和ACK都设置了ECT位，因此都是用ECN位标记的候选。因此，在接收到ECN位设置为[RFC3168]的ACK时，TCP接收器会降低其发送ACK的速率。它保持动态变化的延迟ACK因子d，并为接收到的每d个数据包发送一个ACK。当它接收到设置了ECN位的数据包时，它会乘性地增加d，从而乘性地降低ACK的频率。对于每个随后的RTT（例如，使用TCP RTTM选项[RFC1323]确定），在该RTT期间，它不接收ECN，它线性降低因子d，增加ACK的频率。因此，接收方以发送确认的方式模拟TCP发送方的标准拥塞控制行为。
The maximum value of d is determined by the TCP sender window size, which could be conveyed to the receiver in a new (experimental) TCP option. The receiver should send at least one ACK (preferably more) for each window of data from the sender (i.e., d < (cwnd/mss)) to prevent the sender from stalling until the receiver's delayed ACK timer triggers an ACK to be sent.
d的最大值由TCP发送方窗口大小决定，该窗口大小可以通过新的（实验性的）TCP选项传送给接收方。接收器应针对来自发送器的每个数据窗口（即，d<（cwnd/mss））发送至少一个ACK（优选多个），以防止发送器暂停，直到接收器的延迟ACK定时器触发要发送的ACK为止。
RECOMMENDATION: ACK Congestion Control (ACC) is an experimental technique that requires TCP sender and receiver modifications. There is currently little experience of using such techniques in the Internet. Future versions of TCP may evolve to include this or similar techniques. These are the subject of ongoing research. ACC is not recommended for use within the Internet in its current form.
建议：ACK拥塞控制（ACC）是一种实验性技术，需要修改TCP发送方和接收方。目前在互联网上使用此类技术的经验很少。TCP的未来版本可能会演变为包括这种或类似的技术。这些是正在进行的研究的主题。不建议在当前形式的互联网中使用ACC。
The Window Prediction Mechanism (WPM) is a TCP receiver side mechanism [CLP98] that uses a dynamic ACK delay factor (varying d) resembling the ACC scheme (section 4.3). The TCP receiver reconstructs the congestion control behavior of the TCP sender by predicting a cwnd value. This value is used along with the allowed window to adjust the receiver's value of d. WPM accommodates for unnecessary retransmissions resulting from losses due to link errors.
窗口预测机制（WPM）是一种TCP接收器端机制[CLP98]，它使用类似于ACC方案（第4.3节）的动态ACK延迟因子（变化d）。TCP接收方通过预测cwnd值来重建TCP发送方的拥塞控制行为。此值与允许的窗口一起用于调整接收器的d值。WPM能够适应由于链路错误导致的丢失而导致的不必要的重新传输。
RECOMMENDATION: Window Prediction Mechanism (WPM) is an experimental TCP receiver side modification. There is currently little experience of using such techniques in the Internet. Future versions of TCP may evolve to include this or similar techniques. These are the subjects of ongoing research. WPM is not recommended for use within the Internet in its current form.
建议：窗口预测机制（WPM）是一种实验性的TCP接收端修改。目前在互联网上使用此类技术的经验很少。TCP的未来版本可能会演变为包括这种或类似的技术。这些是正在进行的研究的主题。不建议在当前形式的Internet中使用WPM。
4.5 Acknowledgement based on Cwnd Estimation.
4.5 基于Cwnd估计的确认。
Acknowledgement based on Cwnd Estimation (ACE) [MJW00] attempts to measure the cwnd at the TCP receiver and maintain a varying ACK delay factor (d). The cwnd is estimated by counting the number of packets received during a path RTT. The technique may improve accuracy of prediction of a suitable cwnd.
基于Cwnd估计的确认（ACE）[MJW00]尝试在TCP接收器处测量Cwnd，并保持变化的ACK延迟因子（d）。cwnd是通过计算路径RTT期间接收的数据包数量来估计的。该技术可提高预测合适cwnd的准确性。
RECOMMENDATION: Acknowledgement based on Cwnd Estimation (ACE) is an experimental TCP receiver side modification. There is currently little experience of using such techniques in the Internet. Future versions of TCP may evolve to include this or similar techniques. These are the subject of ongoing research. ACE is not recommended for use within the Internet in its current form.
建议：基于Cwnd估计的确认（ACE）是一种实验性的TCP接收端修改。目前在互联网上使用此类技术的经验很少。TCP的未来版本可能会演变为包括这种或类似的技术。这些是正在进行的研究的主题。不建议在当前形式的互联网中使用ACE。
Reducing the frequency of ACKs may alleviate congestion of the upstream bottleneck link, but can lead to increased size of TCP sender bursts (section 4.1). This may slow the growth of cwnd, and is undesirable when used over shared network paths since it may significantly increase the maximum number of packets in the bottleneck link buffer, potentially resulting in an increase in network congestion. This may also lead to ACK Compression [ZSC91].
减少ACK频率可能会缓解上游瓶颈链路的拥塞，但可能会导致TCP发送方突发的规模增大（第4.1节）。这可能会减缓cwnd的增长，并且在共享网络路径上使用时是不可取的，因为它可能会显著增加瓶颈链路缓冲区中的最大数据包数，从而可能导致网络拥塞的增加。这也可能导致ACK压缩[ZSC91]。
TCP Pacing [AST00], generally referred to as TCP Sender pacing, employs an adapted TCP sender to alleviating transmission burstiness. A bound is placed on the maximum number of packets the TCP sender can transmit back-to-back (at local line rate), even if the window(s) allow the transmission of more data. If necessary, more bursts of data packets are scheduled for later points in time computed based on the transmission rate of the TCP connection. The transmission rate may be estimated from the ratio cwnd/srtt. Thus, large bursts of data packets get broken up into smaller bursts spread over time.
TCP起搏[AST00]，通常称为TCP发送方起搏，使用经过调整的TCP发送方来缓解传输突发性。TCP发送方可以背靠背（以本地线路速率）传输的最大数据包数（即使窗口允许传输更多数据）也有一个界限。如有必要，将更多的数据包突发调度到基于TCP连接的传输速率计算的稍后时间点。可以根据比率cwnd/srtt来估计传输速率。因此，随着时间的推移，数据包的大突发被分解成更小的突发。
A subnetwork may also provide pacing (e.g., Generic Traffic Shaping (GTS)), but implies a significant increase in the per-packet processing overhead and buffer requirement at the router where shaping is performed (section 5.3.3).
子网也可提供调整（例如，通用流量调整（GTS）），但意味着在执行调整的路由器处，每包处理开销和缓冲区要求显著增加（第5.3.3节）。
RECOMMENDATIONS: TCP Sender Pacing requires a change to implementation of the TCP sender. It may be beneficial in the Internet and will significantly reduce the burst size of packets transmitted by a host. This successfully mitigates the impact of receiving Stretch ACKs. TCP Sender Pacing implies increased processing cost per packet, and requires a prediction algorithm to suggest a suitable transmission rate. There are hence performance trade-offs between end host cost and network performance. Specification of efficient algorithms remains an area of ongoing research. Use of TCP Sender Pacing is not expected to introduce new problems. It is an experimental mitigation for TCP hosts that may control the burstiness of transmission (e.g., resulting from Type 1 techniques, section 5.1.2), however it is not currently widely deployed. It is not recommended for use within the Internet in its current form.
建议：TCP发送方调整需要更改TCP发送方的实现。它在因特网中可能是有益的，并且将显著减小由主机传输的分组的突发大小。这成功地减轻了接收拉伸ack的影响。TCP发送方速度调整意味着每个数据包的处理成本增加，并且需要一个预测算法来建议合适的传输速率。因此，在终端主机成本和网络性能之间存在性能权衡。高效算法的规范仍然是一个正在进行的研究领域。使用TCP发送方速度调整预计不会带来新问题。它是TCP主机的一种实验性缓解措施，可控制传输的突发性（例如，由第5.1.2节第1类技术产生），但目前尚未广泛部署。不建议以其当前形式在Internet内使用。
The TCP sender can avoid slowing growth of cwnd by taking into account the volume of data acknowledged by each ACK, rather than opening the cwnd based on the number of received ACKs. So, if an ACK acknowledges d data packets (or TCP data segments), the cwnd would grow as if d separate ACKs had been received. This is called TCP Byte Counting [RFC2581, RFC2760]. (One could treat the single ACK as being equivalent to d/2, instead of d ACKs, to mimic the effect of the TCP delayed ACK algorithm.) This policy works because cwnd growth is only tied to the available capacity in the forward direction, so the number of ACKs is immaterial.
TCP发送方可以通过考虑每个ACK确认的数据量，而不是根据接收到的ACK数量打开cwnd，从而避免cwnd增长放缓。因此，如果ACK确认了d个数据包（或TCP数据段），则cwnd将增长，就像接收到了d个单独的ACK一样。这称为TCP字节计数[RFC2581，RFC2760]。（可以将单个ACK视为等同于d/2，而不是d个ACK，以模拟TCP延迟ACK算法的效果。）此策略有效，因为cwnd增长仅与前向的可用容量相关，因此ACK的数量无关紧要。
This may mitigate the impact of asymmetry when used in combination with other techniques (e.g., a combination of TCP Pacing (section4.6), and ACC (section 4.3) associated with a duplicate ACK threshold at the receiver.)
当与其他技术（例如，TCP起搏（第4.6节）和ACC（第4.3节）的组合与接收器处的重复ACK阈值相结合时，这可以减轻不对称的影响。）
The main issue is that TCP byte counting may generate undesirable long bursts of TCP packets at the sender host line rate. An implementation must also consider that data packets in the forward direction and ACKs in the reverse direction may both travel over network paths that perform some amount of packet reordering. Reordering of IP packets is currently common, and may arise from various causes [BPS00].
主要问题是，TCP字节计数可能会以发送方主机线速率生成不需要的TCP数据包长突发。实现还必须考虑正向数据包和反向方向上的数据包都可以在执行一定数量的分组重新排序的网络路径上行进。IP数据包的重新排序目前很常见，可能由各种原因引起[BPS00]。
RECOMMENDATION: TCP Byte Counting requires a small TCP sender modification. In its simplest form, it can generate large bursts of TCP data packets, particularly when Stretch ACKs are received. Unlimited byte counting is therefore not allowed [RFC2581] for use within the Internet.
建议：TCP字节计数需要对TCP发送方进行少量修改。在其最简单的形式中，它可以生成大量的TCP数据包突发，特别是在接收到拉伸确认时。因此，不允许[RFC2581]在Internet中使用无限字节计数。
It is therefore strongly recommended [RFC2581, RFC2760] that any byte counting scheme should include a method to mitigate the potentially large bursts of TCP data packets the algorithm can cause (e.g., TCP Sender Pacing (section 4.6), ABC [abc-ID]). If the burst size or sending rate of the TCP sender can be controlled then the scheme may be beneficial when Stretch ACKs are received. Determining safe algorithms remain an area of ongoing research. Further experimentation will then be required to assess the success of these safeguards, before they can be recommended for use in the Internet.
因此，强烈建议[RFC2581，RFC2760]任何字节计数方案都应包括一种方法，以缓解算法可能导致的TCP数据包的潜在大突发（例如，TCP发送方定步（第4.6节），ABC[ABC ID]）。如果可以控制TCP发送方的突发大小或发送速率，那么当接收到拉伸确认时，该方案可能是有益的。确定安全算法仍然是一个正在进行的研究领域。在这些安全措施被推荐用于互联网之前，还需要进一步的实验来评估这些措施的成功与否。
Backpressure is a technique to enhance the performance of bidirectional traffic for end hosts directly connected to the upstream bottleneck link [KVR98]. A limit is set on how many data packets of upstream transfers can be enqueued at the upstream bottleneck link. In other words, the bottleneck link queue exerts 'backpressure' on the TCP (sender) layer. This requires a modified implementation, compared to that currently deployed in many TCP stacks. Backpressure ensures that ACKs of downstream connections do not get starved at the upstream bottleneck, thereby improving performance of the downstream connections. Similar generic schemes that may be implemented in hosts/routers are discussed in section 5.4.
背压是一种增强直接连接到上游瓶颈链路的终端主机的双向流量性能的技术[KVR98]。对上行传输的数据包在上行瓶颈链路上排队的数量设置了限制。换句话说，瓶颈链路队列对TCP（发送方）层施加“背压”。与许多TCP堆栈中当前部署的实现相比，这需要修改实现。背压确保下游连接的ACK不会在上游瓶颈处饿死，从而提高下游连接的性能。第5.4节讨论了可在主机/路由器中实施的类似通用方案。
Backpressure can be unfair to a reverse direction connection and make its throughput highly sensitive to the dynamics of the forward connection(s).
背压可能对反向连接不公平，并使其吞吐量对正向连接的动态高度敏感。
RECOMMENDATION: Backpressure requires an experimental modification to the sender protocol stack of a host directly connected to an upstream bottleneck link. Use of backpressure is an implementation issue, rather than a network protocol issue. Where backpressure is implemented, the optimizations described in this section could be
建议：背压需要对直接连接到上游瓶颈链路的主机的发送方协议堆栈进行实验性修改。背压的使用是一个实现问题，而不是一个网络协议问题。在实施背压的情况下，可以使用本节中描述的优化
desirable and can benefit bidirectional traffic for hosts. Specification of safe algorithms for providing backpressure is still a subject of ongoing research. The technique is not recommended for use within the Internet in its current form.
这是理想的，并且有利于主机的双向通信。提供背压的安全算法规范仍然是一个正在进行的研究课题。不建议在当前形式的互联网中使用该技术。
Various link and network layer techniques have been suggested to mitigate the effect of an upstream bottleneck link. These techniques may provide benefit without modification to either the TCP sender or receiver, or may alternately be used in conjunction with one or more of the schemes identified in section 4. In this document, these techniques are known as "transparent" [RFC3135], because at the transport layer, the TCP sender and receiver are not necessarily aware of their existence. This does not imply that they do not modify the pattern and timing of packets as observed at the network layer. The techniques are classified here into three types based on the point at which they are introduced.
已经提出了各种链路和网络层技术来减轻上游瓶颈链路的影响。这些技术可以在不修改TCP发送方或接收方的情况下提供益处，或者可以交替地与第4节中确定的一个或多个方案结合使用。在本文档中，这些技术被称为“透明”[RFC3135]，因为在传输层，TCP发送方和接收方不一定知道它们的存在。这并不意味着它们不修改在网络层观察到的分组的模式和定时。根据引入的点，这里将这些技术分为三种类型。
Most techniques require the individual TCP connections passing over the bottleneck link(s) to be separately identified and imply that some per-flow state is maintained for active TCP connections. A link scheduler may also be employed (section 5.4). The techniques (with one exception, ACK Decimation (section 5.2.2) require:
大多数技术都要求单独标识通过瓶颈链路的各个TCP连接，这意味着为活动TCP连接维护一些每流状态。也可采用链路调度器（第5.4节）。技术（ACK抽取（第5.2.2节）除外）要求：
(i) Visibility of an unencrypted IP and TCP packet header (e.g., no use of IPSec with payload encryption [RFC2406]). (ii) Knowledge of IP/TCP options and ability to inspect packets with tunnel encapsulations (e.g., [RFC2784]) or to suspend processing of packets with unknown formats. (iii) Ability to demultiplex flows (by using address/protocol/port number, or an explicit flow-id).
(i) 未加密IP和TCP数据包头的可见性（例如，不使用IPSec和有效负载加密[RFC2406]）。（ii）了解IP/TCP选项，能够检查具有隧道封装（例如，[RFC2784]）的数据包，或暂停处理具有未知格式的数据包。（iii）解复用流的能力（通过使用地址/协议/端口号或显式流id）。
[RFC3135] describes a class of network device that provides more than forwarding of packets, and which is known as a Protocol Enhancing Proxy (PEP). A large spectrum of PEP devices exists, ranging from simple devices (e.g., ACK filtering) to more sophisticated devices (e.g., stateful devices that split a TCP connection into two separate parts). The techniques described in section 5 of this document belong to the simpler type, and do not inspect or modify any TCP or UDP payload data. They also do not modify port numbers or link addresses. Many of the risks associated with more complex PEPs do not exist for these schemes. Further information about the operation and the risks associated with using PEPs are described in [RFC3135].
[RFC3135]描述了一类网络设备，它提供的不仅仅是数据包的转发，它被称为协议增强代理（PEP）。存在大量PEP设备，从简单设备（例如，ACK过滤）到更复杂的设备（例如，将TCP连接拆分为两个独立部分的有状态设备）。本文档第5节中描述的技术属于更简单的类型，不检查或修改任何TCP或UDP有效负载数据。它们也不会修改端口号或链接地址。这些计划不存在与更复杂的政治公众人物相关的许多风险。[RFC3135]中描述了与使用PEP相关的操作和风险的更多信息。
A client may reduce the volume of bits used to send a single ACK by using compression [RFC3150, RFC3135]. Most modern dial-up modems support ITU-T V.42 bulk compression. In contrast to bulk compression, header compression is known to be very effective at reducing the number of bits sent on the upstream link [RFC1144]. This relies on the observation that most TCP packet headers vary only in a few bit positions between successive packets in a flow, and that the variations can often be predicted.
客户端可以通过使用压缩来减少用于发送单个ACK的比特量[RFC3150，RFC3135]。大多数现代拨号调制解调器支持ITU-T V.42批量压缩。与批量压缩相比，已知报头压缩在减少上行链路上发送的比特数方面非常有效[RFC1144]。这取决于观察到的大多数TCP数据包头仅在流中连续数据包之间的几位位置上变化，并且变化通常可以预测。
TCP header compression [RFC1144] (sometimes known as V-J compression) is a Proposed Standard describing use over low capacity links running SLIP or PPP [RFC3150]. It greatly reduces the size of ACKs on the reverse link when losses are infrequent (a situation that ensures that the state of the compressor and decompressor are synchronized). However, this alone does not address all of the asymmetry issues:
TCP报头压缩[RFC1144]（有时称为V-J压缩）是一种提议的标准，用于描述在运行SLIP或PPP的低容量链路上的使用[RFC3150]。当丢失很少时（这种情况可确保压缩机和减压器的状态同步），它可以大大减少反向链路上的ACK大小。然而，这并不能解决所有不对称问题：
(i) In some (e.g., wireless) subnetworks there is a significant per-packet MAC overhead that is independent of packet size (section 3.2). (ii) A reduction in the size of ACKs does not prevent adverse interaction with large upstream data packets in the presence of bidirectional traffic (section 3.3). (iii) TCP header compression cannot be used with packets that have IP or TCP options (including IPSec [RFC2402, RFC2406], TCP RTTM [RFC1323], TCP SACK [RFC2018], etc.). (iv) The performance of header compression described by RFC1144 is significantly degraded when compressed packets are lost. An improvement, which can still incur significant penalty on long network paths is described in [RFC2507]. This suggests it should only be used on links (or paths) that experience a low level of packet loss [RFC3150]. (v) The normal implementation of Header Compression inhibits compression when IP is used to support tunneling (e.g., L2TP, GRE [RFC2794], IP-in-IP). The tunnel encapsulation complicates locating the appropriate packet headers. Although GRE allows Header Compression on the inner (tunneled) IP header [RFC2784], this is not recommended, since loss of a packet (e.g., due to router congestion along the tunnel path) will result in discard of all packets for one RTT [RFC1144].
(i) 在某些（例如，无线）子网中，存在与数据包大小无关的显著的每数据包MAC开销（第3.2节）。（ii）ACK大小的减小并不能防止在存在双向流量的情况下与大型上游数据包的不利交互（第3.3节）。（iii）TCP报头压缩不能用于具有IP或TCP选项的数据包（包括IPSec[RFC2402、RFC2406]、TCP RTTM[RFC1323]、TCP SACK[RFC2018]等）。（iv）当压缩数据包丢失时，RFC1144描述的报头压缩性能显著降低。[RFC2507]中描述了一种改进，这种改进仍然会对长网络路径产生重大影响。这表明它应该只在经历低丢包率的链路（或路径）上使用[RFC3150]。（v） 当IP用于支持隧道传输（例如L2TP、GRE[RFC2794]，IP中的IP）时，报头压缩的正常实现禁止压缩。隧道封装使定位适当的数据包头变得复杂。尽管GRE允许在内部（隧道式）IP报头[RFC2784]上进行报头压缩，但不建议这样做，因为数据包丢失（例如，由于隧道路径上的路由器拥塞）将导致丢弃一个RTT的所有数据包[RFC1144]。
RECOMMENDATION: TCP Header Compression is a transparent modification performed at both ends of the upstream bottleneck link. It offers no benefit for flows employing IPSec [RFC2402, RFC2406], or when additional protocol headers are present (e.g., IP or TCP options,
建议：TCP报头压缩是在上游瓶颈链路两端执行的透明修改。对于采用IPSec[RFC2402，RFC2406]的流，或者存在其他协议头（例如IP或TCP选项）的流，它没有任何好处，
and/or tunnel encapsulation headers). The scheme is widely implemented and deployed and used over Internet links. It is recommended to improve TCP performance for paths that have a low-to-medium bandwidth asymmetry (e.g., k<10).
和/或隧道封装头）。该方案在互联网链路上得到广泛实施、部署和使用。建议改善具有中低带宽不对称性（例如，k<10）的路径的TCP性能。
In the form described in [RFC1144], TCP performance is degraded when used over links (or paths) that may exhibit appreciable rates of packet loss [RFC3150]. It may also not provide significant improvement for upstream links with bidirectional traffic. It is therefore not desirable for paths that have a high bandwidth asymmetry (e.g., k>10).
按照[RFC1144]中所述的形式，当在链路（或路径）上使用时，TCP性能会降低，而链路（或路径）可能会出现明显的数据包丢失率[RFC3150]。它也可能不会为具有双向流量的上游链路提供显著的改善。因此，对于具有高带宽不对称性（例如，k>10）的路径是不可取的。
TCP header compression [RFC1144] and IP header compression [RFC2507] do not perform well when subject to packet loss. Further, they do not compress packets with TCP option fields (e.g., SACK [RFC2018] and Timestamp (RTTM) [RFC1323]). However, recent work on more robust schemes suggest that a new generation of compression algorithms may be developed which are much more robust. The IETF ROHC working group has specified compression techniques for UDP-based traffic [RFC3095] and is examining a number of schemes that may provide improve TCP header compression. These could be beneficial for asymmetric network paths.
TCP报头压缩[RFC1144]和IP报头压缩[RFC2507]在数据包丢失时表现不佳。此外，它们不使用TCP选项字段（例如，SACK[RFC2018]和Timestamp（RTTM）[RFC1323]）压缩数据包。然而，最近关于更稳健方案的研究表明，可能会开发出新一代更稳健的压缩算法。IETF ROHC工作组已经为基于UDP的通信量[RFC3095]指定了压缩技术，并正在研究一系列可能提供改进TCP报头压缩的方案。这些可能有利于不对称网络路径。
RECOMMENDATION: Robust header compression is a transparent modification that may be performed at both ends of an upstream bottleneck link. This class of techniques may also be suited to Internet paths that suffer low levels of re-ordering. The techniques benefit paths with a low-to-medium bandwidth asymmetry (e.g., k>10) and may be robust to packet loss.
建议：健壮的报头压缩是一种透明的修改，可以在上游瓶颈链路的两端执行。这类技术也适用于重新排序级别较低的Internet路径。这些技术有益于具有低到中等带宽不对称性（例如，k>10）的路径，并且可能对分组丢失具有鲁棒性。
Selection of suitable compression algorithms remains an area of ongoing research. It is possible that schemes may be derived which support IPSec authentication, but not IPSec payload encryption. Such schemes do not alone provide significant improvement in asymmetric networks with a high asymmetry and/or bidirectional traffic.
选择合适的压缩算法仍然是一个正在进行的研究领域。可能会导出支持IPSec身份验证但不支持IPSec有效负载加密的方案。这种方案不能单独在具有高度不对称和/或双向业务的不对称网络中提供显著的改进。
Techniques beyond Type 0 header compression are required to address the performance problems caused by appreciable asymmetry (k>>1). One set of techniques is implemented only at one point on the reverse direction path, within the router/host connected to the upstream bottleneck link. These use flow class or per-flow queues at the upstream link interface to manage the queue of packets waiting for transmission on the bottleneck upstream link.
除了类型0报头压缩之外，还需要其他技术来解决由明显不对称引起的性能问题（k>>1）。一组技术仅在反向路径上的一个点上实施，在连接到上游瓶颈链路的路由器/主机内。它们使用上游链路接口处的流类或每流队列来管理在瓶颈上游链路上等待传输的数据包队列。
This type of technique bounds the upstream link buffer queue size, and employs an algorithm to remove (discard) excess ACKs from each queue. This relies on the cumulative nature of ACKs (section 4.1). Two approaches are described which employ this type of mitigation.
这种类型的技术限制了上游链路缓冲区队列的大小，并使用一种算法从每个队列中移除（丢弃）多余的ack。这取决于ACK的累积性质（第4.1节）。描述了两种采用此类缓解措施的方法。
ACK Filtering (AF) [DMT96, BPK99] (also known as ACK Suppression [SF98, Sam99, FSS01]) is a TCP-aware link-layer technique that reduces the number of ACKs sent on the upstream link. This technique has been deployed in specific production networks (e.g., asymmetric satellite networks [ASB96]). The challenge is to ensure that the sender does not stall waiting for ACKs, which may happen if ACKs are indiscriminately removed.
ACK过滤（AF）[DMT96，BPK99]（也称为ACK抑制[SF98，Sam99，FSS01]）是一种TCP感知的链路层技术，可减少上行链路上发送的ACK数量。该技术已部署在特定的生产网络中（例如，不对称卫星网络[ASB96]）。挑战在于确保发送方不会暂停等待ack，如果不加区别地删除ack，则可能会发生这种情况。
When an ACK from the receiver is about to be enqueued at a upstream bottleneck link interface, the router or the end host link layer (if the host is directly connected to the upstream bottleneck link) checks the transmit queue(s) for older ACKs belonging to the same TCP connection. If ACKs are found, some (or all of them) are removed from the queue, reducing the number of ACKs.
当来自接收器的ACK即将在上游瓶颈链路接口排队时，路由器或终端主机链路层（如果主机直接连接到上游瓶颈链路）检查传输队列是否有属于同一TCP连接的旧ACK。如果找到了ACK，将从队列中删除部分（或全部），从而减少ACK的数量。
Some ACKs also have other functions in TCP [RFC1144], and should not be deleted to ensure normal operation. AF should therefore not delete an ACK that has any data or TCP flags set (SYN, RST, URG, and FIN). In addition, it should avoid deleting a series of 3 duplicate ACKs that indicate the need for Fast Retransmission [RFC2581] or ACKs with the Selective ACK option (SACK)[RFC2018] from the queue to avoid causing problems to TCP's data-driven loss recovery mechanisms. Appropriate treatment is also needed to preserve correct operation of ECN feedback (carried in the TCP header) [RFC3168].
某些ACK在TCP[RFC1144]中还具有其他功能，不应删除以确保正常运行。因此，AF不应删除设置了任何数据或TCP标志（SYN、RST、URG和FIN）的ACK。此外，应避免从队列中删除一系列3个重复的ACK，这些ACK指示需要快速重传[RFC2581]或带有选择性ACK选项（SACK）[RFC2018]的ACK，以避免对TCP的数据驱动丢失恢复机制造成问题。还需要进行适当的处理，以保持ECN反馈（在TCP报头中进行）的正确操作[RFC3168]。
A range of policies to filter ACKs may be used. These may be either deterministic or random (similar to a random-drop gateway, but should take into consideration the semantics of the items in the queue). Algorithms have also been suggested to ensure a minimum ACK rate to guarantee the TCP sender window is updated [Sam99, FSS01], and to limit the number of data packets (TCP segments) acknowledged by a Stretch ACK. Per-flow state needs to be maintained only for connections with at least one packet in the queue (similar to FRED [LM97]). This state is soft [Cla88], and if necessary, can easily be reconstructed from the contents of the queue.
可以使用一系列策略来过滤ack。它们可以是确定性的，也可以是随机的（类似于随机丢弃网关，但应考虑队列中项目的语义）。还建议使用算法来确保最小的ACK速率，以确保TCP发送方窗口得到更新[Sam99，FSS01]，并限制拉伸ACK确认的数据包（TCP段）数量。每个流状态只需要为队列中至少有一个数据包的连接维护（类似于FRED[LM97]）。这种状态是软的[Cla88]，如果需要，可以很容易地从队列的内容中重构。
The undesirable effect of delayed DupACKs (section 3.4) can be reduced by deleting duplicate ACKs above a threshold value [MJW00, CLP98] allowing Fast Retransmission, but avoiding early TCP timeouts, which may otherwise result from excessive queuing of DupACKs.
通过删除高于阈值[MJW00，CLP98]的重复确认，可以减少延迟重复确认（第3.4节）的不良影响，允许快速重传，但避免因重复确认排队过多而导致的早期TCP超时。
Future schemes may include more advanced rules allowing removal of selected SACKs [RFC2018]. Such a scheme could prevent the upstream link queue from becoming filled by back-to-back ACKs with SACK blocks. Since a SACK packet is much larger than an ACK, it would otherwise add significantly to the path delay in the reverse direction. Selection of suitable algorithms remains an ongoing area of research.
未来的方案可能包括更高级的规则，允许移除选定的袋子[RFC2018]。这样的方案可以防止上游链路队列被带有SACK块的背对背ACK填满。由于SACK数据包比ACK数据包大得多，因此它会显著增加反向路径延迟。选择合适的算法仍然是一个正在进行的研究领域。
RECOMMENDATION: ACK Filtering requires a modification to the upstream link interface. The scheme has been deployed in some networks where the extra processing overhead (per ACK) may be compensated for by avoiding the need to modify TCP. ACK Filtering can generate Stretch ACKs resulting in large bursts of TCP data packets. Therefore on its own, it is not recommended for use in the general Internet.
建议：ACK过滤需要修改上游链路接口。该方案已部署在一些网络中，在这些网络中，可以通过避免修改TCP来补偿额外的处理开销（每个ACK）。ACK过滤可以生成拉伸ACK，从而导致TCP数据包的大量突发。因此，就其本身而言，不建议在一般互联网中使用。
ACK Filtering when used in combination with a scheme to mitigate the effect of Stretch ACKs (i.e., control TCP sender burst size) is recommended for paths with appreciable asymmetry (k>1) and/or with bidirectional traffic. Suitable algorithms to support IPSec authentication, SACK, and ECN remain areas of ongoing research.
对于具有明显不对称性（k>1）和/或双向流量的路径，建议将ACK过滤与缓解拉伸ACK（即，控制TCP发送方突发大小）影响的方案结合使用。支持IPSec身份验证、SACK和ECN的合适算法仍然是正在进行的研究领域。
ACK Decimation is based on standard router mechanisms. By using an appropriate configuration of (small) per-flow queues and a chosen dropping policy (e.g., Weighted Fair Queuing, WFQ) at the upstream bottleneck link, a similar effect to AF (section 5.2.1) may be obtained, but with less control of the actual packets which are dropped.
ACK抽取基于标准路由器机制。通过在上游瓶颈链路处使用（小）每流队列的适当配置和选择的丢弃策略（例如，加权公平队列，WFQ），可以获得与AF（第5.2.1节）类似的效果，但对丢弃的实际数据包的控制较少。
In this scheme, the router/host at the bottleneck upstream link maintains per-flow queues and services them fairly (or with priorities) by queuing and scheduling of ACKs and data packets in the reverse direction. A small queue threshold is maintained to drop excessive ACKs from the tail of each queue, in order to reduce ACK Congestion. The inability to identify special ACK packets (c.f., AF) introduces some major drawbacks to this approach, such as the possibility of losing DupACKs, FIN/ACK, RST packets, or packets carrying ECN information [RFC3168]. Loss of these packets does not significantly impact network congestion, but does adversely impact the performance of the TCP session observing the loss.
在该方案中，瓶颈上游链路处的路由器/主机通过反向排队和调度ack和数据包来维护每流队列并公平地（或具有优先级地）为它们提供服务。保持一个小的队列阈值，从每个队列的尾部丢弃过多的ACK，以减少ACK拥塞。无法识别特殊的ACK分组（c.f.，AF）给该方法带来了一些主要缺点，例如可能丢失dupack、FIN/ACK、RST分组或携带ECN信息的分组[RFC3168]。丢失这些数据包不会显著影响网络拥塞，但会对TCP会话的性能产生负面影响。
A WFQ scheduler may assign a higher priority to interactive traffic (providing it has a mechanism to identify such traffic) and provide a fair share of the remaining capacity to the bulk traffic. In the presence of bidirectional traffic, and with a suitable scheduling policy, this may ensure fairer sharing for ACK and data packets. An increased forward transmission rate is achieved over asymmetric links
WFQ调度器可以将更高的优先级分配给交互流量（前提是它具有识别此类流量的机制），并将剩余容量的公平份额提供给批量流量。在存在双向通信量的情况下，并且使用合适的调度策略，这可以确保更公平地共享ACK和数据分组。在非对称链路上实现了更高的前向传输速率
by an increased ACK Decimation rate, leading to generation of Stretch ACKs. As in AF, TCP sender burst size increases when Stretch ACKs are received unless other techniques are used in combination with this technique.
通过增加ACK抽取率，导致产生拉伸ACK。与在AF中一样，TCP发送方突发大小在接收到拉伸确认时增加，除非与此技术结合使用其他技术。
This technique has been deployed in specific networks (e.g., a network with high bandwidth asymmetry supporting high-speed data services to in-transit mobile hosts [Seg00]). Although not optimal, it offered a potential mitigation applicable when the TCP header is difficult to identify or not visible to the link layer (e.g., due to IPSec encryption).
该技术已部署在特定网络中（例如，具有高带宽不对称性的网络支持传输中移动主机的高速数据服务[Seg00]）。虽然不是最优的，但它提供了一种潜在的缓解措施，适用于TCP头难以识别或链路层看不到的情况（例如，由于IPSec加密）。
RECOMMENDATION: ACK Decimation uses standard router mechanisms at the upstream link interface to constrain the rate at which ACKs are fed to the upstream link. The technique is beneficial with paths having appreciable asymmetry (k>1). It is however suboptimal, in that it may lead to inefficient TCP error recovery (and hence in some cases degraded TCP performance), and provides only crude control of link behavior. It is therefore recommended that where possible, ACK Filtering should be used in preference to ACK Decimation.
建议：ACK抽取使用上游链路接口处的标准路由器机制来限制ACK馈送到上游链路的速率。对于具有明显不对称性（k>1）的路径，该技术是有益的。然而，这是次优的，因为它可能导致无效的TCP错误恢复（因此在某些情况下会降低TCP性能），并且只提供对链路行为的粗略控制。因此，建议在可能的情况下，应优先使用ACK滤波而不是ACK抽取。
When ACK Decimation is used on paths with an appreciable asymmetry (k>1) (or with bidirectional traffic) it increases the burst size of the TCP sender, use of a scheme to mitigate the effect of Stretch ACKs or control burstiness is therefore strongly recommended.
当在具有明显不对称性（k>1）（或双向通信量）的路径上使用ACK抽取时，它会增加TCP发送方的突发大小，因此强烈建议使用一种方案来减轻拉伸ACK的影响或控制突发性。
TYPE 2 mitigations perform TYPE 1 upstream link bandwidth management, but also employ a second active element which mitigates the effect of the reduced ACK rate and burstiness of ACK transmission. This is desirable when end hosts use standard TCP sender implementations (e.g., those not implementing the techniques in sections 4.6, 4.7).
类型2缓解执行类型1上游链路带宽管理，但也采用第二个有源元件，其缓解了降低的ACK速率和ACK传输突发性的影响。当终端主机使用标准TCP发送方实现时（例如，未实现第4.6节和第4.7节中技术的实现），这是可取的。
Consider a path where a TYPE 1 scheme forwards a Stretch ACK covering d TCP packets (i.e., where the acknowledgement number is d*MSS larger than the last ACK received by the TCP sender). When the TCP sender receives this ACK, it can send a burst of d (or d+1) TCP data packets. The sender is also constrained by the current cwnd. Received ACKs also serve to increase cwnd (by at most one MSS).
考虑一种路径，其中类型1方案转发覆盖D- TCP分组的扩展ACK（即，确认号码是大于TCP发送者接收的最后ACK的D*MSS）。当TCP发送方收到此ACK时，它可以发送d（或d+1）个TCP数据包的突发。发送方还受当前cwnd的约束。接收到的ack还用于增加cwnd（最多一个ms）。
A TYPE 2 scheme mitigates the impact of the reduced ACK frequency resulting when a TYPE 1 scheme is used. This is achieved by interspersing additional ACKs before each received Stretch ACK. The additional ACKs, together with the original ACK, provide the TCP sender with sufficient ACKs to allow the TCP cwnd to open in the same way as if each of the original ACKs sent by the TCP receiver had been forwarded by the reverse path. In addition, by attempting to restore
当使用类型1方案时，类型2方案减轻了降低的ACK频率的影响。这是通过在每个接收到的拉伸ACK之前插入额外的ACK来实现的。附加的ACK与原始ACK一起为TCP发送方提供足够的ACK，以允许TCP cwnd以与TCP接收方发送的每个原始ACK都已通过反向路径转发相同的方式打开。此外，通过尝试恢复
the spacing between ACKs, such a scheme can also restore the TCP self-clocking behavior, and reduce the TCP sender burst size. Such schemes need to ensure conservative behavior (i.e., should not introduce more ACKs than were originally sent) and reduce the probability of ACK Compression [ZSC91].
ACK之间的间隔，这样的方案还可以恢复TCP的自时钟行为，并减少TCP发送方的突发大小。此类方案需要确保保守行为（即，不应引入比最初发送的更多的ACK）并降低ACK压缩的概率[ZSC91]。
The action is performed at two points on the return path: the upstream link interface (where excess ACKs are removed), and a point further along the reverse path (after the bottleneck upstream link(s)), where replacement ACKs are inserted. This attempts to reconstruct the ACK stream sent by the TCP receiver when used in combination with AF (section 5.2.1), or ACK Decimation (section 5.2.2).
该操作在返回路径上的两个点执行：上游链路接口（多余的ack被移除），以及反向路径上的一个点（在瓶颈上游链路之后），插入替换ack。当与AF（第5.2.1节）或ACK抽取（第5.2.2节）结合使用时，尝试重建TCP接收器发送的ACK流。
TYPE 2 mitigations may be performed locally at the receive interface directly following the upstream bottleneck link, or may alternatively be applied at any point further along the reverse path (this is not necessarily on the forward path, since asymmetric routing may employ different forward and reverse internet paths). Since the techniques may generate multiple ACKs upon reception of each individual Stretch ACK, it is strongly recommended that the expander implements a scheme to prevent exploitation as a "packet amplifier" in a Denial-of-Service (DoS) attack (e.g., to verify the originator of the ACK). Identification of the sender could be accomplished by appropriately configured packet filters and/or by tunnel authentication procedures (e.g., [RFC2402, RFC2406]). A limit on the number of reconstructed ACKs that may be generated from a single packet may also be desirable.
类型2缓解措施可直接在上游瓶颈链路之后的接收接口本地执行，或可替代地应用于反向路径上更远的任何点（这不一定在正向路径上，因为非对称路由可采用不同的正向和反向因特网路径）。由于这些技术可以在接收到每个单独的拉伸ACK时生成多个ACK，因此强烈建议扩展器实施一种方案，以防止在拒绝服务（DoS）攻击中被利用为“分组放大器”（例如，验证ACK的发起人）。发送方的识别可以通过适当配置的分组过滤器和/或通过隧道认证过程（例如，[RFC2402，RFC2406]）来完成。对可从单个分组生成的重构ack的数量的限制也是可取的。
ACK Reconstruction (AR) [BPK99] is used in conjunction with AF (section 5.2.1). AR deploys a soft-state [Cla88] agent called an ACK Reconstructor on the reverse path following the upstream bottleneck link. The soft-state can be regenerated if lost, based on received ACKs. When a Stretch ACK is received, AR introduces additional ACKs by filling gaps in the ACK sequence. Some potential Denial-of-Service vulnerabilities may arise (section 6) and need to be addressed by appropriate security techniques.
ACK重建（AR）[BPK99]与AF一起使用（第5.2.1节）。AR在上游瓶颈链路之后的反向路径上部署一个称为ACK重构器的软状态[Cla88]代理。如果丢失，可以根据接收到的ACK重新生成软状态。当接收到拉伸ACK时，AR通过填充ACK序列中的间隙引入额外的ACK。可能会出现一些潜在的拒绝服务漏洞（第6节），需要通过适当的安全技术加以解决。
The Reconstructor determines the number of additional ACKs, by estimating the number of filtered ACKs. This uses implicit information present in the received ACK stream by observing the ACK sequence number of each received ACK. An example implementation could set an ACK threshold, ackthresh, to twice the MSS (this assumes the chosen MSS is known by the link). The factor of two corresponds
重构器通过估计过滤的ack的数量来确定附加ack的数量。这通过观察每个接收到的ACK的ACK序列号来使用接收到的ACK流中存在的隐式信息。示例实现可以将ACK阈值ackthresh设置为MSS的两倍（这假设链路知道所选MSS）。二的因子对应
to standard TCP delayed-ACK policy (d=2). Thus, if successive ACKs arrive separated by delta, the Reconstructor regenerates a maximum of ((delta/ackthresh) - 2) ACKs.
到标准TCP延迟确认策略（d=2）。因此，如果连续的ack以delta分开到达，则重构器最多重新生成（（delta/ackthresh）-2）个ack。
To reduce the TCP sender burst size and allow the cwnd to increase at a rate governed by the downstream link, the reconstructed ACKs must be sent at a consistent rate (i.e., temporal spacing between reconstructed ACKs). One method is for the Reconstructor to measure the arrival rate of ACKs using an exponentially weighted moving average estimator. This rate depends on the output rate from the upstream link and on the presence of other traffic sharing the link. The output of the estimator indicates the average temporal spacing for the ACKs (and the average rate at which ACKs would reach the TCP sender if there were no further losses or delays). This may be used by the Reconstructor to set the temporal spacing of reconstructed ACKs. The scheme may also be used in combination with TCP sender adaptation (e.g., a combination of the techniques in sections 4.6 and 4.7).
为了减小TCP发送方突发大小并允许cwnd以由下游链路控制的速率增加，必须以一致的速率（即，重构的ACK之间的时间间隔）发送重构的ACK。一种方法是重构器使用指数加权移动平均估计器测量ack的到达率。该速率取决于上游链路的输出速率以及共享该链路的其他通信量的存在。估计器的输出指示ack的平均时间间隔（以及如果没有进一步的丢失或延迟，ack到达TCP发送方的平均速率）。这可由重构器用于设置重构ack的时间间隔。该方案也可与TCP发送方适配结合使用（例如，第4.6节和第4.7节中的技术组合）。
The trade-off in AR is between obtaining less TCP sender burstiness, and a better rate of cwnd increase, with a reduction in RTT variation, versus a modest increase in the path RTT. The technique cannot perform reconstruction on connections using IPSec (AH [RFC2402] or ESP [RFC2406]), since it is unable to generate appropriate security information. It also cannot regenerate other packet header information (e.g., the exact pattern of bits carried in the IP packet ECN field [RFC3168] or the TCP RTTM option [RFC1323]).
AR中的权衡是在获得较少的TCP发送方突发性和更好的cwnd增加率之间进行的，前者减少RTT变化，而后者适度增加路径RTT。该技术无法使用IPSec（AH[RFC2402]或ESP[RFC2406]）对连接执行重建，因为它无法生成适当的安全信息。它也不能重新生成其他数据包头信息（例如，IP数据包ECN字段[RFC3168]或TCP RTTM选项[RFC1323]中携带的比特的确切模式）。
An ACK Reconstructor operates correctly (i.e., generates no spurious ACKs and preserves the end-to-end semantics of TCP), providing:
ACK重构器正常运行（即，不生成虚假ACK并保留TCP的端到端语义），提供：
(i) the TCP receiver uses ACK Delay (d=2) [RFC2581] (ii) the Reconstructor receives only in-order ACKs (iii) all ACKs are routed via the Reconstructor (iv) the Reconstructor correctly determines the TCP MSS used by the session (v) the packets do not carry additional header information (e.g., TCP RTTM option [RFC1323], IPSec using AH [RFC2402]or ESP [RFC2406]).
(i) TCP接收器使用ACK延迟（d=2）[RFC2581]（ii）重构器仅按顺序接收ACK（iii）所有ACK通过重构器路由（iv）重构器正确确定会话使用的TCP MS（v）数据包不携带额外的报头信息（例如，TCP RTTM选项[RFC1323]，使用AH[RFC2402]或ESP的IPSec）[RFC2406]）。
RECOMMENDATION: ACK Reconstruction is an experimental transparent modification performed on the reverse path following the upstream bottleneck link. It is designed to be used in conjunction with a TYPE 1 mitigation. It reduces the burst size of TCP transmission in the forward direction, which may otherwise increase when TYPE 1 schemes are used alone. It requires modification of equipment after the upstream link (including maintaining per-flow soft state). The scheme introduces implicit assumptions about the network path and has
建议：ACK重建是在上游瓶颈链路之后的反向路径上执行的实验性透明修改。设计用于与1类缓解措施结合使用。它减少了前向TCP传输的突发大小，当单独使用类型1方案时，该突发大小可能会增加。需要在上游链路后对设备进行修改（包括保持每流软状态）。该方案引入了关于网络路径的隐式假设，并且
potential Denial-of-Service vulnerabilities (i.e., acting as a packet amplifier); these need to be better understood and addressed by appropriate security techniques.
潜在的拒绝服务漏洞（即充当数据包放大器）；需要通过适当的安全技术更好地理解和解决这些问题。
Selection of appropriate algorithms to pace the ACK traffic remains an open research issue. There is also currently little experience of the implications of using such techniques in the Internet, and therefore it is recommended that this technique should not be used within the Internet in its current form.
选择合适的算法来调整ACK流量仍然是一个开放的研究问题。目前，在互联网上使用此类技术的影响方面也鲜有经验，因此建议不要以当前形式在互联网上使用此类技术。
ACK Compaction and ACK Companding [SAM99, FSS01] are techniques that operate at a point on the reverse path following the constrained ACK bottleneck. Like AR (section 5.3.1), ACK Compaction and ACK Companding are both used in conjunction with an AF technique (section 5.2.1) and regenerate filtered ACKs, restoring the ACK stream. However, they differ from AR in that they use a modified AF (known as a compactor or compressor), in which explicit information is added to all Stretch ACKs generated by the AF. This is used to explicitly synchronize the reconstruction operation (referred to here as expansion).
ACK压缩和ACK压缩[SAM99，FSS01]是在受限ACK瓶颈之后的反向路径上的一点上操作的技术。与AR（第5.3.1节）类似，ACK压缩和ACK压缩都与AF技术（第5.2.1节）结合使用，并重新生成过滤后的ACK，恢复ACK流。然而，它们与AR的不同之处在于，它们使用修改后的AF（称为压缩程序或压缩器），其中显式信息被添加到AF生成的所有拉伸ack中。这用于显式同步重建操作（此处称为扩展）。
The modified AF combines two modifications: First, when the compressor deletes an ACK from the upstream bottleneck link queue, it appends explicit information (a prefix) to the remaining ACK (this ACK is marked to ensure it is not subsequently deleted). The additional information contains details the conditions under which ACKs were previously filtered. A variety of information may be encoded in the prefix. This includes the number of ACKs deleted by the AF and the average number of bytes acknowledged. This may subsequently be used by an expander at the remote end of the tunnel. Further timing information may also be added to control the pacing of the regenerated ACKs [FSS01]. The temporal spacing of the filtered ACKs may also be encoded.
修改后的AF结合了两种修改：首先，当压缩器从上游瓶颈链路队列中删除一个ACK时，它会将显式信息（前缀）附加到剩余的ACK（该ACK被标记以确保随后不会被删除）。附加信息包含以前过滤ACK的条件的详细信息。可以在前缀中编码各种信息。这包括AF删除的ACK数和确认的平均字节数。随后可由隧道远端的扩展器使用。还可以添加进一步的定时信息以控制再生ack的步调[FSS01]。还可以对过滤的ack的时间间隔进行编码。
To encode the prefix requires the subsequent expander to recognize a modified ACK header. This would normally limit the expander to link-local operation (at the receive interface of the upstream bottleneck link). If remote expansion is needed further along the reverse path, a tunnel may be used to pass the modified ACKs to the remote expander. The tunnel introduces extra overhead, however networks with asymmetric capacity and symmetric routing frequently already employ such tunnels (e.g., in a UDLR network [RFC3077], the expander may be co-located with the feed router).
编码前缀需要后续扩展器识别修改的ACK报头。这通常会限制扩展器到链路的本地操作（在上游瓶颈链路的接收接口处）。如果需要沿反向路径进一步进行远程扩展，则可以使用隧道将修改后的ack传递给远程扩展器。隧道引入了额外的开销，但是具有非对称容量和对称路由的网络通常已经使用此类隧道（例如，在UDLR网络[RFC3077]中，扩展器可能与馈送路由器位于同一位置）。
ACK expansion uses a stateless algorithm to expand the ACK (i.e., each received packet is processed independently of previously received packets). It uses the prefix information together with the acknowledgment field in the received ACK, to produce an equivalent number of ACKs to those previously deleted by the compactor. These ACKs are forwarded to the original destination (i.e., the TCP sender), preserving normal TCP ACK clocking. In this way, ACK Compaction, unlike AR, is not reliant on specific ACK policies, nor must it see all ACKs associated with the reverse path (e.g., it may be compatible with schemes such as DAASS [RFC2760]).
ACK扩展使用无状态算法来扩展ACK（即，每个接收到的分组独立于先前接收到的分组进行处理）。它将前缀信息与接收到的ACK中的确认字段一起使用，以生成与压缩程序先前删除的确认数量相等的确认。这些ACK被转发到原始目的地（即TCP发送方），保持正常的TCP ACK时钟。这样，与AR不同，ACK压缩不依赖于特定的ACK策略，也不必查看与反向路径相关的所有ACK（例如，它可能与DAASS[RFC2760]等方案兼容）。
Some potential Denial-of-Service vulnerabilities may arise (section 6) and need to be addressed by appropriate security techniques. The technique cannot perform reconstruction on connections using IPSec, since they are unable to regenerate appropriate security information. It is possible to explicitly encode IPSec security information from suppressed packets, allowing operation with IPSec AH, however this remains an open research issue, and implies an additional overhead per ACK.
可能会出现一些潜在的拒绝服务漏洞（第6节），需要通过适当的安全技术加以解决。该技术无法使用IPSec对连接执行重建，因为它们无法重新生成适当的安全信息。可以从受抑制的数据包显式编码IPSec安全信息，允许使用IPSec AH进行操作，但是这仍然是一个开放的研究问题，并且意味着每个ACK都会有额外的开销。
RECOMMENDATION: ACK Compaction and Companding are experimental transparent modifications performed on the reverse path following the upstream bottleneck link. They are designed to be used in conjunction with a modified TYPE 1 mitigation and reduce the burst size of TCP transmission in the forward direction, which may otherwise increase when TYPE 1 schemes are used alone.
建议：ACK压缩和压扩是在上游瓶颈链路之后的反向路径上执行的实验性透明修改。它们被设计为与改进的1型缓解措施结合使用，并减少前向TCP传输的突发大小，否则单独使用1型方案时可能会增加突发大小。
The technique is desirable, but requires modification of equipment after the upstream bottleneck link (including processing of a modified ACK header). Selection of appropriate algorithms to pace the ACK traffic also remains an open research issue. Some potential Denial-of-Service vulnerabilities may arise with any device that may act as a packet amplifier. These need to be addressed by appropriate security techniques. There is little experience of using the scheme over Internet paths. This scheme is a subject of ongoing research and is not recommended for use within the Internet in its current form.
该技术是可取的，但需要在上游瓶颈链路之后修改设备（包括处理修改的ACK报头）。选择合适的算法来调整ACK流量也是一个开放的研究问题。任何用作数据包放大器的设备都可能出现一些潜在的拒绝服务漏洞。这些需要通过适当的安全技术加以解决。在互联网路径上使用该方案的经验很少。该方案是一个正在进行的研究主题，不建议以当前形式在互联网中使用。
The bursts of data packets generated when a Type 1 scheme is used on the reverse direction path may be mitigated by introducing a router supporting Generic Traffic Shaping (GTS) on the forward path [Seg00]. GTS is a standard router mechanism implemented in many deployed routers. This technique does not eliminate the bursts of data generated by the TCP sender, but attempts to smooth out the bursts by employing scheduling and queuing techniques, producing traffic which resembles that when TCP Pacing is used (section 4.6). These
当在反向路径上使用类型1方案时生成的数据分组的突发可以通过在正向路径[Seg00]上引入支持通用业务整形（GTS）的路由器来减轻。GTS是在许多已部署路由器中实现的标准路由器机制。该技术不会消除TCP发送方生成的突发数据，但试图通过使用调度和排队技术来平滑突发数据，从而产生与使用TCP起搏时类似的流量（第4.6节）。这些
techniques require maintaining per-flow soft-state in the router, and increase per-packet processing overhead. Some additional buffer capacity is needed to queue packets being shaped.
这些技术需要在路由器中保持每流软状态，并增加每包处理开销。需要一些额外的缓冲区容量来对正在成形的数据包进行排队。
To perform GTS, the router needs to select appropriate traffic shaping parameters, which require knowledge of the network policy, connection behavior and/or downstream bottleneck characteristics. GTS may also be used to enforce other network policies and promote fairness between competing TCP connections (and also UDP and multicast flows). It also reduces the probability of ACK Compression [ZSC91].
要执行GTS，路由器需要选择适当的流量整形参数，这需要了解网络策略、连接行为和/或下游瓶颈特征。GTS还可用于实施其他网络策略并促进竞争TCP连接（以及UDP和多播流）之间的公平性。它还降低了ACK压缩的概率[ZSC91]。
The smoothing of packet bursts reduces the impact of the TCP transmission bursts on routers and hosts following the point at which GTS is performed. It is therefore desirable to perform GTS near to the sending host, or at least at a point before the first forward path bottleneck router.
分组突发的平滑减少了TCP传输突发在GTS执行点之后对路由器和主机的影响。因此，希望在发送主机附近或至少在第一前向路径瓶颈路由器之前的点执行GTS。
RECOMMENDATIONS: Generic Traffic Shaping (GTS) is a transparent technique employed at a router on the forward path. The algorithms to implement GTS are available in widely deployed routers and may be used on an Internet link, but do imply significant additional per-packet processing cost.
建议：通用流量整形（GTS）是路由器在前向路径上采用的一种透明技术。用于实现GTS的算法可在广泛部署的路由器中使用，并可在互联网链路上使用，但确实意味着每包处理成本的显著增加。
Configuration of a GTS is a policy decision of a network service provider. When appropriately configured the technique will reduce size of TCP data packet bursts, mitigating the effects of Type 1 techniques. GTS is recommended for use in the Internet in conjunction with type 1 techniques such as ACK Filtering (section 5.2.1) and ACK Decimation (section 5.2.2).
GTS的配置是网络服务提供商的决策。当适当配置时，该技术将减少TCP数据包突发的大小，减轻类型1技术的影响。建议将GTS与ACK过滤（第5.2.1节）和ACK抽取（第5.2.2节）等1类技术一起用于互联网。
Many of the above schemes imply using per flow queues (or per connection queues in the case of TCP) at the upstream bottleneck link. Per-flow queuing (e.g., FQ, CBQ) offers benefit when used on any slow link (where the time to transmit a packet forms an appreciable part of the path RTT) [RFC3150]. Type 3 schemes offer additional benefit when used with one of the above techniques.
上述许多方案意味着在上游瓶颈链路上使用每流队列（或TCP情况下的每连接队列）。每流排队（例如，FQ、CBQ）在任何慢速链路上使用时都有好处（其中传输数据包的时间构成路径RTT的一个可观部分）[RFC3150]。当与上述技术之一一起使用时，类型3方案提供了额外的好处。
When bidirectional traffic exists in a bandwidth asymmetric network competing ACK and packet data flows along the return path may degrade the performance of both upstream and downstream flows [KVR98]. Therefore, it is highly desirable to use a queuing strategy combined with a scheduling mechanism at the upstream link. This has also been called priority-based multiplexing [RFC3135].
当带宽不对称网络中存在双向流量时，沿返回路径竞争ACK和分组数据流可能会降低上游和下游流的性能[KVR98]。因此，非常希望在上游链路处使用与调度机制相结合的排队策略。这也被称为基于优先级的多路复用[RFC3135]。
On a slow upstream link, appreciable jitter may be introduced by sending large data packets ahead of ACKs [RFC3150]. A simple scheme may be implemented using per-flow queuing with a fair scheduler (e.g., round robin service to all flows, or priority scheduling). A modified scheduler [KVR98] could place a limit on the number of ACKs a host is allowed to transmit upstream before transmitting a data packet (assuming at least one data packet is waiting in the upstream link queue). This guarantees at least a certain minimum share of the capacity to flows in the reverse direction, while enabling flows in the forward direction to improve TCP throughput.
在缓慢的上行链路上，通过在ack之前发送大数据包[RFC3150]，可能会引入明显的抖动。可以使用具有公平调度器的每流队列（例如，对所有流的循环服务或优先级调度）来实现简单方案。修改后的调度器[KVR98]可以在发送数据包之前限制主机允许向上游发送的ACK数量（假设至少有一个数据包在上游链路队列中等待）。这保证了反向流至少有一定的最小容量份额，同时使正向流能够提高TCP吞吐量。
Bulk (payload) compression, a small MTU, link level transparent fragmentation [RFC1991, RFC2686] or link level suspend/resume capability (where higher priority frames may pre-empt transmission of lower priority frames) may be used to mitigate the impact (jitter) of bidirectional traffic on low speed links [RFC3150]. More advanced schemes (e.g., WFQ) may also be used to improve the performance of transfers with multiple ACK streams such as http [Seg00].
大容量（有效负载）压缩、小型MTU、链路级透明分段[RFC1991、RFC2686]或链路级挂起/恢复能力（其中高优先级帧可抢占低优先级帧的传输）可用于减轻低速链路上双向通信量的影响（抖动）[RFC3150]。更高级的方案（例如，WFQ）也可用于改进具有多个ACK流（例如http[Seg00]）的传输的性能。
RECOMMENDATION: Per-flow queuing is a transparent modification performed at the upstream bottleneck link. Per-flow (or per-class) scheduling does not impact the congestion behavior of the Internet, and may be used on any Internet link. The scheme has particular benefits for slow links. It is widely implemented and widely deployed on links operating at less than 2 Mbps. This is recommended as a mitigation on its own or in combination with one of the other described techniques.
建议：每流排队是在上游瓶颈链路上执行的透明修改。每流（或每类）调度不会影响Internet的拥塞行为，并且可以在任何Internet链路上使用。该方案对慢速链接有特别的好处。它被广泛实施并广泛部署在以低于2Mbps的速率运行的链路上。建议将其单独作为缓解措施，或与所述其他技术之一结合使用。
ACKs-first Scheduling is an experimental technique to improve performance of bidirectional transfers. In this case data packets and ACKs compete for resources at the upstream bottleneck link [RFC3150]. A single First-In First-Out, FIFO, queue for both data packets and ACKs could impact the performance of forward transfers. For example, if the upstream bottleneck link is a 28.8 kbps dialup line, the transmission of a 1 Kbyte sized data packet would take about 280 ms. So even if just two such data packets get queued ahead of ACKs (not an uncommon occurrence since data packets are sent out in pairs during slow start), they would shut out ACKs for well over half a second. If more than two data packets are queued up ahead of an ACK, the ACKs would be delayed by even more [RFC3150].
ACKs优先调度是一种提高双向传输性能的实验技术。在这种情况下，数据包和ack在上游瓶颈链路[RFC3150]上争夺资源。数据包和ACK的单一先进先出（FIFO）队列可能会影响前向传输的性能。例如，如果上游瓶颈链路是28.8 kbps拨号线路，则1 Kbyte大小的数据包的传输将需要约280 ms。因此，即使只有两个这样的数据包在ack之前排队（由于数据包在慢启动期间成对发送，这种情况并不少见），他们会把阿克斯关在外面超过半秒钟。如果在ACK之前有两个以上的数据包排队，则ACK将延迟更多[RFC3150]。
A possible approach to alleviating this is to schedule data and ACKs differently from FIFO. One algorithm, in particular, is ACKs-first scheduling, which accords a higher priority to ACKs over data packets. The motivation for such scheduling is that it minimizes the idle time for the forward connection by minimizing the time that ACKs
缓解这一问题的一种可能方法是以不同于FIFO的方式调度数据和ACK。特别是一种算法是ACKs优先调度，它赋予ACKs比数据包更高的优先级。这种调度的动机是通过最小化确认时间来最小化前向连接的空闲时间
spend queued behind data packets at the upstream link. At the same time, with Type 0 techniques such as header compression [RFC1144], the transmission time of ACKs becomes small enough that the impact on subsequent data packets is minimal. (Subnetworks in which the per-packet overhead of the upstream link is large, e.g., packet radio subnetworks, are an exception, section 3.2.) This scheduling scheme does not require the upstream bottleneck router/host to explicitly identify or maintain state for individual TCP connections.
在上行链路的数据包后面排队。同时，使用诸如报头压缩[RFC1144]之类的类型0技术，ack的传输时间变得足够小，以至于对后续数据分组的影响最小。（上行链路的每包开销较大的子网，例如分组无线子网，属于例外情况，第3.2节。）此调度方案不要求上行瓶颈路由器/主机明确标识或维护单个TCP连接的状态。
ACKs-first scheduling does not help avoid a delay due to a data packet in transmission. Link fragmentation or suspend/resume may be beneficial in this case.
ACKs优先调度不能帮助避免由于传输中的数据包而导致的延迟。在这种情况下，链路碎片或挂起/恢复可能是有益的。
RECOMMENDATION: ACKs-first scheduling is an experimental transparent modification performed at the upstream bottleneck link. If it is used without a mechanism (such as ACK Congestion Control (ACC), section 4.3) to regulate the volume of ACKs, it could lead to starvation of data packets. This is a performance penalty experienced by end hosts using the link and does not modify Internet congestion behavior. Experiments indicate that ACKs-first scheduling in combination with ACC is promising. However, there is little experience of using the technique in the wider Internet. Further development of the technique remains an open research issue, and therefore the scheme is not currently recommended for use within the Internet.
建议：ACKs first调度是在上游瓶颈链路上执行的实验性透明修改。如果在没有机制（如ACK拥塞控制（ACC），第4.3节）的情况下使用它来调节ACK的容量，则可能会导致数据包饥饿。这是使用链接的终端主机所遭受的性能损失，并且不会修改Internet拥塞行为。实验表明，ACKs优先调度与ACC相结合是很有前景的。然而，在更广泛的互联网上使用该技术的经验很少。该技术的进一步发展仍然是一个开放的研究问题，因此目前不建议在互联网上使用该方案。
The recommendations contained in this document do not impact the integrity of TCP, introduce new security implications to the TCP protocol, or applications using TCP.
本文档中包含的建议不会影响TCP的完整性，不会给TCP协议或使用TCP的应用程序带来新的安全隐患。
Some security considerations in the context of this document arise from the implications of using IPSec by the end hosts or routers operating along the return path. Use of IPSec prevents, or complicates, some of the mitigations. For example:
本文档上下文中的一些安全注意事项源自沿返回路径运行的终端主机或路由器使用IPSec的含义。使用IPSec会阻止或使某些缓解措施复杂化。例如：
(i) When IPSec ESP [RFC2406] is used to encrypt the IP payload, the TCP header can neither be read nor modified by intermediate entities. This rules out header compression, ACK Filtering, ACK Reconstruction, and the ACK Compaction.
(i) 当IPSec ESP[RFC2406]用于加密IP有效负载时，中间实体既不能读取也不能修改TCP头。这排除了报头压缩、ACK过滤、ACK重建和ACK压缩。
(ii) The TCP header information may be visible, when some forms of network layer security are used. For example, using IPSec AH [RFC2402], the TCP header may be read, but not modified, by intermediaries. This may in future allow extensions to support ACK Filtering, but rules out the generation of new
（ii）当使用某些形式的网络层安全性时，TCP报头信息可能是可见的。例如，使用IPSec AH[RFC2402]，TCP报头可以被中介读取，但不能被修改。这可能在将来允许扩展支持ACK过滤，但排除了生成新的
packets by intermediaries (e.g., ACK Reconstruction). The enhanced header compression scheme discussed in [RFC2507] would also work with IPSec AH.
通过中间层的数据包（例如，ACK重建）。[RFC2507]中讨论的增强的报头压缩方案也适用于IPSec AH。
There are potential Denial-of-Service (DoS) implications when using Type 2 schemes. Unless additional security mechanisms are used, a Reconstructor/expander could be exploited as a packet amplifier. A third party may inject unauthorized Stretch ACKs into the reverse path, triggering the generation of additional ACKs. These ACKs would consume capacity on the return path and processing resources at the systems along the path, including the destination host. This provides a potential platform for a DoS attack. The usual precautions must be taken to verify the correct tunnel end point, and to ensure that applications cannot falsely inject packets that expand to generate unwanted traffic. Imposing a rate limit and bound on the delayed ACK factor(d) would also lessen the impact of any undetected exploitation.
当使用类型2方案时，存在潜在的拒绝服务（DoS）影响。除非使用额外的安全机制，否则重构器/扩展器可以用作数据包放大器。第三方可能会将未经授权的扩展ack注入反向路径，从而触发生成额外ack。这些ACK将消耗返回路径上的容量以及路径沿线系统（包括目标主机）上的处理资源。这为DoS攻击提供了一个潜在的平台。必须采取通常的预防措施来验证正确的隧道端点，并确保应用程序不会错误地注入扩展以产生不需要的流量的数据包。对延迟确认系数（d）施加速率限制和限制也会减少任何未被发现的剥削的影响。
This document considers several TCP performance constraints that arise from asymmetry in the properties of the forward and reverse paths across an IP network. Such performance constraints arise, e.g., as a result of both bandwidth (capacity) asymmetry, asymmetric shared media in the reverse direction, and interactions with Media Access Control (MAC) protocols. Asymmetric capacity may cause TCP Acknowledgments (ACKs) to be lost or become inordinately delayed (e.g., when a bottleneck link is shared between many flows, or when there is bidirectional traffic). This effect may be exacerbated with media-access delays (e.g., in certain multi-hop radio subnetworks, satellite Bandwidth on Demand access). Asymmetry, and particular high asymmetry, raises a set of TCP performance issues.
本文档考虑了由于IP网络上的正向和反向路径的属性不对称而产生的几个TCP性能约束。例如，由于带宽（容量）不对称、反向非对称共享媒体以及与媒体访问控制（MAC）协议的交互作用，会产生此类性能约束。不对称容量可能导致TCP确认（ACKs）丢失或过度延迟（例如，当瓶颈链路在多个流之间共享时，或存在双向流量时）。媒体访问延迟可能会加剧这种影响（例如，在某些多跳无线电子网中，卫星带宽按需访问）。不对称性，特别是高度不对称性，引发了一系列TCP性能问题。
A set of techniques providing performance improvement is surveyed. These include techniques to alleviate ACK Congestion and techniques that enable a TCP sender to cope with infrequent ACKs without destroying TCP self-clocking. These techniques include both end-to-end, local link-layer, and subnetwork schemes. Many of these techniques have been evaluated in detail via analysis, simulation, and/or implementation on asymmetric subnetworks forming part of the Internet. There is however as yet insufficient operational experience for some techniques, and these therefore currently remain items of on-going research and experimentation.
调查了一组提供性能改进的技术。这些技术包括缓解ACK拥塞的技术和使TCP发送方能够在不破坏TCP自时钟的情况下处理不频繁的ACK的技术。这些技术包括端到端、本地链路层和子网络方案。通过分析、模拟和/或在构成互联网一部分的非对称子网上实施，对其中许多技术进行了详细评估。然而，对于某些技术，还没有足够的操作经验，因此，这些技术目前仍然是正在进行的研究和实验项目。
The following table summarizes the current recommendations. Mechanisms are classified as recommended (REC), not recommended (NOT REC) or experimental (EXP). Experimental techniques may not be well specified. These techniques will require further operational experience before they can be recommended for use in the public Internet.
下表总结了当前的建议。机制分为推荐（REC）、不推荐（not REC）或实验（EXP）。实验技术可能没有很好的规定。这些技术需要进一步的操作经验才能被推荐用于公共互联网。
The recommendations for end-to-end host modifications are summarized in table 1. This lists each technique, the section in which each technique is discussed, and where it is applied (S denotes the host sending TCP data packets in the forward direction, R denotes the host which receives these data packets).
表1总结了端到端主机修改的建议。这列出了每种技术、讨论每种技术的部分以及应用的位置（S表示正向发送TCP数据包的主机，R表示接收这些数据包的主机）。
+------------------------+-------------+------------+--------+
| Technique | Use | Section | Where |
+------------------------+-------------+------------+--------+
| Modified Delayed ACKs | NOT REC | 4.1 | TCP R |
| Large MSS & NO FRAG | REC | 4.2 | TCP SR |
| Large MSS & IP FRAG | NOT REC | 4.2 | TCP SR |
| ACK Congestion Control | EXP | 4.3 | TCP SR |
| Window Pred. Mech (WPM)| NOT REC | 4.4 | TCP R |
| Window Cwnd. Est. (ACE)| NOT REC | 4.5 | TCP R |
| TCP Sender Pacing | EXP *1 | 4.6 | TCP S |
| Byte Counting | NOT REC *2 | 4.7 | TCP S |
| Backpressure | EXP *1 | 4.8 | TCP R |
+------------------------+-------------+------------+--------+
+------------------------+-------------+------------+--------+
| Technique | Use | Section | Where |
+------------------------+-------------+------------+--------+
| Modified Delayed ACKs | NOT REC | 4.1 | TCP R |
| Large MSS & NO FRAG | REC | 4.2 | TCP SR |
| Large MSS & IP FRAG | NOT REC | 4.2 | TCP SR |
| ACK Congestion Control | EXP | 4.3 | TCP SR |
| Window Pred. Mech (WPM)| NOT REC | 4.4 | TCP R |
| Window Cwnd. Est. (ACE)| NOT REC | 4.5 | TCP R |
| TCP Sender Pacing | EXP *1 | 4.6 | TCP S |
| Byte Counting | NOT REC *2 | 4.7 | TCP S |
| Backpressure | EXP *1 | 4.8 | TCP R |
+------------------------+-------------+------------+--------+
Table 1: Recommendations concerning host modifications.
表1：关于主机修改的建议。
*1 Implementation of the technique may require changes to the internal design of the protocol stack in end hosts. *2 Dependent on a scheme for preventing excessive TCP transmission burst.
*1实现该技术可能需要更改终端主机中协议栈的内部设计*2取决于防止过度TCP传输突发的方案。
The recommendations for techniques that do not require the TCP sender and receiver to be aware of their existence (i.e., transparent techniques) are summarized in table 2. Each technique is listed along with the section in which each mechanism is discussed, and where the technique is applied (S denotes the sending interface prior to the upstream bottleneck link, R denotes receiving interface following the upstream bottleneck link).
关于不要求TCP发送方和接收方知道其存在的技术（即透明技术）的建议总结在表2中。每种技术都与讨论每种机制的章节一起列出，并且在哪里应用了该技术（S表示上游瓶颈链路之前的发送接口，R表示上游瓶颈链路之后的接收接口）。
+------------------------+-------------+------------+--------+
| Mechanism | Use | Section | Type |
+------------------------+-------------+------------+--------+
| Header Compr. (V-J) | REC *1 | 5.1.1 | 0 SR |
| Header Compr. (ROHC) | REC *1 *2 | 5.1.2 | 0 SR |
+------------------------+-------------+------------+--------+
| ACK Filtering (AF) | EXP *3 | 5.2.1 | 1 S |
| ACK Decimation | EXP *3 | 5.2.2 | 1 S |
+------------------------+-------------+------------+--------+
| ACK Reconstruction (AR)| NOT REC | 5.3.1 | 2 *4 |
| ACK Compaction/Compand.| EXP | 5.3.2 | 2 S *4 |
| Gen. Traff. Shap. (GTS)| REC | 5.3.3 | 2 *5 |
+------------------------+-------------+------------+--------+
| Fair Queueing (FQ) | REC | 5.4.1 | 3 S |
| ACKs-First Scheduling | NOT REC | 5.4.2 | 3 S |
+------------------------+-------------+------------+--------+
+------------------------+-------------+------------+--------+
| Mechanism | Use | Section | Type |
+------------------------+-------------+------------+--------+
| Header Compr. (V-J) | REC *1 | 5.1.1 | 0 SR |
| Header Compr. (ROHC) | REC *1 *2 | 5.1.2 | 0 SR |
+------------------------+-------------+------------+--------+
| ACK Filtering (AF) | EXP *3 | 5.2.1 | 1 S |
| ACK Decimation | EXP *3 | 5.2.2 | 1 S |
+------------------------+-------------+------------+--------+
| ACK Reconstruction (AR)| NOT REC | 5.3.1 | 2 *4 |
| ACK Compaction/Compand.| EXP | 5.3.2 | 2 S *4 |
| Gen. Traff. Shap. (GTS)| REC | 5.3.3 | 2 *5 |
+------------------------+-------------+------------+--------+
| Fair Queueing (FQ) | REC | 5.4.1 | 3 S |
| ACKs-First Scheduling | NOT REC | 5.4.2 | 3 S |
+------------------------+-------------+------------+--------+
Table 2: Recommendations concerning transparent modifications.
表2：关于透明修改的建议。
*1 At high asymmetry these schemes may degrade TCP performance, but are not considered harmful to the Internet. *2 Standardisation of new TCP compression protocols is the subject of ongoing work within the ROHC WG, refer to other IETF RFCs on the use of these techniques. *3 Use in the Internet is dependent on a scheme for preventing excessive TCP transmission burst. *4 Performed at a point along the reverse path after the upstream bottleneck link. *5 Performed at a point along the forward path.
*1在高度不对称的情况下，这些方案可能会降低TCP性能，但不会被认为对互联网有害*2新TCP压缩协议的标准化是ROHC工作组正在进行的工作的主题，关于这些技术的使用，请参考其他IETF RFC*3互联网的使用取决于防止过度TCP传输突发的方案*4在上游瓶颈链路之后的反向路径上的一点执行*5在前进路径上的一点执行。
This document has benefited from comments from the members of the Performance Implications of Links (PILC) Working Group. In particular, the authors would like to thank John Border, Spencer Dawkins, Aaron Falk, Dan Grossman, Randy Katz, Jeff Mandin, Rod Ragland, Ramon Segura, Joe Touch, and Lloyd Wood for their useful comments. They also acknowledge the data provided by Metricom Inc., concerning operation of their packet data network.
本文件得益于链接性能影响（PILC）工作组成员的意见。特别是，作者要感谢约翰·博德、斯宾塞·道金斯、亚伦·福克、丹·格罗斯曼、兰迪·卡茨、杰夫·曼丁、罗德·拉格兰、拉蒙·塞古拉、乔·图奇和劳埃德·伍德的有用评论。他们还确认Metricom Inc.提供的有关其分组数据网络运行的数据。
References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at http://www.rfc-editor.org/.
RFCnnnn表格的参考资料为网上提供的互联网征求意见（RFC）文件，网址为http://www.rfc-editor.org/.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed Serial Links", RFC 1144, February 1990.
[RFC1144]Jacobson，V.，“压缩低速串行链路的TCP/IP头”，RFC1144，1990年2月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]Allman，M.，Paxson，V.和W.Stevens，“TCP拥塞控制”，RFC 25811999年4月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, June 2001.
[RFC3135]Border，J.，Kojo，M.，Griner，J.，黑山，G.和Z.Shelby，“旨在缓解链路相关降级的性能增强代理”，RFC 31352001年6月。
[abc-ID] Allman, M., "TCP Congestion Control with Appropriate Byte Counting", Work in Progress.
[abc ID]Allman，M.，“具有适当字节计数的TCP拥塞控制”，正在进行中。
[All97b] Allman, M., "Fixing Two BSD TCP Bugs", Technical Report CR-204151, NASA Lewis Research Center, October 1997.
[All97b]Allman，M.，“修复两个BSD TCP漏洞”，技术报告CR-204151，NASA刘易斯研究中心，1997年10月。
[ANS01] ANSI Standard T1.413, "Network to Customer Installation Interfaces - Asymmetric Digital Subscriber Lines (ADSL) Metallic Interface", November 1998.
[ANS01]ANSI标准T1.413，“网络到客户安装接口-非对称数字用户线（ADSL）金属接口”，1998年11月。
[ASB96] Arora, V., Suphasindhu, N., Baras, J.S. and D. Dillon, "Asymmetric Internet Access over Satellite-Terrestrial Networks", Proc. AIAA: 16th International Communications Satellite Systems Conference and Exhibit, Part 1, Washington, D.C., February 25-29, 1996, pp.476-482.
[ASB96]Arora，V.，Suphasindhu，N.，Baras，J.S.和D.Dillon，“卫星地面网络上的非对称互联网接入”，Proc。AIAA：第16届国际通信卫星系统会议和展览，第一部分，华盛顿特区，1996年2月25-29日，第476-482页。
[AST00] Aggarwal, A., Savage, S., and T. Anderson, "Understanding the Performance of TCP Pacing", Proc. IEEE INFOCOM, Tel-Aviv, Israel, V.3, March 2000, pp. 1157-1165.
[AST00]Aggarwal，A.，Savage，S.，和T.Anderson，“理解TCP起搏的性能”，Proc。IEEE INFOCOM，以色列特拉维夫，第3版，2000年3月，第1157-1165页。
[Bal98] Balakrishnan, H., "Challenges to Reliable Data Transport
over Heterogeneous Wireless Networks", Ph.D. Thesis,
University of California at Berkeley, USA, August 1998.
http://nms.lcs.mit.edu/papers/hari-phd/
[Bal98] Balakrishnan, H., "Challenges to Reliable Data Transport
over Heterogeneous Wireless Networks", Ph.D. Thesis,
University of California at Berkeley, USA, August 1998.
http://nms.lcs.mit.edu/papers/hari-phd/
[BPK99] Balakrishnan, H., Padmanabhan, V. N., and R. H. Katz, "The Effects of Asymmetry on TCP Performance", ACM Mobile Networks and Applications (MONET), Vol.4, No.3, 1999, pp. 219-241. An expanded version of a paper published at Proc. ACM/IEEE Mobile Communications Conference (MOBICOM), 1997.
[BPK99]Balakrishnan，H.，Padmanabhan，V.N.，和R.H.Katz，“不对称对TCP性能的影响”，ACM移动网络和应用（MONET），第4卷，第3期，1999年，第219-241页。在Proc上发表的论文的扩充版。ACM/IEEE移动通信会议（MOBICOM），1997年。
[BPS00] Bennett, J. C., Partridge, C., and N. Schectman, "Packet Reordering is Not Pathological Network Behaviour", IEEE/ACM Transactions on Networking, Vol. 7, Issue. 6, 2000, pp.789-798.
[BPS00]Bennett，J.C.，Partridge，C.和N.Schectman，“数据包重新排序不是病态的网络行为”，IEEE/ACM网络交易，第7卷，第2期。2000年6月6日，第789-798页。
[Cla88] Clark, D.D, "The Design Philosophy of the DARPA Internet Protocols", ACM Computer Communications Review (CCR), Vol. 18, Issue 4, 1988, pp.106-114.
[Cla88]Clark，D.D.“DARPA互联网协议的设计理念”，ACM计算机通信评论（CCR），第18卷，1988年第4期，第106-114页。
[CLC99] Clausen, H., Linder, H., and B. Collini-Nocker, "Internet over Broadcast Satellites", IEEE Communications Magazine, Vol. 37, Issue. 6, 1999, pp.146-151.
[CLC99]Clausen，H.，Linder，H.，和B.Collini Nocker，“广播卫星上的互联网”，IEEE通信杂志，第37卷，第期。1999年6月6日，第146-151页。
[CLP98] Calveras, A., Linares, J., and J. Paradells, "Window Prediction Mechanism for Improving TCP in Wireless Asymmetric Links". Proc. IEEE Global Communications Conference (GLOBECOM), Sydney Australia, November 1998, pp.533-538.
[CLP98]Calveras，A.，Linares，J.，和J.Paradells，“改进无线非对称链路中TCP的窗口预测机制”。过程。IEEE全球通信会议（GLOBECOM），澳大利亚悉尼，1998年11月，第533-538页。
[CR98] Cohen, R., and Ramanathan, S., "Tuning TCP for High Performance in Hybrid Fiber Coaxial Broad-Band Access Networks", IEEE/ACM Transactions on Networking, Vol.6, No.1, 1998, pp.15-29.
[CR98]Cohen，R.和Ramanathan，S.，“在混合光纤同轴宽带接入网络中调整TCP以实现高性能”，IEEE/ACM网络交易，第6卷，第1期，1998年，第15-29页。
[DS00] Cable Television Laboratories, Inc., Data-Over-Cable
Service Interface Specifications---Radio Frequency
Interface Specification SP-RFIv1.1-I04-00407, 2000
[DS00] Cable Television Laboratories, Inc., Data-Over-Cable
Service Interface Specifications---Radio Frequency
Interface Specification SP-RFIv1.1-I04-00407, 2000
[DS01] Data-Over-Cable Service Interface Specifications, Radio Frequency Interface Specification 1.0, SP-RFI-I05-991105, Cable Television Laboratories, Inc., November 1999.
[DS01]有线数据服务接口规范，射频接口规范1.0，SP-RFI-I05-991105，有线电视实验室有限公司，1999年11月。
[DMT96] Durst, R., Miller, G., and E. Travis, "TCP Extensions for Space Communications", ACM/IEEE Mobile Communications Conference (MOBICOM), New York, USA, November 1996, pp.15- 26.
[DMT96]Durst，R.，Miller，G.和E.Travis，“空间通信的TCP扩展”，ACM/IEEE移动通信会议（MOBICOM），美国纽约，1996年11月，第15-26页。
[EN97] "Digital Video Broadcasting (DVB); DVB Specification for Data Broadcasting", European Standard (Telecommunications series) EN 301 192, 1997.
[EN97]“数字视频广播（DVB）；数据广播的DVB规范”，欧洲标准（电信系列）EN 301 192，1997。
[EN00] "Digital Video Broadcasting (DVB); Interaction Channel for Satellite Distribution Systems", Draft European Standard (Telecommunications series) ETSI, Draft EN 301 790, v.1.2.1
[EN00]“数字视频广播（DVB）；卫星分配系统的交互通道”，欧洲标准草案（电信系列）ETSI，EN 301 790草案，v.1.2.1
[FJ93] Floyd, S., and V. Jacobson, "Random Early Detection gateways for Congestion Avoidance", IEEE/ACM Transactions on Networking, Vol.1, No.4, 1993, pp.397-413.
[FJ93]Floyd，S.和V.Jacobson，“避免拥塞的随机早期检测网关”，IEEE/ACM网络交易，第1卷，第4期，1993年，第397-413页。
[FSS01] Fairhurst, G., Samaraweera, N.K.G, Sooriyabandara, M., Harun, H., Hodson, K., and R. Donardio, "Performance Issues in Asymmetric Service Provision using Broadband Satellite", IEE Proceedings on Communication, Vol.148, No.2, 2001, pp.95-99.
[FSS01]Fairhurst，G.，Samaraweera，N.K.G.，Sooriyabandara，M.，Harun，H.，Hodson，K.，和R.Donardio，“使用宽带卫星提供非对称服务的性能问题”，IEE通信会议录，第148卷，第2期，2001年，第95-99页。
[ITU01] ITU-T Recommendation E.681, "Traffic Engineering Methods For IP Access Networks Based on Hybrid Fiber/Coax System", September 2001.
[ITU01]ITU-T建议E.681，“基于混合光纤/同轴电缆系统的IP接入网络流量工程方法”，2001年9月。
[ITU02] ITU-T Recommendation G.992.1, "Asymmetrical Digital Subscriber Line (ADSL) Transceivers", July 1999.
[ITU02]ITU-T建议G.992.1，“非对称数字用户线（ADSL）收发器”，1999年7月。
[Jac88] Jacobson, V., "Congestion Avoidance and Control", Proc. ACM SIGCOMM, Stanford, CA, ACM Computer Communications Review (CCR), Vol.18, No.4, 1988, pp.314-329.
[Jac88]Jacobson，V.，“拥塞避免和控制”，过程。ACM SIGCOMM，加利福尼亚州斯坦福，ACM计算机通信评论（CCR），第18卷，第4期，1988年，第314-329页。
[Ken87] Kent C.A., and J. C. Mogul, "Fragmentation Considered Harmful", Proc. ACM SIGCOMM, USA, ACM Computer Communications Review (CCR), Vol.17, No.5, 1988, pp.390- 401.
[Ken87]Kent C.A.和J.C.Mogul，“碎片被认为是有害的”，Proc。ACM SIGCOMM，美国，《ACM计算机通信评论》（CCR），第17卷，第5期，1988年，第390-401页。
[KSG98] Krout, T., Solsman, M., and J. Goldstein, "The Effects of Asymmetric Satellite Networks on Protocols", Proc. IEEE Military Communications Conference (MILCOM), Bradford, MA, USA, Vol.3, 1998, pp.1072-1076.
[KSG98]Krout，T.，Solsman，M.，和J.Goldstein，“非对称卫星网络对协议的影响”，Proc。IEEE军事通信会议（MILCOM），美国马萨诸塞州布拉德福德，1998年第3卷，第1072-1076页。
[KVR98] Kalampoukas, L., Varma, A., and Ramakrishnan, K.K., "Improving TCP Throughput over Two-Way Asymmetric Links: Analysis and Solutions", Proc. ACM SIGMETRICS, Medison, USA, 1998, pp.78-89.
[KVR98]Kalampoukas，L.，Varma，A.，和Ramakrishnan，K.K.，“改善双向非对称链路上的TCP吞吐量：分析和解决方案”，Proc。ACM SIGMETRICS，麦迪逊，美国，1998年，第78-89页。
[LM97] Lin, D., and R. Morris, "Dynamics of Random Early Detection", Proc. ACM SIGCOMM, Cannes, France, ACM Computer Communications Review (CCR), Vol.27, No.4, 1997, pp.78-89.
[LM97]Lin，D.和R.Morris，“随机早期检测的动力学”，Proc。ACM SIGCOMM，法国戛纳，《ACM计算机通信评论》（CCR），第27卷，第4期，1997年，第78-89页。
[LMS97] Lakshman, T.V., Madhow, U., and B. Suter, "Window-based Error Recovery and Flow Control with a Slow Acknowledgement Channel: A Study of TCP/IP Performance", Proc. IEEE INFOCOM, Vol.3, Kobe, Japan, 1997, pp.1199-1209.
[LMS97]Lakshman，T.V.，Madhow，U.和B.Suter，“基于窗口的错误恢复和慢确认信道的流量控制：TCP/IP性能研究”，Proc。IEEE信息网，第3卷，日本神户，1997年，第1199-1209页。
[MJW00] Ming-Chit, I.T., Jinsong, D., and W. Wang,"Improving TCP Performance Over Asymmetric Networks", ACM SIGCOMM, ACM Computer Communications Review (CCR), Vol.30, No.3, 2000.
[MJW00]Ming Chit，I.T.，Jinsong，D.，和W.Wang，“在非对称网络上改进TCP性能”，ACM SIGCOMM，ACM计算机通信评论（CCR），第30卷，第3期，2000年。
[Pad98] Padmanabhan, V.N., "Addressing the Challenges of Web Data
Transport", Ph.D. Thesis, University of California at
Berkeley, USA, September 1998 (also Tech Report UCB/CSD-
98-1016). http://www.cs.berkeley.edu/~padmanab/phd-
thesis.html
[Pad98] Padmanabhan, V.N., "Addressing the Challenges of Web Data
Transport", Ph.D. Thesis, University of California at
Berkeley, USA, September 1998 (also Tech Report UCB/CSD-
98-1016). http://www.cs.berkeley.edu/~padmanab/phd-
thesis.html
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，R.和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC2018] Mathis, B., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]Mathis，B.，Mahdavi，J.，Floyd，S.和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[RFC2402]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[RFC2507] Degermark, M., Nordgren, B. and S. Pink, "IP Header Compression", RFC 2507, February 1999.
[RFC2507]Degermark，M.，Nordgren，B.和S.Pink，“IP头压缩”，RFC 2507，1999年2月。
[RFC2525] Paxson, V., Allman, M., Dawson, S., Heavens, I. and B. Volz, "Known TCP Implementation Problems", RFC 2525, March 1999.
[RFC2525]Paxson，V.，Allman，M.，Dawson，S.，天堂，I.和B.Volz，“已知的TCP实现问题”，RFC 25251999年3月。
[RFC2686] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC 2686, September 1999.
[RFC2686]Bormann，C.，“多链路PPP的多类扩展”，RFC2686，1999年9月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Henderson, T., Heidemann, J., Kruse, H., Ostermann, S., Scott, K., Semke, J., Touch, J. and D. Tran, "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760]奥尔曼，M.，道金斯，S.，格洛弗，D.，格林纳，J.，亨德森，T.，海德曼，J.，克鲁斯，H.，奥斯特曼，S.，斯科特，K.，塞姆克，J.，Touch，J.和D.Tran，“正在进行的与卫星相关的TCP研究”，RFC 27602000年2月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]Paxson，V.和M.Allman，“计算TCP的重传计时器”，RFC 2988，2000年11月。
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N. and Y. Zhang, "A link Layer tunneling mechanism for unidirectional links", RFC 3077, March 2001.
[RFC3077]Duros，E.，Dabbous，W.，Izumiyama，H.，Fujii，N.和Y.Zhang，“单向链路的链路层隧道机制”，RFC 3077，2001年3月。
[RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T. and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP ESP and uncompressed", RFC 3095, July 2001.
[RFC3095]Bormann，C.，Burmeister，C.，Degermark，M.，Fukushima，H.，Hannu，H.，Jonsson，E.，Hakenberg，R.，Koren，T.，Le，K.，Liu，Z.，Martenson，A.，Miyazaki，A.，Svanbro，K.，Wiebke，T.，Yoshimura，T.和H.Zheng，“鲁棒头压缩（ROHC）：框架和四个配置文件：RTP，UDP ESP和未压缩”，RFC 3095，2001年7月。
[RFC3150] Dawkins, S., Montenegro, G., Kojo, M. and V. Magret, "End-to-end Performance Implications of Slow Links", BCP 48, RFC 3150, July 2001.
[RFC3150]Dawkins，S.，黑山，G.，Kojo，M.和V.Magret，“慢链路的端到端性能影响”，BCP 48，RFC 3150，2001年7月。
[RFC3168] Ramakrishnan K., Floyd, S. and D. Black, "A Proposal to add Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan K.，Floyd，S.和D.Black，“向IP添加明确拥塞通知（ECN）的提案”，RFC 3168，2001年9月。
[Sam99] Samaraweera, N.K.G, "Return Link Optimization for Internet Service Provision Using DVB-S Networks", ACM Computer Communications Review (CCR), Vol.29, No.3, 1999, pp.4-19.
[Sam99]Samaraweera，N.K.G，“使用DVB-S网络提供互联网服务的返回链路优化”，ACM计算机通信评论（CCR），第29卷，第3期，1999年，第4-19页。
[Seg00] Segura R., "Asymmetric Networking Techniques For Hybrid Satellite Communications", NC3A, The Hague, Netherlands, NATO Technical Note 810, August 2000, pp.32-37.
[Seg00]Segura R.，“混合卫星通信的非对称网络技术”，NC3A，荷兰海牙，北约技术说明810，2000年8月，第32-37页。
[SF98] Samaraweera, N.K.G., and G. Fairhurst. "High Speed Internet Access using Satellite-based DVB Networks", Proc. IEEE International Networks Conference (INC98), Plymouth, UK, 1998, pp.23-28.
[SF98]Samaraweera，N.K.G.和G.Fairhurst。“使用基于卫星的DVB网络进行高速互联网接入”，Proc。IEEE国际网络会议（INC98），英国普利茅斯，1998年，第23-28页。
[ZSC91] Zhang, L., Shenker, S., and D. D. Clark, "Observations and Dynamics of a Congestion Control Algorithm: The Effects of Two-Way Traffic", Proc. ACM SIGCOMM, ACM Computer Communications Review (CCR), Vol 21, No 4, 1991, pp.133- 147.
[ZSC91]Zhang，L.，Shenker，S.，和D.D.Clark，“拥塞控制算法的观察和动力学：双向交通的影响”，Proc。ACM SIGCOMM，《ACM计算机通信评论》（CCR），第21卷，第4期，1991年，第133-147页。
There are no IANA considerations associated with this document.
没有与本文件相关的IANA注意事项。
Appendix - Examples of Subnetworks Exhibiting Network Path Asymmetry
附录-显示网络路径不对称的子网示例
This appendix provides a list of some subnetworks which are known to experience network path asymmetry. The asymmetry in capacity of these network paths can require mitigations to provide acceptable overall performance. Examples include the following:
本附录列出了一些已知存在网络路径不对称的子网络。这些网络路径的容量不对称可能需要缓解，以提供可接受的总体性能。例子包括：
- IP service over some wide area and local area wireless networks. In such networks, the predominant network path asymmetry arises from the hub-and-spokes architecture of the network (e.g., a single base station that communicates with multiple mobile stations), this requires a Ready To Send / Clear To Send (RTS/CTS) protocol and a Medium Access Control (MAC) protocol which needs to accommodate the significant turn-around time for the radios. A high per-packet transmission overhead may lead to significant network path asymmetry.
- 一些广域和局域网无线网络上的IP服务。在这种网络中，主要的网络路径不对称来自网络的集线器和辐条架构（例如，与多个移动站通信的单个基站），这需要准备发送/清除发送（RTS/CTS）协议和介质访问控制（MAC）协议，需要适应无线电的重要周转时间。高的每包传输开销可能导致严重的网络路径不对称。
- IP service over a forward satellite link utilizing Digital Video Broadcast (DVB) transmission [EN97] (e.g., 38-45 Mbps), and a slower upstream link using terrestrial network technology (e.g., dial-up modem, line of sight microwave, cellular radio) [CLC99]. Network path asymmetry arises from a difference in the upstream and downstream link capacities.
- 使用数字视频广播（DVB）传输[EN97]（例如，38-45 Mbps）的前向卫星链路上的IP服务，以及使用地面网络技术（例如，拨号调制解调器、视线微波、蜂窝无线电）的较慢上行链路上的IP服务[CLC99]。网络路径不对称源于上下游链路容量的差异。
- Certain military networks [KSG98] providing Internet access to in-transit or isolated hosts [Seg00] using a high capacity downstream satellite link (e.g., 2-3 Mbps) with a narrowband upstream link (e.g., 2.4-9.6 kbps) using either Demand Assigned Multiple Access (DAMA) or fixed rate satellite links. The main factor contributing to network path asymmetry is the difference in the upstream and downstream link capacities. Some differences between forward and reverse paths may arise from the way in which upstream link capacity is allocated.
- 某些军用网络[KSG98]使用高容量下行卫星链路（例如，2-3 Mbps）和窄带上行链路（例如，2.4-9.6 kbps），使用按需分配多址（DAMA）或固定速率卫星链路，为在途或隔离主机[Seg00]提供互联网接入。导致网络路径不对称的主要因素是上下游链路容量的差异。前向路径和反向路径之间的一些差异可能来自上游链路容量的分配方式。
- Most data over cable TV networks (e.g., DOCSIS [ITU01, DS00]), where the analogue channels assigned for upstream communication (i.e., in the reverse direction) are narrower and may be more noisy than those assigned for the downstream link. As a consequence, the upstream and downstream links differ in their transmission rate. For example, in DOCSIS 1.0 [DS00], the downstream transmission rate is either 27 or 52 Mbps. Upstream transmission rates may be dynamically selected to be one of a series of rates which range between 166 kbps to 9 Mbps. Operators may assign multiple upstream channels per downstream channel. Physical layer (PHY) overhead (which accompanies upstream transmissions, but is not present in the downstream link) can also increase the network path asymmetry. The Best Effort service, which is typically used to carry TCP, uses a
- 有线电视网络上的大多数数据（例如DOCSIS[ITU01，DS00]），其中分配给上游通信（即反向）的模拟信道比分配给下游链路的信道窄，并且可能噪声更大。因此，上游和下游链路的传输速率不同。例如，在DOCSIS 1.0[DS00]中，下行传输速率为27或52 Mbps。上游传输速率可以动态地选择为范围在166 kbps到9 Mbps之间的一系列速率之一。运营商可以为每个下游信道分配多个上游信道。物理层（PHY）开销（伴随上游传输，但在下游链路中不存在）也会增加网络路径不对称性。尽力而为服务（通常用于承载TCP）使用
contention/reservation MAC protocol. A cable modem (CM) sending an isolated packet (such as a TCP ACK) on the upstream link must contend with other CMs to request capacity from the central cable modem termination system (CMTS). The CMTS then grants timeslots to a CM for the upstream transmission. The CM may "piggyback" subsequent requests onto upstream packets, avoiding contention cycles; as a result, spacing of TCP ACKs can be dramatically altered due to minor variations in load of the cable data network and inter-arrival times of TCP DATA packets. Numerous other complexities may add to, or mitigate, the asymmetry in rate and access latency experienced by packets sent on the upstream link relative to downstream packets in DOCSIS. The asymmetry experienced by end hosts may also change dynamically (e.g., with network load), and when best effort services share capacity with services that have symmetric reserved capacity (e.g., IP telephony over the Unsolicited Grant service) [ITU01].
竞争/保留MAC协议。在上行链路上发送隔离数据包（如TCP ACK）的电缆调制解调器（CM）必须与其他CMs竞争，以从中央电缆调制解调器终端系统（CMTS）请求容量。然后，CMTS将时隙授予CM用于上游传输。CM可以将后续请求“背驮”到上游分组上，避免争用周期；因此，由于电缆数据网络的负载和TCP数据包的到达时间的微小变化，TCP确认的间隔可以显著改变。许多其他复杂性可增加或减轻在上游链路上发送的分组相对于DOCSIS中的下游分组所经历的速率和访问延迟的不对称性。终端主机所经历的不对称性也可能动态变化（例如，随着网络负载的变化），并且当尽力而为的服务与具有对称保留容量的服务共享容量时（例如，通过非请求授权服务的IP电话）[ITU01]。
- Asymmetric Digital Subscriber Line (ADSL), by definition, offers a downstream link transmission rate that is higher than that of the upstream link. The available rates depend upon channel quality and system configuration. For example, one widely deployed ADSL technology [ITU02, ANS01] operates at rates that are multiples of 32 kbps (up to 6.144 Mbps) in the downstream link, and up to 640 kbps for the upstream link. The network path asymmetry experienced by end hosts may be further increased when best effort services, e.g., Internet access over ADSL, share the available upstream capacity with reserved services (e.g., constant bit rate voice telephony).
- 根据定义，非对称数字用户线（ADSL）提供的下行链路传输速率高于上行链路。可用速率取决于信道质量和系统配置。例如，一种广泛部署的ADSL技术[ITU02，ANS01]在下行链路中以32 kbps（高达6.144 Mbps）的倍数运行，在上行链路中以640 kbps的倍数运行。当尽力而为的服务（例如，通过ADSL的因特网接入）与保留服务（例如，恒定比特率语音电话）共享可用的上游容量时，终端主机所经历的网络路径不对称可能进一步增加。
Authors' Addresses
作者地址
Hari Balakrishnan Laboratory for Computer Science 200 Technology Square Massachusetts Institute of Technology Cambridge, MA 02139 USA
哈里巴拉克里希南计算机科学实验室麻省理工学院科技广场200号剑桥，美国马萨诸塞州02139
Phone: +1-617-253-8713
EMail: hari@lcs.mit.edu
Web: http://nms.lcs.mit.edu/~hari/
Phone: +1-617-253-8713
EMail: hari@lcs.mit.edu
Web: http://nms.lcs.mit.edu/~hari/
Venkata N. Padmanabhan Microsoft Research One Microsoft Way Redmond, WA 98052 USA
Venkata N.Padmanabhan微软研究一路微软雷德蒙，华盛顿州98052美国
Phone: +1-425-705-2790
EMail: padmanab@microsoft.com
Web: http://www.research.microsoft.com/~padmanab/
Phone: +1-425-705-2790
EMail: padmanab@microsoft.com
Web: http://www.research.microsoft.com/~padmanab/
Godred Fairhurst Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK
哥德雷德费尔赫斯特工程部弗雷泽诺贝尔建筑阿伯丁大学阿伯丁A24 24 UE英国
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
EMail: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry
Mahesh Sooriyabandara Department of Engineering Fraser Noble Building University of Aberdeen Aberdeen AB24 3UE UK
阿伯丁大学阿弗丁Ab24 3UE英国弗雷泽诺贝尔建筑工程系
EMail: mahesh@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/mahesh
EMail: mahesh@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/mahesh
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。