Improving the Robustness of TCP to Non-Congestion Events
RFC 4653
|
| Document |
Type |
|
RFC - Experimental
(August 2006; Errata)
|
|
Last updated |
|
2015-10-14
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 4653 (Experimental)
|
|
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
Show full document text