Improving the Robustness of TCP to Non-Congestion Events
RFC 4653
Document | Type | RFC - Experimental (August 2006; Errata) | |
---|---|---|---|
Authors | Anil Reddy , Sumitha Bhandarkar , Ethan Blanton , Mark Allman | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4653 (Experimental) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Lars Eggert | ||
Send notices to | (None) |
Network Working Group S. Bhandarkar Request for Comments: 4653 A. L. N. Reddy Category: Experimental Texas A&M University M. Allman ICIR/ICSI E. Blanton Purdue University August 2006 Improving the Robustness of TCP to Non-Congestion Events Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document specifies Non-Congestion Robustness (NCR) for TCP. In the absence of explicit congestion notification from the network, TCP uses loss as an indication of congestion. One of the ways TCP detects loss is using the arrival of three duplicate acknowledgments. However, this heuristic is not always correct, notably in the case when network paths reorder segments (for whatever reason), resulting in degraded performance. TCP-NCR is designed to mitigate this degraded performance by increasing the number of duplicate acknowledgments required to trigger loss recovery, based on the current state of the connection, in an effort to better disambiguate true segment loss from segment reordering. This document specifies the changes to TCP, as well as the costs and benefits of these modifications. Bhandarkar, et al. Experimental [Page 1] RFC 4653 Improving the Robustness of TCP August 2006 Table of Contents 1. Introduction ....................................................2 1.1. Terminology ................................................4 2. NCR Description .................................................5 3. Algorithm .......................................................6 3.1. Initialization .............................................8 3.2. Terminating Extended Limited Transmit and Preventing Bursts ..........................................9 3.3. Extended Limited Transmit .................................10 3.4. Entering Loss Recovery ....................................11 4. Advantages .....................................................12 5. Disadvantages ..................................................12 6. Related Work ...................................................13 7. Security Considerations ........................................14 8. Acknowledgments ................................................14 9. IANA Considerations ............................................14 10. References ....................................................14 10.1. Normative References .....................................14 10.2. Informative References ...................................15 1. Introduction One strength of TCP [RFC793] lies in its ability to adjust its sending rate according to the perceived congestion in the network [Jac88, RFC2581]. In the absence of explicit notification of congestion from the network, TCP uses segment loss as an indication of congestion (i.e., assuming queue overflow). TCP receivers send cumulative acknowledgments (ACKs) indicating the next sequence number expected from the sender for arriving segments [RFC793]. When segments arrive out of order, duplicate ACKs are generated. As specified in [RFC2581], a TCP sender uses the arrival of three duplicate ACKs as an indication of segment loss. The TCP sender retransmits the lost segment and reduces the load imposed on the network, assuming the segment loss was caused by resource contention within the network path. The TCP sender does not assume loss on the first or second duplicate ACK, but waits for three duplicate ACKs to account for minor packet reordering. However, the use of this constant threshold of duplicate ACKs has several problems that can be mitigated with a dynamic threshold. The following is an example of TCP's behavior: + TCP A is the data sender, and TCP B is the data receiver. + TCP A sends 10 segments, each consisting of a single data byte (i.e., transmits bytes 1-10 in segments 1-10). Bhandarkar, et al. Experimental [Page 2] RFC 4653 Improving the Robustness of TCP August 2006 + Assume segment 3 is dropped in the network. + TCP B cumulatively acknowledges segments 1 and 2, making the cumulative ACK transmitted to the sender 3 (the next expectedShow full document text