Network Working Group P. Sarolahti
Request for Comments: 4138 Nokia Research Center
Category: Experimental M. Kojo
University of Helsinki
August 2005
Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP and the
Stream Control Transmission Protocol (SCTP)
Status of This Memo
このメモのステータス
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
Spurious retransmission timeouts cause suboptimal TCP performance because they often result in unnecessary retransmission of the last window of data. This document describes the F-RTO detection algorithm for detecting spurious TCP retransmission timeouts. F-RTO is a TCP sender-only algorithm that does not require any TCP options to operate. After retransmitting the first unacknowledged segment triggered by a timeout, the F-RTO algorithm of the TCP sender monitors the incoming acknowledgments to determine whether the timeout was spurious. It then decides whether to send new segments or retransmit unacknowledged segments. The algorithm effectively helps to avoid additional unnecessary retransmissions and thereby improves TCP performance in the case of a spurious timeout. The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP).
彼らは多くの場合、データの最後のウィンドウの不要な再送信につながるので、スプリアス再送タイムアウトが次善のTCP性能を引き起こします。この文書では、偽のTCP再送タイムアウトを検出するためのF-RTO検出アルゴリズムを説明します。 F-RTOが動作するために、任意のTCPオプションを必要としないTCP送信側のみのアルゴリズムです。タイムアウトによってトリガー最初不承認のセグメントを再送信した後に、TCP送信側のF-RTOアルゴリズムは、タイムアウトが偽であったかどうかを決定するために受信確認応答を監視します。これは、新しいセグメントを送信したり、未確認のセグメントを再送信するかを決定します。このアルゴリズムは、効果的に追加の不必要な再送信を回避するために役立ち、それによって、スプリアスタイムアウトした場合のTCPのパフォーマンスが向上します。 F-RTOアルゴリズムは、ストリーム制御伝送プロトコル（SCTP）に適用することができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . 4
2. F-RTO Algorithm . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Algorithm . . . . . . . . . . . . . . . . . . . 5
2.2. Discussion . . . . . . . . . . . . . . . . . . . . 6
3. SACK-Enhanced Version of the F-RTO Algorithm . . . . . . 8
4. Taking Actions after Detecting Spurious RTO . . . . . . . 10
5. SCTP Considerations . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References. . . . . . . . . . . . . . . . 12
8.2. Informative References. . . . . . . . . . . . . . . 13
Appendix A: Scenarios . . . . . . . . . . . . . . . . . . . . 15
Appendix B: SACK-Enhanced F-RTO and Fast Recovery . . . . . . 20
Appendix C: Discussion of Window-Limited Cases . . . . . . . 21
The Transmission Control Protocol (TCP) [Pos81] has two methods for triggering retransmissions. First, the TCP sender relies on incoming duplicate ACKs, which indicate that the receiver is missing some of the data. After a required number of successive duplicate ACKs have arrived at the sender, it retransmits the first unacknowledged segment [APS99] and continues with a loss recovery algorithm such as NewReno [FHG04] or SACK-based loss recovery [BAFW03]. Second, the TCP sender maintains a retransmission timer which triggers retransmission of segments, if they have not been acknowledged before the retransmission timeout (RTO) expires. When the retransmission timeout occurs, the TCP sender enters the RTO recovery where the congestion window is initialized to one segment and unacknowledged segments are retransmitted using the slow-start algorithm. The retransmission timer is adjusted dynamically, based on the measured round-trip times [PA00].
伝送制御プロトコル（TCP）[Pos81]は、再送をトリガするための2つの方法を持っています。まず、TCPの送信側は受信側がデータの一部が欠落していることを示し、着信重複ACK、に依存しています。連続した重複ACKの必要数は、送信者に到着した後、それは最初の不承認のセグメント[APS99]を再送し、そのような[BAFW03] NewRenoの[FHG04]またはSACKベースの損失回復として損失回復アルゴリズムを継続します。第二に、TCPの送信側は再送タイムアウト（RTO）が満了する前に、彼らは確認されていない場合は、セグメントの再送をトリガーする再送タイマを維持します。再送タイムアウトが発生した場合、TCPの送信側は、輻輳ウィンドウが1つのセグメントに初期化され、未確認のセグメントはスロースタートアルゴリズムを使用して再送されRTO回復に入ります。再送タイマが測定された往復時間[PA00]に基づいて、動的に調整されます。
It has been pointed out that the retransmission timer can expire spuriously and cause unnecessary retransmissions when no segments have been lost [LK00, GL02, LM03]. After a spurious retransmission timeout, the late acknowledgments of the original segments arrive at the sender, usually triggering unnecessary retransmissions of a whole window of segments during the RTO recovery. Furthermore, after a spurious retransmission timeout, a conventional TCP sender increases the congestion window on each late acknowledgment in slow start. This injects a large number of data segments into the network within one round-trip time, thus violating the packet conservation principle [Jac88].
何のセグメントが[LK00、GL02、LM03]失われていないとき再送タイマーが誤って失効し、不必要な再送信を引き起こす可能性があることを指摘されています。スプリアス再送タイムアウトの後、元のセグメントの後期確認応答は通常、RTO回復時にセグメントのウィンドウ全体の不必要な再送信をトリガ、送信側に到着します。さらに、スプリアス再送タイムアウトの後、従来のTCPの送信側はスロースタートの各後半確認の輻輳ウィンドウが増加します。これにより、パケット保存原理[Jac88]に違反し、1往復時間内にネットワークへのデータ・セグメントの多数を注入します。
There are a number of potential reasons for spurious retransmission timeouts. First, some mobile networking technologies involve sudden delay spikes on transmission because of actions taken during a hand-off. Second, given a low-bandwidth link or some other change in available bandwidth, arrival of competing traffic (possibly with higher priority) can cause a sudden increase of round-trip time. This may trigger a spurious retransmission timeout. A persistently reliable link layer can also cause a sudden delay when a data frame and several retransmissions of it are lost for some reason. This document does not distinguish between the different causes of such a delay spike. Rather, it discusses the spurious retransmission timeouts caused by a delay spike in general.
スプリアス再送タイムアウトの潜在的な理由はたくさんあります。まず、いくつかのモバイルネットワーク技術があるため、ハンドオフ時に取られた行動の伝送に突然の遅延スパイクを伴います。第二に、低帯域幅リンクまたは利用可能な帯域幅で他のいくつかの変化を、（おそらく優先度の高い）競合するトラフィックの到着は、ラウンドトリップ時間の急激な増加を引き起こす可能性が与えられました。これは、スプリアス再送タイムアウトをトリガすることができます。永続的に信頼性の高いリンク層は、データフレームと、それにはいくつかの再送が何らかの理由で失われた突然の遅延を引き起こす可能性があります。この文書では、このような遅延スパイクの異なる原因を区別しません。むしろ、それは一般的には遅延スパイクに起因するスプリアス再送タイムアウトを説明します。
This document describes the F-RTO detection algorithm. It is based on the detection mechanism of the "Forward RTO-Recovery" (F-RTO) algorithm [SKR03] that is used for detecting spurious retransmission timeouts and thus avoids unnecessary retransmissions following the retransmission timeout. When the timeout is not spurious, the F-RTO algorithm reverts back to the conventional RTO recovery algorithm, and therefore has similar behavior and performance. In contrast to alternative algorithms proposed for detecting unnecessary retransmissions (Eifel [LK00], [LM03] and DSACK-based algorithms [BA04]), F-RTO does not require any TCP options for its operation, and it can be implemented by modifying only the TCP sender. The Eifel algorithm uses TCP timestamps [BBJ92] for detecting a spurious timeout upon arrival of the first acknowledgment after the retransmission. The DSACK-based algorithms require that the TCP Selective Acknowledgment Option [MMFR96], with the DSACK extension [FMMP00], is in use. With DSACK, the TCP receiver can report if it has received a duplicate segment, enabling the sender to detect afterwards whether it has retransmitted segments unnecessarily. The F-RTO algorithm only attempts to detect and avoid unnecessary retransmissions after an RTO. Eifel and DSACK can also be used for detecting unnecessary retransmissions caused by other events, such as packet reordering.
この文書では、F-RTO検出アルゴリズムを説明します。これは、スプリアス再送タイムアウトを検出するために使用される「前方RTOリカバリ」（F-RTO）アルゴリズム[SKR03]の検出メカニズムに基づいており、従って再送タイムアウトの後、不要な再送信を回避します。タイムアウトがスプリアスでない場合は、F-RTOアルゴリズムは、従来のRTO回復アルゴリズムに戻りますので、同様の動作とパフォーマンスを持っています。不要な再送（アイフェル[LK00]、[LM03]とDSACKベースのアルゴリズム[BA04]）を検出するために提案された代替アルゴリズムとは対照的に、F-RTOは、その動作のための任意のTCPオプションを必要とせず、それだけ変更することによって実現することができますTCPの送信者。アイフェルアルゴリズムは、再送後の最初の確認応答の到着時にスプリアスタイムアウトを検出するための[BBJ92] TCPタイムスタンプを使用します。 DSACKベースのアルゴリズムは、DSACK延長[FMMP00]とTCP選択的確認応答オプション[MMFR96]は、使用中であることを必要とします。それは重複セグメントを受信した場合DSACKでは、TCP受信機はそれが不必要にセグメントを再送信しているかどうかを後で検出するために、送信者を有効にする、報告することができます。 F-RTOアルゴリズムは、RTOの後に不要な再送を検出し、避けるようにしようとします。アイフェルとDSACKはまた、パケットの並べ替えのような他のイベントによって引き起こされる不必要な再送信を検出するために使用することができます。
When an RTO expires, the F-RTO sender retransmits the first unacknowledged segment as usual [APS99]. Deviating from the normal operation after a timeout, it then tries to transmit new, previously unsent data, for the first acknowledgment that arrives after the timeout, given that the acknowledgment advances the window. If the second acknowledgment that arrives after the timeout advances the window (i.e., acknowledges data that was not retransmitted), the F-RTO sender declares the timeout spurious and exits the RTO recovery. However, if either of these two acknowledgments is a duplicate ACK, there will not be sufficient evidence of a spurious timeout. Therefore, the F-RTO sender retransmits the unacknowledged segments in slow start similarly to the traditional algorithm. With a
RTOが満了すると、F-RTOの送信者は、[APS99]いつものように最初の不承認のセグメントを再送信します。タイムアウト後に正常な動作から逸脱、次に肯定応答ウィンドウを進めることを考えると、タイムアウト後に到着した最初の確認応答を、新しい、以前に未送信のデータを送信しようとします。タイムアウト後に到着した第二確認応答が窓を進める（すなわち、再送されていなかったデータを認める）、F-RTOの送信者は、スプリアスタイムアウトを宣言し、RTO回復を終了します。これら二つの肯定応答のいずれかが重複ACKである場合には、スプリアスタイムアウトの十分な証拠は存在しません。したがって、F-RTOの送信者は、従来のアルゴリズムと同様に、スロースタートで未確認のセグメントを再送します。とともに
SACK-enhanced version of the F-RTO algorithm, spurious timeouts may be detected even if duplicate ACKs arrive after an RTO retransmission.
F-RTOアルゴリズムのSACK-拡張バージョン、スプリアスタイムアウトは重複ACKがRTO再送の後に到着した場合であっても検出することができます。
The F-RTO algorithm can also be applied to the Stream Control Transmission Protocol (SCTP) [Ste00], because SCTP has acknowledgment and packet retransmission concepts similar to TCP. For convenience, this document mostly refers to TCP, but the algorithms and other discussion are valid for SCTP as well.
SCTPはTCPと同様の確認応答とパケット再送の概念を持っているので、F-RTOアルゴリズムはまた、ストリーム制御伝送プロトコル（SCTP）[Ste00]に適用することができます。便宜上、このドキュメントでは、主にTCPを意味するが、アルゴリズムや他の議論は同様にSCTPのために有効です。
This document is organized as follows. Section 2 describes the basic F-RTO algorithm. Section 3 outlines an optional enhancement to the F-RTO algorithm that takes advantage of the TCP SACK option. Section 4 discusses the possible actions to be taken after detecting a spurious RTO. Section 5 gives considerations on applying F-RTO with SCTP, and Section 6 discusses the security considerations.
次のようにこの文書は、組織化されています。第2節では、基本的なF-RTOアルゴリズムを記述しています。第3節では、TCP SACKオプションを利用していますF-RTOアルゴリズムにオプションの拡張機能の概要を説明します。第4節では、偽のRTOを検出した後に取られる可能なアクションについて説明します。第5節では、SCTPとF-RTOを適用する上での考慮を与え、そして第6節は、セキュリティ上の考慮事項について説明します。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
彼らは、この文書に表示される[RFC2119]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
A timeout is considered spurious if it would have been avoided had the sender waited longer for an acknowledgment to arrive [LM03]. F-RTO affects the TCP sender behavior only after a retransmission timeout. Otherwise, the TCP behavior remains the same. When the RTO expires, the F-RTO algorithm monitors incoming acknowledgments and if the TCP sender gets an acknowledgment for a segment that was not retransmitted due to timeout, the F-RTO algorithm declares a timeout spurious. The actions taken in response to a spurious timeout are not specified in this document, but we discuss some alternatives in Section 4. This section introduces the algorithm and then discusses the different steps of the algorithm in more detail.
それは回避されていた場合はタイムアウトが送信者が[LM03]を到着する確認応答を長く待っていたスプリアスと考えられています。 F-RTOは再送タイムアウト後にTCPの送信者の行動に影響を与えます。それ以外の場合は、TCPの動作は同じまま。 RTOの期限が切れると、F-RTOアルゴリズムは、着信確認応答を監視し、TCPの送信側がタイムアウトに再送されていなかったセグメントの確認応答を取得する場合、F-RTOアルゴリズムは、スプリアスタイムアウトを宣言します。スプリアスタイムアウトに対応して取られたアクションは、この文書で指定されたが、我々はこのセクションでは、アルゴリズムを導入し、その後、より詳細に、アルゴリズムの異なる手順を説明します第4節では、いくつかの選択肢を議論されていません。
Following the practice used with the Eifel Detection algorithm [LM03], we use the "SpuriousRecovery" variable to indicate whether the retransmission is declared spurious by the sender. This variable can be used as an input for a corresponding response algorithm. With F-RTO, the value of SpuriousRecovery can be either SPUR_TO (indicating a spurious retransmission timeout) or FALSE (indicating that the timeout is not declared spurious), and the TCP sender should follow the conventional RTO recovery algorithm.
アイフェル検出アルゴリズム[LM03]で使用する練習の後、我々は再送信が送信者によってスプリアス宣言されているかどうかを示すために「SpuriousRecovery」変数を使用します。この変数は、対応する応答アルゴリズムの入力として使用することができます。 F-RTOと、SpuriousRecoveryの値がSPUR_TO（スプリアス再送タイムアウトを示す）またはFALSE（偽タイムアウトが宣言されていないことを示す）のいずれかとすることができ、TCP送信者は、従来のRTO回復アルゴリズムに従うべきです。
A TCP sender MAY implement the basic F-RTO algorithm. If it chooses to apply the algorithm, the following steps MUST be taken after the retransmission timer expires. If the sender implements some loss recovery algorithm other than Reno or NewReno [FHG04], the F-RTO algorithm SHOULD NOT be entered when earlier fast recovery is underway.
TCPの送信者は、基本的なF-RTOアルゴリズムを実装してもよいです。それはアルゴリズムを適用することを選択した場合は再送タイマが満了した後、以下のステップがとられなければなりません。送信者がリノまたはNewRenoの[FHG04]以外のいくつかの損失回復アルゴリズムを実装している場合、以前の速い回復が進行中であるとき、F-RTOアルゴリズムは入力しないでください。
1) When RTO expires, retransmit the first unacknowledged segment and set SpuriousRecovery to FALSE. Also, store the highest sequence number transmitted so far in variable "recover".
RTOが満了すると1）、最初の不承認のセグメントを再送し、FALSEにSpuriousRecoveryを設定。また、これまでの変数「回復」で送信された最高のシーケンス番号を格納します。
2) When the first acknowledgment after the RTO retransmission arrives at the sender, the sender chooses one of the following actions, depending on whether the ACK advances the window or whether it is a duplicate ACK.
RTO再送後の最初の肯定応答が送信者に到達すると2）、送信側は、ACKウィンドウを進めるかどうか、またはそれが重複ACKであるかどうかによって、次のアクションのいずれかを選択します。
a) If the acknowledgment is a duplicate ACK OR it acknowledges a sequence number equal to the value of "recover" OR it does not acknowledge all of the data that was retransmitted in step 1, revert to the conventional RTO recovery and continue by retransmitting unacknowledged data in slow start. Do not enter step 3 of this algorithm. The SpuriousRecovery variable remains as FALSE.
a）の承認が重複ACKであるか、「回復」の値に等しいシーケンス番号を認識し、またはそれが、ステップ1で再送されたデータのすべてを認める従来のRTO回復に戻すと、未確認の再送信することによって継続していない場合スロースタートのデータ。このアルゴリズムのステップ3を入力しないでください。 SpuriousRecovery変数はFALSEとして残っています。
b) Else, if the acknowledgment advances the window AND it is below the value of "recover", transmit up to two new (previously unsent) segments and enter step 3 of this algorithm. If the TCP sender does not have enough unsent data, it can send only one segment. In addition, the TCP sender MAY override the Nagle algorithm [Nag84] and immediately send a segment if needed. Note that sending two segments in this step is allowed by TCP congestion control requirements [APS99]: An F-RTO TCP sender simply chooses different segments to transmit.
肯定応答ウィンドウを進め、それが「回復」の値以下である場合、B）そうでなければ、2つの新しい（以前に未送信）のセグメントまで送信し、このアルゴリズムのステップ3に入ります。 TCPの送信側が十分な未送信データがない場合は、それだけで一つのセグメントを送信することができます。また、TCPの送信者は、Nagleアルゴリズム[Nag84]をオーバーライドして、すぐに必要に応じてセグメントを送信することができます。 F-RTO TCP送信者は、単に送信する異なるセグメントを選択：このステップで二つのセグメントを送信するTCPの輻輳制御要件[APS99]で許可されていることに留意されたいです。
If the TCP sender does not have any new data to send, or the advertised window prohibits new transmissions, the recommended action is to skip step 3 of this algorithm and continue with slow start retransmissions, following the conventional RTO recovery algorithm. However, alternative ways of handling the window-limited cases that could result in better performance are discussed in Appendix C.
TCPの送信者が送信するための新たなデータを持っていない、または広告ウィンドウが新しい送信を禁止している場合は、推奨されるアクションは、このアルゴリズムのステップ3をスキップして、従来のRTO回復アルゴリズムを以下、スロースタート再送信を継続することです。ただし、パフォーマンスが向上する可能性があり、ウィンドウが制限された場合を扱う別の方法は、付録Cで議論されています
3) When the second acknowledgment after the RTO retransmission arrives at the sender, the TCP sender either declares the timeout spurious, or starts retransmitting the unacknowledged segments.
3）RTO再送後の第二の肯定応答は、送信側でTCPの送信者を到着するといずれかのスプリアスタイムアウトを宣言し、または未確認のセグメントを再送信を開始します。
a) If the acknowledgment is a duplicate ACK, set the congestion window to no more than 3 * MSS, and continue with the slow start algorithm retransmitting unacknowledged segments. The congestion window can be set to 3 * MSS, because two round-trip times have elapsed since the RTO, and a conventional TCP sender would have increased cwnd to 3 during the same time. Leave SpuriousRecovery set to FALSE.
確認応答が重複ACKの場合a）に、せいぜい3に輻輳ウィンドウ* MSSを設定して、未確認のセグメントを再送スロースタートアルゴリズムを続けます。 2往復時間がRTOから経過したため、輻輳ウィンドウは、3 * MSSに設定することができ、かつ従来のTCPの送信者は、同じ時間の間に3までにcwndを増加していたであろう。 SpuriousRecoveryはFALSEに設定しておきます。
b) If the acknowledgment advances the window (i.e., if it acknowledges data that was not retransmitted after the timeout), declare the timeout spurious, set SpuriousRecovery to SPUR_TO, and set the value of the "recover" variable to SND.UNA (the oldest unacknowledged sequence number [Pos81]).
確認ウィンドウが進むb）は、タイムアウト後に再送されていなかったデータ）を承認した場合（すなわち、SPUR_TOにSpuriousRecoveryを設定スプリアスタイムアウトを宣言し、（SND.UNAに「回復」変数の値を設定します最も古い未確認のシーケンス番号[Pos81]）。
The F-RTO sender takes cautious actions when it receives duplicate acknowledgments after a retransmission timeout. Because duplicate ACKs may indicate that segments have been lost, reliably detecting a spurious timeout is difficult due to the lack of additional information. Therefore, it is prudent to follow the conventional TCP recovery in those cases.
それは再送タイムアウトの後、重複確認応答を受信したときにF-RTOの送信側は慎重な行動を取ります。重複ACKはセグメントが失われていることを示す可能性があるので、確実にスプリアスタイムアウトを検出することにより、付加的な情報が不足することは困難です。したがって、これらの例では、従来のTCPの回復に従うことが賢明です。
If the first acknowledgment after the RTO retransmission covers the "recover" point at algorithm step (2a), there is not enough evidence that a non-retransmitted segment has arrived at the receiver after the timeout. This is a common case when a fast retransmission is lost and has been retransmitted again after an RTO, while the rest of the unacknowledged segments were successfully delivered to the TCP receiver before the retransmission timeout. Therefore, the timeout cannot be declared spurious in this case.
RTO再送後の最初の承認がアルゴリズムのステップ（2A）で「回復」のポイントをカバーする場合、非再送されたセグメントは、タイムアウト後に受信機に到着したという十分な証拠はありません。これは、高速再送が失われ、未確認のセグメントの残りの部分が正常に再送タイムアウトの前にTCP受信機に配信された一方で、RTOの後に再び再送されてきた場合に一般的なケースです。そのため、タイムアウトはこの場合には、スプリアス宣言することはできません。
If the first acknowledgment after the RTO retransmission does not acknowledge all of the data that was retransmitted in step 1, the TCP sender reverts to the conventional RTO recovery. Otherwise, a malicious receiver acknowledging partial segments could cause the sender to declare the timeout spurious in a case where data was lost.
RTO再送後の最初の確認手順1で再送されたデータのすべてを認めていない場合は、TCPの送信者は、従来のRTO回復に戻ります。それ以外の場合は、部分セグメントを認め悪質な受信機は、送信者が、データが失われた場合のスプリアスタイムアウトを宣言する可能性があります。
The TCP sender is allowed to send two new segments in algorithm branch (2b) because the conventional TCP sender would transmit two segments when the first new ACK arrives after the RTO retransmission. If sending new data is not possible in algorithm branch (2b), or if the receiver window limits the transmission, the TCP sender has to send something in order to prevent the TCP transfer from stalling. If no segments were sent, the pipe between sender and receiver might run out of segments, and no further acknowledgments would arrive. Therefore, in the window-limited case, the recommendation is to revert to the conventional RTO recovery with slow start retransmissions. Appendix C discusses some alternative solutions for window-limited situations.
TCPの送信者は、最初の新しいACKがRTO再送後に到着したときに、従来のTCP送信者が二つのセグメントを送信してしまうため、アルゴリズムのブランチ（2B）に二つの新しいセグメントを送信することが許可されています。新しいデータを送信することは、アルゴリズムの枝でできない場合は、受信ウィンドウは、送信を制限している場合（図2b）、または、TCPの送信者は、失速からのTCP転送を防ぐために何かを送信する必要があります。何のセグメントが送信されなかった場合は、送信者と受信者の間のパイプは、セグメントが不足する可能性があり、それ以上の確認応答が到着しないだろう。したがって、ウィンドウが制限された場合に、推奨は、スロースタート再送を伴う従来のRTO回復に戻すことです。付録Cには、ウィンドウが制限された状況のために、いくつかの代替ソリューションについて説明します。
If the retransmission timeout is declared spurious, the TCP sender sets the value of the "recover" variable to SND.UNA in order to allow fast retransmit [FHG04]. The "recover" variable was proposed for avoiding unnecessary, multiple fast retransmits when RTO expires during fast recovery with NewReno TCP. Because the sender retransmits only the segment that triggered the timeout, the problem of unnecessary multiple fast retransmits [FHG04] cannot occur. Therefore, if three duplicate ACKs arrive at the sender after the timeout, they probably indicate a packet loss, and thus fast retransmit should be used to allow efficient recovery. If there are not enough duplicate ACKs arriving at the sender after a packet loss, the retransmission timer expires again and the sender enters step 1 of this algorithm.
再送タイムアウトがスプリアス宣言されている場合、TCPの送信者は、高速再送[FHG04]できるようにするためにSND.UNAに「回復」変数の値を設定します。 「回復」変数は、RTOがNewRenoのTCPと高速回復中に期限切れになったときに不必要な、複数の高速再送を回避するために提案されました。送信者がタイムアウトをトリガセグメントのみを再送信するので、不必要な複数の高速再送[FHG04]の問題が発生することができません。 3つの重複ACKがタイムアウト後に送信側に到着した場合はそのため、彼らはおそらくパケット損失を示し、これにより高速再送は、効率的な回収を可能にするために使用する必要があります。パケットロスの後に、送信者に届く十分な重複ACKが存在しない場合は、再送タイマが再び満了すると、送信者は、このアルゴリズムのステップ1に入ります。
When the timeout is declared spurious, the TCP sender cannot detect whether the unnecessary RTO retransmission was lost. In principle, the loss of the RTO retransmission should be taken as a congestion signal. Thus, there is a small possibility that the F-RTO sender will violate the congestion control rules, if it chooses to fully revert congestion control parameters after detecting a spurious timeout. The Eifel detection algorithm has a similar property, while the DSACK option can be used to detect whether the retransmitted segment was successfully delivered to the receiver.
タイムアウトがスプリアス宣言されると、TCPの送信者は、不要なRTO再送が失われたかどうかを検出することはできません。原理的には、RTO再送の損失は、輻輳信号として解釈されるべきです。したがって、それは完全にスプリアスタイムアウトを検出した後、輻輳制御パラメータを戻すことを選択した場合、F-RTOの送信側は、輻輳制御ルールに違反することが小さい可能性があります。 DSACKオプションは再送セグメントが正常に受信機に配信されたか否かを検出するために使用することができるがアイフェル検出アルゴリズムは、同様の性質を有します。
The F-RTO algorithm has a side-effect on the TCP round-trip time measurement. Because the TCP sender can avoid most of the unnecessary retransmissions after detecting a spurious timeout, the sender is able to take round-trip time samples on the delayed segments. If the regular RTO recovery was used without TCP timestamps, this would not be possible due to the retransmission ambiguity. As a result, the RTO is likely to have more accurate and larger values with F-RTO than with the regular TCP after a spurious timeout that was triggered due to delayed segments. We believe this is an advantage in the networks that are prone to delay spikes.
F-RTOアルゴリズムはTCPのラウンドトリップ時間測定に副作用を持っています。 TCPの送信者が偽のタイムアウトを検出した後、不要な再送信のほとんどを避けることができるため、送信者は遅れセグメント上のラウンドトリップ時間のサンプルを取ることが可能です。通常のRTO回復がTCPタイムスタンプせずに使用した場合、これは、再送曖昧に不可能であろう。結果として、RTOが原因遅延セグメントにトリガされたスプリアスタイムアウト後に正規TCPよりもF-RTOを用いてより正確でより大きな値を有する可能性があります。私たちは、これがスパイクを遅らせる傾向があるネットワークでは有利であると考えています。
There are some situations where the F-RTO algorithm may not avoid unnecessary retransmissions after a spurious timeout. If packet reordering or packet duplication occurs on the segment that triggered the spurious timeout, the F-RTO algorithm may not detect the spurious timeout due to incoming duplicate ACKs. Additionally, if a spurious timeout occurs during fast recovery, the F-RTO algorithm often cannot detect the spurious timeout because the segments that were transmitted before the fast recovery trigger duplicate ACKs. However, we consider these cases rare, and note that in cases where
F-RTOアルゴリズムがスプリアスタイムアウト後に不必要な再送信を回避しないかもしれないいくつかの状況があります。パケットの並べ替えまたはパケットの重複がスプリアスタイムアウトをトリガセグメントで発生した場合、F-RTOアルゴリズムによる着信重複ACKにスプリアスタイムアウトを検出しなくてもよいです。スプリアスタイムアウトが高速回復中に発生した場合、高速リカバリ・トリガーの前に送信されたセグメントはACKを複製するため、また、F-RTOアルゴリズムは、多くの場合、スプリアスタイムアウトを検出することはできません。しかし、我々はこれらの例稀考慮し、注意して例どこで
F-RTO fails to detect the spurious timeout, it retransmits the unacknowledged segments in slow start, and thus performs similarly to the regular RTO recovery.
F-RTOは、スロースタートで未確認のセグメントを再送する、スプリアスタイムアウトの検出に失敗し、したがって、定期的なRTO回復と同様に行います。
This section describes an alternative version of the F-RTO algorithm that uses the TCP Selective Acknowledgment Option [MMFR96]. By using the SACK option, the TCP sender detects spurious timeouts in most of the cases when packet reordering or packet duplication is present. If the SACK blocks acknowledge new data that was not transmitted after the RTO retransmission, the sender may declare the timeout spurious, even when duplicate ACKs follow the RTO.
このセクションでは、TCP選択的確認応答オプション[MMFR96]を使用してF-RTOアルゴリズムの代替バージョンを記述する。 SACKオプションを使用することにより、TCPの送信者は、パケットの並べ替えやパケット重複が存在するほとんどの場合スプリアスタイムアウトを検出します。 SACKブロックはRTO再送後に送信されなかった新しいデータを確認した場合、送信者は重複ACKがRTOをたどる場合でも、スプリアスタイムアウトを宣言してもよいです。
Given that the TCP Selective Acknowledgment Option [MMFR96] is enabled for a TCP connection, a TCP sender MAY implement the SACK-enhanced F-RTO algorithm. If the sender applies the SACK-enhanced F-RTO algorithm, it MUST follow the steps below. This algorithm SHOULD NOT be applied if the TCP sender is already in SACK loss recovery when retransmission timeout occurs. However, when retransmission timeout occurs during existing loss recovery, it should be possible to apply the principle of F-RTO within certain limitations. This is a topic for further research. Appendix B briefly discusses the related issues.
TCP選択確認応答オプションは、[MMFR96] TCP接続のために有効になっていることを考えると、TCPの送信者はSACK強化F-RTOアルゴリズムを実装してもよいです。送信者はSACK強化F-RTOアルゴリズムを適用する場合は、以下の手順に従わなければなりません。再送タイムアウトが発生したときにTCPの送信者はSACKの損失回復にすでに存在する場合は、このアルゴリズムが適用されるべきではありません。再送タイムアウトは、既存の損失回復の間に発生した場合しかし、一定の制限内でF-RTOの原則を適用することが可能でなければなりません。これは、今後の研究の課題です。付録Bは、簡単に関連する問題について説明します。
The steps of the SACK-enhanced version of the F-RTO algorithm are as follows.
次のようにF-RTOアルゴリズムのSACK-強化されたバージョンの手順は次のとおりです。
1) When the RTO expires, retransmit the first unacknowledged segment and set SpuriousRecovery to FALSE. Set variable "recover" to indicate the highest segment transmitted so far. Following the recommendation in SACK specification [MMFR96], reset the SACK scoreboard.
RTOが満了すると1）、最初の不承認のセグメントを再送し、FALSEにSpuriousRecoveryを設定。これまでに送信し、最も高いセグメントを示すために「回復」変数に設定します。 SACK仕様[MMFR96]で推薦に続き、SACKスコアボードをリセットします。
2) Wait until the acknowledgment of the data retransmitted due to the timeout arrives at the sender. If duplicate ACKs arrive before the cumulative acknowledgment for retransmitted data, adjust the scoreboard according to the incoming SACK information. Stay in step 2 and wait for the next new acknowledgment. If RTO expires again, go to step 1 of the algorithm.
タイムアウトによる再送データの確認応答が送信者に到着するまで2）待ってください。重複ACKが再送信されたデータの累積確認応答の前に到着した場合、着信SACK情報に応じてスコアボードを調整します。ステップ2に滞在し、次の新しい確認応答を待ちます。 RTOが再び有効期限が切れた場合、アルゴリズムの1に進みます。
a) if a cumulative ACK acknowledges a sequence number equal to "recover", revert to the conventional RTO recovery and set the congestion window to no more than 2 * MSS, like a regular TCP would do. Do not enter step 3 of this algorithm.
a）は、累積ACKは、「回復」は、従来のRTO回復に戻すと、通常のTCPが行うだろうと同じように、せいぜい2 * MSSに輻輳ウィンドウを設定するに等しいシーケンス番号を認識している場合。このアルゴリズムのステップ3を入力しないでください。
b) else, if a cumulative ACK acknowledges a sequence number (smaller than "recover", but larger than SND.UNA) transmit up to two new (previously unsent) segments and proceed to step 3. If the TCP sender is not able to transmit any previously unsent data -- either due to receiver window limitation, or because it does not have any new data to send -- the recommended action is to refrain from entering step 3 of this algorithm. Rather, continue with slow start retransmissions following the conventional RTO recovery algorithm.
b）の他に、累積ACKシーケンス番号（「回復」よりも小さいが、SND.UNAより大きい）は、2つの新しい（以前に未送信）のセグメントまで送信し、TCPの送信者ができない場合は手順3に進ん認めた場合ウィンドウの制限を受信機に起因するか、それは、送信するすべての新しいデータを持っていないので - - 以前に未送信データを送信し、推奨アクションは、このアルゴリズムのステップ3に入るのを控えることです。むしろ、従来のRTO回復アルゴリズムを以下のスロースタート再送信を続行します。
It is also possible to apply some of the alternatives for handling window-limited cases discussed in Appendix C. In this case, the TCP sender should follow the recommendations concerning acknowledgments of retransmitted segments given in Appendix B.
それは、この場合、付録Cで説明するウィンドウが制限された場合を扱うための選択肢のいくつかを適用することも可能である、TCPの送信者は付録Bに与えられた再送されたセグメントの確認応答に関する勧告に従うべきです
3) The next acknowledgment arrives at the sender. Either a duplicate ACK or a new cumulative ACK (advancing the window) applies in this step.
3）次の確認は、送信側に到着します。重複ACKまたは（ウィンドウを進める）新たな累積ACKのどちらかが、この段階で適用されます。
a) if the ACK acknowledges a sequence number above "recover", either in SACK blocks or as a cumulative ACK, set the congestion window to no more than 3 * MSS and proceed with the conventional RTO recovery, retransmitting unacknowledged segments. Take this branch also when the acknowledgment is a duplicate ACK and it does not acknowledge any new, previously unacknowledged data below "recover" in the SACK blocks. Leave SpuriousRecovery set to FALSE.
ACKは、SACKブロックにまたは累積ACKのいずれかとして、「回復」は、上記シーケンス番号を確認応答する場合A）、せいぜい3 * MSSに輻輳ウィンドウを設定し、未確認のセグメントを再送信する、従来のRTO回復を進めます。確認応答が重複ACKであり、それはSACKブロックに「回復」は、以下のいずれかの新しい、以前に未確認のデータを確認していない場合も、このブランチを取ります。 SpuriousRecoveryはFALSEに設定しておきます。
b) if the ACK does not acknowledge sequence numbers above "recover" AND it acknowledges data that was not acknowledged earlier (either with cumulative acknowledgment or using SACK blocks), declare the timeout spurious and set SpuriousRecovery to SPUR_TO. The retransmission timeout can be declared spurious, because the segment acknowledged with this ACK was transmitted before the timeout.
b）のACKが「回復」し、それが以前に認められていなかったデータを承認（いずれかの累積承認または）SACKブロックを使用して、タイムアウトがスプリアスとSPUR_TOにSpuriousRecoveryを設定宣言する上記のシーケンス番号を確認していない場合。セグメントはこのACKがタイムアウトする前に送信されたと認めたため、再送タイムアウトは、スプリアス宣言することができます。
If there are unacknowledged holes between the received SACK blocks, those segments are retransmitted similarly to the conventional SACK recovery algorithm [BAFW03]. If the algorithm exits with SpuriousRecovery set to SPUR_TO, "recover" is set to SND.UNA, thus allowing fast recovery on incoming duplicate acknowledgments.
受信されたSACKブロック間の未確認の穴がある場合、これらのセグメントは、[BAFW03従来SACK回復アルゴリズムと同様に再送されます。 SpuriousRecoveryとアルゴリズムは終了がSPUR_TOに設定した場合は、「回復」ので、着信重複確認応答の高速リカバリが可能、SND.UNAに設定されています。
Upon retransmission timeout, a conventional TCP sender assumes that outstanding segments are lost and starts retransmitting the unacknowledged segments. When the retransmission timeout is detected to be spurious, the TCP sender should not continue retransmitting based on the timeout. For example, if the sender was in congestion avoidance phase transmitting new, previously unsent segments, it should continue transmitting previously unsent segments after detecting a spurious RTO. This document does not describe the response to spurious timeouts, but a response algorithm is described in RFC 4015 [LG04].
再送タイムアウト時には、従来のTCPの送信者は、優れたセグメントが失われていることを前提とし未確認のセグメントを再送信を開始します。再送タイムアウトがスプリアスあることが検出された場合、TCPの送信者がタイムアウトに基づいて再送し続けるべきではありません。送信者が新しい、以前に未送信のセグメントを送信する輻輳回避フェーズにあった場合、それは偽のRTOを検出した後、以前に未送信のセグメントを送信し続けなければなりません。この文書では、スプリアスタイムアウトに対する応答を記載していないが、応答アルゴリズムは、RFC 4015 [LG04]に記載されています。
Additionally, different response variants to spurious retransmission timeout have been discussed in various research papers [SKR03, GL03, Sar03] and IETF documents [SL03]. The different response alternatives vary in whether the spurious retransmission timeout should be taken as a congestion signal, thus causing the congestion window or slow start threshold to be reduced at the sender, or whether the congestion control state should be fully reverted to the state valid prior to the retransmission timeout.
また、スプリアス再送タイムアウトに異なる応答変異体は、様々な研究論文[SKR03、GL03、Sar03]とIETFドキュメント[SL03]で議論されています。スプリアス再送タイムアウトは、このように送信側で減少し、又は輻輳制御状態が完全に前の有効な状態に復帰する必要があるかどうかをする輻輳ウィンドウまたはスロースタート閾値を引き起こし、混雑信号として解釈されるべきであるか否かで異なる応答選択肢が変わります再送タイムアウトします。
SCTP has similar retransmission algorithms and congestion control to TCP. The SCTP T3-rtx timer for one destination address is maintained in the same way as the TCP retransmission timer, and after a T3-rtx expires, an SCTP sender retransmits unacknowledged data chunks in slow start like TCP does. Therefore, SCTP is vulnerable to the negative effects of the spurious retransmission timeouts similarly to TCP. Due to similar RTO recovery algorithms, F-RTO algorithm logic can be applied also to SCTP. Since SCTP uses selective acknowledgments, the SACK-based variant of the algorithm is recommended, although the basic version can also be applied to SCTP. However, SCTP contains features that are not present with TCP that need to be discussed when applying the F-RTO algorithm.
SCTPはTCPと同様の再送アルゴリズムと輻輳制御を持っています。 1つの宛先アドレスのためのSCTPのT3-RTXタイマーは、TCPの再送タイマと同じように維持され、T3-RTXの有効期限が切れた後にTCPが行うよう、SCTP送信者は、スロースタートで未確認のデータチャンクを再送します。したがって、SCTPは、TCPと同様にスプリアス再送タイムアウトの負の影響に対して脆弱です。同様のRTO回復アルゴリズムに、F-RTOアルゴリズムロジックはSCTPにも適用することができます。 SCTPは、選択的肯定応答を使用するための基本的なバージョンはまた、SCTPに適用することができるが、アルゴリズムのSACKベースの変異体は、推奨されます。ただし、SCTPは、F-RTOアルゴリズムを適用するときに議論する必要があるTCPと存在しない機能が含まれています。
SCTP associations can be multi-homed. The current retransmission policy states that retransmissions should go to alternative addresses. If the retransmission was due to spurious timeout caused by a delay spike, it is possible that the acknowledgment for the retransmission arrives back at the sender before the acknowledgments of the original transmissions arrive. If this happens, a possible loss of the original transmission of the data chunk that was retransmitted due to the spurious timeout may remain undetected when applying the F-RTO algorithm. Because the timeout was caused by a delay spike, and it was spurious in that respect, a suitable response is to continue by sending new data. However, if the original transmission was lost, fully reverting the congestion control parameters is too aggressive. Therefore, taking conservative actions on congestion control is recommended, if the SCTP association is multi-homed and retransmissions go to alternative addresses. The information in duplicate TSNs can be then used for reverting congestion control, if desired [BA04].
SCTPアソシエーションは、マルチホームすることができます。現在の再送ポリシーは、再送信が代替アドレスに行くべきであると述べています。再送が遅延スパイクに起因するスプリアスタイムアウトによるものであったならば、本来の送信の確認応答が到着する前に、再送信のための肯定応答が送信者に戻って到着することは可能です。この場合、F-RTOアルゴリズムを適用する場合、スプリアスタイムアウト再送されたデータチャンクの元の送信の可能性のある損失が検出されないままであってもよいです。タイムアウトが遅延スパイクによって引き起こされ、それがその点で偽だったので、適した応答は、新たなデータを送信することにより、継続することです。元の送信が失われた場合は、完全に輻輳制御パラメータを元に戻すことは、あまりにも積極的です。 SCTPアソシエーションがマルチホームで、再送信は、代替アドレスに行けばそのため、輻輳制御に保守的な行動を取ることは、推奨されます。 【BA04】所望であれば、重複したTSNの情報は、次いで、輻輳制御を戻すために使用することができます。
Note that the forward transmissions made in F-RTO algorithm step (2b) should be destined to the primary address, since they are not retransmissions.
彼らは再送信されないため、F-RTOアルゴリズムステップで作られた前方送信が（図2b）、プライマリアドレス宛する必要があることに注意してください。
When making a retransmission, an SCTP sender can bundle a number of unacknowledged data chunks and include them in the same packet. This needs to be considered when implementing F-RTO for SCTP. The basic principle of F-RTO still holds: in order to declare the timeout spurious, the sender must get an acknowledgment for a data chunk that was not retransmitted after the retransmission timeout. In other words, acknowledgments of data chunks that were bundled in RTO retransmission must not be used for declaring the timeout spurious.
再送を行う場合、SCTP送信者は、未確認データチャンクの数をバンドルし、同じパケットに含めることができます。これは、SCTPのためのF-RTOを実装する際に考慮する必要があります。 F-RTOの基本原理は、まだ保持している：スプリアスタイムアウトを宣言するためには、送信者が再送タイムアウト後に再送されていなかったデータチャンクのための承認を取得する必要があります。言い換えれば、RTO再送にバンドルされたデータチャンクの確認応答がスプリアスタイムアウトを宣言するために使用することはできません。
The main security threat regarding F-RTO is the possibility that a receiver could mislead the sender into setting too large a congestion window after an RTO. There are two possible ways a malicious receiver could trigger a wrong output from the F-RTO algorithm. First, the receiver can acknowledge data that it has not received. Second, it can delay acknowledgment of a segment it has received earlier, and acknowledge the segment after the TCP sender has been deluded to enter algorithm step 3.
F-RTOに関する主要なセキュリティ上の脅威は、受信機がRTOの後にあまりにも大きな輻輳ウィンドウを設定するに送信者を誤解させることができる可能性があります。悪質な受信機はF-RTOアルゴリズムからの間違った出力を引き起こす可能性が2つの方法があります。まず、受信機は、受信していないデータを確認することができます。第二に、それが以前に受信したセグメントの確認応答を遅らせる、およびTCPの送信者がアルゴリズムのステップ3を入力するように惑わされた後のセグメントを確認することができます。
If the receiver acknowledges a segment it has not really received, the sender can be led to declare spurious timeout in the F-RTO algorithm, step 3. However, because the sender will have an incorrect state, it cannot retransmit the segment that has never reached the receiver. Therefore, this attack is unlikely to be useful for the receiver to maliciously gain a larger congestion window.
受信機はそれが本当に受信していないセグメントを承認した場合、送信者はF-RTOアルゴリズムでスプリアスタイムアウトを宣言するために導くことができ、ステップ3.しかし、送信者が間違った状態になりますので、それは決してありませんセグメントを再送することはできません受信機に到達しました。したがって、この攻撃が悪意大きな輻輳ウィンドウを得るために受信機のために有用である可能性は低いです。
A common case for a retransmission timeout is that a fast retransmission of a segment is lost. If all other segments have been received, the RTO retransmission causes the whole window to be acknowledged at once. This case is recognized in F-RTO algorithm branch (2a). However, if the receiver only acknowledges one segment after receiving the RTO retransmission, and then the rest of the segments, it could cause the timeout to be declared spurious when it is not. Therefore, it is suggested that, when an RTO expires during fast recovery phase, the sender would not fully revert the congestion window even if the timeout was declared spurious. Instead, the sender would reduce the congestion window to 1.
再送タイムアウトのための一般的なケースは、セグメントの高速再送が失われることです。他のすべてのセグメントが受信されている場合は、RTO再送は、ウィンドウ全体が一度に認知されるようにします。このケースは、F-RTOアルゴリズムブランチ（2A）で認識されています。受信機のみRTO再送信を受信した後、一つのセグメントを認識し、セグメントの、その後残りの場合は、それがない場合、タイムアウトがスプリアス宣言する可能性があります。したがって、RTOは高速回復期に満了したときに、送信側は完全にタイムアウトがスプリアス宣言された場合でも、輻輳ウィンドウを元に戻すないだろう、ということを示唆しています。代わりに、送信者は1に輻輳ウィンドウを減少させるであろう。
If there is more than one segment missing at the time of a retransmission timeout, the receiver does not benefit from misleading the sender to declare a spurious timeout because the sender would have to go through another recovery period to retransmit the missing segments, usually after an RTO has elapsed.
複数のセグメントが再送タイムアウトの時が欠落している場合は、送信者が後に通常、欠落したセグメントを再送信するために、別の回復期間を経る必要があるため、受信機は、スプリアスタイムアウトを宣言するために、送信者に誤解を招くから恩恵を受けていませんRTOが経過しました。
We are grateful to Reiner Ludwig, Andrei Gurtov, Josh Blanton, Mark Allman, Sally Floyd, Yogesh Swami, Mika Liljeberg, Ivan Arias Rodriguez, Sourabh Ladha, Martin Duke, Motoharu Miyake, Ted Faber, Samu Kontinen, and Kostas Pentikousis for the discussion and feedback contributed to this text.
私たちは、議論のためのライナールートヴィヒ、アンドレイGurtov、ジョシュ・ブラントン、マーク・オールマン、サリー・フロイド、ヨーゲッシュスワミ、ミカLiljeberg、イヴァン・アリアス・ロドリゲス、Sourabh Ladha、マーティン・デューク、元治三宅、テッド・フェーバー、Samu Kontinen、およびコスタスPentikousisに感謝していますフィードバックは、このテキストに貢献しました。
[APS99] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[APS99]オールマン、M.、パクソン、V.、およびW.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[BAFW03] Blanton, E., Allman, M., Fall, K., and L. Wang, "A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP", RFC 3517, April 2003.
[BAFW03]ブラントン、E.、オールマン、M.、秋、K.、およびL.王は、2003年4月、RFC 3517の "保守的な選択的確認応答（SACK）は、TCPのために損失回復アルゴリズムをベース"。
[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月。
[FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[FHG04]フロイド、S.、ヘンダーソン、T.、およびA. Gurtov、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 3782、2004年4月。
[MMFR96] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, October 1996.
【MMFR96]マティス、M.、Mahdavi、J.、フロイド、S.、とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[PA00]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
【Pos81]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[Ste00] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[Ste00]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。
[ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[ABF01]オールマン、M.、バラクリシュナン、H.、およびS.フロイド、RFC 3042、2001年1月 "株式会社ミットを使用したTCPの損失回復の強化"。
[BA04] Blanton, E. and M. Allman, "Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions", RFC 3708, February 2004.
[BA04]ブラントン、E.およびM.オールマン、RFC 3708、2004年2月「スプリアス再送を検出するためにTCP複製選択的確認応答（DSACKs）およびストリーム制御伝送プロトコル（SCTP）重複送信シーケンス番号（TSNを）の使用」。
[BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[BBJ92]ジェーコブソン、V.、ブレーデン、R.、およびD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[FMMP00] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An Extension to the Selective Acknowledgement (SACK) Option for TCP", RFC 2883, July 2000.
【FMMP00]フロイド、S.、Mahdavi、J.、マティス、M.、およびM.ポドルスキー、 "TCPのための選択的確認応答（SACK）オプションの拡張"、RFC 2883、2000年7月。
[GL02] A. Gurtov and R. Ludwig. Evaluating the Eifel Algorithm for TCP in a GPRS Network. In Proc. of European Wireless, Florence, Italy, February 2002.
【GL02] A. Gurtov及びR.ルートヴィヒ。 GPRSネットワークにおけるTCPのためのアイフェルアルゴリズムを評価します。 PROCで。ヨーロッパのワイヤレス、フィレンツェ、イタリア、2002年2月の。
[GL03] A. Gurtov and R. Ludwig, Responding to Spurious Timeouts in TCP. In Proceedings of IEEE INFOCOM 03, San Francisco, CA, USA, March 2003.
【GL03] A. Gurtov及びR.ルートヴィヒ、TCPにスプリアスタイムアウトに応答します。 IEEE INFOCOM 03、サンフランシスコ、CA、USA、2003年3月の議事録。
[Jac88] V. Jacobson. Congestion Avoidance and Control. In Proceedings of ACM SIGCOMM 88.
【Jac88] V.ヤコブソン。輻輳回避とコントロール。 ACM SIGCOMM 88の議事録。
[LG04] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[LG04]ルートヴィヒ、R.とA. Gurtov、 "TCPのためのアイフェルレスポンスアルゴリズム"、RFC 4015、2005年2月。
[LK00] R. Ludwig and R.H. Katz. The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. ACM SIGCOMM Computer Communication Review, 30(1), January 2000.
[LK00] R.ルートヴィヒ及びR.H.カッツ。アイフェルアルゴリズム：スプリアス再送に対するTCPは、堅牢な作り。 ACM SIGCOMMコンピュータコミュニケーションレビュー、30（1）、2000年1月。
[LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[LM03]ルートヴィヒ、R.及びM.マイヤー、 "TCPのためのアイフェル検出アルゴリズム"、RFC 3522、2003年4月。
[Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
[Nag84]ネーグル、J.、 "IP / TCPインターネットワークにおける輻輳制御"、RFC 896、1984年1月。
[SKR03] P. Sarolahti, M. Kojo, and K. Raatikainen. F-RTO: An Enhanced Recovery Algorithm for TCP Retransmission Timeouts. ACM SIGCOMM Computer Communication Review, 33(2), April 2003.
[SKR03] P. Sarolahti、M.古城、及びK. Raatikainen。 F-RTO：TCP再送信タイムアウトのための強化された回復アルゴリズム。 ACM SIGCOMMコンピュータコミュニケーションレビュー、33（2）、2003年4月。
[Sar03] P. Sarolahti. Congestion Control on Spurious TCP Retransmission Timeouts. In Proceedings of IEEE Globecom 2003, San Francisco, CA, USA. December 2003.
【Sar03] P. Sarolahti。スプリアスTCP再送タイムアウトの輻輳制御。 IEEEの議事録で2003年、サンフランシスコ、CA、USA GLOBECOM。 2003年12月。
[SL03] Y. Swami and K. Le, "DCLOR: De-correlated Loss Recovery using SACK Option for Spurious Timeouts", work in progress, September 2003.
「：スプリアスタイムアウトのためのSACKオプションを使用して無相関損失回復DCLOR」、進行中の作業、2003年9月[SL03] Y.スワミとK.ル、。
Appendix A: Scenarios
付録A：シナリオ
This section discusses different scenarios where RTOs occur and how the basic F-RTO algorithm performs in those scenarios. The interesting scenarios are: a sudden delay triggering retransmission timeout, loss of a retransmitted packet during fast recovery, link outage causing the loss of several packets, and packet reordering. A performance evaluation with a more thorough analysis on a real implementation of F-RTO is given in [SKR03].
このセクションでは、RTOSが発生異なるシナリオについて説明する方法と基本的なF-RTOアルゴリズムは、これらのシナリオで行います。興味深いシナリオは以下のとおりです。突然の遅延は、再送タイムアウト、高速リカバリ時の再送パケットの損失、いくつかのパケットの損失を引き起こしリンク停止、およびパケットの並べ替えをトリガします。 F-RTOの実際の実装上のより徹底的な分析と性能評価は、[SKR03]で与えられます。
A.1. Sudden Delay
A.1。突然の遅延
The main motivation behind the F-RTO algorithm is to improve TCP performance when a delay spike triggers a spurious retransmission timeout. The example below illustrates the segments and acknowledgments transmitted by the TCP end hosts when a spurious timeout occurs, but no packets are lost. For simplicity, delayed acknowledgments are not used in the example. The example below applies the Eifel Response Algorithm [LG04] after detecting a spurious timeout.
F-RTOアルゴリズムの背後にある主な動機は、遅延スパイクがスプリアス再送タイムアウトをトリガすると、TCPのパフォーマンスを改善することです。スプリアスタイムアウトが発生した場合の例では、以下のセグメントとTCPエンドホストによって送信された肯定応答を示すが、何らのパケットが失われていません。簡単にするために、遅れて確認応答は、例で使用されていません。以下の例では、スプリアスタイムアウトを検出した後、[LG04]アイフェル応答アルゴリズムを適用します。
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
5. |
[delay]
|
[RTO]
[F-RTO step (1)]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<earlier xmitted SEG 6> --->
7. <---------------------------- ACK 7
[F-RTO step (2b)]
8. SEND 12 ---------------------------->
9. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
<earlier xmitted SEG 7> --->
10. <---------------------------- ACK 8
[F-RTO step (3b)]
[SpuriousRecovery <- SPUR_TO]
(cwnd = 7, ssthresh = 6, FlightSize = 6)
11. SEND 14 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7)
12. <---------------------------- ACK 9
13. SEND 15 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7)
14. <---------------------------- ACK 10
15. SEND 16 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7)
...
When a sudden delay (long enough to trigger timeout) occurs at step 5, the TCP sender retransmits the first unacknowledged segment (step 6). The next ACK covers the RTO retransmission because the originally transmitted segment 6 arrived at the receiver, and the TCP sender continues by sending two new data segments (steps 8, 9). Note that on F-RTO steps (1) and (2b), congestion window and FlightSize are not yet reset because in the case of spurious timeout, the segments sent before the timeout are still in the network. However, the sender should still be equally aggressive toward conventional TCP. Because the second acknowledgment arriving after the RTO retransmission acknowledges data that was not retransmitted due to timeout (step 10), the TCP sender declares the timeout to be spurious and continues by sending new data on the next acknowledgments. Also, the congestion control state is reversed, as required by the Eifel Response Algorithm.
（タイムアウトをトリガするのに十分な長さ）突然の遅延は、ステップ5で発生した場合、TCP送信者は、まず不承認のセグメント（ステップ6）を再送します。元々送信されたセグメント6が受信機に到着したので、次のACKがRTO再送を覆い、TCP送信者は、2つの新たなデータセグメントを送信することによって継続する（8ステップ、9）。まだためスプリアスタイムアウトの場合にはリセットされない（1）F-RTOステップになお及び（2b）は、輻輳ウィンドウとFlightSize、タイムアウト前に送信されたセグメントは、ネットワークにまだあります。ただし、送信者はまだ従来のTCPに向けて均等に積極的でなければなりません。 RTO再送信がタイムアウト（ステップ10）に再送信されなかったデータを認識した後、第2の確認応答が到着しているので、TCPの送信者は、タイムアウトが偽りであることを宣言し、次の謝辞に新しいデータを送信することで続けています。アイフェルレスポンスアルゴリズムで必要とされる。また、輻輳制御状態が、逆転されます。
A.2. Loss of a Retransmission
A.2。再送信の損失
If a retransmitted segment is lost, the only way to retransmit it is to wait for the timeout to trigger the retransmission. Once the segment is successfully received, the receiver usually acknowledges several segments at once, because other segments in the same window have been successfully delivered before the retransmission arrives at the receiver. The example below shows a scenario where retransmission (of segment 6) is lost, as well as a later segment (segment 9) in the same window. The limited transmit [ABF01] or SACK TCP [MMFR96] enhancements are not in use in this example.
再送されたセグメントが失われた場合、それを再送信する唯一の方法は、再送をトリガするためにタイムアウトを待つことです。セグメントが正常に受信される再送信が受信機に到着する前に、同じウィンドウ内の他のセグメントが正常に配信されているため、受信機は、通常、一度に複数のセグメントを認めます。以下の例では、同じウィンドウ内に（セグメント6の）再送信が失われたシナリオ、ならびに後セグメント（セグメント9）を示します。限られた送信【ABF01]またはSACK TCP [MMFR96]拡張は、この例で使用されていません。
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
<segment 6 lost>
<segment 9 lost>
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
5. <---------------------------- ACK 6
6. <---------------------------- ACK 6
7. <---------------------------- ACK 6
8. SEND 6 --------------X
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<segment 6 lost>
9. <---------------------------- ACK 6
10. SEND 12 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
11. <---------------------------- ACK 6
12. SEND 13 ---------------------------->
(cwnd = 8, ssthresh = 3, FlightSize = 8)
[RTO]
13. SEND 6 ---------------------------->
(cwnd = 8, ssthresh = 2, FlightSize = 8)
14. <---------------------------- ACK 9
[F-RTO step (2b)]
15. SEND 14 ---------------------------->
16. SEND 15 ---------------------------->
(cwnd = 7, ssthresh = 2, FlightSize = 7)
17. <---------------------------- ACK 9
[F-RTO step (3a)]
[SpuriousRecovery <- FALSE]
(cwnd = 3, ssthresh = 2, FlightSize = 7)
18. SEND 9 ---------------------------->
19. SEND 10 ---------------------------->
20. SEND 11 ---------------------------->
...
In the example above, segment 6 is lost and the sender retransmits it after three duplicate ACKs in step 8. However, the retransmission is also lost, and the sender has to wait for the RTO to expire before retransmitting it again. Because the first ACK following the RTO retransmission acknowledges the RTO retransmission (step 14), the sender transmits two new segments. The second ACK in step 17 does not acknowledge any previously unacknowledged data. Therefore, the F-RTO sender enters the slow start and sets cwnd to 3 * MSS. The congestion window can be set to three segments, because two round-trips have elapsed after the retransmission timeout. Finally, the receiver acknowledges all segments transmitted prior to entering recovery and the sender can continue transmitting new data in congestion avoidance.
上記の例では、セグメント6が失われ、送信側はしかし、再送も失われ、ステップ8三個の重複ACKの後にそれを再送信し、送信側がRTOは再びそれを再送信する前に期限切れに待たなければなりません。 RTO再送続く最初のACKがRTO再送（ステップ14）を認めているため、送信者は、2つの新しいセグメントを送信します。ステップ17における第二のACKは、以前に未確認のデータを認識しません。したがって、F-RTOの送信者は、3 * MSSにcwndをスロースタートとセットに入ります。 2往復が再送タイムアウト後の経過しているので、輻輳ウィンドウは、三つのセグメントに設定することができます。最後に、受信機は前の回復と輻輳回避に新しいデータを送信し続けることができ、送信者に入るに送信すべてのセグメントを認めています。
A.3. Link Outage
A.3。リンク停止
The example below illustrates the F-RTO behavior when 4 consecutive packets are lost in the network causing the TCP sender to fall back to RTO recovery. Limited transmit and SACK are not used in this example.
以下の例では、4つの連続したパケットがTCPの送信側がバックRTO回復にフォールさせるネットワークで失われているF-RTOの挙動を示しています。リミテッド送信およびSACKは、この例で使用されていません。
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
<segments 6-9 lost>
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
5. <---------------------------- ACK 6
|
|
[RTO]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
7. <---------------------------- ACK 7
[F-RTO step (2b)]
8. SEND 12 ---------------------------->
9. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
10. <---------------------------- ACK 7
[F-RTO step (3a)]
[SpuriousRecovery <- FALSE]
(cwnd = 3, ssthresh = 3, FlightSize = 7)
11. SEND 7 ---------------------------->
12. SEND 8 ---------------------------->
13. SEND 9 ---------------------------->
Again, F-RTO sender transmits two new segments (steps 8 and 9) after the RTO retransmission is acknowledged. Because the next ACK does not acknowledge any data that was not retransmitted after the retransmission timeout (step 10), the F-RTO sender proceeds with conventional recovery and slow start retransmissions.
RTO再送が確認された後、再び、F-RTOの送信者は、2つの新しいセグメント（ステップ8,9）を送信します。次のACKは、再送タイムアウト（ステップ10）の後に再送されなかったデータ、従来の回復とスロースタート再送を伴うF-RTOの送信者が進行を認めていないため。
A.4. Packet Reordering
A.4。パケットの順序変更
Because F-RTO modifies the TCP sender behavior only after a retransmission timeout and it is intended to avoid unnecessary retransmissions only after spurious timeout, we limit the discussion on the effects of packet reordering on F-RTO behavior to the cases where it occurs immediately after the retransmission timeout. When the TCP receiver gets an out-of-order segment, it generates a duplicate ACK. If the TCP sender implements the basic F-RTO algorithm, this may prevent the sender from detecting a spurious timeout.
F-RTOのみ再送タイムアウト後にTCPの送信側の動作を変更すると、唯一のスプリアスタイムアウトの後、不要な再送を避けるために意図されているので、我々はそれが直後に発生した場合にF-RTOの行動に並べ替え、パケットの影響に関する議論を制限します再送タイムアウト。 TCP受信機がアウト・オブ・オーダのセグメントを取得したときに、それは重複ACKを生成します。 TCPの送信者は、基本的なF-RTOアルゴリズムを実装している場合、これはスプリアスタイムアウトを検出してから送信者を防ぐことができます。
However, if the TCP sender applies the SACK-enhanced F-RTO, it is possible to detect a spurious timeout when packet reordering occurs. Below, we illustrate the behavior of SACK-enhanced F-RTO when segment 8 arrives before segments 6 and 7, and segments starting from segment 6 are delayed in the network. In this example the TCP sender reduces the congestion window and slow start threshold in response to spurious timeout.
TCPの送信者はSACK強化F-RTOを適用する場合は、そのパケットの並べ替えが発生したときにスプリアスタイムアウトを検出することが可能です。セグメント8は、ネットワーク内で遅延されたセグメント6から出発したセグメント6,7、およびセグメントの前に到着したとき、以下に、我々はSACK増強F-RTOの挙動を示します。この例では、TCPの送信者は、スプリアスタイムアウトに応じて輻輳ウィンドウとスロースタートしきい値を低減します。
...
(cwnd = 6, ssthresh < 6, FlightSize = 6)
1. <---------------------------- ACK 5
2. SEND 10 ---------------------------->
(cwnd = 6, ssthresh < 6, FlightSize = 6)
3. <---------------------------- ACK 6
4. SEND 11 ---------------------------->
5. |
[delay]
|
[RTO]
6. SEND 6 ---------------------------->
(cwnd = 6, ssthresh = 3, FlightSize = 6)
<earlier xmitted SEG 8> --->
7. <---------------------------- ACK 6
[SACK 8]
[SACK F-RTO stays in step 2]
8. <earlier xmitted SEG 6> --->
9. <---------------------------- ACK 7
[SACK 8]
[SACK F-RTO step (2b)]
10. SEND 12 ---------------------------->
11. SEND 13 ---------------------------->
(cwnd = 7, ssthresh = 3, FlightSize = 7)
12. <earlier xmitted SEG 7> --->
13. <---------------------------- ACK 9
[SACK F-RTO step (3b)]
[SpuriousRecovery <- SPUR_TO]
(cwnd = 7, ssthresh = 6, FlightSize = 6)
14. SEND 14 ---------------------------->
(cwnd = 7, ssthresh = 6, FlightSize = 7)
15. <---------------------------- ACK 10
16. SEND 15 ---------------------------->
...
After RTO expires and the sender retransmits segment 6 (step 6), the receiver gets segment 8 and generates duplicate ACK with SACK for segment 8. In response to the acknowledgment, the TCP sender does not send anything but stays in F-RTO step 2. Because the next acknowledgment advances the cumulative ACK point (step 9), the sender can transmit two new segments according to SACK-enhanced F-RTO. The next segment acknowledges new data between 7 and 11 that was not acknowledged earlier (segment 7), so the F-RTO sender declares the timeout spurious.
RTOが満了すると送信側がセグメント6（ステップ6）再送信、受信機は、セグメント8を取得し、確認応答に応答して、セグメント8のSACKと重複ACKを生成した後に、TCP送信者はF-RTO工程2に留まるが、何も送信しません次の確認応答が累積ACK点（ステップ9）を進めるため、送信者はSACK増強F-RTOに応じて二つの新しいセグメントを送信することができます。次のセグメントは、（セグメント7）以前認め、そうF-RTOの送信者がスプリアスタイムアウトを宣言していないし7と11の間で新たなデータを認識しています。
Appendix B: SACK-enhanced F-RTO and Fast Recovery
付録B：SACK-強化F-RTOおよび高速リカバリ
We believe that a slightly modified, SACK-enhanced F-RTO algorithm can be used to detect spurious timeouts also when RTO expires while an earlier loss recovery is underway. However, there are issues that need to be considered if F-RTO is applied in this case.
我々はわずかに変更され、SACKが強化されたF-RTOアルゴリズムは、以前の損失回復が進行している間、RTOが満了したときにも、スプリアスタイムアウトを検出するために使用することができると信じています。しかし、F-RTOが、この場合に適用された場合に考慮する必要がある問題があります。
In step 3, the original SACK-based F-RTO algorithm requires that an ACK acknowledges previously unacknowledged non-retransmitted data between SND.UNA and send_high. If RTO expires during earlier (SACK-based) loss recovery, the F-RTO sender must use only acknowledgments for non-retransmitted segments transmitted before the SACK-based loss recovery started. This means that in order to declare timeout spurious, the TCP sender must receive an acknowledgment for non-retransmitted segment between SND.UNA and RecoveryPoint in algorithm step 3. RecoveryPoint is defined in conservative SACK-recovery algorithm [BAFW03], and it is set to indicate the highest segment transmitted so far when SACK-based loss recovery begins. In other words, if the TCP sender receives acknowledgment for a segment that was transmitted more than one RTO ago, it can declare the timeout spurious. Defining an efficient algorithm for checking these conditions remains a future work item.
ステップ3において、元のSACKベースのF-RTOアルゴリズムは、ACKがSND.UNAとsend_high間で以前に認められていない非再送データを認識することを必要とします。 RTOは、以前の（SACKベース）の損失回復の間に期限切れになった場合、F-RTOの送信者はSACKベースの損失回復を開始する前に送信された非再送セグメントに対してのみ確認応答を使用する必要があります。これは、スプリアスタイムアウトを宣言するために、TCP送信者は3 RecoveryPointは保守的SACK-回復アルゴリズム[BAFW03]で定義されるアルゴリズムのステップでSND.UNAとRecoveryPoint間の非再送セグメントに対する確認応答を受信する必要があり、それが設定されていることを意味しますこれまでSACKベースの損失回復が始まる時に送信最高のセグメントを示します。 TCPの送信側が受信した場合、他の言葉では、送信されたセグメントに対する確認応答に複数のRTO前に、それはスプリアスタイムアウトを宣言することができます。これらの状態をチェックするための効率的なアルゴリズムを定義することは、将来の作業項目のまま。
When spurious timeout is detected according to the rules given above, it may be possible that the response algorithm needs to consider this case separately, for example, in terms of which segments to retransmit after RTO expires, and whether it is safe to revert the congestion control parameters. This is considered a topic for future research.
スプリアスタイムアウトが上記所定の規則に従って検出された場合、応答アルゴリズムはRTOが満了した後に再送信するためにどのセグメントの点で、例えば、別々にこのケースを検討する必要があること、および輻輳を戻すために安全であるかどうかを可能とすることができます制御パラメータ。これは、今後の研究の課題と考えられています。
Appendix C: Discussion of Window-Limited Cases
付録C：ウィンドウ-限られたケースの議論
When the advertised window limits the transmission of two new previously unsent segments, or there are no new data to send, it is recommended in F-RTO algorithm step (2b) that the TCP sender continue with the conventional RTO recovery algorithm. The disadvantage is that the sender may continue unnecessary retransmissions due to possible spurious timeout. This section briefly discusses the options that can potentially improve performance when transmitting previously unsent data is not possible.
広告ウィンドウは、2つの新しい以前に未送信のセグメントの送信を制限するか、または送信する新しいデータが存在しない場合は、TCP送信者は、従来のRTO回復アルゴリズムを継続することをF-RTOアルゴリズムステップ（2B）で推奨されています。欠点は、送信者が原因の可能スプリアスタイムアウトに不要な再送を続けることです。このセクションでは、簡単にはできません以前に未送信データを送信する際に潜在的にパフォーマンスを向上させることができますオプションについて説明します。
- The TCP sender could reserve an unused space of a size of one or two segments in the advertised window to ensure the use of algorithms such as F-RTO or Limited Transmit [ABF01] in window-limited situations. On the other hand, while doing this, the TCP sender should ensure that the window of outstanding segments is large enough for proper utilization of the available pipe.
- TCP送信者は、ウィンドウ・限られた状況において、このようなF-RTOまたは限定された送信などのアルゴリズム[ABF01]の使用を確実にするために広告ウィンドウ内の一つまたは二つのセグメントのサイズの未使用スペースを確保できました。一方、これをやっている間、TCPの送信者は、優れたセグメントのウィンドウが使用可能なパイプの適切な利用のために十分な大きさであることを確認する必要があります。
- Use additional information if available, e.g., TCP timestamps with the Eifel Detection algorithm, for detecting a spurious timeout. However, Eifel detection may yield different results from F-RTO when ACK losses and an RTO occur within the same round-trip time [SKR03].
- 利用追加情報利用可能な場合には、例えば、TCPは、スプリアスタイムアウトを検出するため、アイフェル検出アルゴリズムを用いてタイムスタンプ。 ACK損失とRTOが同じラウンドトリップ時間[SKR03]内で発生した場合しかし、アイフェル検出は、F-RTOは異なる結果をもたらすことができます。
- Retransmit data from the tail of the retransmission queue and continue with step 3 of the F-RTO algorithm. It is possible that the retransmission will be made unnecessarily. Thus, this option is not encouraged, except for hosts that are known to operate in an environment that is prone to spurious timeouts. On the other hand, with this method it is possible to limit unnecessary retransmissions due to spurious timeout to one retransmission.
- 再送信データ再送キューの最後尾からとF-RTOアルゴリズムのステップ3に進みます。再送信が不必要に行われることも可能です。したがって、このオプションはスプリアスタイムアウトが発生しやすい環境で動作することが知られているホストを除き、奨励されていません。一方、この方法では、一つの再送に起因するスプリアスタイムアウトに不要な再送信を制限することが可能です。
- Send a zero-sized segment below SND.UNA, similar to TCP Keep-Alive probe, and continue with step 3 of the F-RTO algorithm. Because the receiver replies with a duplicate ACK, the sender is able to detect whether the timeout was spurious from the incoming acknowledgment. This method does not send data unnecessarily, but it delays the recovery by one round-trip time in cases where the timeout was not spurious. Therefore, this method is not encouraged.
- SND.UNA以下ゼロサイズのセグメントを送信し、同様のキープアライブプローブをTCP、およびF-RTOアルゴリズムのステップ3に進みます。受信機が重複ACKで応答するため、送信者は、タイムアウトが受信確認応答からのスプリアスであったかどうかを検出することができます。この方法では、不必要にデータを送信しませんが、それはタイムアウトが偽りではなかった場合に1往復時間で回復を遅らせます。したがって、この方法は推奨されません。
- In receiver-limited cases, send one octet of new data, regardless of the advertised window limit, and continue with step 3 of the F-RTO algorithm. It is possible that the receiver will have free buffer space to receive the data by the time the segment has propagated through the network, in which case no harm is done. If the receiver is not capable of receiving the segment, it rejects the segment and sends a duplicate ACK.
- 受信制限のケースでは、関係なく、広告ウィンドウ限界の、新たなデータの1つのオクテットを送信し、F-RTOアルゴリズムのステップ3に進みます。受信機は害が行われない、その場合、セグメントは、ネットワークを介して伝播した時点でデータを受信するためのフリーバッファスペースを有することが可能です。受信機は、セグメントを受信可能でない場合は、セグメントを拒否し、重複ACKを送信します。
Authors' Addresses
著者のアドレス
Pasi Sarolahti Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP Finland
パシSarolahtiノキア・リサーチセンター私書箱ボックス407 FIN-00045 NOKIA GROUPフィンランド
Phone: +358 50 4876607 EMail: pasi.sarolahti@nokia.com http://www.cs.helsinki.fi/u/sarolaht/
電話番号：+358 50 4876607 Eメール：pasi.sarolahti@nokia.com http://www.cs.helsinki.fi/u/sarolaht/
Markku Kojo University of Helsinki Department of Computer Science P.O. Box 68 FIN-00014 UNIVERSITY OF HELSINKI Finland
コンピュータサイエンスのヘルシンキ部門のマルック古城大学私書箱ヘルシンキ、フィンランドの箱68 FIN-00014 UNIVERSITY
Phone: +358 9 191 51305 EMail: kojo@cs.helsinki.fi
電話：+358 9 191 51305 Eメール：kojo@cs.helsinki.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。