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)


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.




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 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.


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
1. Introduction
1. 介绍

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.


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].


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.


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].


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


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].


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].


1.1 Link ARQ
1.1 链路ARQ

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.


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.


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


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.


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].


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 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.


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.


Links supporting stateful reservation-based quality of service (QoS) according to the Integrated Services (intserv) model are also not explicitly discussed.


1.2 Causes of Packet Loss on a Link
1.2 链路上数据包丢失的原因

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].


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.


1.3 Why Use ARQ?
1.3 为什么要使用ARQ?

Reasons that encourage considering the use of ARQ include:


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.


1.4 Commonly-used ARQ Techniques
1.4 常用的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.


Whatever mechanisms are chosen, there are two easily-described categories of ARQ retransmission process that are widely used:


1.4.1 Stop-And-Wait ARQ
1.4.1 停下来等待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.


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.


1.4.2 Sliding-Window ARQ
1.4.2 滑动窗口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.


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.


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.


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.


1.5 Causes of Delay Across a Link
1.5 链路延迟的原因

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.


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.


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.


2. ARQ Persistence
2. 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.


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.


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.


2.1 Perfectly-Persistent (Reliable) ARQ Protocols
2.1 完全持久(可靠)ARQ协议

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.


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].


Arguments against the use of perfect persistence for IP traffic include:


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.


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.


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.


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])。这些协议将无限次地重新传输一个帧,直到确认接收到该帧为止。

2.2 High-Persistence (Highly-Reliable) ARQ Protocols
2.2 高持久性(高可靠性)ARQ协议

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.


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.


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].


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.


Examples of high-persistence ARQ protocols include [BHA97, ECK98, LUD99a, MEY99].


2.3 Low-Persistence (Partially-Reliable) ARQ Protocols
2.3 低持久性(部分可靠)ARQ协议

The characteristics of a link using a low-persistence ARQ protocol may be summarised as:


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].


2.4 Choosing Your Persistency
2.4 选择你的坚持

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.


2.5 Impact of Link Outages
2.5 链路中断的影响

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.


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.


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.


3. Treatment of Packets and Flows
3. 数据包和流的处理
3.1 Packet Ordering
3.1 数据包订购

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.


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.


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:


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.


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].


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.


A number of experimental ARQ protocols have allowed out-of-order delivery [BAL95, SAM96, WARD95].


3.2 Using Link ARQ to Support Multiple Flows
3.2 使用链路ARQ支持多个流

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.


When packets from several flows are simultaneously in transit within a link ARQ protocol, ARQ may cause a number of additional effects:


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.


3.3 Differentiation of Link Service Classes
3.3 链路服务类别的区分

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.


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.


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].


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.


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].


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.


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.


In general, if separation of flows according to class is not practicable, a low persistency is best for link ARQ.


4. Conclusions
4. 结论

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.


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


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.


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.


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.


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.


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.


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


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.


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.


5. Security Considerations
5. 安全考虑

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.


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.


6. IANA Considerations
6. IANA考虑

No assignments from the IANA are required.


7. Acknowledgements
7. 致谢

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.


8. References
8. 工具书类

References of the form RFCnnnn are Internet Request for Comments (RFC) documents available online at


8.1 Normative References
8.1 规范性引用文件

[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.


[RFC793] Postel, J., "Transmission Control Protocol", RFC 793, September 1981.


[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月。

8.2 Informative References
8.2 资料性引用

[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.


[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.


[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.


[DRAFTKARN02] Karn, P., Ed., "Advice for Internet Subnetwork Designers", Work in Progress.


[DRAFTHAN01] Handley, M., Floyd, S. and J. Widmer, "TCP Friendly Rate Control (TFRC): Protocol Specification", Work in Progress.


[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.


[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.


[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.


[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.


[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.


[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.


[STE94] Stevens, W. R., "TCP/IP Illustrated, Volume 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.


Authors' Addresses


Godred Fairhurst Department of Engineering University of Aberdeen Aberdeen AB24 3UE United Kingdom



Lloyd Wood Cisco Systems Ltd 4 The Square Stockley Park Uxbridge UB11 1BY United Kingdom

Lloyd Wood Cisco Systems Ltd 4英国斯托克利公园Uxlibridge UB11广场


Full Copyright Statement


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


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


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






Funding for the RFC Editor function is currently provided by the Internet Society.