[要約] RFC 4138は、TCPとSCTPで虚偽の再送タイムアウトを検出するためのアルゴリズムである。その目的は、ネットワークの遅延やパケットのロスによる誤った再送タイムアウトを避け、通信のパフォーマンスを向上させることである。
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)
Forward RTO-Recovery（F-RTO）：TCPおよび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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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 Senderのみのアルゴリズムです。タイムアウトによってトリガーされた最初の未承認セグメントを再送信した後、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]を再送信し、NewReno [FHG04]やサックベースの損失回復[BAFW03]などの損失回復アルゴリズムを継続します。第二に、TCP送信者は、再送信タイムアウト（RTO）の有効期限が切れる前に認められていない場合、セグメントの再送信をトリガーする再送信タイマーを維持します。再送信タイムアウトが発生すると、TCP送信者はRTO回復に入り、そこでは輻輳ウィンドウが1つのセグメントに初期化され、スロースタートアルゴリズムを使用して再刻まれていないセグメントが再送信されます。再送信タイマーは、測定された往復時間[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送信者は、遅いスタートで各遅い謝辞の輻輳ウィンドウを増やします。これにより、1回の往復時間内に多数のデータセグメントがネットワークに注入されるため、パケット保存原則[JAC88]に違反します。
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-Recovery」（F-RTO）アルゴリズム[SKR03]の検出メカニズムに基づいており、偽りの再送信のタイムアウトを検出するために使用されるため、再送信時に不必要な再送信を回避します。タイムアウトがスプリアスでない場合、F-RTOアルゴリズムは従来のRTO回復アルゴリズムに戻るため、同様の動作とパフォーマンスがあります。不必要な再送信（EIFEL [LK00]、[LM03]およびDSACKベースのアルゴリズム[BA04]）を検出するために提案された代替アルゴリズムとは対照的に、F-RTOはその動作にTCPオプションを必要としません。TCP送信者。EIFELアルゴリズムは、TCPタイムスタンプ[BBJ92]を使用して、再送信後の最初の承認の到着時に偽のタイムアウトを検出します。DSACKベースのアルゴリズムでは、DSACK拡張[FMMP00]を使用して、TCP選択的確認オプション[MMFR96]が使用されていることが必要です。DSACKを使用すると、TCPレシーバーは重複セグメントを受け取ったかどうかを報告でき、送信者が不必要に再送信されたかどうかをその後検出できます。F-RTOアルゴリズムは、RTO後の不必要な再送信の検出と回避を試みます。Eifelと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 SACK-enhanced version of the F-RTO algorithm, spurious timeouts may be detected even if duplicate ACKs arrive after an RTO retransmission.
RTOの有効期限が切れると、F-RTO送信者は通常のように最初の未承認セグメントを再送信します[APS99]。タイムアウト後の通常の操作から逸脱して、その後、新しい以前に安全でないデータを送信しようとします。これは、承認がウィンドウを進めることを考慮して、タイムアウト後に到着する最初の謝辞のために送信しようとします。タイムアウトの後に到着する2番目の承認がウィンドウを進行した場合（つまり、再送信されていないデータを認めます）、F-RTO送信者はタイムアウトのスプリアスを宣言し、RTO回復を終了します。ただし、これら2つの謝辞のいずれかが重複したACKである場合、偽のタイムアウトの十分な証拠はありません。したがって、F-RTO送信者は、従来のアルゴリズムと同様に、スローの未承認セグメントを再送信します。F-RTOアルゴリズムのサック強化バージョンでは、RTOの再送信後に重複したAcksが到着した場合でも、偽のタイムアウトが検出される場合があります。
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.
F-RTOアルゴリズムは、SCTPにはTCPと同様の認識とパケット再送信の概念があるため、ストリーム制御伝送プロトコル（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サックオプションを活用するF-RTOアルゴリズムのオプションの拡張の概要を説明します。セクション4では、偽のRTOを検出した後に実行される可能性のあるアクションについて説明します。セクション5では、F-RTOをSCTPに適用することに関する考慮事項を示し、セクション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]に記載されているように解釈される場合、このドキュメントに表示される場合、キーワードは必要、必要は、推奨される、推奨する、推奨することはできません。
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.
EIFEL検出アルゴリズム[LM03]で使用されたプラクティスに続いて、「SpouriousRecovery」変数を使用して、送信が送信者によって偽物と宣言されるかどうかを示します。この変数は、対応する応答アルゴリズムの入力として使用できます。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アルゴリズムを実装できます。アルゴリズムを適用することを選択した場合、再送信タイマーの有効期限が切れた後、次の手順を実行する必要があります。送信者がRenoまたは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".
1) RTOが期限切れになったら、最初の未承認のセグメントを再送信し、SpuriousRecoveryをFalseに設定します。また、これまでに送信された最高のシーケンス番号を変数「回復」に保存します。
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.
2) RTOの再送信が送信者に到着した後の最初の承認が、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を入力しないでください。SpouriousRecovery変数は虚偽のままです。
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送信者に十分な不明なデータがない場合、1つのセグメントのみを送信できます。さらに、TCP送信者は、Nagleアルゴリズム[Nag84]をオーバーライドし、必要に応じてすぐにセグメントを送信する場合があります。このステップで2つのセグメントを送信することは、TCP混雑制御要件[APS99]によって許可されることに注意してください。F-RTO TCP送信者は、送信するさまざまなセグメントを選択するだけです。
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の再送信が送信者に到着した後の2番目の謝辞は、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.
a) 確認が重複したACKである場合は、輻輳ウィンドウを3 * MSS以下に設定し、未承認のセグメントを再送信するスロースタートアルゴリズムを続行します。RTO以来2つの往復時間が経過しており、従来のTCP送信者が同時にCWNDを3に増加させるため、輻輳ウィンドウは3 * MSSに設定できます。SpuariousRecoveryを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に偽のレッケーを設定し、「回復」変数の値を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）の「回復」ポイントをカバーしている場合、タイムアウト後に非再配置セグメントが受信機に到着したという十分な証拠がありません。これは、迅速な再送信が失われ、RTOの後に再び再送信された場合の一般的なケースであり、残りの承認されていないセグメントは再送信タイムアウトの前にTCPレシーバーに正常に配信されました。したがって、この場合、タイムアウトを偽物と宣言することはできません。
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送信者は、従来のTCP送信者がRTOの再送信後に最初の新しいACKが到着したときに2つのセグメントを送信するため、アルゴリズムブランチ（2B）に2つの新しいセグメントを送信できます。アルゴリズムブランチ（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送信者は、高速再送信を可能にするために、snd.unaに「回復」変数の値を設定します[FHG04]。NewReno TCPでの迅速な回復中にRTOが有効期限を切るときに、不必要な複数の高速再送信を回避するために、「回復」変数が提案されました。送信者はタイムアウトをトリガーしたセグメントのみを再送信するため、不必要な複数の高速再送信[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送信者が輻輳制御ルールに違反する可能性が少しあります。EIFEL検出アルゴリズムには同様のプロパティがありますが、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送信者は、偽のタイムアウトを検出した後、不必要な再送信のほとんどを回避できるため、送信者は遅延セグメントで往復時間サンプルを採取することができます。TCPタイムスタンプなしで通常のRTO回復を使用した場合、再送信のあいまいさのためにこれは不可能です。その結果、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 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アルゴリズムが偽りのタイムアウト後に不必要な再送信を回避できない状況がいくつかあります。スプリアスタイムアウトをトリガーしたセグメントでパケットの並べ替えまたはパケットの複製が発生した場合、F-RTOアルゴリズムは、重複するACKの発生によりスプリアスタイムアウトを検出しない場合があります。さらに、高速回復中にスプリアスタイムアウトが発生した場合、F-RTOアルゴリズムは、高速回復の前に送信されたセグメントが複製ACKをトリガーするため、スプリアスタイムアウトを検出できないことがよくあります。ただし、これらのケースはまれであると考えており、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の再送信後に送信されなかった新しいデータを確認した場合、送信者は、Acksが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接続に対してTCP Selective Auncemenceオプション[MMFR96]が有効になっていることを考えると、TCP送信者はSack強化F-RTOアルゴリズムを実装できます。送信者がサック強化F-RTOアルゴリズムを適用する場合、以下の手順に従う必要があります。再送信タイムアウトが発生したときにTCP送信者がすでに袋損失回復中である場合、このアルゴリズムは適用しないでください。ただし、既存の損失回復中に再送信タイムアウトが発生した場合、特定の制限内でF-RTOの原則を適用することが可能です。これは、さらなる研究のトピックです。付録Bでは、関連する問題について簡単に説明します。
The steps of the SACK-enhanced version of the F-RTO algorithm are as follows.
F-RTOアルゴリズムのサック強化バージョンの手順は次のとおりです。
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.
1) RTOの有効期限が切れたら、最初の未承認のセグメントを再送信し、偽の回収をfalseに設定します。変数「回復」を設定して、これまでに送信された最高のセグメントを示します。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が到着した場合は、着信サック情報に従ってスコアボードを調整します。ステップ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つの新しい（以前に安全でない）セグメントを送信し、ステップ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.
a) ACKがサックブロックまたは累積ACKのいずれかで「回復」上のシーケンス番号を認めている場合、輻輳ウィンドウを3 * MSS以下に設定し、従来のRTO回復を進め、未承認のセグメントを再送信します。謝辞が重複したACKであり、サックブロックの「回復」の下の新しい未装備のデータを認めない場合にもこのブランチを取ります。SpuariousRecoveryを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が「Recover」上のシーケンス番号を認めず、以前に認められなかったデータを認めている場合（累積的な承認または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.
受信したサックブロックの間に未充填の穴がある場合、これらのセグメントは、従来のサックリカバリアルゴリズム[BAFW03]と同様に再送信されます。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の有効期限が切れた後、SCTP送信者はTCPのようにスロースタートで未充填のデータチャンクを再送信します。したがって、SCTPは、TCPと同様に、偽りの再送信タイムアウトの悪影響に対して脆弱です。同様のRTO回復アルゴリズムのため、F-RTOアルゴリズムロジックもSCTPにも適用できます。SCTPは選択的承認を使用するため、アルゴリズムのサックベースのバリアントが推奨されますが、基本バージョンはSCTPにも適用できます。ただし、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協会がマルチホームであり、再送信が代替アドレスに送られる場合、混雑制御に対する保守的な行動をとることをお勧めします。重複したTSNSの情報は、必要に応じて、輻輳制御を戻すために使用できます[BA04]。
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の再送信を受信した後、レシーバーが1つのセグメントのみを認め、残りのセグメントを認めている場合、タイムアウトがそうでない場合は偽りと宣言される可能性があります。したがって、速い回復段階で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.
フィードバックがこのテキストに貢献しました。
[APS99] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[APS99] Allman、M.、Paxson、V。、およびW. Stevens、「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] Blanton、E.、Allman、M.、Fall、K。、およびL. Wang、「TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム」、RFC 3517、2003年4月。
[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月。
[FHG04] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 3782, April 2004.
[FHG04] Floyd、S.、Henderson、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] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Ascondage Options」、RFC 2018、1996年10月。
[PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[PA00] Paxson、V。およびM. Allman、「TCPの再送信タイマーのコンピューティング」、RFC 2988、2000年11月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[POS81] Postel、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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、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] Allman、M.、Balakrishnan、H。、およびS. Floyd、「限定送信を使用したTCPの損失回復の強化」、RFC 3042、2001年1月。
[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] Blanton、E。およびM. Allman、「TCPを使用して、選択的承認（DSACK）およびストリーム制御伝送プロトコル（SCTP）重複透過シーケンス番号（TSNS）を使用して、スプリアスな再送信を検出する」、RFC 3708、2004年2月。
[BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[BBJ92] Jacobson、V.、Braden、R。、およびD. Borman、「高性能のための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] Floyd、S.、Mahdavi、J.、Mathis、M。、およびM. Podolsky、「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.ガルトフとR.ルートヴィヒ。GPRSネットワークでのTCPのeifelアルゴリズムの評価。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. Ludwig、TCPでのスプリアスタイムアウトに対応。2003年3月、米国カリフォルニア州サンフランシスコのIEEE Infocom 03の議事録。
[Jac88] V. Jacobson. Congestion Avoidance and Control. In Proceedings of ACM SIGCOMM 88.
[Jac88] V.ジェイコブソン。混雑の回避と制御。ACM Sigcomm88の議事録。
[LG04] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm for TCP", RFC 4015, February 2005.
[LG04] Ludwig、R。およびA. Gurtov、「TCPのEIFEL応答アルゴリズム」、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.カッツ。EIFELアルゴリズム：スプリアスな再送信に対してTCPを堅牢にする。ACM Sigcomm Computer Communication Review、30（1）、2000年1月。
[LM03] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for TCP", RFC 3522, April 2003.
[LM03] Ludwig、R。およびM. Meyer、「TCPのEIFEL検出アルゴリズム」、RFC 3522、2003年4月。
[Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC 896, January 1984.
[Nag84] Nagle、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。Kojo、およびK. Raatikainen。F-RTO：TCP再送信タイムアウトの拡張回復アルゴリズム。ACM Sigcomm Computer Communication Review、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 Globecom 2003の議事録、米国カリフォルニア州サンフランシスコ。2003年12月。
[SL03] Y. Swami and K. Le, "DCLOR: De-correlated Loss Recovery using SACK Option for Spurious Timeouts", work in progress, September 2003.
[SL03] Y. SwamiおよびK. Le、「Dclor：Spourious TimeoutのSackオプションを使用した相関損失の回復」、2003年9月、進行中の作業。
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].
このセクションでは、RTOが発生する場所と、基本的なF-RTOアルゴリズムがこれらのシナリオでどのように機能するかについて説明します。興味深いシナリオは、再送信のタイムアウトをトリガーする突然の遅延、迅速な回復中の再送信パケットの喪失、リンクの停止により、複数のパケットの喪失を引き起こすリンクの停止、およびパケットの並べ替えがあります。F-RTOの実際の実装に関するより徹底的な分析を伴うパフォーマンス評価は、[SKR03]に記載されています。
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エンドホストによって送信されるセグメントと謝辞を示していますが、パケットは失われていません。簡単にするために、遅延承認は例では使用されません。以下の例は、スプリアスタイムアウトを検出した後のEIFEL応答アルゴリズム[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) ...
11. 14を送信------------------------------>（cwnd = 7、ssthresh = 6、flightsize = 7）12。<---------------------------- ACK 9 13. 15を送信------------------------------------------------------->（cwnd = 7、ssthresh = 6、flightsize = 7）14。<----------------------------------------------------------------------------------------- ACK 10 15. 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）を再送信します。次のACKは、元々送信されたセグメント6が受信機に到着し、TCP送信者が2つの新しいデータセグメントを送信することで継続するため、RTOの再送信をカバーします（ステップ8、9）。F-RTOステップ（1）および（2B）では、輻輳ウィンドウとフライトサイズはまだリセットされていないことに注意してください。スプリアスタイムアウトの場合、タイムアウトの前に送信されるセグメントはまだネットワーク内にあるためです。ただし、送信者は、従来のTCPに対しても同様に攻撃的である必要があります。RTOの再送信後に到着した2番目の承認は、タイムアウトのために再送信されなかったデータを認めているため（ステップ10）、TCP送信者はタイムアウトが偽りであると宣言し、次の謝辞に新しいデータを送信することで継続します。また、eifel応答アルゴリズムで要求されるように、輻輳制御状態は逆転します。
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で3つの重複したAcksの後にそれを再送信します。ただし、再送信も失われ、送信者は再び再送信する前にRTOが期限切れになるのを待たなければなりません。RTOの再送信に続く最初のACKはRTOの再送信を認めているため（ステップ14）、送信者は2つの新しいセグメントを送信します。ステップ17の2番目のACKは、以前に未把持されていないデータを認めていません。したがって、F-RTO送信者はスロースタートに入り、CWNDを3 * MSSに設定します。再送信タイムアウト後に2つのラウンドトリップが経過したため、輻輳ウィンドウを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回復に戻るとFRTOの動作を示しています。この例では、限られた送信と袋は使用されていません。
...
(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.
繰り返しますが、F-RTO送信者は、RTOの再送信が認められた後、2つの新しいセグメント（ステップ8および9）を送信します。次のACKは、再送信タイムアウト後に再送信されなかったデータを認めていないため（ステップ10）、F-RTO送信者は従来の回復とスロースタートの再送信を獲得します。
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送信者がサック強化F-RTOを適用すると、パケットの再注文が発生したときにスプリアスタイムアウトを検出することができます。以下では、セグメント8がセグメント6および7の前に到着し、セグメント6から始まるセグメントがネットワークで遅れている場合、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のサックで重複したACKを生成します。確認に応じて、TCP送信者はF-RTOのステップ2に留まる以外に何も送信しません。。次の承認は累積ACKポイント（ステップ9）を進めるため、送信者はSack強化されたF-RTOに従って2つの新しいセグメントを送信できます。次のセグメントは、7〜11の間の新しいデータを認めていますが、これは以前に認められていませんでした（セグメント7）ため、F-RTO送信者はタイムアウトのスプリアスを宣言します。
Appendix B: SACK-enhanced F-RTO and Fast Recovery
付録B：サック強化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.
以前の損失回復が進行中にRTOが期限切れになったときにも、わずかに変更されたサック強化F-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の間に以前に承認されていない非再送信データを確認する必要があります。以前の（SACKベースの）損失回復中にRTOが期限切れになった場合、F-RTO送信者は、サックベースの損失回復が開始される前に送信される非再配置セグメントの謝辞のみを使用する必要があります。これは、タイムアウトの偽物を宣言するために、TCP送信者は、アルゴリズムステップ3のSND.UNAとRecoveryPointの間の非再配偶者セグメントの承認を受け取る必要があります。RecoveryPointは保守的なサック回収アルゴリズム[BAFW03]で定義されており、設定されています。サックベースの損失回復が始まるときにこれまでに伝達された最高のセグメントを示すため。言い換えれば、TCP送信者が1回以上前に送信されたセグメントの謝辞を受け取った場合、タイムアウトをスプリアスと宣言できます。これらの条件をチェックするための効率的なアルゴリズムを定義することは、将来の作業項目のままです。
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送信者は、広告ウィンドウに1つまたは2つのセグメントのサイズの未使用スペースを予約して、F-RTOやLimited送信[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].
- 利用可能な場合は、eifel検出アルゴリズムを備えたTCPタイムスタンプなどの追加情報を使用して、偽のタイムアウトを検出します。ただし、ACKの損失とRTOが同じ往復時間内に発生すると、EIFEL検出がF-RTOから異なる結果をもたらす可能性があります[SKR03]。
- 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で続行します。再送信が不必要に行われる可能性があります。したがって、このオプションは、偽のタイムアウトになりやすい環境で動作することが知られているホストを除き、奨励されていません。一方、この方法では、1回の再送信へのスプリアスタイムアウトのために不必要な再送信を制限することができます。
- 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.
- TCP Keep-Alive Probeと同様に、SND.UNAの下にゼロサイズのセグメントを送信し、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
Pasi Sarolahti Nokia Research Center P.O.Box 407 Fin-00045 Nokia Group Finland
Phone: +358 50 4876607
EMail: 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
ヘルシンキ大学コンピュータサイエンス大学マルクコホ校P.O.ボックス68フィン-00014ヘルシンキフィンランド大学
Phone: +358 9 191 51305
EMail: kojo@cs.helsinki.fi
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。