Network Working Group G. Fairhurst
Request for Comments: 3366 University of Aberdeen
BCP: 62 L. Wood
Category: Best Current Practice Cisco Systems Ltd
August 2002
Network Working Group G. Fairhurst
Request for Comments: 3366 University of Aberdeen
BCP: 62 L. Wood
Category: Best Current Practice Cisco Systems Ltd
August 2002
Advice to link designers on link Automatic Repeat reQuest (ARQ)
就链路自动重复请求（ARQ）向链路设计者提供建议
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 provides advice to the designers of digital communication equipment and link-layer protocols employing link-layer Automatic Repeat reQuest (ARQ) techniques. This document presumes that the designers wish to support Internet protocols, but may be unfamiliar with the architecture of the Internet and with the implications of their design choices for the performance and efficiency of Internet traffic carried over their links.
本文件为采用链路层自动重复请求（ARQ）技术的数字通信设备和链路层协议的设计者提供建议。本文件假定设计人员希望支持互联网协议，但可能不熟悉互联网的体系结构，也不熟悉其设计选择对通过其链接传输的互联网流量的性能和效率的影响。
ARQ is described in a general way that includes its use over a wide range of underlying physical media, including cellular wireless, wireless LANs, RF links, and other types of channel. This document also describes issues relevant to supporting IP traffic over physical-layer channels where performance varies, and where link ARQ is likely to be used.
ARQ是以一种通用的方式描述的，包括它在广泛的底层物理介质上的使用，包括蜂窝无线、无线局域网、RF链路和其他类型的信道。本文档还描述了与支持物理层信道上的IP流量相关的问题，其中性能不同，并且可能使用链路ARQ。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .2
1.1 Link ARQ. . . . . . . . . . . . . . . . . . . . . . . . . . .4
1.2 Causes of Packet Loss on a Link . . . . . . . . . . . . . . .5
1.3 Why Use ARQ?. . . . . . . . . . . . . . . . . . . . . . . . .6
1.4 Commonly-used ARQ Techniques. . . . . . . . . . . . . . . . .7
1.4.1 Stop-and-wait ARQ . . . . . . . . . . . . . . . . . . . . . .7
1.4.2 Sliding-Window ARQ. . . . . . . . . . . . . . . . . . . . . .7
1.5 Causes of Delay Across a Link . . . . . . . . . . . . . . . .8
2. ARQ Persistence . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Perfectly-Persistent (Reliable) ARQ Protocols . . . . . . . 10
2.2 High-Persistence (Highly-Reliable) ARQ Protocols. . . . . . 12
2.3 Low-Persistence (Partially-Reliable) ARQ Protocols. . . . . 13
2.4 Choosing Your Persistency . . . . . . . . . . . . . . . . . 13
2.5 Impact of Link Outages. . . . . . . . . . . . . . . . . . . 14
3. Treatment of Packets and Flows. . . . . . . . . . . . . . . 15
3.1 Packet Ordering . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Using Link ARQ to Support Multiple Flows. . . . . . . . . . 16
3.3 Differentiation of Link Service Classes . . . . . . . . . . 17
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 22
8. References. . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1 Normative References. . . . . . . . . . . . . . . . . . . . 22
8.2 Informative References. . . . . . . . . . . . . . . . . . . 23
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 26
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . 27
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . .2
1.1 Link ARQ. . . . . . . . . . . . . . . . . . . . . . . . . . .4
1.2 Causes of Packet Loss on a Link . . . . . . . . . . . . . . .5
1.3 Why Use ARQ?. . . . . . . . . . . . . . . . . . . . . . . . .6
1.4 Commonly-used ARQ Techniques. . . . . . . . . . . . . . . . .7
1.4.1 Stop-and-wait ARQ . . . . . . . . . . . . . . . . . . . . . .7
1.4.2 Sliding-Window ARQ. . . . . . . . . . . . . . . . . . . . . .7
1.5 Causes of Delay Across a Link . . . . . . . . . . . . . . . .8
2. ARQ Persistence . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Perfectly-Persistent (Reliable) ARQ Protocols . . . . . . . 10
2.2 High-Persistence (Highly-Reliable) ARQ Protocols. . . . . . 12
2.3 Low-Persistence (Partially-Reliable) ARQ Protocols. . . . . 13
2.4 Choosing Your Persistency . . . . . . . . . . . . . . . . . 13
2.5 Impact of Link Outages. . . . . . . . . . . . . . . . . . . 14
3. Treatment of Packets and Flows. . . . . . . . . . . . . . . 15
3.1 Packet Ordering . . . . . . . . . . . . . . . . . . . . . . 15
3.2 Using Link ARQ to Support Multiple Flows. . . . . . . . . . 16
3.3 Differentiation of Link Service Classes . . . . . . . . . . 17
4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Security Considerations . . . . . . . . . . . . . . . . . . 21
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . 22
8. References. . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1 Normative References. . . . . . . . . . . . . . . . . . . . 22
8.2 Informative References. . . . . . . . . . . . . . . . . . . 23
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . 26
10. Full Copyright Statement. . . . . . . . . . . . . . . . . . 27
IP, the Internet Protocol [RFC791], forms the core protocol of the global Internet and defines a simple "connectionless" packet-switched network. Over the years, Internet traffic using IP has been carried over a wide variety of links, of vastly different capacities, delays and loss characteristics. In the future, IP traffic can be expected to continue to be carried over a very wide variety of new and existing link designs, again of varied characteristics.
互联网协议[RFC791]是全球互联网的核心协议，定义了一个简单的“无连接”分组交换网络。多年来，使用IP的互联网流量已通过各种各样的链路传输，容量、延迟和丢失特性差异极大。在未来，IP流量有望继续通过各种各样的新的和现有的链路设计进行传输，同样具有各种不同的特性。
A companion document [DRAFTKARN02] describes the general issues associated with link design. This document should be read in conjunction with that and with other documents produced by the Performance Implications of Link Characteristics (PILC) IETF workgroup [RFC3135, RFC3155].
配套文件[DRAFTKARN02]描述了与链路设计相关的一般问题。本文件应与该文件以及链路特性性能影响（PILC）IETF工作组[RFC3135，RFC3155]编制的其他文件一起阅读。
This document is intended for three distinct groups of readers:
本文件适用于三类不同的读者：
a. Link designers wishing to configure (or tune) a link for the IP traffic that it will carry, using standard link-layer mechanisms such as the ISO High-level Data Link Control (HDLC) [ISO4335a] or its derivatives.
a. 链路设计者希望使用标准链路层机制，如ISO高级数据链路控制（HDLC）[ISO4335a]或其衍生物，为其将承载的IP通信量配置（或调整）链路。
b. Link implementers who may wish to design new link mechanisms that perform well for IP traffic.
b. 链路实现者，他们可能希望设计新的链路机制，为IP通信量提供良好的性能。
c. The community of people using or developing TCP, UDP and related protocols, who may wish to be aware of the ways in which links can operate.
c. 使用或开发TCP、UDP和相关协议的人员社区，他们可能希望了解链路的运行方式。
The primary audiences are intended to be groups (a) and (b). Group (c) should not need to be aware of the exact details of an ARQ scheme across a single link, and should not have to consider such details for protocol implementations; much of the Internet runs across links that do not use any form of ARQ. However, the TCP/IP community does need to be aware that the IP protocol operates over a diverse range of underlying subnetworks. This document may help to raise that awareness.
主要受众为（a）组和（b）组。组（C）不需要知道跨单个链路的ARQ方案的确切细节，并且不应该考虑协议实现的这些细节；大部分互联网都是通过不使用任何形式ARQ的链接运行的。然而，TCP/IP社区确实需要意识到IP协议在不同范围的底层子网上运行。本文件可能有助于提高这种认识。
Perfect reliability is not a requirement for IP networks, nor is it a requirement for links [DRAFTKARN02]. IP networks may discard packets due to a variety of reasons entirely unrelated to channel errors, including lack of queuing space, congestion management, faults, and route changes. It has long been widely understood that perfect end-to-end reliability can be ensured only at, or above, the transport layer [SALT81].
完美的可靠性不是IP网络的要求，也不是链路的要求[DRAFTKARN02]。IP网络可能由于与信道错误完全无关的各种原因丢弃数据包，包括缺少排队空间、拥塞管理、故障和路由更改。长期以来，人们普遍认为，只有在传输层或传输层以上才能确保完美的端到端可靠性[81]。
Some familiarity with TCP, the Transmission Control Protocol [RFC793, STE94], is presumed here. TCP provides a reliable byte-stream transport service, building upon the best-effort datagram delivery service provided by the Internet Protocol. TCP achieves this by dividing data into TCP segments, and transporting these segments in IP packets. TCP guarantees that a TCP session will retransmit the TCP segments contained in any data packets that are lost along the Internet path between endhosts. TCP normally performs retransmission using its Fast Retransmit procedure, but if the loss fails to be detected (or retransmission is unsuccessful), TCP falls back to a Retransmission Time Out (RTO) retransmission using a timer [RFC2581, RFC2988]. (Link protocols also implement timers to verify integrity of the link, and to assist link ARQ.) TCP also copes with any duplication or reordering introduced by the IP network. There are a number of variants of TCP, with differing levels of sophistication in
这里假定您对TCP（传输控制协议[RFC793，STE94]）有一定的了解。TCP提供可靠的字节流传输服务，建立在互联网协议提供的尽力而为的数据报交付服务之上。TCP通过将数据划分为TCP段并在IP数据包中传输这些段来实现这一点。TCP保证TCP会话将重新传输终端主机之间沿Internet路径丢失的任何数据包中包含的TCP段。TCP通常使用其快速重传过程执行重传，但如果无法检测到丢失（或重传不成功），则TCP会使用计时器退回到重传超时（RTO）重传[RFC2581，RFC2988]。（链路协议还实现定时器，以验证链路的完整性，并协助链路ARQ。）TCP还处理IP网络引入的任何复制或重新排序。TCP有许多变体，在不同的应用程序中具有不同的复杂程度
their procedures for handling loss recovery and congestion avoidance. Far from being static, the TCP protocol is itself subject to ongoing gradual refinement and evolution, e.g., [RFC2488, RFC2760].
他们处理损失恢复和拥塞避免的程序。TCP协议本身并不是静态的，而是不断地改进和演变的，例如[RFC2488，RFC2760]。
Internet networks may reasonably be expected to carry traffic from a wide and evolving range of applications. Not all applications require or benefit from using the reliable service provided by TCP. In the Internet, these applications are carried by alternate transport protocols, such as the User Datagram Protocol (UDP) [RFC768].
可以合理地预期，互联网网络将承载来自广泛且不断发展的应用程序的流量。并非所有应用程序都需要或受益于使用TCP提供的可靠服务。在互联网上，这些应用程序由备用传输协议承载，如用户数据报协议（UDP）[RFC768]。
At the link layer, ARQ operates on blocks of data, known as frames, and attempts to deliver frames from the link sender to the link receiver over a channel. The channel provides the physical-layer connection over which the link protocol operates. In its simplest form, a channel may be a direct physical-layer connection between the two link nodes (e.g., across a length of cable or over a wireless medium). ARQ may also be used edge-to-edge across a subnetwork, where the path includes more than one physical-layer medium. Frames often have a small fixed or maximum size for convenience of processing by Medium-Access Control (MAC) and link protocols. This contrasts with the variable lengths of IP datagrams, or 'packets'. A link-layer frame may contain all, or part of, one or more IP packets. A link ARQ mechanism relies on an integrity check for each frame (e.g., strong link-layer CRC [DRAFTKARN02]) to detect channel errors, and uses a retransmission process to retransmit lost (i.e., missing or corrupted) frames.
在链路层，ARQ对称为帧的数据块进行操作，并尝试通过信道将帧从链路发送方传送到链路接收方。通道提供链路协议操作的物理层连接。在其最简单的形式中，信道可以是两个链路节点之间的直接物理层连接（例如，跨越一段电缆或通过无线介质）。ARQ还可以跨子网边对边使用，其中路径包括多个物理层介质。帧通常具有较小的固定大小或最大大小，以便通过媒体访问控制（MAC）和链路协议进行处理。这与IP数据报或“数据包”的可变长度形成对比。链路层帧可以包含一个或多个IP分组的全部或部分。链路ARQ机制依赖于对每个帧的完整性检查（例如，强链路层CRC[DRAFTKARN02]）来检测信道错误，并使用重传过程来重传丢失（即丢失或损坏）的帧。
Links may be full-duplex (allowing two-way communication over separate forward and reverse channels), half-duplex (where two-way communication uses a shared forward and reverse channel, e.g., IrDA, IEEE 802.11) or simplex (where a single channel permits communication in only one direction).
链路可以是全双工（允许在单独的前向和反向信道上进行双向通信）、半双工（其中双向通信使用共享的前向和反向信道，例如IrDA、IEEE 802.11）或单工（其中单个信道仅允许在一个方向上进行通信）。
ARQ requires both a forward and return path, and therefore link ARQ may be used over links that employ full- or half-duplex links. When a channel is shared between two or more link nodes, a link MAC protocol is required to ensure all nodes requiring transmission can gain access to the shared channel. Such schemes may add to the delay (jitter) associated with transmission of packet data and ARQ control frames.
ARQ需要转发和返回路径，因此链路ARQ可以在采用全双工或半双工链路的链路上使用。当一个信道在两个或多个链路节点之间共享时，需要链路MAC协议来确保所有需要传输的节点都可以访问共享信道。此类方案可增加与分组数据和ARQ控制帧的传输相关联的延迟（抖动）。
When using ARQ over a link where the probability of frame loss is related to the frame size, there is an optimal frame size for any specific target channel error rate. To allow for efficient use of the channel, this maximum link frame size may be considerably lower
当在帧丢失概率与帧大小相关的链路上使用ARQ时，对于任何特定的目标信道错误率都有一个最佳帧大小。为了允许有效地使用信道，该最大链路帧大小可以相当低
than the maximum IP datagram size specified by the IP Maximum Transmission Unit (MTU). Each frame will then contain only a fraction of an IP packet, and transparent implicit fragmentation of the IP datagram is used [DRAFTKARN02]. A smaller frame size introduces more frame header overhead per payload byte transported.
大于IP最大传输单元（MTU）指定的最大IP数据报大小。然后，每个帧将只包含IP数据包的一小部分，并使用IP数据报的透明隐式分段[DRAFTKARN02]。较小的帧大小会在传输的每个有效负载字节中引入更多的帧头开销。
Explicit network-layer IP fragmentation is undesirable for a variety of reasons, and should be avoided [KEN87, DRAFTKARN02]. Its use can be minimized with use of Path MTU discovery [RFC1191, RFC1435, RFC1981].
出于各种原因，显式网络层IP碎片是不可取的，应该避免[KEN87，DRAFTKARN02]。通过使用路径MTU发现[RFC1191、RFC1435、RFC1981]，可以将其使用降至最低。
Another way to reduce the frame loss rate (or reduce transmit signal power for the same rate of frame loss) is to use coding, e.g., Forward Error Correction (FEC) [LIN93].
降低帧丢失率（或针对相同的帧丢失率降低发射信号功率）的另一种方法是使用编码，例如前向纠错（FEC）[LIN93]。
FEC is commonly included in the physical-layer design of wireless links and may be used simultaneously with link ARQ. FEC schemes which combine modulation and coding also exist, and may also be adaptive. Hybrid ARQ [LIN93] combines adaptive FEC with link ARQ procedures to reduce the probability of loss of retransmitted frames. Interleaving may also be used to reduce the probability of frame loss by dispersing the occurrence of errors more widely in the channel to improve error recovery; this adds further delay to the channel's existing propagation delay.
FEC通常包括在无线链路的物理层设计中，并且可以与链路ARQ同时使用。结合调制和编码的FEC方案也存在，并且也可以是自适应的。混合ARQ[LIN93]将自适应FEC与链路ARQ过程相结合，以降低重传帧丢失的概率。交织还可用于通过更广泛地分散信道中错误的发生以改进错误恢复来降低帧丢失的概率；这会进一步增加通道现有传播延迟的延迟。
The document does not consider the use of link ARQ to support a broadcast or multicast service within a subnetwork, where a link may send a single packet to more than one recipient using a single link transmit operation. Although such schemes are supported in some subnetworks, they raise a number of additional issues not examined here.
该文档不考虑使用链路ARQ来支持子网内的广播或多播服务，其中链路可以使用单个链路发送操作向一个以上的接收者发送单个分组。尽管这些方案在一些子网中得到支持，但它们提出了一些本文未讨论的其他问题。
Links supporting stateful reservation-based quality of service (QoS) according to the Integrated Services (intserv) model are also not explicitly discussed.
根据集成服务（intserv）模型，支持基于状态保留的服务质量（QoS）的链路也没有明确讨论。
Not all packets sent to a link are necessarily received successfully by the receiver at the other end of the link. There are a number of possible causes of packet loss. These may occur as frames travel across a link, and include:
并非发送到链路的所有数据包都必须由链路另一端的接收器成功接收。有许多可能导致数据包丢失的原因。这些可能在帧穿过链接时发生，包括：
a. Loss due to channel noise, often characterised by random frame loss. Channel noise may also result from other traffic degrading channel conditions.
a. 信道噪声引起的损耗，通常以随机帧损耗为特征。信道噪声也可能由其他通信量降低的信道条件引起。
b. Frame loss due to channel interference. This interference can be random, structured, and in some cases even periodic.
b. 由于信道干扰造成的帧丢失。这种干扰可以是随机的、结构化的，在某些情况下甚至是周期性的。
c. A link outage, a period during which the link loses all or virtually all frames, until the link is restored. This is a common characteristic of some types of link, e.g., mobile cellular radio.
c. 链路中断，链路丢失所有或几乎所有帧的一段时间，直到链路恢复。这是某些类型链路的共同特征，例如移动蜂窝无线电。
Other forms of packet loss are not related to channel conditions, but include:
其他形式的分组丢失与信道条件无关，但包括：
i. Loss of a frame transmitted in a shared channel where a contention-aware MAC protocol is used (e.g., due to collision). Here, many protocols require that retransmission is deferred to promote stability of the shared channel (i.e., prevent excessive channel contention). This is discussed further in section 1.5.
i. 在使用竞争感知MAC协议的共享信道中传输的帧丢失（例如，由于冲突）。这里，许多协议要求延迟重传以促进共享信道的稳定性（即，防止过度信道争用）。这将在第1.5节中进一步讨论。
ii. Packet discards due to congestion. Queues will eventually overflow as the arrival rate of new packets to send continues to exceed the outgoing packet transmission rate over the link.
二,。由于拥塞而丢弃数据包。当要发送的新数据包的到达率继续超过链路上的传出数据包传输率时，队列最终将溢出。
iii. Loss due to implementation errors, including hardware faults and software errors. This is recognised as a common cause of packet corruption detected in the endhosts [STONE00].
iii.由于实施错误造成的损失，包括硬件故障和软件错误。这被认为是endhosts[STONE00]中检测到的数据包损坏的常见原因。
The rate of loss and patterns of loss experienced are functions of the design of the physical and link layers. These vary significantly across different link configurations. The performance of a specific implementation may also vary considerably across the same link configuration when operated over different types of channel.
损耗率和所经历的损耗模式是物理层和链路层设计的函数。这些在不同的链路配置中有很大的不同。当在不同类型的信道上操作时，特定实现的性能在相同的链路配置上也可能有相当大的差异。
Reasons that encourage considering the use of ARQ include:
鼓励考虑使用ARQ的原因包括：
a. ARQ across a single link has a faster control loop than TCP's acknowledgement control loop, which takes place over the longer end-to-end path over which TCP must operate. It is therefore possible for ARQ to provide more rapid retransmission of TCP segments lost on the link, at least for a reasonable number of retries [RFC3155, SALT81].
a. 跨单个链路的ARQ具有比TCP的确认控制环路更快的控制环路，后者发生在TCP必须操作的较长端到端路径上。因此，ARQ可以对链路上丢失的TCP段提供更快速的重新传输，至少可以进行合理的重试次数[RFC3155，SALT81]。
b. Link ARQ can operate on individual frames, using implicit transparent link fragmentation [DRAFTKARN02]. Frames may be much smaller than IP packets, and repetition of smaller frames containing lost or errored parts of an IP packet may improve the efficiency of the ARQ process and the efficiency of the link.
b. 链路ARQ可以使用隐式透明链路分段在单个帧上运行[DRAFTKARN02]。帧可以比IP分组小得多，并且包含IP分组的丢失或错误部分的较小帧的重复可以提高ARQ过程的效率和链路的效率。
A link ARQ procedure may be able to use local knowledge that is not available to endhosts, to optimise delivery performance for the current link conditions. This information can include information about the state of the link and channel, e.g., knowledge of the current available transmission rate, the prevailing error environment, or available transmit power in wireless links.
链路ARQ程序可能能够使用终端主机无法获得的本地知识，以优化当前链路条件下的交付性能。该信息可以包括关于链路和信道的状态的信息，例如，关于当前可用传输速率、主要错误环境或无线链路中的可用传输功率的知识。
A link ARQ protocol uses a link protocol mechanism to allow the sender to detect lost or corrupted frames and to schedule retransmission. Detection of frame loss may be via a link protocol timer, by detecting missing positive link acknowledgement frames, by receiving explicit negative acknowledgement frames and/or by polling the link receiver status.
链路ARQ协议使用链路协议机制来允许发送方检测丢失或损坏的帧并安排重传。帧丢失的检测可以通过链路协议定时器、通过检测丢失的正链路确认帧、通过接收明确的负确认帧和/或通过轮询链路接收器状态来进行。
Whatever mechanisms are chosen, there are two easily-described categories of ARQ retransmission process that are widely used:
无论选择何种机制，都有两种易于描述的ARQ重传过程，它们被广泛使用：
A sender using stop-and-wait ARQ (sometimes known as 'Idle ARQ' [LIN93]) transmits a single frame and then waits for an acknowledgement from the receiver for that frame. The sender then either continues transmission with the next frame, or repeats transmission of the same frame if the acknowledgement indicates that the original frame was lost or corrupted.
使用停止并等待ARQ（有时称为“空闲ARQ”[LIN93]）的发送方发送单个帧，然后等待接收方确认该帧。然后，发送方或者继续下一帧的传输，或者如果确认指示原始帧丢失或损坏，则重复相同帧的传输。
Stop-and-wait ARQ is simple, if inefficient, for protocol designers to implement, and therefore popular, e.g., tftp [RFC1350] at the transport layer. However, when stop-and-wait ARQ is used in the link layer, it is well-suited only to links with low bandwidth-delay products. This technique is not discussed further in this document.
停止并等待ARQ对于协议设计者来说很简单，但效率很低，因此在传输层很流行，例如tftp[RFC1350]。然而，当在链路层中使用停止和等待ARQ时，它非常适合于具有低带宽延迟产品的链路。本文档中不再进一步讨论此技术。
A protocol using sliding-window link ARQ [LIN93] numbers every frame with a unique sequence number, according to a modulus. The modulus defines the numbering base for frame sequence numbers, and the size of the sequence space. The largest sequence number value is viewed by the link protocol as contiguous with the first (0), since the numbering space wraps around.
使用滑动窗口链接ARQ[LIN93]的协议根据模对每一帧使用唯一序列号进行编号。模数定义了帧序列号的编号基础和序列空间的大小。由于编号空间环绕，链路协议将最大序列号值视为与第一个（0）相邻。
TCP is itself a sliding-window protocol at the transport layer [STE94], so similarities between a link-interface-to-link-interface protocol and end-to-end TCP may be recognisable. A sliding-window link protocol is much more complex in implementation than the simpler stop-and-wait protocol described in the previous section, particularly if per-flow ordering is preserved.
TCP本身是传输层的滑动窗口协议[STE94]，因此可以识别链路接口到链路接口协议和端到端TCP之间的相似性。滑动窗口链接协议在实现上要比上一节中描述的简单的停止和等待协议复杂得多，特别是在保留每个流顺序的情况下。
At any time the link sender may have a number of frames outstanding and awaiting acknowledgement, up to the space available in its transmission window. A sufficiently-large link sender window (equivalent to or greater than the number of frames sent, or larger than the bandwidth*delay product capacity of the link) permits continuous transmission of new frames. A smaller link sender window causes the sender to pause transmission of new frames until a timeout or a control frame, such as an acknowledgement, is received. When frames are lost, a larger window, i.e., more than the link's bandwidth*delay product, is needed to allow continuous operation while frame retransmission takes place.
在任何时候，链路发送方可能有许多帧未完成并等待确认，直到其传输窗口中的可用空间为止。足够大的链路发送器窗口（等于或大于发送的帧数，或大于链路的带宽*延迟乘积容量）允许新帧的连续传输。较小的链路发送器窗口导致发送器暂停新帧的传输，直到接收到超时或控制帧（例如确认）。当帧丢失时，需要一个更大的窗口，即大于链路的带宽*延迟乘积，以允许在发生帧重传时进行连续操作。
The modulus numbering space determines the size of the frame header sequence number field. This sequence space needs to be larger than the link window size and, if using selective repeat ARQ, larger than twice the link window size. For continuous operation, the sequence space should be larger than the product of the link capacity and the link ARQ persistence (discussed in section 2), so that in-flight frames can be identified uniquely.
模数编号空间决定帧头序列号字段的大小。该序列空间需要大于链路窗口大小，如果使用选择性重复ARQ，则需要大于链路窗口大小的两倍。对于连续操作，序列空间应大于链路容量和链路ARQ持久性的乘积（在第2节中讨论），以便能够唯一地识别飞行中的帧。
As with TCP, which provides sliding-window delivery across an entire end-to-end path rather than across a single link, there are a large number of variations on the basic sliding-window implementation, with increased complexity and sophistication to make them suitable for various conditions. Selective Repeat (SR), also known as Selective Reject (SREJ), and Go-Back-N, also known as Reject (REJ), are examples of ARQ techniques using protocols implementing sliding window ARQ.
与TCP一样，TCP提供跨整个端到端路径而不是跨单个链路的滑动窗口交付，基本滑动窗口实现有大量变化，复杂性和复杂性增加，使其适合各种条件。选择性重复（SR），也称为选择性拒绝（SREJ），返回N，也称为拒绝（REJ），是使用实现滑动窗口ARQ的协议的ARQ技术的示例。
Links and link protocols contribute to the total path delay experienced between communicating applications on endhosts. Delay has a number of causes, including:
链路和链路协议会导致终端主机上通信应用程序之间的总路径延迟。延误有许多原因，包括：
a. Input packet queuing and frame buffering at the link head before transmission over the channel.
a. 在通过信道传输之前，在链路头处输入数据包队列和帧缓冲。
b. Retransmission back-off, an additional delay introduced for retransmissions by some MAC schemes when operating over a shared channel to prevent excessive contention. A high level of
b. 重传退避（Retransmission back off），在共享信道上运行时，某些MAC方案为重传引入的额外延迟，以防止过度争用。高水平的
contention may otherwise arise, if, for example, a set of link receivers all retransmitted immediately after a collision on a busy shared channel. Link ARQ protocols designed for shared channels may select a backoff delay, which increases with the number of attempts taken to retransmit a frame; analogies can be drawn with end-to-end TCP congestion avoidance at the transport layer [RFC2581]. In contrast, a link over a dedicated channel (which has capacity pre-allocated to the link) may send a retransmission at the earliest possible time.
例如，如果一组链路接收器在繁忙共享信道上发生冲突后立即重新传输，则可能会产生争用。为共享信道设计的链路ARQ协议可以选择退避延迟，退避延迟随着尝试重新传输帧的次数而增加；可以在传输层使用端到端TCP拥塞避免进行类比[RFC2581]。相反，专用信道上的链路（其具有预先分配给该链路的容量）可以在尽可能早的时间发送重传。
c. Waiting for access to the allocated channel when the channel is shared. There may be processing or protocol-induced delay before transmission takes place [FER99, PAR00].
c. 共享频道时，正在等待对已分配频道的访问。在传输发生之前，可能存在处理或协议引起的延迟[FER99，PAR00]。
d. Frame serialisation and transmission processing. These are functions of frame size and the transmission speed of the link.
d. 帧序列化和传输处理。这些是帧大小和链路传输速度的函数。
e. Physical-layer propagation time, limited by the speed of transmission of the signal in the physical medium of the channel.
e. 物理层传播时间，受信道物理介质中信号传输速度的限制。
f. Per-frame processing, including the cost of QoS scheduling, encryption, FEC and interleaving. FEC and interleaving also add substantial delay and, in some cases, additional jitter. Hybrid link ARQ schemes [LIN93], in particular, may incur significant receiver processing delay.
f. 每帧处理，包括QoS调度、加密、FEC和交织的成本。FEC和交织也会增加大量延迟，在某些情况下还会增加额外的抖动。尤其是，混合链路ARQ方案[LIN93]可能会引起显著的接收机处理延迟。
g. Packet processing, including buffering frame contents at the link receiver for packet reassembly, before onward transmission of the packet.
g. 数据包处理，包括在数据包向前传输之前，在链路接收器处为数据包重组缓冲帧内容。
When link ARQ is used, steps (b), (c), (d), (e), and (f) may be repeated a number of times, every time that retransmission of a frame occurs, increasing overall delay for the packet carried in part by the frame. Adaptive ARQ schemes (e.g., hybrid ARQ using adaptive FEC codes) may also incur extra per-frame processing for retransmitted frames.
当使用链路ARQ时，每次发生帧的重传时，步骤（b）、（c）、（d）、（e）和（f）可以重复多次，从而增加帧部分承载的分组的总延迟。自适应ARQ方案（例如，使用自适应FEC码的混合ARQ）也可能对重传帧产生额外的每帧处理。
It is important to understand that applications and transport protocols at the endhosts are unaware of the individual delays contributed by each link in the path, and only see the overall path delay. Application performance is therefore determined by the cumulative delay of the entire end-to-end Internet path. This path may include an arbitrary or even a widely-fluctuating number of links, where any link may or may not use ARQ. As a result, it is not possible to state fixed limits on the acceptable delay that a link can add to a path; other links in the path will add an unknown delay.
重要的是要了解，终端主机上的应用程序和传输协议不知道路径中每个链路造成的个别延迟，而只看到整体路径延迟。因此，应用程序性能由整个端到端Internet路径的累积延迟决定。该路径可以包括任意数量的链路，甚至是数量波动很大的链路，其中任何链路都可以使用或不使用ARQ。因此，不可能对链路可添加到路径的可接受延迟规定固定限制；路径中的其他链接将添加未知延迟。
ARQ protocols may be characterised by their persistency. Persistence is the willingness of the protocol to retransmit lost frames to ensure reliable delivery of traffic across the link.
ARQ协议的特点可能是其持久性。持久性是指协议愿意重新传输丢失的帧，以确保通过链路可靠地传输流量。
A link's retransmission persistency defines how long the link is allowed to delay a packet, in an attempt to transmit all the frames carrying the packet and its content over the link, before giving up and discarding the packet. This persistency can normally be measured in milliseconds, but may, if the link propagation delay is specified, be expressed in terms of the maximum number of link retransmission attempts permitted. The latter does not always map onto an exact time limit, for the reasons discussed in section 1.5.
链路的重传持续性定义了在放弃和丢弃数据包之前，允许链路延迟数据包的时间，以尝试通过链路传输承载数据包及其内容的所有帧。这种持续性通常可以以毫秒为单位进行测量，但如果指定了链路传播延迟，则可以用允许的最大链路重传尝试次数来表示。由于第1.5节讨论的原因，后者并不总是映射到确切的时间限制。
An example of a reliable link protocol that is perfectly persistent is the ISO HDLC protocol in the Asynchronous Balanced Mode (ABM) [ISO4335a].
完全持久的可靠链路协议的一个例子是异步平衡模式（ABM）下的ISO HDLC协议[ISO4335a]。
A protocol that only retransmits a number of times before giving up is less persistent, e.g., Ethernet [FER99], IEEE 802.11, or GSM RLP [RFC2757]. Here, lower persistence also ensures stability and fair sharing of a shared channel, even when many senders are attempting retransmissions.
在放弃之前只重新传输多次的协议不太持久，例如以太网[FER99]、IEEE 802.11或GSM RLP[RFC2757]。在这里，较低的持久性还确保了共享信道的稳定性和公平共享，即使许多发送方正在尝试重新传输。
TCP, STCP [RFC2960] and a number of applications using UDP (e.g., tftp) implement their own end-to-end reliable delivery mechanisms. Many TCP and UDP applications, e.g., streaming multimedia, benefit from timely delivery from lower layers with sufficient reliability, rather than perfect reliability with increased link delays.
TCP、STCP[RFC2960]和许多使用UDP的应用程序（例如tftp）实现了它们自己的端到端可靠传输机制。许多TCP和UDP应用程序（如流媒体）都能从较低层的及时传输中获得足够的可靠性，而不是从链路延迟增加的完美可靠性中获益。
A perfectly-persistent ARQ protocol is one that attempts to provide a reliable service, i.e., in-order delivery of packets to the other end of the link, with no missing packets and no duplicate packets. The perfectly-persistent ARQ protocol will repeat a lost or corrupted frame an indefinite (and potentially infinite) number of times until the frame is successfully received.
完美持久ARQ协议是一种尝试提供可靠服务的协议，即，在没有丢失数据包和重复数据包的情况下，将数据包有序地传送到链路的另一端。完全持久的ARQ协议将无限次（可能无限次）重复丢失或损坏的帧，直到成功接收到该帧。
If traffic is going no further than across one link, and losses do not occur within the endhosts, perfect persistence ensures reliability between the two link ends without requiring any higher-layer protocols. This reliability can become counterproductive for traffic traversing multiple links, as it duplicates and interacts with functionality in protocol mechanisms at higher layers [SALT81].
如果通信量只在一条链路上传输，并且在终端主机内不会发生丢失，则完美持久性可确保两个链路端之间的可靠性，而不需要任何更高层的协议。这种可靠性可能对通过多个链路的流量产生反作用，因为它在更高层复制协议机制中的功能并与之交互[81]。
Arguments against the use of perfect persistence for IP traffic include:
反对对IP流量使用完美持久性的论点包括：
a. Variable link delay; the impact of ARQ introduces a degree of jitter, a function of the physical-layer delay and frame serialisation and transmission times (discussed in section 1.5), to all flows sharing a link performing frame retransmission.
a. 可变链路延迟；ARQ的影响将一定程度的抖动（物理层延迟、帧序列化和传输时间的函数）（在第1.5节中讨论）引入共享链路执行帧重传的所有流。
b. Perfect persistence does not provide a clear upper bound on the maximum retransmission delay for the link. Significant changes in path delay caused by excessive link retransmissions may lead to timeouts of TCP retransmission timers, although a high variance in link delay and the resulting overall path delay may also cause a large TCP RTO value to be selected [LUD99b, PAR00]. This will alter TCP throughput, decreasing overall performance, but, in mitigation, it can also decrease the occurrence of timeouts due to continued packet loss.
b. 完美持久性不能为链路的最大重传延迟提供明确的上限。过度链路重传导致的路径延迟的显著变化可能导致TCP重传计时器超时，尽管链路延迟的高变化和由此产生的总体路径延迟也可能导致选择较大的TCP RTO值[LUD99b，PAR00]。这将改变TCP吞吐量，降低总体性能，但作为缓解措施，它还可以减少由于持续的数据包丢失而导致的超时。
c. Applications needing perfectly-reliable delivery can implement a form of perfectly-persistent ARQ themselves, or use a reliable transport protocol within the endhosts. Implementing perfect persistence at each link along the path between the endhosts is redundant, but cannot ensure the same reliability as end-to-end transport [SALT81].
c. 需要完全可靠传输的应用程序本身可以实现一种完全持久的ARQ，或者在终端主机内使用可靠的传输协议。在终端主机之间的路径上的每条链路上实现完美持久性是多余的，但无法确保与端到端传输相同的可靠性[81]。
d. Link ARQ should not adversely delay the flow of end-to-end control information. As an example, the ARQ retransmission of data for one or more flows should not excessively extend the protocol control loops. Excessive delay of duplicate TCP acknowledgements (dupacks [STE94, BAL97]), SACK, or Explicit Congestion Notification (ECN) indicators will reduce the responsiveness of TCP flows to congestion events. Similar issues exist for TCP-Friendly Rate Control (TFRC), where equation-based congestion control is used with UDP [DRAFTHAN01].
d. 链路ARQ不应对端到端控制信息流造成不利延迟。例如，一个或多个流的数据的ARQ重传不应过度扩展协议控制循环。重复TCP确认（dupacks[STE94，BAL97]）、SACK或显式拥塞通知（ECN）指示器的过度延迟将降低TCP流对拥塞事件的响应。TCP友好速率控制（TFRC）也存在类似的问题，基于等式的拥塞控制与UDP[DRAFTHAN01]一起使用。
Perfectly-persistent link protocols that perform unlimited ARQ, i.e., that continue to retransmit frames indefinitely until the frames are successfully received, are seldom found in real implementations.
在实际实现中很少发现执行无限制ARQ的完美持久链路协议，即在成功接收帧之前无限期地继续重新传输帧。
Most practical link protocols give up retransmission at some point, but do not necessarily do so with the intention of bounding the ARQ retransmission persistence. A protocol may, for instance, terminate retransmission after a link connection failure, e.g., after no frames have been successfully received within a pre-configured timer period. The number of times a protocol retransmits a specific frame (or the maximum number of retransmissions) therefore becomes a function of many different parameters (ARQ procedure, link timer values, and procedure for link monitoring), rather than being pre-configured.
大多数实用的链路协议在某一点上放弃重传，但这样做并不一定是为了限制ARQ重传持久性。例如，协议可以在链路连接失败之后（例如，在预先配置的定时器周期内没有成功接收到帧之后）终止重传。协议重新传输特定帧的次数（或最大重新传输次数）因此成为许多不同参数（ARQ过程、链路定时器值和链路监控过程）的函数，而不是预先配置的。
Another common feature of this type of behaviour is that some protocol implementers presume that, after a link failure, packets queued to be sent over the link are no longer significant and can be discarded when giving up ARQ retransmission.
这种行为的另一个常见特征是，一些协议实现者假定，在链路故障后，排队等待通过链路发送的数据包不再重要，并且在放弃ARQ重传时可以丢弃。
Examples of ARQ protocols that are perfectly persistent include ISO/ITU-T LAP-B [ISO7776] and ISO HDLC in the Asynchronously Balanced Mode (ABM) [ISO4335a], e.g., using Multiple Selective Reject (MSREJ [ISO4335b]). These protocols will retransmit a frame an unlimited number of times until receipt of the frame is acknowledged.
完全持久的ARQ协议示例包括异步平衡模式（ABM）[ISO4335a]下的ISO/ITU-T LAP-B[ISO7776]和ISO HDLC，例如，使用多选择拒绝（MSREJ[ISO4335b]）。这些协议将无限次地重新传输一个帧，直到确认接收到该帧为止。
High-persistence ARQ protocols limit the number of times (or number of attempts) that ARQ may retransmit a particular frame before the sender gives up on retransmission of the missing frame and moves on to forwarding subsequent buffered in-sequence frames. Ceasing retransmission of a frame does not imply a lack of link connectivity and does not cause a link protocol state change.
高持久性ARQ协议限制了ARQ在发送方放弃重新传输丢失的帧并继续转发后续按顺序缓冲的帧之前重新传输特定帧的次数（或尝试次数）。停止帧的重新传输并不意味着缺乏链路连接，也不会导致链路协议状态改变。
It has been recommended that a single IP packet should never be delayed by the network for more than the Maximum Segment Lifetime (MSL) of 120 seconds defined for TCP [RFC1122]. It is, however, difficult in practice to bound the maximum path delay of an Internet path. One case where segment (packet) lifetime may be significant is where alternate paths of different delays exist between endhosts and route flapping or flow-unaware traffic engineering is used. Some TCP packets may follow a short path, while others follow a much longer path, e.g., using persistent ARQ over a link outage.
建议网络对单个IP数据包的延迟不得超过为TCP定义的120秒的最大段生存期（MSL）[RFC1122]。然而，在实践中很难限制Internet路径的最大路径延迟。段（数据包）寿命可能很重要的一种情况是，端主机之间存在不同延迟的备用路径，并且使用了路由抖动或流不感知流量工程。一些TCP数据包可能遵循较短的路径，而另一些则遵循更长的路径，例如，在链路中断期间使用持久ARQ。
Failure to limit the maximum packet lifetime can result in TCP sequence numbers wrapping at high transmission rates, where old data segments may be confused with newer segments if the sequence number space has been exhausted and reused in the interim. Some TCP implementations use the Round Trip Timestamp Measurement (RTTM) option in TCP packets to remove this ambiguity, using the Protection Against Wrapped Sequence number (PAWS) algorithm [RFC1323].
未能限制最大数据包生存期可能导致TCP序列号以高传输速率包装，如果序列号空间已耗尽并在此期间重新使用，则旧数据段可能与新数据段混淆。一些TCP实现在TCP数据包中使用往返时间戳测量（RTTM）选项来消除这种模糊性，使用保护包裹序列号（PAWS）算法[RFC1323]。
In practice, the MSL is usually very large compared to the typical TCP RTO. The calculation of TCP RTO is based on estimated round-trip path delay [RFC2988]. If the number of link retransmissions causes a path delay larger than the value of RTO, the TCP retransmission timer can expire, leading to a timeout and retransmission of a segment (packet) by the TCP sender.
实际上，与典型的TCP RTO相比，MSL通常非常大。TCP RTO的计算基于估计的往返路径延迟[RFC2988]。如果链路重新传输的次数导致路径延迟大于RTO的值，TCP重新传输计时器可能会过期，导致TCP发送方超时并重新传输段（数据包）。
Although high persistency may benefit bulk flows, the additional delay (and variations in delay) that it introduces may be highly undesirable for other types of flows. Being able to treat flows separately, with different classes of link service, is useful, and is discussed in section 3.
尽管高持久性可能有利于批量流，但它引入的额外延迟（以及延迟的变化）对于其他类型的流来说可能是非常不可取的。能够使用不同类别的链接服务分别处理流是很有用的，这将在第3节中讨论。
Examples of high-persistence ARQ protocols include [BHA97, ECK98, LUD99a, MEY99].
高持久性ARQ协议的示例包括[BHA97、ECK98、LUD99a、MEY99]。
The characteristics of a link using a low-persistence ARQ protocol may be summarised as:
使用低持久性ARQ协议的链路的特征可总结为：
a. The link is not perfectly reliable and does not provide an absolute guarantee of delivery, i.e., the transmitter will discard some frames as it 'gives up' before receiving an acknowledgement of successful transmission across the link.
a. 链路不是完全可靠的，也不能提供绝对的传输保证，即发射机在接收到链路上成功传输的确认之前“放弃”了一些帧。
b. There is a lowered limit on the maximum added delay that IP packets will experience when travelling across the link (typically lower than the TCP path RTO). This reduces interaction with TCP timers or with UDP-based error-control schemes.
b. IP数据包在链路上传输时所经历的最大附加延迟有一个较低的限制（通常低于TCP路径RTO）。这减少了与TCP定时器或基于UDP的错误控制方案的交互。
c. The link offers a low bound for the time that retransmission for any one frame can block completed transmission and assembly of other correctly and completely-received IP packets whose transmission was begun before the missing frame was sent. Limiting delay avoids aggravating contention or interaction between different packet flows (see also section 3.2).
c. 链路提供了一个下限，即任何一帧的重新传输都会阻止其他正确和完全接收的IP数据包的完成传输和组装，这些数据包的传输是在发送丢失的帧之前开始的。限制延迟可避免加剧不同数据包流之间的争用或交互（另见第3.2节）。
Examples of low-persistence ARQ protocols include [SAM96, WARD95, CHE00].
低持久性ARQ协议的示例包括[SAM96、WARD95、CHE00]。
The TCP Maximum RTO is an upper limit on the maximum time that TCP will wait until it performs a retransmission. Most TCP implementations will generally have a TCP RTO of at least several times the path delay.
TCP最大RTO是TCP在执行重传之前等待的最大时间的上限。大多数TCP实现通常具有至少几倍于路径延迟的TCP RTO。
Setting a lower link persistency (e.g., of the order 2-5 retransmission attempts) reduces potential interaction with the TCP RTO timer, and may therefore reduce the probability of duplicate copies of the same packet being present in the link transmit buffer under some patterns of loss.
设置较低的链路持久性（例如，2-5次重传尝试的顺序）减少了与TCP RTO定时器的潜在交互，并且因此可以降低在某些丢失模式下链路传输缓冲器中存在相同分组的重复副本的概率。
A link using a physical layer with a low propagation delay may allow tens of retransmission attempts to deliver a single frame, and still satisfy a bound for (b) in section 2.3. In this case, a low delay is defined as being where the total packet transmission time across the link is much less than 100 ms (a common value for the granularity of the internal TCP system timer).
使用具有低传播延迟的物理层的链路可以允许数十次重传尝试来传送单个帧，并且仍然满足第2.3节中（b）的限制。在这种情况下，低延迟被定义为链路上的总数据包传输时间远小于100 ms（内部TCP系统计时器粒度的公共值）。
A packet may traverse a number of successive links on its total end-to-end path. This is therefore an argument for much lower persistency on any individual link, as delay due to persistency is accumulated along the path taken by each packet.
一个数据包可以在其总的端到端路径上穿越多个连续链路。因此，这是任何单个链路上的持续性要低得多的一个理由，因为持续性引起的延迟沿着每个数据包所采用的路径累积。
Some implementers have chosen a lower persistence, falling back on the judgement of TCP or of a UDP application to retransmit any packets that are not recovered by the link ARQ protocol.
一些实现者选择了较低的持久性，依靠TCP或UDP应用程序的判断来重新传输链路ARQ协议未恢复的任何数据包。
Links experiencing persistent loss, where many consecutive frames are corrupted over an extended time, may also need to be considered. Examples of channel behaviour leading to link outages include fading, roaming, and some forms of interference. During the loss event, there is an increased probability that a retransmission request may be corrupted, and/or an increased probability that a retransmitted frame will also be lost. This type of loss event is often known as a "transient outage".
可能还需要考虑经历持续丢失的链路，其中许多连续帧在较长时间内损坏。导致链路中断的信道行为示例包括衰落、漫游和某些形式的干扰。在丢失事件期间，重传请求可能被破坏的概率增加，和/或重传帧也将丢失的概率增加。这种类型的损失事件通常被称为“瞬时停机”。
If the transient outage extends for longer than the TCP RTO, the TCP sender will also perform transport-layer retransmission. At the same time, the TCP sender will reduce its congestion window (cwnd) to 1 segment (packet), recalculate its RTO, and wait for an ACK packet. If no acknowledgement is received, TCP will retransmit again, up to a retry limit. TCP only determines that the outage is over (i.e., that path capacity is restored) by receipt of an ACK. If link ARQ protocol persistency causes a link in the path to discard the ACK, the TCP sender must wait for the next RTO retransmission and its ACK to learn that the link is restored. This can be many seconds after the end of the transient outage.
如果瞬态中断的时间长于TCP RTO，则TCP发送方还将执行传输层重传。同时，TCP发送方将其拥塞窗口（cwnd）减少为1段（数据包），重新计算其RTO，并等待ACK数据包。如果没有收到确认，TCP将重新传输，直到重试限制。TCP仅通过接收ACK来确定中断结束（即恢复路径容量）。如果链路ARQ协议持续性导致路径中的链路丢弃ACK，则TCP发送方必须等待下一次RTO重传及其ACK，以了解链路已恢复。这可能是瞬态大修结束后的几秒钟。
When a link layer is able to differentiate a set of link service classes (see section 3.3), a link ARQ persistency longer than the largest link loss event may benefit a TCP session. This would allow TCP to rapidly restore transmission without the need to wait for a retransmission time out, generally improving TCP performance in the face of transient outages. Implementation of such schemes remains a research issue.
当链路层能够区分一组链路服务类别（参见第3.3节）时，链路ARQ持续时间长于最大链路丢失事件可能有利于TCP会话。这将允许TCP快速恢复传输，而无需等待重新传输超时，通常在遇到暂时中断时提高TCP性能。这些计划的实施仍然是一个研究问题。
When an outage occurs for a sender sharing a common channel with other nodes, uncontrolled high persistence can continue to consume transmission resources for the duration of the outage. This may be undesirable, since it reduces the capacity available for other nodes sharing the channel, which do not necessarily experience the same outage. These nodes could otherwise use the channel for more productive transfers. The persistence is often limited by another controlling mechanism in such cases. To counter such contention effects, ARQ protocols may delay retransmission requests, or defer the retransmission of requested frames until the outage ends for the sender.
当与其他节点共享公共信道的发送方发生中断时，不受控制的高持久性会在中断期间继续消耗传输资源。这可能是不可取的，因为它降低了共享信道的其他节点的可用容量，这些节点不一定会经历相同的中断。这些节点可以使用该通道进行更高效的传输。在这种情况下，持久性通常受到另一种控制机制的限制。为了对抗这种争用效应，ARQ协议可以延迟重传请求，或者延迟所请求帧的重传，直到发送方的中断结束。
An alternate suggested approach for a link layer that is able to identify separate flows is to use low link persistency (section 2.3) along with a higher-layer mechanism, for example one that attempts to deliver one packet (or whole TCP segment) per TCP flow after a loss event [DRAFTKARN02]. This is intended to ensure that TCP transmission is restored rapidly. Algorithms to implement this remain an area of research.
对于能够识别独立流的链路层，另一种建议的方法是使用低链路持久性（第2.3节）以及更高层的机制，例如，在丢失事件后，尝试为每个TCP流交付一个数据包（或整个TCP段）[DRAFTKARN02]。这是为了确保TCP传输能够快速恢复。实现这一点的算法仍然是一个研究领域。
A common debate is whether a link should be allowed to forward packets in an order different from that in which they were originally received at its transmit interface.
一个常见的争论是，是否应该允许链路以不同于最初在其传输接口接收数据包的顺序转发数据包。
IP networks are not required to deliver all IP packets in order, although in most cases networks do deliver IP packets in their original transmission order. Routers supporting class-based queuing do reorder received packets, by reordering packets in different flows, but these usually retain per-flow ordering.
IP网络不需要按顺序交付所有IP数据包，尽管在大多数情况下，网络确实按其原始传输顺序交付IP数据包。支持基于类的排队的路由器通过对不同流中的数据包重新排序，对接收到的数据包进行重新排序，但这些路由器通常保留按流排序。
Policy-based queuing, allowing fairer access to the link, may also reorder packets. There is still much debate on optimal algorithms, and on optimal queue sizes for particular link speeds. This, however, is not related to the use of link ARQ and applies to any (potential) bottleneck router.
基于策略的队列允许对链路进行更公平的访问，也可以对数据包进行重新排序。关于最优算法和特定链路速度下的最优队列大小，仍有很多争论。然而，这与链路ARQ的使用无关，适用于任何（潜在）瓶颈路由器。
Although small amounts of reordering are common in IP networks [BEN00], significant reordering within a flow is undesirable as it can have a number of effects:
虽然少量的重新排序在IP网络中很常见[BEN00]，但流中的重大重新排序是不可取的，因为它可能会产生许多影响：
a. Reordering will increase packet jitter for real-time applications. This may lead to application data loss if a small play-out buffer is used by the receiving application.
a. 重新排序将增加实时应用程序的数据包抖动。如果接收应用程序使用较小的播放缓冲区，这可能会导致应用程序数据丢失。
b. Reordering will interleave arrival of TCP segments, leading to generation of duplicate ACKs (dupacks), leading to assumptions of loss. Reception of an ACK followed by a sequence of three identical dupacks causes the TCP sender to trigger fast retransmission and recovery, a form of congestion avoidance, since TCP always presumes that packet loss is due to congestion [RFC2581, STE94]. This reduces TCP throughput efficiency as far as the application is concerned, although it should not impact data integrity.
b. 重新排序将交错TCP段的到达，导致重复ACK（DUPACK）的生成，导致丢失的假设。接收到一个ACK，然后是三个相同的dupack序列，导致TCP发送方触发快速重传和恢复，这是避免拥塞的一种形式，因为TCP总是假定数据包丢失是由于拥塞引起的[RFC2581，STE94]。就应用程序而言，这会降低TCP吞吐量效率，但不应影响数据完整性。
In addition, reordering may negatively impact processing by some existing poorly-implemented TCP/IP stacks, by leading to unwanted side-effects in poorly-implemented IP fragment reassembly code, poorly-implemented IP demultiplexing (filter) code, or in poorly-implemented UDP applications.
此外，重新排序可能会对一些现有的执行不善的TCP/IP堆栈的处理产生负面影响，导致执行不善的IP片段重组代码、执行不善的IP解复用（筛选器）代码或执行不善的UDP应用程序产生不必要的副作用。
Ordering effects must also be considered when breaking the end-to-end paradigm and evaluating transport-layer relays such as split-TCP implementations or Protocol Enhancing Proxies [RFC3135].
在打破端到端范式和评估传输层中继（如拆分TCP实现或协议增强代理）时，还必须考虑排序效应[RFC3135]。
As with total path delay, TCP and UDP flows are impacted by the cumulative effect of reordering along the entire path. Link protocol designers must not assume that their link is the only link undertaking packet reordering, as some level of reordering may be introduced by other links along the same path, or by router processing within the network [BEN00]. Ideally, the link protocol should not contribute to reordering within a flow, or at least ensure that it does not significantly increase the level of reordering within the flow. To achieve this, buffering is required at the link receiver. The total amount of buffering required is a function of the link's bandwidth*delay product and the level of ARQ persistency, and is bounded by the link window size.
与总路径延迟一样，TCP和UDP流受到沿整个路径重新排序的累积影响。链路协议设计者不得假设他们的链路是进行数据包重新排序的唯一链路，因为沿着同一路径的其他链路或网络内的路由器处理可能会引入某种级别的重新排序[BEN00]。理想情况下，链路协议不应有助于流内的重新排序，或者至少确保它不会显著增加流内的重新排序级别。为了实现这一点，需要在链路接收器处进行缓冲。所需的缓冲总量是链路带宽*延迟乘积和ARQ持续性水平的函数，并受链路窗口大小的限制。
A number of experimental ARQ protocols have allowed out-of-order delivery [BAL95, SAM96, WARD95].
许多实验性ARQ协议允许无序交付[BAL95、SAM96、WARD95]。
Most links can be expected to carry more than one IP flow at a time. Some high-capacity links are expected to carry a very large number of simultaneous flows, often from and to a large number of different endhosts. With use of multiple applications at an endhost, multiple flows can be considered the norm rather than the exception, even for last-hop links.
大多数链路一次可以承载多个IP流。一些高容量链路预计将承载大量的同步流，通常从大量不同的终端主机到大量不同的终端主机。在一个终端主机上使用多个应用程序时，可以将多个流视为规范而不是例外，即使对于最后一跳链路也是如此。
When packets from several flows are simultaneously in transit within a link ARQ protocol, ARQ may cause a number of additional effects:
当来自多个流的数据包在链路ARQ协议内同时传输时，ARQ可能会造成许多附加影响：
a. ARQ introduces variable delay (jitter) to a TCP flow sharing a link with another flow experiencing loss. This additional delay, introduced by the need for a link to provide in-sequence delivery of packets, may adversely impact other applications sharing the link, and can increase the duration of the initial slow-start period for TCP flows for these applications. This is significant for short-lived TCP flows (e.g., those used by HTTP/1.0 and earlier), which spend most of their lives in slow-start.
a. ARQ将可变延迟（抖动）引入一个TCP流，该TCP流与另一个丢失的流共享一个链路。这种额外的延迟是由于需要一条链路来提供数据包的顺序传递而引入的，它可能会对共享该链路的其他应用程序产生不利影响，并且可能会增加这些应用程序的TCP流的初始慢启动期的持续时间。这对于寿命较短的TCP流（例如HTTP/1.0和更早版本使用的TCP流）非常重要，因为它们的大部分生命都是在缓慢启动中度过的。
b. ARQ introduces jitter to UDP flows that share a link with another flow experiencing loss. An end-to-end protocol may not require reliable delivery for its flows, particularly if it is supporting a delay-sensitive application.
b. ARQ将抖动引入到与另一个丢失流共享链路的UDP流。端到端协议可能不需要可靠地传递其流，特别是当它支持对延迟敏感的应用程序时。
c. High-persistence ARQ may delay packets long enough to cause the premature timeout of another TCP flow's RTO timer, although modern TCP implementations should not experience this since their computed RTO values should leave a sufficient margin over path RTTs to cope with reasonable amounts of jitter.
c. 高持久性ARQ可能会延迟数据包足够长的时间，导致另一个TCP流的RTO计时器过早超时，尽管现代TCP实现不应该经历这种情况，因为它们计算的RTO值应该在路径RTT上留下足够的余量，以应对合理数量的抖动。
Reordering of packets belonging to different flows may be desirable [LUD99b, CHE00] to achieve fair sharing of the link between established bulk-data transfer sessions and sessions that transmit less data, but would benefit from lower link transit delay. Preserving ordering within each individual flow, to avoid the effects of reordering described earlier in section 3.1, is worthwhile.
可能需要对属于不同流的分组进行重新排序[LUD99b，CHE00]，以实现已建立的批量数据传输会话和传输较少数据的会话之间链路的公平共享，但将受益于较低的链路传输延迟。为了避免前面第3.1节所述的重新排序的影响，在每个单独的流中保留排序是值得的。
High ARQ persistency is generally considered unsuitable for many applications using UDP, where reliable delivery is not always required and where it may introduce unacceptable jitter, but may benefit bulk data transfers under certain link conditions. A scheme that differentiates packet flows into two or more classes, to provide a different service to each class, is therefore desirable.
高ARQ持久性通常被认为不适合于使用UDP的许多应用程序，在这些应用程序中，并不总是需要可靠的传输，并且可能会引入不可接受的抖动，但在某些链路条件下可能有利于批量数据传输。因此，理想的方案是将分组流区分为两个或多个类，以便为每个类提供不同的服务。
Observation of flow behaviour can tell you which flows are controlled and congestion-sensitive, or uncontrolled and not, so that you can treat them differently and ensure fairness. However, this cannot tell you whether a flow is intended as reliable or unreliable by its application, or what the application requires for best operation.
对流量行为的观察可以告诉您哪些流量是受控的，哪些是拥塞敏感的，哪些是非受控的，这样您就可以区别对待它们并确保公平性。但是，这不能告诉您流的应用程序是可靠的还是不可靠的，或者应用程序需要什么来实现最佳操作。
Supporting different link services for different classes of flows therefore requires that the link is able to distinguish the different flows from each other. This generally needs an explicit indication of the class associated with each flow.
因此，为不同类别的流支持不同的链路服务需要链路能够相互区分不同的流。这通常需要明确指示与每个流关联的类。
Some potential schemes for indicating the class of a packet include:
用于指示分组类别的一些潜在方案包括：
a. Using the Type of Service (ToS) bits in the IP header [RFC791]. The IETF has replaced these globally-defined bits, which were not widely used, with the differentiated services model (diffserv [RFC2475, RFC3260]). In diffserv, each packet carries a Differentiated Service Code Point (DSCP), which indicates which one of a set of diffserv classes the flow belongs to. Each router maps the DSCP value of a received IP packet to one of a set of Per Hop Behaviours (PHBs) as the packet is processed within the network. Diffserv uses include policy-based routing, class-based queuing, and support for other QoS metrics, including IP packet priority, delay, reliability, and cost.
a. 使用IP头中的服务类型（ToS）位[RFC791]。IETF用区分服务模型（diffserv[RFC2475，RFC3260]）取代了这些未被广泛使用的全局定义位。在diffserv中，每个数据包都携带一个区分服务代码点（DSCP），它指示流属于一组diffserv类中的哪一个。当在网络中处理数据包时，每个路由器将接收到的IP数据包的DSCP值映射到一组每跳行为（PHB）中的一个。Diffserv的用途包括基于策略的路由、基于类的排队以及对其他QoS指标的支持，包括IP数据包优先级、延迟、可靠性和成本。
b. Inspecting the network packet header and viewing the IP protocol type [RFC791] to gain an idea of the transport protocol used and thus guess its needs. This is not possible when carrying an encrypted payload, e.g., using the IP security extensions (IPSec) with Encapsulation Security Payload (ESP) [RFC2406] payload encryption.
b. 检查网络数据包头并查看IP协议类型[RFC791]，了解所使用的传输协议，从而猜测其需求。这在承载加密的有效负载时是不可能的，例如，使用IP安全扩展（IPSec）和封装安全有效负载（ESP）[RFC2406]有效负载加密。
c. By inspecting the transport packet header information to view the TCP or UDP headers and port numbers (e.g., [PAR00, BAL95]). This is not possible when using payload encryption, e.g., IPSec with ESP payload encryption [RFC2406], and incurs processing overhead for each packet sent over the link.
c. 通过检查传输数据包头信息来查看TCP或UDP头和端口号（例如，[PAR00，BAL95]）。当使用有效负载加密（例如，IPSec和ESP有效负载加密[RFC2406]）时，这是不可能的，并且会导致通过链路发送的每个数据包的处理开销。
There are, however, some drawbacks to these schemes:
然而，这些方案有一些缺点：
i. The ToS/Differentiated Services Code Point (DSCP) values [RFC2475] may not be set reliably, and may be overwritten by intermediate routers along the packet's path. These values may be set by an ISP, and do not necessarily indicate the level of reliability required by the end application. The link must be configured with knowledge of the local meaning of the values.
i. ToS/区分服务代码点（DSCP）值[RFC2475]可能无法可靠设置，并且可能会被数据包路径上的中间路由器覆盖。这些值可由ISP设置，不一定表示最终应用程序所需的可靠性水平。链接必须配置为了解值的本地含义。
ii. Tunnelling of traffic (e.g., GRE, MPLS, L2TP, IP-in-IP encapsulation) can aggregate flows of different transport classes, complicating individual flow classification with schemes (b) and (c) and incurring further header processing if tunnel contents are inspected.
二,。流量隧道（例如，GRE、MPLS、L2TP、IP-in-IP封装）可以聚合不同传输类别的流，使方案（b）和（c）中的单个流分类复杂化，如果检查隧道内容，则会导致进一步的报头处理。
iii. Use of the TCP/UDP port number makes assumptions about application behaviour and requirements. New applications or protocols can invalidate these assumptions, as can the use of e.g., Network Address Port Translation, where port numbers are remapped [RFC3022].
iii.TCP/UDP端口号的使用对应用程序行为和要求进行了假设。新的应用程序或协议可能会使这些假设失效，例如使用网络地址端口转换（其中端口号被重新映射）[RFC3022]。
iv. In IPv6, the entire IPv6 header must be parsed to locate the transport layer protocol, adding complexity to header inspection. Again, this assumes that IPSec payload encryption is not used.
iv.在IPv6中，必须解析整个IPv6报头以定位传输层协议，这增加了报头检查的复杂性。同样，这假定未使用IPSec有效负载加密。
Despite the difficulties in providing a framework for accurate flow identification, approach (a) may be beneficial, and is preferable to adding optimisations that are triggered by inspecting the contents of specific IP packets. Some such optimisations are discussed in detail in [LUD99b].
尽管在提供用于准确流识别的框架方面存在困难，但方法（a）可能是有益的，并且比添加通过检查特定IP分组的内容而触发的优化更可取。[LUD99b]中详细讨论了一些此类优化。
Flow management is desirable; clear flow identification increases the number of tools available for the link designer, and permits more complex ARQ strategies that may otherwise make misassumptions about traffic requirements and behaviour when flow identification is not done.
流程管理是可取的；清晰的流量识别增加了链路设计者可用的工具数量，并允许更复杂的ARQ策略，否则在未进行流量识别时，可能会对流量需求和行为做出错误假设。
Links that are unable to distinguish clearly and safely between delay-sensitive flows, e.g., real-time multimedia, DNS queries or telnet, and delay-insensitive flows, e.g., bulk ftp transfers or reliable multicast file transfer, cannot separate link service classes safely. All flows should therefore experience the same link behaviour.
无法清楚安全地区分延迟敏感流（如实时多媒体、DNS查询或telnet）和延迟不敏感流（如批量ftp传输或可靠多播文件传输）的链路无法安全地分离链路服务类别。因此，所有流都应该经历相同的链接行为。
In general, if separation of flows according to class is not practicable, a low persistency is best for link ARQ.
一般来说，如果按照类分离流是不可行的，那么低持久性对于链路ARQ是最好的。
A number of techniques may be used by link protocol designers to counter the effects of channel errors or loss. One of these techniques is Automatic Repeat ReQuest, ARQ, which has been and continues to be used on links that carry IP traffic. An ARQ protocol retransmits link frames that have been corrupted during transmission across a channel. Link ARQ may significantly improve the probability of successful transmission of IP packets over links prone to occasional frame loss.
链路协议设计者可以使用许多技术来对抗信道错误或丢失的影响。其中一种技术是自动重复请求ARQ，它已经并将继续用于承载IP流量的链路上。ARQ协议重新传输在跨信道传输期间损坏的链路帧。链路ARQ可以显著提高IP分组在容易偶尔发生帧丢失的链路上成功传输的概率。
A lower rate of packet loss generally benefits transport protocols and endhost applications. Applications using TCP generally benefit from Internet paths with little or no loss and low round trip path delay. This reduces impact on applications, allows more rapid growth
较低的数据包丢失率通常有利于传输协议和终端主机应用程序。使用TCP的应用程序通常受益于Internet路径，几乎没有或几乎没有损失，且往返路径延迟较低。这减少了对应用程序的影响，允许更快速的增长
of TCP's congestion window during slow start, and ensures prompt reaction to end-to-end protocol exchanges (e.g., retransmission, congestion indications). Applications using other transport protocols, e.g., UDP or SCTP, also benefit from low loss and timely delivery.
在慢速启动期间，确保TCP拥塞窗口的安全性，并确保对端到端协议交换（例如，重传、拥塞指示）做出快速反应。使用其他传输协议（如UDP或SCTP）的应用程序也可以从低损耗和及时交付中获益。
A side-effect of link ARQ is that link transit delay is increased when frames are retransmitted. At low error rates, many of the details of ARQ, such as degree of persistence or any resulting out-of-order delivery, become unimportant. Most frame losses will be resolved in one or two retransmission attempts, and this is generally unlikely to cause significant impact to e.g., TCP. However, on shared high-delay links, the impact of ARQ on other UDP or TCP flows may lead to unwanted jitter.
链路ARQ的一个副作用是，当帧被重新传输时，链路传输延迟增加。在错误率较低的情况下，ARQ的许多细节，例如持久性程度或任何由此导致的无序交付，变得不重要。大多数帧丢失将在一次或两次重传尝试中解决，这通常不太可能对TCP等造成重大影响。然而，在共享的高延迟链路上，ARQ对其他UDP或TCP流的影响可能会导致不必要的抖动。
Where error rates are highly variable, high link ARQ persistence may provide good performance for a single TCP flow. However, interactions between flows can arise when many flows share capacity on the same link. A link ARQ procedure that provides flow management will be beneficial. Lower ARQ persistence may also have merit, and is preferable for applications using UDP. The reasoning here is that the link can perform useful work forwarding some complete packets, and that blocking all flows by retransmitting the frames of a single packet with high persistence is undesirable.
在错误率高度可变的情况下，高链路ARQ持久性可以为单个TCP流提供良好的性能。但是，当多个流共享同一链路上的容量时，可能会出现流之间的交互。提供流量管理的链路ARQ程序将是有益的。较低的ARQ持久性也有其优点，对于使用UDP的应用程序更可取。这里的理由是，链路可以执行有用的工作，转发一些完整的数据包，并且通过以高持久性重新传输单个数据包的帧来阻止所有流是不可取的。
During a link outage, interactions between ARQ and multiple flows are less significant; the ARQ protocol is likely to be equally unsuccessful in retransmitting frames for all flows. High persistence may benefit TCP flows, by enabling prompt recovery once the channel is restored.
在链路中断期间，ARQ和多个流之间的交互不太重要；ARQ协议在所有流的帧重传中可能同样不成功。高持久性可能有利于TCP流，因为一旦通道恢复，就可以进行即时恢复。
Low ARQ persistence is particularly useful where it is difficult or impossible to classify traffic flows, and hence treat each flow independently, and where the link capacity can accommodate a large number of simultaneous flows.
低ARQ持久性在难以或不可能对业务流进行分类的情况下尤其有用，从而独立地处理每个流，并且链路容量可以容纳大量同时的流。
Link ARQ designers should consider the implications of their design on the wider Internet. Effects such as increased transit delay, jitter, and re-ordering are cumulative when performed on multiple links along an Internet path. It is therefore very hard to say how many ARQ links may exist in series along an arbitrary Internet path between endhosts, especially as the path taken and its links may change over time.
Link ARQ设计者应该考虑他们的设计对更广泛的互联网的影响。当在沿互联网路径的多个链路上执行时，诸如传输延迟增加、抖动和重新排序等影响是累积的。因此，很难说在终端主机之间的任意Internet路径上可能串联存在多少ARQ链路，特别是当所采用的路径及其链路可能随时间而改变时。
In summary, when links cannot classify traffic flows and treat them separately, low persistence is generally desirable; preserving packet ordering is generally desirable. Extremely high persistence and perfect persistence are generally undesirable; highly-persistent ARQ
总之，当链路不能对流量进行分类并单独处理时，通常需要低持久性；保存数据包顺序通常是可取的。极高的持久性和完美的持久性通常是不可取的；高持久性ARQ
is a bad idea unless flow classification and detailed and accurate knowledge of flow requirements make it possible to deploy high persistency where it will be beneficial.
这是一个坏主意，除非流分类和对流需求的详细而准确的了解使得在有利的地方部署高持久性成为可能。
There is currently insufficient experience to recommend a specific ARQ scheme for any class of link. It is also important to realize that link ARQ is just one method of error recovery, and that other complementary physical-layer techniques may be used instead of, or together with, ARQ to improve overall link throughput for IP traffic.
目前没有足够的经验为任何类别的链路推荐特定的ARQ方案。还必须认识到，链路ARQ只是错误恢复的一种方法，并且可以使用其他补充物理层技术来代替ARQ，或者与ARQ一起使用，以提高IP业务的整体链路吞吐量。
The choice of potential schemes includes adapting the data rate, adapting the signal bandwidth, adapting the transmission power, adaptive modulation, adaptive information redundancy / forward error control, and interleaving. All of these schemes can be used to improve the received signal energy per bit, and hence reduce error, frame loss and resulting packet loss rates given specific channel conditions.
潜在方案的选择包括自适应数据速率、自适应信号带宽、自适应传输功率、自适应调制、自适应信息冗余/前向差错控制和交织。所有这些方案都可用于提高每比特的接收信号能量，从而在特定信道条件下降低错误、帧丢失和由此产生的分组丢失率。
There is a need for more research to more clearly identify the importance of and trade-offs between the above issues over various types of link and over various types of channels. It would be useful if researchers and implementers clearly indicated the loss model, link capacity and characteristics, link and end-to-end path delays, details of TCP, and the number (and details) of flows sharing a link when describing their experiences. In each case, it is recommended that specific details of the link characteristics and mechanisms also be considered; solutions vary with conditions.
需要进行更多的研究，以更清楚地确定上述问题在各种类型的链接和各种类型的渠道之间的重要性和权衡。如果研究人员和实施者在描述他们的经历时明确指出损失模型、链路容量和特性、链路和端到端路径延迟、TCP的细节以及共享链路的流的数量（和细节），这将是有用的。在每种情况下，建议还考虑链路特性和机制的具体细节；解决方案因条件而异。
No security implications have been identified as directly impacting IP traffic. However, an unreliable link service may adversely impact some existing link-layer key management distribution protocols if link encryption is also used over the link.
没有发现直接影响IP流量的安全隐患。然而，如果链路加密也在链路上使用，则不可靠的链路服务可能会对某些现有的链路层密钥管理分发协议产生不利影响。
Denial-of-service attacks exploiting the behaviour of the link protocol, e.g., using knowledge of its retransmission behaviour and propagation delay to cause a particular form of jamming, may be specific to an individual link scenario.
利用链路协议的行为进行的拒绝服务攻击（例如，利用其重传行为和传播延迟的知识造成特定形式的干扰）可能特定于单个链路场景。
No assignments from the IANA are required.
不需要IANA分配任务。
Much of what is described here has been developed from a summary of a subset of the discussions on the archived IETF PILC mailing list. We thank the contributors to PILC for vigorous debate.
这里所描述的大部分内容都是从归档的IETF PILC邮件列表中讨论的一个子集总结而来的。我们感谢PILC的贡献者进行了激烈的辩论。
In particular, the authors would like to thank Spencer Dawkins, Aaron Falk, Dan Grossman, Merkourios Karaliopoulos, Gary Kenward, Reiner Ludwig and Jean Tourrilhes for their detailed comments.
特别是，作者要感谢斯宾塞·道金斯、亚伦·福克、丹·格罗斯曼、梅科乌里奥斯·卡拉利奥普洛斯、加里·肯沃德、雷纳·路德维希和让·图里尔斯的详细评论。
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/.
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981.
[RFC793]Postel，J.，“传输控制协议”，RFC793，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月。
[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月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC2475]Blake，S.，Black，D.，Carlson，M.，Davies，E.，Wang，Z.和W.Weiss，“差异化服务架构”，RFC 24751998年12月。
[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月。
[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月。
[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月。
[RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
[RFC3260]Grossman，D.“区分服务的新术语和澄清”，RFC 3260，2002年4月。
[BAL95] Balakrishnan, H., Seshan, S. and R. H. Katz, "Improving Reliable Transport and Handoff Performance in Cellular Wireless Networks", ACM MOBICOM, Berkeley, 1995.
[BAL95]Balakrishnan，H.，Seshan，S.和R.H.Katz，“改善蜂窝无线网络中的可靠传输和切换性能”，ACM MOBICOM，伯克利，1995年。
[BAL97] Balakrishnan, H., Padmanabhan, V. N., Seshan, S. and R. H. Katz, "A Comparison of Mechanisms for Improving TCP Performance over Wireless Links", IEEE/ACM Transactions on Networking, 5(6), pp. 756-759, 1997.
[BAL97]Balakrishnan，H.，Padmanabhan，V.N.，Seshan，S.和R.H.Katz，“改善无线链路TCP性能的机制比较”，IEEE/ACM网络交易，5（6），第756-759页，1997年。
[BEN00] Bennett, J. C., Partridge, C. and N. Schectman, "Packet Reordering is Not Pathological Network Behaviour", IEEE/ACM Transactions on Networking, 7(6), pp. 789-798, 2000.
[BEN00]Bennett，J.C.，Partridge，C.和N.Schectman，“数据包重新排序不是病态的网络行为”，IEEE/ACM网络交易，7（6），第789-798页，2000年。
[BHA97] Bhagwat, P., Bhattacharya, P., Krishna A. and S. K. Tripathi, "Using channel state dependent packet scheduling to improve TCP throughput over wireless LANs", ACM/Baltzer Wireless Networks Journal, (3)1, 1997.
[BHA97]Bhagwat，P.，Bhattacharya，P.，Krishna A.和S.K.Tripathi，“使用依赖信道状态的数据包调度来提高无线局域网上的TCP吞吐量”，ACM/Baltzer无线网络杂志，（3）11997。
[CHE00] Cheng, H. S., G. Fairhurst et al., "An Efficient Partial Retransmission ARQ Strategy with Error Codes by Feedback Channel", IEE Proceedings - Communications, (147)5, pp. 263-268, 2000.
[CHE00]Cheng，H.S.，G.Fairhurst等人，“通过反馈信道使用错误码的有效部分重传ARQ策略”，IEE会议记录-通信，（147）5，第263-2682000页。
[DRAFTKARN02] Karn, P., Ed., "Advice for Internet Subnetwork Designers", Work in Progress.
[DRAFTKARN02]Karn，P.，Ed.，“互联网子网设计师的建议”，正在进行的工作。
[DRAFTHAN01] Handley, M., Floyd, S. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", Work in Progress.
[DRAFTHAN01]Handley，M.，Floyd，S.和J.Widmer，“TCP友好速率控制（TFRC）：协议规范”，正在进行的工作。
[ECK98] Eckhardt, D. A. and P. Steenkiste, "Improving Wireless LAN Performance via Adaptive Local Error Control", IEEE ICNP, 1998.
[ECK98]Eckhardt，D.A.和P.Steenkiste，“通过自适应局部差错控制提高无线局域网性能”，IEEE ICNP，1998年。
[FER99] Ferrero, A., "The Eternal Ethernet", Addison-Wesley, 1999.
[Ferrero，A.，“永恒的以太网”，艾迪生·韦斯利，1999年。
[ISO4335a] HDLC Procedures: Specification for Consolidation of Elements of Procedures, ISO 4335 and AD/1, International Standardization Organization, 1985.
[ISO4335a]HDLC程序：程序要素合并规范，ISO 4335和AD/1，国际标准化组织，1985年。
[ISO4335b] HDLC Procedures: Elements of Procedures, Amendment 4: Multi-Selective Reject Option, ISO 4335/4, International Standards Organization, 1991.
[ISO4335b]HDLC程序：程序要素，修改件4：多选择拒绝选项，ISO 4335/4，国际标准组织，1991年。
[ISO7776] Specification for X.25 LAPB-Compatible DTE Data Link Procedures, ISO 4335/4, International Standards Organization, 1985.
[ISO7776]X.25 LAPB兼容DTE数据链路程序规范，ISO 4335/4，国际标准组织，1985年。
[KEN87] Kent, C. A. and J. C. Mogul, "Fragmentation Considered Harmful", Proceedings of ACM SIGCOMM 1987, ACM Computer Communications Review, 17(5), pp. 390-401, 1987.
[KEN87]Kent，C.A.和J.C.Mogul，“碎片被认为是有害的”，1987年ACM SIGCOMM会议录，ACM计算机通信评论，17（5），第390-4011987页。
[LIN93] Lin, S. and D. Costello, "Error Control Coding: Fundamentals and Applications", Prentice Hall, 1993.
[LIN93]Lin，S.和D.Costello，“差错控制编码：基础和应用”，Prentice Hall，1993年。
[LUD99a] Ludwig, R., Rathonyi, B., Konrad, A., Oden, K., and A. Joseph, "Multi-Layer Tracing of TCP over a Reliable Wireless Link", ACM SIGMETRICS, pp. 144-154, 1999.
[LUD99a]Ludwig，R.，Rathonyi，B.，Konrad，A.，Oden，K.，和A.Joseph，“可靠无线链路上TCP的多层跟踪”，ACM SIGMETRICS，第144-154页，1999年。
[LUD99b] Ludwig, R., Konrad, A., Joseph, A. and R. H. Katz, "Optimizing the End-to-End Performance of Reliable Flows over Wireless Links", ACM MobiCOM, 1999.
[Ludwig，R.，Konrad，A.，Joseph，A.和R.H.Katz，“优化无线链路上可靠流的端到端性能”，ACM MobiCOM，1999年。
[MEY99] Meyer, M., "TCP Performance over GPRS", IEEE Wireless Communications and Networking Conference, 1999.
[MEY99]Meyer，M.，“GPRS上的TCP性能”，IEEE无线通信和网络会议，1999年。
[PAR00] Parsa, C. and J. J. Garcia-Luna-Aceves, "Improving TCP Performance over Wireless Networks at the Link Layer", ACM Mobile Networks and Applications Journal, (5)1, pp. 57-71, 2000.
[PAR00]Parsa，C.和J.J.Garcia Luna Aceves，“在链路层改善无线网络上的TCP性能”，ACM移动网络和应用杂志，（5）1，第57-71页，2000年。
[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[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月。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC1350]Sollins，K.，“TFTP协议（修订版2）”，STD 33，RFC 1350，1992年7月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435]Knowles，S.，“来自Path MTU发现经验的IESG建议”，RFC 1435，1993年3月。
[RFC1981] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over Satellite Channels using Standard Mechanisms", BCP 28, RFC 2488, January 1999.
[RFC2488]Allman，M.，Glover，D.和L.Sanchez，“使用标准机制增强卫星信道上的TCP”，BCP 28，RFC 2488，1999年1月。
[RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret V. and N. Vaidya, "Long Thin Networks", RFC 2757, January 2000.
[RFC2757]黑山，G.，道金斯，S.，科乔，M.，Magret诉和N.Vaidya，“长瘦网络”，RFC 2757，2000年1月。
[RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., Henderson, T., Heidemann, J., Touch, J., Kruse, H., Ostermann, S., Scott K. and J. Semke "Ongoing TCP Research Related to Satellites", RFC 2760, February 2000.
[RFC2760]奥尔曼，M.，道金斯，S.，格洛弗，D.，格林纳，J.，特兰，D.，亨德森，T.，海德曼，J.，图奇，J.，克鲁斯，H.，奥斯特曼，S.，斯科特K.和J.塞姆克“正在进行的与卫星相关的TCP研究”，RFC 27602000年2月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960]Stewart，R.，Xie，Q.，Morneault，K.，Sharp，C.，Schwarzbauer，H.，Taylor，T.，Rytina，I.，Kalla，M.，Zhang，L.和V.Paxson，“流控制传输协议”，RFC 29602000年10月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V. and N. Vaidya, "End-to-end Performance Implications of Links with Errors", BCP 50, RFC 3155, August 2001.
[RFC3155]Dawkins，S.，黑山，G.，Kojo，M.，Magret，V.和N.Vaidya，“带错误链接的端到端性能影响”，BCP 50，RFC 3155，2001年8月。
[SALT81] Saltzer, J. H., Reed, D. P. and D. Clark, "End-to-End Arguments in System Design", Second International Conference on Distributed Computing Systems, pp. 509-512, 1981. Published with minor changes in ACM Transactions in Computer Systems (2)4, pp. 277-288, 1984.
[SALT81]Saltzer，J.H.，Reed，D.P.和D.Clark，“系统设计中的端到端论证”，第二届分布式计算系统国际会议，第509-512页，1981年。《计算机系统中的ACM交易》（2）4，第277-288页，1984年出版，内容略有变化。
[SAM96] Samaraweera, N. and G. Fairhurst, "Robust Data Link Protocols for Connection-less Service over Satellite Links", International Journal of Satellite Communications, 14(5), pp. 427-437, 1996.
[SAM96]Samaraweera，N.和G.Fairhurst，“卫星链路上无连接服务的健壮数据链路协议”，国际卫星通信杂志，14（5），第427-437页，1996年。
[SAM98] Samaraweera, N. and G. Fairhurst, "Reinforcement of TCP/IP Error Recovery for Wireless Communications", ACM Computer Communications Review, 28(2), pp. 30-38, 1998.
[SAM98]Samaraweera，N.和G.Fairhurst，“加强无线通信的TCP/IP错误恢复”，ACM计算机通信评论，28（2），第30-38页，1998年。
[STE94] Stevens, W. R., "TCP/IP Illustrated, Volume 1", Addison-Wesley, 1994.
[STE94]Stevens，W.R.，“TCP/IP图解，第1卷”，Addison-Wesley，1994年。
[STONE00] Stone, J. and C. Partridge, "When the CRC and TCP Checksum Disagree", Proceedings of SIGCOMM 2000, ACM Computer Communications Review 30(4), pp. 309-321, September 2000.
[STONE00]Stone，J.和C.Partridge，“当CRC和TCP校验和不一致时”，SIGCOMM 2000年会议记录，ACM计算机通信评论30（4），第309-321页，2000年9月。
[WARD95] Ward, C., et al., "A Data Link Control Protocol for LEO Satellite Networks Providing a Reliable Datagram Service", IEEE/ACM Transactions on Networking, 3(1), 1995.
[WARD95]Ward，C.等人，“提供可靠数据报服务的低轨卫星网络的数据链路控制协议”，IEEE/ACM网络事务，3（1），1995年。
Authors' Addresses
作者地址
Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen AB24 3UE United Kingdom
英国阿伯丁大学工程系阿伯丁
EMail: gorry@erg.abdn.ac.uk
http://www.erg.abdn.ac.uk/users/gorry/
EMail: gorry@erg.abdn.ac.uk
http://www.erg.abdn.ac.uk/users/gorry/
Lloyd Wood Cisco Systems Ltd 4 The Square Stockley Park Uxbridge UB11 1BY United Kingdom
Lloyd Wood Cisco Systems Ltd 4英国斯托克利公园Uxlibridge UB11广场
EMail: lwood@cisco.com
http://www.ee.surrey.ac.uk/Personal/L.Wood/
EMail: lwood@cisco.com
http://www.ee.surrey.ac.uk/Personal/L.Wood/
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编辑功能的资金目前由互联网协会提供。