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
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规定使用SACK选项确认TCP的累积确认字段未涵盖的无序数据。本说明通过指定使用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.
TCP数据接收器使用RFC 2018中定义的选择性确认（SACK）选项确认累积确认字段未涵盖的非连续数据块。但是，RFC 2018未规定在收到重复段时使用SACK选项。此说明指定在确认收到重复数据包时使用SACK选项[F99]。我们使用术语D-SACK（用于重复SACK）来指代报告重复段的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端节点实现了，那么我们相信其中一个端节点使用这个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 |
+--------+--------+--------+--------+
+--------+--------+
| 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）选项包含许多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意味着第一个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中。”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块指定此较大的块。额外的SACK块可用于指定额外的非连续数据块，如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) 接收到的每个重复连续数据序列最多在一个D-SACK块中报告。（即，仅当接收器接收到两个重复段时，接收器才会在后续数据包中发送两个相同的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.
(5) 按照上述用于报告重复段的SACK块，额外的SACK块可用于报告额外的数据块，如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.
请注意，由于每个重复段仅在一个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.
我们用三个例子来说明这些准则。在每个示例中，我们假设数据接收器首先接收到每个500字节的八个段，并且发送了一个确认，其中累积确认字段设置为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)
发送-接收-确认-发送段段（包括SACK块）
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.
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-SACK块中报告它：
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
发送-接收-确认-发送段段（包括SACK块）
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
---------
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:
由于数据包丢失，接收器接收到两个无序段。接下来，接收器接收这些无序段之一的重复段：
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
发送-接收-确认-发送段段（包括SACK块）
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
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.
发送方可能发送包含一个或多个重复子段的数据包——也就是说，仅部分但并非全部发送的数据包已经到达接收方。这可以发生在发送器发送段的大小增加时，例如，当在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字节。接收器随后接收一个1000字节的数据包，其中包含一个已经接收到的500字节子段和一个尚未接收到的500字节子段。接收器使用单个D-SACK块仅报告已接收的子段。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
发送-接收-确认-发送段段（包括SACK块）
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
---------
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.
在发送方将其数据包大小从500字节增加到1500字节后，接收方接收到包含两个非连续重复的500字节子段的数据包，这些子段小于累积确认字段。接收器在单个D-SACK块中报告第一个这样的重复段。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
发送-接收-确认-发送段段（包括SACK块）
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
---------
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.
该示例类似于示例5，不同之处在于，在发送方增加分组大小之后，接收方接收到包含两个非连续重复子段的分组，这两个子段位于累积确认字段之上而不是之下。第一个D-SACK块报告第一个重复的子段，第二个SACK块报告它所属的较大的非连续数据块。
Transmitted Received ACK Sent Segment Segment (Including SACK Blocks)
发送-接收-确认-发送段段（包括SACK块）
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
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]指定了一种针对包裹序列号（PAW）的保护算法。PAWS提供了一种方法，用于区分新数据的序列号和序列号空间中前一个周期的序列号。重复段可能被PAW检测为属于序列号空间中的前一个周期。
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的使用之间没有有害的交互作用。如第4节所述，D-SACK块可包括在ACK的SACK选项中，与TCP接收器使用PAW无关，也与PAW确定数据段的有效性或无效性无关。
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选项的扩展使接收器能够准确报告重复数据的接收情况。由于重复数据包的每次接收仅在一个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块是否确实确认了重复数据，发送方应将第一个SACK块中的序列空间与同一数据包中携带的累积ACK进行比较。如果SACK序列空间小于该累计ACK，则表明SACK块标识的段已被接收器接收多次。实现不能将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.
如果第一个SACK块中的序列空间大于累积ACK，则发送方接下来比较第一个SACK块中的序列空间与第二个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.
遵循RFC22581[RFC2581]的TCP实现在以下四种情况中的每种情况下都可能看到重复的数据包。本文档未指定TCP实现在这些情况下应采取的操作。SACK选项的扩展只允许发送方检测这些情况中的每一个。请注意，这四种情况并不是重复数据包的可能情况的详尽列表，而是最常见/可能的情况的代表。随后的文档将描述发送方响应的实验方案，以检测由于重新排序、丢失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)
发送-接收-确认-发送段段（包括SACK块）
500-999 500-999 1000
1000-1499 1000-1499 1500
(replicated)
1000-1499 1500, SACK=1000-1500
---------
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.
在这种情况下，第二个数据包在网络中被复制。包含低于其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，并且最后两个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)
发送-接收-确认-发送段段（包括SACK块）
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
---------
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段的第二次传输被复制。考虑到网络中没有复制其他段，可以认为第二种选择不太可能。
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]还提出了两位字段作为时间戳选项的替代，用于明确标记数据包的前三次重传。[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
D-SACK的使用允许发送方检测由于数据包重新排序而不是数据包丢失而导致快速重传的某些情况（例如，没有丢失任何ACK数据包）。这允许TCP发送方
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.
调整重复确认阈值，以防止将来出现此类不必要的快速重传。与此相结合，当发送方在事实发生后确定其进行了不必要的窗口缩减时，发送方可以选择通过将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)
发送-接收-确认-发送段段（包括SACK块）
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
--------
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]的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)
发送-接收-确认-发送段段（包括SACK块）
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
---------
...
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。随后，这些段的重传到达，导致ack携带识别重复段的SACK块。
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信息，随后是一个ACK，该ACK携带SACK信息（500-999），指示已接收到重传的段。
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
如果没有使用D-SACK，并且其中一个重复的ACK被装载在一个数据包上，发送方将不知道收到了多少个重复的数据包。如果没有使用D-SACK，并且数据包上没有任何重复的ACK，那么发送方将发送N个重复的数据包（对于某些N个），并接收N个重复的ACK。在这种情况下，发送方可以合理地推断
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).
某些数据或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.
我们要感谢Mark Handley、Reiner Ludwig和Venkat Padmanabhan就这些问题进行的对话，并感谢Mark Allman对本文件的有用反馈。
[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和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，数据包重新排序不是病态的网络行为，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]Hari Balakrishnan，Venkata Padmanabhan和Randy H.Katz，《不对称对TCP性能的影响》，第三届ACM/IEEE Mobicom会议，匈牙利布达佩斯，1997年9月。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]Floyd，S.，Re: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，信息处理系统-开放系统互连-面向连接的传输协议规范，国际标准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]Reiner Ludwig，《流量自适应无线链路案例》，技术报告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，《Eifel算法：使TCP对伪重传具有鲁棒性》，SIGCOMM计算机通信评论，第30卷，第1期，2000年1月。URL“http://www.acm.org/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扩展”，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 25811999年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 Wetheral，Tom Anderson，TCP拥塞控制与行为不端的接收器，ACM计算机通信评论，第71-78页，第29节，第5页，1999年10月。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互联网研究中心（ACIRI）
Phone: +1 510-666-6989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
Phone: +1 510-666-6989
EMail: floyd@aciri.org
URL: http://www.aciri.org/floyd/
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/
Phone: 412 268-3319
EMail: mathis@psc.edu
URL: http://www.psc.edu/~mathis/
Matthew Podolsky UC Berkeley Electrical Engineering & Computer Science Dept.
马修·波多尔斯基加州大学伯克利分校电气工程与计算机科学系。
Phone: 510-649-8914
EMail: podolsky@eecs.berkeley.edu
URL: http://www.eecs.berkeley.edu/~podolsky
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.
版权所有（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编辑功能的资金目前由互联网协会提供。