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.
長い1つの再送タイムアウトよりも続かエンド・ツー・エンドのパスの接続の中断は、次善の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-LCD）へのTCPをより堅牢にするためのアルゴリズムを提案しています。これは、標準の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.
この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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].
その期間に応じて、接続の中断は、2つの群に分類することができます[TCP-RLCI]：「短い」と「長いです」。接続が初めて再送タイマが起動する前に返す場合、接続の中断は、「短い」です。この場合、TCPは、高速再送信を介してデータセグメントを失い、正常に配信後のACKを介して肯定応答（ACKを）失った回復します。接続の中断は、再送タイマ火災が少なくとも一度接続が再開される前に、与えられた場合、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 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.
長い接続の中断は、TCP接続上で発生すると、TCPの送信者は、最終的には、それ以上の確認応答を受信しません。再送タイマが満了した後、TCPの送信者は、タイムアウトベースの損失回復に入り、失われたとして最古の優れたセグメント（SND.UNA）を宣言します。 TCP密結合の信頼性及び輻輳制御するので、SND.UNAの再送は、伝送速度の減少とともにトリガされます。これは、セグメント損失が輻輳[RFC5681]の指標であるという仮定に基づいています。最古の優れたセグメントが正常に認識されているまで、または接続がタイムアウトするまで限り、接続の中断が解消されないよう、TCPは、この手順を繰り返します。 RFC 2988 [RFC2988]の推奨再送タイムアウト（RTO）の管理に従うTCP実装は、各再送信試行の後にRTOを倍増します。しかし、RTO成長は少なくとも60秒であるが、長くてもよい最大RTOは、上限で囲まれてもよい：Linuxは、例えば、120秒を使用します。接続が2回の再送信試行の間に復元された場合、それは単に接続が再確立されているかどうかを知るためにあらゆる手段を持たないため、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-LCD）に堅牢性を提供するために、TCP送信側のみの変更を指定します。メモは、標準のインターネット制御メッセージプロトコル（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.
TCP-LCDのLinuxの実装の実験結果は、[ZimHan09]で提示されています。実装は、メインラインのLinuxに組み込まれており、すでにインターネット内で使用されます。これまでのところ、何の負の経験は、アルゴリズムに起因することが報告されていません。より現実の結果が得られるまでしかし、我々は実験として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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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 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).
読者は、伝送制御プロトコル（TCP）送信者は、その再送タイマを計算し管理するために使用するために必要な標準的なアルゴリズムを定義[RFC2988]のアルゴリズムとの用語に精通しなければなりません。 [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セグメントを指します。 [RFC0793]で定義されるようにTCPセンダ状態変数「SND.UNA」と現在のセグメント変数「SEG.SEQ」が使用されています。 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.
リンク障害が発生している中間ルータのキューがすべての着信パケットをバッファリングすることができれば、接続性の中断は、アイフェル[RFC3522]、[RFC4015]または転送RTOのいずれかを使用して、TCP実装によってうまく処理された遅延の変化を引き起こすであろう-recovery（F-RTO）[RFC5682]。リンク停止が長すぎるために持続する場合は、リンク停止を経験したルータは、パケットを廃棄することを余儀なくされ、最終的にそのルーティングテーブルから対応するネクストホップを削除することができます。含ま失敗したアドレス解決プロトコル（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 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.
特定の宛先への他の経路が存在しないことを条件とする、インターネットプロトコルバージョン4（IPv4）[RFC0791]ルータは、ICMP宛先到達不能コード0のメッセージ（ネット到達不能）またはコード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.
インターネットプロトコルバージョン6（IPv6）[RFC2460]のために、コード0のICMP宛先到達不能メッセージ（ネット到達不能）の、コード1の対応は、（到達不能ホスト）コード0のICMPv6の宛先到達不能メッセージ（宛先へのルート）であります[RFC4443]。 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と、さらなる調査（例えば、ICMP宛先到達不能メッセージ（ソースルートが失敗した）、コード11（サービスの（タイプ）TOSのためのネット到達不能）、またはコード12が必要（TOSのために到達できないホスト）[RFC1812]）。一方、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.
簡単にするために、我々はこれが意味するコード0またはコード1とのICMPv6先のICMP宛先到達不能メッセージコード0の到達不能メッセージの同義語として、ICMPv4のか、ICMPv6ので明示的に修飾しない限り、用語「ICMP到達不能メッセージ」を使用します。受信したICMPメッセージの取り扱いとその対処[RFC2119]からのすべてのキーワードは、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到達不能メッセージを送信しない場合があります。両方の特殊性は、ICMPv6のためのICMPv4と[RFC4443]のために[RFC1812]に由来します。
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の到達不能メッセージは、自分の体で、全体のIPv4ヘッダICMPv4の到達不能メッセージを引き出すデータグラムの[RFC0791]、プラスそのデータグラムのペイロードの最初の64ビットを含んでいなければなりません。これは、送信ホストはそれを誘発したトランスポート接続にICMPv4のエラーメッセージを一致させることができます。 RFC 1812 [RFC1812]は、これらの要件を増強し、ICMPv4のメッセージは576バイトを超えるICMPv4のデータグラムの長さなしに、可能な限り元のデータグラムのできるだけ多くを含むべきであると述べています。したがって、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エラーメッセージのペイロードは、エラーメッセージが最小のIPv6 MTU（1280バイト）[RFC4443]を超えることなく、ICMPv6エラーメッセージを誘発したIPv6データグラムからできるだけ多くのバイトを含まなければなりません。したがって、十分な情報が影響を受ける接続と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到達不能メッセージとICMP到達不能メッセージ自体を引き出すTCPセグメントの両方が横断したパスのその部分上の任意の輻輳を目撃しませんでした。
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到達不能メッセージは、おそらく失われた再送シーケンス番号を持つセグメントが含まれて受信されるたびに1つの再送タイマバックオフを元に戻すことにより、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).
TCPの再送タイマを計算するために、RFC 2988 [RFC2988]を使用するTCP送信者は、長い接続の中断の場合には過保守的な再送タイマバックオフを回避するために、以下のスキームを採用することができます。 TCP送信者は、以下のステップを実行した場合、アルゴリズムは、最も古い未解決のセグメント（SND.UNA）の最初のタイムアウト時に開始しなければならなくて、最初に許容可能なACKの到着時に停止しなければなりません。このアルゴリズムは、同じセグメントのために、その後のタイムアウト時に再開始してはなりません。スキームはSYN-SENTまたはSYN-RECEIVED状態で使用すべきではない[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.
TCPの再送タイマを計算するために、RFC 2988 [RFC2988]を使用しないTCPの送信者はTCP-LCDを使用してはなりません。私たちは、しかし、我々はこのように将来の仕事を残す仕組みを簡単にRFC 2988.以外のアルゴリズムに適合させることができることを想定しています。
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」変数を、使用しています。変数は1、タイムアウトベースの損失回復の間に行わ再送タイマバックオフの数をカウントするために使用されます。また、「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.
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.6）へのステップ（5.4）がここに入ります。 （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」変数をインクリメントします。
BACKOFF_CNT := BACKOFF_CNT + 1.
BACKOFF_CNT：= BACKOFF_CNT + 1。
(3) Wait either
（3）のいずれかを待ち
a) for the expiration of the retransmission timer. When the
retransmission timer expires, proceed to step (R); or
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）「BACKOFF_CNT> 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」、すなわち、TCPセグメント「SEG」ICMP到達不能メッセージ「ICMP_DU」を誘発するが、再送信のシーケンス番号が含まれている場合、もし
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).
(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.
許容できるACKが到着した場合には（A）これは、標準のTCPの挙動のプレースホルダです。これ以上の処理はありません。
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）を設定し、再送タイマーがバックオフし、第1の不承認のセグメント（ステップ（R））[RFC5681]、[RFC2988]を再送します。再送タイマの満了を説明するために、TCPの送信者は1で、「BACKOFF_CNT」変数をインクリメントし（ステップ（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は最初不承認のセグメントの再送を繰り返し、バック再送タイマーオフ「BACKOFF_CNT（ステップ（R））[RFC2988]、ならびに増加もう一度う「可変一つ（ステップ（2））。 TCPは再送タイマバックオフを行わない結果になるかも知れませんRTO上の最大値を配置するRFC 2988の[RFC2988]オプションを実装することがあります。しかし、ステップ（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.
再送（S）後の最初の受信パケットが許容される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 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].
一方、再送（S）の後であれば最初の受信パケットはICMP到達不能メッセージ（ステップ（3C））であり、ステップ（4）は、それを許可する場合、TCPはエラーを報告し、各ICMP到達不能メッセージのための一つのバックオフを取り消すべきです再送信に。 ICMP到達不能メッセージを再送することによって誘発されたかどうかを決定するために、それに含まれるシーケンス番号が検査される（ステップ（5）、ステップ（6））。アンドゥがデクリメント「BACKOFF_CNT」変数（ステップ（7））とRTOを再計算することによって行われます。この計算は、明示的に[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.
合法的に1つのバックオフを取り消し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の動作が変更されていないか、TCPの送信側の再送タイマは、最後に受信許容ACKので、有効期限はありませんでした。従って、定義により、アルゴリズムは、長い接続の中断の場合にトリガー。
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.
SND.UNAを含む、すなわち再送シーケンス番号とTCPセグメントを含むだけそのようなICMP到達不能メッセージは、TCP-LCDによって評価されます。他のすべてのICMP到達不能メッセージは無視されます。これらのICMP到達不能メッセージの到着は再送信が輻輳によるドロップされなかったが、成功した報告ルータに配信されたという強力な証拠を提供します。換言すれば、ICMP到達不能メッセージとICMP到達不能メッセージ自体を引き出すTCPセグメントの両方が横断したパスの非常に一部上の少なくともいずれかの輻輳のための証拠はありません。
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到達不能メッセージを誘発したTCPセグメントが再送（セクション5.1）ではないかもしれないいずれか、またはにも属していないため、受信したICMP到達不能メッセージは、再送（SND.UNA）のセグメント番号が含まれている場合であっても、発生する可能性が現在のタイムアウトベースの損失回復（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.6節は、TCPが定常状態にある間、ICMP到達不能メッセージに反応しないための動機を説明しながら、5.4節では、可能なプロービングの周波数を説明します。
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]再送後の最初の許容されるACKが元の送信または再送信を指すかどうかを区別するためのTCP送信者のできないことです。この問題は、高速再送、タイムアウトベースの再送信の両方の後に発生します。しかし、現代のTCP実装はアイフェルの助け[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到達不能メッセージが同時にTCPタイムアウトベースの損失回復している間、現在の最も古い未解決のセグメント（SND.UNA）の正確なシーケンス番号を含む必要があるからであるこの出来事の可能性は、非常に小さいです。しかし、アルゴリズムのための2つの「最悪の場合」のシナリオが可能です。
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 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.
例えば、リンク停止に起因する中間ルータで中断されます定常状態のTCP接続を、考えます。 RTOが満了すると、TCPの送信者は、タイムアウトベースの損失回復に入り、確認されていない最も古いセグメント（SND.UNA）を再送信を開始します。 TCPの送信側が任意の破滅せずに正常に再送タイマーをオフにバックアップするようにいくつかの理由で、ルータはすべて、対応するICMP到達不能メッセージを遅らせます。接続の中断の終わりには、TCPの送信者は、最終的に再確立を検出し、それはあまりにも、スキームと最終的には、タイムアウトベースの損失回復を残します。シーケンス番号ラップアラウンド後、2つのピア間の接続が再び破壊されるが、輻輳へと正確に電流SND.UNAは、前のサイクルからSND.UNAと一致した時点で、この時間。ルータは今遅れICMP到達不能メッセージを発する場合は、TCPの送信者が間違って再送タイマバックオフを元に戻します。 TCPシーケンス番号は32ビットを含むように、このシナリオの確率は、1/2 ^ 32以下です。最初のタイムアウトベースの損失回復が十分に多くの再送信を考えると、対応するICMP到達不能メッセージは、ほとんどが「RTO_BASE」で第2の回収に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到達不能メッセージに含まれるTCPセグメントの数は現在のSND.UNAと一致し、タイムアウトが輻輳の結果であった場合は再送タイマーのバックオフのスプリアス元に戻すには、一度可能であり、今遅延ICMP到達不能メッセージを発します。別の接続の中断の場合には、再送タイマバックオフの追加の取り消しは影響を及ぼしません。このシナリオの確率は、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 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.
中間ルーターがパケットを複製する場合には、TCPの送信者は送信され、タイムアウトベースの再送信よりも、タイムアウトベースの損失回復の間に多くのICMP到達不能メッセージを受け取ることができます。 TCP-LCDは「BACKOFF_CNT」変数に行わ再送タイマバックオフの数を追跡しますので、しかし、それは実際に行われたよりも多くの再送タイマバックオフを元に戻すことはできません。パケット複製及び輻輳が2つの通信ホスト間のパスに一致する場合、それにもかかわらず、重複ICMP到達不能メッセージは、いくつかの再送信または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がタイムアウトベースの損失回復の間に到着した際に行われているものに似て再計算することを主張するかもしれない（カーンのアルゴリズム[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-RECEIVED状態[RFC0793]でありながら、TCPの送信側がタイムアウトベースの損失回復に入っている可能性があります。この文書に記載されたアルゴリズムはまた、接続の中断を持つネットワークでのより高速な接続の確立に使用することができます。既存の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 messages, thereby forcing the originating TCP to stop sending data, very similar to the blind throughput-reduction attack mentioned in [RFC5927].
TCPは定常状態にある間、TCPの輻輳制御のコンテキストでICMP到達不能メッセージの別の搾取は、適切なように見えるかもしれません。 ICMP到達不能メッセージを生成したルータまでのRTTが先に全体のRTTよりも実質的に短い可能性があるとして、それはデータの現在のウィンドウを送信している間、ICMP到達不能メッセージは非常によく、発信TCPに達する可能性があります。残りのウィンドウが大きい場合には、それだけで非常にルータでさらにICMP到達不能メッセージをトリガすることをタイムリーに証拠があるとして、残りの透過窓を控えるように適切に思えるかもしれません。これは、無駄の観点から改善を約束しますが、それはセキュリティの観点から逆効果かもしれません。攻撃者は、それによって[RFC5927]に記載されたブラインドスループット縮小攻撃に非常に類似したデータを、送信を停止する発信TCPを強制的に、そのようなICMPメッセージを偽造することができました。
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タイムスタンプ・オプションのタイムスタンプ値フィールド（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:
以下のようにTCPの前に（1' ）は、変数 『RTO』それはタイムアウトベースの損失回復を開始したときに、変数 『BACKOFF_CNT』と 『RTO_BASE』を設定し、データ構造 『RETRANS_TS』を更新します。
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）「RETRANS_TS」データ構造に工程（R）に送信される再送「RET」に含まれるTCPタイムスタンプ・オプションのタイムスタンプ値フィールド（TSval）の値を格納。
RETRANS_TS.add(RET.TSval)
RETRANS_TS.add（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.exists（SEQ.TSval）"、すなわち、TCPセグメント "SEG" ICMP到達不能メッセージ "ICMP_DU" を誘発するが、再送信のシーケンス番号が含まれている場合、そしてそのタイムスタンプ値フィールド（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).
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.
この変形の欠点は2つある。まず、変更はコストで来る：TCPの送信者は1、タイムアウトベースの損失回復中に送信されたすべての再送のタイムスタンプを格納する必要があります。中間ルータがトリガデータグラムのペイロードの最初の64ビットに加えて、リンク停止用具[RFC1812]を経験し、含むことを選択した場合に必要とされるように、第2に、この変異体は、多くのビットとして、再送タイマバックオフを元に戻すことができ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]はTCPホストが同一のセグメントで発生した再送信の数を測定する二つの閾値、R1とR2とのデータセグメントの過度の再送信を処理する必要があり、セクション4.2.3.5で述べています。両方のしきい値は、時間単位または再送回数のいずれかとして測定することがあります。
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.
これは、IPsec [RFC4301]、IP [RFC2003]、総称ルーティングカプセル化（GRE）[RFC2784]内のIPカプセル化、およびその他を含むIPトンネルは、受信したICMP到達不能メッセージ限り、TCP-LCDと互換性があることは注目に値しますタイムアウトベースの損失回復の間、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.
例えば、トランスポート・モードのIPsecのようなエンド・ツー・エンドのトンネル[RFC4301]は使用された場合、TCP送信者は、ここで追加のステップICMP到達不能メッセージを受信することができ、アルゴリズムのステップにおいて、例えば、も行う復号（5）、必要とされていますこれらのICMPメッセージからTCPヘッダを抽出します。すなわち、SEG.SEQが抽出された受信ICMP到達不能メッセージは、十分な情報が含まれていることを設け、この情報は、まだ提案されたアルゴリズムの有効な入力として使用することができます。
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到達不能メッセージを受信することができます。それにもかかわらず、トンネル入口ノードは、TCPの送信者に通知するためにICMP到達不能メッセージを再生します。十分な情報が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は、各アクティブな接続のための1つのセグメントをバッファリングおよび接続の再確立時に、これらのセグメントを再生する「スマートリンク層」を導入します。このアプローチは、重大な欠点を有する：以前にステートレス中間ルータは、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-REXMIT-NOW] TCPのセマンティクスに違反し、trueになります。
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 a sender-only modification. Moreover, ELFN does not consider congestion and may impose serious additional load on the network, depending on the probe interval.
TCPのフィードバックに基づく方式（TCP-F）[CRVP01]または明示的なリンク障害通知（ELFN）HV02]のような他のアプローチは、中間ルータから生成され、送信された特別なメッセージによって破壊パス約TCP送信者に通知します。リンク障害が発生した場合には、TCPの送信者は、セグメントの送信を停止し、その再送タイマーをフリーズします。 TCP-Fはこの状態にとどまり、「ルート確立通知」のいずれかが受信されているか、内部タイマが満了するまで沈黙します。対照的に、ELFNは、定期的に再確立の接続を検出するためにネットワークをプローブ。この文書で提案する方式は、送信側のみの変更であるのに対し、どちらの提案は、中間ルータへの変更に依存しています。また、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.
「アドホックTCP」（ATCP）[LS01]の著者らは、TCPとIPとの間の層を導入することによって、パケット損失の種類を識別するための拡張を提案します。彼らは、ICMP宛先到達不能メッセージは、このように指数バックオフでプローブゼロウィンドウを実行するには、TCPの送信者を強制的に、TCPの受信機はゼロにウィンドウを宣伝設定し利用します。このプロービング期間中に到着したICMP宛先到達不能メッセージは無視されます。このアプローチは、TCPがすでに探査された再送タイマバックオフを元に戻すためにICMPメッセージを利用し、この文書にほぼ直交しています。原則的には、両方のメカニズムを組み合わせることができます。しかし、セキュリティ上の配慮のために、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の地元の動作を変更し、リモートピアにローカル受信接続変更の兆候（のCCI）を知らせるための新しいTCPオプションをご紹介します。 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.
一般的に、攻撃者は2つだけの攻撃の選択肢があります：TCP-LCDに変更されたTCPは、ネットワークを氾濫させるために、またはTCPの送信側の伝送速度を遅くしようとする正当なICMP到達不能メッセージを抑制しようとするICMP到達不能メッセージを生成します。
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 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.
TCP-LCDのための入力としてフィットICMP到達不能メッセージを生成するためには、攻撃者が正しい4タプルを推測する必要があります（すなわち、送信元IPアドレス、ソースTCPポート、宛先IPアドレス、宛先TCPポート）及び現在のタイムアウトに基づく再送の正確なセグメントシーケンス番号。まだ、正しいシーケンス番号は、1/2 ^ 32の確率を考えると、一般的に推測することは困難です。攻撃者は、そのシーケンス番号（すなわち、攻撃者が再送信を盗聴することができる）、再送回数がTCPが持っていた前に計算されたRTOによって制限されるため、攻撃者からネットワーク負荷への影響は、低いとみなすことができる情報を有していてもタイムアウトベースの損失回復に入りました。したがって、最高プロービング周波数は[RFC2988]で指定されるように、すなわち、1秒、一度最小RTOあたりよりさらに低いことが予想されます。正確に4組とセグメントシーケンス番号を推測することができ、攻撃者が簡単に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到達不能メッセージの抑制を引き起こすことができる手段があるかもしれません。 TCP-LCDを使用してTCPの送信側が希望通常のTCPのように動作しますので、しかし、攻撃者は、すべての正当なICMP到達不能メッセージを抑制できたとしても、このような攻撃のセキュリティへの影響は、軽微であります。この種の攻撃は（あるため、ローカルポリシーの、例えば）全ての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.
私たちは、この文書の以前のバージョンへのフィードバックのためにラースエッゲルト、エードリアンファレル、マーク・ハンドリー、甲斐Jakobs、Ilpo Jarvinen、エンリコMarocco、キャサリン・メドウズ、ユルゲンQuittek、パシSarolahti、ティム・シェパード、ジョー・タッチ、そしてカールステン・ウルフに感謝したいと思います。また、Linuxでのアルゴリズムを実装し、テストのためにマイケル・フェーバー、ダニエルSchaffrath、そしてダミアンLukowskiに感謝します。特別な感謝は、Linuxの実装に関する貴重なフィードバックを与えるためIlpo Jarvinenに行きます。
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.
この作品は、研究の卓越性クラスターの超高速モバイル情報通信（UMIC）、アーヘン工科大学内ドイツ国立科学財団（DFG）によって支えられてきました。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、B.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティング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]コンタ、A.、デアリング、S.、およびM.グプタ、 "インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（ICMPv6の）"、RFC 4443、2006年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681]オールマン、M.、パクソン、V.、およびE.ブラントン、 "TCP輻輳制御"、RFC 5681、2009年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]チャンドラン、K.、Raghunathan、S.、Venkatesan、S.、およびR.プラカシュ、「アドホック無線ネットワークにおける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]オランダ、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]カーン、P.とC.ヤマウズラ、「信頼性の高いトランスポートプロトコルにラウンドトリップ時間の見積りの改善」、アプリケーション、技術、アーキテクチャ、およびコンピュータ通信（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]劉、J.及びS.シン、「ATCP：モバイルアドホックネットワークのためのTCP」通信VOLに選択された領域に、IEEEジャーナル。 19、ありません。 7頁。1300年から1315年、2001年7月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年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]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上で送信するためのイーサネットアドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、 "インターネットホストのための要件 - 通信層"、STD 3、RFC 1122、1989年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]パーキンス、C.、 "IP内IPカプセル化"、RFC 2003、1996年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
"IPに明示的輻輳通知の添加（ECN）" [RFC3168]ラマクリシュナン、K.、フロイド、S.、およびD.ブラック、RFC 3168、2001年9月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522]ルートヴィヒ、R.及びM.マイヤー、 "TCPのためのアイフェル検出アルゴリズム"、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]フロイド、S.、ヘンダーソン、T.、およびA. Gurtov、RFC 3782、2004年4月 "TCPの高速回復アルゴリズムにNewRenoの変更"。
[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]カーン、P.、ボルマン、C.、Fairhurst、G.、グロスマン、D.、ルートヴィヒ、R.、Mahdavi、J.、モンテネグロ、G.、タッチ、J.、およびL.ウッド、「アドバイスインターネットサブネットワークデザイナー」、BCP 89、RFC 3819、2004年7月のため。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[RFC4015]ルートヴィヒ、R.とA. Gurtov、 "TCPのためのアイフェルレスポンスアルゴリズム"、RFC 4015、2005年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC 5461]。、 "ソフトエラーへのTCPの反応" のフォント、RFC 5461、2009年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.、古城、M.、山本、K.、およびM.秦、 "フォワード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.、シュミット、S.、およびM.ブルンナー、 "断続的に接続されたホストのためのプロトコルの強化"、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]スコット、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]エッゲルト、L.、Schuetz、S.、およびS.シュミッド、 "即時再送信のための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.、エッゲルト、L.、エディ、W.、スワミ、Y.、およびK.ル、 "下層接続-変更効能に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]チャン、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]ツィンマーマン、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
電話：+49 241 80 21422 Eメール：zimmermann@cs.rwth-aachen.de
Arnd Hannemann RWTH Aachen University Ahornstrasse 55 Aachen, 52074 Germany
Arnd Hannemannアーヘン工科大学のカエデシュトラーセ55アーヘン、ドイツ52074
Phone: +49 241 80 21423 EMail: hannemann@nets.rwth-aachen.de
電話：+49 241 80 21423 Eメール：hannemann@nets.rwth-aachen.de