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