Network Working Group E. Blanton
Request for Comments: 3517 Purdue University
Category: Standards Track M. Allman
BBN/NASA GRC
K. Fall
Intel Research
L. Wang
University of Kentucky
April 2003
A Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. The algorithm presented in this document conforms to the spirit of the current congestion control specification (RFC 2581), but allows TCP senders to recover more effectively when multiple segments are lost from a single flight of data.
この文書は、選択的確認応答（SACK）TCPオプションの使用に基づいているTCPのための保守的な損失回復アルゴリズムを提案します。この文書で提示するアルゴリズムは、現在の輻輳制御仕様（RFC 2581）の精神に準拠するが、複数のセグメントがデータの単一フライトから失われている場合に、TCP送信者がより効果的に回復することを可能にします。
Terminology
用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載されているように解釈されます。
1 Introduction
1はじめに
This document presents a conservative loss recovery algorithm for TCP that is based on the use of the selective acknowledgment (SACK) TCP option. While the TCP SACK [RFC2018] is being steadily deployed in the Internet [All00], there is evidence that hosts are not using the SACK information when making retransmission and congestion control decisions [PF01]. The goal of this document is to outline one straightforward method for TCP implementations to use SACK information to increase performance.
この文書は、選択的確認応答（SACK）TCPオプションの使用に基づいているTCPのための保守的な損失回復アルゴリズムを提案します。 TCP SACK [RFC2018]は着実に[All00]インターネットで展開されている間、再送信と輻輳制御の決定[PF01]を行うときにホストがSACK情報を使用していないという証拠があります。このドキュメントの目標は、TCPの実装は、パフォーマンスを向上させるためにSACK情報を使用するための1つの簡単な方法を概説することです。
[RFC2581] allows advanced loss recovery algorithms to be used by TCP [RFC793] provided that they follow the spirit of TCP's congestion control algorithms [RFC2581, RFC2914]. [RFC2582] outlines one such advanced recovery algorithm called NewReno. This document outlines a loss recovery algorithm that uses the SACK [RFC2018] TCP option to enhance TCP's loss recovery. The algorithm outlined in this document, heavily based on the algorithm detailed in [FF96], is a conservative replacement of the fast recovery algorithm [Jac90, RFC2581]. The algorithm specified in this document is a straightforward SACK-based loss recovery strategy that follows the guidelines set in [RFC2581] and can safely be used in TCP implementations. Alternate SACK-based loss recovery methods can be used in TCP as implementers see fit (as long as the alternate algorithms follow the guidelines provided in [RFC2581]). Please note, however, that the SACK-based decisions in this document (such as what segments are to be sent at what time) are largely decoupled from the congestion control algorithms, and as such can be treated as separate issues if so desired.
[RFC2581]は、高度な損失回復アルゴリズムは、TCPが使用することを可能にする[RFC793]彼らはTCPの輻輳制御アルゴリズム[RFC2581、RFC2914]の精神に従うことを条件とします。 [RFC2582]はNewRenoのと呼ばれるそのような高度な回復アルゴリズムを概説します。このドキュメントでは、TCPの損失回復を強化するためにSACK [RFC2018] TCPオプションを使用して損失回復アルゴリズムの概要を説明します。本文書で概説アルゴリズムは、高濃度[FF96]に詳述されたアルゴリズムに基づいて、高速回復アルゴリズム[Jac90、RFC2581]の保存的置換です。この文書で指定されたアルゴリズムは[RFC2581]で設定したガイドラインに従い、安全にTCPの実装に使用することができ、簡単SACKベースの損失回復戦略です。実装が合うように交互のSACKベースの損失回復方法がTCPで使用することができる（代替アルゴリズムは[RFC2581]に提供されたガイドラインに従っている限り）。 （そのようなセグメントが何時送信されるものなど）は、この文書に記載されているSACKベースの決定が大きく輻輳制御アルゴリズムから分離され、そして所望の場合のような別の問題として扱うことができることは、ご注意ください。
2 Definitions
2つの定義
The reader is expected to be familiar with the definitions given in [RFC2581].
読者は[RFC2581]で与えられた定義に精通していることが予想されます。
The reader is assumed to be familiar with selective acknowledgments as specified in [RFC2018].
読者は[RFC2018]で指定されるように選択的確認応答に精通しているものとします。
For the purposes of explaining the SACK-based loss recovery algorithm we define four variables that a TCP sender stores:
SACKベースの損失回復アルゴリズムを説明する目的のために我々はそのTCP送信店4つの変数を定義します。
"HighACK" is the sequence number of the highest byte of data that has been cumulatively ACKed at a given point.
「HighACKは、」累積的に与えられた時点でACKされたデータの最上位バイトのシーケンス番号です。
"HighData" is the highest sequence number transmitted at a given point.
「HighData」は、所与の時点で送信された最も高いシーケンス番号です。
"HighRxt" is the highest sequence number which has been retransmitted during the current loss recovery phase.
「HighRxtは、」現在の損失回復フェーズ中に再送されたシーケンス番号が最大です。
"Pipe" is a sender's estimate of the number of bytes outstanding in the network. This is used during recovery for limiting the sender's sending rate. The pipe variable allows TCP to use a fundamentally different congestion control than specified in [RFC2581]. The algorithm is often referred to as the "pipe algorithm".
「パイプ」、ネットワーク内の未処理のバイト数の送信者の推定値です。これは、送信者の送信速度を制限するためのリカバリ時に使用されています。パイプ変数は、TCPは、[RFC2581]で指定は基本的に異なる輻輳制御を使用することを可能にします。このアルゴリズムは、多くの場合、「パイプアルゴリズム」と呼ばれています。
For the purposes of this specification we define a "duplicate acknowledgment" as a segment that arrives with no data and an acknowledgment (ACK) number that is equal to the current value of HighACK, as described in [RFC2581].
本明細書の目的のために、我々は、[RFC2581]に記載されているように、データ及びHighACKの現在の値に等しい肯定応答（ACK）番号と到着セグメントとして「重複確認応答」を定義します。
We define a variable "DupThresh" that holds the number of duplicate acknowledgments required to trigger a retransmission. Per [RFC2581] this threshold is defined to be 3 duplicate acknowledgments. However, implementers should consult any updates to [RFC2581] to determine the current value for DupThresh (or method for determining its value).
私たちは、再送をトリガするために必要な重複確認応答の数を保持する変数「DupThresh」を定義します。 [RFC2581]は、この閾値は3つの重複肯定応答であると定義されます。しかし、実装者は現在DupThreshの値（またはその値を決定するための方法）を決定するために、[RFC2581]に更新を相談してください。
Finally, a range of sequence numbers [A,B] is said to "cover" sequence number S if A <= S <= B.
<= S <= Bの場合、最終的に、シーケンス番号[A、B]の範囲は、 "カバー" シーケンス番号Sと言われています
3 Keeping Track of SACK Information
3 SACK情報を追跡します
For a TCP sender to implement the algorithm defined in the next section it must keep a data structure to store incoming selective acknowledgment information on a per connection basis. Such a data structure is commonly called the "scoreboard". The specifics of the scoreboard data structure are out of scope for this document (as long as the implementation can perform all functions required by this specification).
TCPの送信者は、次のセクションで定義されたアルゴリズムを実装することは、接続ごとに着信選択送達確認情報を格納するためのデータ構造を維持する必要があります。このようなデータ構造は、一般に「スコアボード」と呼ばれています。 （実装が本明細書に必要なすべての機能を実行することができる限り）スコアボードデータ構造の詳細は、この文書の範囲外です。
Note that this document refers to keeping account of (marking) individual octets of data transferred across a TCP connection. A real-world implementation of the scoreboard would likely prefer to manage this data as sequence number ranges. The algorithms presented here allow this, but require arbitrary sequence number ranges to be marked as having been selectively acknowledged.
このドキュメントは、TCP接続を介して転送されるデータの個々のオクテット（マーキング）のアカウントを維持することをいいます。スコアボードの実世界の実装では、おそらく、シーケンス番号範囲として、このデータを管理することを好むだろう。ここで紹介するアルゴリズムは、これを許可しますが、任意のシーケンス番号が選択的に認知されたものとしてマークする範囲が必要です。
4 Processing and Acting Upon SACK Information
4処理とSACK情報に作用します
For the purposes of the algorithm defined in this document the scoreboard SHOULD implement the following functions:
スコアボードには、以下の機能を実装する必要があり、この文書で定義されたアルゴリズムの目的のために：
Update ():
アップデート（）：
Given the information provided in an ACK, each octet that is cumulatively ACKed or SACKed should be marked accordingly in the scoreboard data structure, and the total number of octets SACKed should be recorded.
ACKで提供される情報が与えられると、累積ACKさまたは解雇された各オクテットは、スコアボードデータ構造に応じてマークされるべきであり、解雇オクテットの総数が記録されるべきです。
Note: SACK information is advisory and therefore SACKed data MUST NOT be removed from TCP's retransmission buffer until the data is cumulatively acknowledged [RFC2018].
注意：SACK情報は参考であり、データが累積的に確認されるまで、したがってデータはTCPの再送バッファから削除されてはならない解雇[RFC2018]。
IsLost (SeqNum):
IsLost（SEQNUM）：
This routine returns whether the given sequence number is considered to be lost. The routine returns true when either DupThresh discontiguous SACKed sequences have arrived above 'SeqNum' or (DupThresh * SMSS) bytes with sequence numbers greater than 'SeqNum' have been SACKed. Otherwise, the routine returns false.
与えられたシーケンス番号が失われると考えられているかどうかをこのルーチン。真のいずれかDupThreshの不連続は、シーケンスを解雇戻っは「SEQNUM」より大きいシーケンス番号とバイト「SEQNUM」または（DupThresh * SMSS）の上に到着した解雇されています。そうでなければ、ルーチンはfalseを返します。
SetPipe ():
SetPipe（）：
This routine traverses the sequence space from HighACK to HighData and MUST set the "pipe" variable to an estimate of the number of octets that are currently in transit between the TCP sender and the TCP receiver. After initializing pipe to zero the following steps are taken for each octet 'S1' in the sequence space between HighACK and HighData that has not been SACKed:
このルーチンは、HighACKからHighDataに配列スペースを横断し、TCPの送信側とTCP受信機の間の輸送に現在あるオクテットの数の推定値に「パイプ」変数を設定しなければなりません。以下のステップをゼロにパイプを初期化した後に解雇されていないHighACKとHighData間の配列空間の各オクテット「S1」のために採取されます。
(a) If IsLost (S1) returns false:
（a）はIsLost（S1）がfalseを返した場合：
Pipe is incremented by 1 octet.
パイプは1つのオクテットだけ増分されます。
The effect of this condition is that pipe is incremented for packets that have not been SACKed and have not been determined to have been lost (i.e., those segments that are still assumed to be in the network).
この条件の効果は、パイプが解雇されていないと（依然としてネットワークであると仮定され、すなわち、それらのセグメントを）失われたと判定されなかったパケットのために増加されることです。
(b) If S1 <= HighRxt:
（b）は、S1 <= HighRxt場合：
Pipe is incremented by 1 octet.
パイプは1つのオクテットだけ増分されます。
The effect of this condition is that pipe is incremented for the retransmission of the octet.
この条件の効果は、パイプがオクテットの再送信のために増分されることです。
Note that octets retransmitted without being considered lost are counted twice by the above mechanism.
紛失したとみなされずに再送信オクテットは、上記のメカニズムによって2回カウントされることに注意してください。
NextSeg ():
NextSeg（）：
This routine uses the scoreboard data structure maintained by the Update() function to determine what to transmit based on the SACK information that has arrived from the data receiver (and hence been marked in the scoreboard). NextSeg () MUST return the sequence number range of the next segment that is to be transmitted, per the following rules:
このルーチンは、データ受信機から到着している（従って、スコアボードでマークされて）SACK情報に基づいて送信するかを決定するために、更新（）関数によって維持スコアボードデータ構造を使用します。 NextSeg（）は、次のルールごとに、送信されるべき次のセグメントのシーケンス番号範囲を返さなければなりません。
(1) If there exists a smallest unSACKed sequence number 'S2' that meets the following three criteria for determining loss, the sequence range of one segment of up to SMSS octets starting with S2 MUST be returned.
損失を決定するための以下の3つの基準を満たす最小unSACKedシーケンス番号「S2」が存在する場合（1）、S2で開始SMSSオクテットまでの一つのセグメントのシーケンス範囲を返さなければなりません。
(1.a) S2 is greater than HighRxt.
（1.A）S2はHighRxtより大きい。
(1.b) S2 is less than the highest octet covered by any received SACK.
（1.B）S2は、任意の受信されたSACKによって覆わ最高オクテット未満です。
(1.c) IsLost (S2) returns true.
（1.C）IsLost（S2）がtrueを返します。
(2) If no sequence number 'S2' per rule (1) exists but there exists available unsent data and the receiver's advertised window allows, the sequence range of one segment of up to SMSS octets of previously unsent data starting with sequence number HighData+1 MUST be returned.
（2）もしシーケンス番号「S2」ルールあたり（1）存在しても存在し利用可能な未送信データが存在し、受信機の広告ウィンドウは、シーケンス番号から始めて、以前に未送信データのSMSSオクテットまでの一つのセグメントのシーケンスの範囲を可能にHighData +図1は、返さなければなりません。
(3) If the conditions for rules (1) and (2) fail, but there exists an unSACKed sequence number 'S3' that meets the criteria for detecting loss given in steps (1.a) and (1.b) above (specifically excluding step (1.c)) then one segment of up to SMSS octets starting with S3 MAY be returned.
（3）ルールの条件（1）及び（2）は失敗するが、工程（1.A）とで与えられた損失を検出するための基準を満たすunSACKedシーケンス番号「S3」が存在する場合（1.B）上記（具体的に除く工程（1.C））、次いでS3で開始SMSSオクテットまでのいずれかのセグメントが戻されてもよいです。
Note that rule (3) is a sort of retransmission "last resort".
It allows for retransmission of sequence numbers even when the
sender has less certainty a segment has been lost than as with
rule (1). Retransmitting segments via rule (3) will help
sustain TCP's ACK clock and therefore can potentially help
avoid retransmission timeouts. However, in sending these
segments the sender has two copies of the same data considered
to be in the network (and also in the Pipe estimate). When an
ACK or SACK arrives covering this retransmitted segment, the sender cannot be sure exactly how much data left the network
(one of the two transmissions of the packet or both
transmissions of the packet). Therefore the sender may
underestimate Pipe by considering both segments to have left
the network when it is possible that only one of the two has.
We believe that the triggering of rule (3) will be rare and that the implications are likely limited to corner cases relative to the entire recovery algorithm. Therefore we leave the decision of whether or not to use rule (3) to implementors.
私たちは、ルールのトリガは、（3）まれになり、意味合いがありそう全体の回復アルゴリズムに対するコーナーケースに限定されていることと信じています。そこで我々は、実装者にルール（3）を使用するか否かの決定を残します。
(4) If the conditions for each of (1), (2), and (3) are not met, then NextSeg () MUST indicate failure, and no segment is returned.
（4）（1）、（2）、及び（3）が満たされていないのそれぞれの条件は、次にNextSeg（）が失敗したことを示さなければなりません、そしていかなるセグメントが返されない場合。
Note: The SACK-based loss recovery algorithm outlined in this document requires more computational resources than previous TCP loss recovery strategies. However, we believe the scoreboard data structure can be implemented in a reasonably efficient manner (both in terms of computation complexity and memory usage) in most TCP implementations.
注：このドキュメントで概説SACKベースの損失回復アルゴリズムは、以前のTCPの損失回復戦略よりも多くの計算資源を必要とします。しかし、我々は、スコアボードのデータ構造は、ほとんどのTCPの実装に（両方の計算の複雑さとメモリ使用量の観点で）合理的に効率的な方法で実現することができると信じています。
5 Algorithm Details
5つのアルゴリズム詳細
Upon the receipt of any ACK containing SACK information, the scoreboard MUST be updated via the Update () routine.
SACK情報を含む任意のACKを受信すると、スコアボードは、更新（）ルーチンを介して更新されなければなりません。
Upon the receipt of the first (DupThresh - 1) duplicate ACKs, the scoreboard is to be updated as normal. Note: The first and second duplicate ACKs can also be used to trigger the transmission of previously unsent segments using the Limited Transmit algorithm [RFC3042].
（DupThresh - 1）を受信するとACKを複製し、スコアボードが正常に更新されます。注：第一および第二の重複ACKはまた、限定送信アルゴリズム[RFC3042]を使用して、以前に未送信のセグメントの送信をトリガするために使用することができます。
When a TCP sender receives the duplicate ACK corresponding to DupThresh ACKs, the scoreboard MUST be updated with the new SACK information (via Update ()). If no previous loss event has occurred on the connection or the cumulative acknowledgment point is beyond the last value of RecoveryPoint, a loss recovery phase SHOULD be initiated, per the fast retransmit algorithm outlined in [RFC2581]. The following steps MUST be taken:
TCPの送信者がDupThreshのACKに対応する重複ACKを受信すると、スコアボードには、（更新（）を経由して）新しいSACK情報で更新されなければなりません。以前の損失事象は、接続上で発生していないまたは累積承認ポイントがRecoveryPointの最後の値を超えている場合には、損失の回復期には、[RFC2581]に概説高速再送アルゴリズムごとに、開始すべきです。次のステップが取らなければなりません：
(1) RecoveryPoint = HighData
（1）RecoveryPoint = HighData
When the TCP sender receives a cumulative ACK for this data octet
the loss recovery phase is terminated.
(2) ssthresh = cwnd = (FlightSize / 2)
（2）SSTHRESH = CWND =（FlightSize / 2）
The congestion window (cwnd) and slow start threshold (ssthresh)
are reduced to half of FlightSize per [RFC2581].
(3) Retransmit the first data segment presumed dropped -- the segment starting with sequence number HighACK + 1. To prevent repeated retransmission of the same data, set HighRxt to the highest sequence number in the retransmitted segment.
（3）推定再送第1のデータセグメントがドロップ - セグメントは、同じデータの反復再送信を防止するために、シーケンス番号HighACK + 1から始まる、HighRxtは再送セグメントで最も高いシーケンス番号に設定します。
(4) Run SetPipe ()
（4）ファイル名を指定して実行SetPipe（）
Set a "pipe" variable to the number of outstanding octets
currently "in the pipe"; this is the data which has been sent by
the TCP sender but for which no cumulative or selective
acknowledgment has been received and the data has not been
determined to have been dropped in the network. It is assumed
that the data is still traversing the network path.
(5) In order to take advantage of potential additional available cwnd, proceed to step (C) below.
（5）潜在的な利用できるCWNDを利用するため、以下の（c）に進みます。
Once a TCP is in the loss recovery phase the following procedure MUST be used for each arriving ACK:
TCPは損失回復段階になったら、次の手順では、各到着ACKを使用しなければなりません。
(A) An incoming cumulative ACK for a sequence number greater than RecoveryPoint signals the end of loss recovery and the loss recovery phase MUST be terminated. Any information contained in the scoreboard for sequence numbers greater than the new value of HighACK SHOULD NOT be cleared when leaving the loss recovery phase.
（A）RecoveryPointより大きいシーケンス番号の着信累積ACKが損失回復の終了を通知し、損失回復フェーズが終了しなければなりません。損失の回復期を出るときHighACKの新しい値よりも大きいシーケンス番号のためのスコアボードに含まれるすべての情報をクリアしないでください。
(B) Upon receipt of an ACK that does not cover RecoveryPoint the following actions MUST be taken:
以下のアクションを取らなければならないRecoveryPointをカバーしていないACKを受信すると（B）：
(B.1) Use Update () to record the new SACK information conveyed
by the incoming ACK.
(B.2) Use SetPipe () to re-calculate the number of octets still in the network.
（B.2）の使用SetPipe（）ネットワークではまだオクテットの数を再計算します。
(C) If cwnd - pipe >= 1 SMSS the sender SHOULD transmit one or more segments as follows:
（C）CWND場合 - パイプ> = 1 SMSS次のように送信者が1つ以上のセグメントを送信しなければなりません。
(C.1) The scoreboard MUST be queried via NextSeg () for the
sequence number range of the next segment to transmit (if any), and the given segment sent. If NextSeg () returns failure (no
data to send) return without sending anything (i.e., terminate
steps C.1 -- C.5).
(C.2) If any of the data octets sent in (C.1) are below HighData, HighRxt MUST be set to the highest sequence number of the retransmitted segment.
（C.1）で送信されたデータオクテットのいずれかHighData未満である場合（C.2）、HighRxtは再送セグメントの最高のシーケンス番号に設定しなければなりません。
(C.3) If any of the data octets sent in (C.1) are above HighData, HighData must be updated to reflect the transmission of previously unsent data.
（C.1）で送信されたデータオクテットのいずれかHighDataを超えている場合（C.3）は、HighDataは、以前に未送信データの送信を反映するように更新されなければなりません。
(C.4) The estimate of the amount of data outstanding in the network must be updated by incrementing pipe by the number of octets transmitted in (C.1).
（C.4）ネットワーク内の未処理データの量の推定値は、（C.1）に送信されたオクテットの数でパイプをインクリメントして更新しなければなりません。
(C.5) If cwnd - pipe >= 1 SMSS, return to (C.1)
（C.5）CWND場合 - パイプ> = 1 SMSS、（C.1）に戻ります
In order to avoid memory deadlocks, the TCP receiver is allowed to discard data that has already been selectively acknowledged. As a result, [RFC2018] suggests that a TCP sender SHOULD expunge the SACK information gathered from a receiver upon a retransmission timeout "since the timeout might indicate that the data receiver has reneged." Additionally, a TCP sender MUST "ignore prior SACK information in determining which data to retransmit." However, a SACK TCP sender SHOULD still use all SACK information made available during the slow start phase of loss recovery following an RTO.
メモリデッドロックを回避するためには、TCP受信機はすでに選択認められているデータを破棄するように許可されています。その結果、[RFC2018]はTCPの送信側が再送タイムアウト時に受信機から収集SACK情報を抹消すべきであることを示唆している「タイムアウトがデータ受信が破ったことを示している可能性がありますので、。」また、TCPの送信者は、「再送信するためにどのデータを決定する際に事前SACK情報を無視します。」しなければなりませんしかし、SACKのTCPの送信者はまだRTO以下の損失回復のスロースタートフェーズ中に利用可能となるすべてのSACK情報を使用すべきです。
If an RTO occurs during loss recovery as specified in this document, RecoveryPoint MUST be set to HighData. Further, the new value of RecoveryPoint MUST be preserved and the loss recovery algorithm outlined in this document MUST be terminated. In addition, a new recovery phase (as described in section 5) MUST NOT be initiated until HighACK is greater than or equal to the new value of RecoveryPoint.
この文書で指定されたRTOが損失回復中に発生した場合、RecoveryPointはHighDataに設定しなければなりません。さらに、RecoveryPointの新しい値が保存されなければならないし、この文書で概説損失回復アルゴリズムを終えなければなりません。 HighACKはRecoveryPointの新しい値以上になるまで加えて、新たな回復期（セクション5に記載されているように）を開始してはいけません。
As described in Sections 4 and 5, Update () SHOULD continue to be used appropriately upon receipt of ACKs. This will allow the slow start recovery period to benefit from all available information provided by the receiver, despite the fact that SACK information was expunged due to the RTO.
セクション4および5に記載されているように、更新（）ACKの受信時に適切に使用され続けるべきです。これはスロースタート回復期間は、SACK情報がRTOのために消去されたという事実にもかかわらず、受信機が提供するすべての入手可能な情報から利益を得ることができます。
If there are segments missing from the receiver's buffer following processing of the retransmitted segment, the corresponding ACK will contain SACK information. In this case, a TCP sender SHOULD use this SACK information when determining what data should be sent in each segment of the slow start. The exact algorithm for this selection is not specified in this document (specifically NextSeg () is inappropriate during slow start after an RTO). A relatively straightforward approach to "filling in" the sequence space reported as missing should be a reasonable approach.
再送セグメントの処理に続いて受信機のバッファから欠落しているセグメントが存在する場合、対応するACKは、SACK情報を含むことになります。データは、スロースタートの各セグメントで送信されるべきか決定する際、この場合には、TCP送信者は、このSACK情報を使用すべきです。この選択のための正確なアルゴリズムは、（具体的NextSeg（）はRTO後にスロースタート時には不適切である）、この文書で指定されていません。不足しているとして報告された配列スペース「を埋める」ために、比較的簡単な方法は、合理的なアプローチでなければなりません。
6 Managing the RTO Timer
6 RTOタイマーを管理します
The standard TCP RTO estimator is defined in [RFC2988]. Due to the fact that the SACK algorithm in this document can have an impact on the behavior of the estimator, implementers may wish to consider how the timer is managed. [RFC2988] calls for the RTO timer to be re-armed each time an ACK arrives that advances the cumulative ACK point. Because the algorithm presented in this document can keep the ACK clock going through a fairly significant loss event, (comparatively longer than the algorithm described in [RFC2581]), on some networks the loss event could last longer than the RTO. In this case the RTO timer would expire prematurely and a segment that need not be retransmitted would be resent.
標準のTCP RTO推定は、[RFC2988]で定義されています。これによって文書のSACKアルゴリズムは、推定の行動に影響を与えることができるという事実のために、実装者はタイマーが管理されている方法を検討することを望むかもしれません。 RTOタイマが累積ACK点を進めるACKが到着するたびに再武装するために[RFC2988]はコール。この文書で提示したアルゴリズムは、ACKクロックは、かなり大きな損失イベントを通過保つことができるため（[RFC2581]で説明したアルゴリズムよりも比較的長い）、いくつかのネットワーク上の損失事象は長いRTOよりも続く可能性が。この場合、RTOタイマが早まって期限切れになり、再送信する必要はないセグメントが再送されるだろう。
Therefore we give implementers the latitude to use the standard [RFC2988] style RTO management or, optionally, a more careful variant that re-arms the RTO timer on each retransmission that is sent during recovery MAY be used. This provides a more conservative timer than specified in [RFC2988], and so may not always be an attractive alternative. However, in some cases it may prevent needless retransmissions, go-back-N transmission and further reduction of the congestion window.
そこで我々は、実装に応じて標準[RFC2988]スタイルRTO管理や、復旧の際に送信される再送ごとに再腕RTOタイマーを使用することができる、より慎重なバリアントを使用するには緯度を与えます。これは、[RFC2988]で指定されたよりも多くの保守的なタイマーを提供し、そのため常に魅力的な選択肢ではないかもしれません。しかし、いくつかのケースでは、外出先バック-Nの送信および輻輳ウィンドウの更なる削減、不必要な再送信を防ぐことができます。
7 Research
7研究
The algorithm specified in this document is analyzed in [FF96], which shows that the above algorithm is effective in reducing transfer time over standard TCP Reno [RFC2581] when multiple segments are dropped from a window of data (especially as the number of drops increases). [AHKO97] shows that the algorithm defined in this document can greatly improve throughput in connections traversing satellite channels.
複数のセグメントは、データのウィンドウから削除されたときに、この文書で指定されたアルゴリズムは、特に小滴の数が増加するように（[FF96]、上記のアルゴリズムは、標準TCPリノ上の転送時間を短縮するのに有効であることを示している[RFC2581]で分析されます）。 【AHKO97]この文書で定義されたアルゴリズムが大きく、衛星放送チャンネルを横断する接続におけるスループットを向上させることができることを示しています。
8 Security Considerations
8セキュリティについての考慮事項
The algorithm presented in this paper shares security considerations with [RFC2581]. A key difference is that an algorithm based on SACKs is more robust against attackers forging duplicate ACKs to force the TCP sender to reduce cwnd. With SACKs, TCP senders have an additional check on whether or not a particular ACK is legitimate. While not fool-proof, SACK does provide some amount of protection in this area.
[RFC2581]でこの論文を共有セキュリティの考慮事項に提示したアルゴリズム。主な違いは、袋に基づくアルゴリズムはcwndのを軽減するためにTCPの送信者を強制的に重複ACKを偽造攻撃者に対してより堅牢であるということです。サックスでは、TCPの送信者は、特定のACKが正当であるか否かの追加のチェックを持っています。ばかプルーフされていないが、SACKは、この分野での保護のいくつかの量を提供しません。
Acknowledgments
謝辞
The authors wish to thank Sally Floyd for encouraging this document and commenting on early drafts. The algorithm described in this document is loosely based on an algorithm outlined by Kevin Fall and Sally Floyd in [FF96], although the authors of this document assume responsibility for any mistakes in the above text. Murali Bashyam, Ken Calvert, Tom Henderson, Reiner Ludwig, Jamshid Mahdavi, Matt Mathis, Shawn Ostermann, Vern Paxson and Venkat Venkatsubra provided valuable feedback on earlier versions of this document. We thank Matt Mathis and Jamshid Mahdavi for implementing the scoreboard in ns and hence guiding our thinking in keeping track of SACK state.
著者は、この文書を奨励し、初期の草稿にコメントがサリーフロイドに感謝したいです。この文書の著者は上記のテキストに間違いの責任を負うが、この文書に記載されたアルゴリズムは緩く、[FF96]でケビン・秋とサリー・フロイドによって概説されたアルゴリズムに基づいています。ムラリBashyam、ケン・カルバート、トム・ヘンダーソン、ライナールートヴィヒ、ジャムシードMahdavi、マット・マシス、ショーンOstermann、バーン・パクソンとヴェンカトVenkatsubraはこのドキュメントの以前のバージョンの貴重なフィードバックを提供します。我々はナノ秒でスコアボードを実装するので、SACK状態を追跡するには、私たちの思考を導くためのマットマシスとジャムシードMahdaviに感謝します。
The first author would like to thank Ohio University and the Ohio University Internetworking Research Group for supporting the bulk of his work on this project.
最初の著者は、このプロジェクトに彼の仕事の大部分をサポートするためのオハイオ大学、オハイオ大学のインターネットワーキング研究グループに感謝したいと思います。
Normative References
引用規格
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年10月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2581] Allman, M., Paxson, V. and R. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V.およびR.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
Informative References
参考文献
[AHKO97] Mark Allman, Chris Hayes, Hans Kruse, Shawn Ostermann. TCP Performance Over Satellite Links. Proceedings of the Fifth International Conference on Telecommunications Systems, Nashville, TN, March, 1997.
[AHKO97]マーク・オールマン、クリス・ヘイズ、ハンス・クルーゼ、ショーンOstermann。衛星リンク上でTCPの性能。電気通信システム、ナッシュビル、テネシー州、1997年3月に第5回国際会議の議事録。
[All00] Mark Allman. A Web Server's View of the Transport Layer. ACM Computer Communication Review, 30(5), October 2000.
[All00]マークオールマン。トランスポート層のWeb Serverのビュー。 ACMコンピュータコミュニケーションレビュー、30（5）、2000年10月。
[FF96] Kevin Fall and Sally Floyd. Simulation-based Comparisons of Tahoe, Reno and SACK TCP. Computer Communication Review, July 1996.
[FF96]ケビン・秋とサリーフロイド。タホ、リノとSACK TCPのシミュレーションベースの比較。コンピュータコミュニケーションレビュー、1996年7月。
[Jac90] Van Jacobson. Modified TCP Congestion Avoidance Algorithm. Technical Report, LBL, April 1990.
【Jac90]バン・ジェイコブソン。変更されたTCPの輻輳回避アルゴリズム。テクニカルレポート、LBL、1990年4月。
[PF01] Jitendra Padhye, Sally Floyd. Identifying the TCP Behavior of Web Servers, ACM SIGCOMM, August 2001.
[PF01] Jitendra Padhye、サリーフロイド。 Webサーバー、ACM SIGCOMM、2001年8月のTCPの挙動を特定します。
[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
[RFC2582]フロイド、S.とT.ヘンダーソン、 "TCPの高速回復アルゴリズムにNewRenoの変更"、RFC 2582、1999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S.、 "輻輳制御の原理"、BCP 41、RFC 2914、2000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission Timer", RFC 2988, November 2000.
[RFC2988]パクソン、V.とM.オールマン、 "コンピューティングTCPの再送信タイマー"、RFC 2988、2000年11月。
[RFC3042] Allman, M., Balakrishnan, H, and S. Floyd, "Enhancing TCP's Loss Recovery Using Limited Transmit", RFC 3042, January 2001.
[RFC3042]オールマン、M.、バラクリシュナン、H、およびS.フロイド、 "株式会社トランスミットを使用したTCPの損失回復の強化"、RFC 3042、2001年1月。
Intellectual Property Rights Notice
知的財産権に関するお知らせ
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、または本仕様の実装者または利用者が、そのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Authors' Addresses
著者のアドレス
Ethan Blanton Purdue University Computer Sciences 1398 Computer Science Building West Lafayette, IN 47907
イーサンブラントンパデュー大学47907でコンピュータ・サイエンス1398コンピュータサイエンスビルウェストラファイエット、
EMail: eblanton@cs.purdue.edu
メールアドレス：eblanton@cs.purdue.edu
Mark Allman BBN Technologies/NASA Glenn Research Center Lewis Field 21000 Brookpark Rd. MS 54-5 Cleveland, OH 44135
マーク・オールマンBBNテクノロジーズ/ NASAグレンリサーチセンタールイス・フィールド21000ブルックパークRdを。 MS 54-5クリーブランド、オハイオ州44135
Phone: 216-433-6586 Fax: 216-433-8705 EMail: mallman@bbn.com http://roland.grc.nasa.gov/~mallman
電話：216-433-6586ファックス：216-433-8705 Eメール：mallman@bbn.com http://roland.grc.nasa.gov/~mallman
Kevin Fall Intel Research 2150 Shattuck Ave., PH Suite Berkeley, CA 94704
ケビン秋インテル研究2150シャタックアベニュー、PHスイートバークレー、CA 94704
EMail: kfall@intel-research.net
メールアドレス：kfall@intel-research.net
Lili Wang Laboratory for Advanced Networking 210 Hardymon Building University of Kentucky Lexington, KY 40506-0495
ケンタッキー州レキシントン、ケンタッキー州40506-0495の高度なネットワーク210 Hardymonビル大学リリー王研究所
EMail: lwang0@uky.edu
メールアドレス：lwang0@uky.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。