diff options
Diffstat (limited to 'doc/rfc/rfc5827.txt')
| -rw-r--r-- | doc/rfc/rfc5827.txt | 843 |
1 files changed, 843 insertions, 0 deletions
diff --git a/doc/rfc/rfc5827.txt b/doc/rfc/rfc5827.txt new file mode 100644 index 0000000..d0b5881 --- /dev/null +++ b/doc/rfc/rfc5827.txt @@ -0,0 +1,843 @@ + + + + + + +Internet Engineering Task Force (IETF) M. Allman +Request for Comments: 5827 ICSI +Category: Experimental K. Avrachenkov +ISSN: 2070-1721 INRIA + U. Ayesta + BCAM-IKERBASQUE and LAAS-CNRS + J. Blanton + Ohio University + P. Hurtig + Karlstad University + April 2010 + + + Early Retransmit for TCP + and Stream Control Transmission Protocol (SCTP) + +Abstract + + This document proposes a new mechanism for TCP and Stream Control + Transmission Protocol (SCTP) that can be used to recover lost + segments when a connection's congestion window is small. The "Early + Retransmit" mechanism allows the transport to reduce, in certain + special circumstances, the number of duplicate acknowledgments + required to trigger a fast retransmission. This allows the transport + to use fast retransmit to recover segment losses that would otherwise + require a lengthy retransmission timeout. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for examination, experimental implementation, and + evaluation. + + This document defines an Experimental Protocol for the Internet + community. This document is a product of the Internet Engineering + Task Force (IETF). It represents the consensus of the IETF + community. It has received public review and has been approved for + publication by the Internet Engineering Steering Group (IESG). Not + all documents approved by the IESG are a candidate for any level of + Internet Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5827. + + + + + + + +Allman, et al. Experimental [Page 1] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://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. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +1. Introduction + + Many researchers have studied the problems with TCP's loss recovery + [RFC793, RFC5681] when the congestion window is small, and they have + outlined possible mechanisms to mitigate these problems + [Mor97, BPS+98, Bal98, LK98, RFC3150, AA02]. SCTP's [RFC4960] loss + recovery and congestion control mechanisms are based on TCP, and + therefore the same problems impact the performance of SCTP + connections. When the transport detects a missing segment, the + connection enters a loss recovery phase. There are several variants + of the loss recovery phase depending on the TCP implementation. TCP + can use slow-start-based recovery or fast recovery [RFC5681], NewReno + [RFC3782], and loss recovery, based on selective acknowledgments + (SACKs) [RFC2018, FF96, RFC3517]. SCTP's loss recovery is not as + varied due to the built-in selective acknowledgments. + + All of the above variants have two methods for invoking loss + recovery. First, if an acknowledgment (ACK) for a given segment is + not received in a certain amount of time, a retransmission timer + fires, and the segment is resent [RFC2988, RFC4960]. Second, the + "fast retransmit" algorithm resends a segment when three duplicate + + + +Allman, et al. Experimental [Page 2] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + ACKs arrive at the sender [Jac88, RFC5681]. Duplicate ACKs are + triggered by out-of-order arrivals at the receiver. However, because + duplicate ACKs from the receiver are triggered by both segment loss + and segment reordering in the network path, the sender waits for + three duplicate ACKs in an attempt to disambiguate segment loss from + segment reordering. When the congestion window is small, it may not + be possible to generate the required number of duplicate ACKs to + trigger fast retransmit when a loss does happen. + + Small congestion windows can occur in a number of situations, such + as: + + (1) The connection is constrained by end-to-end congestion control + when the connection's share of the path is small, the path has a + small bandwidth-delay product, or the transport is ascertaining + the available bandwidth in the first few round-trip times of slow + start. + + (2) The connection is "application limited" and has only a limited + amount of data to send. This can happen any time the application + does not produce enough data to fill the congestion window. A + particular case when all connections become application limited + is as the connection ends. + + (3) The connection is limited by the receiver's advertised window. + + The transport's retransmission timeout (RTO) is based on measured + round-trip times (RTT) between the sender and receiver, as specified + in [RFC2988] (for TCP) and [RFC4960] (for SCTP). To prevent spurious + retransmissions of segments that are only delayed and not lost, the + minimum RTO is conservatively chosen to be 1 second. Therefore, it + behooves TCP senders to detect and recover from as many losses as + possible without incurring a lengthy timeout during which the + connection remains idle. However, if not enough duplicate ACKs + arrive from the receiver, the fast retransmit algorithm is never + triggered -- this situation occurs when the congestion window is + small, if a large number of segments in a window are lost, or at the + end of a transfer as data drains from the network. For instance, + consider a congestion window of three segments' worth of data. If + one segment is dropped by the network, then at most two duplicate + ACKs will arrive at the sender. Since three duplicate ACKs are + required to trigger fast retransmit, a timeout will be required to + resend the dropped segment. Note that delayed ACKs [RFC5681] may + further reduce the number of duplicate ACKs a receiver sends. + However, we assume that receivers send immediate ACKs when there is a + gap in the received sequence space per [RFC5681]. + + + + + +Allman, et al. Experimental [Page 3] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + [BPS+98] shows that roughly 56% of retransmissions sent by a busy Web + server are sent after the RTO timer expires, while only 44% are + handled by fast retransmit. In addition, only 4% of the RTO timer- + based retransmissions could have been avoided with SACK, which has to + continue to disambiguate reordering from genuine loss. Furthermore, + [All00] shows that for one particular Web server, the median number + of bytes carried by a connection is less than four segments, + indicating that more than half of the connections will be forced to + rely on the RTO timer to recover from any losses that occur. Thus, + loss recovery that does not rely on the conservative RTO is likely to + be beneficial for short TCP transfers. + + The limited transmit mechanism introduced in [RFC3042] and currently + codified in [RFC5681] allows a TCP sender to transmit previously + unsent data upon receipt of each of the two duplicate ACKs that + precede a fast retransmit. SCTP [RFC4960] uses SACK information to + calculate the number of outstanding segments in the network. Hence, + when the first two duplicate ACKs arrive at the sender, they will + indicate that data has left the network, and they will allow the + sender to transmit new data (if available), similar to TCP's limited + transmit algorithm. In the remainder of this document, we use + "limited transmit" to include both TCP and SCTP mechanisms for + sending in response to the first two duplicate ACKs. By sending + these two new segments, the sender is attempting to induce additional + duplicate ACKs (if appropriate), so that fast retransmit will be + triggered before the retransmission timeout expires. The sender-side + "Early Retransmit" mechanism outlined in this document covers the + case when previously unsent data is not available for transmission + (case (2) above) or cannot be transmitted due to an advertised window + limitation (case (3) above). + + Note: This document is being published as an experimental RFC, as + part of the process for the TCPM working group and the IETF to assess + whether the proposed change is useful and safe in the heterogeneous + environments, including which variants of the mechanism are the most + effective. In the future, this specification may be updated and put + on the standards track if its safeness and efficacy can be + demonstrated. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + The reader is expected to be familiar with the definitions given in + [RFC5681]. + + + + +Allman, et al. Experimental [Page 4] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + +3. Early Retransmit Algorithm + + The Early Retransmit algorithm calls for lowering the threshold for + triggering fast retransmit when the amount of outstanding data is + small and when no previously unsent data can be transmitted (such + that limited transmit could be used). Duplicate ACKs are triggered + by each arriving out-of-order segment. Therefore, fast retransmit + will not be invoked when there are less than four outstanding + segments (assuming only one segment loss in the window). However, + TCP and SCTP are not required to track the number of outstanding + segments, but rather the number of outstanding bytes or messages. + (Note that SCTP's message boundaries do not necessarily correspond to + segment boundaries.) Therefore, applying the intuitive notion of a + transport with less than four segments outstanding is more + complicated than it first appears. In Section 3.1, we describe a + "byte-based" variant of Early Retransmit that attempts to roughly map + the number of outstanding bytes to a number of outstanding segments + that is then used when deciding whether to trigger Early Retransmit. + In Section 3.2, we describe a "segment-based" variant that represents + a more precise algorithm for triggering Early Retransmit. This + precision comes at the cost of requiring additional state to be kept + by the TCP sender. In both cases, we describe SACK-based and non- + SACK-based versions of the scheme (of course, the non-SACK version + will not apply to SCTP). This document explicitly does not prefer + one variant over the other, but leaves the choice to the implementer. + +3.1. Byte-Based Early Retransmit + + A TCP or SCTP sender MAY use byte-based Early Retransmit. + + Upon the arrival of an ACK, a sender employing byte-based Early + Retransmit MUST use the following two conditions to determine when an + Early Retransmit is sent: + + (2.a) The amount of outstanding data (ownd) -- data sent but not yet + acknowledged -- is less than 4*SMSS bytes (as defined in + [RFC5681]). + + Note that in the byte-based variant of Early Retransmit, "ownd" + is equivalent to "FlightSize" (defined in [RFC5681]). We use + different notation, because "ownd" is not consistent with + FlightSize throughout this document. + + Also note that in SCTP, messages will have to be converted to + bytes to make this variant of Early Retransmit work. + + + + + + +Allman, et al. Experimental [Page 5] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + (2.b) There is either no unsent data ready for transmission at the + sender, or the advertised receive window does not permit new + segments to be transmitted. + + When the above two conditions hold and a TCP connection does not + support SACK, the duplicate ACK threshold used to trigger a + retransmission MUST be reduced to: + + ER_thresh = ceiling (ownd/SMSS) - 1 (1) + + duplicate ACKs, where ownd is expressed in terms of bytes. We call + this reduced ACK threshold enabling "Early Retransmission". + + When conditions (2.a) and (2.b) hold and a TCP connection does + support SACK or SCTP is in use, Early Retransmit MUST be used only + when "ownd - SMSS" bytes have been SACKed. + + If either (or both) condition (2.a) and/or (2.b) does not hold, the + transport MUST NOT use Early Retransmit, but rather prefer the + standard mechanisms, including fast retransmit and limited transmit. + + As noted above, the drawback of this byte-based variant is precision + [HB08]. We illustrate this with two examples: + + + Consider a non-SACK TCP sender that uses an SMSS of 1460 bytes + and transmits three segments, each with 400 bytes of payload. + This is a case where Early Retransmit could aid loss recovery if + one segment is lost. However, in this case, ER_thresh will + become zero, per Equation (1), because the number of outstanding + bytes is a poor estimate of the number of outstanding segments. + A similar problem occurs for senders that employ SACK, as the + expression "ownd - SMSS" will become negative. + + + Next, consider a non-SACK TCP sender that uses an SMSS of + 1460 bytes and transmits 10 segments, each with 400 bytes of + payload. In this case, ER_thresh will be 2 per Equation (1). + Thus, even though there are enough segments outstanding to + trigger fast retransmit with the standard duplicate ACK + threshold, Early Retransmit will be triggered. This could cause + or exacerbate performance problems caused by segment reordering + in the network. + + + + + + + + + + +Allman, et al. Experimental [Page 6] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + +3.2. Segment-Based Early Retransmit + + A TCP or SCTP sender MAY use segment-based Early Retransmit. + + Upon the arrival of an ACK, a sender employing segment-based Early + Retransmit MUST use the following two conditions to determine when an + Early Retransmit is sent: + + (3.a) The number of outstanding segments (oseg) -- segments sent but + not yet acknowledged -- is less than four. + + (3.b) There is either no unsent data ready for transmission at the + sender, or the advertised receive window does not permit new + segments to be transmitted. + + When the above two conditions hold and a TCP connection does not + support SACK, the duplicate ACK threshold used to trigger a + retransmission MUST be reduced to: + + ER_thresh = oseg - 1 (2) + + duplicate ACKs, where oseg represents the number of outstanding + segments. (We discuss tracking the number of outstanding segments + below.) We call this reduced ACK threshold enabling "Early + Retransmission". + + When conditions (3.a) and (3.b) hold and a TCP connection does + support SACK or SCTP is in use, Early Retransmit MUST be used only + when "oseg - 1" segments have been SACKed. A segment is considered + to be SACKed when all of its data bytes (TCP) or data chunks (SCTP) + have been indicated as arrived by the receiver. + + If either (or both) condition (3.a) and/or (3.b) does not hold, the + transport MUST NOT use Early Retransmit, but rather prefer the + standard mechanisms, including fast retransmit and limited transmit. + + This version of Early Retransmit solves the precision issues + discussed in the previous section. As noted previously, the cost is + that the implementation will have to track segment boundaries to form + an understanding as to how many actual segments have been + transmitted, but not acknowledged. This can be done by the sender + tracking the boundaries of the three segments on the right side of + the current window (which involves tracking four sequence numbers in + TCP). This could be done by keeping a circular list of the segment + boundaries, for instance. Cumulative ACKs that do not fall within + this region indicate that at least four segments are outstanding, and + therefore Early Retransmit MUST NOT be used. When the outstanding + window becomes small enough that Early Retransmit can be invoked, a + + + +Allman, et al. Experimental [Page 7] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + full understanding of the number of outstanding segments will be + available from the four sequence numbers retained. (Note: the + implicit sequence number consumed by the TCP FIN bit can also be + included in the tracking of segment boundaries.) + +4. Discussion + + In this section, we discuss a number of issues surrounding the Early + Retransmit algorithm. + +4.1. SACK vs. Non-SACK + + The SACK variant of the Early Retransmit algorithm is preferred to + the non-SACK variant in TCP due to its robustness in the face of ACK + loss (since SACKs are sent redundantly), and due to interactions with + the delayed ACK timer (SCTP does not have a non-SACK mode and + therefore naturally supports SACK-based Early Retransmit). Consider + a flight of three segments, S1...S3, with S2 being dropped by the + network. When S1 arrives, it is in order, and so the receiver may or + may not delay the ACK, leading to two scenarios: + + (A) The ACK for S1 is delayed: In this case, the arrival of S3 will + trigger an ACK to be transmitted, covering S1 (which was + previously unacknowledged). In this case, Early Retransmit + without SACK will not prevent an RTO because no duplicate ACKs + will arrive. However, with SACK, the ACK for S1 will also + include SACK information indicating that S3 has arrived at the + receiver. The sender can then invoke Early Retransmit on this + ACK because only one segment remains outstanding. + + (B) The ACK for S1 is not delayed: In this case, the arrival of S1 + triggers an ACK of previously unacknowledged data. The arrival + of S3 triggers a duplicate ACK (because it is out of order). + Both ACKs will cover the same segment (S1). Therefore, + regardless of whether SACK is used, Early Retransmit can be + performed by the sender (assuming no ACK loss). + +4.2. Segment Reordering + + Early Retransmit is less robust in the face of reordered segments + than when using the standard fast retransmit threshold. Research + shows that a general reduction in the number of duplicate ACKs + required to trigger fast retransmit to two (rather than three) leads + to a reduction in the ratio of good to bad retransmits by a factor of + three [Pax97]. However, this analysis did not include the additional + conditioning on the event that the ownd was smaller than four + segments and that no new data was available for transmission. + + + + +Allman, et al. Experimental [Page 8] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + A number of studies have shown that network reordering is not a rare + event across some network paths. Various measurement studies have + shown that reordering along most paths is negligible, but along + certain paths can be quite prevalent [Pax97, BPS99, BS02, Pir05]. + Evaluating Early Retransmit in the face of real segment reordering is + part of the experiment we hope to instigate with this document. + +4.3. Worst Case + + Next, we note two "worst case" scenarios for Early Retransmit: + + (1) Persistent reordering of segments coupled with an application + that does not constantly send data can result in large numbers of + needless retransmissions when using Early Retransmit. For + instance, consider an application that sends data two segments at + a time, followed by an idle period when no data is queued for + delivery. If the network consistently reorders the two segments, + the sender will needlessly retransmit one out of every two unique + segments transmitted when using the above algorithm (meaning that + one-third of all segments sent are needless retransmissions). + However, this would only be a problem for long-lived connections + from applications that transmit in spurts. + + (2) Similar to the above, consider the case of that consist of two + segment each and always experience reordering. Just as in (1) + above, one out of every two unique data segments will be + retransmitted needlessly; therefore, one-third of the traffic + will be spurious. + + Currently, this document offers no suggestion on how to mitigate the + above problems. However, the worst cases are likely pathological. + Part of the experiments that this document hopes to trigger would + involve better understanding of whether such theoretical worst-case + scenarios are prevalent in the network, and in general, to explore + the trade-off between spurious fast retransmits and the delay imposed + by the RTO. Appendix A does offer a survey of possible mitigations + that call for curtailing the use of Early Retransmit when it is + making poor retransmission decisions. + +5. Related Work + + There are a number of similar proposals in the literature that + attempt to mitigate the same problem that Early Retransmit addresses. + + Deployment of Explicit Congestion Notification (ECN) [Flo94, RFC3168] + may benefit connections with small congestion window sizes [RFC2884]. + ECN provides a method for indicating congestion to the end-host + without dropping segments. While some segment drops may still occur, + + + +Allman, et al. Experimental [Page 9] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + ECN may allow a transport to perform better with small congestion + window sizes because the sender will be required to detect less + segment loss [RFC2884]. + + [Bal98] outlines another solution to the problem of having no new + segments to transmit into the network when the first two duplicate + ACKs arrive. In response to these duplicate ACKs, a TCP sender + transmits zero-byte segments to induce additional duplicate ACKs. + This method preserves the robustness of the standard fast retransmit + algorithm at the cost of injecting segments into the network that do + not deliver any data, and therefore are potentially wasting network + resources (at a time when there is a reasonable chance that the + resources are scarce). + + [RFC4653] also defines an orthogonal method for altering the + duplicate ACK threshold. The mechanisms proposed in this document + decrease the duplicate ACK threshold when a small amount of data is + outstanding. Meanwhile, the mechanisms in [RFC4653] increase the + duplicate ACK threshold (over the standard of 3) when the congestion + window is large in an effort to increase robustness to segment + reordering. + +6. Security Considerations + + The security considerations found in [RFC5681] apply to this + document. No additional security problems have been identified with + Early Retransmit at this time. + +7. Acknowledgments + + We thank Sally Floyd for her feedback in discussions about Early + Retransmit. The notion of Early Retransmit was originally sketched + in an Internet-Draft co-authored by Sally Floyd and Hari + Balakrishnan. Armando Caro, Joe Touch, Alexander Zimmermann, and + many members of the TSVWG and TCPM working groups provided good + discussions that helped shape this document. Our thanks to all! + +8. References + +8.1. Normative References + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP + Selective Acknowledgment Options", RFC 2018, + October 1996. + + + + +Allman, et al. Experimental [Page 10] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An + Extension to the Selective Acknowledgement (SACK) Option + for TCP", RFC 2883, July 2000. + + [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + + [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing + TCP's Loss Recovery Using Limited Transmit", RFC 3042, + January 2001. + + [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion + Control", RFC 5681, September 2009. + +8.2. Informative References + + [AA02] Urtzi Ayesta, Konstantin Avrachenkov, "The Effect of the + Initial Window Size and Limited Transmit Algorithm on the + Transient Behavior of TCP Transfers", In Proc. of the + 15th ITC Internet Specialist Seminar, Wurzburg, + July 2002. + + [All00] Mark Allman. A Web Server's View of the Transport Layer. + ACM Computer Communication Review, October 2000. + + [Bal98] Hari Balakrishnan. Challenges to Reliable Data Transport + over Heterogeneous Wireless Networks. Ph.D. Thesis, + University of California at Berkeley, August 1998. + + [BPS+98] Hari Balakrishnan, Venkata Padmanabhan, + Srinivasan Seshan, Mark Stemm, and Randy Katz. TCP + Behavior of a Busy Web Server: Analysis and Improvements. + Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998. + + [BPS99] Jon Bennett, Craig Partridge, Nicholas Shectman. Packet + Reordering is Not Pathological Network Behavior. + IEEE/ACM Transactions on Networking, December 1999. + + [BS02] John Bellardo, Stefan Savage. Measuring Packet + Reordering, ACM/USENIX Internet Measurement Workshop, + November 2002. + + + + +Allman, et al. Experimental [Page 11] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + [FF96] Kevin Fall, Sally Floyd. Simulation-based Comparisons of + Tahoe, Reno, and SACK TCP. ACM Computer Communication + Review, July 1996. + + [Flo94] Sally Floyd. TCP and Explicit Congestion Notification. + ACM Computer Communication Review, October 1994. + + [HB08] Per Hurtig, Anna Brunstrom. Enhancing SCTP Loss + Recovery: An Experimental Evaluation of Early Retransmit. + Elsevier Computer Communications, Vol. 31(16), + October 2008, pp. 3778-3788. + + [Jac88] Van Jacobson. Congestion Avoidance and Control. ACM + SIGCOMM 1988. + + [LK98] Dong Lin, H.T. Kung. TCP Fast Recovery Strategies: + Analysis and Improvements. Proc. IEEE INFOCOM Conf., + San Francisco, CA, March 1998. + + [Mor97] Robert Morris. TCP Behavior with Many Flows. Proc. + Fifth IEEE International Conference on Network Protocols, + October 1997. + + [Pax97] Vern Paxson. End-to-End Internet Packet Dynamics. ACM + SIGCOMM, September 1997. + + [Pir05] N. M. Piratla, "A Theoretical Foundation, Metrics and + Modeling of Packet Reordering and Methodology of Delay + Modeling using Inter-packet Gaps," Ph.D. Dissertation, + Department of Electrical and Computer Engineering, + Colorado State University, Fort Collins, CO, Fall 2005. + + [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of + Explicit Congestion Notification (ECN) in IP Networks", + RFC 2884, July 2000. + + [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, + "End-to-end Performance Implications of Slow Links", + BCP 48, RFC 3150, July 2001. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, September 2001. + + [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A + Conservative Selective Acknowledgment (SACK)-based Loss + Recovery Algorithm for TCP", RFC 3517, April 2003. + + + + +Allman, et al. Experimental [Page 12] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + + [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm + for TCP", RFC 3522, April 2003. + + [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno + Modification to TCP's Fast Recovery Algorithm", RFC 3782, + April 2004. + + [RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, + "Improving the Robustness of TCP to Non-Congestion + Events", RFC 4653, August 2006. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Allman, et al. Experimental [Page 13] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + +Appendix A. Research Issues in Adjusting the Duplicate ACK Threshold + + Decreasing the number of duplicate ACKs required to trigger fast + retransmit, as suggested in Section 3, has the drawback of making + fast retransmit less robust in the face of minor network reordering. + Two egregious examples of problems caused by reordering are given in + Section 4. This appendix outlines several schemes that have been + suggested to mitigate the problems caused by Early Retransmit in the + face of segment reordering. These methods need further research + before they are suggested for general use (and current consensus is + that the cases that make Early Retransmit unnecessarily retransmit a + large amount of data are pathological, and therefore, these + mitigations are not generally required). + + MITIGATION A.1: Allow a connection to use Early Retransmit as long as + the algorithm is not injecting "too much" spurious data into the + network. For instance, using the information provided by TCP's + D-SACK option [RFC2883] or SCTP's Duplicate Transmission Sequence + Number (Duplicate-TSN) notification, a sender can determine when + segments sent via Early Retransmit are needless. Likewise, using + Eifel [RFC3522], the sender can detect spurious Early Retransmits. + Once spurious Early Retransmits are detected, the sender can + either eliminate the use of Early Retransmit, or limit the use of + the algorithm to ensure that an acceptably small fraction of the + connection's transmissions are not spurious. For example, a + connection could stop using Early Retransmit after the first + spurious retransmit is detected. + + MITIGATION A.2: If a sender cannot reliably determine whether an + Early-Retransmitted segment is spurious or not, the sender could + simply limit Early Retransmits, either to some fixed number per + connection (e.g., Early Retransmit is allowed only once per + connection), or to some small percentage of the total traffic + being transmitted. + + MITIGATION A.3: Allow a connection to trigger Early Retransmit using + the criteria given in Section 3, in addition to a "small" timeout + [Pax97]. For instance, a sender may have to wait for two + duplicate ACKs and then T msec before Early Retransmit is invoked. + The added time gives reordered acknowledgments time to arrive at + the sender and avoid a needless retransmit. Designing a method + for choosing an appropriate timeout is part of the research that + would need to be involved in this scheme. + + + + + + + + +Allman, et al. Experimental [Page 14] + +RFC 5827 Early Retransmit for TCP and SCTP April 2010 + + +Authors' Addresses + + Mark Allman + International Computer Science Institute + 1947 Center Street, Suite 600 + Berkeley, CA 94704-1198 + USA + Phone: 440-235-1792 + EMail: mallman@icir.org + http://www.icir.org/mallman/ + + + Konstantin Avrachenkov + INRIA + 2004 route des Lucioles, B.P.93 + 06902, Sophia Antipolis + France + Phone: 00 33 492 38 7751 + EMail: k.avrachenkov@sophia.inria.fr + http://www-sop.inria.fr/members/Konstantin.Avratchenkov/me.html + + + Urtzi Ayesta + BCAM-IKERBASQUE LAAS-CNRS + Bizkaia Technology Park, Building 500 7 Avenue Colonel Roche + 48160 Derio 31077, Toulouse + Spain France + EMail: urtzi@laas.fr + http://www.laas.fr/~urtzi + + + Josh Blanton + Ohio University + 301 Stocker Center + Athens, OH 45701 + USA + EMail: jblanton@irg.cs.ohiou.edu + + + Per Hurtig + Karlstad University + Department of Computer Science + Universitetsgatan 2 651 88 + Karlstad + Sweden + EMail: per.hurtig@kau.se + + + + + +Allman, et al. Experimental [Page 15] + |