Internet Engineering Task Force (IETF) A. Zimmermann
Request for Comments: 6069 A. Hannemann
Category: Experimental RWTH Aachen University
ISSN: 2070-1721 December 2010
Internet Engineering Task Force (IETF) A. Zimmermann
Request for Comments: 6069 A. Hannemann
Category: Experimental RWTH Aachen University
ISSN: 2070-1721 December 2010
Making TCP More Robust to Long Connectivity Disruptions (TCP-LCD)
使TCP对长时间连接中断（TCP-LCD）更具鲁棒性
Abstract
摘要
Disruptions in end-to-end path connectivity, which last longer than one retransmission timeout, cause suboptimal TCP performance. The reason for this performance degradation is that TCP interprets segment loss induced by long connectivity disruptions as a sign of congestion, resulting in repeated retransmission timer backoffs. This, in turn, leads to a delayed detection of the re-establishment of the connection since TCP waits for the next retransmission timeout before it attempts a retransmission.
端到端路径连接中断（持续时间超过一个重传超时）会导致TCP性能不理想。这种性能下降的原因是TCP将长时间连接中断导致的段丢失解释为拥塞的迹象，从而导致重复的重传计时器退避。这反过来导致延迟检测连接的重新建立，因为TCP在尝试重新传输之前等待下一次重新传输超时。
This document proposes an algorithm to make TCP more robust to long connectivity disruptions (TCP-LCD). It describes how standard ICMP messages can be exploited during timeout-based loss recovery to disambiguate true congestion loss from non-congestion loss caused by connectivity disruptions. Moreover, a reversion strategy of the retransmission timer is specified that enables a more prompt detection of whether or not the connectivity to a previously disconnected peer node has been restored. TCP-LCD is a TCP sender-only modification that effectively improves TCP performance in the case of connectivity disruptions.
本文提出了一种算法，使TCP对长时间连接中断（TCP-LCD）更具鲁棒性。它描述了如何在基于超时的丢失恢复期间利用标准ICMP消息来消除连接中断导致的真实拥塞丢失和非拥塞丢失之间的歧义。此外，指定了重传定时器的反转策略，该策略使得能够更迅速地检测到与先前断开的对等节点的连接是否已经恢复。TCP-LCD是一种仅限TCP发送方的修改，可在连接中断的情况下有效提高TCP性能。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
本文件不是互联网标准跟踪规范；它是为检查、实验实施和评估而发布的。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文档为互联网社区定义了一个实验协议。本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6069.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6069.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Connectivity Disruption Indication ..............................5
4. Connectivity Disruption Reaction ................................7
4.1. Basic Idea .................................................7
4.2. Algorithm Details ..........................................8
5. Discussion of TCP-LCD ..........................................11
5.1. Retransmission Ambiguity ..................................12
5.2. Wrapped Sequence Numbers ..................................12
5.3. Packet Duplication ........................................13
5.4. Probing Frequency .........................................14
5.5. Reaction during Connection Establishment ..................14
5.6. Reaction in Steady-State ..................................14
6. Dissolving Ambiguity Issues Using the TCP Timestamps Option ....15
7. Interoperability Issues ........................................17
7.1. Detection of TCP Connection Failures ......................17
7.2. Explicit Congestion Notification (ECN) ....................17
7.3. TCP-LCD and IP Tunnels ....................................17
8. Related Work ...................................................18
9. Security Considerations ........................................19
10. Acknowledgments ...............................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................21
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Connectivity Disruption Indication ..............................5
4. Connectivity Disruption Reaction ................................7
4.1. Basic Idea .................................................7
4.2. Algorithm Details ..........................................8
5. Discussion of TCP-LCD ..........................................11
5.1. Retransmission Ambiguity ..................................12
5.2. Wrapped Sequence Numbers ..................................12
5.3. Packet Duplication ........................................13
5.4. Probing Frequency .........................................14
5.5. Reaction during Connection Establishment ..................14
5.6. Reaction in Steady-State ..................................14
6. Dissolving Ambiguity Issues Using the TCP Timestamps Option ....15
7. Interoperability Issues ........................................17
7.1. Detection of TCP Connection Failures ......................17
7.2. Explicit Congestion Notification (ECN) ....................17
7.3. TCP-LCD and IP Tunnels ....................................17
8. Related Work ...................................................18
9. Security Considerations ........................................19
10. Acknowledgments ...............................................20
11. References ....................................................20
11.1. Normative References .....................................20
11.2. Informative References ...................................21
Connectivity disruptions can occur in many different situations. The frequency of connectivity disruptions depends on the properties of the end-to-end path between the communicating hosts. While connectivity disruptions can occur in traditional wired networks, e.g., disruption caused by an unplugged network cable, the likelihood of their occurrence is significantly higher in wireless (multi-hop) networks. Especially, end-host mobility, network topology changes, and wireless interferences are crucial factors. In the case of the Transmission Control Protocol (TCP) [RFC0793], the performance of the connection can experience a significant reduction compared to a permanently connected path [SESB05]. This is because TCP, which was originally designed to operate in fixed and wired networks, generally assumes that the end-to-end path connectivity is relatively stable over the connection's lifetime.
连接中断可能发生在许多不同的情况下。连接中断的频率取决于通信主机之间的端到端路径的属性。虽然传统有线网络中可能会发生连接中断，例如，网络电缆未拔出导致的中断，但在无线（多跳）网络中发生连接中断的可能性要高得多。特别是，终端主机移动性、网络拓扑变化和无线干扰是关键因素。在传输控制协议（TCP）[RFC0793]的情况下，与永久连接的路径[SESB05]相比，连接的性能会显著降低。这是因为最初设计用于在固定和有线网络中运行的TCP通常假定端到端路径连接在连接的生命周期内相对稳定。
Depending on their duration, connectivity disruptions can be classified into two groups [TCP-RLCI]: "short" and "long". A connectivity disruption is "short" if connectivity returns before the retransmission timer fires for the first time. In this case, TCP recovers lost data segments through Fast Retransmit and lost acknowledgments (ACKs) through successfully delivered later ACKs. Connectivity disruptions are declared as "long" for a given TCP connection if the retransmission timer fires at least once before connectivity is resumed. Whether or not path characteristics, like the round-trip time (RTT) or the available bandwidth, have changed when connectivity resumes after a disruption is another important aspect for TCP's retransmission scheme [TCP-RLCI].
根据持续时间的不同，连接中断可分为两组[TCP-RLCI]：“短”和“长”。如果在重新传输计时器首次触发之前连接恢复，则连接中断为“短”。在这种情况下，TCP通过快速重新传输来恢复丢失的数据段，并通过随后成功传递的确认来恢复丢失的确认（ACKs）。如果重新传输计时器在连接恢复之前至少触发一次，则给定TCP连接的连接中断被声明为“长”。当中断后恢复连接时，路径特征（如往返时间（RTT）或可用带宽）是否发生变化是TCP重传方案[TCP-RLCI]的另一个重要方面。
The algorithm specified in this document improves TCP's behavior in the case of "long connectivity disruptions". In particular, it focuses on the period prior to the re-establishment of the connectivity to a previously disconnected peer node. The document does not describe any modifications to TCP's behavior and its congestion control mechanisms [RFC5681] after connectivity has been restored.
本文档中指定的算法改进了TCP在“长时间连接中断”情况下的行为。特别地，它关注于重新建立到先前断开的对等节点的连接之前的时间段。本文档未描述在连接恢复后对TCP行为及其拥塞控制机制[RFC5681]的任何修改。
When a long connectivity disruption occurs on a TCP connection, the TCP sender eventually does not receive any more acknowledgments. After the retransmission timer expires, the TCP sender enters the timeout-based loss recovery and declares the oldest outstanding segment (SND.UNA) as lost. Since TCP tightly couples reliability and congestion control, the retransmission of SND.UNA is triggered together with the reduction of the transmission rate. This is based on the assumption that segment loss is an indication of congestion [RFC5681]. As long as the connectivity disruption persists, TCP will repeat this procedure until the oldest outstanding segment has
当TCP连接发生长时间连接中断时，TCP发送方最终不会再收到任何确认。在重传计时器过期后，TCP发送方进入基于超时的丢失恢复，并将最早的未完成段（SND.UNA）声明为丢失。由于TCP将可靠性和拥塞控制紧密耦合，因此SND.UNA的重传会随着传输速率的降低而触发。这是基于以下假设，即段丢失表示拥塞[RFC5681]。只要连接中断持续存在，TCP将重复此过程，直到最旧的未完成段恢复
successfully been acknowledged or until the connection has timed out. TCP implementations that follow the recommended retransmission timeout (RTO) management of RFC 2988 [RFC2988] double the RTO after each retransmission attempt. However, the RTO growth may be bounded by an upper limit, the maximum RTO, which is at least 60 s, but may be longer: Linux, for example, uses 120 s. If connectivity is restored between two retransmission attempts, TCP still has to wait until the retransmission timer expires before resuming transmission, since it simply does not have any means to know if the connectivity has been re-established. Therefore, depending on when connectivity becomes available again, this can waste up to a maximum RTO of possible transmission time.
已成功确认或直到连接超时。遵循RFC 2988[RFC2988]的推荐重传超时（RTO）管理的TCP实现在每次重传尝试后使RTO加倍。然而，RTO增长可能受到上限的限制，即最大RTO，它至少为60秒，但可能更长：例如，Linux使用120秒。如果在两次重新传输尝试之间恢复了连接，TCP仍然必须等到重新传输计时器过期后才能恢复传输，因为它根本没有任何方法知道连接是否已重新建立。因此，取决于连接何时再次可用，这可能会浪费可能传输时间的最大RTO。
This retransmission behavior is not efficient, especially in scenarios with long connectivity disruptions. In the ideal case, TCP would attempt a retransmission as soon as connectivity to its peer has been re-established. In this document, we specify a TCP sender-only modification to provide robustness to long connectivity disruptions (TCP-LCD). The memo describes how the standard Internet Control Message Protocol (ICMP) can be exploited during timeout-based loss recovery to identify non-congestion loss caused by long connectivity disruptions. TCP-LCD's reversion strategy of the retransmission timer enables higher-frequency retransmissions and thereby a prompt detection when connectivity to a previously disconnected peer node has been restored. If no congestion is present, TCP-LCD approaches the ideal behavior.
这种重传行为效率不高，尤其是在连接中断时间较长的情况下。在理想情况下，TCP将在与对等方重新建立连接后立即尝试重新传输。在本文档中，我们指定了一个仅限TCP发送方的修改，以提供对长时间连接中断（TCP-LCD）的健壮性。备忘录描述了如何在基于超时的丢失恢复期间利用标准Internet控制消息协议（ICMP）来识别长时间连接中断造成的非拥塞丢失。TCP-LCD的重传定时器反转策略可实现更高频率的重传，从而在恢复与先前断开的对等节点的连接时进行提示检测。如果不存在拥塞，TCP-LCD将接近理想行为。
Experimental results of a Linux implementation of TCP-LCD have been presented in [ZimHan09]. The implementation has been incorporated into mainline Linux, and is already used within the Internet. Thus far, no negative experiences have been reported that could be attributed to the algorithm. However, we consider TCP-LCD as experimental until more real-life results have been obtained. Nevertheless, we encourage implementation of TCP-LCD under other operating systems to provide for broader testing and experimentation opportunities.
[ZimHan09]中给出了TCP-LCD的Linux实现的实验结果。该实现已并入主线Linux，并已在Internet中使用。到目前为止，还没有任何可归因于该算法的负面经验报告。然而，我们认为TCP LCD作为实验，直到获得更真实的结果。然而，我们鼓励在其他操作系统下实现TCP-LCD，以提供更广泛的测试和实验机会。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The reader should be familiar with the algorithm and terminology from [RFC2988], which defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer. In this document, the terms "retransmission timer" and "retransmission timeout" are used as
读者应熟悉[RFC2988]中的算法和术语，其中定义了传输控制协议（TCP）发送方计算和管理其重传计时器所需使用的标准算法。在本文档中，术语“重传计时器”和“重传超时”用作
defined in [RFC2988]. The retransmission timer ensures data delivery in the absence of any feedback from the receiver. The duration of this timer is referred to as retransmission timeout (RTO).
定义见[RFC2988]。重传定时器确保在没有来自接收器的任何反馈的情况下进行数据传送。此计时器的持续时间称为重传超时（RTO）。
As defined in [RFC0793], the term "acceptable acknowledgment (ACK)" refers to a TCP segment that acknowledges previously unacknowledged data. The TCP sender state variable "SND.UNA" and the current segment variable "SEG.SEQ" are used as defined in [RFC0793]. SND.UNA holds the segment sequence number of the earliest segment that has not been acknowledged by the TCP receiver (the oldest outstanding segment). SEG.SEQ is the segment sequence number of a given segment.
如[RFC0793]中所定义，术语“可接受的确认（ACK）”指确认先前未确认数据的TCP段。TCP发送方状态变量“SND.UNA”和当前段变量“SEG.SEQ”按照[RFC0793]中的定义使用。SND.UNA保存TCP接收器尚未确认的最早段的段序列号（最早的未完成段）。SEG.SEQ是给定段的段序列号。
For the purposes of this specification, we define the term "timeout-based loss recovery", which refers to the state that a TCP sender enters upon the first timeout of the oldest outstanding segment (SND.UNA) and leaves upon the arrival of the *first* acceptable ACK. It is important to note that other documents use a different interpretation of the term "timeout-based loss recovery". For example, the NewReno modification to TCP's Fast Recovery algorithm [RFC3782] extends the period that a TCP sender remains in timeout-based loss recovery compared to the one defined in this document. This is because [RFC3782] attempts to avoid unnecessary multiple Fast Retransmits that can occur after an RTO.
在本规范中，我们定义了术语“基于超时的丢失恢复”，它是指TCP发送方在最早未完成段（SND.UNA）的第一次超时时进入并在到达*第一个*可接受ACK时离开的状态。需要注意的是，其他文件对术语“基于超时的损失恢复”使用了不同的解释。例如，对TCP的快速恢复算法[RFC3782]的NewReno修改延长了TCP发送方在基于超时的丢失恢复中的时间，而不是本文档中定义的时间。这是因为[RFC3782]试图避免RTO后可能发生的不必要的多次快速重传。
If the queue of an intermediate router that is experiencing a link outage can buffer all incoming packets, a connectivity disruption will only cause a variation in delay, which is handled well by TCP implementations using either Eifel [RFC3522], [RFC4015] or Forward RTO-Recovery (F-RTO) [RFC5682]. However, if the link outage lasts for too long, the router experiencing the link outage is forced to drop packets, and finally may remove the corresponding next hop from its routing table. Means to detect such link outages include reacting to failed address resolution protocol (ARP) [RFC0826] queries, sensing unsuccessful links, and the like. However, this is solely the responsibility of the respective router.
如果正在经历链路中断的中间路由器的队列可以缓冲所有传入的数据包，那么连接中断只会导致延迟的变化，这可以通过使用Eifel[RFC3522]、[RFC4015]或前向RTO恢复（F-RTO）[RFC5682]的TCP实现很好地处理。但是，如果链路中断持续时间过长，则经历链路中断的路由器将被迫丢弃数据包，并最终可能从其路由表中删除相应的下一跳。检测这种链路中断的方法包括对失败的地址解析协议（ARP）[RFC0826]查询作出反应、感测不成功的链路等。然而，这完全是各路由器的责任。
Note: The focus of this memo is on introducing a method of how ICMP messages may be exploited to improve TCP's performance; how different physical and link-layer mechanisms below the network layer may trigger ICMP destination unreachable messages are out of scope of this memo.
注：本备忘录的重点是介绍如何利用ICMP消息提高TCP性能的方法；网络层下不同的物理层和链路层机制如何触发ICMP目标不可访问消息超出了本备忘录的范围。
Provided that no other route to the specific destination exists, an Internet Protocol version 4 (IPv4) [RFC0791] router will notify the corresponding sending host about the dropped packets via ICMP destination unreachable messages of code 0 (net unreachable) or
如果不存在到特定目的地的其他路由，则Internet协议版本4（IPv4）[RFC0791]路由器将通过代码为0（net unreachable）或
code 1 (host unreachable) [RFC1812]. Therefore, the sending host can use the ICMP destination unreachable messages of these codes as an indication of a connectivity disruption, since the reception of these messages provides evidence that packets were dropped due to a link outage.
代码1（无法访问主机）[RFC1812]。因此，发送主机可以使用这些代码的ICMP目的地不可到达消息作为连接中断的指示，因为这些消息的接收提供了由于链路中断而丢弃数据包的证据。
For Internet Protocol version 6 (IPv6) [RFC2460], the counterpart of the ICMP destination unreachable message of code 0 (net unreachable) and of code 1 (host unreachable) is the ICMPv6 destination unreachable message of code 0 (no route to destination) [RFC4443]. As with IPv4, a router should generate an ICMPv6 destination unreachable message of code 0 in response to a packet that cannot be delivered to its destination address because it lacks a matching entry in its routing table.
对于Internet协议版本6（IPv6）[RFC2460]，代码0（网络不可访问）和代码1（主机不可访问）的ICMP目标不可访问消息的对应物是代码0（无到目标的路由）[RFC4443]的ICMPv6目标不可访问消息。与IPv4一样，路由器应生成代码为0的ICMPv6目的地不可访问消息，以响应由于其路由表中缺少匹配项而无法传递到其目的地地址的数据包。
Note that there are also other ICMP and ICMPv6 destination unreachable messages with different codes. Some of them are candidates for connectivity disruption indications, too, but need further investigation (for example, ICMP destination unreachable messages with code 5 (source route failed), code 11 (net unreachable for TOS (Type of Service)), or code 12 (host unreachable for TOS) [RFC1812]). On the other hand, codes that flag hard errors are of no use for this scheme, since TCP should abort the connection when those are received [RFC1122].
请注意，还有其他代码不同的ICMP和ICMPv6目标不可访问消息。其中一些也是连接中断指示的候选项，但需要进一步调查（例如，代码为5（源路由失败）、代码为11（TOS无法访问网络（服务类型））或代码为12（TOS无法访问主机）[RFC1812]）的ICMP目的地无法访问消息。另一方面，标记硬错误的代码对此方案没有用处，因为TCP应该在收到硬错误时中止连接[RFC1122]。
For the sake of simplicity, we will use, unless explicitly qualified with ICMPv4 or ICMPv6, the term "ICMP unreachable message" as a synonym for ICMP destination unreachable messages of code 0 or code 1 and ICMPv6 destination unreachable messages of code 0. This implies that all keywords from [RFC2119] that deal with the handling of received ICMP messages apply in the same way to ICMPv6 messages.
为简单起见，除非使用ICMPv4或ICMPv6明确限定，否则我们将使用术语“ICMP不可访问消息”作为代码0或代码1的ICMP目的地不可访问消息和代码0的ICMPv6目的地不可访问消息的同义词。这意味着[RFC2119]中处理接收到的ICMP消息的所有关键字都以相同的方式应用于ICMPv6消息。
The accurate interpretation of ICMP unreachable messages as a connectivity disruption indication is complicated by the following two peculiarities of ICMP messages. First, they do not necessarily operate on the same timescale as the packets, i.e., TCP segments that elicited them. When a router drops a packet due to a missing route, it will not necessarily send an ICMP unreachable message immediately, but will rather queue it for later delivery. Second, ICMP messages are subject to rate-limiting, e.g., when a router drops a whole window of data due to a link outage, it is unlikely to send as many ICMP unreachable messages as dropped TCP segments. Depending on the load of the router, it may not even send any ICMP unreachable messages at all. Both peculiarities originate from [RFC1812] for ICMPv4 and [RFC4443] for ICMPv6.
由于ICMP消息的以下两个特点，将ICMP无法访问消息准确解释为连接中断指示变得复杂。首先，它们不一定在与数据包相同的时间尺度上运行，即引发它们的TCP段。当路由器由于丢失路由而丢弃数据包时，它不一定会立即发送ICMP无法到达的消息，而是将其排队等待以后的传递。其次，ICMP消息受到速率限制，例如，当路由器由于链路中断而丢弃整个数据窗口时，它不可能发送与丢弃的TCP段一样多的ICMP无法到达的消息。根据路由器的负载，它甚至可能根本不发送任何ICMP无法访问的消息。这两种特性都源自ICMPv4的[RFC1812]和ICMPv6的[RFC4443]。
Fortunately, according to [RFC0792], ICMPv4 unreachable messages have to contain, in their body, the entire IPv4 header [RFC0791] of the datagram eliciting the ICMPv4 unreachable message, plus the first 64 bits of the payload of that datagram. This allows the sending host to match the ICMPv4 error message to the transport connection that elicited it. RFC 1812 [RFC1812] augments these requirements and states that ICMPv4 messages should contain as much of the original datagram as possible without the length of the ICMPv4 datagram exceeding 576 bytes. Therefore, in the case of TCP, at least the source port number, the destination port number, and the 32-bit TCP sequence number are included. This allows the originating TCP to demultiplex the received ICMPv4 message and to identify the affected connection. Moreover, it can identify which segment of the respective connection triggered the ICMPv4 unreachable message, unless there are several segments in flight with the same sequence number (see Section 5.1).
幸运的是，根据[RFC0792]，ICMPv4不可访问消息必须在其正文中包含引发ICMPv4不可访问消息的数据报的整个IPv4报头[RFC0791]，加上该数据报有效负载的前64位。这允许发送主机将ICMPv4错误消息与引发该消息的传输连接相匹配。RFC 1812[RFC1812]增加了这些要求，并规定ICMPv4消息应包含尽可能多的原始数据报，且ICMPv4数据报的长度不超过576字节。因此，在TCP的情况下，至少包括源端口号、目标端口号和32位TCP序列号。这允许发起TCP将接收到的ICMPv4消息解复用，并识别受影响的连接。此外，它可以识别相应连接的哪个段触发了ICMPv4不可到达消息，除非飞行中有多个段具有相同的序列号（见第5.1节）。
For IPv6 [RFC2460], the payload of an ICMPv6 error message has to include as many bytes as possible from the IPv6 datagram that elicited the ICMPv6 error message, without making the error message exceed the minimum IPv6 MTU (1280 bytes) [RFC4443]. Thus, enough information is available to identify both the affected connection and the corresponding segment that triggered the ICMPv6 error message.
对于IPv6[RFC2460]，ICMPv6错误消息的有效负载必须包含来自引发ICMPv6错误消息的IPv6数据报的尽可能多的字节，而不会使错误消息超过最小IPv6 MTU（1280字节）[RFC4443]。因此，有足够的信息可用于识别受影响的连接和触发ICMPv6错误消息的相应段。
A connectivity disruption indication in the form of an ICMP unreachable message associated with a presumably lost TCP segment provides strong evidence that the segment was not dropped due to congestion, but was successfully delivered as far as the reporting router. It therefore did not witness any congestion at least on that part of the path that was traversed by both the TCP segment eliciting the ICMP unreachable message and the ICMP unreachable message itself.
与可能丢失的TCP段相关的ICMP无法访问消息形式的连接中断指示提供了有力证据，表明该段未因拥塞而丢弃，但已成功传送到报告路由器。因此，至少在引发ICMP不可访问消息的TCP段和ICMP不可访问消息本身所经过的路径部分，它没有看到任何拥塞。
Section 4.1 introduces the basic idea of TCP-LCD. The complete algorithm is specified in Section 4.2.
第4.1节介绍了TCP-LCD的基本思想。第4.2节规定了完整的算法。
The goal of the algorithm is to promptly detect when connectivity to a previously disconnected peer node has been restored after a long connectivity disruption, while retaining appropriate behavior in case of congestion. TCP-LCD exploits standard ICMP unreachable messages during timeout-based loss recovery. This increases TCP's retransmission frequency by undoing one retransmission timer backoff whenever an ICMP unreachable message is received that contains a segment with a sequence number of a presumably lost retransmission.
该算法的目标是在长时间连接中断后，及时检测到与先前断开连接的对等节点的连接何时恢复，同时在拥塞情况下保持适当的行为。TCP-LCD在基于超时的丢失恢复期间利用标准ICMP无法访问的消息。每当接收到包含可能丢失的重传序列号的段的ICMP不可访问消息时，通过撤消一个重传计时器回退，这会增加TCP的重传频率。
This approach has the advantage of appropriately reducing the probing rate in case of congestion. If either the retransmission itself or the corresponding ICMP message is dropped, the previously performed retransmission timer backoff is not undone, which effectively halves the probing rate.
这种方法的优点是在拥塞情况下适当降低探测速率。如果重传本身或相应的ICMP消息被丢弃，则先前执行的重传计时器退避不会撤消，这实际上使探测速率减半。
A TCP sender that uses RFC 2988 [RFC2988] to compute TCP's retransmission timer MAY employ the following scheme to avoid over-conservative retransmission timer backoffs in case of long connectivity disruptions. If a TCP sender does implement the following steps, the algorithm MUST be initiated upon the first timeout of the oldest outstanding segment (SND.UNA) and MUST be stopped upon the arrival of the first acceptable ACK. The algorithm MUST NOT be re-initiated upon subsequent timeouts for the same segment. The scheme SHOULD NOT be used in SYN-SENT or SYN-RECEIVED states [RFC0793] (see Section 5.5).
使用RFC 2988[RFC2988]来计算TCP的重传计时器的TCP发送方可采用以下方案，以避免在长时间连接中断的情况下出现过度保守的重传计时器退避。如果TCP发送方确实执行了以下步骤，则必须在最早的未完成段（SND.UNA）第一次超时时启动算法，并且必须在第一个可接受的ACK到达时停止算法。在同一段的后续超时时，不得重新启动算法。该方案不应用于同步发送或同步接收状态[RFC0793]（见第5.5节）。
A TCP sender that does not employ RFC 2988 [RFC2988] to compute TCP's retransmission timer MUST NOT use TCP-LCD. We envision that the scheme could be easily adapted to algorithms other than RFC 2988. However, we leave this as future work.
不使用RFC 2988[RFC2988]计算TCP重传计时器的TCP发送方不得使用TCP-LCD。我们设想该方案可以很容易地适应RFC2988以外的算法。然而，我们将此作为未来的工作。
RFC 2988 [RFC2988] provides in rule (2.5) the option to place a maximum value on the RTO. When a TCP implements this rule to provide an upper bound for the RTO, it MUST also be used in the following algorithm. In particular, if the RTO is bounded by an upper limit (maximum RTO), the "MAX_RTO" variable used in this scheme MUST be initialized with this upper limit. Otherwise, if the RTO is unbounded, the "MAX_RTO" variable MUST be set to infinity.
RFC 2988[RFC2988]在规则（2.5）中提供了在RTO上设置最大值的选项。当TCP实现此规则以提供RTO的上限时，还必须在以下算法中使用此规则。特别是，如果RTO受到上限（最大RTO）的限制，则此方案中使用的“MAX_RTO”变量必须使用此上限进行初始化。否则，如果RTO是无界的，“MAX_RTO”变量必须设置为无穷大。
The scheme specified in this document uses the "BACKOFF_CNT" variable, whose initial value is zero. The variable is used to count the number of performed retransmission timer backoffs during one timeout-based loss recovery. Moreover, the "RTO_BASE" variable is used to recover the previous RTO if the retransmission timer backoff was unnecessary. The variable is initialized with the RTO upon initiation of timeout-based loss recovery.
本文档中指定的方案使用“BACKOFF_CNT”变量，其初始值为零。该变量用于统计一次基于超时的丢失恢复期间执行的重传计时器退避次数。此外，如果不需要重传计时器退避，“RTO_BASE”变量用于恢复先前的RTO。在启动基于超时的丢失恢复时，使用RTO初始化变量。
(1) Before TCP updates the variable "RTO" when it initiates timeout-based loss recovery, set the variables "BACKOFF_CNT" and "RTO_BASE" as follows:
(1) 在TCP启动基于超时的丢失恢复时更新变量“RTO”之前，请按如下方式设置变量“BACKOFF_CNT”和“RTO_BASE”：
BACKOFF_CNT := 0; RTO_BASE := RTO.
退避系数：=0；RTO_BASE:=RTO。
Proceed to step (R).
转至步骤（R）。
(R) This is a placeholder for standard TCP's behavior in case the retransmission timer has expired. In particular, if RFC 2988 [RFC2988] is used, steps (5.4) to (5.6) of that algorithm go here. Proceed to step (2).
（R） 这是在重传计时器过期时标准TCP行为的占位符。特别是，如果使用RFC 2988[RFC2988]，则该算法的步骤（5.4）至（5.6）如下所示。转至步骤（2）。
(2) To account for the expiration of the retransmission timer in the previous step (R), increment the "BACKOFF_CNT" variable by one:
(2) 为了说明上一步骤（R）中重传计时器的过期，将“BACKOFF_CNT”变量增加1：
BACKOFF_CNT := BACKOFF_CNT + 1.
退避措施：=退避措施+1。
(3) Wait either
(3) 等等
a) for the expiration of the retransmission timer. When the retransmission timer expires, proceed to step (R); or
a) 对于重传计时器的过期。当重传定时器到期时，进入步骤（R）；或
b) for the arrival of an acceptable ACK. When an acceptable ACK arrives, proceed to step (A); or
b) 用于到达可接受的ACK。当可接受的ACK到达时，进行步骤（A）；或
c) for the arrival of an ICMP unreachable message. When the ICMP unreachable message "ICMP_DU" arrives, proceed to step (4).
c) 用于ICMP无法访问消息的到达。当ICMP不可访问消息“ICMP_DU”到达时，转至步骤（4）。
(4) If "BACKOFF_CNT > 0", i.e., if at least one retransmission timer backoff can be undone, then
(4) 如果“退避>0”，即，如果至少一个重传计时器退避可以撤消，则
proceed to step (5);
进行步骤（5）；
else
其他的
proceed to step (3).
转至步骤（3）。
(5) Extract the TCP segment header included in the ICMP unreachable message "ICMP_DU":
(5) 提取ICMP不可访问消息“ICMP_DU”中包含的TCP段头：
SEG := Extract(ICMP_DU).
SEG:=提取（ICMP_-DU）。
(6) If "SEG.SEQ == SND.UNA", i.e., if the TCP segment "SEG" eliciting the ICMP unreachable message "ICMP_DU" contains the sequence number of a retransmission, then
(6) 如果“SEG.SEQ==SND.UNA”，即，如果引发ICMP不可到达消息“ICMP_DU”的TCP段“SEG”包含重传的序列号，则
proceed to step (7);
进行步骤（7）；
else
其他的
proceed to step (3).
转至步骤（3）。
(7) Undo the last retransmission timer backoff:
(7) 撤消上次重新传输计时器后退：
BACKOFF_CNT := BACKOFF_CNT - 1; RTO := min(RTO_BASE * 2^(BACKOFF_CNT), MAX_RTO).
退避系数：=退避系数-1；RTO:=最小值（RTO_BASE*2^（BACKOFF_CNT），最大值（RTO）。
(8) If the retransmission timer expires due to the undoing in the previous step (7), then
(8) 如果由于上一步骤（7）中的撤消而导致重传计时器过期，则
proceed to step (R);
进行步骤（R）；
else
其他的
proceed to step (3).
转至步骤（3）。
(A) This is a placeholder for standard TCP's behavior in case an acceptable ACK has arrived. No further processing.
（A） 这是标准TCP行为的占位符，以防收到可接受的ACK。无需进一步处理。
When a TCP in steady-state detects a segment loss using the retransmission timer, it enters the timeout-based loss recovery and initiates the algorithm (step (1)). It adjusts the slow-start threshold (ssthresh), sets the congestion window (cwnd) to one segment, backs off the retransmission timer, and retransmits the first unacknowledged segment (step (R)) [RFC5681], [RFC2988]. To account for the expiration of the retransmission timer, the TCP sender increments the "BACKOFF_CNT" variable by one (step (2)).
当处于稳态的TCP使用重传计时器检测到段丢失时，它进入基于超时的丢失恢复并启动算法（步骤（1））。它调整慢启动阈值（ssthresh），将拥塞窗口（cwnd）设置为一个段，退出重传计时器，并重传第一个未确认的段（步骤（R））[RFC5681]，[RFC2988]。为了说明重传计时器的过期，TCP发送方将“BACKOFF_CNT”变量增加1（步骤（2））。
In case the retransmission timer expires again (step (3a)), a TCP will repeat the retransmission of the first unacknowledged segment and back off the retransmission timer once more (step (R)) [RFC2988], as well as increment the "BACKOFF_CNT" variable by one (step (2)). Note that a TCP may implement RFC 2988's [RFC2988] option to place a maximum value on the RTO that may result in not performing the retransmission timer backoff. However, step (2) MUST always and unconditionally be applied, no matter whether or not the retransmission timer is actually backed off. In other words, each time the retransmission timer expires, the "BACKOFF_CNT" variable MUST be incremented by one.
如果重传计时器再次过期（步骤（3a）），TCP将重复第一个未确认段的重传，并再次退出重传计时器（步骤（R））[RFC2988]，以及将“退避”变量增加1（步骤（2））。注意，TCP可以实现RFC 2988的[RFC2988]选项，以在RTO上设置可能导致不执行重传定时器退避的最大值。然而，无论重传计时器是否实际后退，都必须始终且无条件地应用步骤（2）。换句话说，每次重传计时器过期时，“BACKOFF_CNT”变量必须递增1。
If the first received packet after the retransmission(s) is an acceptable ACK (step (3b)), a TCP will proceed as normal, i.e., slow-start the connection and terminate the algorithm (step (A)). Later ICMP unreachable messages from the just terminated timeout-based loss recovery are ignored, since the ACK clock is already restarting due to the successful retransmission.
如果在重传之后接收到的第一个分组是可接受的ACK（步骤（3b）），则TCP将正常进行，即，缓慢启动连接并终止算法（步骤（a））。由于ACK时钟已因成功的重新传输而重新启动，因此忽略刚终止的基于超时的丢失恢复的后续ICMP不可访问消息。
On the other hand, if the first received packet after the retransmission(s) is an ICMP unreachable message (step (3c)), and if step (4) permits it, TCP SHOULD undo one backoff for each ICMP
另一方面，如果在重传之后接收到的第一个数据包是ICMP不可到达的消息（步骤（3c）），并且如果步骤（4）允许，TCP应该为每个ICMP撤消一次退避
unreachable message reporting an error on a retransmission. To decide if an ICMP unreachable message was elicited by a retransmission, the sequence number it contains is inspected (step (5), step (6)). The undo is performed by recalculating the RTO with the decremented "BACKOFF_CNT" variable (step (7)). This calculation explicitly matches the (bounded) exponential backoff specified in rule (5.5) of [RFC2988].
无法访问的消息，报告重新传输时出错。为了确定ICMP无法到达的消息是否是由重新传输引起的，需要检查它包含的序列号（步骤（5），步骤（6））。通过使用递减的“BACKOFF_CNT”变量重新计算RTO来执行撤销（步骤（7））。该计算明确匹配[RFC2988]规则（5.5）中规定的（有界）指数回退。
Upon receipt of an ICMP unreachable message that legitimately undoes one backoff, there is the possibility that the shortened retransmission timer has already expired (step (8)). Then, TCP SHOULD retransmit immediately. In case the shortened retransmission timer has not yet expired, TCP MUST wait accordingly.
在接收到合法撤销一次退避的ICMP不可到达消息时，有可能缩短的重新传输计时器已经过期（步骤（8））。然后，TCP应该立即重新传输。如果缩短的重传计时器尚未过期，TCP必须相应地等待。
TCP-LCD takes caution to only react to connectivity disruption indications in the form of ICMP unreachable messages during timeout-based loss recovery. Therefore, TCP's behavior is not altered when either no ICMP unreachable messages are received or the retransmission timer of the TCP sender did not expire since the last received acceptable ACK. Thus, by definition, the algorithm triggers only in the case of long connectivity disruptions.
TCP-LCD注意在基于超时的丢失恢复期间，仅对ICMP不可访问消息形式的连接中断指示作出反应。因此，如果没有收到ICMP不可访问的消息，或者TCP发送方的重传计时器自上次收到可接受的ACK后未过期，则TCP的行为不会改变。因此，根据定义，该算法仅在长时间连接中断的情况下触发。
Only such ICMP unreachable messages that contain a TCP segment with the sequence number of a retransmission, i.e., that contain SND.UNA, are evaluated by TCP-LCD. All other ICMP unreachable messages are ignored. The arrival of those ICMP unreachable messages provides strong evidence that the retransmissions were not dropped due to congestion, but were successfully delivered to the reporting router. In other words, there is no evidence for any congestion at least on that very part of the path that was traversed by both the TCP segment eliciting the ICMP unreachable message and the ICMP unreachable message itself.
TCP-LCD仅评估包含具有重传序列号的TCP段（即，包含SND.UNA）的ICMP不可访问消息。忽略所有其他ICMP无法访问的消息。这些ICMP无法到达的消息的到达提供了强有力的证据，证明重传没有因为拥塞而中断，而是成功地传送到了报告路由器。换句话说，至少在引发ICMP不可访问消息的TCP段和ICMP不可访问消息本身所经过的路径的这一部分上，没有证据表明存在任何拥塞。
However, there are some situations where TCP-LCD makes a false decision and incorrectly undoes a retransmission timer backoff. This can happen, even when the received ICMP unreachable message contains the segment number of a retransmission (SND.UNA), because the TCP segment that elicited the ICMP unreachable message may either not be a retransmission (Section 5.1) or does not belong to the current timeout-based loss recovery (Section 5.2). Finally, packet duplication (Section 5.3) can also spuriously trigger the algorithm.
但是，在某些情况下，TCP-LCD会做出错误的决定，并错误地撤消重传计时器回退。即使接收到的ICMP不可到达消息包含重传的段号（SND.UNA），也可能发生这种情况，因为引发ICMP不可到达消息的TCP段可能不是重传（第5.1节），或者不属于当前基于超时的丢失恢复（第5.2节）。最后，数据包复制（第5.3节）也会错误地触发算法。
Section 5.4 discusses possible probing frequencies, while Section 5.6 describes the motivation for not reacting to ICMP unreachable messages while TCP is in steady-state.
第5.4节讨论了可能的探测频率，而第5.6节描述了TCP处于稳定状态时不响应ICMP不可到达消息的动机。
Historically, the retransmission ambiguity problem [Zh86], [KP87] is the TCP sender's inability to distinguish whether the first acceptable ACK after a retransmission refers to the original transmission or to the retransmission. This problem occurs after both a Fast Retransmit and a timeout-based retransmit. However, modern TCP implementations can eliminate the retransmission ambiguity with either the help of Eifel [RFC3522], [RFC4015] or Forward RTO-Recovery (F-RTO) [RFC5682].
历史上，重传模糊问题[Zh86]，[KP87]是TCP发送方无法区分重传后的第一个可接受ACK是指原始传输还是指重传。此问题发生在快速重新传输和基于超时的重新传输之后。然而，现代TCP实现可以借助Eifel[RFC3522]、[RFC4015]或前向RTO恢复（F-RTO）[RFC5682]消除重传模糊性。
The reversion strategy of the given algorithm suffers from a form of retransmission ambiguity, too. In contrast to the above case, TCP suffers from ambiguity regarding ICMP unreachable messages received during timeout-based loss recovery. With the TCP segment number included in the ICMP unreachable message, a TCP sender is not able to determine if the ICMP unreachable message refers to the original transmission or to any of the timeout-based retransmissions. That is, there is an ambiguity with regard to which TCP segment an ICMP unreachable message reports on.
给定算法的恢复策略也存在某种形式的重传模糊。与上述情况相反，TCP在基于超时的丢失恢复期间收到的ICMP不可访问消息方面存在歧义。由于ICMP不可访问消息中包含TCP段号，TCP发送方无法确定ICMP不可访问消息是指原始传输还是任何基于超时的重新传输。也就是说，ICMP不可访问消息报告的TCP段不明确。
However, this ambiguity is not considered to be a problem for the algorithm. The assumption that a received ICMP unreachable message provides evidence that a non-congestion loss caused by the connectivity disruption was wrongly considered a congestion loss still holds, regardless of to which TCP segment (transmission or retransmission) the message refers.
然而，这种模糊性不被认为是算法的问题。接收到的ICMP不可访问消息的假设提供了证据，证明连接中断导致的非拥塞丢失被错误地视为拥塞丢失，无论消息引用的TCP段是哪个（传输还是重传）。
Besides the ambiguity whether a received ICMP unreachable message refers to the original transmission or to any of the retransmissions, there is another source of ambiguity related to the TCP sequence numbers contained in ICMP unreachable messages. For high-bandwidth paths, the sequence space may wrap quickly. This might cause delayed ICMP unreachable messages to coincidentally fit as valid input in the proposed scheme. As a result, the scheme may incorrectly undo retransmission timer backoffs. The chances of this happening are minuscule, since a particular ICMP unreachable message would need to contain the exact sequence number of the current oldest outstanding segment (SND.UNA), while at the same time TCP is in timeout-based loss recovery. However, two "worst case" scenarios for the algorithm are possible.
除了接收到的ICMP不可到达消息是指原始传输还是指任何重新传输的模糊性之外，还有另一个与ICMP不可到达消息中包含的TCP序列号相关的模糊性来源。对于高带宽路径，序列空间可能会快速换行。这可能会导致延迟的ICMP不可访问消息恰好适合作为建议方案中的有效输入。因此，该方案可能会错误地撤消重传计时器退避。发生这种情况的可能性很小，因为特定的ICMP不可访问消息需要包含当前最早未完成段（SND.UNA）的确切序列号，而TCP同时处于基于超时的丢失恢复中。然而，该算法有两种“最坏情况”的可能。
For instance, consider a steady-state TCP connection, which will be disrupted at an intermediate router due to a link outage. Upon the expiration of the RTO, the TCP sender enters the timeout-based loss recovery and starts to retransmit the earliest segment that has not
例如，考虑一个稳态TCP连接，它会由于链路中断而在中间路由器中断。RTO到期后，TCP发送方进入基于超时的丢失恢复，并开始重新传输尚未恢复的最早段
been acknowledged (SND.UNA). For some reason, the router delays all corresponding ICMP unreachable messages so that the TCP sender backs the retransmission timer off normally without any undoing. At the end of the connectivity disruption, the TCP sender eventually detects the re-establishment, and it leaves the scheme and finally the timeout-based loss recovery, too. A sequence number wrap-around later, the connectivity between the two peers is disrupted again, but this time due to congestion and exactly at the time at which the current SND.UNA matches the SND.UNA from the previous cycle. If the router emits the delayed ICMP unreachable messages now, the TCP sender would incorrectly undo retransmission timer backoffs. As the TCP sequence number contains 32 bits, the probability of this scenario is at most 1/2^32. Given sufficiently many retransmissions in the first timeout-based loss recovery, the corresponding ICMP unreachable messages could reduce the RTO in the second recovery at most to "RTO_BASE". However, once the ICMP unreachable messages are depleted, the standard exponential backoff will be performed. Thus, the congestion response will only be delayed by some false retransmissions.
已确认（SND.UNA）。出于某种原因，路由器延迟所有相应的ICMP无法访问的消息，以便TCP发送方在不撤消任何操作的情况下正常关闭重传计时器。在连接中断结束时，TCP发送方最终检测到重新建立，并离开该方案，最后离开基于超时的丢失恢复。序列号换行后，两个对等点之间的连接再次中断，但这一次是由于拥塞，并且正好在当前SND.UNA与上一个周期的SND.UNA匹配的时间。如果路由器现在发出延迟的ICMP不可访问消息，TCP发送方将错误地撤消重传计时器退避。由于TCP序列号包含32位，这种情况的概率最多为1/2^32。考虑到在第一次基于超时的丢失恢复中有足够多的重传，相应的ICMP不可访问消息可以将第二次恢复中的RTO最多减少到“RTO_基”。但是，一旦ICMP无法访问的消息耗尽，将执行标准的指数退避。因此，拥塞响应只会因一些错误的重传而延迟。
Similar to the above, consider the case where a steady-state TCP connection with n segments in flight will be disrupted at some point due to a link outage at an intermediate router. For each segment in flight, the router may generate an ICMP unreachable message. However, for some reason, it delays them. Once the link outage is over and the connection has been re-established, the TCP sender leaves the scheme and slow-starts the connection. Following a sequence number wrap-around, a retransmission timeout occurs, just at the moment the TCP sender's current window of data reaches the previous range of the sequence number space again. In case the router emits the delayed ICMP unreachable messages now, spurious undoing of the retransmission timer backoff is possible once, if the TCP segment number contained in the ICMP unreachable messages matches the current SND.UNA, and the timeout was a result of congestion. In the case of another connectivity disruption, the additional undoing of the retransmission timer backoff has no impact. The probability of this scenario is at most n/2^32.
与上述类似，考虑在一个中间路由器中由于链路中断而在某个点中断与飞行中的N段的稳态TCP连接的情况。对于飞行中的每个段，路由器可能会生成一条ICMP无法到达的消息。然而，由于某些原因，它推迟了他们。一旦链路中断结束并重新建立连接，TCP发送方将退出方案并缓慢启动连接。在序列号环绕之后，就在TCP发送方的当前数据窗口再次达到序列号空间的前一个范围时，发生重新传输超时。如果路由器现在发出延迟的ICMP不可访问消息，则如果ICMP不可访问消息中包含的TCP段号与当前SND.UNA匹配，并且超时是拥塞的结果，则可能会出现一次重新传输计时器回退的虚假撤销。在另一个连接中断的情况下，重新传输计时器退避的额外撤消没有影响。这种情况的概率最多为n/2^32。
In case an intermediate router duplicates packets, a TCP sender may receive more ICMP unreachable messages during timeout-based loss recovery than sent timeout-based retransmissions. However, since TCP-LCD keeps track of the number of performed retransmission timer backoffs in the "BACKOFF_CNT" variable, it will not undo more retransmission timer backoffs than were actually performed. Nevertheless, if packet duplication and congestion coincide on the path between the two communicating hosts, duplicated ICMP unreachable
在中间路由器复制数据包的情况下，在基于超时的丢失恢复期间，TCP发送方可能会收到比发送的基于超时的重新传输更多的ICMP无法到达的消息。但是，由于TCP-LCD在“BACKOFF_CNT”变量中跟踪执行的重传计时器退避次数，因此它不会撤消比实际执行的更多的重传计时器退避。然而，如果数据包复制和拥塞在两个通信主机之间的路径上重合，则无法访问复制的ICMP
messages could hide the congestion loss of some retransmissions or ICMP unreachable messages, and the algorithm may incorrectly undo retransmission timer backoffs. Considering the overall impact of a router that duplicates packets, the additional load induced by some spurious timeout-based retransmits can probably be neglected.
消息可能隐藏某些重传或ICMP无法访问消息的拥塞丢失，并且算法可能错误地撤消重传计时器退避。考虑到复制数据包的路由器的总体影响，可能可以忽略一些虚假的基于超时的重传引起的额外负载。
One might argue that if an ICMP unreachable message arrives for a timeout-based retransmission, the RTO shall be reset or recalculated, similar to what is done when an ACK arrives during timeout-based loss recovery (see Karn's algorithm [KP87], [RFC2988]), and a new retransmission should be sent immediately. Generally, this would result in a much higher probing frequency based on the round-trip time to the router where connectivity has been disrupted. However, we believe the current scheme provides a good trade-off between conservative behavior and fast detection of connectivity re-establishment. TCP-LCD focuses on long-connectivity disruptions, i.e., on disruptions that last for several RTOs. Thus, a much higher probing frequency (less than once per RTO) would not significantly increase the available transmission time compared to the duration of the connectivity disruption.
有人可能会争辩说，如果ICMP不可到达消息到达进行基于超时的重新传输，则应重置或重新计算RTO，类似于在基于超时的丢失恢复期间ACK到达时所做的操作（参见Karn的算法[KP87]，[RFC2988]），并且应立即发送新的重新传输。一般来说，这将导致更高的探测频率，这取决于到连接中断的路由器的往返时间。然而，我们相信目前的方案在保守行为和快速检测连通性重建之间提供了一个很好的折衷方案。TCP-LCD侧重于长时间连接中断，即持续数个RTO的中断。因此，与连接中断的持续时间相比，更高的探测频率（每个RTO少于一次）不会显著增加可用传输时间。
It is possible that a TCP sender enters timeout-based loss recovery while the connection is in SYN-SENT or SYN-RECEIVED states [RFC0793]. The algorithm described in this document could also be used for faster connection establishment in networks with connectivity disruptions. However, because existing TCP implementations [RFC5461] already interpret ICMP unreachable messages during connection establishment and abort the corresponding connection, we refrain from suggesting this.
当连接处于SYN-SENT或SYN-RECEIVE状态时，TCP发送方可能会进入基于超时的丢失恢复[RFC0793]。本文档中描述的算法也可用于在连接中断的网络中更快地建立连接。但是，由于现有的TCP实现[RFC5461]已经在连接建立期间解释ICMP不可访问的消息并中止相应的连接，因此我们不建议这样做。
Another exploitation of ICMP unreachable messages in the context of TCP congestion control might seem appropriate, while TCP is in steady-state. As the RTT up to the router that generated the ICMP unreachable message is likely to be substantially shorter than the overall RTT to the destination, the ICMP unreachable message may very well reach the originating TCP while it is transmitting the current window of data. In case the remaining window is large, it might seem appropriate to refrain from transmitting the remaining window as there is timely evidence that it will only trigger further ICMP unreachable messages at that very router. Although this promises improvement from a wastage perspective, it may be counterproductive from a security perspective. An attacker could forge such ICMP
当TCP处于稳定状态时，在TCP拥塞控制上下文中对ICMP不可访问消息的另一次攻击似乎是合适的。由于到生成ICMP不可到达消息的路由器的RTT可能比到目的地的总RTT短得多，ICMP不可到达消息在传输当前数据窗口时很可能到达原始TCP。如果剩余窗口较大，则似乎应避免传输剩余窗口，因为有及时证据表明，它只会在该路由器上触发进一步的ICMP无法访问的消息。虽然从浪费的角度来看，这有助于改善，但从安全的角度来看，这可能会适得其反。攻击者可以伪造这样的ICMP
messages, thereby forcing the originating TCP to stop sending data, very similar to the blind throughput-reduction attack mentioned in [RFC5927].
消息，从而迫使原始TCP停止发送数据，这与[RFC5927]中提到的盲吞吐量降低攻击非常相似。
An additional consideration is the following: in the presence of multi-path routing, even the receipt of a legitimate ICMP unreachable message cannot be exploited accurately, because there is the possibility that only one of the multiple paths to the destination is suffering from a connectivity disruption, which causes ICMP unreachable messages to be sent. Then, however, there is the possibility that the path along which the connectivity disruption occurred contributed considerably to the overall bandwidth, such that a congestion response is very well reasonable. However, this is not necessarily the case. Therefore, a TCP has no means except for its inherent congestion control to decide on this matter. All in all, it seems that for a connection in steady-state, i.e., not in timeout-based loss recovery, reacting to ICMP unreachable messages in regard to congestion control is not appropriate. For the case of timeout-based retransmissions, however, there is a reasonable congestion response, which is skipping further retransmission timer backoffs because there is no congestion indication -- as described above.
另一个需要考虑的问题是：在存在多路径路由的情况下，即使接收到合法的ICMP不可访问消息也无法准确利用，因为有可能只有一条到目的地的多条路径受到连接中断的影响，这会导致发送ICMP无法访问的消息。然而，存在这样的可能性，即发生连接中断的路径对总体带宽的贡献很大，因此拥塞响应非常合理。然而，情况未必如此。因此，TCP除了其固有的拥塞控制之外，没有其他方法来决定这个问题。总而言之，对于处于稳定状态的连接，即不处于基于超时的丢失恢复状态的连接，在拥塞控制方面对ICMP无法访问的消息作出反应似乎是不合适的。然而，对于基于超时的重传，存在合理的拥塞响应，它跳过进一步的重传计时器退避，因为没有拥塞指示——如上所述。
If the TCP Timestamps option [RFC1323] is enabled for a connection, a TCP sender SHOULD use the following algorithm to dissolve the ambiguity issues mentioned in Sections 5.1, 5.2, and 5.3. In particular, both the retransmission ambiguity and the packet duplication problems are prevented by the following TCP-LCD variant. On the other hand, the false positives caused by wrapped sequence numbers cannot be completely avoided, but the likelihood is further reduced by a factor of 1/2^32, since the Timestamp Value field (TSval) of the TCP Timestamps option contains 32 bits.
如果为连接启用了TCP时间戳选项[RFC1323]，则TCP发送方应使用以下算法解决第5.1、5.2和5.3节中提到的歧义问题。特别是，以下TCP-LCD变体可以防止重传模糊性和数据包复制问题。另一方面，无法完全避免由包装序列号引起的误报，但由于TCP Timestamps选项的Timestamp Value字段（TSval）包含32位，因此可能性进一步降低了1/2^32。
Hence, implementers may choose to employ the TCP-LCD with the following modifications.
因此，实现者可以选择使用TCP-LCD，并进行以下修改。
Step (1) is replaced by step (1'):
步骤（1）替换为步骤（1’）：
(1') Before TCP updates the variable "RTO" when it initiates timeout-based loss recovery, set the variables "BACKOFF_CNT" and "RTO_BASE", and the data structure "RETRANS_TS", as follows:
（1'）在TCP启动基于超时的丢失恢复时更新变量“RTO”之前，将变量“BACKOFF_CNT”和“RTO_BASE”以及数据结构“RETRANS_TS”设置如下：
BACKOFF_CNT := 0;
RTO_BASE := RTO;
BACKOFF_CNT := 0;
RTO_BASE := RTO;
RETRANS_TS := [].
RETRANS_TS := [].
Proceed to step (R).
转至步骤（R）。
Step (2) is extended by step (2b):
步骤（2）由步骤（2b）扩展：
(2b) Store the value of the Timestamp Value field (TSval) of the TCP Timestamps option included in the retransmission "RET" sent in step (R) into the "RETRANS_TS" data structure:
（2b）将包括在步骤（R）中发送的重传“RET”中的TCP时间戳选项的时间戳值字段（TSval）的值存储到“retransts”数据结构中：
RETRANS_TS.add(RET.TSval)
重新培训添加（RET.TSval）
Step (6) is replaced by step (6'):
将步骤（6）替换为步骤（6’）：
(6') If "SEG.SEQ == SND.UNA && RETRANS_TS.exists(SEQ.TSval)", i.e., if the TCP segment "SEG" eliciting the ICMP unreachable message "ICMP_DU" contains the sequence number of a retransmission, and the value in its Timestamp Value field (TSval) is valid, then
（6'）如果“SEG.SEQ==SND.UNA&&RETRANS_TS.存在（SEQ.TSval）”，即，如果引发ICMP不可到达消息“ICMP_DU”的TCP段“SEG”包含重新传输的序列号，并且其时间戳值字段（TSval）中的值有效，则
proceed to step (7');
进行步骤（7’）；
else
其他的
proceed to step (3).
转至步骤（3）。
Step (7) is replaced by step (7'):
步骤（7）替换为步骤（7’）：
(7') Undo the last retransmission timer backoff:
（7’）撤消上次重传计时器后退：
RETRANS_TS.remove(SEQ.TSval);
BACKOFF_CNT := BACKOFF_CNT - 1;
RTO := min(RTO_BASE * 2^(BACKOFF_CNT), MAX_RTO).
RETRANS_TS.remove(SEQ.TSval);
BACKOFF_CNT := BACKOFF_CNT - 1;
RTO := min(RTO_BASE * 2^(BACKOFF_CNT), MAX_RTO).
The downside of this variant is twofold. First, the modifications come at a cost: the TCP sender is required to store the timestamps of all retransmissions sent during one timeout-based loss recovery. Second, this variant can only undo a retransmission timer backoff if the intermediate router experiencing the link outage implements [RFC1812] and chooses to include, in addition to the first 64 bits of the payload of the triggering datagram, as many bits as are needed to include the TCP Timestamps option in the ICMP unreachable message.
这种变体的缺点有两个。首先，修改是有代价的：TCP发送方需要存储基于超时的丢失恢复期间发送的所有重传的时间戳。第二，如果经历链路中断的中间路由器实现[RFC1812]并选择除了触发数据报的有效载荷的前64位之外，还包括ICMP不可访问消息中包含TCP时间戳选项所需的尽可能多的位，则此变体只能撤销重传计时器回退。
This section discusses interoperability issues related to introducing TCP-LCD.
本节讨论与引入TCP-LCD相关的互操作性问题。
TCP-LCD may produce side effects for TCP implementations that attempt to detect TCP connection failures by counting timeout-based retransmissions. [RFC1122] states in Section 4.2.3.5 that a TCP host must handle excessive retransmissions of data segments with two thresholds, R1 and R2, that measure the number of retransmissions that have occurred for the same segment. Both thresholds might be measured either in time units or as a count of retransmissions.
TCP-LCD可能会对尝试通过计算基于超时的重新传输来检测TCP连接故障的TCP实现产生副作用。[RFC1122]在第4.2.3.5节中指出，TCP主机必须处理具有两个阈值（R1和R2）的数据段的过度重传，这两个阈值测量同一段发生的重传次数。这两个阈值可以以时间单位或作为重传计数来测量。
Due to TCP-LCD's reversion strategy of the retransmission timer, the assumption that a certain number of retransmissions corresponds to a specific time interval no longer holds, as additional retransmissions may be performed during timeout-based-loss recovery to detect the end of the connectivity disruption. Therefore, a TCP employing TCP-LCD either MUST measure the thresholds R1 and R2 in time units or, in case R1 and R2 are counters of retransmissions, MUST convert them into time intervals that correspond to the time an unmodified TCP would need to reach the specified number of retransmissions.
由于TCP-LCD的重传计时器反转策略，特定次数的重传对应于特定时间间隔的假设不再成立，因为在基于超时的丢失恢复期间可能会执行额外的重传，以检测连接中断的结束。因此，采用TCP-LCD的TCP必须以时间单位测量阈值R1和R2，或者，如果R1和R2是重传计数器，则必须将其转换为与未修改的TCP达到指定重传次数所需的时间相对应的时间间隔。
With Explicit Congestion Notification (ECN) [RFC3168], ECN-capable routers are no longer limited to dropping packets to indicate congestion. Instead, they can set the Congestion Experienced (CE) codepoint in the IP header to indicate congestion. With TCP-LCD, it may happen that during a connectivity disruption, a received ICMP unreachable message has been elicited by a timeout-based retransmission that was marked with the CE codepoint before reaching the router experiencing the link outage. In such a case, a TCP sender MUST, corresponding to Section 6.1.2 of [RFC3168], additionally reset the retransmission timer in case the algorithm undoes a retransmission timer backoff.
使用显式拥塞通知（ECN）[RFC3168]，支持ECN的路由器不再局限于丢弃数据包以指示拥塞。相反，他们可以在IP报头中设置拥塞体验（CE）代码点以指示拥塞。对于TCP-LCD，在连接中断期间，接收到的ICMP不可访问消息可能会在到达经历链路中断的路由器之前，通过基于超时的重新传输（标记为CE代码点）引发。在这种情况下，TCP发送方必须根据[RFC3168]第6.1.2节，在算法撤销重传计时器退避的情况下，额外重置重传计时器。
It is worth noting that IP tunnels, including IPsec [RFC4301], IP encapsulation within IP [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], and others, are compatible with TCP-LCD, as long as the received ICMP unreachable messages can be demultiplexed and extracted appropriately by the TCP sender during timeout-based loss recovery.
值得注意的是，IP隧道，包括IPsec[RFC4301]、IP内的IP封装[RFC2003]、通用路由封装（GRE）[RFC2784]等，与TCP-LCD兼容，只要接收到的ICMP不可访问消息在基于超时的丢失恢复期间可以由TCP发送方适当地解复用和提取。
If, for example, end-to-end tunnels like IPsec in transport mode [RFC4301] are employed, a TCP sender may receive ICMP unreachable messages where additional steps, e.g., also performing decryption in step (5) of the algorithm, are needed to extract the TCP header from these ICMP messages. Provided that the received ICMP unreachable message contains enough information, i.e., SEG.SEQ is extractable, this information can still be used as a valid input for the proposed algorithm.
例如，如果采用诸如传输模式[RFC4301]中的IPsec的端到端隧道，则TCP发送方可以接收ICMP不可到达消息，其中需要额外的步骤，例如，在算法的步骤（5）中执行解密，以从这些ICMP消息提取TCP报头。如果接收到的ICMP不可访问消息包含足够的信息，即SEG.SEQ是可提取的，则该信息仍然可以用作建议算法的有效输入。
Likewise, if IP encapsulation like [RFC2003] is used in some part of the path between the communicating hosts, the tunnel ingress node may receive the ICMP unreachable messages from an intermediate router experiencing the link outage. Nevertheless, the tunnel ingress node may replay the ICMP unreachable messages in order to inform the TCP sender. If enough information is preserved to extract SEG.SEQ, the replayed ICMP unreachable messages can still be used in TCP-LCD.
类似地，如果在通信主机之间的路径的某些部分中使用类似于[RFC2003]的IP封装，则隧道入口节点可能会从经历链路中断的中间路由器接收ICMP不可到达消息。然而，隧道入口节点可以重播ICMP不可到达消息以通知TCP发送方。如果保留了足够的信息以提取SEG.SEQ，则重播的ICMP不可访问消息仍可在TCP-LCD中使用。
Several methods that address TCP's problems in the presence of connectivity disruptions have been proposed in literature. Some of them try to improve TCP's performance by modifying lower layers. For example, [SM03] introduces a "smart link layer", which buffers one segment for each active connection and replays these segments upon connectivity re-establishment. This approach has a serious drawback: previously stateless intermediate routers have to be modified in order to inspect TCP headers, to track the end-to-end connection, and to provide additional buffer space. This leads to an additional need for memory and processing power.
文献中提出了几种在连接中断情况下解决TCP问题的方法。他们中的一些人试图通过修改较低的层来提高TCP的性能。例如，[SM03]引入了一个“智能链路层”，它为每个活动连接缓冲一个段，并在重新建立连接时重放这些段。这种方法有一个严重的缺点：必须修改以前的无状态中间路由器，以便检查TCP头，跟踪端到端连接，并提供额外的缓冲区空间。这导致了对内存和处理能力的额外需求。
On the other hand, stateless link-layer schemes, as proposed in [RFC3819], which unconditionally buffer some small number of packets, may have another problem: if a packet is buffered longer than the maximum segment lifetime (MSL) of 2 min. [RFC0793], i.e., the disconnection lasts longer than the MSL, TCP's assumption that such segments will never be received will no longer be true, violating TCP's semantics [TCP-REXMIT-NOW].
另一方面，[RFC3819]中提出的无状态链路层方案无条件缓冲少量数据包，可能存在另一个问题：如果数据包的缓冲时间长于2分钟的最大段生存期（MSL）[RFC0793]，即断开持续时间长于MSL，TCP关于这些数据段永远不会被接收的假设将不再成立，这违反了TCP的语义[TCP-REXMIT-NOW]。
Other approaches, like the TCP feedback-based scheme (TCP-F) [CRVP01] or the Explicit Link Failure Notification (ELFN) [HV02] inform a TCP sender about a disrupted path by special messages generated and sent from intermediate routers. In the case of a link failure, the TCP sender stops sending segments and freezes its retransmission timers. TCP-F stays in this state and remains silent until either a "route establishment notification" is received or an internal timer expires. In contrast, ELFN periodically probes the network to detect connectivity re-establishment. Both proposals rely on changes to intermediate routers, whereas the scheme proposed in this document is
其他方法，如基于TCP反馈的方案（TCP-F）[CRVP01]或显式链路故障通知（ELFN）[HV02]通过中间路由器生成和发送的特殊消息通知TCP发送方中断的路径。在链路故障的情况下，TCP发送方停止发送段并冻结其重传计时器。TCP-F保持此状态并保持静默，直到收到“路由建立通知”或内部计时器过期。相反，ELFN定期探测网络以检测连接重建。这两个方案都依赖于对中间路由器的更改，而本文件中提出的方案是
a sender-only modification. Moreover, ELFN does not consider congestion and may impose serious additional load on the network, depending on the probe interval.
仅限发件人的修改。此外，ELFN不考虑拥塞，并且可能取决于探测间隔在网络上施加严重的附加负载。
The authors of "ad hoc TCP" (ATCP) [LS01] propose enhancements to identify different types of packet loss by introducing a layer between TCP and IP. They utilize ICMP destination unreachable messages to set TCP's receiver advertised window to zero, thus forcing the TCP sender to perform zero window probing with an exponential backoff. ICMP destination unreachable messages that arrive during this probing period are ignored. This approach is nearly orthogonal to this document, which exploits ICMP messages to undo a retransmission timer backoff when TCP is already probing. In principle, both mechanisms could be combined. However, due to security considerations, it does not seem appropriate to adopt ATCP's reaction, as discussed in Section 5.6.
“ad hoc TCP”（ATCP）[LS01]的作者建议通过在TCP和IP之间引入一个层来增强识别不同类型的数据包丢失的功能。它们利用ICMP目的地不可到达消息将TCP的接收方播发窗口设置为零，从而迫使TCP发送方执行带有指数退避的零窗口探测。在此探测期间到达的ICMP目标不可访问消息将被忽略。此方法与本文档几乎是正交的，它利用ICMP消息在TCP已经探测时撤消重传计时器回退。原则上，这两种机制可以结合使用。然而，出于安全考虑，如第5.6节所述，采用ATCP的反应似乎并不合适。
Schuetz et al. [TCP-RLCI] describe a set of TCP extensions that improve TCP's behavior when transmitting over paths whose characteristics can change rapidly. Their proposed extensions modify the local behavior of TCP and introduce a new TCP option to signal locally received connectivity-change indications (CCIs) to remote peers. Upon receipt of a CCI, they re-probe the path characteristics either by performing a speculative retransmission or by sending a single segment of new data, depending on whether the connection is currently stalled in exponential backoff or transmitting in steady-state, respectively. The authors focus on specifying TCP response mechanisms; nevertheless, underlying layers would have to be modified to explicitly send CCIs to make these immediate responses possible.
Schuetz等人[TCP-RLCI]描述了一组TCP扩展，这些扩展可以改善TCP在特性可以快速变化的路径上传输时的行为。他们提出的扩展修改了TCP的本地行为，并引入了一个新的TCP选项来向远程对等方发送本地接收的连接更改指示（CCI）信号。在接收到CCI后，它们通过执行推测性重传或发送单个新数据段来重新探测路径特征，这分别取决于连接当前是在指数退避中暂停还是在稳态下传输。作者专注于指定TCP响应机制；然而，必须修改底层以显式发送CCI，从而使这些即时响应成为可能。
Generally, an attacker has only two attack alternatives: to generate ICMP unreachable messages to try to make a TCP modified with TCP-LCD flood the network, or to suppress legitimate ICMP unreachable messages to try to slow down the transmission rate of a TCP sender.
通常，攻击者只有两种攻击选择：生成ICMP无法访问的消息以尝试使使用TCP-LCD修改的TCP充斥网络，或抑制合法的ICMP无法访问的消息以尝试降低TCP发送方的传输速率。
In order to generate ICMP unreachable messages that fit as an input for TCP-LCD, an attacker would need to guess the correct four-tuple (i.e., Source IP Address, Source TCP port, Destination IP Address, and Destination TCP port) and the exact segment sequence number of the current timeout-based retransmission. Yet, the correct sequence number is generally hard to guess, given the probability of 1/2^32. Even if an attacker has information about that sequence number (i.e., the attacker can eavesdrop on the retransmissions) the impact on the network load from the attacker may be considered low, since the retransmission frequency is limited by the RTO that was computed before TCP had entered the timeout-based loss recovery. Hence, the
为了生成适合作为TCP-LCD输入的ICMP不可访问消息，攻击者需要猜测正确的四元组（即，源IP地址、源TCP端口、目标IP地址和目标TCP端口）以及当前基于超时的重新传输的准确段序列号。然而，考虑到1/2^32的概率，正确的序列号通常很难猜测。即使攻击者拥有关于该序列号的信息（即，攻击者可以窃听重传），攻击者对网络负载的影响也可能被认为很低，因为重传频率受到TCP进入基于超时的丢失恢复之前计算的RTO的限制。因此
highest probing frequency is expected to be even lower than once per minimum RTO, i.e., 1 s as specified by [RFC2988]. It is important to note that an attacker who can correctly guess the four-tuple and the segment sequence number can easily launch more serious attacks (i.e., hijack the connection), whether or not TCP-LCD is used.
最高探测频率预计甚至低于每最小RTO一次，即[RFC2988]规定的1秒。需要注意的是，无论是否使用TCP-LCD，能够正确猜测四元组和段序列号的攻击者都可以轻松发起更严重的攻击（即劫持连接）。
There may be means by which an attacker can cause the suppression of legitimate ICMP unreachable messages (e.g., by flooding the router experiencing the link outage to trigger ICMP rate-limiting). However, even if the attacker could suppress every legitimate ICMP unreachable message, the security impact of such an attack is negligible, since the TCP sender using TCP-LCD will behave like a regular TCP would. Note that this kind of attack is indistinguishable from a router experiencing a link outage that is not sending ICMP unreachable messages at all (e.g., because of local policy).
攻击者可能会通过某种方式抑制合法的ICMP无法访问的消息（例如，通过使经历链路中断的路由器泛洪来触发ICMP速率限制）。但是，即使攻击者可以抑制每个合法的ICMP无法访问的消息，这种攻击的安全影响也可以忽略不计，因为使用TCP-LCD的TCP发送方的行为将与常规TCP发送方的行为类似。请注意，这种攻击与发生链路中断的路由器无法区分，因为路由器根本不发送ICMP无法访问的消息（例如，由于本地策略）。
In summary, the algorithm proposed in this document is considered to be secure.
总之，本文中提出的算法被认为是安全的。
We would like to thank Lars Eggert, Adrian Farrel, Mark Handley, Kai Jakobs, Ilpo Jarvinen, Enrico Marocco, Catherine Meadows, Juergen Quittek, Pasi Sarolahti, Tim Shepard, Joe Touch, and Carsten Wolff for feedback on earlier versions of this document. We also thank Michael Faber, Daniel Schaffrath, and Damian Lukowski for implementing and testing the algorithm in Linux. Special thanks go to Ilpo Jarvinen for giving valuable feedback regarding the Linux implementation.
我们要感谢Lars Eggert、Adrian Farrel、Mark Handley、Kai Jakobs、Ilpo Jarvinen、Enrico Marocco、Catherine Meadows、Juergen Quitek、Pasi Sarolahti、Tim Shepard、Joe Touch和Carsten Wolff对本文件早期版本的反馈。我们还感谢Michael Faber、Daniel Schaffrath和Damian Lukowski在Linux中实现并测试了该算法。特别感谢Ilpo Jarvinen提供了有关Linux实现的宝贵反馈。
This work has been supported by the German National Science Foundation (DFG) within the research excellence cluster Ultra High-Speed Mobile Information and Communication (UMIC), RWTH Aachen University.
这项工作得到了德国国家科学基金会（DFG）在亚琛工业大学卓越大学超高速移动信息与通信（UMIC）研究所的支持。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]Jacobson，V.，Braden，B.，和D.Borman，“高性能TCP扩展”，RFC 1323，1992年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443]Conta，A.，Deering，S.和M.Gupta，“互联网协议版本6（IPv6）规范的互联网控制消息协议（ICMPv6）”，RFC 4443，2006年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]Allman，M.，Paxson，V.和E.Blanton，“TCP拥塞控制”，RFC 56812009年9月。
[CRVP01] Chandran, K., Raghunathan, S., Venkatesan, S., and R. Prakash, "A feedback-based scheme for improving TCP performance in ad hoc wireless networks", IEEE Personal Communications vol. 8, no. 1, pp. 34-39, February 2001.
[CRVP01]Chandran，K.，Raghunathan，S.，Venkatesan，S.，和R.Prakash，“改进自组织无线网络中TCP性能的基于反馈的方案”，IEEE个人通信第8卷，第1期，第34-39页，2001年2月。
[HV02] Holland, G. and N. Vaidya, "Analysis of TCP performance over mobile ad hoc networks", Wireless Networks vol. 8, no. 2-3, pp. 275-288, March 2002.
[HV02]Holland，G.和N.Vaidya，“移动自组织网络上TCP性能的分析”，无线网络第8卷，第2-3期，第275-288页，2002年3月。
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM'87) pp. 2-7, August 1987.
[KP87]Karn，P.和C.Partridge，“改进可靠传输协议中的往返时间估计”，《计算机通信应用、技术、架构和协议会议记录》（SIGCOMM'87），第2-7页，1987年8月。
[LS01] Liu, J. and S. Singh, "ATCP: TCP for mobile ad hoc networks", IEEE Journal on Selected Areas in Communications vol. 19, no. 7, pp. 1300-1315, July 2001.
[LS01]Liu，J.和S.Singh，“ATCP:TCP用于移动自组织网络”，IEEE通信杂志第19卷第7期，第1300-1315页，2001年7月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784]Farinaci，D.，Li，T.，Hanks，S.，Meyer，D.，和P.Traina，“通用路由封装（GRE）”，RFC 27842000年3月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168]Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522]Ludwig，R.和M.Meyer，“TCP的Eifel检测算法”，RFC 3522，2003年4月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[RFC3782]Floyd，S.，Henderson，T.，和A.Gurtov，“TCP快速恢复算法的NewReno修改”，RFC 3782，2004年4月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819]Karn，P.，Bormann，C.，Fairhurst，G.，Grossman，D.，路德维希，R.，Mahdavi，J.，黑山，G.，Touch，J.，和L.Wood，“互联网子网络设计师的建议”，BCP 89，RFC 3819，2004年7月。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[RFC4015]Ludwig，R.和A.Gurtov，“TCP的Eifel响应算法”，RFC 4015，2005年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC5461]Gont，F.，“TCP对软错误的反应”，RFC 54612009年2月。
[RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP", RFC 5682, September 2009.
[RFC5682]Sarolahti，P.，Kojo，M.，Yamamoto，K.，和M.Hata，“前向RTO恢复（F-RTO）：使用TCP检测虚假重传超时的算法”，RFC 5682，2009年9月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927]Gont，F.，“针对TCP的ICMP攻击”，RFC 5927，2010年7月。
[SESB05] Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol enhancements for intermittently connected hosts", SIGCOMM Computer Communication Review vol. 35, no. 3, pp. 5-18, December 2005.
[SESB05]Schuetz，S.，Eggert，L.，Schmid，S.，和M.Brunner，“间歇性连接主机的协议增强”，SIGCOMM计算机通信评论第35卷，第3期，第5-18页，2005年12月。
[SM03] Scott, J. and G. Mapp, "Link layer-based TCP optimisation for disconnecting networks", SIGCOMM Computer Communication Review vol. 33, no. 5, pp. 31-42, October 2003.
[SM03]Scott，J.和G.Mapp，“基于链路层的TCP断开网络优化”，SIGCOMM计算机通信评论第33卷，第5期，第31-42页，2003年10月。
[TCP-REXMIT-NOW] Eggert, L., Schuetz, S., and S. Schmid, "TCP Extensions for Immediate Retransmissions", Work in Progress, June 2005.
[TCP-REXMIT-NOW]Eggert，L.，Schuetz，S.和S.Schmid，“用于立即重传的TCP扩展”，正在进行的工作，2005年6月。
[TCP-RLCI] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., and K. Le, "TCP Response to Lower-Layer Connectivity-Change Indications", Work in Progress, February 2008.
[TCP-RLCI]Schuetz，S.，Koutsianas，N.，Eggert，L.，Eddy，W.，Swami，Y.，和K.Le，“TCP对下层连接变化指示的响应”，正在进行的工作，2008年2月。
[Zh86] Zhang, L., "Why TCP Timers Don't Work Well", Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM'86) pp. 397-405, August 1986.
[Zh86]Zhang，L.“为什么TCP定时器不能很好地工作”，《计算机通信应用、技术、体系结构和协议会议记录》（SIGCOMM'86），第397-405页，1986年8月。
[ZimHan09] Zimmermann, A., "Make TCP more Robust to Long Connectivity Disruptions", Proceedings of the 75th IETF Meeting slides, July 2009, <http://www.ietf.org/proceedings/75/slides/tcpm-0.pdf>.
[ZimHan09]Zimmermann，A.，“使TCP对长时间的连接中断更加健壮”，第75届IETF会议记录幻灯片，2009年7月<http://www.ietf.org/proceedings/75/slides/tcpm-0.pdf>.
Authors' Addresses
作者地址
Alexander Zimmermann RWTH Aachen University Ahornstrasse 55 Aachen, 52074 Germany
亚历山大·齐默尔曼亚琛大学阿霍恩大街55号，亚琛，52074德国
Phone: +49 241 80 21422
EMail: zimmermann@cs.rwth-aachen.de
Phone: +49 241 80 21422
EMail: zimmermann@cs.rwth-aachen.de
Arnd Hannemann RWTH Aachen University Ahornstrasse 55 Aachen, 52074 Germany
德国亚琛阿霍恩大街55号亚琛亚琛大学
Phone: +49 241 80 21423
EMail: hannemann@nets.rwth-aachen.de
Phone: +49 241 80 21423
EMail: hannemann@nets.rwth-aachen.de