rfc2883.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页
TXT
956 行
the examples below.
4.2.1. Example 4: Reporting a single duplicate subsegment.
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.
Floyd, et al. Standards Track [Page 6]
RFC 2883 SACK Extension July 2000
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.
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.
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.
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.
Floyd, et al. Standards Track [Page 7]
RFC 2883 SACK Extension July 2000
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
4.3. Interaction Between D-SACK and PAWS
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 specifies that for such packets, the receiver should do the
following:
Send an acknowledgement in reply as specified in RFC 793 page 69,
and drop the segment.
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.
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.
Floyd, et al. Standards Track [Page 8]
RFC 2883 SACK Extension July 2000
5. Detection of Duplicate Packets
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].
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.
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.
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.
Floyd, et al. Standards Track [Page 9]
RFC 2883 SACK Extension July 2000
5.1. Replication by the network
If a packet is replicated in the network, this extension to the SACK
option can identify this. For example:
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.
WITHOUT 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).
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).
5.2. False retransmit due to reordering
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:
Floyd, et al. Standards Track [Page 10]
RFC 2883 SACK Extension July 2000
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.
WITHOUT 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.
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.
[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].
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
Floyd, et al. Standards Track [Page 11]
RFC 2883 SACK Extension July 2000
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.
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].
5.3. Retransmit Timeout Due to ACK Loss
If an entire window of ACKs is lost, a timeout will result. An
example of this is given below:
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?