rfc2883.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页
TXT
956 行
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
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.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
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.
1. Conventions and Acronyms
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].
Floyd, et al. Standards Track [Page 1]
RFC 2883 SACK Extension July 2000
2. Introduction
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.
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.
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.
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.
Floyd, et al. Standards Track [Page 2]
RFC 2883 SACK Extension July 2000
3. The Sack Option Format as defined in RFC 2018
The SACK option as defined in RFC 2018 is as follows:
+--------+--------+
| 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.
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."
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.
Floyd, et al. Standards Track [Page 3]
RFC 2883 SACK Extension July 2000
4. Use of the SACK option for reporting a duplicate segment
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.
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.
(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.)
(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.
(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.
(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.
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.
4.1 Reporting Full Duplicate Segments
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.
Floyd, et al. Standards Track [Page 4]
RFC 2883 SACK Extension July 2000
4.1.1. Example 1: Reporting a duplicate segment.
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.
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:
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
---------
Floyd, et al. Standards Track [Page 5]
RFC 2883 SACK Extension July 2000
4.1.3. Example 3: Reporting a duplicate of an out-of-order segment.
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.
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
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?