Network Working Group S. Floyd
Request for Comments: 2883 ACIRI
Category: Standards Track J. Mahdavi
Novell
M. Mathis
Pittsburgh Supercomputing Center
M. Podolsky
UC Berkeley
July 2000
An Extension to the Selective Acknowledgement (SACK) Option 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）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This note defines an extension of the Selective Acknowledgement (SACK) Option [RFC2018] for TCP. RFC 2018 specified the use of the SACK option for acknowledging out-of-sequence data not covered by TCP's cumulative acknowledgement field. This note extends RFC 2018 by specifying the use of the SACK option for acknowledging duplicate packets. This note suggests that when duplicate packets are received, the first block of the SACK option field can be used to report the sequence numbers of the packet that triggered the acknowledgement. This extension to the SACK option allows the TCP sender to infer the order of packets received at the receiver, allowing the sender to infer when it has unnecessarily retransmitted a packet. A TCP sender could then use this information for more robust operation in an environment of reordered packets [BPS99], ACK loss, packet replication, and/or early retransmit timeouts.
このノートは、TCPのための選択的確認応答（SACK）オプション[RFC2018]の拡張を定義します。 RFC 2018 TCPの累積確認応答フィールドでカバーされていないシーケンス外のデータを認めるためのSACKオプションを使用することを指定しました。このノートでは、重複パケットを認めるためのSACKオプションの使用を指定することにより、RFC 2018を拡張します。このノートでは、重複したパケットを受信したときに、SACKオプションフィールドの最初のブロックは、確認応答を引き起こしたパケットのシーケンス番号を報告するために使用することができることを示唆しています。 SACKオプションにこの拡張は、TCPの送信者は、それが不必要にパケットを再送した場合に、送信者が推測できるように、受信機で受信したパケットの順序を推測することができます。 TCPの送信者は、並べ替え、パケット[BPS99]、ACKロス、パケット複製、および/または早期再送信タイムアウトの環境で、より堅牢な動作のために、この情報を使用することができます。
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [B97].
彼らは、この文書に表示される[B97]で説明したように解釈される際のキーワードは、REQUIREDは、、、、、MAY、推奨、およびオプションのすべきでないないものとものとしてはなりませんしなければなりません。
The Selective Acknowledgement (SACK) option defined in RFC 2018 is used by the TCP data receiver to acknowledge non-contiguous blocks of data not covered by the Cumulative Acknowledgement field. However, RFC 2018 does not specify the use of the SACK option when duplicate segments are received. This note specifies the use of the SACK option when acknowledging the receipt of a duplicate packet [F99]. We use the term D-SACK (for duplicate-SACK) to refer to a SACK block that reports a duplicate segment.
RFC 2018で定義された選択的確認応答（SACK）オプションは、累積確認応答フィールドでカバーされていないデータの非連続ブロックを確認するためにTCPデータ受信機によって使用されます。重複セグメントが受信されたときただし、RFC 2018には、SACKオプションの使用を指定しません。重複パケット[F99]の受信を確認すると、このノートでは、SACKオプションを使用することを指定します。我々は、重複セグメントを報告SACKブロックを参照するために（重複SACKため）という用語は、D-SACKを使用します。
This document does not make any changes to TCP's use of the cumulative acknowledgement field, or to the TCP receiver's decision of *when* to send an acknowledgement packet. This document only concerns the contents of the SACK option when an acknowledgement is sent.
確認応答パケットを送信する*ときに、この文書では、累積確認応答フィールドのTCPの使用、または*のTCP受信機の決定は変更されません。肯定応答が送信されるときにこの文書では、唯一のSACKオプションの内容に関するものです。
This extension is compatible with current implementations of the SACK option in TCP. That is, if one of the TCP end-nodes does not implement this D-SACK extension and the other TCP end-node does, we believe that this use of the D-SACK extension by one of the end nodes will not introduce problems.
この拡張は、TCPでSACKオプションの現在の実装と互換性があります。これは、TCPのエンドノードの一つが、このD-SACK拡張を実装していないと、他のTCPエンドノードがない場合、我々は、エンド・ノードの1つによってD-SACK拡張のこの使用は、問題を導入しないと信じている、です。
The use of D-SACK does not require separate negotiation between a TCP sender and receiver that have already negotiated SACK capability. The absence of separate negotiation for D-SACK means that the TCP receiver could send D-SACK blocks when the TCP sender does not understand this extension to SACK. In this case, the TCP sender will simply discard any D-SACK blocks, and process the other SACK blocks in the SACK option field as it normally would.
D-SACKの使用は、すでにSACK機能を交渉したTCPの送信者と受信者との間の個別の交渉を必要としません。 D-SACKのための個別の交渉の不在は、TCPの送信者はSACKするために、この拡張機能を理解していない場合、TCP受信機がD-SACKブロックを送信することができることを意味します。この場合、TCPの送信者は、単に任意のD-SACKブロックを破棄し、そしてそれは通常どおりSACKオプションフィールド内の他のSACKブロックを処理します。
The SACK option as defined in RFC 2018 is as follows:
次のようにRFC 2018で定義されているSACKオプションは次のとおりです。
+--------+--------+
| Kind=5 | Length |
+--------+--------+--------+--------+
| Left Edge of 1st Block |
+--------+--------+--------+--------+
| Right Edge of 1st Block |
+--------+--------+--------+--------+
| |
/ . . . /
| |
+--------+--------+--------+--------+
| Left Edge of nth Block |
+--------+--------+--------+--------+
| Right Edge of nth Block |
+--------+--------+--------+--------+
The Selective Acknowledgement (SACK) option in the TCP header contains a number of SACK blocks, where each block specifies the left and right edge of a block of data received at the TCP receiver. In particular, a block represents a contiguous sequence space of data received and queued at the receiver, where the "left edge" of the block is the first sequence number of the block, and the "right edge" is the sequence number immediately following the last sequence number of the block.
TCPヘッダ内の選択的確認応答（SACK）オプションは、各ブロックは、データのブロックの左端と右端を指定するTCP受信機で受信されたSACKブロックの数を含んでいます。具体的には、ブロックは、データの連続した配列空間を表す受信されたブロックの「左端」は、ブロックの最初のシーケンス番号であり、「右端」は直後のシーケンス番号である受信機でキューに入れられましたブロックの最後のシーケンス番号。
RFC 2018 implies that the first SACK block specify the segment that triggered the acknowledgement. From RFC 2018, when the data receiver chooses to send a SACK option, "the first SACK block ... 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."
RFC 2018第SACKブロックが肯定応答をトリガーセグメントを指定することを意味します。 RFC 2018から、データ受信「は、SACKオプションを送信する第SACKブロックを選択した場合...そのセグメントがヘッダに確認応答番号フィールドを進めない限り、このACKを引き起こしセグメントを含むデータの連続ブロックを指定しなければなりません。 "
However, RFC 2018 does not address the use of the SACK option when acknowledging a duplicate segment. For example, RFC 2018 specifies that "each block represents received bytes of data that are contiguous and isolated". RFC 2018 further specifies that "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." RFC 2018 does not specify the use of the SACK option when a duplicate segment is received, and the cumulative acknowledgement field in the ACK acknowledges all of the data in the data receiver's queue.
重複セグメントを認めしかし、RFC 2018には、SACKオプションの使用には対応していません。例えば、RFC 2018「は、各ブロックが連続し、分離されているデータの受信バイトを表す」ことを指定します。 RFC 2018は、さらに、「全く送られた場合、SACKオプションは、データ受信側のキューに最高のシーケンス番号をACKしないすべてのACKに含まれるべきである。」ことを指定します重複セグメントを受信したときにRFC 2018は、SACKオプションの使用を指定しないと、ACKで累積確認応答フィールドは、データ受信側のキュー内のデータのすべてを認めています。
This section specifies the use of SACK blocks when the SACK option is used in reporting a duplicate segment. When D-SACK is used, the first block of the SACK option should be a D-SACK block specifying the sequence numbers for the duplicate segment that triggers the acknowledgement. If the duplicate segment is part of a larger block of non-contiguous data in the receiver's data queue, then the following SACK block should be used to specify this larger block. Additional SACK blocks can be used to specify additional non-contiguous blocks of data, as specified in RFC 2018.
このセクションでは、SACKオプションが重複したセグメントをレポートに使用されているSACKブロックの使用を指定します。 D-SACKを使用する場合、SACKオプションの最初のブロックは、肯定応答をトリガする重複セグメントのシーケンス番号を指定するD-SACKブロックであるべきです。重複セグメントは、受信機のデータキューに非連続データの大きなブロックの一部である場合、次のSACKブロックは、この大きなブロックを指定するために使用されるべきです。 RFC 2018で指定された追加のSACKブロックは、データの追加の非連続ブロックを指定するために使用することができます。
The guidelines for reporting duplicate segments are summarized below:
重複セグメントを報告するためのガイドラインを以下にまとめます。
(1) A D-SACK block is only used to report a duplicate contiguous sequence of data received by the receiver in the most recent packet.
（1）D-SACKブロックは、最も最近のパケットに受信機によって受信されたデータの複製連続配列を報告するために使用されます。
(2) Each duplicate contiguous sequence of data received is reported in at most one D-SACK block. (I.e., the receiver sends two identical D-SACK blocks in subsequent packets only if the receiver receives two duplicate segments.)
（2）それぞれが受信したデータの連続した配列は、せいぜい1つのD-SACKブロックに報告されている重複します。 （すなわち、受信機は、受信機は、2つの重複セグメントを受信する場合にのみ、後続のパケット内の2つの同一のD-SACKブロックを送信します。）
(3) The left edge of the D-SACK block specifies the first sequence number of the duplicate contiguous sequence, and the right edge of the D-SACK block specifies the sequence number immediately following the last sequence in the duplicate contiguous sequence.
（3）D-SACKブロックの左端は、重複連続配列の最初のシーケンス番号を指定し、D-SACKブロックの右端には、直ちに重複連続した配列の最後のシーケンス次のシーケンス番号を指定します。
(4) If the D-SACK block reports a duplicate contiguous sequence from a (possibly larger) block of data in the receiver's data queue above the cumulative acknowledgement, then the second SACK block in that SACK option should specify that (possibly larger) block of data.
（4）D-SACKブロックは、ブロック、そのSACKオプションで第SACKブロックが（おそらく大きい）ことを指定する必要があり、累積確認応答上記レシーバのデータキューにデータの（おそらくより大きな）ブロックから重複連続配列が報告された場合データの。
(5) Following the SACK blocks described above for reporting duplicate segments, additional SACK blocks can be used for reporting additional blocks of data, as specified in RFC 2018.
RFC 2018で指定されるように（5）重複セグメントを報告するための上述のSACKブロックに続いて、追加のSACKブロックは、データの追加ブロックを報告するために使用することができます。
Note that because each duplicate segment is reported in only one ACK packet, information about that duplicate segment will be lost if that ACK packet is dropped in the network.
各重複セグメントが一つだけACKパケットで報告されているため、そのACKパケットがネットワーク内でドロップされた場合、その重複セグメントに関する情報が失われることに注意してください。
We illustrate these guidelines with three examples. In each example, we assume that the data receiver has first received eight segments of 500 bytes each, and has sent an acknowledgement with the cumulative acknowledgement field set to 4000 (assuming the first sequence number is zero). The D-SACK block is underlined in each example.
私たちは3例で、これらのガイドラインを示しています。各例では、データ受信機は最初の500バイト毎の8つのセグメントを受信し、及び（最初のシーケンス番号がゼロであると仮定して）4000に累積確認応答フィールドを設定して確認応答を送信したと仮定する。 D-SACKブロックは、各実施例で下線が引かれています。
Because several ACK packets are lost, the data sender retransmits packet 3000-3499, and the data receiver subsequently receives a duplicate segment with sequence numbers 3000-3499. The receiver sends an acknowledgement with the cumulative acknowledgement field set to 4000, and the first, D-SACK block specifying sequence numbers 3000-3500.
いくつかのACKパケットが失われているため、データの送信者は、パケット3000から3499を再送信し、データ受信機は、その後、シーケンス番号3000から3499との重複セグメントを受け取ります。受信機は、4000に設定され、累積確認応答フィールドで確認応答を送信し、シーケンス番号3000から3500を指定する最初、D-SACKブロック。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
3000-3499 3000-3499 3500 (ACK dropped)
3500-3999 3500-3999 4000 (ACK dropped)
3000-3499 3000-3499 4000, SACK=3000-3500
---------
4.1.2. Example 2: Reporting an out-of-order segment and a duplicate
segment.
Following a lost data packet, the receiver receives an out-of-order data segment, which triggers the SACK option as specified in RFC 2018. Because of several lost ACK packets, the sender then retransmits a data packet. The receiver receives the duplicate packet, and reports it in the first, D-SACK block:
失われたデータパケットの後、受信機は、RFC 2018で指定されるようにので、いくつかの失われたACKパケットのSACKオプションをトリガアウト・オブ・オーダのデータセグメントを受信し、送信側は、データパケットを再送します。受信機は、重複パケットを受信し、第1、D-SACKブロックにそれを報告します。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
3000-3499 3000-3499 3500 (ACK dropped)
3500-3999 3500-3999 4000 (ACK dropped)
4000-4499 (data packet dropped)
4500-4999 4500-4999 4000, SACK=4500-5000 (ACK dropped)
3000-3499 3000-3499 4000, SACK=3000-3500, 4500-5000
---------
Because of a lost data packet, the receiver receives two out-of-order segments. The receiver next receives a duplicate segment for one of these out-of-order segments:
なぜなら失われたデータパケットを、受信機は、二つのアウト・オブ・オーダのセグメントを受信します。受信機は、次に、これらのアウト・オブ・オーダのセグメントのいずれかの重複セグメントを受信します。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
3500-3999 3500-3999 4000
4000-4499 (data packet dropped)
4500-4999 4500-4999 4000, SACK=4500-5000
5000-5499 5000-5499 4000, SACK=4500-5500
(duplicated packet)
5000-5499 4000, SACK=5000-5500, 4500-5500
---------
4.2. Reporting Partial Duplicate Segments
It may be possible that a sender transmits a packet that includes one or more duplicate sub-segments--that is, only part but not all of the transmitted packet has already arrived at the receiver. This can occur when the size of the sender's transmitted segments increases, which can occur when the PMTU increases in the middle of a TCP session, for example. The guidelines in Section 4 above apply to reporting partial as well as full duplicate segments. This section gives examples of these guidelines when reporting partial duplicate segments.
つまり、一部だけではなく、送信されたパケットの全てが既に受信機に到着した - 送信者が1つまたは複数の重複サブセグメントを含むパケットを送信することが可能であってもよいです。送信者の送信セグメントのサイズが増加する場合に発生し得る、起こり得る場合、例えば、TCPセッションの途中でPMTU増加します。第4節のガイドラインは、上記の部分だけでなく、完全な重複セグメント報告に適用されます。部分的な重複セグメントを報告する場合は、このセクションでは、これらのガイドラインの例を示します。
When the SACK option is used for reporting partial duplicate segments, the first D-SACK block reports the first duplicate sub-segment. If the data packet being acknowledged contains multiple partial duplicate sub-segments, then only the first such duplicate sub-segment is reported in the SACK option. We illustrate this with the examples below.
SACKオプションが部分的重複セグメントを報告するために使用される場合、第1のD-SACKブロックは、第一の重複サブセグメントを報告します。確認応答されるデータパケットは、複数の部分的な重複サブセグメントが含まれている場合、最初のそのような重複サブセグメントは、SACKオプションで報告されています。私たちは、以下の例でこれを説明します。
The sender increases the packet size from 500 bytes to 1000 bytes. The receiver subsequently receives a 1000-byte packet containing one 500-byte subsegment that has already been received and one which has not. The receiver reports only the already received subsegment using a single D-SACK block.
送信者は1000バイトに500バイトからパケットサイズを増加します。受信機は、その後、既に受信されていない一つとなっているもの500バイトのサブセグメントを含有する1000バイトのパケットを受信します。単一D-SACKブロックを使用してのみ、既に受信したサブセグメントレシーバレポート。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
500-999 500-999 1000
1000-1499 (delayed)
1500-1999 (data packet dropped)
2000-2499 2000-2499 1000, SACK=2000-2500
1000-2000 1000-1499 1500, SACK=2000-2500
1000-2000 2500, SACK=1000-1500
---------
4.2.2. Example 5: Two non-contiguous duplicate subsegments covered by the cumulative acknowledgement.
4.2.2. 例5：累積確認応答でカバー二つの非連続的な重複サブセグメント。
After the sender increases its packet size from 500 bytes to 1500 bytes, the receiver receives a packet containing two non-contiguous duplicate 500-byte subsegments which are less than the cumulative acknowledgement field. The receiver reports the first such duplicate segment in a single D-SACK block.
送信者が1500バイト、500のバイトからそのパケットのサイズを増加した後、受信機は、累積確認応答フィールド未満である2つの非隣接重複する500バイトのサブセグメントを含むパケットを受信します。受信機は、単一のD-SACKブロックの最初のそのような重複セグメントを報告します。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
500-999 500-999 1000
1000-1499 (delayed)
1500-1999 (data packet dropped)
2000-2499 (delayed)
2500-2999 (data packet dropped)
3000-3499 3000-3499 1000, SACK=3000-3500
1000-2499 1000-1499 1500, SACK=3000-3500
2000-2499 1500, SACK=2000-2500, 3000-3500
1000-2499 2500, SACK=1000-1500, 3000-3500
---------
4.2.3. Example 6: Two non-contiguous duplicate subsegments not covered by the cumulative acknowledgement.
4.2.3. 例6：二つの非連続的な重複サブセグメントが累積確認応答でカバーされていません。
This example is similar to Example 5, except that after the sender increases the packet size, the receiver receives a packet containing two non-contiguous duplicate subsegments which are above the cumulative acknowledgement field, rather than below. The first, D-SACK block reports the first duplicate subsegment, and the second, SACK block reports the larger block of non-contiguous data that it belongs to.
この例では、送信側がパケットサイズを増加した後、受信機はむしろ以下より、累積確認応答フィールド上にある2つの非隣接重複サブセグメントを含むパケットを受信した以外は、実施例5と同様です。まず、D-SACKブロックは、最初の重複サブセグメントを報告し、第二、SACKブロックは、それが属する非連続データの大きなブロックを報告します。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
500-999 500-999 1000
1000-1499 (data packet dropped)
1500-1999 (delayed)
2000-2499 (data packet dropped)
2500-2999 (delayed)
3000-3499 (data packet dropped)
3500-3999 3500-3999 1000, SACK=3500-4000
1000-1499 (data packet dropped)
1500-2999 1500-1999 1000, SACK=1500-2000, 3500-4000
2000-2499 1000, SACK=2000-2500, 1500-2000,
3500-4000
1500-2999 1000, SACK=1500-2000, 1500-3000,
---------
3500-4000
RFC 1323 [RFC1323] specifies an algorithm for Protection Against Wrapped Sequence Numbers (PAWS). PAWS gives a method for distinguishing between sequence numbers for new data, and sequence numbers from a previous cycle through the sequence number space. Duplicate segments might be detected by PAWS as belonging to a previous cycle through the sequence number space.
RFC 1323 [RFC1323]は包まれたシーケンス番号（PAWS）に対する保護のためのアルゴリズムを指定します。 PAWSは、シーケンス番号空間を介して、前のサイクルから新しいデータのシーケンス番号、およびシーケンス番号を区別するための方法を提供します。重複セグメントはシーケンス番号空間を介して前のサイクルに属するものとしてPAWSによって検出されるかもしれません。
RFC 1323 specifies that for such packets, the receiver should do the following:
RFC 1323には、このようなパケットに対して、受信機は、次の操作を行う必要があることを指定します。
Send an acknowledgement in reply as specified in RFC 793 page 69, and drop the segment.
RFC 793ページ69で指定されるように応答に肯定応答を送信し、セグメントをドロップ。
Since PAWS still requires sending an ACK, there is no harmful interaction between PAWS and the use of D-SACK. The D-SACK block can be included in the SACK option of the ACK, as outlined in Section 4, independently of the use of PAWS by the TCP receiver, and independently of the determination by PAWS of the validity or invalidity of the data segment.
PAWSはまだACKを送信する必要があるため、PAWSおよびD-SACKの使用の間に有害な相互作用が存在しません。 D-SACKブロックは、セクション4に概説されるように独立してTCPレシーバによってPAWSの使用、ACKのSACKオプションに含まれ、独立したデータ・セグメントの有効または無効のPAWSによる判定することができます。
TCP senders receiving D-SACK blocks should be aware that a segment reported as a duplicate segment could possibly have been from a prior cycle through the sequence number space. This is independent of the use of PAWS by the TCP data receiver. We do not anticipate that this will present significant problems for senders using D-SACK information.
D-SACKブロックを受信した送信者は、セグメントが重複セグメントとして報告されていることに注意する必要があり、TCPは、おそらくシーケンス番号空間を介して前のサイクルからだったかもしれません。これは、TCPデータ受信機によるPAWSの使用とは無関係です。これはD-SACK情報を使用して送信者のための重要な問題を提示することを予想していません。
This extension to the SACK option enables the receiver to accurately report the reception of duplicate data. Because each receipt of a duplicate packet is reported in only one ACK packet, the loss of a single ACK can prevent this information from reaching the sender. In addition, we note that the sender can not necessarily trust the receiver to send it accurate information [SCWA99].
SACKオプションにこの拡張は、正確に重複データの受信を報告するために受信機を可能にします。重複パケットの各領収書は一つだけACKパケットで報告されているため、単一ACKの損失は、送信者に届くからこの情報を防ぐことができます。また、当社は、送信者が、必ずしも正確な情報[SCWA99]それを送信するために受信機を信頼することはできませんのでご注意します。
In order for the sender to check that the first (D)SACK block of an acknowledgement in fact acknowledges duplicate data, the sender should compare the sequence space in the first SACK block to the cumulative ACK which is carried IN THE SAME PACKET. If the SACK sequence space is less than this cumulative ACK, it is an indication that the segment identified by the SACK block has been received more than once by the receiver. An implementation MUST NOT compare the sequence space in the SACK block to the TCP state variable snd.una (which carries the total cumulative ACK), as this may result in the wrong conclusion if ACK packets are reordered.
送信者が実際に肯定応答の最初の（D）SACKブロックは、重複データを認識することを確認するために、送信者は、同一のパケットで運ばれる累積ACK第1 SACKブロックのシーケンススペースとを比較すべきです。 SACKシーケンススペースはこの累積的ACKよりも小さい場合には、SACKブロックによって識別されたセグメントが受信機によって複数回受信されたことを示しています。 ACKパケットが並べ替えられる場合、これは間違った結論をもたらすことができるように実装では、（総累積ACKを運ぶ）TCPステート変数SND.UNAにSACKブロックのシーケンススペースとを比較してはいけません。
If the sequence space in the first SACK block is greater than the cumulative ACK, then the sender next compares the sequence space in the first SACK block with the sequence space in the second SACK block, if there is one. This comparison can determine if the first SACK block is reporting duplicate data that lies above the cumulative ACK.
最初のSACKブロックのシーケンススペースは累積ACKよりも大きい場合に存在する場合、送信者は、次に、第SACKブロックのシーケンス空間を有する第1のSACKブロックのシーケンススペースとを比較します。最初のSACKブロックは累積ACKの上にある重複したデータを報告している場合は、この比較が決定することができます。
TCP implementations which follow RFC 2581 [RFC2581] could see duplicate packets in each of the following four situations. This document does not specify what action a TCP implementation should take in these cases. The extension to the SACK option simply enables the sender to detect each of these cases. Note that these four conditions are not an exhaustive list of possible cases for duplicate packets, but are representative of the most common/likely cases. Subsequent documents will describe experimental proposals for sender responses to the detection of unnecessary retransmits due to reordering, lost ACKS, or early retransmit timeouts.
RFC 2581 [RFC2581]を従うTCP実装は、次の4つの各状況に重複したパケットを見ることができました。このドキュメントでは、TCPの実装では、これらの場合に実行するアクションを指定しません。 SACKオプションへの拡張は、単にこれらのケースのそれぞれを検出するために、送信者を可能にします。これら4つの条件が重複したパケットのための可能な例網羅したリストではありませんが、最も一般的な/そうな例代表的なものであることに注意してください。後続の文書が原因並べ替えに不要な再送が検出されたことに、送信者の応答のための実験的な提案を説明します、ACKS、または初期再送タイムアウトを失いました。
If a packet is replicated in the network, this extension to the SACK option can identify this. For example:
パケットがネットワーク内で複製されている場合、SACKオプションには、この拡張機能は、これを特定することができます。例えば：
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
500-999 500-999 1000
1000-1499 1000-1499 1500
(replicated)
1000-1499 1500, SACK=1000-1500
---------
In this case, the second packet was replicated in the network. An ACK containing a D-SACK block which is lower than its ACK field and is not identical to a previously retransmitted segment is indicative of a replication by the network.
この場合、第2のパケットは、ネットワーク内で複製しました。そのACKフィールドよりも低く、以前に再送信セグメントと同一ではないD-SACKブロックを含むACKは、ネットワークによって、複製の指標です。
WITHOUT D-SACK:
D-SACKなし：
If D-SACK was not used and the last ACK was piggybacked on a data packet, the sender would not know that a packet had been replicated in the network. If D-SACK was not used and neither of the last two ACKs was piggybacked on a data packet, then the sender could reasonably infer that either some data packet *or* the final ACK packet had been replicated in the network. The receipt of the D-SACK packet gives the sender positive knowledge that this data packet was replicated in the network (assuming that the receiver is not lying).
D-SACKを使用せず、最後のACKがデータパケットに背負われていた場合、送信者は、パケットがネットワーク内で複製されていたことを知ることはできません。 D-SACKを使用していなかった最後の2個のACKのどちらも、データパケットに背負われた場合、送信者は、合理的に、最終的なACKパケットがネットワークに複製されていたいずれかのいくつかのデータパケット*または*と推論できました。 D-SACKパケットを受信し、このデータパケットが（受信機が横たわっていないと仮定して）ネットワーク内で複製されたことを送信者正知識を与えます。
RESEARCH ISSUES:
研究課題：
The current SACK option already allows the sender to identify duplicate ACKs that do not acknowledge new data, but the D-SACK option gives the sender a stronger basis for inferring that a duplicate ACK does not acknowledge new data. The knowledge that a duplicate ACK does not acknowledge new data allows the sender to refrain from using that duplicate ACKs to infer packet loss (e.g., Fast Retransmit) or to send more data (e.g., Fast Recovery).
現在のSACKオプションは、すでに送信者が新しいデータを認識していない重複ACKを識別することができますが、D-SACKオプションは、送信者に重複ACKが新しいデータを認めないことを推測するための強力な基盤を提供します。重複ACKが新しいデータを認識しないという知識は、送信者が重複ACKパケットロス（例えば、高速再送信）を推論する以上のデータ（例えば、高速リカバリ）を送信することに使用を控えることができます。
If packets are reordered in the network such that a segment arrives more than 3 packets out of order, TCP's Fast Retransmit algorithm will retransmit the out-of-order packet. An example of this is shown below:
パケットは、セグメントの順序が3つの以上のパケットを到着するようなネットワークに並べ替えされている場合は、TCPの高速再送アルゴリズムは、アウトオブオーダーパケットを再送します。この一例を以下に示します。
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
500-999 500-999 1000
1000-1499 (delayed)
1500-1999 1500-1999 1000, SACK=1500-2000
2000-2499 2000-2499 1000, SACK=1500-2500
2500-2999 2500-2999 1000, SACK=1500-3000
1000-1499 1000-1499 3000
1000-1499 3000, SACK=1000-1500
---------
In this case, an ACK containing a SACK block which is lower than its ACK field and identical to a previously retransmitted segment is indicative of a significant reordering followed by a false (unnecessary) retransmission.
この場合、先に再送セグメントに対するACKフィールドよりも低いと同一であるSACKブロックを含むACKが偽（不要な）再送信が続く著しい並べ替えを示します。
WITHOUT D-SACK:
D-SACKなし：
With the use of D-SACK illustrated above, the sender knows that either the first transmission of segment 1000-1499 was delayed in the network, or the first transmission of segment 1000-1499 was dropped and the second transmission of segment 1000-1499 was duplicated. Given that no other segments have been duplicated in the network, this second option can be considered unlikely.
上記例示D-SACKを使用して、送信者は、セグメント1000年から1499年の最初の送信のいずれかがネットワークに遅延した、またはセグメント1000年から1499年の最初の送信がドロップし、セグメント1000年から1499年の第二の送信があったことを知ります重複。他のセグメントは、ネットワーク内で重複されていないことを考えると、この2番目のオプションはそう考えることができます。
Without the use of D-SACK, the sender would only know that either the first transmission of segment 1000-1499 was delayed in the network, or that either one of the data segments or the final ACK was duplicated in the network. Thus, the use of D-SACK allows the sender to more reliably infer that the first transmission of segment 1000-1499 was not dropped.
D-SACKを使用することなく、送信側は、セグメント1000年から1499年の最初の送信のいずれかがネットワークで遅延し、又はデータセグメントまたは最終ACKのいずれかがネットワーク内で重複していることを知っているであろう。したがって、D-SACKを使用することは、送信者がより確実セグメント1000年から1499年の最初の送信がドロップされなかったことを推測することを可能にします。
[AP99], [L99], and [LK00] note that the sender could unambiguously detect an unnecessary retransmit with the use of the timestamp option. [LK00] proposes a timestamp-based algorithm that minimizes the penalty for an unnecessary retransmit. [AP99] proposes a heuristic for detecting an unnecessary retransmit in an environment with neither timestamps nor SACK. [L99] also proposes a two-bit field as an alternate to the timestamp option for unambiguously marking the first three retransmissions of a packet. A similar idea was proposed in [ISO8073].
[AP99]、[L99]、および[LK00]は、送信者が明確にタイムスタンプオプションを使用して、不必要な再送信を検出できることに注意してください。 [LK00]は、不必要な再送信のためのペナルティを最小にするタイムスタンプベースのアルゴリズムを提案します。 [AP99]は、タイムスタンプやSACKでもないとの環境の中で、不必要な再送信を検出するためのヒューリスティックを提案しています。 [L99]も明確パケットの最初の三つの再送をマーキングするためのタイムスタンプオプションの代替として、2ビットのフィールドを提案しています。同様の考え方は、[ISO8073]で提案されました。
RESEARCH ISSUES:
研究課題：
The use of D-SACK allows the sender to detect some cases (e.g., when no ACK packets have been lost) when a a Fast Retransmit was due to packet reordering instead of packet loss. This allows the TCP sender to adjust the duplicate acknowledgment threshold, to prevent such unnecessary Fast Retransmits in the future. Coupled with this, when the sender determines, after the fact, that it has made an unnecessary window reduction, the sender has the option of "undoing" that reduction in the congestion window by resetting ssthresh to the value of the old congestion window, and slow-starting until the congestion window has reached that point.
D-SACKを使用することは、送信者がいくつかのケースを検出することを可能にする（例えば、どのACKパケットが失われていない場合）、高速再送信ではなく、パケットロスの並び替えパケットによるものであった場合。これは、TCPの送信者は、将来的に、このような不要な高速再送信を防ぐために、重複確認応答のしきい値を調整することができます。このと相まって、送信者が判断した場合、事実の後に、それが不要なウィンドウの削減を行ったことを、送信者は「元に戻す」のオプション古い輻輳ウィンドウの値にSSTHRESHをリセットすることで、輻輳ウィンドウの低下があり、輻輳ウィンドウは、そのポイントに到達するまで遅い開始。
Any proposal for "undoing" a reduction in the congestion window would have to address the possibility that the TCP receiver could be lying in its reports of received packets [SCWA99].
「元に戻す」ための任意の提案は、輻輳ウィンドウの減少は、TCP受信機が受信したパケット[SCWA99]のそのレポートに横たわっされる可能性に対処しなければなりません。
If an entire window of ACKs is lost, a timeout will result. An example of this is given below:
ACKのウィンドウ全体が失われた場合、タイムアウトが発生します。この例は以下の通りであります：
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
500-999 500-999 1000 (ACK dropped)
1000-1499 1000-1499 1500 (ACK dropped)
1500-1999 1500-1999 2000 (ACK dropped)
2000-2499 2000-2499 2500 (ACK dropped)
(timeout)
500-999 500-999 2500, SACK=500-1000
--------
In this case, all of the ACKs are dropped, resulting in a timeout. This condition can be identified because the first ACK received following the timeout carries a D-SACK block indicating duplicate data was received.
この場合には、ACKのすべてがタイムアウトになり、ドロップされます。最初のACKを受信したので、この条件は、タイムアウト後に同定することができ、重複データを示すD-SACKブロックが受信された運びます。
WITHOUT D-SACK:
D-SACKなし：
Without the use of D-SACK, the sender in this case would be unable to decide that no data packets has been dropped.
D-SACKを使用せず、この場合、送信側はデータパケットが廃棄されていないことを決定することができないであろう。
RESEARCH ISSUES:
研究課題：
For a TCP that implements some form of ACK congestion control [BPK97], this ability to distinguish between dropped data packets and dropped ACK packets would be particularly useful. In this case, the connection could implement congestion control for the return (ACK) path independently from the congestion control on the forward (data) path.
ACK輻輳制御の何らかの形[BPK97]、データ・パケットをドロップし、ACKパケットが特に有用であろう滴下区別するためにこの機能を実装するためのTCP。この場合、接続は、順方向（データ）パス上の輻輳制御から独立してリターン（ACK）パスの輻輳制御を実装することができました。
If the sender's RTO is too short, an early retransmission timeout can occur when no packets have in fact been dropped in the network. An example of this is given below:
送信者のRTOが短すぎるとパケットが実際にネットワークにドロップされていない場合は、早期再送タイムアウトが発生する可能性があります。この例は以下の通りであります：
Transmitted Received ACK Sent
Segment Segment (Including SACK Blocks)
500-999 (delayed)
1000-1499 (delayed)
1500-1999 (delayed)
2000-2499 (delayed)
(timeout)
500-999 (delayed)
500-999 1000
1000-1499 (delayed)
1000-1499 1500
...
1500-1999 2000
2000-2499 2500
500-999 2500, SACK=500-1000
--------
1000-1499 2500, SACK=1000-1500
---------
...
In this case, the first packet is retransmitted following the timeout. Subsequently, the original window of packets arrives at the receiver, resulting in ACKs for these segments. Following this, the retransmissions of these segments arrive, resulting in ACKs carrying SACK blocks which identify the duplicate segments.
この場合、最初のパケットは、タイムアウト、次の再送信されます。続いて、パケットの元のウィンドウは、これらのセグメントのためのACK、その結果、受信機に到着します。これに続いて、これらのセグメントの再送は重複セグメントを識別SACKブロックを運ぶACKをもたらす、到着します。
This can be identified as an early retransmission timeout because the ACK for byte 1000 is received after the timeout with no SACK information, followed by an ACK which carries SACK information (500- 999) indicating that the retransmitted segment had already been received.
バイト1000 ACKが再送セグメントが既に受信されたことを示すSACK情報（500〜999）を運ぶACKに続いて、無SACK情報をタイムアウト後に受信されるので、これは初期再送タイムアウトとして識別することができます。
WITHOUT D-SACK:
D-SACKなし：
If D-SACK was not used and one of the duplicate ACKs was piggybacked on a data packet, the sender would not know how many duplicate packets had been received. If D-SACK was not used and none of the duplicate ACKs were piggybacked on a data packet, then the sender would have sent N duplicate packets, for some N, and received N duplicate ACKs. In this case, the sender could reasonably infer that some data or ACK packet had been replicated in the network, or that an early retransmission timeout had occurred (or that the receiver is lying).
D-SACKを使用しないと、重複ACKの一つは、データパケットに背負われた場合は、送信者が受信されていたどのように多くの重複パケット知ることはできません。 D-SACKを使用しないと、重複ACKのいずれもデータパケットに便乗しなかった場合、送信者は、いくつかのNのために、パケットを複製N送信され、N個のACKを複製受けているだろう。この場合、送信者は、合理的にいくつかのデータまたはACKパケットがネットワークに複製されていたこと、または早期再送タイムアウトが発生していたこと（あるいは受信機が横たわっていること）を推測できました。
RESEARCH ISSUES:
研究課題：
After the sender determines that an unnecessary (i.e., early) retransmit timeout has occurred, the sender could adjust parameters for setting the RTO, to prevent more unnecessary retransmit timeouts. Coupled with this, when the sender determines, after the fact, that it has made an unnecessary window reduction, the sender has the option of "undoing" that reduction in the congestion window.
送信者が不要（すなわち、初期）再送タイムアウトが発生したと判断した後、送信者はより多くの不必要な再送タイムアウトを防止するために、RTOを設定するためのパラメータを調整することができました。送信者が判断した場合、このと相まって、事実の後に、それが不要なウィンドウの削減を行ったことを、送信者は輻輳ウィンドウの「元に戻す」という削減のオプションがあります。
This document neither strengthens nor weakens TCP's current security properties.
この文書では、どちらも強くもなく、TCPの現在のセキュリティプロパティを弱めます。
We would like to thank Mark Handley, Reiner Ludwig, and Venkat Padmanabhan for conversations on these issues, and to thank Mark Allman for helpful feedback on this document.
我々は、これらの問題についての会話のためのマーク・ハンドリー、ライナールートヴィヒ、およびヴェンカトPadmanabhanに感謝して、この文書に関する有益なフィードバックのためのマーク・オールマンに感謝したいと思います。
[AP99] Mark Allman and Vern Paxson, On Estimating End-to-End Network Path Properties, SIGCOMM 99, August 1999. URL "http://www.acm.org/sigcomm/sigcomm99/papers/session7- 3.html".
[AP99]マークオールマンとバーン・パクソン、推定エンドツーエンドのネットワークパスの性質について、SIGCOMM 99、1999年8月URL「http://www.acm.org/sigcomm/sigcomm99/papers/session7- 3.html」 。
[BPS99] J.C.R. Bennett, C. Partridge, and N. Shectman, Packet Reordering is Not Pathological Network Behavior, IEEE/ACM Transactions on Networking, Vol. 7, No. 6, December 1999, pp. 789-798.
[BPS99] J.C.R.ベネット、C.パートリッジ、およびN. Shectman、パケットの順序変更はネットワーキング、巻上のIEEE / ACM取引、病理学的ネットワークの動作ではありません。図7に示すように、第6号、1999年12月、頁789-798。
[BPK97] Hari Balakrishnan, Venkata Padmanabhan, and Randy H. Katz, The Effects of Asymmetry on TCP Performance, Third ACM/IEEE Mobicom Conference, Budapest, Hungary, Sep 1997. URL "http://www.cs.berkeley.edu/~padmanab/ index.html#Publications".
[BPK97]ハリ・バラクリシュナン、ヴェンカタPadmanabhan、およびランディH.カッツ、TCPパフォーマンス、第三ACM / IEEEモビコム会議、ブダペスト、ハンガリー、9月1997 URL「http://www.cs.berkeley.edu上の非対称性の影響/〜padmanab / index.htmlを＃出版」。
[F99] Floyd, S., Re: TCP and out-of-order delivery, Message ID <199902030027.QAA06775@owl.ee.lbl.gov> to the end-to-end-interest mailing list, February 1999. URL "http://www.aciri.org/floyd/notes/TCP_Feb99.email".
[F99]フロイド、S.、再：TCPとアウト・オブ・オーダーの配信、メッセージID <199902030027.QAA06775@owl.ee.lbl.gov>エンド・ツー・エンド・関心メーリングリストに、1999年2月URL "http://www.aciri.org/floyd/notes/TCP_Feb99.email"。
[ISO8073] ISO/IEC, Information-processing systems - Open Systems Interconnection - Connection Oriented Transport Protocol Specification, Internation Standard ISO/IEC 8073, December 1988.
[ISO8073] ISO / IEC、情報処理システム - 開放型システム間相互接続 - コネクション型トランスポートプロトコル仕様、INTERNATION標準ISO / IEC 8073、1988年12月。
[L99] Reiner Ludwig, A Case for Flow Adaptive Wireless links, Technical Report UCB//CSD-99-1053, May 1999. URL "http://iceberg.cs.berkeley.edu/papers/Ludwig-FlowAdaptive/".
[L99]ライナールートヴィヒ、フローのAdaptive Wirelessリンク用ケース、テクニカルレポートUCB // CSD-99から1053まで、1999年5月URL "http://iceberg.cs.berkeley.edu/papers/Ludwig-FlowAdaptive/"。
[LK00] Reiner Ludwig and Randy H. Katz, The Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions, SIGCOMM Computer Communication Review, V. 30, N. 1, January 2000. URL "http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-2000.html".
[LK00]ライナールートヴィヒとランディH.カッツ、アイフェルアルゴリズム：スプリアス再送、SIGCOMMコンピュータコミュニケーションレビュー、V. 30、N. 1に対してロバストTCPを作り、2000年1月URL「http://www.acm.org/ SIGCOMM / CCR /アーカイブ/ CCR-TOC / CCR-TOC-2000.html」。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323]ジェーコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, April 1996.
[RFC2018]マティス、M.、Mahdavi、J.、フロイド、S.とA. Romanow、 "TCPの選択確認応答オプション"、RFC 2018、1996年4月。
[RFC2581] Allman, M., Paxson,V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581]オールマン、M.、パクソン、V。そして、W.スティーブンス、 "TCP輻輳制御"、RFC 2581、1999年4月。
[SCWA99] Stefan Savage, Neal Cardwell, David Wetherall, Tom Anderson, TCP Congestion Control with a Misbehaving Receiver, ACM Computer Communications Review, pp. 71-78, V. 29, N. 5, October, 1999. URL "http://www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-99.html".
【SCWA99]ステファン・サヴェージ、ニールカードウェル、デイビット・ウェザーオール、トム・アンダーソン、ふらちなレシーバーとのTCP輻輳制御、ACMコンピュータコミュニケーションレビュー、頁71-78、V. 29、N. 5、10月、1999年URLは「http： //www.acm.org/sigcomm/ccr/archive/ccr-toc/ccr-toc-99.html」。
Authors' Addresses
著者のアドレス
Sally Floyd AT&T Center for Internet Research at ICSI (ACIRI)
サリーフロイドAT＆T ICSIでのインターネット研究センター（ACIRI）
Phone: +1 510-666-6989 EMail: floyd@aciri.org URL: http://www.aciri.org/floyd/
電話：+1 510-666-6989電子メール：floyd@aciri.org URL：http://www.aciri.org/floyd/
Jamshid Mahdavi Novell
ジャムシードMahdaviノベル
Phone: 1-408-967-3806 EMail: mahdavi@novell.com
電話：1-408-967-3806 Eメール：mahdavi@novell.com
Matt Mathis Pittsburgh Supercomputing Center
マット・マシスピッツバーグスーパーコンピューティングセンター
Phone: 412 268-3319 EMail: mathis@psc.edu URL: http://www.psc.edu/~mathis/
電話番号：412 268-3319 Eメール：mathis@psc.edu URL：http://www.psc.edu/~mathis/
Matthew Podolsky UC Berkeley Electrical Engineering & Computer Science Dept.
マシュー・ポドルスキーUCバークレー校電気工学＆コンピュータサイエンス専攻
Phone: 510-649-8914 EMail: podolsky@eecs.berkeley.edu URL: http://www.eecs.berkeley.edu/~podolsky
電話：510-649-8914 Eメール：podolsky@eecs.berkeley.eduのURL：http://www.eecs.berkeley.edu/~podolsky
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。