[要約] 要約：RFC 6069は、TCP接続の長期的な中断に対してTCPをより堅牢にするための提案です。 目的：TCP-LCDは、ネットワークの不安定性や長期的な中断によるTCP接続の問題を解決し、信頼性とパフォーマンスを向上させることを目指しています。
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を長い接続の破壊（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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）を回復します。接続タイマーが再開される前に少なくとも1回発火する場合、接続の破壊は、特定のTCP接続の「長い」と宣言されます。往復時間（RTT）や利用可能な帯域幅などのパス特性が、破壊後に接続が再開されると、TCPの再送信スキーム[TCP-RLCI]のもう1つの重要な側面が変化するかどうかが変わりました。
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を2倍にします。ただし、RTOの成長は、上限、最大RTOである最大6秒であるが、たとえば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 Senderのみの変更を指定して、長い接続の破壊（TCP-LCD）に堅牢性を提供します。メモは、標準のインターネット制御メッセージプロトコル（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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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).
読者は、[RFC2988]のアルゴリズムと用語に精通している必要があります。これは、伝送制御プロトコル（TCP）送信者が再送信タイマーの計算と管理に使用する必要があるという標準アルゴリズムを定義します。このドキュメントでは、[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を使用して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.
注：このメモの焦点は、TCPのパフォーマンスを改善するためにICMPメッセージを悪用する方法の方法を導入することです。ネットワークレイヤーの下の異なる物理的およびリンク層メカニズムが、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]ルーターは、コード0またはコード1（ホスト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]の場合、ICMP宛先コード0（ネット到達不能）およびコード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（ソースルートに失敗した）、コード11（TOSのネットなし（サービスの種類））、またはコード12を使用したICMP宛先の到達不可能なメッセージ（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.
簡単にするために、ICMPV4またはICMPV6で明示的に資格を与えない限り、「ICMPの到達不可能なメッセージ」という用語をICMP宛先コード0またはコード1およびICMPV6宛先の到達不可能なメッセージの同義語として使用します。受信した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メッセージの次の2つの特性により、接続の破壊兆候としての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の到達不可能なメッセージは、ICMP44の到達不可能なメッセージを引き出すデータグラムのIPv4ヘッダー全体[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バイト）を超えることなく、ICMPV6エラーメッセージを誘発するIPv6データグラムからできるだけ多くのバイトを含める必要があります[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の到達不可能なメッセージと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到達不可能なメッセージを悪用します。これにより、TCPの再送信頻度が増加し、1つの再送信タイマーのバックオフを元に戻すことにより、おそらく失われた再送信のシーケンス数を持つセグメントを含むICMPの届かないメッセージが受信されるたびに増加します。
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の到着時に停止する必要があります。アルゴリズムは、同じセグメントの後続のタイムアウト時に再開始してはなりません。スキームは、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」変数をInfinityに設定する必要があります。
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.
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.4）から（5.6）がここにあります。ステップ（2）に進みます。
(2) To account for the expiration of the retransmission timer in the previous step (R), increment the "BACKOFF_CNT" variable by one:
(2) 前のステップ（R）の再送信タイマーの有効期限を説明するには、「backoff_cnt」変数を1つずつ増やします。
BACKOFF_CNT := BACKOFF_CNT + 1.
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
a) 再送信タイマーの有効期限のため。再送信タイマーが期限切れになったら、ステップ（r）に進みます。また
b) for the arrival of an acceptable ACK. When an acceptable ACK arrives, proceed to step (A); or
b) 許容可能なACKの到着のため。許容可能なACKが到着したら、ステップ（a）に進みます。また
c) for the arrival of an ICMP unreachable message. When the ICMP unreachable message "ICMP_DU" arrives, proceed to step (4).
c) ICMPの到達不可能なメッセージの到着。ICMPの到達不可能なメッセージ「ICMP_DU」が到着したら、ステップ（4）に進みます。
(4) If "BACKOFF_CNT > 0", i.e., if at least one retransmission timer backoff can be undone, then
(4) 「backoff_cnt> 0」、つまり、少なくとも1つの再送信タイマーのバックオフを元に戻すことができる場合は、
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：= Extract（ICMP_DU）。
(6) If "SEG.SEQ == SND.UNA", i.e., if the TCP segment "SEG" eliciting the ICMP unreachable message "ICMP_DU" contains the sequence number of a retransmission, then
(6) 「seg.seq == snd.una」、すなわち、icmpの到達不可能なメッセージを誘発するTCPセグメント「seg "がeverainableメッセージを誘発する場合、再送信のシーケンス番号が含まれている場合、その後、再送信のシーケンス番号が含まれています。
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).
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.
（a）これは、許容可能なACKが到着した場合の標準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送信者は「backoff_cnt」変数を1（ステップ（2））で増分します。
In case the retransmission timer expires again (step (3a)), a TCP will repeat the retransmission of the first unacknowledged segment and back off the retransmission timer once more (step (R)) [RFC2988], as well as increment the "BACKOFF_CNT" variable by one (step (2)). Note that a TCP may implement RFC 2988's [RFC2988] option to place a maximum value on the RTO that may result in not performing the retransmission timer backoff. However, step (2) MUST always and unconditionally be applied, no matter whether or not the retransmission timer is actually backed off. In other words, each time the retransmission timer expires, the "BACKOFF_CNT" variable MUST be incremented by one.
If the first received packet after the retransmission(s) is an acceptable ACK (step (3b)), a TCP will proceed as normal, i.e., slow-start the connection and terminate the algorithm (step (A)). Later ICMP unreachable messages from the just terminated timeout-based loss recovery are ignored, since the ACK clock is already restarting due to the successful retransmission.
再送信後に最初に受信したパケットが許容可能なACK（ステップ（3B））である場合、TCPは通常どおり続行されます。つまり、接続をスロースタートしてアルゴリズムを終了します（ステップ（a））。ACKクロックは再送信が成功したためにすでに再起動しているため、後に終了したタイムアウトベースの損失回復からの到達不可能なメッセージは無視されます。
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].
一方、再送信後に最初に受信したパケットがICMPの到達不可能なメッセージ（ステップ（3C））である場合、ステップ（4）が許可する場合、TCPはエラーを報告する各ICMPの到達可能なメッセージの1つのバックオフを元に戻す必要があります再送信時。ICMPの到達不可能なメッセージが再送信によって引き出されたかどうかを判断するために、含まれるシーケンス番号が検査されます（ステップ（5）、ステップ（6））。UNDOは、減少した「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送信者の再送信タイマーが最後に受け入れられたACKを受け取ってから期限切れにならなかった場合、TCPの動作は変更されません。したがって、定義上、アルゴリズムは、長い接続の破壊の場合にのみトリガーされます。
Only such ICMP unreachable messages that contain a TCP segment with the sequence number of a retransmission, i.e., that contain SND.UNA, are evaluated by TCP-LCD. All other ICMP unreachable messages are ignored. The arrival of those ICMP unreachable messages provides strong evidence that the retransmissions were not dropped due to congestion, but were successfully delivered to the reporting router. In other words, there is no evidence for any congestion at least on that very part of the path that was traversed by both the TCP segment eliciting the ICMP unreachable message and the ICMP unreachable message itself.
再送信のシーケンス番号を持つTCPセグメントを含むそのようなICMP到達不可能なメッセージのみ、つまりSND.UNAを含む、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の到達不可能なメッセージに再送信のセグメント番号（SND.UNA）が含まれている場合でも、これは発生する可能性があります。なぜなら、ICMPの到達不可能なメッセージを引き出すTCPセグメントは、再送信（セクション5.1）ではないか、または現在のタイムアウトベースの損失回復（セクション5.2）。最後に、パケットの複製（セクション5.3）は、アルゴリズムをスパイアルにトリガーすることもできます。
Section 5.4 discusses possible probing frequencies, while Section 5.6 describes the motivation for not reacting to ICMP unreachable messages while TCP is in steady-state.
セクション5.4では、可能な調査周波数について説明し、セクション5.6では、TCPが定常状態にある間にICMPの到達不可能なメッセージに反応しないという動機について説明します。
Historically, the retransmission ambiguity problem [Zh86], [KP87] is the TCP sender's inability to distinguish whether the first acceptable ACK after a retransmission refers to the original transmission or to the retransmission. This problem occurs after both a Fast Retransmit and a timeout-based retransmit. However, modern TCP implementations can eliminate the retransmission ambiguity with either the help of Eifel [RFC3522], [RFC4015] or Forward RTO-Recovery (F-RTO) [RFC5682].
歴史的に、再送信のあいまいさの問題[Zh86]、[KP87]は、TCP送信者が、再送信後の最初の許容可能なACKが元の送信または再送信を指すかどうかを区別できないことです。この問題は、高速再送信とタイムアウトベースの再送信の両方の後に発生します。ただし、最新のTCP実装は、EIFEL [RFC3522]、[RFC4015]またはForward RTO-Recovery（F-RTO）[RFC5682]の助けを借りて、再送信の曖昧さを排除できます。
The reversion strategy of the given algorithm suffers from a form of retransmission ambiguity, too. In contrast to the above case, TCP suffers from ambiguity regarding ICMP unreachable messages received during timeout-based loss recovery. With the TCP segment number included in the ICMP unreachable message, a TCP sender is not able to determine if the ICMP unreachable message refers to the original transmission or to any of the timeout-based retransmissions. That is, there is an ambiguity with regard to which TCP segment an ICMP unreachable message reports on.
与えられたアルゴリズムの復帰戦略は、再送信の曖昧さの形態にも及びます。上記のケースとは対照的に、TCPは、タイムアウトベースの損失回復中に受け取ったICMPの到達不可能なメッセージに関する曖昧さに苦しんでいます。ICMPの到達不可能なメッセージにTCPセグメント番号が含まれている場合、TCP送信者は、ICMPの到達不可能なメッセージが元の送信またはタイムアウトベースの再送信を指すかどうかを判断できません。つまり、ICMPの到達不可能なメッセージが報告するTCPセグメントに関するあいまいさがあります。
However, this ambiguity is not considered to be a problem for the algorithm. The assumption that a received ICMP unreachable message provides evidence that a non-congestion loss caused by the connectivity disruption was wrongly considered a congestion loss still holds, regardless of to which TCP segment (transmission or retransmission) the message refers.
ただし、このあいまいさはアルゴリズムの問題とは見なされません。受信したICMPの到達不可能なメッセージが、接続性の破壊によって引き起こされる非結合損失が、メッセージが参照するTCPセグメント（伝送または再送信）に関係なく、誤って渋滞の損失がまだ保持されていると誤って考慮されたという証拠を提供します。
Besides the ambiguity whether a received ICMP unreachable message refers to the original transmission or to any of the retransmissions, there is another source of ambiguity related to the TCP sequence numbers contained in ICMP unreachable messages. For high-bandwidth paths, the sequence space may wrap quickly. This might cause delayed ICMP unreachable messages to coincidentally fit as valid input in the proposed scheme. As a result, the scheme may incorrectly undo retransmission timer backoffs. The chances of this happening are minuscule, since a particular ICMP unreachable message would need to contain the exact sequence number of the current oldest outstanding segment (SND.UNA), while at the same time TCP is in timeout-based loss recovery. However, two "worst case" scenarios for the algorithm are possible.
受信したICMPの到達不可能なメッセージが元の送信または再送信のいずれかを指すかどうかのあいまいさに加えて、ICMPの到達不可能なメッセージに含まれるTCPシーケンス番号に関連する曖昧さの別のソースがあります。高帯域幅のパスの場合、シーケンス空間が迅速にラップする場合があります。これにより、ICMPの到達不可能なメッセージが遅延して、提案されたスキームで有効な入力として偶然に適合する可能性があります。その結果、スキームは再送信タイマーのバックオフを誤って元に戻す可能性があります。特定のICMPの到達不可能なメッセージは、現在の最も古い発行セグメント（SND.UNA）の正確なシーケンス番号を含める必要があり、同時にTCPがタイムアウトベースの損失回復にあるため、この出来事の可能性は非常に大きいです。ただし、アルゴリズムの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）を再送信し始めます。何らかの理由で、ルーターは対応するすべてのICMPの到達不可能なメッセージを遅らせるため、TCP送信者は通常、元に戻すことなく再送信タイマーを後退させます。接続の破壊の終わりに、TCP送信者は最終的に再確立を検出し、スキームを離れ、最後にタイムアウトベースの損失回復も残します。シーケンス番号ラップアラウンドの後、2人のピア間の接続性は再び破壊されますが、今回は混雑のために、現在のSND.UNAが前のサイクルのSND.UNAと一致する時点で正確に停止します。ルーターが遅延したICMPの到達不可能なメッセージを今すぐ放出した場合、TCP送信者は再送信タイマーのバックオフを誤って元に戻すでしょう。TCPシーケンス番号には32ビットが含まれているため、このシナリオの確率は最大1/2^32です。最初のタイムアウトベースの損失回復で十分に多くの再送信を考えると、対応するICMPの到達不可能なメッセージは、せいぜい2回目の回復でRTOを「RTO_BASE」に減らすことができます。ただし、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.
上記と同様に、中間ルーターでのリンク停止により、ある時点で定常状態のTCP接続がある時点で破壊される場合を検討してください。飛行中の各セグメントについて、ルーターはICMPの到達不可能なメッセージを生成する場合があります。しかし、何らかの理由で、それはそれらを遅らせます。リンクの停止が終了し、接続が再確立されると、TCP送信者はスキームを離れ、接続を遅くします。シーケンス番号ラップアラウンドに続いて、再送信タイムアウトが発生します。これは、TCP送信者の現在のデータウィンドウがシーケンス番号スペースの以前の範囲に到達する現時に発生します。ルーターが遅延のあるICMPの到達不可能なメッセージを発した場合、ICMPの到達不可能なメッセージに含まれるTCPセグメント番号が現在のSND.UNAと一致し、タイムアウトが輻輳の結果である場合、再送信タイマーバックオフの偽りの元に戻すことが1回可能です。別の接続性の破壊の場合、再送信タイマーのバックオフの追加を取り消すことは影響しません。このシナリオの確率は、せいぜい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送信者は、Timeoutベースのリカバリ中に、Timeoutベースの再送信を送信するよりも多くの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の到達不可能なメッセージが届く場合、タイムアウトベースの損失回復中にACKが到着したときに行われるものと同様に、RTOはリセットまたは再計算されるものとするかもしれません（Karn's Algorithm [KP87]、[RFC2988を参照してください]）、そして新しい再送信をすぐに送信する必要があります。一般に、これにより、接続性が破壊されたルーターへの往復時間に基づいて、はるかに高いプローブ周波数が得られます。しかし、現在のスキームは、保守的な行動と接続性の再確立の迅速な検出との間の良好なトレードオフを提供すると考えています。TCP-LCDは、長い接続性の混乱、つまりいくつかのRTOで続く混乱に焦点を当てています。したがって、プローブ周波数がはるかに高い（RTOごとに1回未満）、接続性の破壊の期間と比較して、利用可能な伝送時間を大幅に増加させません。
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.
TCP送信者は、接続がSyn-SentまたはSyn-Received状態である間にタイムアウトベースの損失回復に入る可能性があります[RFC0793]。このドキュメントで説明されているアルゴリズムは、接続の破壊を伴うネットワークでの接続確立をより高速にするためにも使用できます。ただし、既存のTCP実装[RFC5461]は、接続の確立中にICMPの到達不可能なメッセージをすでに解釈し、対応する接続を中止するため、これを提案することは控えます。
Another exploitation of ICMP unreachable messages in the context of TCP congestion control might seem appropriate, while TCP is in steady-state. As the RTT up to the router that generated the ICMP unreachable message is likely to be substantially shorter than the overall RTT to the destination, the ICMP unreachable message may very well reach the originating TCP while it is transmitting the current window of data. In case the remaining window is large, it might seem appropriate to refrain from transmitting the remaining window as there is timely evidence that it will only trigger further ICMP unreachable messages at that very router. Although this promises improvement from a wastage perspective, it may be counterproductive from a security perspective. An attacker could forge such ICMP 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の到達不可能なメッセージをトリガーするというタイムリーな証拠があるためです。これは浪費の観点からの改善を約束しますが、セキュリティの観点からは逆効果である可能性があります。攻撃者はそのようなICMPメッセージを偽造することができ、それにより、[RFC5927]で言及されているブラインドスループット削減攻撃に非常によく似たデータの送信を停止するように発信するTCPが強制されます。
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:
（1 '）TCPがタイムアウトベースの損失回復を開始するときに変数「RTO」を更新する前に、変数「backoff_cnt」と「rto_base」を設定し、次のようにデータ構造「retans_ts」を設定します。
BACKOFF_CNT := 0;
RTO_BASE := RTO;
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）TCPタイムスタンプのタイムスタンプ値フィールド（TSVAL）の値を保存します。再送信に含まれる「RET」に含まれる「RET」（R）に送信された「RECRANS_TS」データ構造に送信されます。
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）」」の場合、つまり、icmpの到達不可能なメッセージを誘発するtcpセグメント「seg」の場合、再送信のシーケンス番号が含まれています。そして、そのタイムスタンプ値フィールド（TSVAL）の値は有効です。
proceed to step (7');
ステップ（7 '）に進みます。
else
そうしないと
proceed to step (3).
ステップ（3）に進みます。
Step (7) is replaced by step (7'):
ステップ（7）はステップ（7 '）に置き換えられます。
(7') Undo the last retransmission timer backoff:
（7 '）最後の再送信タイマーバックオフを元に戻す：
RETRANS_TS.remove(SEQ.TSval); BACKOFF_CNT := BACKOFF_CNT - 1; RTO := min(RTO_BASE * 2^(BACKOFF_CNT), MAX_RTO).
RETRANS_TS.REMOVE（seq.tsval）;backoff_cnt：= backoff_cnt -1;rto：= min（rto_base * 2^（backoff_cnt）、max_rto）。
The downside of this variant is twofold. First, the modifications come at a cost: the TCP sender is required to store the timestamps of all retransmissions sent during one timeout-based loss recovery. Second, this variant can only undo a retransmission timer backoff if the intermediate router experiencing the link outage implements [RFC1812] and chooses to include, in addition to the first 64 bits of the payload of the triggering datagram, as many bits as are needed to include the TCP Timestamps option in the ICMP unreachable message.
このバリアントの欠点は2つあります。まず、変更にはコストがかかります。TCP送信者は、1回のタイムアウトベースの損失回復中に送信されたすべての再送信のタイムスタンプを保存するために必要です。第二に、このバリアントは、リンクの停止を経験している中間ルーターが[RFC1812]を実装している場合にのみ再送信タイマーのバックオフを元に戻すことができ、トリガーデータグラムのペイロードの最初の64ビットに加えて、必要な数のビットを含むことを選択することを選択します。ICMPの到達不可能なメッセージにTCPタイムスタンプオプションを含めます。
This section discusses interoperability issues related to introducing TCP-LCD.
このセクションでは、TCP-LCDの導入に関連する相互運用性の問題について説明します。
TCP-LCD may produce side effects for TCP implementations that attempt to detect TCP connection failures by counting timeout-based retransmissions. [RFC1122] states in Section 4.2.3.5 that a TCP host must handle excessive retransmissions of data segments with two thresholds, R1 and R2, that measure the number of retransmissions that have occurred for the same segment. Both thresholds might be measured either in time units or as a count of retransmissions.
TCP-LCDは、タイムアウトベースの再送信をカウントすることによりTCP接続障害を検出しようとするTCP実装の副作用を生成する場合があります。[RFC1122]セクション4.2.3.5の述べています。TCPホストは、同じセグメントで発生した再送信の数を測定する2つのしきい値、R1とR2のデータセグメントの過度の再送信を処理する必要があると述べています。両方のしきい値は、時間単位または再送信のカウントとして測定される場合があります。
Due to TCP-LCD's reversion strategy of the retransmission timer, the assumption that a certain number of retransmissions corresponds to a specific time interval no longer holds, as additional retransmissions may be performed during timeout-based-loss recovery to detect the end of the connectivity disruption. Therefore, a TCP employing TCP-LCD either MUST measure the thresholds R1 and R2 in time units or, in case R1 and R2 are counters of retransmissions, MUST convert them into time intervals that correspond to the time an unmodified TCP would need to reach the specified number of retransmissions.
TCP-LCDの再送信タイマーの逆転戦略により、特定の数の再送信が特定の時間間隔に対応するという仮定は、もはや保持されなくなります。混乱。したがって、TCP-LCDを使用するTCPは、時間単位でしきい値R1とR2を測定する必要があります。または、R1とR2が再送信のカウンターである場合、変更されていないTCPが時間間隔に変換する必要があります。指定された数の再送信数。
With Explicit Congestion Notification (ECN) [RFC3168], ECN-capable routers are no longer limited to dropping packets to indicate congestion. Instead, they can set the Congestion Experienced (CE) codepoint in the IP header to indicate congestion. With TCP-LCD, it may happen that during a connectivity disruption, a received ICMP unreachable message has been elicited by a timeout-based retransmission that was marked with the CE codepoint before reaching the router experiencing the link outage. In such a case, a TCP sender MUST, corresponding to Section 6.1.2 of [RFC3168], additionally reset the retransmission timer in case the algorithm undoes a retransmission timer backoff.
明示的な輻輳通知（ECN）[RFC3168]では、ECN対応ルーターは、混雑を示すためにパケットを落とすことに限定されなくなりました。代わりに、IPヘッダーに経験豊富な（CE）コードポイントを設定して、混雑を示すことができます。TCP-LCDを使用すると、接続性の破壊中に、リンクの停止が発生するルーターに到達する前にCEコードポイントでマークされたタイムアウトベースの再送信によって受信されたICMPの到達不可能なメッセージが引き出されたことがあります。そのような場合、[RFC3168]のセクション6.1.2に対応するTCP送信者は、アルゴリズムが再送信タイマーのバックオフを元に戻す場合に再送信タイマーをさらにリセットする必要があります。
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]内のIPカプセル化、一般的なルーティングカプセル化（GRE）[RFC2784]などのIPトンネルは、受信したICMPのないメッセージを受け入れないメッセージを含む限り、TCP-LCDと互換性があることに注意してください。タイムアウトベースの損失回復中に、TCP送信者によって非gultiplexedおよび適切に抽出することができます。
If, for example, end-to-end tunnels like IPsec in transport mode [RFC4301] are employed, a TCP sender may receive ICMP unreachable messages where additional steps, e.g., also performing decryption in step (5) of the algorithm, are needed to extract the TCP header from these ICMP messages. Provided that the received ICMP unreachable message contains enough information, i.e., SEG.SEQ is extractable, this information can still be used as a valid input for the proposed algorithm.
たとえば、トランスポートモード[RFC4301]のIPSECのようなエンドツーエンドのトンネルが採用されている場合、TCP送信者は、アルゴリズムのステップ（5）で追加のステップ（5）で復号化を実行する必要があるICMPの到達不可能なメッセージを受信する場合があります。これらのICMPメッセージからTCPヘッダーを抽出します。受信したICMPの到達不可能なメッセージに十分な情報が含まれている場合、つまり、SEG.SEQが抽出可能である場合、この情報は提案されたアルゴリズムの有効な入力として使用できます。
Likewise, if IP encapsulation like [RFC2003] is used in some part of the path between the communicating hosts, the tunnel ingress node may receive the ICMP unreachable messages from an intermediate router experiencing the link outage. Nevertheless, the tunnel ingress node may replay the ICMP unreachable messages in order to inform the TCP sender. If enough information is preserved to extract SEG.SEQ, the replayed ICMP unreachable messages can still be used in TCP-LCD.
同様に、[RFC2003]のようなIPカプセル化が通信ホスト間のパスの一部で使用されている場合、トンネルイングレスノードは、リンクの停止を経験する中間ルーターからICMPの到達不可能なメッセージを受信する場合があります。それにもかかわらず、TCP送信者に通知するために、Tunnel Ingressノードは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]で提案されているステートレスリンク層スキームは、少数のパケットを無条件にバッファリングする可能性がありますが、パケットが最大セグメント寿命（MSL）よりも長く2分より長くバッファリングされている場合。[RFC0793]、つまり、切断はMSLよりも長く続く、そのようなセグメントが決して受信されないというTCPの仮定はもはや真実ではなく、TCPのセマンティクスに違反します[TCP-Rexmit-Now]。
Other approaches, like the TCP feedback-based scheme (TCP-F) [CRVP01] or the Explicit Link Failure Notification (ELFN) [HV02] inform a TCP sender about a disrupted path by special messages generated and sent from intermediate routers. In the case of a link failure, the TCP sender stops sending segments and freezes its retransmission timers. TCP-F stays in this state and remains silent until either a "route establishment notification" is received or an internal timer expires. In contrast, ELFN periodically probes the network to detect connectivity re-establishment. Both proposals rely on changes to intermediate routers, whereas the scheme proposed in this document is 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.
「Ad Hoc TCP」（ATCP）[LS01]の著者は、TCPとIPの間に層を導入することにより、さまざまなタイプのパケット損失を特定するための機能強化を提案します。ICMP宛先の到達不可能なメッセージを利用して、TCPのレシーバー広告ウィンドウをゼロに設定するため、TCP送信者は指数関数的バックオフでゼロウィンドウプローブを実行するように強制します。この調査期間中に到着するICMP宛先到達不可能なメッセージは無視されます。このアプローチは、このドキュメントに対してほぼ直交します。これにより、ICMPメッセージを悪用して、TCPがすでに調査中の再送信タイマーバックオフを元に戻します。原則として、両方のメカニズムを組み合わせることができます。ただし、セキュリティの考慮事項により、セクション5.6で説明したように、ATCPの反応を採用することは適切ではないと思われます。
Schuetz et al. [TCP-RLCI] describe a set of TCP extensions that improve TCP's behavior when transmitting over paths whose characteristics can change rapidly. Their proposed extensions modify the local behavior of TCP and introduce a new TCP option to signal locally received connectivity-change indications (CCIs) to remote peers. Upon receipt of a CCI, they re-probe the path characteristics either by performing a speculative retransmission or by sending a single segment of new data, depending on whether the connection is currently stalled in exponential backoff or transmitting in steady-state, respectively. The authors focus on specifying TCP response mechanisms; nevertheless, underlying layers would have to be modified to explicitly send CCIs to make these immediate responses possible.
Schuetz et al。[TCP-RLCI]特性が迅速に変化する可能性のあるパス上でTCPの動作を改善するTCP拡張のセットを説明します。提案された拡張機能は、TCPのローカルな動作を変更し、新しいTCPオプションを導入して、ローカルに受信した接続変化の表示（CCIS）をリモートピアに信号します。CCIを受け取ると、投機的再送信を実行するか、接続が現在指数関数的バックオフで停止しているか、定常状態で送信されているかどうかに応じて、新しいデータの単一セグメントを送信することにより、パス特性を再プローブします。著者は、TCP応答メカニズムの指定に焦点を当てています。それにもかかわらず、これらの即時応答を可能にするためにCCISを明示的に送信するために、基礎となる層を変更する必要があります。
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の到達不可能なメッセージを抑制して、TCP-LCDでTCPを変更しようとするために、到達不可能なメッセージを生成することです。
In order to generate ICMP unreachable messages that fit as an input for TCP-LCD, an attacker would need to guess the correct four-tuple (i.e., Source IP Address, Source TCP port, Destination IP Address, and Destination TCP port) and the exact segment sequence number of the current timeout-based retransmission. Yet, the correct sequence number is generally hard to guess, given the probability of 1/2^32. Even if an attacker has information about that sequence number (i.e., the attacker can eavesdrop on the retransmissions) the impact on the network load from the attacker may be considered low, since the retransmission frequency is limited by the RTO that was computed before TCP had entered the timeout-based loss recovery. Hence, the 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によって再送信頻度が制限されるため、攻撃者からのネットワーク負荷への影響は低いと見なされる場合があります。タイムアウトベースの損失回復を入力しました。したがって、最も高いプロービング周波数は、最小RTOごとに1回、つまり[RFC2988]で指定されている1秒よりもさらに低いと予想されます。TCP-LCDが使用されるかどうかにかかわらず、4タプルとセグメントシーケンス番号を正しく推測できる攻撃者が、より深刻な攻撃を簡単に開始できる（つまり、接続をハイジャックする）ことができることに注意することが重要です。
There may be means by which an attacker can cause the suppression of legitimate ICMP unreachable messages (e.g., by flooding the router experiencing the link outage to trigger ICMP rate-limiting). However, even if the attacker could suppress every legitimate ICMP unreachable message, the security impact of such an attack is negligible, since the TCP sender using TCP-LCD will behave like a regular TCP would. Note that this kind of attack is indistinguishable from a router experiencing a link outage that is not sending ICMP unreachable messages at all (e.g., because of local policy).
攻撃者が合法的なICMPの到達不可能なメッセージの抑制を引き起こす可能性のある手段がある場合があります（たとえば、ICMPレート制限をトリガーするためにリンクの停止を経験するルーターにあふれることにより）。ただし、攻撃者がすべての正当なICMPの到達不可能なメッセージを抑制できたとしても、TCP-LCDを使用したTCP送信者は通常のTCPのように振る舞うため、このような攻撃のセキュリティへの影響は無視できます。この種の攻撃は、ICMPが到達できないメッセージをまったく送信していないリンクの停止を経験しているルーターと区別できないことに注意してください（たとえば、ローカルポリシーのため）。
In summary, the algorithm proposed in this document is considered to be secure.
要約すると、このドキュメントで提案されているアルゴリズムは安全であると見なされます。
We would like to thank Lars Eggert, Adrian Farrel, Mark Handley, Kai Jakobs, Ilpo Jarvinen, Enrico Marocco, Catherine Meadows, Juergen Quittek, Pasi Sarolahti, Tim Shepard, Joe Touch, and Carsten Wolff for feedback on earlier versions of this document. We also thank Michael Faber, Daniel Schaffrath, and Damian Lukowski for implementing and testing the algorithm in Linux. Special thanks go to Ilpo Jarvinen for giving valuable feedback regarding the Linux implementation.
ラース・エガート、エイドリアン・ファレル、マーク・ハンドリー、カイ・ジェイコブス、イルポ・ジャーヴィネン、エンリコ・マロッコ、キャサリン・メドウズ、ジュエルゲン・キッテク、ティム・シェパード、ジョー・タッチ、そしてこの文書のフィードバックについてのフィードバックについて感謝します。また、Linuxのアルゴリズムを実装およびテストしてくれたMichael Faber、Daniel Schaffrath、およびDamian 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.
この作業は、Rwth Aachen UniversityのResearch Excellence Cluster Ultra High Speed Mobile Information Communication（UMIC）の中で、ドイツ国立科学財団（DFG）によってサポートされています。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、B。、およびD. Borman、「TCP拡張のためのTCP拡張」、RFC 1323、1992年5月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812] Baker、F。、「IPバージョン4ルーターの要件」、RFC 1812、1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、RFC 4443、2006年3月。
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009.
[RFC5681] Allman、M.、Paxson、V。、およびE. Blanton、「TCP混雑制御」、RFC 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] Chandran、K.、Raghunathan、S.、Venkatesan、S.、およびR. Prakash、「アドホックワイヤレスネットワークのTCPパフォーマンスを改善するためのフィードバックベースのスキーム」、IEEE Personal Communications Vol。8、いいえ。1、pp。34-39、2001年2月。
[HV02] Holland, G. and N. Vaidya, "Analysis of TCP performance over mobile ad hoc networks", Wireless Networks vol. 8, no. 2-3, pp. 275-288, March 2002.
[HV02] Holland、G。およびN. Vaidya、「モバイルアドホックネットワーク上のTCPパフォーマンスの分析」、Wireless Networks Vol。8、いいえ。2-3、pp。275-288、2002年3月。
[KP87] Karn, P. and C. Partridge, "Improving Round-Trip Time Estimates in Reliable Transport Protocols", Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM'87) pp. 2-7, August 1987.
[KP87] Karn、P。およびC. Partridge、「信頼できる輸送プロトコルにおける往復時間推定の改善」、コンピューター通信のためのアプリケーション、技術、アーキテクチャ、およびプロトコルに関する会議の議事録（SigComm'87）pp。2-7、1987年8月。
[LS01] Liu, J. and S. Singh, "ATCP: TCP for mobile ad hoc networks", IEEE Journal on Selected Areas in Communications vol. 19, no. 7, pp. 1300-1315, July 2001.
[LS01] Liu、J。およびS. Singh、「ATCP：モバイルアドホックネットワークのTCP」、IEEE Journal on Communications Vol。19、いいえ。7、pp。1300-1315、2001年7月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、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] Plummer、D。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「Internet Protocol、Version 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] Farinacci、D.、Li、T.、Hanks、S.、Meyer、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.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[RFC3522] Ludwig、R。およびM. Meyer、「TCPのEIFEL検出アルゴリズム」、RFC 3522、2003年4月。
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[RFC3782] Floyd、S.、Henderson、T。、およびA. Gurtov、「TCPの高速回復アルゴリズムへのNewreno修正」、RFC 3782、2004年4月。
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. Wood, "Advice for Internet Subnetwork Designers", BCP 89, RFC 3819, July 2004.
[RFC3819] Karn、P.、Bormann、C.、Fairhurst、G.、Grossman、D.、Ludwig、R.、Mahdavi、J.、Montenegro、G.、Touch、J.、およびL. Wood、「アドバイス」アドバイスインターネットサブネットワークデザイナー向け」、BCP 89、RFC 3819、2004年7月。
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[RFC4015] Ludwig、R。およびA. Gurtov、「TCPのEIFEL応答アルゴリズム」、RFC 4015、2005年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.
[RFC5461] Gont、F。、「ソフトエラーに対する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.、Kojo、M.、Yamamoto、K。、およびM. Hata、「Forward RTO-Recovery（F-RTO）：TCPで偽りの再送信タイムアウトを検出するためのアルゴリズム」、RFC 5682、2009年9月。
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010.
[RFC5927] Gont、F。、「TCPに対するICMP攻撃」、RFC 5927、2010年7月。
[SESB05] Schuetz, S., Eggert, L., Schmid, S., and M. Brunner, "Protocol enhancements for intermittently connected hosts", SIGCOMM Computer Communication Review vol. 35, no. 3, pp. 5-18, December 2005.
[SESB05] Schuetz、S.、Eggert、L.、Schmid、S。、およびM. Brunner、「断続的に接続されたホストのプロトコル強化」、Sigcomm Computer Communication Review Vol。35、いいえ。3、pp。5-18、2005年12月。
[SM03] Scott, J. and G. Mapp, "Link layer-based TCP optimisation for disconnecting networks", SIGCOMM Computer Communication Review vol. 33, no. 5, pp. 31-42, October 2003.
[SM03] Scott、J。およびG. Mapp、「ネットワークを切断するためのリンクレイヤーベースのTCP最適化」、Sigcomm Computer Communication Review Vol。33、いいえ。5、pp。31-42、2003年10月。
[TCP-REXMIT-NOW] Eggert, L., Schuetz, S., and S. Schmid, "TCP Extensions for Immediate Retransmissions", Work in Progress, June 2005.
[TCP-Rexmit-Now] Eggert、L.、Schuetz、S。、およびS. Schmid、「即時再送信のためのTCP拡張」、2005年6月、進行中の作業。
[TCP-RLCI] Schuetz, S., Koutsianas, N., Eggert, L., Eddy, W., Swami, Y., and K. Le, "TCP Response to Lower-Layer Connectivity-Change Indications", Work in Progress, February 2008.
[TCP-RLCI] Schuetz、S.、Koutsianas、N.、Eggert、L.、Eddy、W.、Swami、Y.、およびK. Le、「低層接続の選択指標に対するTCP応答」、進捗、2008年2月。
[Zh86] Zhang, L., "Why TCP Timers Don't Work Well", Proceedings of the Conference on Applications, Technologies, Architectures, and Protocols for Computer Communication (SIGCOMM'86) pp. 397-405, August 1986.
[Zh86] Zhang、L。、「なぜTCPタイマーがうまくいかないのか」、コンピューター通信のためのアプリケーション、技術、アーキテクチャ、およびプロトコルに関する会議の議事録（Sigcomm'86）pp。397-405、1986年8月。
[ZimHan09] Zimmermann, A., "Make TCP more Robust to Long Connectivity Disruptions", Proceedings of the 75th IETF Meeting slides, July 2009, <http://www.ietf.org/proceedings/75/slides/tcpm-0.pdf>.
[Zimhan09] Zimmermann、A。、「TCPを長い接続の破壊に対してより堅牢にする」、75th IETF Meeting Slidesの議事録、2009年7月、<http://www.ietf.org/proceedings/75/slides/tcpm-0.pdf>。
Authors' Addresses
著者のアドレス
Alexander Zimmermann RWTH Aachen University Ahornstrasse 55 Aachen, 52074 Germany
アレクサンダー・ジマーマンrwthアーチェン大学アホーンストラッセ55アーヘン、52074ドイツ
Phone: +49 241 80 21422
EMail: zimmermann@cs.rwth-aachen.de
Arnd Hannemann RWTH Aachen University Ahornstrasse 55 Aachen, 52074 Germany
Arnd Hannemann rwth Aachen University Ahornstrasse 55 Aachen、52074ドイツ
Phone: +49 241 80 21423
EMail: hannemann@nets.rwth-aachen.de