RFC2018 日本語訳
2018 TCP Selective Acknowledgment Options. M. Mathis, J. Mahdavi, S.Floyd, A. Romanow. October 1996. (Format: TXT=25671 bytes) (Obsoletes RFC1072) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Mathis
Request for Comments: 2018 J. Mahdavi
Category: Standards Track PSC
S. Floyd
LBNL
A. Romanow
Sun Microsystems
October 1996
コメントを求めるワーキンググループM.マシス要求をネットワークでつないでください: 2018年のJ.Mahdaviカテゴリ: 標準化過程PSC S.フロイドLBNL A.Romanowサン・マイクロシステムズ1996年10月
TCP Selective Acknowledgment Options
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)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
TCP may experience poor performance when multiple packets are lost from one window of data. With the limited information available from cumulative acknowledgments, a TCP sender can only learn about a single lost packet per round trip time. An aggressive sender could choose to retransmit packets early, but such retransmitted segments may have already been successfully received.
複数のパケットがデータの1つの窓から失われているとき、TCPは不十分な性能を経験するかもしれません。 累積している承認によって利用可能な限られた情報で、TCP送付者は周遊旅行時間あたり1つの単一の無くなっているパケットに関して学ぶことができるだけです。 攻撃的な送付者は、早くパケットを再送するのを選ぶことができましたが、既に首尾よくそのような再送されたセグメントを受け取ったかもしれません。
A Selective Acknowledgment (SACK) mechanism, combined with a selective repeat retransmission policy, can help to overcome these limitations. The receiving TCP sends back SACK packets to the sender informing the sender of data that has been received. The sender can then retransmit only the missing data segments.
選択している反復「再-トランスミッション」方針に結合したSelective Acknowledgment(SACK)メカニズムは、これらの限界を克服するのを助けることができます。 受信TCPは受け取られたデータについて送付者に知らせる送付者に逆SACKパケットを送ります。 そして、送付者は欠測値セグメントしか再送できません。
This memo proposes an implementation of SACK and discusses its performance and related issues.
このメモは、SACKの実現を提案して、性能について議論して、問題を関係づけました。
Acknowledgements
承認
Much of the text in this document is taken directly from RFC1072 "TCP Extensions for Long-Delay Paths" by Bob Braden and Van Jacobson. The authors would like to thank Kevin Fall (LBNL), Christian Huitema (INRIA), Van Jacobson (LBNL), Greg Miller (MITRE), Greg Minshall (Ipsilon), Lixia Zhang (XEROX PARC and UCLA), Dave Borman (BSDI), Allison Mankin (ISI) and others for their review and constructive comments.
テキストの多くが本書ではそうです。直接RFC1072から、ボブ・ブレーデンとヴァン・ジェーコブソンが「長時間の遅延経路のためのTCP拡張子」を取ります。 作者は彼らのレビューと建設的なコメントについてケビンFall(LBNL)、クリスチャンのHuitema(INRIA)、ヴァン・ジェーコブソン(LBNL)、グレッグ・ミラー(MITRE)、グレッグMinshall(Ipsilon)、Lixiaチャン(XEROX PARCとUCLA)、デーヴ・ボーマン(BSDI)、アリソン・マンキン(ISI)、および他のものに感謝したがっています。
Mathis, et. al. Standards Track [Page 1] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[1ページ]RFC2018TCP
1. Introduction
1. 序論
Multiple packet losses from a window of data can have a catastrophic effect on TCP throughput. TCP [Postel81] uses a cumulative acknowledgment scheme in which received segments that are not at the left edge of the receive window are not acknowledged. This forces the sender to either wait a roundtrip time to find out about each lost packet, or to unnecessarily retransmit segments which have been correctly received [Fall95]. With the cumulative acknowledgment scheme, multiple dropped segments generally cause TCP to lose its ACK-based clock, reducing overall throughput.
データの窓からの複数のパケット損失がTCPスループットに壊滅的な影響を与えることができます。 窓を受けてください。TCPが容認されたセグメントが左を斜めに進まない累積している承認計画を使用する、[Postel81]承認されません。 これによって、送付者はやむを得ずそれぞれの無くなっているパケットを見つけるか、または不必要に正しく受け取られたセグメント[Fall95]を再送する往復の時間を待ちます。 一般に、累積している承認計画で、複数の低下しているセグメントで、総合的なスループットを減らして、TCPはACKベースの時計をなくします。
Selective Acknowledgment (SACK) is a strategy which corrects this behavior in the face of multiple dropped segments. With selective acknowledgments, the data receiver can inform the sender about all segments that have arrived successfully, so the sender need retransmit only the segments that have actually been lost.
選択しているAcknowledgment(SACK)は複数の低下しているセグメントに直面してこの振舞いを修正する戦略です。 選択している承認で、データ受信装置が首尾よく到着したすべてのセグメントに関して送付者に知らせることができるので、送付者は実際に失われたセグメントだけを再送しなければなりません。
Several transport protocols, including NETBLT [Clark87], XTP [Strayer92], RDP [Velten84], NADIR [Huitema81], and VMTP [Cheriton88] have used selective acknowledgment. There is some empirical evidence in favor of selective acknowledgments -- simple experiments with RDP have shown that disabling the selective acknowledgment facility greatly increases the number of retransmitted segments over a lossy, high-delay Internet path [Partridge87]. A recent simulation study by Kevin Fall and Sally Floyd [Fall95], demonstrates the strength of TCP with SACK over the non-SACK Tahoe and Reno TCP implementations.
いくつかのトランスポート・プロトコルのNETBLT[Clark87]を含んでいるXTP[Strayer92]、RDP[Velten84]、NADIR[Huitema81]、およびVMTP[Cheriton88]は選択している承認を使用しました。 何らかの実証的証拠が選択している承認を支持してあります--RDPとの簡単な実験は、選択している承認施設を無効にすると再送されたセグメントの数が損失性高遅れインターネット経路[Partridge87]の上で大いに増加するのを示しました。 最近のシミュレーションは、ケビンFallとサリー・フロイド[Fall95]で研究して、非SACKタホとリノTCP実現の上のSACKと共にTCPの強さを示します。
RFC1072 [VJ88] describes one possible implementation of SACK options for TCP. Unfortunately, it has never been deployed in the Internet, as there was disagreement about how SACK options should be used in conjunction with the TCP window shift option (initially described RFC1072 and revised in [Jacobson92]).
RFC1072[VJ88]はTCPのためにSACKオプションの1つの可能な実現について説明します。 残念ながら、それはインターネットで一度も配備されたことがありません、SACKオプションがどうTCP窓のシフトオプション(初めは、RFC1072について説明して、[Jacobson92]で復習する)に関連して使用されるべきであるかに関して不一致があったとき。
We propose slight modifications to the SACK options as proposed in RFC1072. Specifically, sending a selective acknowledgment for the most recently received data reduces the need for long SACK options [Keshav94, Mathis95]. In addition, the SACK option now carries full 32 bit sequence numbers. These two modifications represent the only changes to the proposal in RFC1072. They make SACK easier to implement and address concerns about robustness.
私たちはRFC1072で提案されるようにSACKオプションへのわずかな変更を提案します。 明確に、最も最近受信されたデータのための選択している承認を送ると、長いSACKオプション[Keshav94、Mathis95]の必要性は減少します。 さらに、SACKオプションは今、32ビットの完全な一連番号を運びます。 これらの2つの変更がRFC1072での提案への唯一の変化を表します。 彼らで、SACKは丈夫さに関して実行して、危惧に対処するのが、より簡単になります。
The selective acknowledgment extension uses two TCP options. The first is an enabling option, "SACK-permitted", which may be sent in a SYN segment to indicate that the SACK option can be used once the connection is established. The other is the SACK option itself, which may be sent over an established connection once permission has been given by SACK-permitted.
選択している承認拡大は2つのTCPオプションを使用します。 1番目は接続がいったん確立されるとSACKオプションを使用できるのを示すためにSYNセグメントで送られるかもしれない可能な「袋で受入れられた」オプションです。 もう片方がSACKオプション自体です。(SACKによって可能にされることでいったん許可を与えると、確立した接続の上にそのオプションを送るかもしれません)。
Mathis, et. al. Standards Track [Page 2] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[2ページ]RFC2018TCP
The SACK option is to be included in a segment sent from a TCP that is receiving data to the TCP that is sending that data; we will refer to these TCP's as the data receiver and the data sender, respectively. We will consider a particular simplex data flow; any data flowing in the reverse direction over the same connection can be treated independently.
SACKオプションはデータを受け取っているTCPからそのデータを送るTCPに送られたセグメントで含まれることです。 私たちはそれぞれこれらへのデータ受信装置としてのTCPとデータ送付者を参照するつもりです。 私たちは、特定のシンプレクスがデータフローであると考えるつもりです。 独自に同じ接続の上を反対の方向に流れるどんなデータも扱うことができます。
2. Sack-Permitted Option
2. 袋で受入れられたオプション
This two-byte option may be sent in a SYN by a TCP that has been extended to receive (and presumably process) the SACK option once the connection has opened. It MUST NOT be sent on non-SYN segments.
接続がいったん開くと、この2バイトのオプションはSYNでSACKオプションを受け取る(おそらく、処理する)ために広げられたTCPによって送られるかもしれません。 非SYNセグメントでそれを送ってはいけません。
TCP Sack-Permitted Option:
TCPはオプションを袋で可能にしました:
Kind: 4
種類: 4
+---------+---------+
| Kind=4 | Length=2|
+---------+---------+
+---------+---------+ | 種類=4| 長さ=2| +---------+---------+
3. Sack Option Format
3. 袋のオプション形式
The SACK option is to be used to convey extended acknowledgment information from the receiver to the sender over an established TCP connection.
SACKオプションは受信機から送付者まで確立したTCP接続の上に拡張承認情報を伝えるのに使用されることです。
TCP SACK Option:
TCPはオプションを略奪します:
Kind: 5
種類: 5
Length: Variable
長さ: 変数
+--------+--------+
| Kind=5 | Length |
+--------+--------+--------+--------+
| Left Edge of 1st Block |
+--------+--------+--------+--------+
| Right Edge of 1st Block |
+--------+--------+--------+--------+
| |
/ . . . /
| |
+--------+--------+--------+--------+
| Left Edge of nth Block |
+--------+--------+--------+--------+
| Right Edge of nth Block |
+--------+--------+--------+--------+
+--------+--------+ | 種類=5| 長さ| +--------+--------+--------+--------+ | 最初のブロックの左の縁| +--------+--------+--------+--------+ | 最初のブロックの正しい縁| +--------+--------+--------+--------+ | | / . . . / | | +--------+--------+--------+--------+ | n番目のBlockのEdgeに残されます。| +--------+--------+--------+--------+ | n番目のBlockの右のEdge| +--------+--------+--------+--------+
Mathis, et. al. Standards Track [Page 3] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[3ページ]RFC2018TCP
The SACK option is to be sent by a data receiver to inform the data sender of non-contiguous blocks of data that have been received and queued. The data receiver awaits the receipt of data (perhaps by means of retransmissions) to fill the gaps in sequence space between received blocks. When missing segments are received, the data receiver acknowledges the data normally by advancing the left window edge in the Acknowledgement Number Field of the TCP header. The SACK option does not change the meaning of the Acknowledgement Number field.
SACKオプションはデータ受信装置で送って、受け取られて、列に並ばせられた非隣接のブロックのデータについてデータ送付者に知らせることです。 データ受信装置は、受信されたブロックの間の系列スペースに不足をいっぱいにするためにデータ(恐らく「再-トランスミッション」による)の領収書を待ちます。 なくなったセグメントが受け取られているとき、通常、データ受信装置は、TCPヘッダーのAcknowledgement Number Fieldにおける左の窓の縁を進めることによって、データを承認します。 SACKオプションはAcknowledgement Number分野の意味を変えません。
This option contains a list of some of the blocks of contiguous sequence space occupied by data that has been received and queued within the window.
このオプションは窓の中に受け取られて、列に並ばせられたデータで隣接の系列使用船腹のいくつかのブロックのリストを含みます。
Each contiguous block of data queued at the data receiver is defined in the SACK option by two 32-bit unsigned integers in network byte order:
データ受信装置に列に並ばせられたそれぞれの隣接のデータは2つの32ビットの符号のない整数によってSACKオプションでネットワークバイトオーダーで定義されます:
* Left Edge of Block
* ブロックの左の縁
This is the first sequence number of this block.
これはこのブロックの最初の一連番号です。
* Right Edge of Block
* ブロックの正しい縁
This is the sequence number immediately following the last
sequence number of this block.
これはすぐにこのブロックの最後の一連番号に続く一連番号です。
Each block represents received bytes of data that are contiguous and isolated; that is, the bytes just below the block, (Left Edge of Block - 1), and just above the block, (Right Edge of Block), have not been received.
各ブロックは容認されたバイトの隣接の、そして、孤立しているデータを表します。 すなわち、(BlockのEdgeに残されました--1)というブロックのすぐ下と、そして、ブロックのすぐ上のバイト(Blockの右のEdge)は受け取られていません。
A SACK option that specifies n blocks will have a length of 8*n+2 bytes, so the 40 bytes available for TCP options can specify a maximum of 4 blocks. It is expected that SACK will often be used in conjunction with the Timestamp option used for RTTM [Jacobson92], which takes an additional 10 bytes (plus two bytes of padding); thus a maximum of 3 SACK blocks will be allowed in this case.
nブロックを指定するSACKオプションが8*nの長さを+2バイト持つので、TCPオプションに有効な40バイトは最大4ブロックを指定できます。 SACKがしばしば追加10バイト取る(2バイトの詰め物)RTTM[Jacobson92]に使用されるTimestampオプションに関連して使用されると予想されます。 したがって、最大3つのSACKブロックがこの場合許されるでしょう。
The SACK option is advisory, in that, while it notifies the data sender that the data receiver has received the indicated segments, the data receiver is permitted to later discard data which have been reported in a SACK option. A discussion appears below in Section 8 of the consequences of advisory SACK, in particular that the data receiver may renege, or drop already SACKed data.
SACKオプションは顧問です、データ受信装置が示されたセグメントを受けたことをデータ送付者に通知している間、データ受信装置が後でSACKオプションで報告されたデータを捨てることが許可されているので。 議論は、顧問SACKの結果のセクション8、特定にデータ受信装置が手を引くか、または既にSACKedデータを落とすかもしれないのを以下に現れさせます。
Mathis, et. al. Standards Track [Page 4] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[4ページ]RFC2018TCP
4. Generating Sack Options: Data Receiver Behavior
4. 袋のオプションを発生させます: データ受信装置の振舞い
If the data receiver has received a SACK-Permitted option on the SYN for this connection, the data receiver MAY elect to generate SACK options as described below. If the data receiver generates SACK options under any circumstance, it SHOULD generate them under all permitted circumstances. If the data receiver has not received a SACK-Permitted option for a given connection, it MUST NOT send SACK options on that connection.
データ受信装置がこの接続のためにSYNにSACKによって可能にされたオプションを受け取ったなら、データ受信装置は、以下で説明されるようにSACKオプションを発生させるのを選ぶかもしれません。 受信機はデータであるならどんな状況の下でのSACKオプションを発生させて、それはSHOULDです。すべての受入れられた状況でそれらを発生させてください。 データ受信装置が与えられた接続のためにSACKによって可能にされたオプションを受け取っていないなら、それはその接続のときにオプションをSACKに送ってはいけません。
If sent at all, SACK options SHOULD be included in all ACKs which do not ACK the highest sequence number in the data receiver's queue. In this situation the network has lost or mis-ordered data, such that the receiver holds non-contiguous data in its queue. RFC 1122, Section 4.2.2.21, discusses the reasons for the receiver to send ACKs in response to additional segments received in this state. The receiver SHOULD send an ACK for every valid segment that arrives containing new data, and each of these "duplicate" ACKs SHOULD bear a SACK option.
少しでも送るなら、SACKは含まれているコネがすべて、どんなデータ受信装置の待ち行列で最も高い一連番号のACKもしないACKsであったならSHOULDにゆだねます。 ネットワークが失ったこの状況か誤規則正しいデータ、受信機が待ち行列における非隣接のデータを保持するようなもので。 RFC、1122 セクション4.2 .2 .21 受信機がこの状態に受け取られた追加セグメントに対応してACKsを送る理由について議論します。 受信機SHOULDは新しいデータを含んでいて、到着するあらゆる有効なセグメントのためにACKを送ります、そして、それぞれのこれらの「写し」ACKs SHOULDはSACKオプションを示します。
If the data receiver chooses to send a SACK option, the following rules apply:
データ受信装置が、SACKオプションを送るのを選ぶなら、以下の規則は適用されます:
* The first SACK block (i.e., the one immediately following the
kind and length fields in the option) MUST specify the contiguous
block of data containing the segment which triggered this ACK,
unless that segment advanced the Acknowledgment Number field in
the header. This assures that the ACK with the SACK option
reflects the most recent change in the data receiver's buffer
queue.
* 最初のSACKブロック(すなわち、すぐにオプションにおける種類と長さの野原に続くもの)はこのACKの引き金となったセグメントを含むデータの隣接のブロックを指定しなければなりません、そのセグメントがヘッダーのAcknowledgment Number野原を進めなかったなら。 これは、SACKオプションがあるACKがデータ受信装置のバッファ待ち行列における最新の変化を反映することを保証します。
* The data receiver SHOULD include as many distinct SACK blocks as
possible in the SACK option. Note that the maximum available
option space may not be sufficient to report all blocks present in
the receiver's queue.
* データ受信装置SHOULDはSACKオプションでできるだけ多くの異なったSACKブロックを含んでいます。 最大の利用可能なオプションスペースがすべてのブロックが受信機の待ち行列で存在していると報告するために十分でないかもしれないことに注意してください。
* The SACK option SHOULD be filled out by repeating the most
recently reported SACK blocks (based on first SACK blocks in
previous SACK options) that are not subsets of a SACK block
already included in the SACK option being constructed. This
assures that in normal operation, any segment remaining part of a
non-contiguous block of data held by the data receiver is reported
in at least three successive SACK options, even for large-window
TCP implementations [RFC1323]). After the first SACK block, the
following SACK blocks in the SACK option may be listed in
arbitrary order.
* いっぱいにされて、構成されるSACKオプションに外で既に1つのSACKブロックの部分集合でない最も最近報告されたSACKブロック(前のSACKオプションで最初に、SACKブロックに基づいている)を繰り返すのを含んでいて、SACKはSHOULDにゆだねます。 これは、通常の操作では、データ受信装置によって保持されたデータの非隣接のブロックのどんなセグメント残存部分も少なくとも3つの連続したSACKオプションで報告されることを保証します、大きい窓のTCP実現[RFC1323)のためにさえ。 最初のSACKブロックの後に、SACKオプションにおける以下のSACKブロックは順序不同にリストアップされるかもしれません。
Mathis, et. al. Standards Track [Page 5] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[5ページ]RFC2018TCP
It is very important that the SACK option always reports the block containing the most recently received segment, because this provides the sender with the most up-to-date information about the state of the network and the data receiver's queue.
SACKオプションがいつも最も最近容認されたセグメントを含むブロックを報告するのは、非常に重要です、これがネットワークの事情の最も最新の情報とデータ受信装置の待ち行列を送付者に提供するので。
5. Interpreting the Sack Option and Retransmission Strategy: Data Sender Behavior
5. 袋のオプションを解釈して、Retransmission戦略: データ送付者の振舞い
When receiving an ACK containing a SACK option, the data sender SHOULD record the selective acknowledgment for future reference. The data sender is assumed to have a retransmission queue that contains the segments that have been transmitted but not yet acknowledged, in sequence-number order. If the data sender performs re-packetization before retransmission, the block boundaries in a SACK option that it receives may not fall on boundaries of segments in the retransmission queue; however, this does not pose a serious difficulty for the sender.
SACKオプションを含むACKを受けるとき、データ送付者SHOULDは後日のために選択している承認を記録します。 データ送付者は、伝えられたセグメントを含む再送キューを持っていると思われますが、まだ承認されていません、一連番号オーダーで。 データ送付者が「再-トランスミッション」の前で再packetizationを実行するなら、それが受け取るSACKオプションにおけるブロック境界は再送キューにおけるセグメントの境界の責任とならないかもしれません。 しかしながら、これは送付者のために重大な困難を引き起こしません。
One possible implementation of the sender's behavior is as follows. Let us suppose that for each segment in the retransmission queue there is a (new) flag bit "SACKed", to be used to indicate that this particular segment has been reported in a SACK option.
送付者の振舞いの1つの可能な実現は以下の通りです。 そこでの再送キューにおける各セグメントのためのそれがこの特定のセグメントがSACKオプションで報告されたのを示すのに使用されるために「略奪された」(新しい)のフラグビットであると思いましょう。
When an acknowledgment segment arrives containing a SACK option, the data sender will turn on the SACKed bits for segments that have been selectively acknowledged. More specifically, for each block in the SACK option, the data sender will turn on the SACKed flags for all segments in the retransmission queue that are wholly contained within that block. This requires straightforward sequence number comparisons.
SACKオプションを含んでいて、確認応答セグメントが到着するとき、データ送付者は選択的に承認されたセグメントのためのSACKedビットをつけるでしょう。 より明確に、SACKオプションにおける各ブロックに関して、データ送付者は再送キューにおけるそのブロックの中に完全に保管されているすべてのセグメントのためのSACKed旗をつけるでしょう。 これは簡単な一連番号比較を必要とします。
After the SACKed bit is turned on (as the result of processing a received SACK option), the data sender will skip that segment during any later retransmission. Any segment that has the SACKed bit turned off and is less than the highest SACKed segment is available for retransmission.
SACKedビットがつけられた(容認されたSACKオプションを処理するという結果として)後に、データ送付者はどんな後の「再-トランスミッション」の間も、そのセグメントをスキップするでしょう。 SACKedビットをオフにさせて、最も高いSACKedセグメント以下であるどんなセグメントも「再-トランスミッション」に利用可能です。
After a retransmit timeout the data sender SHOULD turn off all of the SACKed bits, since the timeout might indicate that the data receiver has reneged. The data sender MUST retransmit the segment at the left edge of the window after a retransmit timeout, whether or not the SACKed bit is on for that segment. A segment will not be dequeued and its buffer freed until the left window edge is advanced over it.
aの後に、データ送付者SHOULDがSACKedビットのすべてからターンするタイムアウトを再送してください、タイムアウトが、データ受信装置が手を引いたのを示すかもしれないので。 aがタイムアウトを再送した後にデータ送付者は窓の左の縁でセグメントを再送しなければなりません、そのセグメントに、SACKedビットがオンであるか否かに関係なく。 セグメントは、デキューされてそのバッファに左の窓の縁がそれの上に進められるまで解放されたならないでしょう。
Mathis, et. al. Standards Track [Page 6] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[6ページ]RFC2018TCP
5.1 Congestion Control Issues
5.1 輻輳制御問題
This document does not attempt to specify in detail the congestion control algorithms for implementations of TCP with SACK. However, the congestion control algorithms present in the de facto standard TCP implementations MUST be preserved [Stevens94]. In particular, to preserve robustness in the presence of packets reordered by the network, recovery is not triggered by a single ACK reporting out-of- order packets at the receiver. Further, during recovery the data sender limits the number of segments sent in response to each ACK. Existing implementations limit the data sender to sending one segment during Reno-style fast recovery, or to two segments during slow-start [Jacobson88]. Other aspects of congestion control, such as reducing the congestion window in response to congestion, must similarly be preserved.
このドキュメントは、詳細にSACKとのTCPの実現のための輻輳制御アルゴリズムを指定するのを試みません。 しかしながら、デファクトスタンダードTCP実現における現在の輻輳制御アルゴリズムを保存しなければなりません[Stevens94]。 -受信機でパケットを注文してください。ネットワークによって再命令されたパケットがあるとき丈夫さを保存するために、特に、回復が結論を提示する独身のACKによって引き起こされない、-、さらに、回復の間、データ送付者は各ACKに対応して送られたセグメントの数を制限します。 既存の実現は遅れた出発[Jacobson88]の間、データ送付者をリノ-スタイルの速い回復か、2つのセグメントに1つのセグメントを送るのに制限します。 同様に混雑に対応して混雑ウィンドウを減少などにさせることなどの輻輳制御の他の局面を保持しなければなりません。
The use of time-outs as a fall-back mechanism for detecting dropped packets is unchanged by the SACK option. Because the data receiver is allowed to discard SACKed data, when a retransmit timeout occurs the data sender MUST ignore prior SACK information in determining which data to retransmit.
検出のための後退メカニズムがパケットを落とすのに従って、タイムアウトの使用はSACKオプションで変わりがありません。 aが再送されるとき、データ受信装置がSACKedデータを捨てることができるので、タイムアウトは起こります。どのデータを再送したらよいかを決定する際にデータ送付者は先のSACK情報を無視しなければなりません。
Future research into congestion control algorithms may take advantage of the additional information provided by SACK. One such area for future research concerns modifications to TCP for a wireless or satellite environment where packet loss is not necessarily an indication of congestion.
輻輳制御アルゴリズムの今後の研究はSACKによって提供された追加情報を利用するかもしれません。 今後の調査のためのそのような領域の1つは無線電信のためのTCPへの変更かパケット損失が必ず混雑のしるしであるというわけではない衛星環境に関係があります。
6. Efficiency and Worst Case Behavior
6. 効率と最悪の場合の振舞い
If the return path carrying ACKs and SACK options were lossless, one block per SACK option packet would always be sufficient. Every segment arriving while the data receiver holds discontinuous data would cause the data receiver to send an ACK with a SACK option containing the one altered block in the receiver's queue. The data sender is thus able to construct a precise replica of the receiver's queue by taking the union of all the first SACK blocks.
ACKsとSACKオプションを運ぶリターンパスがlosslessであるなら、SACKオプションパケットあたり1つのブロックがいつも十分でしょうに。 データ受信装置が不連続なデータを保持している間に到着するあらゆるセグメントで、データ受信装置はSACKオプションが受信機の待ち行列に1つの変えられたブロックを含んでいるACKを送るでしょう。 その結果、データ送付者は、すべての最初のSACKブロックの組合を取ることによって、受信機の待ち行列の正確なレプリカを構成できます。
Mathis, et. al. Standards Track [Page 7] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[7ページ]RFC2018TCP
Since the return path is not lossless, the SACK option is defined to include more than one SACK block in a single packet. The redundant blocks in the SACK option packet increase the robustness of SACK delivery in the presence of lost ACKs. For a receiver that is also using the time stamp option [Jacobson92], the SACK option has room to include three SACK blocks. Thus each SACK block will generally be repeated at least three times, if necessary, once in each of three successive ACK packets. However, if all of the ACK packets reporting a particular SACK block are dropped, then the sender might assume that the data in that SACK block has not been received, and unnecessarily retransmit those segments.
リターンパスがlosslessでないので、SACKオプションは単一のパケットでの1つ以上のSACKブロック以上を含むように定義されます。 SACKオプションパケットでの余分なブロックは無くなっているACKsの面前でSACK配送の丈夫さを増加させます。 また、タイムスタンプオプション[Jacobson92]を使用している受信機に関しては、SACKオプションには、3つのSACKブロックを含む余地があります。 したがって、一般に、それぞれのSACKブロックはそれぞれの3つの連続したACKパケットで必要なら少なくとも3回一度繰り返されるでしょう。 しかしながら、特定のSACKブロックを報告するACKパケットのすべてが落とされるなら、送付者は、そのSACKブロックのデータが受信されていないと仮定して、不必要にそれらのセグメントを再送するかもしれません。
The deployment of other TCP options may reduce the number of available SACK blocks to 2 or even to 1. This will reduce the redundancy of SACK delivery in the presence of lost ACKs. Even so, the exposure of TCP SACK in regard to the unnecessary retransmission of packets is strictly less than the exposure of current implementations of TCP. The worst-case conditions necessary for the sender to needlessly retransmit data is discussed in more detail in a separate document [Floyd96].
他のTCPオプションの展開は有効なSACKブロックの数を2か1までさえ減少させるかもしれません。 これは無くなっているACKsの面前でSACK配送の冗長を減らすでしょう。 たとえそうだとしても、不要なパケットの再送に関するTCP SACKの展示はTCPの現在の実現の摘発より厳密に少ないです。 さらに詳細に別々のドキュメント[Floyd96]で送付者が不必要にデータを再送するのと議論するのが必要な最悪の場合状態。
Older TCP implementations which do not have the SACK option will not be unfairly disadvantaged when competing against SACK-capable TCPs. This issue is discussed in more detail in [Floyd96].
SACKできるTCPsを競争するとき、SACKオプションを持っていないより古いTCP実現が不公平に不都合でないでしょう。 さらに詳細に[Floyd96]でこの問題について議論します。
7. Sack Option Examples
7. 袋のオプションの例
The following examples attempt to demonstrate the proper behavior of SACK generation by the data receiver.
以下の例は、データ受信装置でSACK世代の適切な振舞いを示すのを試みます。
Assume the left window edge is 5000 and that the data transmitter sends a burst of 8 segments, each containing 500 data bytes.
左の窓の縁が5000であり、データ送信機が8つのセグメントの炸裂を送ると仮定してください、それぞれ500データ・バイトを含んでいて。
Case 1: The first 4 segments are received but the last 4 are
dropped.
ケース1: 最初の4つのセグメントが受け取られていますが、ベスト4は落とされます。
The data receiver will return a normal TCP ACK segment
acknowledging sequence number 7000, with no SACK option.
データ受信装置は、SACKオプションなしで一連番号7000を承認しながら、正常なTCP ACKセグメントを返すでしょう。
Mathis, et. al. Standards Track [Page 8] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[8ページ]RFC2018TCP
Case 2: The first segment is dropped but the remaining 7 are
received.
ケース2: 最初のセグメントは落とされますが、残っている7は受け取られています。
Upon receiving each of the last seven packets, the data
receiver will return a TCP ACK segment that acknowledges
sequence number 5000 and contains a SACK option specifying
one block of queued data:
それぞれの最後の7つのパケットを受けると、データ受信装置は1ブロックの列に並ばせられたデータを指定する一連番号5000を承認して、SACKオプションを含むTCP ACKセグメントを返すでしょう:
Triggering ACK Left Edge Right Edge
Segment
ACKの引き金となると、縁は正しい縁のセグメントにいなくなりました。
5000 (lost)
5500 5000 5500 6000
6000 5000 5500 6500
6500 5000 5500 7000
7000 5000 5500 7500
7500 5000 5500 8000
8000 5000 5500 8500
8500 5000 5500 9000
5000 (失われています)5500 5000 5500 6000 6000 5000 5500 6500 6500 5000 5500 7000 7000 5000 5500 7500 7500 5000 5500 8000 8000 5000 5500 8500 8500 5000 5500 9000
Case 3: The 2nd, 4th, 6th, and 8th (last) segments are
dropped.
ケース3: 2番目、4番目、6番目、および8(最後)番目のセグメントは落とされます。
The data receiver ACKs the first packet normally. The
third, fifth, and seventh packets trigger SACK options as
follows:
データ受信装置ACKs、最初のパケット、通常。 3番目、5番目、および7番目のパケットは以下のSACKオプションの引き金となります:
Triggering ACK First Block 2nd Block 3rd Block
Segment Left Right Left Right Left Right
Edge Edge Edge Edge Edge Edge
正しい状態で残っている正しい状態で残っているACK最初のブロック第2ブロックの第3ブロックセグメントの引き金となると、正しい縁の縁の縁の縁の縁の縁はいなくなりました。
5000 5500
5500 (lost)
6000 5500 6000 6500
6500 (lost)
7000 5500 7000 7500 6000 6500
7500 (lost)
8000 5500 8000 8500 7000 7500 6000 6500
8500 (lost)
5000 5500 5500(失われている)6000 5500 6000 6500 6500(失われている)7000 5500 7000 7500 6000 6500 7500(失われている)8000 5500 8000 8500 7000 7500 6000 6500 8500(無くなる)です。
Mathis, et. al. Standards Track [Page 9] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[9ページ]RFC2018TCP
Suppose at this point, the 4th packet is received out of order.
(This could either be because the data was badly misordered in the
network, or because the 2nd packet was retransmitted and lost, and
then the 4th packet was retransmitted). At this point the data
receiver has only two SACK blocks to report. The data receiver
replies with the following Selective Acknowledgment:
ここに4番目のパケットが故障していた状態で受け取られると仮定してください。 (これは2番目のパケットがデータがネットワークでひどくmisorderedされたか、再送されて、または損をしたからであるかもしれません次に、4番目のパケットは再送されました。) ここに、データ受信装置には、報告する2つのSACKブロックしかありません。 データ受信装置は以下のSelective Acknowledgmentと共に返答します:
Triggering ACK First Block 2nd Block 3rd Block
Segment Left Right Left Right Left Right
Edge Edge Edge Edge Edge Edge
正しい状態で残っている正しい状態で残っているACK最初のブロック第2ブロックの第3ブロックセグメントの引き金となると、正しい縁の縁の縁の縁の縁の縁はいなくなりました。
6500 5500 6000 7500 8000 8500
6500 5500 6000 7500 8000 8500
Suppose at this point, the 2nd segment is received. The data
receiver then replies with the following Selective Acknowledgment:
ここに2番目のセグメントが受け取られていると仮定してください。 次に、データ受信装置は以下のSelective Acknowledgmentと共に返答します:
Triggering ACK First Block 2nd Block 3rd Block
Segment Left Right Left Right Left Right
Edge Edge Edge Edge Edge Edge
正しい状態で残っている正しい状態で残っているACK最初のブロック第2ブロックの第3ブロックセグメントの引き金となると、正しい縁の縁の縁の縁の縁の縁はいなくなりました。
5500 7500 8000 8500
5500 7500 8000 8500
8. Data Receiver Reneging
8. データ受信装置の手を引くこと
Note that the data receiver is permitted to discard data in its queue that has not been acknowledged to the data sender, even if the data has already been reported in a SACK option. Such discarding of SACKed packets is discouraged, but may be used if the receiver runs out of buffer space.
データ受信装置がデータ送付者に承諾されていない待ち行列におけるデータを捨てることが許可されていることに注意してください、データがSACKオプションで既に報告されたとしても。 SACKedパケットをそのような捨てることは、がっかりしていますが、受信機がバッファ領域を使い果たすなら、使用されるかもしれません。
The data receiver MAY elect not to keep data which it has reported in a SACK option. In this case, the receiver SACK generation is additionally qualified:
データ受信装置は、それがSACKオプションで報告したデータを保たないのを選ぶかもしれません。 この場合、受信機SACK世代はさらに、資格があります:
* The first SACK block MUST reflect the newest segment. Even if
the newest segment is going to be discarded and the receiver has
already discarded adjacent segments, the first SACK block MUST
report, at a minimum, the left and right edges of the newest
segment.
* 最初のSACKブロックは最も新しいセグメントを反映しなければなりません。 最も新しいセグメントが捨てられるべきである行くのと受信機であっても、隣接しているセグメントは既に捨てられました、と最初のSACKブロックは報告しなければなりません、最小限で、最も新しいセグメントの左右の縁。
* Except for the newest segment, all SACK blocks MUST NOT report
any old data which is no longer actually held by the receiver.
* 最も新しいセグメント以外に、すべてのSACKブロックが実際にもう受信機によって保持されない少しの古いデータも報告してはいけません。
Since the data receiver may later discard data reported in a SACK option, the sender MUST NOT discard data before it is acknowledged by the Acknowledgment Number field in the TCP header.
データ受信装置が後でSACKオプションで報告されたデータを捨てるかもしれないので、それがTCPヘッダーのAcknowledgment Number分野によって承認される前に、送付者はデータを捨ててはいけません。
Mathis, et. al. Standards Track [Page 10] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[10ページ]RFC2018TCP
9. Security Considerations
9. セキュリティ問題
This document neither strengthens nor weakens TCP's current security properties.
このドキュメントは、TCPの現在のセキュリティの特性を強化でない、また弱めません。
10. References
10. 参照
[Cheriton88] Cheriton, D., "VMTP: Versatile Message Transaction Protocol", RFC 1045, Stanford University, February 1988.
[Cheriton88]Cheriton、D.、「VMTP:」 「多能なメッセージ取引プロトコル」、RFC1045、スタンフォード大学、1988年2月。
[Clark87] Clark, D., Lambert, M., and L. Zhang, "NETBLT: A Bulk Data Transfer Protocol", RFC 998, MIT, March 1987.
[Clark87] クラーク、D.、ランバート、M.、およびL.チャン、「NETBLT:」 「バルク・データ転送プロトコル」、RFC998、MIT、1987年3月。
[Fall95] Fall, K. and Floyd, S., "Comparisons of Tahoe, Reno, and Sack TCP", ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z, December 1995.
[Fall95] 秋とK.とフロイド、S.、「タホ、リノ、および袋のTCPの比較」、 ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z 、1995年12月。
[Floyd96] Floyd, S., "Issues of TCP with SACK", ftp://ftp.ee.lbl.gov/papers/issues_sa.ps.Z, January 1996.
[Floyd96] フロイド、S.、「袋があるTCPの問題」、 ftp://ftp.ee.lbl.gov/papers/issues_sa.ps.Z 、1996年1月。
[Huitema81] Huitema, C., and Valet, I., An Experiment on High Speed File Transfer using Satellite Links, 7th Data Communication Symposium, Mexico, October 1981.
[Huitema81] 衛星中継を使用する高速ファイル転送、第7データ通信シンポジウム、メキシコ(1981年10月)のHuitema、C.と召使、I.、実験。
[Jacobson88] Jacobson, V., "Congestion Avoidance and Control", Proceedings of SIGCOMM '88, Stanford, CA., August 1988.
[Jacobson88] ジェーコブソンと、V.と、「輻輳回避とコントロール」、SIGCOMM88年、スタンフォード(カリフォルニア)の議事、8月1988日
[Jacobson88}, Jacobson, V. and R. Braden, "TCP Extensions for Long- Delay Paths", RFC 1072, October 1988.
[Jacobson88、ジェーコブソン、V.とR.ブレーデン、「長い遅れ経路のためのTCP拡張子」RFC1072、10月1988日
[Jacobson92] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[Jacobson92]ジェーコブソン(V.とブレーデン、R.とD.ボーマン、「高性能のためのTCP拡張子」RFC1323)は1992がそうするかもしれません。
[Keshav94] Keshav, presentation to the Internet End-to-End Research Group, November 1994.
[Keshav94]Keshav、インターネットのEndから終わりへのResearch Group、1994年11月までのプレゼンテーション。
[Mathis95] Mathis, M., and Mahdavi, J., TCP Forward Acknowledgment Option, presentation to the Internet End-to-End Research Group, June 1995.
[Mathis95] インターネットのEndから終わりへのResearch Group、1995年6月までのマシス、M.とMahdavi、J.、TCP Forward Acknowledgment Option、プレゼンテーション。
[Partridge87] Partridge, C., "Private Communication", February 1987.
[Partridge87] ヤマウズラ、C.、「私信」、1987年2月。
[Postel81] Postel, J., "Transmission Control Protocol - DARPA Internet Program Protocol Specification", RFC 793, DARPA, September 1981.
[Postel81] ポステル、J.、「転送管理は議定書を作ります--DARPAインターネットはプロトコル仕様をプログラムする」RFC793、DARPA、1981年9月。
[Stevens94] Stevens, W., TCP/IP Illustrated, Volume 1: The Protocols, Addison-Wesley, 1994.
[Stevens94] スティーブンス、W.、例証されたTCP/IP、第1巻: プロトコル、アディソン-ウエスリー、1994。
Mathis, et. al. Standards Track [Page 11] RFC 2018 TCP Selective Acknowledgement Options October 1996
etマシス、アル。 承認オプション1996年10月に選択している標準化過程[11ページ]RFC2018TCP
[Strayer92] Strayer, T., Dempsey, B., and Weaver, A., XTP -- the xpress transfer protocol. Addison-Wesley Publishing Company, 1992.
[Strayer92] 迷い人とT.とデンプシー、B.とウィーバー、A.、XTP--xpressはプロトコルを移します。 アディソン-ウエスリー出版社、1992。
[Velten84] Velten, D., Hinden, R., and J. Sax, "Reliable Data Protocol", RFC 908, BBN, July 1984.
[Velten84] フェルテンとD.とHinden、R.とJ.サクソフォーン、「確実な資料プロトコル」、RFC908、BBN、1984年7月。
11. Authors' Addresses
11. 作者のアドレス
Matt Mathis and Jamshid Mahdavi
Pittsburgh Supercomputing Center
4400 Fifth Ave
Pittsburgh, PA 15213
mathis@psc.edu
mahdavi@psc.edu
マット・マシスとJamshid MahdaviピッツバーグSupercomputingセンター4400黙秘権Aveピッツバーグ(PA)15213 mathis@psc.edu mahdavi@psc.edu
Sally Floyd
Lawrence Berkeley National Laboratory
One Cyclotron Road
Berkeley, CA 94720
floyd@ee.lbl.gov
サリー・フロイド・ローレンス・バークレーの国家の研究所1サイクロトロンRoadバークレー(カリフォルニア)94720 floyd@ee.lbl.gov
Allyn Romanow
Sun Microsystems, Inc.
2550 Garcia Ave., MPK17-202
Mountain View, CA 94043
allyn@eng.sun.com
アリンRomanowサン・マイクロシステムズ・インク2550ガルシアAve、MPK17-202マウンテンビュー(カリフォルニア)94043 allyn@eng.sun.com
Mathis, et. al. Standards Track [Page 12]
etマシス、アル。 標準化過程[12ページ]
一覧
スポンサーリンク
