idnits 2.17.1 draft-blanton-dsack-use-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 9 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 15, but not defined == Missing Reference: 'RFC2119' is mentioned on line 44, but not defined == Missing Reference: 'WES01' is mentioned on line 210, but not defined == Unused Reference: 'FF99' is defined on line 231, but no explicit reference was found in the text == Unused Reference: 'WES00' is defined on line 265, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AP99' -- No information found for draft-blanton-tcp-dupack-thresh-adjust - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BA01' -- Possible downref: Non-RFC (?) normative reference: ref. 'BA02a' == Outdated reference: A later version (-13) exists of draft-allman-tcp-sack-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'FF99' -- Possible downref: Non-RFC (?) normative reference: ref. 'LK00' == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-tcp-eifel-alg-05 ** Downref: Normative reference to an Experimental draft: draft-ietf-tsvwg-tcp-eifel-alg (ref. 'LM02') -- Possible downref: Non-RFC (?) normative reference: ref. 'Pax97' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-04) exists of draft-sarolahti-tsvwg-tcp-frto-01 -- Possible downref: Normative reference to a draft: ref. 'SK02' == Outdated reference: A later version (-04) exists of draft-ietf-tsvwg-tcp-nonce-00 ** Downref: Normative reference to an Historic draft: draft-ietf-tsvwg-tcp-nonce (ref. 'WES00') Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Ethan Blanton 2 INTERNET DRAFT Purdue University 3 File: draft-blanton-dsack-use-02.txt Mark Allman 4 BBN/NASA GRC 5 October, 2002 6 Expires: April, 2003 8 Using TCP DSACKs and SCTP Duplicate TSNs 9 to Detect Spurious Retransmissions 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 TCP and SCTP provide notification of duplicate segment receipt 35 through DSACK and Duplicate TSN notification, respectively. This 36 document presents a conservative method of using this information 37 to identify unnecessary retransmissions. 39 Terminology 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 43 document are to be interpreted as described in RFC 2119 [RFC2119]. 45 1 Introduction 47 TCP [RFC793] and SCTP [RFC2960] provide notification of duplicate 48 segment receipt through DSACK [RFC2883] and Duplicate TSN 49 notifications, respectively. Using this information, a TCP or SCTP 50 sender can generally determine when a retransmission was sent in 51 error. This document presents a conservative algorithm to 52 disambiguate unnecessary retransmissions from loss events for the 53 purpose of undoing unnecessary congestion control changes (although 54 specifying methods for reversing unneeded congestion control changes 55 is beyond the scope of this document). 57 While DSACKs and duplicate TSN notifications can be caused by 58 segments being duplicated by the network, [Pax97] shows this is 59 rare. Some network paths may exhibit this problem more than others, 60 but we do not believe it to be a general problem. Therefore the 61 algorithm presented in this document is disabled when duplication of 62 segments by the network is detected. 64 This document is intended to outline a reasonable and safe algorithm 65 for detecting spurious retransmissions and discuss some of the 66 considerations involved. It is not intended to describe the only 67 possible method for achieving the goal, although the guidelines in 68 this document should be taken into consideration when designing 69 alternate algorithms. Additionally, this document does not outline 70 what a TCP or SCTP sender may do after a spurious retransmission is 71 detected. Some possibilities are mentioned in [RFC2883], such as 72 reverting changes made to the congestion control state. Discussion 73 of this topic is left to a companion document that makes no 74 assumptions about the manner in which spurious retransmissions are 75 detected [BA01]. 77 2 The Algorithm 79 The complexity of the algorithm used for detecting spurious 80 retransmits depends on the purpose in determining this information. 81 For instance, if a sender is only interested in keeping a count of 82 the number of spurious retransmits the information can be derived 83 directly from the returning DSACK or duplicate TSN notifications. 85 However, if the purpose of detecting spurious retransmissions is to 86 ``undo'' unnecessary changes made to the congestion control state, 87 as suggested in [RFC2883], the data sender needs to ensure that 88 spurious retransmissions in a particular window of data do not mask 89 real segment loss before reverting the congestion control state. 91 For example, say segments N and N+1 are retransmitted. Assume that 92 segment N was dropped by the network and segment N+1 was needlessly 93 retransmitted. When the sender receives the notification that 94 segment N+1 arrived more than once it can conclude that segment N+1 95 was needlessly resent. However, it cannot conclude that it is 96 appropriate to revert the congestion control state because the 97 window of data contained at least one real congestion indication 98 (i.e., segment N was lost). 100 The following algorithm ensures that all retransmissions sent in a 101 particular window are, in fact, needless. We assume the TCP sender 102 has a data structure to hold selective acknowledgment information 103 (e.g., as outlined in [BA02b]). The following steps MUST be taken 104 upon the receipt of each DSACK or duplicate TSN notification: 106 (A) Check the corresponding sequence range or TSN to determine 107 whether the segment has been retransmitted. 109 (A.1) If the segment was retransmitted, mark it as a duplicate. 111 (A.2) If the segment was not retransmitted the incoming DSACK 112 indicates that the network duplicated the segment in 113 question. Processing of this DSACK MUST be terminated. In 114 addition, the algorithm specified in this document MUST NOT 115 be used for the remainder of the connection, as future DSACK 116 reports may be indicating network duplication rather than 117 unnecessary retransmission. Note that some techniques to 118 further disambiguate network duplication from unnecessary 119 retransmission (e.g., the TCP timestamp option [RFC1323]) 120 may be used to refine the algorithm in this document 121 further. Using such a technique in conjunction with an 122 algorithm similar to the one presented herein may allow for 123 the continued use of the algorithm in the face of duplicated 124 segments. We do not delve into such an algorithm in this 125 document due the current rarity of network duplication. 126 However, future work should include tackling this problem. 128 (B) Check all retransmitted segments in the previous window of 129 data. 131 (B.1) If all segments or chunks marked as retransmitted have 132 also been marked as duplicate, we conclude that all 133 retransmissions in the previous window of data were spurious 134 and no loss occurred. 136 (B.2) If any segment or chunk is still marked as retransmitted 137 but not marked as duplicate, there are outstanding 138 retransmissions that could indicate loss within this window 139 of data. We can make no conclusions based on this 140 particular DSACK/duplicate TSN notification. 142 In addition to keeping the state mentioned in [BA02b] (for TCP) and 143 [RFC2960] (for SCTP), an implementation of this algorithm must track 144 all sequence numbers or TSNs that have been acknowledged as 145 duplicates. 147 3 Related Work 149 In addition to the mechanism for detecting spurious retransmits 150 outlined in this document, several other proposals for finding 151 needless retransmits have been developed. 153 [BA02a] uses the algorithm outlined in this document as the basis 154 for investigating several methods to make TCP more robust to 155 reordered packets. 157 The Eifel detection algorithm [LM02] uses the TCP timestamp option 158 [RFC1323] to determine whether the ACK for a given retransmit is for 159 the original transmission or a retransmission. More generally, 160 [LK00] outlines the benefits of detecting spurious retransmits and 161 reverting from needless congestion control changes using the 162 timestamp-based scheme or a mechanism that uses a "retransmit bit" 163 to flag retransmits (and ACKs of retransmits). The Eifel detection 164 algorithm can detect spurious retransmits more rapidly than a 165 DSACK-based scheme. However, the tradeoff is that the overhead of 166 the 12-byte timestamp option must be incurred in every packet 167 transmitted. 169 The F-RTO scheme [SK02] slightly alters TCP's sending pattern 170 immediately following a retransmission timeout and then observes the 171 pattern of the returning ACKs. This pattern can indicate whether 172 the retransmitted segment was needed. The advantage of F-RTO is 173 that the algorithm only needs to be implemented on the sender side 174 of the TCP connection and that nothing extra needs to cross the 175 network (e.g., DSACKs, timestamps, special flags, etc.). The 176 downside is that the algorithm is a heuristic that can be confused 177 by network pathologies (e.g., duplication or reordering of key 178 packets). 180 Finally, [AP99] briefly investigates using the time between 181 retransmitting a segment via the retransmission timeout and the 182 arrival of the next ACK as an indicator of whether the retransmit 183 was needed. The scheme compares this time delta with a fraction (f) 184 of the minimum RTT observed thus far on the connection. If the time 185 delta if less than f*minRTT then the retransmit is labeled 186 spurious. When f=1/2 the algorithm identifies roughly 59% of the 187 needless retransmission timeouts and identifies needed retransmits 188 only 2.5% of the time. 190 4 Security Considerations 192 It is possible for the receiver to falsely indicate spurious 193 retransmissions in the case of actual loss, potentially causing a 194 TCP or SCTP sender to inaccurately conclude that no loss took place 195 (and cause inappropriate changes to the senders congestion control 196 state). Consider the following scenario: 198 A receiver watches every segment or chunk that arrives and 199 acknowledges any segment that arrives out of order by more than 200 some threshold amount as a duplicate, assuming that it is a 201 retransmission. A sender using the above algorithm will assume 202 that the retransmission was spurious. 204 As a more trivial example, a receiver could simply acknowledge 205 every segment or chunk received as a duplicate as they arrive. 206 This approach is more easily defeated by heuristics, but would 207 nonetheless cause the algorithm in this document to come to 208 an incorrect conclusion. 210 The ECN nonce sum proposal [WES01] would help mitigate the ability 211 of the receiver to hide real losses from the sender. 213 References 215 [AP99] Allman, M. and V. Paxson, "On Estimating End-to-End Network 216 Path Properties", SIGCOMM 99. 218 [BA01] E. Blanton, M. Allman. Adjusting the Duplicate ACK 219 Threshold to Avoid Spurious Retransmits. Internet-Draft 220 draft-blanton-tcp-dupack-thresh-adjust-00.txt, July 2001. 221 Work in progress. 223 [BA02a] E. Blanton, M. Allman. On Making TCP More Robust to Packet 224 Reordering. ACM Computer Communication Review, 32(1), January 225 2002. 227 [BA02b] E. Blanton, M. Allman. A Conservative SACK-based Loss 228 Recovery Algorithm for TCP. Internet-Draft 229 draft-allman-tcp-sack-06.txt, July 2001. Work in progress. 231 [FF99] S. Floyd, K. Fall. Promoting the Use of End-to-End 232 Congestion Control on the Internet. IEEE/ACM Transactions 233 on Networking, August 1999. 235 [LK00] R. Ludwig, R. H. Katz. The Eifel Algorithm: Making TCP 236 Robust Against Spurious Retransmissions. ACM Computer 237 Communication Review, 30(1), January 2000. 239 [LM02] R. Ludwig, M. Meyer. The Eifel Detection Algorithm for TCP. 240 Internet-Draft draft-ietf-tsvwg-tcp-eifel-alg-05.txt, October 241 2002. Work in progress. 243 [Pax97] V. Paxson. End-to-End Internet Packet Dynamics. In ACM 244 SIGCOMM, September 1997. 246 [RFC793] Jon Postel. Transmission Control Protocol. Std 7, RFC 247 793. September 1981. 249 [RFC1323] Van Jacobson, Robert Braden, David Borman. TCP Extensions 250 for High Performance. RFC 1323. May 1992. 252 [RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. An 253 Extension to the Selective Acknowledgement (SACK) Option for 254 TCP. RFC 2883, July 2000. 256 [RFC2960] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. 257 Schwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. 258 Paxson. Stream Control Transmission Protocol. October 2000. 260 [SK02] P. Sarolahti, M. Kojo. F-RTO: A TCP RTO Recovery Algorithm 261 for Avoiding Unnecessary Retransmissions. Internet-Draft 262 draft-sarolahti-tsvwg-tcp-frto-01.txt, October 2002. Work in 263 progress. 265 [WES00] D. Wetherall, D. Ely, N. Spring. Robust ECN Signaling with 266 Nonces. Internet-Draft draft-ietf-tsvwg-tcp-nonce-00.txt, 267 January 2001. Work in progress. 269 Authors' Addresses: 271 Ethan Blanton 272 Purdue University Computer Sciences 273 1398 Computer Science Building 274 West Lafayette, IN 47907 275 eblanton@cs.purdue.edu 277 Mark Allman 278 BBN Technologies/NASA Glenn Research Center 279 Lewis Field 280 21000 Brookpark Rd. MS 54-5 281 Cleveland, OH 44135 282 Phone: 216-433-6586 283 Fax: 216-433-8705 284 mallman@bbn.com 285 http://roland.grc.nasa.gov/~mallman