RFC4138 日本語訳
4138 Forward RTO-Recovery (F-RTO): An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and the Stream Control TransmissionProtocol (SCTP). P. Sarolahti, M. Kojo. August 2005. (Format: TXT=55538 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Sarolahti
Request for Comments: 4138 Nokia Research Center
Category: Experimental M. Kojo
University of Helsinki
August 2005
Sarolahtiがコメントのために要求するワーキンググループP.をネットワークでつないでください: 4138年のノキアリサーチセンターカテゴリ: ヘルシンキ2005年8月の実験的なM.Kojo大学
Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP and the
Stream Control Transmission Protocol (SCTP)
RTO-回復(F-RTO)を進めてください: TCPがある偽りの再送タイムアウトを検出するためのアルゴリズムと流れの制御伝動プロトコル(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).
Copyright(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性能を向上させます。 また、Stream Control Transmissionプロトコル(SCTP)にF-RTOアルゴリズムを適用できます。
Sarolahti & Kojo Experimental [Page 1] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[1ページ]RFC4138は2005年8月にRTO-回復を進めます。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . 2 1.1。 用語. . . . . . . . . . . . . . . . . . . . 4 2。 F-RTOアルゴリズム. . . . . . . . . . . . . . . . . . . . . 4 2.1。 アルゴリズム. . . . . . . . . . . . . . . . . . . 5 2.2。 議論. . . . . . . . . . . . . . . . . . . . 6 3。 F-RTOアルゴリズム. . . . . . 8 4の袋で高められたバージョン。 偽物のRTO. . . . . . . 10 5を検出した後に、行動を取ります。 SCTP問題. . . . . . . . . . . . . . . . . . . 10 6。 セキュリティ問題. . . . . . . . . . . . . . . . . 11 7。 承認. . . . . . . . . . . . . . . . . . . . 12 8。 参照. . . . . . . . . . . . . . . . . . . . . . . 12 8.1。 引用規格。 . . . . . . . . . . . . . . . 12 8.2. 有益な参照。 . . . . . . . . . . . . . . 13 付録A: シナリオ. . . . . . . . . . . . . . . . . . . . 15付録B: 袋で高められたF-RTOと速い回復. . . . . . 20付録C: ウィンドウ株式会社ケース. . . . . . . 21の議論
1. Introduction
1. 序論
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送付者は入って来る写しACKsを当てにします。(ACKsは、受信機がいくつかのデータを逃しているのを示します)。 連続した写しACKsの必要な数が送付者に到着した後に、それは、最初の不承認のセグメント[APS99]を再送して、NewRenoなどの損失回復アルゴリズム[FHG04]かSACKベースの損失回復[BAFW03]を続行します。 2番目に、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送付者は遅れた出発におけるそれぞれの遅い承認の混雑ウィンドウを増加させます。 これは往復の1回の以内に多くのデータ・セグメントをネットワークに注ぎます、その結果、パケット保護原則[Jac88]に違反します。
Sarolahti & Kojo Experimental [Page 2] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[2ページ]RFC4138は2005年8月にRTO-回復を進めます。
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.
偽りの再送タイムアウトの多くの潜在的理由があります。 いくつかの可動のネットワーク・テクノロジーがトランスミッションのときにまず最初に、ハンドオフの間に取られた行動のために突然の遅れスパイクを伴います。 2番目に、低バンド幅リンクか利用可能な帯域幅のある他の変化を考えて、競争している交通(ことによるとより高い優先度がある)の到着は往復の時間の急増を引き起こす場合があります。 これは偽りの再送タイムアウトの引き金となるかもしれません。 また、それのデータフレームと数個の「再-トランスミッション」がある理由でなくされているとき、持続して信頼できるリンクレイヤは突然の遅れを引き起こす場合があります。 このドキュメントはそのような遅れスパイクの異なった原因を見分けません。 むしろ、それは一般に、遅れスパイクで引き起こされた偽りの再送タイムアウトについて議論します。
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送付者だけを変更することによって、それは実行できます。 アイフェル高原アルゴリズムは、「再-トランスミッション」の後に最初の承認の到着に偽りのタイムアウトを検出するのに、TCPタイムスタンプ[BBJ92]を使用します。 DSACKベースのアルゴリズムは、TCP Selective Acknowledgment Option[MMFR96]がDSACK拡張子[FMMP00]で使用中であることを必要とします。 写しセグメントを受けたなら、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]を再送します。 タイムアウトの後に通常操作から逸れて、次に、新しい状態で伝わろうとして、unsentデータであり最初の承認のために、それはタイムアウトの後に以前に到着します、承認が窓を進めるなら。 タイムアウトの後に到着する2番目の承認が窓(すなわち、再送されなかったデータを承認する)を進めるなら、F RTO送付者は、タイムアウトが偽りであると宣言して、RTO回復を出ます。 しかしながら、これらの2つの承認のどちらかが写しACKであるなら、偽りのタイムアウトの十分な証拠がないでしょう。 したがって、F-RTO送付者は遅れた出発で同様に伝統的なアルゴリズムに不承認のセグメントを再送します。 aで
Sarolahti & Kojo Experimental [Page 3] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[3ページ]RFC4138は2005年8月にRTO-回復を進めます。
SACK-enhanced version of the F-RTO algorithm, spurious timeouts may be detected even if duplicate ACKs arrive after an RTO retransmission.
写しACKsがRTO retransmissionの後に到着しても、F-RTOアルゴリズムのSACKによって高められたバージョン、偽りのタイムアウトは検出されるかもしれません。
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.
また、Stream Control Transmissionプロトコル(SCTP)[Ste00]にF-RTOアルゴリズムを適用できます、SCTPには承認とTCPと同様のパケット「再-トランスミッション」概念があるので。 便利について、このドキュメントは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を検出しながら似られるように可能な動作について論じます。 SCTPと共にF-RTOを適用するときセクション5は問題を与えます、そして、セクション6はセキュリティ問題について議論します。
1.1. Terminology
1.1. 用語
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]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
2. F-RTO Algorithm
2. F-RTOアルゴリズム
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.
アイフェル高原Detectionアルゴリズム[LM03]で使用される習慣に続いて、私たちは、「再-トランスミッション」が偽りであると送付者によって申告されるかどうかを示すのに"SpuriousRecovery"変数を使用します。 対応する応答アルゴリズムに入力としてこの変数を使用できます。 F-RTOと共に、SpuriousRecoveryの値は、シュプール_TO(偽りの再送タイムアウトを示す)かFALSEのどちらかであるかもしれません(タイムアウトが偽りであることは宣言されないのを示して)、そして、TCP送付者は従来のRTO回復アルゴリズムに従うべきです。
Sarolahti & Kojo Experimental [Page 4] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[4ページ]RFC4138は2005年8月にRTO-回復を進めます。
2.1. The Algorithm
2.1. アルゴリズム
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アルゴリズムSHOULD NOTを除いて、入られてください。
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が期限が切れるときには最初の不承認のセグメントを再送してください、そして、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.
2) RTO retransmissionの後の最初の承認が送付者に到着するとき、送付者は以下の動作の1つを選びます、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 ORであるなら、それは、遅れた出発でステップ1で再送されたデータのすべてを承認して、従来のRTO回復に戻って、不承認のデータを再送することによって続かないと「回復してください」というORの値と等しい一連番号に認めます。 このアルゴリズムのステップ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つの新しい(以前にunsentな)セグメントを送ってください、そして、このアルゴリズムのステップ3に入れてください。 TCP送付者に十分なunsentデータがないなら、それは1つのセグメントしか送ることができません。 さらに、必要であるなら、TCP送付者は、ネーグルアルゴリズム[Nag84]をくつがえして、すぐに、セグメントを送るかもしれません。 TCP輻輳制御要件[APS99]によってこのステップで2つのセグメントを送るのが許されていることに注意してください: 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回復アルゴリズムに従って。 しかしながら、Appendix 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 retransmissionの後の2番目の承認が送付者に到着するとき、TCP送付者は、タイムアウトが偽りであると宣言し始めるか、または不承認のセグメントを再送し始めます。
Sarolahti & Kojo Experimental [Page 5] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[5ページ]RFC4138は2005年8月にRTO-回復を進めます。
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だけに混雑ウィンドウを設定してください、そして、不承認のセグメントを再送しながら、遅れた出発アルゴリズムを続行してください。 3*MSSに混雑ウィンドウを設定できます、RTO以来往復の2回は経過しています、そして、従来のTCP送付者は同時間、cwndを3まで増加させたでしょう、したがって。 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) 承認が窓を進めるなら(すなわち、タイムアウトの後に再送されなかったデータを承認するなら)、タイムアウトが偽りであると宣言してください、そして、シュプール_TOにSpuriousRecoveryを設定してください、そして、SND.UNA(最も古い不承認の一連番号[Pos81])に「回復してください」という変数の値を設定してください。
2.2. Discussion
2.2. 議論
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送付者は用心深い行動を取ります。 写しACKsが、セグメントが失われたのを示すかもしれなくて、偽りのタイムアウトを確かに検出するのは追加情報の不足のために難しいです。 したがって、それらの場合における従来の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 retransmissionの後の最初の承認が「回復」を覆うなら、アルゴリズムステップを指し示してください。(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 retransmissionの後の最初の承認がステップ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
最初の新しいACKがRTO retransmissionの後に到着するとき、従来のTCP送付者は2つのセグメントを伝えるでしょう、したがって、TCP送付者がアルゴリズムブランチ(2b)で2つの新しいセグメントを送ることができます。 送付の新しいデータがアルゴリズムブランチ(2b)で可能でないか、または受信機の窓がトランスミッションを制限するなら、TCP送付者は、TCP転送が遅らせられるのを防ぐために何かを送らなければなりません。 セグメントを全く送らないなら、送付者と受信機の間のパイプはセグメントを使い果たすでしょうに、そして、さらなる承認は全く到着しないでしょう。 したがって、窓で限られた場合には、推薦があります。
Sarolahti & Kojo Experimental [Page 6] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[6ページ]RFC4138は2005年8月にRTO-回復を進めます。
revert to the conventional RTO recovery with slow start retransmissions. Appendix C discusses some alternative solutions for window-limited situations.
遅れた出発「再-トランスミッション」に従った従来の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]を再送してください。 RTOが速い回復の間、NewReno TCPと共に期限が切れると、倍数は、「回復してください」という変数が避けるために不要な状態で提案されたのを速く再送します。 送付者がタイムアウトの引き金となったセグメントだけを再送するので、不要な倍数断食の問題は[FHG04]を再送します。起こることができません。 したがって、3写しACKsがタイムアウトの後に送付者に到着するなら、彼らはたぶんパケット損失を示します、そして、その結果、速く再送してください。効率的な回復を許すのが使用されるべきです。 十分がなければ、パケット損失、再送信タイマーが再び呼吸が絶えて、送付者がこのアルゴリズムのステップ1に入れた後に送付者に到着するACKsをコピーしてください。
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 retransmissionがなくされたかどうか検出できません。 原則として、RTO retransmissionの損失は混雑信号としてみなされるべきです。 したがって、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は遅れたセグメントのため引き起こされた偽りのタイムアウトの後にF-RTOがある通常のTCPよりさらに正確で大きい値を持っていそうです。 私たちは、これがスパイクを遅らせる傾向があるネットワークで利点であると信じています。
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アルゴリズムは入って来る写しACKsによる偽りのタイムアウトを検出しないかもしれません。 さらに、偽りのタイムアウトが速い回復の間、起こるなら、速い回復引き金の前に伝えられたセグメントがACKsをコピーするので、F-RTOアルゴリズムはしばしば偽りのタイムアウトを検出できるというわけではありません。 しかしながら、私たちは、これらのケースがまれであると考えて、コネがどこをケースに入れるかに注意します。
Sarolahti & Kojo Experimental [Page 7] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[7ページ]RFC4138は2005年8月に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回復に働きます。
3. SACK-Enhanced Version of the F-RTO Algorithm
3. F-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 Selective Acknowledgment Option[MMFR96]を使用するF-RTOアルゴリズムの異本について説明します。 パケット再命令かパケット重複が存在しているとき、SACKオプションを使用することによって、TCP送付者は場合の大部分における偽りのタイムアウトを検出します。 SACKブロックであるなら、写しACKsがRTOに続いたら、RTO retransmissionの後に送られなかった新しいデータであり、送付者が、タイムアウトが偽りであると宣言するかもしれないと認めてください。
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 Selective Acknowledgment Option[MMFR96]がTCP接続のために有効にされるなら、TCP送付者はSACKによって高められたF-RTOアルゴリズムを実行するかもしれません。 送付者がSACKによって高められたF-RTOアルゴリズムを適用するなら、それは下の方法に従わなければなりません。 このアルゴリズムSHOULD NOT、再送タイムアウトが起こるとき、SACK損失回復にTCP送付者が既にいるなら、適用されてください。 しかしながら、再送タイムアウトが既存の損失回復の間起こるとき、ある限度内で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.
1) RTOが期限が切れるときには最初の不承認のセグメントを再送してください、そして、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) タイムアウトのため再送されたデータの承認が送付者に到着するまで、待ってください。 写しACKsが再送されたデータのための累積している承認の前に到着するなら、入って来る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回復に戻ってください、そして、2*MSSだけに混雑ウィンドウを設定してください、通常のTCPがするように。 このアルゴリズムのステップ3に入らないでください。
Sarolahti & Kojo Experimental [Page 8] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[8ページ]RFC4138は2005年8月にRTO-回復を進めます。
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つの新しい(以前にunsentな)セグメントを送ってください、そして、ステップ3に進んでください。 --どちらか受信機窓の制限のためまたはそれに送る少しの新しいデータもないのでTCP送付者がどんな以前にunsentなデータも送ることができないならお勧めの動作はこのアルゴリズムのステップ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.
また、窓で限られたケースがAppendix C.In本件で議論した取り扱いのための代替手段のいくつかを適用するのも可能である、TCP送付者はAppendix 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が「回復してください」の上、または、SACKブロックか累積しているACKとして一連番号を承認するなら、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ブロックを使用するのに)承認されなかったデータを承認するなら、タイムアウトが偽りであると申告してください、そして、シュプール_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ブロックの間には、不承認の穴があれば、それらのセグメントは同様に従来のSACK回復アルゴリズム[BAFW03]に再送されます。 アルゴリズムがシュプール_TOに用意ができているSpuriousRecoveryと共に出るなら、「回復してください」はSND.UNAに設定されます、その結果、入って来る写し承認のときに速い回復を許します。
Sarolahti & Kojo Experimental [Page 9] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[9ページ]RFC4138は2005年8月にRTO-回復を進めます。
4. Taking Actions after Detecting Spurious RTO
4. 偽物のRTOを検出した後に、行動を取ります。
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送付者は、タイムアウトに基づいて再送し続けるべきではありません。 例えば、送付者が新しい状態で伝わる輻輳回避フェーズにいるなら、以前に、unsentセグメントであり、それは、偽物のRTOを検出した後に以前にunsentセグメントを伝え続けているでしょうに。 このドキュメントは偽りのタイムアウトに応答を説明しませんが、応答アルゴリズムはRFC4015[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]で偽りの再送タイムアウトへの異なった応答異形について議論しました。 混雑ウィンドウか遅れた出発敷居が送付者で減少することを偽りの再送タイムアウトが混雑信号としてみなされるかどうかと、その結果、引き起こすべきであるか、または輻輳制御状態が再送タイムアウトの前に有効な状態に完全に振り向けられるべきであるかどうかで異なった応答代替手段は異なります。
5. SCTP Considerations
5. SCTP問題
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に持っています。 TCP再送信タイマーと同様に、1つの送付先アドレスのためのSCTP T3-rtxタイマは維持されます、そして、T3-rtxが期限が切れた後にSCTP送付者はTCPが再送するように遅れた出発で不承認のデータ塊を再送します。 したがって、SCTPは同様に偽りの再送タイムアウトのマイナスの効果に傷つきやすいです。TCPに。 同様のRTO回復アルゴリズムのため、また、F-RTOアルゴリズム論理をSCTPに適用できます。 SCTPが選択している承認を使用するので、アルゴリズムのSACKベースの異形はお勧めです、また、基本的なバージョンを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
SCTP協会がそうであることができる、マルチ、家へ帰り 現在の「再-トランスミッション」方針は、「再-トランスミッション」が代替アドレスに行くはずであると述べます。 「再-トランスミッション」が遅れスパイクで引き起こされた偽りのタイムアウトのためであったなら、オリジナルのトランスミッションの承認が到着する前に「再-トランスミッション」のための承認が送付者で帰って来るのは、可能です。 これが起こるなら、偽りのタイムアウトのため再送されたデータ塊のオリジナルの送信の可能な損失はF-RTOアルゴリズムを適用するとき、非検出されたままで残るかもしれません。 タイムアウトが遅れスパイクで引き起こされて、それがその点で偽りであったので、適当な応答は送付の新しいデータで続くことになっています。 しかしながら、オリジナルです。
Sarolahti & Kojo Experimental [Page 10] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[10ページ]RFC4138は2005年8月にRTO-回復を進めます。
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協会がそうならマルチ、家へ帰り、そして、代替アドレスに順調な「再-トランスミッション」。 そして、望まれているなら[BA04]輻輳制御を振り向けるのに写しTSNsの情報を使用できます。
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 retransmissionに束ねられたデータ塊の承認を使用してはいけません。
6. Security Considerations
6. セキュリティ問題
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つの可能な方法があります。 まず最初に、受信機はそれが受け取っていないデータを承認できます。 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
再送タイムアウトのためのよくある例はセグメントの速い「再-トランスミッション」が無くなるということです。 他のすべてのセグメントを受け取ったなら、RTO retransmissionはすぐに、全体の窓を承認させます。 本件はF-RTOで認識されて、アルゴリズムが分岐するということです。(2a)。 しかしながら、宣言しないとき、次に、RTO retransmissionを受信して、セグメントの残りを受信した後に受信機が1つのセグメントしか承認しないなら、それで、偽りであるとタイムアウトを宣言するかもしれません。 したがって、それが示される、それ、いつの間、RTOは期限が切れるか。
Sarolahti & Kojo Experimental [Page 11] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[11ページ]RFC4138は2005年8月にRTO-回復を進めます。
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.
速く、タイムアウトが偽りであると宣言されたとしても、回収段階、送付者は完全に混雑ウィンドウを振り向けるというわけではないでしょうに。 代わりに、送付者は混雑ウィンドウを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.
再送タイムアウト時点でなくなった1つ以上のセグメントがあれば、受信機は送付者がなくなったセグメントを再送するために別の回復の期間に直面しなければならないでしょう、したがって、偽りのタイムアウトを宣言するために送付者をミスリードするのから利益を得ません、通常、RTOが経過した後に。
7. Acknowledgements
7. 承認
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、ジョッシュ・ブラントン、マーク・オールマン、サリー・フロイド、Yogesh Swami、ミカLiljeberg、議論とフィードバックのためのロドリゲス、Sourabh Ladha、マーチン・デューク、Motoharu三宅、テッド・フェーバー、Samu Kontinen、およびコスタスPentikousisが本稿に寄付したイワンArias。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[APS99] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[APS99] オールマンとM.とパクソン、V.とW.スティーブンス、「TCP輻輳制御」、RFC2581、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.ワング、「TCPに、保守的な選択している承認(袋)ベースの損失回復アルゴリズム」、RFC3517(2003年4月)。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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変更」、RFC3782、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の選択している承認オプション」、RFC2018、1996年10月。
[PA00] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[PA00] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[Pos81] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[Pos81] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、1981年9月。
Sarolahti & Kojo Experimental [Page 12] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[12ページ]RFC4138は2005年8月にRTO-回復を進めます。
[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.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「流れの制御伝動プロトコル」、RFC2960(2000年10月)対パクソン
8.2. Informative References
8.2. 有益な参照
[ABF01] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
TCP's Loss Recovery Using Limited Transmit", RFC 3042,
January 2001.
[ABF01] オールマン、M.、Balakrishnan、H.、およびS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、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] ブラントン、E.、およびM.オールマン、「TCPの写しの選択している承認(DSACKs)を使用して、流れの制御伝動プロトコル(SCTP)は偽物のRetransmissionsを検出するために、トランスミッション一連番号(TSNs)をコピーします」、RFC3708、2004年2月。
[BBJ92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[BBJ92]ジェーコブソン(V.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。
[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のための選択している承認(袋)オプションへの拡大」、RFC2883(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.ラドウィグ。 TCPのためにGPRSネットワークでアイフェル高原アルゴリズムを評価します。 中、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とTCPの偽りのタイムアウトに応じるR.ラドウィグ。 IEEE INFOCOM03の議事、2003年のサンフランシスコ(カリフォルニア)(米国)の行進のときに。
[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] ラドウィグとR.とA.Gurtov、「TCPのためのアイフェル高原応答アルゴリズム」、RFC4015、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を偽物のRetransmissionsに対して強健にします。 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のためのアイフェル高原検出アルゴリズム」、RFC3522、2003年4月。
[Nag84] Nagle, J., "Congestion Control in IP/TCP Internetworks",
RFC 896, January 1984.
[Nag84] ネーグル、J.、「IP/TCPインターネットワークにおける輻輳制御」、RFC896、1984年1月。
Sarolahti & Kojo Experimental [Page 13] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[13ページ]RFC4138は2005年8月にRTO-回復を進めます。
[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コンピュータコミュニケーションレビュー、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 Globecom2003、サンフランシスコ(カリフォルニア)(米国)の議事で。 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.スワミーとK.Le、「DCLOR:」 「Spurious TimeoutsにSACK Optionを使用する反-関連しているLoss Recovery」は進歩、2003年9月に働いています。
Sarolahti & Kojo Experimental [Page 14] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[14ページ]RFC4138は2005年8月にRTO-回復を進めます。
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アルゴリズムがそれらのシナリオでどう働くかを論じます。 おもしろいシナリオは以下の通りです。 再送タイムアウトの引き金となる突然の遅れ、速い回復の間の再送されたパケットの損失はいくつかのパケット、およびパケット再命令の損失をもたらす供給停止をリンクします。 [SKR03]でF-RTOの本当の実現の、より徹底的な分析による業績評価を与えます。
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終わりのホストによって伝えられたセグメントと承認を例証しますが、どんなパケットも無くなっていません。 簡単さのために、遅れた承認は例で使用されません。 偽りのタイムアウトを検出した後に、以下の例はアイフェル高原Response Algorithm[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)
... (cwnd=6、ssthresh<6、FlightSize=6) 1. <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK5 2。 10を送ってください。---------------------------->(cwndは6、ssthresh<6、FlightSize=6と等しい)3。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 4。 11を送ってください。---------------------------->(cwndは6、ssthresh<6、FlightSize=6と等しい)5。 | [遅れ]| [RTO] [F-RTOは(1)]6を踏みます。 6を送ってください。---------------------------->(cwndは6、ssthresh=3、FlightSize=6と等しい)の<の以前のxmitted SEG6>。--->7。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK7[F-RTOステップ(2b)]8。 12を送ってください。---------------------------->9。 13を送ってください。---------------------------->(cwndは7、ssthresh=3、FlightSize=7と等しい)の<の以前のxmitted SEG7>。--->10。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK8[F-RTOステップ(3b)][SpuriousRecovery<シュプール_TO](cwnd=7、ssthresh=6、FlightSize=6)
Sarolahti & Kojo Experimental [Page 15] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[15ページ]RFC4138は2005年8月にRTO-回復を進めます。
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。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK9 13。 15を送ってください。---------------------------->(cwndは7、ssthresh=6、FlightSize=7と等しい)14。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK10 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)を再送します。 元々伝えられたセグメント6が受信機に到着したので、次のACKはRTO retransmissionを覆っています、そして、TCP送付者は2つの新しいデータ・セグメント(ステップ8、9)を送ることによって、続きます。 F-RTOで(1)と(2b)を踏む注意、偽りのタイムアウトの場合には、タイムアウトの前に送られたセグメントがまだネットワークにあるので、混雑ウィンドウとFlightSizeはまだリセットされていません。 しかしながら、送付者はまだ等しく従来のTCPに向かって攻撃的であるべきです。 RTO retransmissionがそれがデータであったのを承認した後に、タイムアウト(ステップ10)のため、2番目の承認到着が再送されなかったので、TCP送付者は、タイムアウトが偽りであると宣言して、新しいデータを次の承認に送ることによって、続きます。 また、輻輳制御状態は必要に応じてアイフェル高原Response Algorithmによって覆されます。
A.2. Loss of a Retransmission
A.2。 Retransmissionの損失
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)
... (cwnd=6、ssthresh<6、FlightSize=6) <の6の無くなっている><セグメントセグメント9は>1をなくしました。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK5 2。 10を送ってください。---------------------------->(cwndは6、ssthresh<6、FlightSize=6と等しい)3。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 4。 11を送ってください。---------------------------->。(cwnd=6、ssthresh<6、FlightSize=6)
Sarolahti & Kojo Experimental [Page 16] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[16ページ]RFC4138は2005年8月にRTO-回復を進めます。
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 ---------------------------->
...
5. <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 6。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 7。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 8。 6を送ってください。--------------X(cwndは6、ssthresh=3、FlightSize=6と等しい)<セグメント6は>9をなくしました。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 10。 12を送ってください。---------------------------->(cwndは7、ssthresh=3、FlightSize=7と等しい)11。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 12。 13を送ってください。---------------------------->(cwndは8、ssthresh=3、FlightSize=8と等しい)[RTO。]13 6を送ってください。---------------------------->(cwndは8、ssthresh=2、FlightSize=8と等しい)14。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK9[F-RTOステップ(2b)]15。 14を送ってください。---------------------------->16。 15を送ってください。---------------------------->(cwndは7、ssthresh=2、FlightSize=7と等しい)17。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK、9 [F-RTOは(3a)][SpuriousRecovery<FALSE](cwndは3、ssthresh=2、FlightSize=7と等しい)18を踏みます。 9を送ってください。---------------------------->19。 10を送ってください。---------------------------->20。 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は無くなります、そして、3がステップ8にACKsをコピーした後に送付者がそれを再送します。 しかしながら、また、「再-トランスミッション」はなくされています、そして、送付者は再びそれを再送する前にRTOが期限が切れるのを待たなければなりません。 RTO retransmissionに続く最初のACKがRTO retransmission(ステップ14)を承認するので、送付者は2つの新しいセグメントを伝えます。 ステップ17における第2ACKは少しの以前に不承認のデータも承認しません。 したがって、F-RTO送付者は、遅れた出発を入れて、3*MSSにcwndを設定します。 2回の丸い旅行が再送タイムアウトの後に経過したので、3つのセグメントに混雑ウィンドウを設定できます。 最終的に、受信機は、回復と送付者に入る前に伝えられたすべてのセグメントが、輻輳回避における新しいデータを送り続けることができると認めます。
Sarolahti & Kojo Experimental [Page 17] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[17ページ]RFC4138は2005年8月にRTO-回復を進めます。
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 ---------------------------->
... (cwnd=6、ssthresh<6、FlightSize=6) <セグメント6-9は>1をなくしました。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK5 2。 10を送ってください。---------------------------->(cwndは6、ssthresh<6、FlightSize=6と等しい)3。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 4。 11を送ってください。---------------------------->(cwndは6、ssthresh<6、FlightSize=6と等しい)5。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6| | [RTO。]6 6を送ってください。---------------------------->(cwndは6、ssthresh=3、FlightSize=6と等しい)7。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK7[F-RTOステップ(2b)]8。 12を送ってください。---------------------------->9。 13を送ってください。---------------------------->(cwndは7、ssthresh=3、FlightSize=7と等しい)10。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK、7 [F-RTOは(3a)][SpuriousRecovery<FALSE](cwndは3、ssthresh=3、FlightSize=7と等しい)11を踏みます。 7を送ってください。---------------------------->12。 8を送ってください。---------------------------->13。 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 retransmissionが承認された後にF-RTO送付者は2つの新しいセグメント(ステップ8と9)を伝えます。 次のACKが再送タイムアウト(ステップ10)の後に再送されなかった少しのデータも承認しないので、F-RTO送付者は従来の回復と遅れた出発「再-トランスミッション」を続けます。
A.4. Packet Reordering
A.4。 パケットReordering
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
F-RTOが再送タイムアウトの後にだけTCP送付者の振舞いを変更して、偽りのタイムアウトの後にだけ不要な「再-トランスミッション」を避けるのが意図しているので、私たちはパケットがそれが再送タイムアウト直後起こるケースへのF-RTOの振舞いのときに再命令されるという効果についての議論を制限します。 いつ
Sarolahti & Kojo Experimental [Page 18] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[18ページ]RFC4138は2005年8月にRTO-回復を進めます。
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.
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と7の前に到着するとき、以下では、私たちがSACKによって高められたF-RTOの動きを例証します、そして、セグメント6から始めるセグメントがネットワークで遅れます。 この例では、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 ---------------------------->
...
... (cwnd=6、ssthresh<6、FlightSize=6) 1. <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK5 2。 10を送ってください。---------------------------->(cwndは6、ssthresh<6、FlightSize=6と等しい)3。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6 4。 11を送ってください。---------------------------->5。 | [遅れ]| [RTO。]6 6を送ってください。---------------------------->(cwndは6、ssthresh=3、FlightSize=6と等しい)の<の以前のxmitted SEG8>。--->7。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK6[SACK8][SACK F-RTOはステップ2にいる]8。 <の以前のxmitted SEG6>。--->9。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK7[SACK8][SACK F-RTOステップ(2b)]10。 12を送ってください。---------------------------->11。 13を送ってください。---------------------------->(cwndは7、ssthresh=3、FlightSize=7と等しい)12。 <の以前のxmitted SEG7>。--->13。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK9[SACK F-RTOステップ(3b)][SpuriousRecovery<シュプール_TO](cwndは7、ssthresh=6、FlightSize=6と等しい)14。 14を送ってください。---------------------------->(cwndは7、ssthresh=6、FlightSize=7と等しい)15。 <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ACK10 16。 15を送ってください。---------------------------->…
Sarolahti & Kojo Experimental [Page 19] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[19ページ]RFC4138は2005年8月にRTO-回復を進めます。
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を発生させます。 承認に対応して、F-RTOステップ2にいる以外に、TCP送付者は何も発信させません。 次の承認が累積している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が期限が切れるとき、偽りのタイムアウトも検出するのにわずかに変更されて、SACKによって高められた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の間の以前に不承認の非再送されたデータを承認するのを必要とします、そして、_高く発信してください。 RTOが以前(SACKベースの)の損失回復の間、期限が切れるなら、F-RTO送付者はSACKベースの損失回復が始まる前に伝えられた非再送されたセグメントに承認だけを使用しなければなりません。 これは、TCP送付者がタイムアウトが偽りであると宣言するためにアルゴリズムステップ3でSND.UNAとRecoveryPointの間の非再送されたセグメントのための承認を受けなければならないことを意味します。 RecoveryPointは保守的なSACK-回復アルゴリズム[BAFW03]で定義されます、そして、それが、SACKベースの損失回復が今までのところ始まるとき、最も高いセグメントが伝わったのを示すように設定されます。 言い換えれば、TCP送付者がセグメントのための承認を受けるならそれが1伝えられた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が期限が切れた後にどのセグメントを再送したらよいかに上に与えられた規則に従って偽りのタイムアウトが検出されるのが可能であるかもしれないか、そして、混雑を振り向けるのが安全であるかどうかがパラメタを制御します。 これは今後の調査のための話題であると考えられます。
Sarolahti & Kojo Experimental [Page 20] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[20ページ]RFC4138は2005年8月に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つの新しい以前にunsentなセグメントの送信を制限するか、または送るどんな新しいデータもないとき、F-RTOアルゴリズムステップ(2b)では、TCP送付者が従来のRTO回復アルゴリズムを続行することが勧められます。 不都合は送付者が可能な偽りのタイムアウトのため不要な「再-トランスミッション」を続けるかもしれないということです。 このセクションは簡潔に以前にunsentデータを送るのが可能でないときに性能を潜在的に向上させることができるオプションについて論じます。
- 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か株式会社Transmit[ABF01]などのアルゴリズムの使用を確実にするために広告を出している窓の1か2つのセグメントのサイズの未使用のスペースを予約できました。 他方では、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].
- 利用可能であるなら、例えば追加情報を使用してください。偽りのタイムアウトを検出するためのアイフェル高原Detectionアルゴリズムがある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を続行してください。 「再-トランスミッション」が不必要に作られるのは、可能です。 したがって、このオプションは奨励されません、偽りのタイムアウトの傾向がある環境で作動するのが知られているホストを除いて。 他方では、この方法で、偽りのタイムアウトによる不要な「再-トランスミッション」を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.
- 無大きさで分けられたセグメントをSND.UNAの下に送ってください、生きているTCP Keep徹底的調査と同様であり、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を送ります。
Sarolahti & Kojo Experimental [Page 21] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[21ページ]RFC4138は2005年8月にRTO-回復を進めます。
Authors' Addresses
作者のアドレス
Pasi Sarolahti Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP Finland
パシSarolahtiノキアリサーチセンター私書箱407フィン-00045Nokia Groupフィンランド
Phone: +358 50 4876607 EMail: pasi.sarolahti@nokia.com http://www.cs.helsinki.fi/u/sarolaht/
以下に電話をしてください。 +358 50 4876607はメールされます: 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
マルックKojoヘルシンキコンピュータサイエンス学部大学P.O. Box68フィン-00014ヘルシンキフィンランド大学
Phone: +358 9 191 51305 EMail: kojo@cs.helsinki.fi
以下に電話をしてください。 +358 9 191 51305 メール: kojo@cs.helsinki.fi
Sarolahti & Kojo Experimental [Page 22] RFC 4138 Forward RTO-Recovery August 2005
Sarolahti&Kojoの実験的な[22ページ]RFC4138は2005年8月にRTO-回復を進めます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Sarolahti & Kojo Experimental [Page 23]
Sarolahti&Kojo実験的です。[23ページ]
一覧
スポンサーリンク
