[要約] RFC 2883は、TCPの選択的確認（SACK）オプションの拡張であり、パフォーマンスの向上とネットワークの効率化を目的としています。
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.
Copyright（c）The Internet Society（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]に記載されているように解釈される場合、必要な、要求されてはなりません。
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オプションの使用を指定していません。このメモは、重複パケットの受領を確認するときにSACKオプションの使用を指定します[F99]。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が累積確認フィールドを使用したこと、またはAumponedmentパケットを送信するための *時た *の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オプションの現在の実装と互換性があります。つまり、1つのTCPエンドノードの1つがこのD-Sack拡張機能を実装しておらず、もう1つのTCPエンドノードが実装していない場合、Endノードの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の使用では、既にネゴシエートされたサック機能を既に交渉したTCP送信者とレシーバーとの間の個別の交渉は必要ありません。D-Sackの個別の交渉がないことは、TCP受信機がTCP送信者がこの拡張機能を理解していない場合にD-Sackブロックを送信できることを意味します。この場合、TCP送信者は、d-sackブロックを単純に破棄し、通常と同じようにサックオプションフィールドの他のサックブロックを処理します。
The SACK option as defined in RFC 2018 is as follows:
RFC 2018で定義されているサックオプションは次のとおりです。
+--------+--------+
| 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レシーバーで受信したデータブロックの左右の端を指定する多数のサックブロックが含まれています。特に、ブロックは、ブロックの「左端」がブロックの最初のシーケンス番号であり、「右端」が直後にブロックの最初のシーケンス番号であるレシーバーで受け取ったデータの連続的なシーケンス空間を表します。ブロックの最後のシーケンス番号。
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は、最初のサックブロックが確認をトリガーしたセグメントを指定することを意味します。RFC 2018から、データ受信者がサックオプションを送信することを選択したとき、「最初のサックブロック...この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はさらに、「データ受信機のキューで最高のシーケンス番号を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オプションを使用する場合のサックブロックの使用を指定します。d-sackを使用する場合、sackオプションの最初のブロックは、確認をトリガーする重複セグメントのシーケンス番号を指定するDサックブロックである必要があります。重複セグメントが受信機のデータキュー内の非連続データの大きなブロックの一部である場合、次のサックブロックを使用して、この大きなブロックを指定する必要があります。RFC 2018で指定されているように、追加のサックブロックを使用して、データの追加の非連続ブロックを指定できます。
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サックブロックで報告されます。（つまり、受信者は、レシーバーが2つの重複セグメントを受信した場合にのみ、後続のパケットに2つの同一のDサックブロックを送信します。）
(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ブロックが、累積確認の上にあるレシーバーのデータキュー内の（おそらく大きい）データブロックからの重複連続シーケンスを報告する場合、そのサックオプションの2番目のサックブロックは、（おそらくより大きい）データブロックを指定する必要があります。
(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.
(5) 重複セグメントを報告するために上記のサックブロックに従って、RFC 2018で指定されているように、追加のサックブロックを追加のデータブロックを報告するために使用できます。
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.
各重複セグメントは1つの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ブロックは、各例で下線が引かれています。
4.1.1. Example 1: Reporting a duplicate segment.
4.1.1. 例1：重複セグメントの報告。
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に設定し、最初のd-sackブロックを指定したシーケンス番号3000-3500を指定する累積確認フィールドで確認を送信します。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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で指定されているSACKオプションをトリガーするオーダーアウトデータセグメントを受信します。いくつかの紛失したACKパケットのため、送信者はデータパケットを再送信します。レシーバーは重複パケットを受信し、最初のDサックブロックに報告します。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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
---------
4.1.3. Example 3: Reporting a duplicate of an out-of-order segment.
4.1.3. 例3：注文外セグメントの複製を報告します。
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:
データパケットが失われたため、受信機は2つのオーダーアウトオブオーダーセグメントを受け取ります。次に、レシーバーは、これらのオーダーアウトオブオーダーセグメントのいずれかの重複セグメントを受け取ります。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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オプションが部分的な重複セグメントを報告するために使用される場合、最初のD-Sackブロックは最初の重複サブセグメントを報告します。承認されているデータパケットに複数の部分的な複製サブセグメントが含まれている場合、SACKオプションで最初のそのような重複サブセグメントのみが報告されます。これを以下の例で説明します。
4.2.1. Example 4: Reporting a single duplicate subsegment.
4.2.1. 例4：単一の複製サブセグメントの報告。
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.
送信者は、パケットサイズを500バイトから1000バイトに増やします。その後、レシーバーは、すでに受信されている500バイトのサブセグメントを含む1000バイトのパケットとそうでないものを受け取ります。レシーバーは、単一のDサックブロックを使用して、すでに受信したサブセグメントのみを報告します。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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：累積認識でカバーされている2つの非連続的な重複サブセグメント。
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.
送信者がパケットサイズを500バイトから1500バイトに増やした後、受信者は、累積確認フィールドよりも少ない2つの非連続的な重複500バイトサブセグメントを含むパケットを受け取ります。受信機は、最初のそのような重複セグメントを単一のDサックブロックに報告します。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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：累積認識でカバーされていない2つの非連続的な重複サブセグメント。
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.
この例は例5に似ていますが、送信者がパケットサイズを増やした後、受信機は、累積的な確認フィールドの上にある2つの非連続的な重複サブセグメントを含むパケットを受け取ることを除きます。最初のD-Sackブロックは、最初の重複サブセグメントを報告し、2番目のSackブロックは、それが属する非連続データの大きなブロックを報告します。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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 Page 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.
足はまだACKを送信する必要があるため、足とDサックの使用の間に有害な相互作用はありません。D-Sackブロックは、TCPレシーバーによるPAWSの使用とは無関係に、セクション4で概説されているように、データセグメントの有効性または無効性のPAWによる決定とは無関係に、ACKのSACKオプションに含めることができます。
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データレシーバーによるPAWの使用とは無関係です。これが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オプションのこの拡張機能により、受信者は重複データの受信を正確に報告できます。重複パケットの各受領は1つの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）サックブロックが複製データを確認することを確認するために、送信者は最初のサックブロックのシーケンススペースを同じパケットで運ばれる累積ACKと比較する必要があります。サックシーケンススペースがこの累積ACKよりも少ない場合、サックブロックによって識別されたセグメントがレシーバーによって複数回受信されたことを示しています。実装は、Sackブロックのシーケンス空間をTCP状態変数SND.UNA（合計累積ACKを運ぶ）と比較してはなりません。これにより、ACKパケットが再注文された場合、間違った結論が発生する可能性があります。
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.
最初のサックブロックのシーケンススペースが累積ACKよりも大きい場合、送信者は次に、最初のサックブロックのシーケンススペースを2番目のサックブロックのシーケンススペースと比較します。この比較により、最初のサックブロックが累積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つの条件は、重複パケットの可能なケースの網羅的なリストではなく、最も一般的/可能性の高いケースを代表していることに注意してください。その後の文書では、並べ替え、ACKの紛失、または早期の再送信タイムアウトによる不必要な再送信の検出に対する送信者の応答に関する実験的提案について説明します。
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)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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サックブロックを含む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)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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フィールドよりも低く、以前に再送信されたセグメントと同一のサックブロックを含む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番目の伝送が削除されたことを知っています。複製。ネットワークで他のセグメントが複製されていないことを考えると、この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]は、タイムスタンプも袋もない環境で不必要な再送信を検出するためのヒューリスティックを提案しています。[L99]は、パケットの最初の3つの再送信を明確にマークするためのタイムスタンプオプションの代替として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)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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サックブロックを運ぶため、特定できます。
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]を実装するTCPの場合、ドロップされたデータパケットとドロップされたACKパケットを区別するこの能力は特に役立ちます。この場合、接続は、フォワード（データ）パス上の渋滞制御とは独立して、リターン（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)
送信されたACK送信セグメントセグメント（サックブロックを含む）
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が袋ブロックを運ぶことになります。
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が続くため、早期の再送信タイムアウトとして識別できます。
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が使用されず、重複したAcksの1つがデータパケットでピギーバックされた場合、送信者は重複したパケットの数を知りません。d-sackが使用されず、データパケットに重複したアックがピギーバックされていない場合、送信者はいくつかのnに対してn重複パケットを送信し、n重複したAcksを受け取りました。この場合、送信者は、一部のデータまたは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.
これらの問題に関する会話について、マーク・ハンドリー、ライナー・ルートヴィヒ、ベンカット・パドマナバンに感謝し、この文書に関する有益なフィードバックをしてくれたマーク・オールマンに感謝します。
[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] Mark Allman and Vern Paxson、エンドツーエンドネットワークパスプロパティの推定、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.Bennett、C。Partridge、およびN. Shectman、Packet Reorderingは病理学的ネットワークの動作ではなく、IEEE/ACMトランザクションでのネットワーク、Vol。7、No。6、1999年12月、pp。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] Hari Balakrishnan、Venkata Padmanabhan、およびRandy H. Katz、TCPパフォーマンスに対する非対称性の影響、3回目のACM/IEEE Mobicom Conference、1997年9月。/ 〜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] Floyd、S.、Re：TCPおよびOut-Order Delivery、Message ID <199902030027.QAA06775@OWL.EE.LBL.GOV> 1999年2月。"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、情報処理システム - オープンシステムの相互接続 - 接続指向輸送プロトコル仕様、1988年12月、Internation Standard ISO/IEC 8073。
[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] Reiner Ludwig、Flow Adaptive Wireless Linksのケース、テクニカルレポート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] Reiner LudwigとRandy H. Katz、アイフェルアルゴリズム：Sigcomm Computer Communication Review、V。30、N。1、2000年1月にTCPを堅牢にする。sigcomm/ccr/archive/ccr-toc/ccr-toc-2000.html "。
[RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[RFC1323] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のためのTCP拡張」、RFC 1323、1992年5月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgement Options", RFC 2018, April 1996.
[RFC2018] Mathis、M.、Mahdavi、J.、Floyd、S。、およびA. Romanow、「TCP選択的承認オプション」、RFC 2018、1996年4月。
[RFC2581] Allman, M., Paxson,V. and W. Stevens, "TCP Congestion Control", RFC 2581, April 1999.
[RFC2581] Allman、M.、Paxson、v。W. Stevens、「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] Stefan Savage、Neal Cardwell、David Wetherall、Tom Anderson、TCP混雑制御、ACM Computer Communications Review、pp。71-78、V。29、N。5、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)
ICSIのインターネット研究のためのSally Floyd AT＆Tセンター（Aciri）
Phone: +1 510-666-6989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
Jamshid Mahdavi Novell
Jamshid Mahdavi Novell
Phone: 1-408-967-3806 EMail: mahdavi@novell.com
電話：1-408-967-3806メール：mahdavi@novell.com
Matt Mathis Pittsburgh Supercomputing Center
マットマティスピッツバーグスーパーコンピューティングセンター
Phone: 412 268-3319
EMail: 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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。