RFC3517 日本語訳
3517 A Conservative Selective Acknowledgment (SACK)-based LossRecovery Algorithm for TCP. E. Blanton, M. Allman, K. Fall, L. Wang. April 2003. (Format: TXT=27855 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループE.ブラントン要求をネットワークでつないでください: 3517年のパデュー大学カテゴリ: 規格は2003年4月にケンタッキーのM.オールマンBBN/NASA GRC K.秋のインテル研究L.ワング大学を追跡します。
A Conservative Selective Acknowledgment (SACK)-based
Loss Recovery Algorithm for TCP
TCPに、保守的な選択している承認(袋)ベースの損失回復アルゴリズム
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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のために保守的な損失回復アルゴリズムを提示します。 本書では提示されたアルゴリズムで、仕様(RFC2581)を現在の輻輳制御の精神に従わせますが、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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
Blanton, et al. Standards Track [Page 1] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[1ページ]。
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.
TCPの輻輳制御アルゴリズム[RFC2581、RFC2914]の精神に従えば、[RFC2581]は、高度な損失回復アルゴリズムがTCP[RFC793]によって使用されるのを許容します。 [RFC2582]がそのような回復の高度な1つについて概説するので、アルゴリズムは、NewRenoと呼びました。 このドキュメントはTCPの損失回復を機能アップするのにSACK[RFC2018]TCPオプションを使用する損失回復アルゴリズムを概説します。 本書では概説された大いに[FF96]で詳細なアルゴリズムに基づいたアルゴリズムは速い回復アルゴリズム[Jac90、RFC2581]の保守的な交換です。 本書では指定されたアルゴリズムは[RFC2581]でガイドラインセットに続いて、TCP実現に安全に使用できる簡単なSACKベースの損失回復戦略です。 implementersが適していると決めるように(交互のアルゴリズムが[RFC2581]に提供されたガイドラインに従う限り)TCPで交互のSACKベースの損失回復方法を使用できます。 しかしながら、主に輻輳制御アルゴリズムからこのドキュメント(何時に送るかなどのどんなセグメントがことである)における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"は累積的にそうである最も高いバイトに関するデータの一連番号です。与えられたポイントのACKed。
"HighData" is the highest sequence number transmitted at a given
point.
"HighData"は与えられたポイントで伝えられる中で最も高い一連番号です。
Blanton, et al. Standards Track [Page 2] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[2ページ]。
"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].
この仕様の目的のために、私たちはデータなしで到着するセグメントとHighACKの現行価値と等しい承認(ACK)番号と「写し承認」を定義します、[RFC2581]で説明されるように。
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つの写し承認になるように定義されます。 しかしながら、implementersは、DupThresh(または、値を決定するための方法)のために現行価値を決定するために[RFC2581]にどんなアップデートにも相談するはずです。
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送付者に関しては、それは、接続基礎あたりのaの入って来る選択している承認情報を格納するためにデータ構造を保たなければなりません。 そのようなデータ構造は一般的に「スコアボード」と呼ばれます。 このドキュメントのための範囲の外にスコアボードデータ構造の詳細があります(実現がこの仕様によって必要とされたすべての機能を実行できる限り)。
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接続の向こう側にデータの(マークします)個々の八重奏の話を移し続けるのをこのドキュメントが示すことに注意してください。 スコアボードの本当の世界実現は、一連番号が及んでこのデータを管理するのをおそらく好むでしょう。 ここに提示されたアルゴリズムは、これを許容しますが、気紛れな順番数の範囲が選択的に承認されたとして示されるのを必要とします。
Blanton, et al. Standards Track [Page 3] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[3ページ]。
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:
本書では定義されたアルゴリズムの目的のために、スコアボードSHOULDは以下の機能を実行します:
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かSACKedがスコアボードデータ構造でそれに従って、マークされるべきです、そして、八重奏SACKedの総数は記録されるべきです。
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情報は顧問です、そして、したがって、データが累積的に承認されるまで[RFC2018]、SACKedデータはTCPの「再-トランスミッション」バッファから取り除かれてはいけません。
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'がSACKedであるより大きい状態でDupThresh discontiguous SACKed系列が'SeqNum'か(DupThresh*SMSS)バイトより上で到着したとき、ルーチンは本当に戻ります。 さもなければ、ルーチンは虚偽で戻ります。
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の間のSACKedでない系列スペースの各八重奏'S1'に以下の方法を取ります:
(a) If IsLost (S1) returns false:
(a) IsLost(S1)が虚偽で戻るなら:
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).
この状態の効果はパイプがSACKedでない、また失われたと決心していないパケット(すなわち、ネットワークにはあるとまだ思われているそれらのセグメント)のために増加されるということです。
(b) If S1 <= HighRxt:
(b) S1<がHighRxtと等しいなら:
Pipe is incremented by 1 octet.
パイプは1つの八重奏で増加されます。
Blanton, et al. Standards Track [Page 4] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[4ページ]。
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.
無くなるのは考えられない再送された八重奏が二度上のメカニズムによって数えられることに注意してください。
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情報に基づいて何を伝えたらよいかを決定するためにUpdate()機能によって維持されたスコアボードデータ構造を使用します。 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) 'S2'が最もわずかなunSACKed一連番号に存在しているなら、それは損失を決定する以下の3つの評価基準を満たします、S2 MUSTを返しているSMSS八重奏までの始めの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はどんな容認されたSACKでもカバーされる中で最も高い八重奏以下です。
(1.c) IsLost (S2) returns true.
(1.c)IsLost(S2)は本当に戻ります。
(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) 利用可能なunsentデータが存在していますが、存在しているという規則(1)あたりの'S2'と広告を出している窓が許容する受信機のもの、系列が1つのセグメントを以前にのSMSS八重奏まで及ばせる一連番号でないなら、一連番号HighData+1から始まるunsentデータを返さなければなりません。
(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)のための状態であるなら失敗してくださいが、unSACKed一連番号ステップで与えられた損失を検出する評価基準を満たす'S3'が存在しています。(次に、S3 MAYを返しているSMSS八重奏までの始めの(特にステップ(1.c)を除いた)1つのセグメントを超えた1.a)と(1.b。)
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
規則(3)が一種の「再-トランスミッション」「切り札」であると述べてください。 送付者にセグメントが失われたというより少ない確実性がありさえするときさえ、一連番号の「再-トランスミッション」を考慮する、規則(1)のように。 規則(3)でセグメントを再送するのは、TCPのACK時計を支えるのを助けて、したがって、再送タイムアウトを避けるのを潜在的に助けることができます。 しかしながら、これらのセグメントを送る際に、送付者はネットワーク(そしてPipe見積りでも)にはコピー2部に関する同じデータがあると考えさせます。 ACKかSACKが到着するとき、これを覆っていると、セグメントは再送されました。
Blanton, et al. Standards Track [Page 5] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[5ページ]。
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.
送付者はちょうどどのくらいのデータが(パケットの2個のトランスミッションの1つかパケットのトランスミッションの両方)にネットワークを出たかを確信しているはずがありません。 したがって、送付者は2つのものの1つだけが持っているそれが可能であるときに両方のセグメントがネットワークを出たと考えるのによるPipeを過小評価するかもしれません。
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の領収書ではも、Update()ルーチンでスコアボードをアップデートしなければなりません。
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の領収書では、標準としてスコアボードをアップデートすることになっています。 以下に注意してください。 また、株式会社Transmitアルゴリズム[RFC3042]を使用することで以前にunsentなセグメントの送信の引き金となるのに1番目と第2写しACKsを使用できます。
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を受け取るとき、新しいSACK情報でスコアボードをアップデートしなければなりません。(Update())を通して。 前の損失出来事が全く接続のときに起こっていないか、または累積している承認ポイントがRecoveryPointの最終値を超えているなら、損失回収段階SHOULDが開始されて、速さであることに従って[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.
TCP送付者がこのデータ八重奏のために累積しているACKを受け取るとき、損失回収段階は終えられます。
Blanton, et al. Standards Track [Page 6] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[6ページ]。
(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].
混雑ウィンドウ(cwnd)と遅れた出発敷居(ssthresh)は半分の[RFC2581]あたりのFlightSizeまで減少します。
(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) 低下していると推定された最初のデータ・セグメントを再送してください--一連番号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.
現在、「パイプ」の傑出している八重奏の数に「パイプ」変数を設定してください。 これは送られましたが、どんな累積しているか選択している承認も受けていなくて、またデータが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) 損失回復の終わりのRecoveryPoint信号と損失回収段階より大きい一連番号のための入って来る累積しているACKを終えなければなりません。 損失回収段階を残すときHighACK SHOULD NOTの新しい値より大きい一連番号のためのスコアボードにクリアされていた状態で含まれたどんな情報。
(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)は、入って来るACKによって伝えられた新しいSACK情報を記録するのにUpdate()を使用します。
(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-->を運ぶのが1SMSSと等しいなら、送付者SHOULDは以下の1つ以上のセグメントを伝えます:
(C.1) The scoreboard MUST be queried via NextSeg () for the
sequence number range of the next segment to transmit (if any),
(C.1) 次のセグメントの一連番号範囲が伝わる(もしあれば)ようにNextSeg()を通してスコアボードについて質問しなければなりません。
Blanton, et al. Standards Track [Page 7] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[7ページ]。
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).
そして、与えられたセグメントは発信しました。 何も送らないで、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.
HighDataの下にもしあれば送られたデータ八重奏(C.1)の(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.
HighDataの上にもしあれば送られたデータ八重奏(C.1)の(C.3)があって、以前にunsentなデータの伝達を反映するために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.1)で伝えられた八重奏の数に従って、増加しているパイプはネットワークへの未払いのデータ量の見積りの(C.4)をアップデートしなければなりません。
(C.5) If cwnd - pipe >= 1 SMSS, return to (C.1)
(C.5) cwnd-->を運ぶのが1SMSSと等しいなら戻る、戻ります。(C.1)
5.1 Retransmission Timeouts
5.1 Retransmissionタイムアウト
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送付者SHOULDが「タイムアウトは、データ受信装置が手を引いたのを示すかもしれない」ので再送タイムアウトに受信機から集められたSACK情報を梢消するのを示します。 さらに、TCP送付者は「どのデータを再送したらよいかを決定する際に先のSACK情報を無視しなければなりません」。 しかしながら、SACK TCP送付者SHOULDはまだ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が、より開始されるまで、さらに、新しい回収段階(セクション5で説明されるように)を開始してはいけません。RecoveryPointの新しい値。
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()SHOULDは、ACKsを受け取り次第適切に使用され続けています。 これで、遅れた出発回復の期間は受信機によって提供されたすべての入手可能な情報の利益を得ることができるでしょう、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
再送されたセグメントの処理に続く受信機のバッファからなくなったセグメントがあると、対応するACKはSACK情報を含むでしょう。 この場合どんなデータがそれぞれ送られるべきであるかを決定するとき、TCP送付者SHOULDはこのSACK情報を使用します。
Blanton, et al. Standards Track [Page 8] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[8ページ]。
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.
遅れた出発のセグメント。 この選択のための正確なアルゴリズムは本書では指定されません(明確に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アルゴリズムが本書では見積り人の振舞いに影響を与えることができるという事実のため、implementersは、タイマがどのように管理されるかを考えたがっているかもしれません。 累積しているACKポイントを進めるACKが到着するたびに[RFC2988]は、RTOタイマが再軍備するように求めます。 本書では提示されたアルゴリズムが保たれることができるので、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管理を使用するために緯度をimplementersに与えるか、または任意に、回復の間に送られる各「再-トランスミッション」の上の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]と共にこの論文にシェアセキュリティ問題を提示しました。 主要な違いはSACKsに基づくアルゴリズムがTCP送付者にcwndを減少させるように写しACKsを鍛造する攻撃者に対して、より強健であるということです。 SACKsがあるので、TCP送付者には、追加チェックが特定のACKが正統であるかどうかあります。 きわめて簡単でない間、SACKはいくらかの量の保護をこの領域に提供します。
Blanton, et al. Standards Track [Page 9] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[9ページ]。
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]にケビンFallとサリー・フロイドによって概説されたアルゴリズムに基づいています、このドキュメントの作者は上のテキストにおけるどんな誤りへの責任も負いますが。 Murali Bashyam、ケン・カルバート、トム・ヘンダーソン、ライナー・ラドウィグ、Jamshid Mahdavi、マット・マシス、ショーン・オステルマン、バーン・パクソン、およびヴェンカトVenkatsubraはこのドキュメントの以前のバージョンの有益なフィードバックを提供しました。 私たちは、ナノ秒にスコアボードを実行して、したがって、SACK状態の動向をおさえる際に私たちの考えを誘導して頂いて、マット・マシスと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.
第1代作者は、このプロジェクトに対する彼の仕事の大半を支持して頂いて、オハイオ大学とオハイオ大学Internetworking Research Groupに感謝したがっています。
Normative References
引用規格
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC793] ポステル、J.、「通信制御プロトコル」、STD7、RFC793、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の選択している承認オプション」、RFC2018、1996年10月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
[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月。
[RFC2581] Allman, M., Paxson, V. and R. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2581] オールマンとM.とパクソンとV.とR.スティーブンス、「TCP輻輳制御」、RFC2581、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年のナッシュビル(テネシー)の行進の情報通信システムにおける第5国際会議の議事。
[All00] Mark Allman. A Web Server's View of the Transport Layer.
ACM Computer Communication Review, 30(5), October 2000.
[All00]はオールマンをマークします。 ウェブサーバーのトランスポート層の視点。 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] ケビンFallとSallyフロイド。 タホ、リノ、および袋のTCPのシミュレーションベースの比較。 1996年7月のコンピュータコミュニケーションレビュー。
Blanton, et al. Standards Track [Page 10] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[10ページ]。
[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、フロイドを出撃させてください。 2001年8月にウェブサーバー、ACM SIGCOMMの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変更」、RFC2582、1999年4月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC
2914, September 2000.
[RFC2914]フロイド、S.、「輻輳制御プリンシプルズ」、BCP41、RFC2914、2000年9月。
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000.
[RFC2988] パクソンとV.とM.オールマン、「コンピューティングTCPの再送信タイマー」、RFC2988、2000年11月。
[RFC3042] Allman, M., Balakrishnan, H, and S. Floyd, "Enhancing TCP's
Loss Recovery Using Limited Transmit", RFC 3042, January
2001.
[RFC3042] オールマン、M.、Balakrishnan、H、およびS.フロイド、「株式会社を使用することでTCPの損失回復を機能アップして、伝わってください」、RFC3042、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はどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、または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専務に情報を記述してください。
Blanton, et al. Standards Track [Page 11] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[11ページ]。
Authors' Addresses
作者のアドレス
Ethan Blanton Purdue University Computer Sciences 1398 Computer Science Building West Lafayette, IN 47907
47907におけるイーサン・ブラントン・パデュー大学コンピューターサイエンシズ1398コンピュータサイエンスBuildingウェストラフィエット
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グレンリサーチセンタルイス分野21000Brookpark通り MS54-5クリーブランド、OH 44135
Phone: 216-433-6586 Fax: 216-433-8705 EMail: mallman@bbn.com http://roland.grc.nasa.gov/~mallman
以下に電話をしてください。 216-433-6586 Fax: 216-433-8705 メールしてください: mallman@bbn.com http://roland.grc.nasa.gov/~mallman
Kevin Fall Intel Research 2150 Shattuck Ave., PH Suite Berkeley, CA 94704
ケビン秋のインテルの研究2150シャタックAve、PH Suiteバークレー、カリフォルニア 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の高度なネットワーク210Hardymonビル大学のためのリリーワング研究所
EMail: lwang0@uky.edu
メール: lwang0@uky.edu
Blanton, et al. Standards Track [Page 12] RFC 3517 SACK-based Loss Recovery for TCP April 2003
ブラントン、他 規格は2003年4月にTCPのためにRFC3517の袋のベースの損失回復を追跡します[12ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Blanton, et al. Standards Track [Page 13]
ブラントン、他 標準化過程[13ページ]
一覧
スポンサーリンク
