diff options
Diffstat (limited to 'doc/rfc/rfc4015.txt')
| -rw-r--r-- | doc/rfc/rfc4015.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc4015.txt b/doc/rfc/rfc4015.txt new file mode 100644 index 0000000..fd527a2 --- /dev/null +++ b/doc/rfc/rfc4015.txt @@ -0,0 +1,731 @@ + + + + + + +Network Working Group R. Ludwig +Request for Comments: 4015 Ericsson Research +Category: Standards Track A. Gurtov + HIIT + February 2005 + + + The Eifel Response Algorithm for TCP + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + Based on an appropriate detection algorithm, the Eifel response + algorithm provides a way for a TCP sender to respond to a detected + spurious timeout. It adapts the retransmission timer to avoid + further spurious timeouts and (depending on the detection algorithm) + can avoid the often unnecessary go-back-N retransmits that would + otherwise be sent. In addition, the Eifel response algorithm + restores the congestion control state in such a way that packet + bursts are avoided. + +1. Introduction + + The Eifel response algorithm relies on a detection algorithm such as + the Eifel detection algorithm, defined in [RFC3522]. That document + contains informative background and motivation context that may be + useful for implementers of the Eifel response algorithm, but it is + not necessary to read [RFC3522] in order to implement the Eifel + response algorithm. Note that alternative response algorithms have + been proposed [BA02] that could also rely on the Eifel detection + algorithm, and alternative detection algorithms have been proposed + [RFC3708], [SK04] that could work together with the Eifel response + algorithm. + + Based on an appropriate detection algorithm, the Eifel response + algorithm provides a way for a TCP sender to respond to a detected + spurious timeout. It adapts the retransmission timer to avoid + + + +Ludwig & Gurtov Standards Track [Page 1] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + further spurious timeouts and (depending on the detection algorithm) + can avoid the often unnecessary go-back-N retransmits that would + otherwise be sent. In addition, the Eifel response algorithm + restores the congestion control state in such a way that packet + bursts are avoided. + + Note: A previous version of the Eifel response algorithm also + included a response to a detected spurious fast retransmit. + However, as a consensus was not reached about how to adapt the + duplicate acknowledgement threshold in that case, that part of the + algorithm was removed for the time being. + +1.1. Terminology + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in [RFC2119]. + + We refer to the first-time transmission of an octet as the 'original + transmit'. A subsequent transmission of the same octet is referred + to as a 'retransmit'. In most cases, this terminology can also be + applied to data segments. However, when repacketization occurs, a + segment can contain both first-time transmissions and retransmissions + of octets. In that case, this terminology is only consistent when + applied to octets. For the Eifel detection and response algorithms, + this makes no difference, as they also operate correctly when + repacketization occurs. + + We use the term 'acceptable ACK' as defined in [RFC793]. That is an + ACK that acknowledges previously unacknowledged data. We use the + term 'bytes_acked' to refer to the amount (in terms of octets) of + previously unacknowledged data that is acknowledged by the most + recently received acceptable ACK. We use the TCP sender state + variables 'SND.UNA' and 'SND.NXT' as defined in [RFC793]. SND.UNA + holds the segment sequence number of the oldest outstanding segment. + SND.NXT holds the segment sequence number of the next segment the TCP + sender will (re-)transmit. In addition, we define as 'SND.MAX' the + segment sequence number of the next original transmit to be sent. + The definition of SND.MAX is equivalent to the definition of + 'snd_max' in [WS95]. + + We use the TCP sender state variables 'cwnd' (congestion window), and + 'ssthresh' (slow-start threshold), and the term 'FlightSize' as + defined in [RFC2581]. FlightSize is the amount (in terms of octets) + of outstanding data at a given point in time. We use the term + 'Initial Window' (IW) as defined in [RFC3390]. The IW is the size of + the sender's congestion window after the three-way handshake is + completed. We use the TCP sender state variables 'SRTT' and + + + +Ludwig & Gurtov Standards Track [Page 2] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + 'RTTVAR', and the terms 'RTO' and 'G' as defined in [RFC2988]. G is + the clock granularity of the retransmission timer. In addition, we + assume that the TCP sender maintains the value of the latest round- + trip time (RTT) measurement in the (local) variable 'RTT-SAMPLE'. + + We use the TCP sender state variable 'T_last', and the term 'tcpnow' + as used in [RFC2861]. T_last holds the system time when the TCP + sender sent the last data segment, whereas tcpnow is the TCP sender's + current system time. + +2. Appropriate Detection Algorithms + + If the Eifel response algorithm is implemented at the TCP sender, it + MUST be implemented together with a detection algorithm that is + specified in a standards track or experimental RFC. + + Designers of detection algorithms who want their algorithms to work + together with the Eifel response algorithm should reuse the variable + "SpuriousRecovery" with the semantics and defined values specified in + [RFC3522]. In addition, we define the constant LATE_SPUR_TO (set + equal to -1) as another possible value of the variable + SpuriousRecovery. Detection algorithms should set the value of + SpuriousRecovery to LATE_SPUR_TO if the detection of a spurious + retransmit is based on the ACK for the retransmit (as opposed to an + ACK for an original transmit). For example, this applies to + detection algorithms that are based on the DSACK option [RFC3708]. + +3. The Eifel Response Algorithm + + The complete algorithm is specified in section 3.1. In sections 3.2 + - 3.6, we discuss the different steps of the algorithm. + +3.1. The Algorithm + + Given that a TCP sender has enabled a detection algorithm that + complies with the requirements set in Section 2, a TCP sender MAY use + the Eifel response algorithm as defined in this subsection. + + If the Eifel response algorithm is used, the following steps MUST be + taken by the TCP sender, but only upon initiation of a timeout-based + loss recovery. That is when the first timeout-based retransmit is + sent. The algorithm MUST NOT be reinitiated after a timeout-based + loss recovery has already been started but not completed. In + particular, it may not be reinitiated upon subsequent timeouts for + the same segment, or upon retransmitting segments other than the + oldest outstanding segment. + + + + + +Ludwig & Gurtov Standards Track [Page 3] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + (0) Before the variables cwnd and ssthresh get updated when + loss recovery is initiated, set a "pipe_prev" variable as + follows: + pipe_prev <- max (FlightSize, ssthresh) + + Set a "SRTT_prev" variable and a "RTTVAR_prev" variable as + follows: + SRTT_prev <- SRTT + (2 * G) + RTTVAR_prev <- RTTVAR + + (DET) This is a placeholder for a detection algorithm that must + be executed at this point, and that sets the variable + SpuriousRecovery as outlined in Section 2. If + [RFC3522] is used as the detection algorithm, steps (1) - + (6) of that algorithm go here. + + (7) If SpuriousRecovery equals SPUR_TO, then + proceed to step (8); + + else if SpuriousRecovery equals LATE_SPUR_TO, then + proceed to step (9); + + else + proceed to step (DONE). + + (8) Resume the transmission with previously unsent data: + + Set + SND.NXT <- SND.MAX + + (9) Reverse the congestion control state: + + If the acceptable ACK has the ECN-Echo flag [RFC3168] set, + then + proceed to step (DONE); + + else set + cwnd <- FlightSize + min (bytes_acked, IW) + ssthresh <- pipe_prev + + Proceed to step (DONE). + + (10) Interworking with Congestion Window Validation: + + If congestion window validation is implemented according + to [RFC2861], then set + T_last <- tcpnow + + + + +Ludwig & Gurtov Standards Track [Page 4] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + (11) Adapt the conservativeness of the retransmission timer: + + Upon the first RTT-SAMPLE taken from new data; i.e., the + first RTT-SAMPLE that can be derived from an acceptable + ACK for data that was previously unsent when the spurious + timeout occurred, + + if the retransmission timer is implemented according + to [RFC2988], then set + SRTT <- max (SRTT_prev, RTT-SAMPLE) + RTTVAR <- max (RTTVAR_prev, RTT-SAMPLE/2) + RTO <- SRTT + max (G, 4*RTTVAR) + + Run the bounds check on the RTO (rules (2.4) and + (2.5) in [RFC2988]), and restart the + retransmission timer; + + else + appropriately adapt the conservativeness of the + retransmission timer that is implemented. + + (DONE) No further processing. + +3.2. Storing the Current Congestion Control State (Step 0) + + The TCP sender stores in pipe_prev what is considered a safe slow- + start threshold (ssthresh) before loss recovery is initiated; i.e., + before the loss indication is taken into account. This is either the + current FlightSize, if the TCP sender is in congestion avoidance, or + the current ssthresh, if the TCP sender is in slow-start. If the TCP + sender later detects that it has entered loss recovery unnecessarily, + then pipe_prev is used in step (9) to reverse the congestion control + state. Thus, until the loss recovery phase is terminated, pipe_prev + maintains a memory of the congestion control state of the time right + before the loss recovery phase was initiated. A similar approach is + proposed in [RFC2861], where this state is stored in ssthresh + directly after a TCP sender has become idle or application limited. + + There had been debates about whether the value of pipe_prev should be + decayed over time; e.g., upon subsequent timeouts for the same + outstanding segment. We do not require decaying pipe_prev for the + Eifel response algorithm and do not believe that such a conservative + approach should be in place. Instead, we follow the idea of + revalidating the congestion window through slow-start, as suggested + in [RFC2861]. That is, in step (9), the cwnd is reset to a value + that avoids large packet bursts, and ssthresh is reset to the value + of pipe_prev. Note that [RFC2581] and [RFC2861] also do not require + + + + +Ludwig & Gurtov Standards Track [Page 5] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + a decaying of ssthresh after it has been reset in response to a loss + indication, or after a TCP sender has become idle or application + limited. + +3.3. Suppressing the Unnecessary go-back-N Retransmits (Step 8) + + Without the use of the TCP timestamps option [RFC1323], the TCP + sender suffers from the retransmission ambiguity problem [Zh86], + [KP87]. Therefore, when the first acceptable ACK arrives after a + spurious timeout, the TCP sender must assume that this ACK was sent + in response to the retransmit when in fact it was sent in response to + an original transmit. Furthermore, the TCP sender must further + assume that all other segments that were outstanding at that point + were lost. + + Note: Except for certain cases where original ACKs were lost, the + first acceptable ACK cannot carry a DSACK option [RFC2883]. + + Consequently, once the TCP sender's state has been updated after the + first acceptable ACK has arrived, SND.NXT equals SND.UNA. This is + what causes the often unnecessary go-back-N retransmits. From that + point on every arriving acceptable ACK that was sent in response to + an original transmit will advance SND.NXT. But as long as SND.NXT is + smaller than the value that SND.MAX had when the timeout occurred, + those ACKs will clock out retransmits, whether or not the + corresponding original transmits were lost. + + In fact, during this phase the TCP sender breaks 'packet + conservation' [Jac88]. This is because the go-back-N retransmits are + sent during slow-start. For each original transmit leaving the + network, two retransmits are sent into the network as long as SND.NXT + does not equal SND.MAX (see [LK00] for more detail). + + Once a spurious timeout has been detected (upon receipt of an ACK for + an original transmit), it is safe to let the TCP sender resume the + transmission with previously unsent data. Thus, the Eifel response + algorithm changes the TCP sender's state by setting SND.NXT to + SND.MAX. Note that this step is only executed if the variable + SpuriousRecovery equals SPUR_TO, which in turn requires a detection + algorithm such as the Eifel detection algorithm [RFC3522] or the F- + RTO algorithm [SK04] that detects a spurious retransmit based upon + receiving an ACK for an original transmit (as opposed to the ACK for + the retransmit [RFC3708]). + + + + + + + + +Ludwig & Gurtov Standards Track [Page 6] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + +3.4. Reversing the Congestion Control State (Step 9) + + When a TCP sender enters loss recovery, it reduces cwnd and ssthresh. + However, once the TCP sender detects that the loss recovery has been + falsely triggered, this reduction proves unnecessary. We therefore + believe that it is safe to revert to the previous congestion control + state, following the approach of revalidating the congestion window + as outlined below. This is unless the acceptable ACK signals + congestion through the ECN-Echo flag [RFC3168]. In that case, the + TCP sender MUST refrain from reversing congestion control state. + + If the ECN-Echo flag is not set, cwnd is reset to the sum of the + current FlightSize and the minimum of bytes_acked and IW. In some + cases, this can mean that the first few acceptable ACKs that arrive + will not clock out any data segments. Recall that bytes_acked is the + number of bytes that have been acknowledged by the acceptable ACK. + Note that the value of cwnd must not be changed any further for that + ACK, and that the value of FlightSize at this point in time may be + different from the value of FlightSize in step (0). The value of IW + puts a limit on the size of the packet burst that the TCP sender may + send into the network after the Eifel response algorithm has + terminated. The value of IW is considered an acceptable burst size. + It is the amount of data that a TCP sender may send into a yet + "unprobed" network at the beginning of a connection. + + Then ssthresh is reset to the value of pipe_prev. As a result, the + TCP sender either immediately resumes probing the network for more + bandwidth in congestion avoidance, or it slow-starts to what is + considered a safe operating point for the congestion window. + +3.5. Interworking with the CWV Algorithm (Step 10) + + An implementation of the Congestion Window Validation (CWV) algorithm + [RFC2861] could potentially misinterpret a delay spike that caused a + spurious timeout as a phase where the TCP sender had been idle. + Therefore, T_last is reset to prevent the triggering of the CWV + algorithm in this case. + + Note: The term 'idle' implies that the TCP sender has no data + outstanding; i.e., all data sent has been acknowledged [Jac88]. + According to this definition, a TCP sender is not idle while it is + waiting for an acceptable ACK after a timeout. Unfortunately, the + pseudo-code in [RFC2861] does not include a check for the + condition "idle" (SND.UNA == SND.MAX). We therefore had to add + step (10) to the Eifel response algorithm. + + + + + + +Ludwig & Gurtov Standards Track [Page 7] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + +3.6. Adapting the Retransmission Timer (Step 11) + + There is currently only one retransmission timer standardized for TCP + [RFC2988]. We therefore only address that timer explicitly. Future + standards that might define alternatives to [RFC2988] should propose + similar measures to adapt the conservativeness of the retransmission + timer. + + A spurious timeout often results from a delay spike, which is a + sudden increase of the RTT that usually cannot be predicted. After a + delay spike, the RTT may have changed permanently; e.g., due to a + path change, or because the available bandwidth on a bandwidth- + dominated path has decreased. This may often occur with wide-area + wireless access links. In this case, the RTT estimators (SRTT and + RTTVAR) should be reinitialized from the first RTT-SAMPLE taken from + new data according to rule (2.2) of [RFC2988]. That is, from the + first RTT-SAMPLE that can be derived from an acceptable ACK for data + that was previously unsent when the spurious timeout occurred. + + However, a delay spike may only indicate a transient phase, after + which the RTT returns to its previous range of values, or even to + smaller values. Also, a spurious timeout may occur because the TCP + sender's RTT estimators were only inaccurate enough that the + retransmission timer expires "a tad too early". We believe that two + times the clock granularity of the retransmission timer (2 * G) is a + reasonable upper bound on "a tad too early". Thus, when the new RTO + is calculated in step (11), we ensure that it is at least (2 * G) + greater (see also step (0)) than the RTO was before the spurious + timeout occurred. + + Note that other TCP sender processing will usually take place between + steps (10) and (11). During this phase (i.e., before step (11) has + been reached), the RTO is managed according to the rules of + [RFC2988]. We believe that this is sufficiently conservative for the + following reasons. First, the retransmission timer is restarted upon + the acceptable ACK that was used to detect the spurious timeout. As + a result, the delay spike is already implicitly factored in for + segments outstanding at that time. This is discussed in more detail + in [EL04], where this effect is called the "RTO offset". + Furthermore, if timestamps are enabled, a new and valid RTT-SAMPLE + can be derived from that acceptable ACK. This RTT-SAMPLE must be + relatively large, as it includes the delay spike that caused the + spurious timeout. Consequently, the RTT estimators will be updated + rather conservatively. Without timestamps the RTO will stay + conservatively backed-off due to Karn's algorithm [RFC2988] until the + first RTT-SAMPLE can be derived from an acceptable ACK for data that + was previously unsent when the spurious timeout occurred. + + + + +Ludwig & Gurtov Standards Track [Page 8] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + For the new RTO to become effective, the retransmission timer has to + be restarted. This is consistent with [RFC2988], which recommends + restarting the retransmission timer with the arrival of an acceptable + ACK. + +4. Advanced Loss Recovery is Crucial for the Eifel Response Algorithm + + We have studied environments where spurious timeouts and multiple + losses from the same flight of packets often coincide [GL02], [GL03]. + In such a case, the oldest outstanding segment arrives at the TCP + receiver, but one or more packets from the remaining outstanding + flight are lost. In those environments, end-to-end performance + suffers if the Eifel response algorithm is operated without an + advanced loss recovery scheme such as a SACK-based scheme [RFC3517] + or NewReno [RFC3782]. The reason is TCP-Reno's aggressiveness after + a spurious timeout. Even though TCP-Reno breaks 'packet + conservation' (see Section 3.3) when blindly retransmitting all + outstanding segments, it usually recovers all packets lost from that + flight within a single round-trip time. On the contrary, the more + conservative TCP-Reno-with-Eifel is often forced into another + timeout. Thus, we recommend that the Eifel response algorithm always + be operated in combination with [RFC3517] or [RFC3782]. Additional + robustness is achieved with the Limited Transmit and Early Retransmit + algorithms [RFC3042], [AAAB04]. + + Note: The SACK-based scheme we used for our simulations in [GL02] + and [GL03] is different from the SACK-based scheme that later got + standardized [RFC3517]. The key difference is that [RFC3517] is + more robust to multiple losses from the same flight. It is less + conservative in declaring that a packet has left the network, and + is therefore less dependent on timeouts to recover genuine packet + losses. + + If the NewReno algorithm [RFC3782] is used in combination with the + Eifel response algorithm, step (1) of the NewReno algorithm SHOULD be + modified as follows, but only if SpuriousRecovery equals SPUR_TO: + + (1) Three duplicate ACKs: + When the third duplicate ACK is received and the sender is + not already in the Fast Recovery procedure, go to step 1A. + + That is, the entire step 1B of the NewReno algorithm is obsolete + because step (8) of the Eifel response algorithm avoids the case + where three duplicate ACKs result from unnecessary go-back-N + retransmits after a timeout. Step (8) of the Eifel response + algorithm avoids such unnecessary go-back-N retransmits in the first + place. However, recall that step (8) is only executed if the + variable SpuriousRecovery equals SPUR_TO, which in turn requires a + + + +Ludwig & Gurtov Standards Track [Page 9] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + detection algorithm, such as the Eifel detection algorithm [RFC3522] + or the F-RTO algorithm [SK04], that detects a spurious retransmit + based upon receiving an ACK for an original transmit (as opposed to + the ACK for the retransmit [RFC3708]). + +5. Security Considerations + + There is a risk that a detection algorithm is fooled by spoofed ACKs + that make genuine retransmits appear to the TCP sender as spurious + retransmits. When such a detection algorithm is run together with + the Eifel response algorithm, this could effectively disable + congestion control at the TCP sender. Should this become a concern, + the Eifel response algorithm SHOULD only be run together with + detection algorithms that are known to be safe against such "ACK + spoofing attacks". + + For example, the safe variant of the Eifel detection algorithm + [RFC3522], is a reliable method to protect against this risk. + +6. Acknowledgements + + Many thanks to Keith Sklower, Randy Katz, Michael Meyer, Stephan + Baucke, Sally Floyd, Vern Paxson, Mark Allman, Ethan Blanton, Pasi + Sarolahti, Alexey Kuznetsov, and Yogesh Swami for many discussions + that contributed to this work. + +7. References + +7.1. Normative References + + [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion + Control", RFC 2581, April 1999. + + [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's + Initial Window", RFC 3390, October 2002. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno + Modification to TCP's Fast Recovery Algorithm", RFC 3782, + April 2004. + + [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion + Window Validation", RFC 2861, June 2000. + + [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm for + TCP", RFC 3522, April 2003. + + + +Ludwig & Gurtov Standards Track [Page 10] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of + Explicit Congestion Notification (ECN) to IP", RFC 3168, + September 2001. + +7.2. Informative References + + [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing + TCP's Loss Recovery Using Limited Transmit", RFC 3042, + January 2001. + + [AAAB04] Allman, M., Avrachenkov, K., Ayesta, U., and J. Blanton, + Early Retransmit for TCP and SCTP, Work in Progress, July + 2004. + + [BA02] Blanton, E. and M. Allman, On Making TCP More Robust to + Packet Reordering, ACM Computer Communication Review, Vol. + 32, No. 1, January 2002. + + [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective + Acknowledgement (DSACKs) and Stream Control Transmission + Protocol (SCTP) Duplicate Transmission Sequence Numbers + (TSNs) to Detect Spurious Retransmissions", RFC 3708, + February 2004. + + [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. + + [EL04] Ekstrom, H. and R. Ludwig, The Peak-Hopper: A New End-to- + End Retransmission Timer for Reliable Unicast Transport, In + Proceedings of IEEE INFOCOM 04, March 2004. + + [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An + Extension to the Selective Acknowledgement (SACK) Option + for TCP", RFC 2883, July 2000. + + [GL02] Gurtov, A. and R. Ludwig, Evaluating the Eifel Algorithm + for TCP in a GPRS Network, In Proceedings of the European + Wireless Conference, February 2002. + + [GL03] Gurtov, A. and R. Ludwig, Responding to Spurious Timeouts + in TCP, In Proceedings of IEEE INFOCOM 03, April 2003. + + + +Ludwig & Gurtov Standards Track [Page 11] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + + [Jac88] Jacobson, V., Congestion Avoidance and Control, In + Proceedings of ACM SIGCOMM 88. + + [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions + for High Performance", RFC 1323, May 1992. + + [KP87] Karn, P. and C. Partridge, Improving Round-Trip Time + Estimates in Reliable Transport Protocols, In Proceedings + of ACM SIGCOMM 87. + + [LK00] Ludwig, R. and R. H. Katz, The Eifel Algorithm: Making TCP + Robust Against Spurious Retransmissions, ACM Computer + Communication Review, Vol. 30, No. 1, January 2000. + + [SK04] Sarolahti, P. and M. Kojo, F-RTO: An Algorithm for + Detecting Spurious Retransmission Timeouts with TCP and + SCTP, Work in Progress, November 2004. + + [WS95] Wright, G. R. and W. R. Stevens, TCP/IP Illustrated, Volume + 2 (The Implementation), Addison Wesley, January 1995. + + [Zh86] Zhang, L., Why TCP Timers Don't Work Well, In Proceedings + of ACM SIGCOMM 88. + +Authors' Addresses + + Reiner Ludwig + Ericsson Research (EDD) + Ericsson Allee 1 + 52134 Herzogenrath, Germany + + EMail: Reiner.Ludwig@ericsson.com + + + Andrei Gurtov + Helsinki Institute for Information Technology (HIIT) + P.O. Box 9800, FIN-02015 + HUT, Finland + + EMail: andrei.gurtov@cs.helsinki.fi + Homepage: http://www.cs.helsinki.fi/u/gurtov + + + + + + + + + + +Ludwig & Gurtov Standards Track [Page 12] + +RFC 4015 The Eifel Response Algorithm for TCP February 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + +Ludwig & Gurtov Standards Track [Page 13] + |