idnits 2.17.1 draft-blanton-tcp-reordering-00.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 4 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 17, but not defined == Missing Reference: 'RFC2119' is mentioned on line 48, but not defined == Missing Reference: 'RFC793' is mentioned on line 51, but not defined ** Obsolete undefined reference: RFC 793 (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. 'BA02a' -- Possible downref: Normative reference to a draft: ref. 'BA02b' -- Possible downref: Non-RFC (?) normative reference: ref. 'BPS99' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jac88' == Outdated reference: A later version (-06) exists of draft-ietf-tsvwg-tcp-eifel-response-01 -- Possible downref: Non-RFC (?) normative reference: ref. 'LK00' == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-tcp-eifel-alg-06 ** 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 1323 (Obsoleted by RFC 7323) ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) == Outdated reference: A later version (-07) exists of draft-swami-tsvwg-tcp-dclor-00 -- Possible downref: Normative reference to a draft: ref. 'SL02' == Outdated reference: A later version (-04) exists of draft-sarolahti-tsvwg-tcp-frto-02 -- Possible downref: Normative reference to a draft: ref. 'SK02' -- Possible downref: Non-RFC (?) normative reference: ref. 'ZKFP02' Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 11 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-tcp-reordering-00.txt Robert Dimond 4 Verizon/NASA GRC 5 Mark Allman 6 BBN/NASA GRC 7 February, 2003 8 Expires: July, 2003 10 Practices for TCP Senders in the Face of 11 Segment Reordering 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of [RFC2026]. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 This document outlines actions a TCP sender can take after 37 determining that a spurious fast retransmission has been sent due to 38 packet reordering. The document outlines the method a TCP 39 connection can use to "undo" needless changes made to the congestion 40 control state. In addition, several methods to help prevent future 41 fast retransmits are outlined. 43 Terminology 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 1 Introduction 51 As outlined in [RFC793] TCP receivers always indicate the next 52 in-order byte of data they expect to receive in the acknowledgments 53 (ACKs) they send. Therefore, if a segment arrives that does not 54 include the next expected byte of data, the receiver generates a 55 duplicate ACK. This situation can arise from either packet loss or 56 from packet reordering in the network. 58 Meanwhile, TCP's fast retransmit algorithm [Jac88,RFC2581] uses the 59 arrival of three duplicate ACKs as an indication that the network 60 lost the packet containing the indicated data byte. Upon detection 61 of a lost segment via fast retransmit the sender resends the given 62 data segment before the expiration of the retransmission timer 63 (RTO). The sender waits for three duplicate ACKs in an attempt to 64 distinguish between actual packet loss and small amounts of packet 65 reordering. 67 Several Internet measurement studies have shown that waiting for the 68 arrival of three duplicate ACKs may not be sufficient to distinguish 69 between packet loss and packet reordering over some network paths 70 [Pax97,BPS99]. Therefore, in some cases a TCP sender may send a 71 spurious fast retransmit. This spurious retransmit wastes network 72 resources on needless work, as well as causing the TCP sender to 73 infer that the network is experiencing congestion and thus the 74 sender should reduce its sending rate. [BA02a] shows the 75 performance impact of various levels of reordering on TCP 76 connections. 78 This document offers several experimental strategies for mitigating 79 the impact of spurious fast retransmits. The first mitigation is to 80 allow the sender to revert to its previous sending rate when 81 spurious retransmissions are detected. The second mitigation is to 82 dynamically vary the number of duplicate ACKs required to trigger 83 fast retransmit in an attempt to prevent spurious retransmissions. 85 Explicitly out of scope for this document is the subject of spurious 86 RTOs. This subject is covered by others (as outlined in section 3 87 on related work). 89 We hope the community will experiment with the mechanisms presented 90 in this document and provide their experience and input to a future 91 decision on which mechanisms (if any) may be appropriate to include 92 as part of the TCP's standard congestion control algorithms. 94 This document is organized as follows. Section 2 offers 95 definitions. Section 3 outlines related work. Section 4 details 96 how a TCP sender can revert to a previous congestion control state 97 after a spurious retransmit has been detected. Section 5 outlines 98 the methods for dynamically adjusting the number of duplicate ACKs 99 required to trigger fast retransmit. Section 6 discusses 100 interactions between adjusting the duplicate ACK threshold and the 101 RTO. Section 7 sketches future work in this area. Section 8 102 outlines security considerations. 104 2 Definitions 106 It is assumed that the reader is familiar with the congestion 107 control concepts and terminology for TCP from [RFC2581]. 109 In addition, the following terms will be used: 111 ``dupthresh'' represents the number of duplicate ACKs required 112 to trigger a fast retransmit. [RFC2581] defines dupthresh to be 113 3 duplicate ACKs. 115 3 Related Work 117 [Editor's note: Additional related work outlined in [SL02] will be 118 included in a later version of this document.] 120 A number of documents have been written on the subject of spurious 121 retransmits. In this space, there are three categories of 122 mechanisms: 124 (1) Mechanisms for detecting spurious retransmits. 126 The changes specified in this document require a mechanism to 127 detect when a TCP sender has needlessly retransmitted. We do 128 not specify any one algorithm that must be used with our 129 mitigation strategies because the exact method employed does not 130 have a direct impact on this specification. (That is not to say 131 that the choice of detection mechanism is immaterial in a larger 132 sense.) 134 [BA02b] outlines a scheme that uses the DSACK TCP option 135 [RFC2883] to detect spurious retransmits. 137 [LM02] outlines the Eifel algorithm that uses the TCP timestamp 138 option [RFC1323] to detect unneeded retransmissions. (An 139 additional variant of the Eifel algorithm uses reserved bits 140 from the TCP header rather than timestamps [LK00].) 142 [SK02] outlines the F-RTO algorithm that uses a slight 143 modification to TCP's sending pattern after a retransmission 144 timeout (RTO) and the resulting ACKs to detect spurious RTOs. 146 (2) Mechanisms for undoing needless changes to congestion control 147 state. 149 Section 4 of this document specifies the appropriate method for 150 reverting to a previous set of congestion control parameters 151 after reliably detecting a needless retransmit (and in the 152 presence of no other congestion signals). The scheme specified 153 in this document draws on the spirit outlined in [RFC2883]. 155 [LG02] outlines the response to spurious retransmits (both 156 spurious fast retransmits and spurious timeouts) after detection 157 by the Eifel detection algorithm [LM02]. The mechanism for 158 undoing needless changes to the congestion control state of the 159 connection is similar to the mechanism we outline in section 4. 161 (3) Mechanisms for making TCP more tolerant to reordering events 162 such that future spurious retransmits are avoided. 164 [LG02] outlines one particular method for adjusting dupthresh in 165 an attempt to prevent future needless fast retransmissions. (In 166 addition, [LG02] provides a method for adjusting the RTO after a 167 spurious RTO.) 169 [ZKFP02] outlines a scheme whereby the TCP sender's SACK 170 scoreboard data structure is annotated with information about 171 packet reordering in an attempt to adjust the dupthresh to 172 prevent packet reordering from causing needless retransmits. 174 Finally, section 5 of this document outlines several schemes to 175 avoid needlessly evoking the fast retransmit algorithm. The 176 mechanisms in section 5 are based on [BA02a]. Each of the above 177 proposals has its pros and cons. An in-depth analysis of each 178 proposal is beyond the scope of this document. 180 4 Reverting Congestion Control State 182 [RFC2883,LK00,BA02a] all mention the possibility of reverting 183 congestion control state when a sender determines that the 184 congestion window was reduced unnecessarily due to a spurious 185 retransmission. This document specifies that a sender that reliably 186 detects a spurious retransmission MAY ``undo'' the needless 187 congestion control state changes. If the sender wishes to undo 188 needless changes it MUST use the following algorithm: 190 (1) When retransmitting a segment and before reducing cwnd or 191 ssthresh, save the value of cwnd as cwnd_prev and the value of 192 ssthresh as ssthresh_prev. 194 (2) Upon the detection of a spurious retransmit, set ssthresh to 195 cwnd_prev. 197 This causes a 1 RTT slow start back to the cwnd in use before 198 the sender needlessly changed the congestion control state. 199 This rule causes a smooth increase of cwnd, whereas simply 200 setting cwnd to cwnd_prev upon detection of a spurious 201 retransmit would cause the transmission of a potentially large 202 burst. 204 (3) Optional. When cwnd reaches ssthresh set ssthresh to 205 ssthresh_prev. 207 This rule allows a TCP that is using slow start when a spurious 208 retransmission is detected to resume that slow start after 209 detection. Without this rule the cwnd would be reverted to its 210 previous value, however further cwnd growth would be limited to 211 the linear growth of congestion avoidance. 213 If a sender uses the above algorithm, one of the algorithms 214 specified in the next section MUST be used in an attempt to prevent 215 further needless retransmissions. 217 5 Preventing Spurious Fast Retransmits 219 Undoing congestion control changes caused by reordering events 220 increases the overall performance of a TCP connection [BA02a]. 221 However, [BA02a] shows that when the steps in section 4 are taken 222 alone the number of unnecessary retransmits (and, therefore, wasted 223 network resources) still remains significantly high. Therefore, 224 further performance gains and network resource savings can be 225 realized if we can prevent subsequent spurious fast retransmits. 226 Simulations in [BA02a] show that a strategy of reversing erroneous 227 congestion control decisions, coupled with a fast retransmit 228 mitigation scheme, achieves good performance (within 1-2% of a 229 transfer that experiences no reordering) while reducing the number 230 of unnecessary retransmits by roughly a factor of 6. 232 This document purposes several options that deal with postponing the 233 fast retransmit algorithm to allow the reordered segments to be 234 acknowledged by the receiver. This is achieved by increasing the 235 duplicate acknowledgment threshold, or directly delaying fast 236 retransmit by an increment of time when a spurious retransmission 237 has occurred previously. 239 Regardless of which approach is taken to avoid spurious retransmits, 240 caution should be taken in their implementation. For example, more 241 aggressive manipulations of dupthresh can result in faster 242 convergence in the face of a connection facing persistent 243 reordering, but may increase the chance of relying on the RTO to 244 recover from real loss. The RTO is often lengthy and cuts cwnd to 245 one segment and invokes slow start. 247 5.1 Increase dupthresh By K 249 A TCP sender that implements this strategy MUST increase dupthresh 250 by some small constant, K, each time a spurious fast retransmit is 251 detected. In [BA02a] K is set to increment dupthresh by one after a 252 spurious retransmission is detected. 254 This method requires minimal state to implement, but a conservative 255 increment of K may be slow to converge in connections where 256 persistent large reordering events are present. In connections 257 where the reordering event lengths are varied convergence becomes 258 problematical at best. 260 5.2 Increase dupthresh Based On Reordering Length 262 A TCP sender that implements this strategy MUST increase dupthresh 263 based on the length of the most recent reordering event that causes 264 a spurious fast retransmit. With this method a TCP sender 265 determines the number of duplicate ACKs, C, that would have 266 disambiguated the reordering event from the perceived loss. C is 267 then averaged with the current value of dupthresh, per 269 dupthresh = (C + dupthresh) / 2 (1) 271 If the new value for dupthresh is less than or equal to its 272 predecessor, dupthresh SHOULD be incremented by one. 274 This method allows for a varied growth of dupthresh, accommodating 275 the varied reordering event lengths mentioned in the previous 276 option. Unfortunately, reordering events significantly longer than 277 the connection's average reordering events may result in skewing 278 dupthresh to an overly optimistic value, preventing fast retransmit 279 before the RTO timer expires. 281 5.3 Delay of Fast Retransmit 283 As proposed in [Pax97], the fast retransmit can be delayed by some 284 small amount of time after dupthresh duplicate ACKs have been 285 received in an effort to distinguish between loss and reordering. A 286 sender that implements this strategy MUST track of the duration in 287 time, T, of the reordering event from the reception of the first 288 duplicate ACK to the first cumulative or partial ACK. This 289 represents the time necessary to disambiguate the longest reordering 290 event in the current connection from its perceived loss. The sender 291 MUST then, on subsequent perceived loss events, wait T seconds after 292 the third duplicate acknowledgment for subsequent reordering/loss 293 events before invoking the fast retransmit algorithm. Should a 294 cumulative ACK be received before this timer expires, the sender 295 MUST NOT invoke fast retransmit. 297 Similar in approach to the scheme sketched in section 5.2, this 298 method considers the length of the reordering event. In using the 299 passage of time, as opposed to counting duplicate ACKs, the strategy 300 is more robust where ACK loss is present. Unfortunately this 301 potential advantage comes at a cost of requiring more overhead than 302 in the previously outlined methods in the form of an additional 303 timer for each TCP connection. 305 5.4 Average Duplicate ACK Tracking 307 In an attempt to use a connection's history while still being 308 adaptive to reordering events which are uncharacteristically 309 divergent, an Exponentially Weighted Moving Average (EWMA) is tried 310 in [BA02a]. The EWMA gives the values needed to mitigate recent 311 spurious fast retransmits a higher weight over the values used in 312 previous fast retransmit mitigation attempts in the connections 313 history. Unfortunately, initial results for this mechanism yielded 314 little or no advantages over TCP variants which did not use any 315 mechanisms to mitigate spurious fast retransmits. Therefore, we do 316 not recommend using an EWMA scheme in this document, but rather 317 offer it as a future research area. 319 6 Preventing Spurious Timeouts 321 In section 5, we outline several methods to increase dupthresh, or 322 insert delay before fast retransmit, in hopes of maintaining cwnd to 323 mitigate TCP performance issues in the face of reordering. 324 Regardless of the method used, since reordering events may vary in 325 length and ACK loss will effect the number of duplicate ACKs 326 returned to the sender there exists a possibility that dupthesh will 327 be set to an overly optimistic value. In this case the RTO will 328 expire before enough duplicate ACKs are received for fast 329 retransmit. In addition to the often lengthy timeout imposed by the 330 RTO [RFC2988] the TCP sender will reduce cwnd to one segment and 331 restart transmission with slow start. This document sketches 332 several additional methods for coping with RTOs caused by an overly 333 optimistic dupthresh in the next subsections. In addition, the 334 outline of future work below (section 7) offers some thoughts in 335 this area. 337 6.1 Reducing dupthresh 339 In addition to the performance issues involved with the expiration 340 of the RTO, the sender should consider an RTO as an indication that 341 the current dupthresh is no longer a valid estimate of the 342 reordering conditions in the network. The TCP sender MUST reset 343 dupthresh to the default value of from [RFC2581] (currently 3). 344 This conservative approach guards against subsequent RTOs stemming 345 from an optimistic dupthresh value, but may allow spurious 346 retransmissions to resume until the sender's dupthresh estimate 347 re-converges. 349 6.2 Bounding dupthresh 351 This document specifies that the dupthresh MUST never be larger than 352 cwnd-1 segments. Furthermore, to be more conservative we RECOMMEND 353 that dupthresh never be more than 90% of cwnd. This means that 354 whenever cwnd is reduced in the course of a TCP transfer the stack 355 must also ensure that dupthresh is likewise reduced, if necessary. 357 6.3 Extending Limited Transmit 359 A final strategy that MAY be used by a TCP sender in an attempt to 360 prevent RTOs is to extend the limited transmit algorithm [RFC3042]. 361 Limited transmit calls for a TCP sender to transmit one previously 362 unsent data segment upon reception of each of the first two 363 duplicate ACKs. This document allows that a a TCP sender MAY 364 transmit a previously unsent data segment on every second duplicate 365 ACK received after the first two and before dupthresh is met. So, 366 when used in conjunction with [RFC3042], a TCP sender with a 367 dupthresh of 7 could transmit new data segments on duplicate ACKs 1, 368 2, 4, and 6. 370 This mechanism allows the TCP sender to sustain the ACK clock and 371 possibly generate new duplicate ACKs that will help trigger fast 372 retransmit and prevent an RTO. The mechanism is conservative 373 because in the case when loss is the cause of the duplicate ACKs 374 (rather than reordering) the rate the TCP sender is transmitting new 375 segments into the network is gradually being reduced by sending only 376 on every second duplicate ACK. 378 This mechanism is similar to the rate-halving proposals []. 380 7 Future Work 382 All the schemes for varying dupthresh in this document involve 383 increasing the number of duplicate ACKs required to trigger fast 384 retransmit. While we provide one scheme to reduce dupthresh 385 (collapsing back to the default value after an RTO) [ZKFP02] shows 386 that schemes that offer both dupthresh increase and decrease offer 387 more performance benefit. One area for future work is to extend the 388 strategies outlined in section 5 to allow for decreasing dupthresh. 390 8 Security Considerations 392 Reversion of congestion control state has no obvious security 393 considerations given an accurate signal that indicates a needless 394 retransmit. Any security considerations pertaining to the method of 395 determining that a fast retransmit was spurious are directly 396 applicable to this document. 398 The adjustment of dupthresh may be vulnerable to any third party who 399 wishes to illegitimately gain network resources and/or cause a 400 denial of service between the sender and receiver. The 401 vulnerability exists when a third party sends fictitious duplicate 402 acknowledgments to the sender with a sequence number within the 403 sender's current cwnd. As a result, the sender may needlessly 404 retransmit and also grow dupthresh to an overly optimistic value, 405 resulting in future RTOs. Such RTOs cause the sender to drop cwnd 406 to 1 segment, relinquishing network resources at the cost of the 407 connection's performance. 409 Acknowledgments 411 The authors would like to thank Sally Floyd, Reiner Ludwig, Vern 412 Paxson and Randall Stewart for spurring this work through their 413 previous work for providing input during the formative stages of 414 this draft. 416 References 418 [BA02a] E. Blanton, M. Allman. On Making TCP More Robust to Packet 419 Reordering. ACM Computer Communication Review, 32(1), January 420 2002. 422 [BA02b] E. Blanton, M. Allman. Using TCP DSACKs and SCTP Duplicate 423 TSNs to Detect Spurious Retransmissions. Internet-Draft 424 draft-blanton-dsack-use-02.txt, October 2002. Work in progress. 426 [BPS99] J. Bennett, C. Partridge, N. Shectman. Packet Reordering 427 is Not Pathological Network Behavior. IEEE/ACM Transactions 428 on Networking, December 1999. 430 [Jac88] Van Jacobson. Congestion Avoidance and Control. ACM 431 SIGCOMM 1988. 433 [LG02] R. Ludwig, A. Gurtov. The Eifel Response Algorithm for TCP. 434 Internet-Draft draft-ietf-tsvwg-tcp-eifel-response-01.txt, 435 October 2002. Work in progress. 437 [LK00] R. Ludwig, R. Katz. The Eifel Algorithm: Making TCP Robust 438 Against Spurious Retransmissions. Computer Communication Review 439 Volume 30 Number 1, January 2000. 441 [LM02] R. Ludwig, M. Meyer. The Eifel Detection Algorithm for TCP. 442 Internet-Draft draft-ietf-tsvwg-tcp-eifel-alg-06.txt, October 443 2002. Work in progress. 445 [Pax97] V. Paxson. End-to-End Internet Packet Dynamics. 446 Presented at ACM SIGCOMM, September 1997. 448 [RFC1323] Van Jacobson, Robert Braden, David Borman. TCP Extensions 449 for High Performance. RFC 1323. May 1992. 451 [RFC2581] M. Allman, V. Paxson, W. Stevens, TCP Congestion Control, 452 RFC 2581, April 1999. 454 [RFC2883] S. Floyd, J. Mahdavi, M. Mathis, M. Podolsky. An 455 Extension to the Selective Acknowledgement (SACK) Option for 456 TCP. RFC 2883, July 2000. 458 [RFC2988] Vern Paxson, Mark Allman. Computing TCP's Retransmission 459 Timer, RFC 2988, November 2000. 461 [RFC3042] Mark Allman, Hari Balkrishnan, Sally Floyd. Enhancing 462 TCP's Loss Recovery Using Limited Transmit. RFC 3042, 463 January 2001 465 [SL02] Yogesh Swami, Khiem Le. DCLOR: De-correlated Loss Recovery 466 using SACK Option for Spurious Timeouts. Internet-Draft 467 draft-swami-tsvwg-tcp-dclor-00.txt, November 2002. Work in 468 progress. 470 [SK02] P. Sarolahti, M. Kojo. F-RTO: A TCP RTO Recovery Algorithm 471 for Avoiding Unnecessary Retransmissions. Internet-Draft 472 draft-sarolahti-tsvwg-tcp-frto-02.txt, November 2002. Work in 473 progress. 475 [ZKFP02] M. Zhang, B. Karp, S. Floyd, L. Peterson. RR-TCP: A 476 Reordering-Robust TCP with DSACK. ICSI Technical Report 477 TR-02-006, July 2002. 479 Authors' Addresses: 481 Ethan Blanton 482 Purdue University Computer Sciences 483 1398 Computer Science Building 484 West Lafayette, IN 47907 485 eblanton@cs.purdue.edu 486 Robert Dimond 487 Verizon FNS/NASA Glenn Research Center 488 Lewis Field 489 21000 Brookpark Rd. MS 142-1 490 Cleveland, OH 44135 491 Phone: 216-433-8468 492 bdimond@grc.nasa.gov 494 Mark Allman 495 BBN Technologies/NASA Glenn Research Center 496 Lewis Field 497 21000 Brookpark Rd. MS 54-5 498 Cleveland, OH 44135 499 Phone: 216-433-6586 500 Fax: 216-433-8705 501 mallman@bbn.com 502 http://roland.grc.nasa.gov/~mallman