📄 rfc2883.txt
字号:
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-40004.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 20005. 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 20005.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 senderFloyd, 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 + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -