RFC 3517 - A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3517
タイトル : RFC 3517 - TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム
翻訳編集 : 自動生成

[要約] 要約： RFC 3517は、TCPの損失回復アルゴリズムであるSACKを改善するための保守的な手法を提案しています。目的： - TCPのパフォーマンスを向上させるために、SACKベースの損失回復アルゴリズムを改善する。 - ネットワークの過負荷やパケットロスに対してより効果的な対策を提供する。 - データ転送の信頼性と効率性を向上させる。

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

TCPの保守的な選択的承認（SACK）ベースの損失回復アルゴリズム

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）の現在のエディションを参照してください。このメモの配布は無制限です。

著作権表示

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].

「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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]、再送信と混雑管理の決定を行う際にホストがSACK情報を使用していないという証拠があります[PF01]。このドキュメントの目標は、TCP実装がサック情報を使用してパフォーマンスを向上させるための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の混雑制御アルゴリズム[RFC2581、RFC2914]の精神に従うことを条件に、TCP [RFC793]で使用される高度な損失回復アルゴリズムを使用できます。[RFC2582]は、NewRenoと呼ばれるこのような高度な回復アルゴリズムの1つを概説しています。このドキュメントは、TCPの損失回復を強化するためにSACK [RFC2018] TCPオプションを使用する損失回復アルゴリズムの概要を説明します。このドキュメントで概説されているアルゴリズムは、[FF96]に詳述されているアルゴリズムに大きく基づいており、高速回復アルゴリズム[JAC90、RFC2581]の保守的な置き換えです。このドキュメントで指定されているアルゴリズムは、[RFC2581]に設定されたガイドラインに従う簡単なサックベースの損失回復戦略であり、TCP実装で安全に使用できます。代替のサックベースの損失回復方法は、実装者が適合を見るためにTCPで使用できます（別のアルゴリズムが[RFC2581]で提供されるガイドラインに従う限り）。ただし、このドキュメントのサックベースの決定（セグメントが何時に送信されるかなど）は、輻輳制御アルゴリズムから主に分離されているため、必要に応じて別々の問題として扱うことができます。

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.

「ハイアック」は、特定のポイントで累積的にアクセスされたデータの最高バイトのシーケンス番号です。

"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".

「Pipe」は、ネットワーク内の未払いのバイト数の送信者の見積もりです。これは、送信者の送信率を制限するために回復中に使用されます。パイプ変数により、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]に記載されているように、データなしと承認（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つの重複謝辞であると定義されています。ただし、実装者は[RFC2581]に更新を参照して、Dupthreshの現在の値（またはその値を決定する方法）を決定する必要があります。

Finally, a range of sequence numbers [A,B] is said to "cover" sequence number S if A <= S <= B.

最後に、A <= S <= Bの場合、シーケンス番号[A、B]の範囲は「カバー」シーケンス番号sと言われています。

3 Keeping Track of SACK Information

3サック情報を追跡します

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サック情報の処理と行動

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で提供される情報を考えると、スコアボードデータ構造で累積的にAckedまたは略奪された各オクテットにそれに応じてマークする必要があり、略奪されたオクテットの総数を記録する必要があります。

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.

このルーチンは、指定されたシーケンス番号が失われたと見なされるかどうかを返します。ルーチンは、「seqnum」を超える「seqnum」の（dupthresh * smss）バイトの上にdupthreshの不連続な略奪されたシーケンスが「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:

このルーチンは、ハイックからハイダタまでシーケンス空間を通過し、「パイプ」変数を、TCP送信者とTCPレシーバーの間で現在輸送中のオクテットの数の推定値に設定する必要があります。パイプを初期化してゼロにした後、略奪されていないハイアックとハイダタの間のシーケンススペースの各オクテット '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:

このルーチンは、更新（）関数によって維持されるスコアボードデータ構造を使用して、データ受信機から届いたサック情報に基づいて送信するものを決定します（したがって、スコアボードにマークされています）。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.

(1) 損失を決定するための次の3つの基準を満たす最小の未払いのシーケンス番号「S2」が存在する場合、S2から始まるUP最大SMSオクテットの1つのセグメントのシーケンス範囲を返す必要があります。

(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は、受け取った袋で覆われた最高のオクテットよりも少ない。

(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) ルール（1）ごとにシーケンス番号「S2」が存在しないが、利用可能な未使用データが存在し、受信機の広告ウィンドウが許可されている場合、シーケンス番号HighData 1から始まる以前に非定期データのUP最大SMSSオクテットのシーケンス範囲を返す必要があります。。

(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）および（1.b）で与えられた損失を検出する基準を満たす未払いのシーケンス番号「S3」が存在する場合（具体的にはステップを除く。（1.C））次に、S3から始まる最大SMSSオクテットの1つのセグメントを返すことができます。

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.

ルール（3）は一種の再送信「最後の手段」であることに注意してください。これにより、送信者がルール（1）と同様にセグメントが失われていない場合でも、シーケンス番号の再送信が可能になります。ルール（3）を介してセグメントを再送信することは、TCPのACKクロックを維持するのに役立つため、再送信のタイムアウトを回避するのに役立ちます。ただし、これらのセグメントを送信する際に、送信者は、ネットワーク内にあると見なされる同じデータのコピーを2つ持っています（また、パイプの推定）。この再送信セグメントをカバーするACKまたはサックが到着すると、送信者はネットワークを離れるデータの量を正確に確認できません（パケットの2つの送信またはパケットの両方の送信）。したがって、送信者は、両セグメントが2つのうちの1つだけが持っている可能性がある場合、両方のセグメントがネットワークを離れることを検討することにより、パイプを過小評価することができます。

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.

注：このドキュメントで概説されているサックベースの損失回復アルゴリズムには、以前の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）Acksの重複を受け取ると、スコアボードは通常どおり更新されます。注：第1および2番目の重複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 Acksに対応する重複ACKを受信する場合、スコアボードは新しいサック情報（update（）を介して）で更新する必要があります。接続で以前の損失イベントが発生していない場合、または[RFC2581]で概説されている高速再送信アルゴリズムに従って、回復ポイントの最後の値を超えて累積的な確認ポイントを超えていない場合。次の手順をとる必要があります。

(1) RecoveryPoint = HighData

When the TCP sender receives a cumulative ACK for this data octet the loss recovery phase is terminated.

TCP送信者がこのデータに対して累積ACKを受信すると、損失回復フェーズが終了します。

   (2) ssthresh = cwnd = (FlightSize / 2)

The congestion window (cwnd) and slow start threshold (ssthresh) are reduced to half of FlightSize per [RFC2581].

輻輳ウィンドウ（CWND）とスロースタートしきい値（SSthresh）は、[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から始まるセグメント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.

「パイプ」のオクテットの数に「パイプ」変数を「パイプ内の」に設定します。これは、TCP送信者によって送信されたが、累積的または選択的な確認が受信されておらず、データがネットワークで削除されたと判断されていないデータです。データはまだネットワークパスを通過していると想定されています。

(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）回復ポイントよりも大きいシーケンス番号の着信累積ACKは、損失回復の終了と損失回復段階を終了する必要があります。スコアボードに含まれるシーケンス番号の情報は、Loss Recolaryフェーズを離れるときにクリアされるべきではありません。

(B) Upon receipt of an ACK that does not cover RecoveryPoint the following actions MUST be taken:

（b）RecoveryPointをカバーしていないACKを受け取ったら、次のアクションを実行する必要があります。

(B.1) Use Update () to record the new SACK information conveyed by the incoming ACK.

（b.1）update（）を使用して、着信ACKによって伝えられた新しいサック情報を記録します。

(B.2) Use SetPipe () to re-calculate the number of octets still in the network.

（B.2）SetPipe（）を使用して、ネットワーク内のオクテットの数を再計算します。

（c）cwnd -pipe> = 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.1）スコアボードは、次のセグメントのシーケンス番号範囲（存在する場合）のシーケンス番号範囲を介して照会する必要があり、特定のセグメントが送信されます。nextseg（）が障害を返す場合（送信するデータはありません）、何も送信せずに返されます（つまり、手順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.2）（c.1）に送信されたデータのいずれかがhighdataを下回っている場合、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.3）（c.1）に送信されたオクテットのいずれかが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)

5.1 Retransmission Timeouts

5.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送信者が再送信タイムアウト時にレシーバーから収集されたサック情報を抹消する必要があることを示唆しています。さらに、TCP送信者は「再送信するデータを決定する際に、以前の袋情報を無視する」必要があります。ただし、sack TCP送信者は、RTOに続く損失回復の遅いスタートフェーズ中に利用可能になったすべてのサック情報を使用する必要があります。

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の新しい値を保存する必要があり、このドキュメントで概説されている損失回収アルゴリズムを終了する必要があります。さらに、（セクション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で説明されているように、Update（）はACKの受領時に適切に使用し続ける必要があります。これにより、RTOのためにSACK情報が削除されたという事実にもかかわらず、ゆっくりと開始回復期間が受信機から提供されるすべての利用可能な情報の恩恵を受けることができます。

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には袋情報が含まれます。この場合、TCP送信者は、スロースタートの各セグメントで送信されるデータを決定する際に、このサック情報を使用する必要があります。この選択の正確なアルゴリズムは、このドキュメントでは指定されていません（具体的には、RTO後のスロースタート中はnextseg（）は不適切です）。欠落していると報告されているシーケンス空間を「埋める」ための比較的簡単なアプローチは、合理的なアプローチでなければなりません。

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アルゴリズムが推定器の動作に影響を与える可能性があるという事実により、実装者はタイマーの管理方法を検討したい場合があります。[RFC2988]は、累積ACKポイントを前進させるACKが到着するたびにRTOタイマーを再武装することを求めています。このドキュメントで提示されたアルゴリズムは、ACKクロックをかなり重要な損失イベント（[RFC2581]で説明したアルゴリズムよりも比較的長い）を維持できるため、一部のネットワークでは、損失イベントはRTOよりも長持ちする可能性があります。この場合、RTOタイマーは時期尚早に期限切れになり、再送信する必要のないセグメントがresします。

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]で指定されているよりも保守的なタイマーを提供するため、必ずしも魅力的な代替手段であるとは限りません。ただし、場合によっては、不必要な再送信、Go-Back-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 RENO [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]とセキュリティ上の考慮事項を共有しています。重要な違いは、サックに基づくアルゴリズムが、TCP送信者にCWNDの削減を強制するように重複するAcksを偽造する攻撃者に対してより堅牢であることです。Sacksを使用すると、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]のKevin FallとSally Floydが概説したアルゴリズムに大まかに基づいていますが、このドキュメントの著者は上記のテキストの間違いの責任を負います。Murali Bashyam、Ken Calvert、Tom Henderson、Reiner Ludwig、Jamshid Mahdavi、Matt Mathis、Shawn Ostermann、Vern Paxson、Venkat Venkatsubraは、この文書の以前のバージョンに関する貴重なフィードバックを提供しました。NSでスコアボードを実装してくれたMatt MathisとJamshid 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] Postel、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] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP Selective Aumponredcement Options」、RFC 2018、1996年10月。

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026] Bradner、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2581] Allman, M., Paxson, V. and R. Stevens, "TCP Congestion Control", RFC 2581, April 1999.

[RFC2581] Allman、M.、Paxson、V。and R. Stevens、「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]マーク・オールマン、クリス・ヘイズ、ハンス・クルーゼ、ショーン・オスターマン。衛星リンク上の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サーバーのビュー。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]ケビンフォールとサリーフロイド。タホ、リノ、サック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、Sally Floyd。WebサーバーのTCP動作の識別、ACM Sigcomm、2001年8月。

[RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to TCP's Fast Recovery Algorithm", RFC 2582, April 1999.

[RFC2582] Floyd、S。およびT. Henderson、「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] Paxson、V。およびM. Allman、「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] Allman、M.、Balakrishnan、H、およびS. Floyd、「限定送信を使用した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

イーサンブラントンパデュー大学コンピューターサイエンス1398コンピューターサイエンスビル、ウェストラファイエット、47907

   EMail: 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 Brookpark Rd。MS 54-5クリーブランド、OH 44135

   Phone: 216-433-6586
   Fax: 216-433-8705
   EMail: mallman@bbn.com
   http://roland.grc.nasa.gov/~mallman

Kevin Fall Intel Research 2150 Shattuck Ave., PH Suite Berkeley, CA 94704

Kevin Fall Intel Research 2150 Shattuck Ave.、PH Suite Berkeley、CA 94704

   EMail: kfall@intel-research.net

Lili Wang Laboratory for Advanced Networking 210 Hardymon Building University of Kentucky Lexington, KY 40506-0495

高度なネットワーキングのためのリリワン研究所210ハーディモンビルケンタッキー大学レキシントン大学40506-0495

   EMail: lwang0@uky.edu

Full Copyright Statement

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。