draft-ietf-tcpm-tcp-rfc4614bis-00.txt   draft-ietf-tcpm-tcp-rfc4614bis-01.txt 
TCP Maintenance and Minor Extensions M. Duke TCP Maintenance and Minor Extensions M. Duke
(TCPM) WG Boing (TCPM) WG F5
Internet-Draft R. Braden Internet-Draft R. Braden
Obsoletes: 4614 (if approved) ISI Obsoletes: 4614 (if approved) ISI
Intended status: Informational W. Eddy Intended status: Informational W. Eddy
Expires: February 10, 2014 MTI Systems Expires: May 25, 2014 MTI Systems
E. Blanton E. Blanton
A. Zimmermann A. Zimmermann
NetApp, Inc. NetApp, Inc.
August 9, 2013 November 21, 2013
A Roadmap for Transmission Control Protocol (TCP) Specification A Roadmap for Transmission Control Protocol (TCP) Specification
Documents Documents
draft-ietf-tcpm-tcp-rfc4614bis-00 draft-ietf-tcpm-tcp-rfc4614bis-01
Abstract Abstract
This document contains a "roadmap" to the Requests for Comments (RFC) This document contains a "roadmap" to the Requests for Comments (RFC)
documents relating to the Internet's Transmission Control Protocol documents relating to the Internet's Transmission Control Protocol
(TCP). This roadmap provides a brief summary of the documents (TCP). This roadmap provides a brief summary of the documents
defining TCP and various TCP extensions that have accumulated in the defining TCP and various TCP extensions that have accumulated in the
RFC series. This serves as a guide and quick reference for both TCP RFC series. This serves as a guide and quick reference for both TCP
implementers and other parties who desire information contained in implementers and other parties who desire information contained in
the TCP-related RFCs. the TCP-related RFCs.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 10, 2014. This Internet-Draft will expire on May 25, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Core Functionality . . . . . . . . . . . . . . . . . . . . . . 4 2. Core Functionality . . . . . . . . . . . . . . . . . . . . . . 5
3. Recommended Enhancements . . . . . . . . . . . . . . . . . . . 7 3. Recommended Enhancements . . . . . . . . . . . . . . . . . . . 8
3.1. Fundamental Changes . . . . . . . . . . . . . . . . . . . 8 3.1. Fundamental Changes . . . . . . . . . . . . . . . . . . . 8
3.2. Congestion Control and Loss Recovery Extensions . . . . . 9 3.2. Congestion Control Extensions . . . . . . . . . . . . . . 9
3.3. SACK-Based Loss Recovery and Congestion Control . . . . . 10 3.3. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 10
3.4. Detection and Prevention of Spurious Retransmissions . . . 11 3.4. Detection and Prevention of Spurious Retransmissions . . . 12
3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 12 3.5. TCP Timeouts . . . . . . . . . . . . . . . . . . . . . . . 13
3.6. Header Compression . . . . . . . . . . . . . . . . . . . . 13 3.6. Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 13
3.7. Defending Spoofing and Flooding Attacks . . . . . . . . . 14 3.7. Header Compression . . . . . . . . . . . . . . . . . . . . 14
4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 15 3.8. Defending Spoofing and Flooding Attacks . . . . . . . . . 15
4.1. Architectural Guidelines . . . . . . . . . . . . . . . . . 16 4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 17
4.2. Congestion Control and Loss Recovery Extensions . . . . . 17 4.1. Architectural Guidelines . . . . . . . . . . . . . . . . . 17
4.3. Detection and Prevention of Spurious Retransmissions . . . 19 4.2. Congestion Control Extensions . . . . . . . . . . . . . . 18
4.4. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 20 4.3. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 19
5. TCP Parameters at IANA . . . . . . . . . . . . . . . . . . . . 20 4.4. Detection and Prevention of Spurious Retransmissions . . . 20
6. Historic and Undeployed Extensions . . . . . . . . . . . . . . 21 4.5. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 21
7. Support Documents . . . . . . . . . . . . . . . . . . . . . . 24 5. TCP Parameters at IANA . . . . . . . . . . . . . . . . . . . . 21
7.1. Foundational Works . . . . . . . . . . . . . . . . . . . . 24 6. Historic and Undeployed Extensions . . . . . . . . . . . . . . 22
7.2. Architectural Guidelines . . . . . . . . . . . . . . . . . 26 7. Support Documents . . . . . . . . . . . . . . . . . . . . . . 25
7.3. Difficult Network Environments . . . . . . . . . . . . . . 27 7.1. Foundational Works . . . . . . . . . . . . . . . . . . . . 25
7.4. Guidance for Developing, Analyzing, and Evaluating TCP . . 29 7.2. Architectural Guidelines . . . . . . . . . . . . . . . . . 27
7.5. Implementation Advice . . . . . . . . . . . . . . . . . . 30 7.3. Difficult Network Environments . . . . . . . . . . . . . . 28
7.6. Management Information Bases . . . . . . . . . . . . . . . 32 7.4. Guidance for Developing, Analyzing, and Evaluating TCP . . 30
7.7. Tools and Tutorials . . . . . . . . . . . . . . . . . . . 34 7.5. Implementation Advice . . . . . . . . . . . . . . . . . . 31
7.8. Case Studies . . . . . . . . . . . . . . . . . . . . . . . 35 7.6. Tools and Tutorials . . . . . . . . . . . . . . . . . . . 34
8. Undocumented TCP Features . . . . . . . . . . . . . . . . . . 36 7.7. Management Information Bases . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 7.8. Case Studies . . . . . . . . . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. Undocumented TCP Features . . . . . . . . . . . . . . . . . . 37
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 38
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
12.1. Normative References . . . . . . . . . . . . . . . . . . . 38 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . . 47 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 12.1. Normative References . . . . . . . . . . . . . . . . . . . 39
12.2. Informative References . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
A correct and efficient implementation of the Transmission Control A correct and efficient implementation of the Transmission Control
Protocol (TCP) is a critical part of the software of most Internet Protocol (TCP) is a critical part of the software of most Internet
hosts. As TCP has evolved over the years, many distinct documents hosts. As TCP has evolved over the years, many distinct documents
have become part of the accepted standard for TCP. At the same time, have become part of the accepted standard for TCP. At the same time,
a large number of more experimental modifications to TCP have also a large number of experimental modifications to TCP have also been
been published in the RFC series, along with informational notes, published in the RFC series, along with informational notes, case
case studies, and other advice. studies, and other advice.
As an introduction to newcomers and an attempt to organize the As an introduction to newcomers and an attempt to organize the
plethora of information for old hands, this document contains a plethora of information for old hands, this document contains a
"roadmap" to the TCP-related RFCs. It provides a brief summary of "roadmap" to the TCP-related RFCs. It provides a brief summary of
the RFC documents that define TCP. This should provide guidance to the RFC documents that define TCP. This should provide guidance to
implementers on the relevance and significance of the standards-track implementers on the relevance and significance of the standards-track
extensions, informational notes, and best current practices that extensions, informational notes, and best current practices that
relate to TCP. relate to TCP.
This document is not an update of RFC 1122 and is not a rigorous This document is not an update of RFC 1122 and is not a rigorous
skipping to change at page 4, line 42 skipping to change at page 5, line 42
Section 5 describes both the procedures that the Internet Assigned Section 5 describes both the procedures that the Internet Assigned
Numbers Authority (IANA) uses and an RFC author should follow when Numbers Authority (IANA) uses and an RFC author should follow when
new TCP parameters are requested and finally assigned. new TCP parameters are requested and finally assigned.
A small number of older experimental extensions that have not been A small number of older experimental extensions that have not been
widely implemented, deployed, and used are noted in Section 6. Many widely implemented, deployed, and used are noted in Section 6. Many
other supporting documents that are relevant to the development, other supporting documents that are relevant to the development,
implementation, and deployment of TCP are described in Section 7. implementation, and deployment of TCP are described in Section 7.
A small number of fairly ubiquitous important implementation A small number of fairly ubiquitous important implementation
practices that is not currently documented in the RFC series is practices that are not currently documented in the RFC series is
listed in Section 8. listed in Section 8.
Within each section, RFCs are listed in the chronological order of Within each section, RFCs are listed in the chronological order of
their publication dates. their publication dates.
2. Core Functionality 2. Core Functionality
A small number of documents compose the core specification of TCP. A small number of documents compose the core specification of TCP.
These define the required core functionalities of TCP's header These define the required core functionalities of TCP's header
parsing, state machine, congestion control, and retransmission parsing, state machine, congestion control, and retransmission
skipping to change at page 6, line 13 skipping to change at page 7, line 13
to support IPv6 jumbograms. to support IPv6 jumbograms.
RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000) RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000)
(Errata) (Errata)
This document [RFC2873] removes from the TCP specification all This document [RFC2873] removes from the TCP specification all
processing of the precedence bits of the TOS byte of the IP processing of the precedence bits of the TOS byte of the IP
header. This resolves a conflict over the use of these bits header. This resolves a conflict over the use of these bits
between RFC 793 and Differentiated Services [RFC2474]. between RFC 793 and Differentiated Services [RFC2474].
RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)
This document [RFC3390] specifies an increase in the permitted
initial window for TCP from one segment to three or four segments
during the slow start phase, depending on the segment size.
RFC 5681 S: "TCP Congestion Control" (August 2009) RFC 5681 S: "TCP Congestion Control" (August 2009)
Although RFC 793 did not contain any congestion control Although RFC 793 did not contain any congestion control
mechanisms, today congestion control is a required component of mechanisms, today congestion control is a required component of
TCP implementations. This document [RFC5681] defines the current TCP implementations. This document [RFC5681] defines the current
versions of Van Jacobson's congestion avoidance and control versions of Van Jacobson's congestion avoidance and control
mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88]. mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88].
A number of behaviors that together constitute what the community A number of behaviors that together constitute what the community
refers to as "Reno TCP" are described in RFC 5681. The name refers to as "Reno TCP" are described in RFC 5681. The name
skipping to change at page 7, line 4 skipping to change at page 7, line 45
implementation and is required for the avoidance of congestion implementation and is required for the avoidance of congestion
collapse and to ensure fairness among competing flows. collapse and to ensure fairness among competing flows.
RFC 2001 and RFC 2581 are the conceptual precursors of RFC 5681. RFC 2001 and RFC 2581 are the conceptual precursors of RFC 5681.
The most important changes relative to RFC 2581 are: The most important changes relative to RFC 2581 are:
(a) The initial window requirements were changed to allow larger (a) The initial window requirements were changed to allow larger
Initial Windows as standardized in [RFC3390]. Initial Windows as standardized in [RFC3390].
(b) During slow start and congestion avoidance, the usage of (b) During slow start and congestion avoidance, the usage of
Appropriate Byte Counting [RFC3465] is explicitly Appropriate Byte Counting [RFC3465] is explicitly
recommended. recommended.
(c) The use of Limited Transmit [RFC3042] is now recommended. (c) The use of Limited Transmit [RFC3042] is now recommended.
RFC 6093 S: "On the Implementation of the TCP Urgent Mechanism" RFC 6093 S: "On the Implementation of the TCP Urgent Mechanism"
(January 2011) (January 2011)
This document [RFC6093] analyzes how current TCP stacks process This document [RFC6093] analyzes how current TCP stacks process
TCP urgent indications, and how the behavior of widely deployed TCP urgent indications, and how the behavior of widely deployed
middleboxes affects the urgent indications processing. Based on middleboxes affects the urgent indications processing. The
their investigation, the document updates the relevant document updates the relevant specifications such that it
specifications such that they accommodate current practice in accommodates current practice in processing TCP urgent
processing TCP urgent indications. Finally, the document raises indications. Finally, the document raises awareness about the
awareness about the reliability of TCP urgent indications in the reliability of TCP urgent indications in the Internet, and
Internet, and recommends against the use of urgent mechanism. recommends against the use of urgent mechanism.
RFC 6298 S: "Computing TCP's Retransmission Timer" (June 2011) RFC 6298 S: "Computing TCP's Retransmission Timer" (June 2011)
Abstract: "This document defines the standard algorithm that Abstract: "This document defines the standard algorithm that
Transmission Control Protocol (TCP) senders are required to use to Transmission Control Protocol (TCP) senders are required to use to
compute and manage their retransmission timer. It expands on the compute and manage their retransmission timer. It expands on the
discussion in section 4.2.3.1 of RFC 1122 and upgrades the discussion in section 4.2.3.1 of RFC 1122 and upgrades the
requirement of supporting the algorithm from a SHOULD to a MUST." requirement of supporting the algorithm from a SHOULD to a MUST."
[RFC6298]. RFC 6298 is the successor of RFC 2988, which changes [RFC6298]. RFC 6298 updates RFC 2988 by changing the initial RTO
the initial RTO from 3s to 1s. from 3s to 1s
RFC 6691 I: "TCP Options and Maximum Segment Size (MSS)" (July 2012) RFC 6691 I: "TCP Options and Maximum Segment Size (MSS)" (July 2012)
This document [RFC6691] clarifies what value to use with the TCP This document [RFC6691] clarifies what value to use with the TCP
Maximum Segment Size (MSS) option when IP and TCP options are in Maximum Segment Size (MSS) option when IP and TCP options are in
use. use.
3. Recommended Enhancements 3. Recommended Enhancements
This section describes recommended TCP modifications that improve This section describes recommended TCP modifications that improve
performance and security. Section 3.1 represents fundamental changes performance and security. Section 3.1 represents fundamental changes
to the protocol. Section 3.2 lists improvements in the congestion to the protocol. Section 3.2 and Section 3.3 list improvements over
control and loss recovery mechanisms specified in RFC 5681. the congestion control and loss recovery mechanisms as specified in
Section 3.3 describes further refinements that make use of selective RFC 5681. Section 3.4 describes algorithms that allow a TCP sender
acknowledgments. Section 3.4 describes algorithms that allows a TCP to detect whether it has entered loss recovery spuriously.
sender to detect whether it has entered loss recovery unnecessarily. Section 3.5 lists documents that revolve around the various TCP
Section 3.5 compromises Path MTU Discovery mechanisms. Header timers. Section 3.6 comprises Path MTU Discovery mechanisms.
compression schemes for TCP/IP header compression are listed in Schemes for TCP/IP header compression are listed in Section 3.7.
Section 3.6. Finally, Section 3.7 deals with the problem of Finally, Section 3.8 deals with the problem of preventing preventing
preventing forged segments and flooding attacks. acceptance of forged segments and flooding attacks.
3.1. Fundamental Changes 3.1. Fundamental Changes
RFC 1323 allows better utilization of high bandwidth-delay product RFC 1323 allows better utilization of high bandwidth-delay product
paths by providing some needed mechanisms for high-rate transfers. paths by providing some needed mechanisms for high-rate transfers.
RFC 2675 describes changes to TCP's semantic for using IPv6 RFC 2675 describes changes to TCP's semantic for using IPv6
Jumbograms. RFC 5482 specifies the TCP User Timeout Option. Jumbograms.
RFC 1323 S: "TCP Extensions for High Performance" (May 1992) RFC 1323 S: "TCP Extensions for High Performance" (May 1992)
This document [RFC1323] defines TCP extensions for window scaling, This document [RFC1323] defines TCP extensions for window scaling,
timestamps, and protection against wrapped sequence numbers, for timestamps, and protection against wrapped sequence numbers, for
efficient and safe operation over paths with large bandwidth-delay efficient and safe operation over paths with large bandwidth-delay
products. These extensions are commonly found in currently used products. These extensions are commonly found in currently used
systems; however, they may require manual tuning and systems; however, they may require manual tuning and
configuration. One issue in this specification that is still configuration. One issue in this specification that is still
under discussion concerns a modification to the algorithm for under discussion concerns a modification to the algorithm for
skipping to change at page 8, line 46 skipping to change at page 9, line 39
interoperability with other TCP implementations when IPv4 or non- interoperability with other TCP implementations when IPv4 or non-
jumbogram IPv6 is used. This document states that jumbograms are jumbogram IPv6 is used. This document states that jumbograms are
to only be used when it can be guaranteed that all receiving to only be used when it can be guaranteed that all receiving
nodes, including each router in the end-to-end path, will support nodes, including each router in the end-to-end path, will support
jumbograms. If even a single node that does not support jumbograms. If even a single node that does not support
jumbograms is attached to a local network, then no host on that jumbograms is attached to a local network, then no host on that
network may use jumbograms. This explains why jumbogram use has network may use jumbograms. This explains why jumbogram use has
been rare, and why this document is considered a performance been rare, and why this document is considered a performance
optimization and not part of TCP over IPv6's basic functionality. optimization and not part of TCP over IPv6's basic functionality.
RFC 5482 S: "TCP User Timeout Option" (June 2009) 3.2. Congestion Control Extensions
As a local per-connection parameter the TCP user timeout controls
how long transmitted data may remain unacknowledged before a
connection is forcefully closed. This document [RFC5482]
specifies the TCP User Timeout Option that allows one end of a TCP
connection to advertise its current user timeout value. This
information provides advice to the other end of the TCP connection
to adapt its user timeout accordingly.
3.2. Congestion Control and Loss Recovery Extensions
Two of the most important aspects of TCP are its congestion control Two of the most important aspects of TCP are its congestion control
and loss recovery features. TCP traditionally treats lost packets as and loss recovery features. TCP traditionally treats lost packets as
indicating congestion-related loss, and cannot distinguish between indicating congestion-related loss, and cannot distinguish between
congestion-related loss and loss due to transmission errors. Even congestion-related loss and loss due to transmission errors. Even
when ECN is in use, there is a rather intimate coupling between when ECN is in use, there is a rather intimate coupling between
congestion control and loss recovery mechanisms. There are several congestion control and loss recovery mechanisms. There are several
extensions to both features, and more often than not, a particular extensions to both features, and more often than not, a particular
extension applies to both. In this sub-section, we group extension applies to both. In this two sub-sections, we group
enhancements to either congestion control, loss recovery, or both, enhancements to TCP's congestion control, while the next sub-section
which can be performed unilaterally; that is, without negotiating focus on TCP's loss recovery.
support between endpoints. In the next sub-section, we group the
extensions that specify or rely on the SACK option, which must be
negotiated bilaterally. TCP implementations should include the
enhancements from both sub-sections so that TCP senders can perform
well without regard to the feature sets of other hosts they connect
to. For example, if SACK use is not successfully negotiated, a host
should use the NewReno behavior as a fall back.
RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
(January 2001)
Abstract: "This document proposes Limited Transmit, a new
Transmission Control Protocol (TCP) mechanism that can be used to
more effectively recover lost segments when a connection's
congestion window is small, or when a large number of segments are
lost in a single transmission window." [RFC3042] Tests from 2004
showed that Limited Transmit was deployed in roughly one third of
the web servers tested [MAF04].
RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN) RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
to IP" (September 2001) to IP" (September 2001)
This document [RFC3168] defines a means for end hosts to detect This document [RFC3168] defines a means for end hosts to detect
congestion before congested routers are forced to discard packets. congestion before congested routers are forced to discard packets.
Although congestion notification takes place at the IP level, ECN Although congestion notification takes place at the IP level, ECN
requires support at the transport level (e.g., in TCP) to echo the requires support at the transport level (e.g., in TCP) to echo the
bits and adapt the sending rate. This document updates RFC 793 to bits and adapt the sending rate. This document updates RFC 793 to
define two previously unused flag bits in the TCP header for ECN define two previously unused flag bits in the TCP header for ECN
skipping to change at page 10, line 12 skipping to change at page 10, line 25
for more secure use of ECN, and RFC 2884 provides some sample for more secure use of ECN, and RFC 2884 provides some sample
results from using ECN. results from using ECN.
RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting
(ABC)" (February 2003) (ABC)" (February 2003)
This document [RFC3465] suggests that congestion control use the This document [RFC3465] suggests that congestion control use the
number of bytes acknowledged instead of the number of number of bytes acknowledged instead of the number of
acknowledgments received. The ABC mechanism behaves differently acknowledgments received. The ABC mechanism behaves differently
than the standard method when there is not a one-to-one than the standard method when there is not a one-to-one
relationship between data segments and acknowledgements. ABC relationship between data segments and acknowledgments. ABC still
still operates within the accepted guidelines, but is more robust operates within the accepted guidelines, but is more robust to
to delayed ACKs and ACK-division [SCWA99][RFC3449]. delayed ACKs and ACK-division [SCWA99][RFC3449]. [RFC3465] is
recommended by [RFC5681].
RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)
This document [RFC3390] specifies an increase in the permitted
initial window for TCP from one segment to three or four segments
during the slow start phase, depending on the segment size.
RFC 6633 S: "Deprecation of ICMP Source Quench Messages" (May 2012) RFC 6633 S: "Deprecation of ICMP Source Quench Messages" (May 2012)
This document [RFC6633] formally deprecates the use of ICMP Source This document [RFC6633] formally deprecates the use of ICMP Source
Quench messages by transport protocols and provides a Quench messages by transport protocols and provides a
recommendation against the implementation of [RFC1016]. recommendation against the implementation of [RFC1016].
3.3. Loss Recovery Extensions
For the typical implementation of the TCP fast recovery algorithm
described in [RFC5681], a TCP sender only retransmits a segment after
a retransmit timeout has occurred, or after three duplicate ACKs have
arrived triggering the fast retransmit. A single RTO might result in
the retransmission of several segments, while the fast retransmit
algorithm in RFC 5681 leads only to a single retransmission. Hence,
multiple losses from a single window of data can lead to a
performance degradation. Documents listed in this section aim to
improve the overall performance of TCP's standard loss recovery
algorithms. In particular, some of them allows TCP senders to
recover more effectively when multiple segments are lost from a
single flight of data.
RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996)
(Errata)
When more than one packet is lost during one round trip time TCP
may experience poor performance since a TCP sender can only learn
about a single lost packet per round trip time from cumulative
acknowledgments. This document [RFC2018] defines the basic
selective acknowledgment (SACK) mechanism for TCP, which can help
to overcome these limitations. The receiving TCP returns SACK
blocks to inform the sender which data has been received. The
sender can then retransmit only the missing data segments.
RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
(January 2001)
Abstract: "This document proposes Limited Transmit, a new
Transmission Control Protocol (TCP) mechanism that can be used to
more effectively recover lost segments when a connection's
congestion window is small, or when a large number of segments are
lost in a single transmission window." [RFC3042] Tests from 2004
showed that Limited Transmit was deployed in roughly one third of
the web servers tested [MAF04]. [RFC3042] is recommended by
[RFC5681].
RFC 6582 S: "The NewReno Modification to TCP's Fast Recovery RFC 6582 S: "The NewReno Modification to TCP's Fast Recovery
Algorithm" (April 2012) Algorithm" (April 2012)
This document [RFC6582] specifies a modification to the standard This document [RFC6582] specifies a modification to the standard
Reno fast recovery algorithm, whereby a TCP sender can use partial Reno fast recovery algorithm, whereby a TCP sender can use partial
acknowledgments to make inferences determining the next segment to acknowledgments to make inferences determining the next segment to
send in situations where SACK would be helpful but isn't send in situations where SACK would be helpful but isn't
available. Although it is only a slight modification, the NewReno available. Although it is only a slight modification, the NewReno
behavior can make a significant difference in performance when behavior can make a significant difference in performance when
multiple segments are lost from a single window of data. multiple segments are lost from a single window of data.
RFC 2582 and RFC 3782 are the conceptual precursors of RFC 6582. RFC 2582 and RFC 3782 are the conceptual precursors of RFC 6582.
The main change in RFC 3782 relative to RFC 2582 was to specify The main change in RFC 3782 relative to RFC 2582 was to specify
the Careful variant of NewReno's Fast Retransmit and Fast Recovery the Careful variant of NewReno's Fast Retransmit and Fast Recovery
algorithms and advace those two algorithms from Experimental to algorithms and advance those two algorithms from Experimental to
Standards Track status. The main change in RFC 6582 relative to Standards Track status. The main change in RFC 6582 relative to
RFC 3782 was to solve a performance degradation that could occur RFC 3782 was to solve a performance degradation that could occur
if FlightSize on Full ACK reception is zero. if FlightSize on Full ACK reception is zero.
3.3. SACK-Based Loss Recovery and Congestion Control
The base TCP specification in RFC 793 provided only a simple
cumulative acknowledgment mechanism. However, a selective
acknowledgment (SACK) mechanism provides performance improvement in
the presence of multiple packet losses from the same flight, more
than outweighing the modest increase in complexity. A TCP should be
expected to implement SACK; however, SACK is a negotiated option and
is only used if support is advertised by both sides of a connection.
RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996)
(Errata)
When more than one packet is lost during one round trip time TCP
may experience poor performance since a TCP sender can only learn
about a single lost packet per round trip time from cumulative
acknowledgments. This document [RFC2018] defines the basic
selective acknowledgment (SACK) mechanism for TCP, which can help
to overcome these limitations. The receiving TCP returns SACK
blocks to inform the sender which data has been received. The
sender can then retransmit only the missing data segments.
RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
Option for TCP" (July 2000)
This document [RFC2883] extends RFC 2018. It enables use of the
SACK option to acknowledge duplicate packets. With this
extension, called DSACK, the sender is able to infer the order of
packets received at the receiver, and therefore to infer when it
has unnecessarily retransmitted a packet.
RFC 6675 S: "A Conservative Loss Recovery Algorithm Based on RFC 6675 S: "A Conservative Loss Recovery Algorithm Based on
Selective Acknowledgment (SACK) for TCP" (August 2012) Selective Acknowledgment (SACK) for TCP" (August 2012)
This document [RFC6675] describes a conservative loss recovery This document [RFC6675] describes a conservative loss recovery
algorithm for TCP that is based on the use of the selective algorithm for TCP that is based on the use of the selective
acknowledgment (SACK) TCP option [RFC2018]. The algorithm acknowledgment (SACK) TCP option [RFC2018]. The algorithm
conforms to the spirit of the congestion control specification in conforms to the spirit of the congestion control specification in
RFC 5681, but allows TCP senders to recover more effectively when RFC 5681, but allows TCP senders to recover more effectively when
multiple segments are lost from a single flight of data. multiple segments are lost from a single flight of data.
skipping to change at page 11, line 52 skipping to change at page 12, line 31
(c) it maintains the ACK clock under certain circumstances (c) it maintains the ACK clock under certain circumstances
involving loss at the end of the window. involving loss at the end of the window.
3.4. Detection and Prevention of Spurious Retransmissions 3.4. Detection and Prevention of Spurious Retransmissions
Spurious retransmission timeouts are harmful to TCP performance and Spurious retransmission timeouts are harmful to TCP performance and
multiple algorithms have been defined for detecting when spurious multiple algorithms have been defined for detecting when spurious
retransmissions have occurred, and then responding differently in retransmissions have occurred, and then responding differently in
order to recover performance. The IETF defined multiple algorithms order to recover performance. The IETF defined multiple algorithms
because there are tradeoffs in whether or not certain TCP options because there are tradeoffs in whether or not certain TCP options
need to be implemented, and IPR status. The Standards Track need to be implemented, and concerns about IPR status. The Standards
documents in this section are closely related to the Experimental Track documents in this section are closely related to the
documents in Section 4.3 also addressing this topic. Experimental documents in Section 4.4 also addressing this topic.
RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
Option for TCP" (July 2000)
This document [RFC2883] extends RFC 2018. It enables use of the
SACK option to acknowledge duplicate packets. With this
extension, called DSACK, the sender is able to infer the order of
packets received at the receiver, and therefore to infer when it
has unnecessarily retransmitted a packet.
RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005) RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005)
This document [RFC4015] describes the response portion of the This document [RFC4015] describes the response portion of the
Eifel algorithm, which can be used in conjunction with one of Eifel algorithm, which can be used in conjunction with one of
several methods of detecting when loss recovery has been several methods of detecting when loss recovery has been
spuriously entered, such as the Eifel detection algorithm in RFC spuriously entered, such as the Eifel detection algorithm in RFC
3522, the algorithm in RFC 3708, or F-RTO in RFC 5682. 3522, the algorithm in RFC 3708, or F-RTO in RFC 5682.
Abstract: "Based on an appropriate detection algorithm, the Eifel Abstract: "Based on an appropriate detection algorithm, the Eifel
skipping to change at page 12, line 27 skipping to change at page 13, line 17
detected spurious timeout. It adapts the retransmission timer to detected spurious timeout. It adapts the retransmission timer to
avoid further spurious timeouts, and can avoid - depending on the avoid further spurious timeouts, and can avoid - depending on the
detection algorithm - the often unnecessary go-back-N retransmits detection algorithm - the often unnecessary go-back-N retransmits
that would otherwise be sent. In addition, the Eifel response that would otherwise be sent. In addition, the Eifel response
algorithm restores the congestion control state in such a way that algorithm restores the congestion control state in such a way that
packet bursts are avoided." packet bursts are avoided."
RFC 5682 S: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting RFC 5682 S: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP" (September 2009) Spurious Retransmission Timeouts with TCP" (September 2009)
The F-RTO detection algorithm [RFC5682], originally describes in The F-RTO detection algorithm [RFC5682], originally described in
RFC 4138, provides an option for inferring spurious retransmission RFC 4138, provides an option for inferring spurious retransmission
timeouts. Unlike some similar detection methods (e.g. RFC 3522 timeouts. Unlike some similar detection methods (e.g. RFC 3522
and RFC 3708), F-RTO does not rely on the use of any TCP options. and RFC 3708), F-RTO does not rely on the use of any TCP options.
The basic idea is to send previously unsent data after the first The basic idea is to send previously unsent data after the first
retransmission after a RTO. If the ACKs advance the window, the retransmission after a RTO. If the ACKs advance the window, the
RTO may be declared spurious. RTO may be declared spurious.
3.5. Path MTU Discovery 3.5. TCP Timeouts
FIXME
RFC 5482 S: "TCP User Timeout Option" (June 2009)
As a local per-connection parameter the TCP user timeout controls
how long transmitted data may remain unacknowledged before a
connection is forcefully closed. This document [RFC5482]
specifies the TCP User Timeout Option that allows one end of a TCP
connection to advertise its current user timeout value. This
information provides advice to the other end of the TCP connection
to adapt its user timeout accordingly.
3.6. Path MTU Discovery
The MTUs supported by different links and tunnels within the Internet The MTUs supported by different links and tunnels within the Internet
can vary widely. Fragmentation of packets larger than the supported can vary widely. Fragmentation of packets larger than the supported
MTU on a hop is undesirable. As TCP is the segmentation layer for MTU on a hop is undesirable. As TCP is the segmentation layer for
dividing an application's bytestream into IP packet payloads, TCP dividing an application's bytestream into IP packet payloads, TCP
implementations generally include Path MTU Discovery (PMTUD) implementations generally include Path MTU Discovery (PMTUD)
mechanisms in order to maximize the size of segments they send, mechanisms in order to maximize the size of segments they send,
without causing fragmentation within the network. Some algorithms without causing fragmentation within the network. Some algorithms
may utilize signalling from routers on the path that the MTU has been may utilize signaling from routers on the path that the MTU has been
exceeded. exceeded.
RFC 1191 S: "Path MTU Discovery" (November 1990) RFC 1191 S: "Path MTU Discovery" (November 1990)
Abstract: "This memo describes a technique for dynamically Abstract: "This memo describes a technique for dynamically
discovering the MTU of an arbitrary Internet path. It specifies a discovering the MTU of an arbitrary Internet path. It specifies a
small change to the way routers generate one type of ICMP message. small change to the way routers generate one type of ICMP message.
For a path that passes through a router that has not been so For a path that passes through a router that has not been so
changed, this technique might not discover the correct path MTU, changed, this technique might not discover the correct path MTU,
but it will always choose a path MTU as accurate as, and in many but it will always choose a path MTU as accurate as, and in many
cases more accurate than, the path MTU that would be chosen by cases more accurate than, the path MTU that would be chosen by
current practice." [RFC1191] current practice." [RFC1191]
RFC 1981 S: "Path MTU Discovery for IP version 6" (August 1996) RFC 1981 S: "Path MTU Discovery for IP version 6" (August 1996)
Abstract: "This document describes Path MTU Discovery for IP Abstract: "This document describes Path MTU Discovery for IP
version 6. It is largely derived from RFC 1191, which describes version 6. It is largely derived from RFC 1191, which describes
skipping to change at page 13, line 26 skipping to change at page 14, line 31
RFC 4821 S: "Packetization Layer Path MTU Discovery" (March 2007) RFC 4821 S: "Packetization Layer Path MTU Discovery" (March 2007)
Abstract: "This document describes a robust method for Path MTU Abstract: "This document describes a robust method for Path MTU
Discovery (PMTUD) that relies on TCP or some other Packetization Discovery (PMTUD) that relies on TCP or some other Packetization
Layer to probe an Internet path with progressively larger packets. Layer to probe an Internet path with progressively larger packets.
This method is described as an extension to RFC 1191 and RFC 1981, This method is described as an extension to RFC 1191 and RFC 1981,
which specify ICMP-based Path MTU Discovery for IP versions 4 and which specify ICMP-based Path MTU Discovery for IP versions 4 and
6, respectively." [RFC4821] 6, respectively." [RFC4821]
3.6. Header Compression 3.7. Header Compression
Especially in streaming applications, the overhead of TCP/IP headers Especially in streaming applications, the overhead of TCP/IP headers
could correspond to more then 50% of the total amount of data sent. could correspond to more then 50% of the total amount of data sent.
Such large overheads may be tolerable in wired LANs where capacity is Such large overheads may be tolerable in wired LANs where capacity is
often not an issue, but are excessive for WANs and wireless systems often not an issue, but are excessive for WANs and wireless systems
where bandwidth is scarce. Header compressions schemes for TCP/IP where bandwidth is scarce. Header compression schemes for TCP/IP
like the RObust Header Compression (ROHC) can significant compresses like "RObust Header Compression (ROHC) can significantly compress
these overhead. It performs well over links with significant error this overhead. It performs well over links with significant error
rates and long round-trip times. rates and long round-trip times.
RFC 1144 S: "Compressing TCP/IP Headers for Low-Speed Serial Links" RFC 1144 S: "Compressing TCP/IP Headers for Low-Speed Serial Links"
(February 1990) (February 1990)
This document [RFC1144] describes a method for compressing the This document [RFC1144] describes a method for compressing the
headers of TCP/IP datagrams to improve performance over low speed headers of TCP/IP datagrams to improve performance over low speed
serial links. The method described in this document is limited in serial links. The method described in this document is limited in
its handling of TCP options and cannot compress the headers of its handling of TCP options and cannot compress the headers of
SYNs and FINs. SYNs and FINs.
skipping to change at page 14, line 9 skipping to change at page 15, line 17
From abstract: "This document specifies a RObust Header From abstract: "This document specifies a RObust Header
Compression (ROHC) profile for compression of TCP/IP packets. The Compression (ROHC) profile for compression of TCP/IP packets. The
profile, called ROHC-TCP, provides efficient and robust profile, called ROHC-TCP, provides efficient and robust
compression of TCP headers, including frequently used TCP options compression of TCP headers, including frequently used TCP options
such as selective acknowledgments (SACKs) and Timestamps." such as selective acknowledgments (SACKs) and Timestamps."
[RFC6846] RFC 6846 is the successor of RFC 4996. It fixes a [RFC6846] RFC 6846 is the successor of RFC 4996. It fixes a
technical issue with the SACK compression and clarifies other technical issue with the SACK compression and clarifies other
compression methods used. compression methods used.
3.7. Defending Spoofing and Flooding Attacks 3.8. Defending Spoofing and Flooding Attacks
By default, TCP lacks any cryptographic structures to differentiate By default, TCP lacks any cryptographic structures to differentiate
legitimate segments and those spoofed from malicious hosts. Spoofing legitimate segments and those spoofed from malicious hosts. Spoofing
valid segments requires correctly guessing a number of fields. The valid segments requires correctly guessing a number of fields. The
documents in this sub-section describe ways to make that guessing documents in this sub-section describe ways to make that guessing
harder, or to prevent it from being able to affect a connection harder, or to prevent it from being able to affect a connection
negatively. negatively.
RFC 4953 I: "Defending TCP Against Spoofing Attacks" (July 2007) RFC 4953 I: "Defending TCP Against Spoofing Attacks" (July 2007)
This document [RFC4953] discusses the recently increased This document [RFC4953] discusses the recently increased
vulnerability of long-lived TCP connections, such as BGP vulnerability of long-lived TCP connections, such as BGP
connections, to resets (RSTs) spoofing attacks. The document connections, to reset (RST) spoofing attacks. The document
analyses the vulnerability, discussing proposed solutions at the analyzes the vulnerability, discussing proposed solutions at the
transport level and their inherent challenges, as well as existing transport level and their inherent challenges, as well as existing
network level solutions and the feasibility of their deployment. network level solutions and the feasibility of their deployment.
RFC 5461 I: "TCP's Reaction to Soft Errors" (February 2009) RFC 5461 I: "TCP's Reaction to Soft Errors" (February 2009)
This document [RFC5461] describes a non-standard but widely This document [RFC5461] describes a non-standard but widely
implemented modification to TCP's handling of ICMP soft error implemented modification to TCP's handling of ICMP soft error
messages that rejects pending connection-requests when such error messages that rejects pending connection-requests when such error
messages are received. This behavior reduces the likelihood of messages are received. This behavior reduces the likelihood of
long delays between connection-establishment attempts that may long delays between connection-establishment attempts that may
arise in some scenarios. arise in some scenarios.
RFC 4987 I: "TCP SYN Flooding Attacks and Common Mitigations" (August RFC 4987 I: "TCP SYN Flooding Attacks and Common Mitigations" (August
2007) 2007)
This document [RFC4987] describes the well-known TCP SYN flooding This document [RFC4987] describes the well-known TCP SYN flooding
attack. It analyses and discusses various countermeasures against attack. It analyzes and discusses various countermeasures against
these attacks, including their use and trade-offs. these attacks, including their use and trade-offs.
RFC 5925 S: "The TCP Authentication Option" (May 2010) RFC 5925 S: "The TCP Authentication Option" (May 2010)
This document [RFC5925] describes the TCP Authentication Option This document [RFC5925] describes the TCP Authentication Option
(TCP-AO), which is used to authenticate TCP segments. TCP-AO (TCP-AO), which is used to authenticate TCP segments. TCP-AO
obsoletes the TCP MD5 Signature option of RFC 2385. It supports obsoletes the TCP MD5 Signature option of RFC 2385. It supports
the use of stronger hash functions, protects against replays for the use of stronger hash functions, protects against replays for
long-lived TCP connections (as used, e.g., in BGP and LDP), long-lived TCP connections (as used, e.g., in BGP and LDP),
coordinates key exchanges between endpoints, and provides a more coordinates key exchanges between endpoints, and provides a more
skipping to change at page 15, line 29 skipping to change at page 16, line 38
the Transmission Control Protocol (TCP). Additionally, this the Transmission Control Protocol (TCP). Additionally, this
document describes a number of widely implemented modifications to document describes a number of widely implemented modifications to
TCP's handling of ICMP error messages that help to mitigate these TCP's handling of ICMP error messages that help to mitigate these
issues." [RFC5927] issues." [RFC5927]
RFC 5961 S: "Improving TCP's Robustness to Blind In-Window Attacks" RFC 5961 S: "Improving TCP's Robustness to Blind In-Window Attacks"
(August 2010) (August 2010)
This document [RFC5961] describes minor modifications to how TCP This document [RFC5961] describes minor modifications to how TCP
handles inbound segments. This renders TCP connections, handles inbound segments. This renders TCP connections,
especially long-lived connections such as H-323 or BGP, are less especially long-lived connections such as H-323 or BGP, less
vulnerable to spoofed packet injection attacks where the 4-tuple vulnerable to spoofed packet injection attacks where the 4-tuple
(the source and destination IP addresses and the source and (the source and destination IP addresses and the source and
destination ports) has been guessed. destination ports) has been guessed.
RFC 6528 S: "Defending Against Sequence Number Attacks" (February RFC 6528 S: "Defending Against Sequence Number Attacks" (February
2012) 2012)
Abstract: "This document [RFC6528] specifies an algorithm for the Abstract: "This document [RFC6528] specifies an algorithm for the
generation of TCP Initial Sequence Numbers (ISNs), such that the generation of TCP Initial Sequence Numbers (ISNs), such that the
chances of an off-path attacker guessing the sequence numbers in chances of an off-path attacker guessing the sequence numbers in
skipping to change at page 16, line 5 skipping to change at page 17, line 12
algorithm originally proposed in that document to Standards Track, algorithm originally proposed in that document to Standards Track,
formally updating RFC 793. formally updating RFC 793.
4. Experimental Extensions 4. Experimental Extensions
The RFCs in this section are still experimental, but they may become The RFCs in this section are still experimental, but they may become
proposed standards in the future. At least part of the reason that proposed standards in the future. At least part of the reason that
they are still experimental is to gain more wide-scale experience they are still experimental is to gain more wide-scale experience
with them before a standards track decision is made. with them before a standards track decision is made.
At this point is worth mentioning that if the experimatal RFC is a At this point is worth mentioning that if the experimental RFC is a
proposal for a new protocol capability or service, i.e., it requires proposal for a new protocol capability or service, i.e., it requires
a new TCP option codepoint, the implemenation and experimentation a new TCP option code point, the implementation and experimentation
should follows (see Section 5), which describes how the experimental should follows [RFC6994] (see Section 5), which describes how the
TCP option codepoints can concurrently support multiple TCP experimental TCP option code points can concurrently support multiple
extensions. TCP extensions.
By their publication as experimental RFCs, it is hoped that the By their publication as experimental RFCs, it is hoped that the
community of TCP researchers will analyze and test the contents of community of TCP researchers will analyze and test the contents of
these RFCs. Although experimentation is encouraged, there is not yet these RFCs. Although experimentation is encouraged, there is not yet
formal consensus that these are fully logical and safe behaviors. formal consensus that these are fully logical and safe behaviors.
Wide-scale deployment of implementations that use these features Wide-scale deployment of implementations that use these features
should be well thought-out in terms of consequences. should be well thought-out in terms of consequences.
4.1. Architectural Guidelines 4.1. Architectural Guidelines
skipping to change at page 16, line 43 skipping to change at page 17, line 50
cache. Although this RFC is technically informational, the cache. Although this RFC is technically informational, the
concepts it describes are in experimental use, so we include it in concepts it describes are in experimental use, so we include it in
this section. this section.
RFC 3124 S: "The Congestion Manager" (June 2001) RFC 3124 S: "The Congestion Manager" (June 2001)
This document [RFC3124], the Congestion Manager, is a related This document [RFC3124], the Congestion Manager, is a related
proposal to RFC 2140. The idea behind the Congestion Manager, proposal to RFC 2140. The idea behind the Congestion Manager,
moving congestion control outside of individual TCP connections, moving congestion control outside of individual TCP connections,
represents a modification to the core of TCP, which supports represents a modification to the core of TCP, which supports
sharing information among TCP connections as well. Although a sharing information among TCP connections. Although a Proposed
Proposed Standard, some pieces of the Congestion Manager support Standard, some pieces of the Congestion Manager support
architecture have not been specified yet, and it has not achieved architecture have not been specified yet, and it has not achieved
use or implementation beyond experimental stacks, so it is not use or implementation beyond experimental stacks, so it is not
listed among the standard TCP enhancements in this roadmap. listed among the standard TCP enhancements in this roadmap.
4.2. Congestion Control and Loss Recovery Extensions 4.2. Congestion Control Extensions
TCP congestion control has been an extremely active research area for TCP congestion control has been an extremely active research area for
many years, as it determines the performance of many applications many years (see [RFC5783], as it determines the performance of many
that use TCP. A number of experimental RFCs address issues with flow applications that use TCP. A number of experimental RFCs address
startup, overshoot, and steady-state behavior in the basic RFC 5681 issues with flow start-up, overshoot, and steady-state behavior in
algorithms. the basic RFC 5681 algorithms. In this sub-sections, enhancements to
TCP's congestion control are listed. The next sub-section focus on
TCP's loss recovery.
RFC 2861 E: "TCP Congestion Window Validation" (June 2000) RFC 2861 E: "TCP Congestion Window Validation" (June 2000)
This document [RFC2861] suggests reducing the congestion window This document [RFC2861] suggests reducing the congestion window
over time when no packets are flowing. This behavior is more over time when no packets are flowing. This behavior is more
aggressive than that specified in RFC 5681, which says that a TCP aggressive than that specified in RFC 5681, which says that a TCP
sender SHOULD set its congestion window to the initial window sender SHOULD set its congestion window to the initial window
after an idle period of an RTO or greater. after an idle period of an RTO or greater.
RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling
skipping to change at page 18, line 24 skipping to change at page 19, line 27
RFC 5690 I: "Adding Acknowledgement Congestion Control to TCP" RFC 5690 I: "Adding Acknowledgement Congestion Control to TCP"
(February 2010) (February 2010)
This document [RFC5690] describes a congestion control mechanism This document [RFC5690] describes a congestion control mechanism
for acknowledgment (ACKs) traffic in TCP. The mechanism is based for acknowledgment (ACKs) traffic in TCP. The mechanism is based
on the acknowledgment congestion control of the Datagram on the acknowledgment congestion control of the Datagram
Congestion Control Protocol's (DCCP's) [RFC4340] Congestion Congestion Control Protocol's (DCCP's) [RFC4340] Congestion
Control Identifier (CCID) 2 [RFC4341]. Control Identifier (CCID) 2 [RFC4341].
RFC 6928 E: "Increasing TCP's Initial Window" (April 2013)
This document [RFC6928] proposes to increase the TCP initial
window from between 2 and 4 segments, as specified in RFC 3390, to
10 segments with a fallback to the existing recommendation when
performance issues are detected.
4.3. Loss Recovery Extensions
RFC 5827 E: "Early Retransmit for TCP and SCTP" (April 2010) RFC 5827 E: "Early Retransmit for TCP and SCTP" (April 2010)
This document [RFC5827] proposes the "Early Retransmit" mechanism This document [RFC5827] proposes the "Early Retransmit" mechanism
for TCP (and SCTP) that can be used to recover lost segments when for TCP (and SCTP) that can be used to recover lost segments when
a connection's congestion window is small. In certain special a connection's congestion window is small. In certain special
circumstances, Early Retransmit reduces the number of duplicate circumstances, Early Retransmit reduces the number of duplicate
acknowledgments required to trigger fast retransmit to recover acknowledgments required to trigger fast retransmit to recover
segment losses without waiting for a lengthy retransmission segment losses without waiting for a lengthy retransmission
timeout. timeout.
RFC 6069 E: "Making TCP more Robust to Long Connectivity Disruptions RFC 6069 E: "Making TCP more Robust to Long Connectivity Disruptions
(TCP-LCD)" (December 2010) (TCP-LCD)" (December 2010)
This document [RFC6069] describes how standard ICMP messages can This document [RFC6069] describes how standard ICMP messages can
be used to disambiguate true congestion loss from non-congestion be used to disambiguate true congestion loss from non-congestion
loss caused by connectivity disruptions. It proposes a reversion loss caused by connectivity disruptions. It proposes a reversion
strategy of TCP's retransmission timer that enables a more prompt strategy of TCP's retransmission timer that enables a more prompt
detection of whether or not the connectivity has been restored. detection of whether or not the connectivity has been restored.
RFC 6928 E: "Increasing TCP's Initial Window" (April 2013)
This document [RFC6928] proposes to increase the TCP initial
window from between 2 and 4 segments, as specified in RFC 3390, to
10 segments with a fallback to the existing recommendation when
performance issues are detected.
RFC 6937 E: "Proportional Rate Reduction for TCP" (May 2013) RFC 6937 E: "Proportional Rate Reduction for TCP" (May 2013)
This document [RFC6937] describes an experimental Proportional This document [RFC6937] describes an experimental Proportional
Rate Reduction (PRR) algorithm as an alternative to the widely Rate Reduction (PRR) algorithm as an alternative to the widely
deployed Fast Recovery algorithm, to improve the accuracy of the deployed Fast Recovery algorithm, to improve the accuracy of the
amount of data sent by TCP during loss recovery. amount of data sent by TCP during loss recovery.
4.3. Detection and Prevention of Spurious Retransmissions 4.4. Detection and Prevention of Spurious Retransmissions
In addition to the Standards Track extensions to deal with spurious In addition to the Standards Track extensions to deal with spurious
retransmissions in Section 3.4, Experimental proposals have also been retransmissions in Section 3.4, Experimental proposals have also been
documented. documented.
RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003) RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003)
The Eifel detection algorithm [RFC3522] allows a TCP sender to The Eifel detection algorithm [RFC3522] allows a TCP sender to
detect a posteriori whether it has entered loss recovery detect a posteriori whether it has entered loss recovery
unnecessarily by using the TCP timestamp option to solve the ACK unnecessarily by using the TCP timestamp option to solve the ACK
skipping to change at page 20, line 5 skipping to change at page 21, line 5
Events" (August 2008) Events" (August 2008)
In the presence of non-congestion events, such as reordering an In the presence of non-congestion events, such as reordering an
out-of-order segment does not necessarily indicates a lost segment out-of-order segment does not necessarily indicates a lost segment
and congestion. This document [RFC4653] proposes to increase the and congestion. This document [RFC4653] proposes to increase the
threshold used to trigger a fast retransmission from the fixed threshold used to trigger a fast retransmission from the fixed
value of three duplicate ACKs to about one congestion window of value of three duplicate ACKs to about one congestion window of
data in order to disambiguate true segment loss from segment data in order to disambiguate true segment loss from segment
reordering. reordering.
4.4. Multipath TCP 4.5. Multipath TCP
MultiPath TCP (MPTCP) is an ongoing effort within the IETF that MultiPath TCP (MPTCP) is an ongoing effort within the IETF that
allows a TCP connection to simultaneous use multiple IP-addresses/ allows a TCP connection to simultaneously use multiple IP-addresses/
interfaces to spread their data across several subflows, while interfaces to spread their data across several subflows, while
presenting a regular TCP interface to applications. Benefits of this presenting a regular TCP interface to applications. Benefits of this
include better resource utilization, better throughput and smoother include better resource utilization, better throughput and smoother
reaction to failures. The documents listed in this section specify reaction to failures. The documents listed in this section specify
the Multipath TCP scheme, while the documents in Sections 7.4, 7.2 the Multipath TCP scheme, while the documents in Sections 7.2, 7.4,
and 7.5 provide some additinal background information. and 7.5 provide some additional background information.
RFC 6356 E: "Coupled Congestion Control for Multipath Transport RFC 6356 E: "Coupled Congestion Control for Multipath Transport
Protocols" (August 2011) Protocols" (August 2011)
This document [RFC6356] presents a congestion control algorithm This document [RFC6356] presents a congestion control algorithm
for multipath transport protocols such as Multipath TCP. It for multipath transport protocols such as Multipath TCP. It
couples the congestion control algorithms running on different couples the congestion control algorithms running on different
subflows by linking their increase functions, and dynamically subflows by linking their increase functions, and dynamically
controls the overall aggressiveness of the multipath flow. The controls the overall aggressiveness of the multipath flow. The
result is an algorithm that is fair to TCP at bottlenecks while result is an algorithm that is fair to TCP at bottlenecks while
skipping to change at page 21, line 24 skipping to change at page 22, line 24
Number Registry (August 2011) Number Registry (August 2011)
From abstract: "This document defines the procedures that the From abstract: "This document defines the procedures that the
Internet Assigned Numbers Authority (IANA) uses when handling Internet Assigned Numbers Authority (IANA) uses when handling
assignment and other requests related to the Service Name and assignment and other requests related to the Service Name and
Transport Protocol Port Number registry." [RFC6335] Transport Protocol Port Number registry." [RFC6335]
RFC 6994 S: "Shared Use of Experimental TCP Options (August 2013) RFC 6994 S: "Shared Use of Experimental TCP Options (August 2013)
This document [RFC6994] describes how the experimental TCP option This document [RFC6994] describes how the experimental TCP option
codepoints can concurrently support multiple TCP extensions, even code points can concurrently support multiple TCP extensions, even
within the same connection. It creates an IANA registry for within the same connection. It creates an IANA registry for
extensions to the experimental codepoints. extensions to the experimental code points.
6. Historic and Undeployed Extensions 6. Historic and Undeployed Extensions
The RFCs listed here define extensions that have thus far failed to The RFCs listed here define extensions that have thus far failed to
arouse substantial interest from implementers and have never seen arouse substantial interest from implementers and have never seen
widespread, or were found to be defective for general use. Most of widespread deployment, or were found to be defective for general use.
them are reclassifies by RFC 6247 [RFC6247] to Historic status. Most of them are reclassified by RFC 6247 [RFC6247] to Historic
status.
RFC 721 U: "Out-of-Band Control Signals in a Host-to-Host Protocol" RFC 721 U: "Out-of-Band Control Signals in a Host-to-Host Protocol"
(September 1976): lack of interest (September 1976): lack of interest
RFC 721 [RFC0721] addresses the problem of implementing a reliable RFC 721 [RFC0721] addresses the problem of implementing a reliable
out-of-band signal (interrupts) for use in a host-to-host out-of-band signal (interrupts) for use in a host-to-host
protocol. The proposal has not been included in the final TCP protocol. The proposal was not included in the final TCP
specification. specification.
RFC 1078 U: "TCP Port Service Multiplexer (TCPMUX)" (November 1988): RFC 1078 U: "TCP Port Service Multiplexer (TCPMUX)" (November 1988):
lack of interest lack of interest
This document [RFC1078] propose a protocol to contact multiple This document [RFC1078] proposes a protocol to contact multiple
services on a single well-known TCP port using a service name services on a single well-known TCP port using a service name
instead of a well-known number. instead of a well-known number.
RFC 1106 H: "TCP Big Window and NAK Options" (June 1989): found RFC 1106 H: "TCP Big Window and NAK Options" (June 1989): found
defective defective
This RFC [RFC1106] defined an alternative to the Window Scale This RFC [RFC1106] defined an alternative to the Window Scale
option for using large windows and described the "negative option for using large windows and described the "negative
acknowledgement" or NAK option. There is a comparison of NAK and acknowledgment" or NAK option. There is a comparison of NAK and
SACK methods, and early discussion of TCP over satellite issues. SACK methods, and early discussion of TCP over satellite issues.
RFC 1110 explains some problems with the approaches described in RFC 1110 explains some problems with the approaches described in
RFC 1106. The options described in this document have not been RFC 1106. The options described in this document have not been
adopted by the larger community, although NAKs are used in the adopted by the larger community, although NAKs are used in the
SCPS-TP adaptation of TCP for satellite and spacecraft use, SCPS-TP adaptation of TCP for satellite and spacecraft use,
developed by the Consultative Committee for Space Data Systems developed by the Consultative Committee for Space Data Systems
(CCSDS). (CCSDS).
RFC 1110 H: "A Problem with the TCP Big Window Option" (August 1989): RFC 1110 H: "A Problem with the TCP Big Window Option" (August 1989):
deprecates RFC 1106 deprecates RFC 1106
skipping to change at page 23, line 38 skipping to change at page 24, line 38
possible performance loss because of TCP's strict ordering or they possible performance loss because of TCP's strict ordering or they
use more specialized transport protocols. use more specialized transport protocols.
RFC 1705 I: "Six Virtual Inches to the Left: The Problem with IPng" RFC 1705 I: "Six Virtual Inches to the Left: The Problem with IPng"
(October 1994): lack of interest (October 1994): lack of interest
To overcome the exhaustion of the IP class B address space, To overcome the exhaustion of the IP class B address space,
suggest this document [RFC1705] that a new version of TCP (TCPng) suggest this document [RFC1705] that a new version of TCP (TCPng)
needs to be developed and deployed. It proposes that a globally needs to be developed and deployed. It proposes that a globally
unique address be assigned to Transport layer to uniquely identify unique address be assigned to Transport layer to uniquely identify
an internet host without specifying any routing information. an Internet host without specifying any routing information.
RFC 6013 E: "TCP Cookie Transactions (TCPCT)" (January 2011): lack of RFC 6013 E: "TCP Cookie Transactions (TCPCT)" (January 2011): lack of
interest interest
This document [RFC6013] describes a method to exchange a cookie This document [RFC6013] describes a method to exchange a cookie
(nonce) during the connection establishment to negotiates (nonce) during the connection establishment to negotiate
elimination of receiver state. These cookies are later used to elimination of receiver state. These cookies are later used to
inhibit premature closing of connections, and reduce retention of inhibit premature closing of connections, and reduce retention of
state after the connection has terminated. state after the connection has terminated.
Since the cookie pair is too large to fit with the other TCP Since the cookie pair is too large to fit with the other TCP
options in the 40 bytes of TCP option space, the document further options in the 40 bytes of TCP option space, the document further
describes method to extent the option space after the connection describes a method to extent the option space after the connection
establishment. establishment.
Although the RFC 6013 is publish in 2011, the authors of this Although RFC 6013 was published in 2011, the authors of this
document places it in this section of the roadmap document due to document places it in this section of the roadmap document due to
two factors. two factors.
(a) The authors are not aware of any wide deployment and use of (a) The authors are not aware of any wide deployment and use of
RFC 6013. RFC 6013.
(b) RFC 6013 uses experimental TCP option codepoints, which (b) RFC 6013 uses experimental TCP option codepoints, which
prohibits a large scale deployment. prohibits a large scale deployment.
7. Support Documents 7. Support Documents
This section contains several classes of documents that do not This section contains several classes of documents that do not
necessarily define current protocol behaviors, but that are necessarily define current protocol behaviors, but that are
nevertheless of interest to TCP implementers. Section 7.1 describes nevertheless of interest to TCP implementers. Section 7.1 describes
several foundational RFCs that give modern readers a better several foundational RFCs that give modern readers a better
understanding of the principles underlying TCP's behaviors and understanding of the principles underlying TCP's behaviors and
development over the years. Section 7.2 contains architectural development over the years. Section 7.2 contains architectural
guidelines and principles for TCP architects and designers. The guidelines and principles for TCP architects and designers. The
documents listed in Section 7.3 provide advice on using TCP in documents listed in Section 7.3 provide advice on using TCP in
various types of network situations that pose challenges above those various types of network situations that pose challenges above those
of typical wired links. Guidance for developing, analyzing, and of typical wired links. Guidance for developing, analyzing, and
evaluating TCP is given in Section 7.4. Some implementation notes evaluating TCP is given in Section 7.4. Some implementation notes
and implementation advices can be found in Section 7.5. The TCP and implementation advice can be found in Section 7.5. RFCs that
Management Information Bases are described in Section 7.6. RFCs that
describe tools for testing and debugging TCP implementations or that describe tools for testing and debugging TCP implementations or that
contain high-level tutorials on the protocol are listed Section 7.7, contain high-level tutorials on the protocol are listed Section 7.6.
The TCP Management Information Bases are described in Section 7.7,
and Section 7.8 lists a number of case studies that have explored TCP and Section 7.8 lists a number of case studies that have explored TCP
performance. performance.
7.1. Foundational Works 7.1. Foundational Works
The documents listed in this section contain information that is The documents listed in this section contain information that is
largely duplicated by the standards documents previously discussed. largely duplicated by the standards documents previously discussed.
However, some of them contain a greater depth of problem statement However, some of them contain a greater depth of problem statement
explanation or other context. Particularly, RFCs 813 - 817 (known as explanation or other context. Particularly, RFCs 813 - 817 (known as
the "Dave Clark Five") describe some early problems and solutions the "Dave Clark Five") describe some early problems and solutions
(RFC 815 only describes the reassembly of IP fragments and is not (RFC 815 only describes the reassembly of IP fragments and is not
included in this TCP roadmap). included in this TCP roadmap).
RFC 675 U: "Specification of Internet Transmission Control Program" RFC 675 U: "Specification of Internet Transmission Control Program"
(December 1974) (December 1974)
This document [RFC0675] is a very early precursor of the infamous This document [RFC0675] is a very early precursor of the
RFC 793 which already contained the three-way handshake in its fundamental RFC 793 which already contained the three-way
final form and the concept of sliding windows for reliable data handshake in its final form and the concept of sliding windows for
transmission. Apart from that the segment layout is totally reliable data transmission. Apart from that the segment layout is
different and the specified API differs from the latter RFC 793. totally different and the specified API differs from the latter
RFC 793.
RFC 761 H: "DoD standard Transmission Control Protocol" (Januar RFC 761 H: "DoD standard Transmission Control Protocol" (Januar
1980) 1980)
This document [RFC0761] is the immediate predecessor of RFC 793. This document [RFC0761] is the immediate precursor of RFC 793.
The header format, the connection establishment including the The header format, the connection establishment including the
different connection states, and the overall API correspond mostly different connection states, and the overall API correspond mostly
the final Standard RFC 793. the final Standard RFC 793.
RFC 813 U: "Window and Acknowledgement Strategy in TCP" (July 1982) RFC 813 U: "Window and Acknowledgement Strategy in TCP" (July 1982)
This document [RFC0813] contains an early discussion of Silly This document [RFC0813] contains an early discussion of Silly
Window Syndrome and its avoidance and motivates and describes the Window Syndrome and its avoidance and motivates and describes the
use of delayed acknowledgments. use of delayed acknowledgments.
skipping to change at page 26, line 38 skipping to change at page 27, line 38
RFC 2914 B: "Congestion Control Principles" (September 2000) RFC 2914 B: "Congestion Control Principles" (September 2000)
This document [RFC2914] motivates the use of end-to-end congestion This document [RFC2914] motivates the use of end-to-end congestion
control for preventing congestion collapse and providing fairness control for preventing congestion collapse and providing fairness
to TCP. to TCP.
RFC 3439 I: "Some Internet Architectural Guidelines and Philosophy" RFC 3439 I: "Some Internet Architectural Guidelines and Philosophy"
(December 2002) (December 2002)
This document [RFC3439] extents RFC 1958 by outlining some This document [RFC3439] extends RFC 1958 by outlining some
philosophical guidelines for architects and designers of Internet philosophical guidelines for architects and designers of Internet
backbone networks. The document describes the Simplicity backbone networks. The document describes the Simplicity
Principle, which states that complexity is the primary mechanism Principle, which states that complexity is the primary mechanism
that impedes efficient scaling. that impedes efficient scaling.
RFC 6182 I: "Architectural Guidelines for Multipath TCP Development" RFC 6182 I: "Architectural Guidelines for Multipath TCP Development"
(March 2011) (March 2011)
Abstract: "This document outlines architectural guidelines for the Abstract: "This document outlines architectural guidelines for the
development of a Multipath Transport Protocol, with references to development of a Multipath Transport Protocol, with references to
skipping to change at page 30, line 11 skipping to change at page 31, line 11
This document [RFC5033] considers the evaluation of suggested This document [RFC5033] considers the evaluation of suggested
congestion control algorithms that differ from the principles congestion control algorithms that differ from the principles
outlined in RFC 2914. It is useful for authors of such algorithms outlined in RFC 2914. It is useful for authors of such algorithms
as well as for IETF members reviewing the associated documents. as well as for IETF members reviewing the associated documents.
RFC 5166 I: "Metrics for the Evaluation of Congestion Control RFC 5166 I: "Metrics for the Evaluation of Congestion Control
Mechanisms" (March 2008) Mechanisms" (March 2008)
This document [RFC5166] discusses metrics that needs to be This document [RFC5166] discusses metrics that needs to be
considered when evaluating new or modified congestion control considered when evaluating new or modified congestion control
mechanisms for the Internet. Among others, the document discusses mechanisms for the Internet. Among others topics, the document
throughput, delay, loss rates, response times, fairness and discusses throughput, delay, loss rates, response times, fairness
robustness for challenging environments. and robustness for challenging environments.
RFC 6077 I: "Open Research Issues in Internet Congestion Control"
(January 2011)
This RFC [RFC6077] summarizes the main open problems in the domain
of Internet congestion control. As a good starting point for
newcomers, the document describes several new challenges that are
becoming important as the network grows, as well as some issues
that have been known for many years.
RFC 6181 I: "Threat Analysis for TCP Extensions for Multipath RFC 6181 I: "Threat Analysis for TCP Extensions for Multipath
Operation with Multiple Addresses" (March 2011) Operation with Multiple Addresses" (March 2011)
This document [RFC6181] describes a threat analysis for Multipath This document [RFC6181] describes a threat analysis for Multipath
TCP (MPTCP). The document discusses several types of attacks and TCP (MPTCP). The document discusses several types of attacks and
provides recommendations for MPTCP designers how to create an provides recommendations for MPTCP designers how to create an
MPTCP specification that is as secure as the current (single-path) MPTCP specification that is as secure as the current (single-path)
TCP. TCP.
skipping to change at page 31, line 35 skipping to change at page 32, line 44
From abstract: "This memo catalogs a number of known TCP From abstract: "This memo catalogs a number of known TCP
implementation problems. The goal in doing so is to improve implementation problems. The goal in doing so is to improve
conditions in the existing Internet by enhancing the quality of conditions in the existing Internet by enhancing the quality of
current TCP/IP implementations." [RFC2525] current TCP/IP implementations." [RFC2525]
RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000) RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000)
From abstract: "This memo catalogs several known Transmission From abstract: "This memo catalogs several known Transmission
Control Protocol (TCP) implementation problems dealing with Path Control Protocol (TCP) implementation problems dealing with Path
Maximum Transmission Unit Discovery (PMTUD), including the long- Maximum Transmission Unit Discovery (PMTUD), including the long-
standing black hole problem, stretch acknowlegements (ACKs) due to standing black hole problem, stretch acknowledgments (ACKs) due to
confusion between Maximum Segment Size (MSS) and segment size, and confusion between Maximum Segment Size (MSS) and segment size, and
MSS advertisement based on PMTU." [RFC2923] MSS advertisement based on PMTU." [RFC2923]
RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August
2002) 2002)
This document [RFC3360] is a plea that firewall vendors not send This document [RFC3360] is a plea that firewall vendors not send
gratuitous TCP RST (Reset) packets when unassigned TCP header bits gratuitous TCP RST (Reset) packets when unassigned TCP header bits
are used. This practice prevents desirable extension and are used. This practice prevents desirable extension and
evolution of the protocol and thus is potentially harmful to the evolution of the protocol and thus is potentially harmful to the
skipping to change at page 32, line 40 skipping to change at page 34, line 5
RFC 6897 I: "Multipath TCP (MPTCP) Application Interface RFC 6897 I: "Multipath TCP (MPTCP) Application Interface
Considerations" (March 2013) Considerations" (March 2013)
This document [RFC6897] characterizes the impact that Multipath This document [RFC6897] characterizes the impact that Multipath
TCP (MPTCP) may have on applications. It further discusses TCP (MPTCP) may have on applications. It further discusses
compatibility issues of MPTCP in combination with non-MPTCP-aware compatibility issues of MPTCP in combination with non-MPTCP-aware
applications. Finally, it describes a basic API that is a simple applications. Finally, it describes a basic API that is a simple
extension of TCP's interface for MPTCP-aware applications. extension of TCP's interface for MPTCP-aware applications.
7.6. Management Information Bases 7.6. Tools and Tutorials
RFC 1180 I: "TCP/IP Tutorial" (January 1991) (Errata)
This document [RFC1180] is an extremely brief overview of the
TCP/IP protocol suite as a whole. It gives some explanation as to
how and where TCP fits in.
RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for
Monitoring and Debugging TCP/IP Internets and Interconnected Devices"
(June 1993)
A few of the tools that this document [RFC1470] describes are
still maintained and in use today; for example, ttcp and tcpdump.
However, many of the tools described do not relate specifically to
TCP and are no longer used or easily available.
RFC 2398 I: "Some Testing Tools for TCP Implementors" (August 1998)
This document [RFC2398] describes a number of TCP packet
generation and analysis tools. Although some of these tools are
no longer readily available or widely used, for the most part they
are still relevant and usable.
RFC 5783 I: "Congestion Control in the RFC Series" (February 2010)
This document [RFC5783] provides an overview of RFCs related to
congestion control that have been published so far. The focus of
the document is on end-host-based congestion control.
7.7. Management Information Bases
The first MIB module defined for use with Simple Network Management The first MIB module defined for use with Simple Network Management
Protocol (SNMP) (in RFC 1066 and its update, RFC 1156) was a single Protocol (SNMP) (in RFC 1066 and its update, RFC 1156) was a single
monolithic MIB module, called MIB-I. This evolved over time to be monolithic MIB module, called MIB-I. This evolved over time to be
MIB-II (RFC 1213). It then became apparent that having a single MIB-II (RFC 1213). It then became apparent that having a single
monolithic MIB module was not scalable, given the number and breadth monolithic MIB module was not scalable, given the number and breadth
of MIB data definitions that needed to be included. Thus, additional of MIB data definitions that needed to be included. Thus, additional
MIB modules were defined, and those parts of MIB-II that needed to MIB modules were defined, and those parts of MIB-II that needed to
evolve were split off. Eventually, the remaining parts of MIB-II evolve were split off. Eventually, the remaining parts of MIB-II
were also split off, the TCP-specific part being documented in RFC were also split off, the TCP-specific part being documented in RFC
skipping to change at page 34, line 12 skipping to change at page 36, line 5
generic structure for both IPv4 and IPv6. This will aid in generic structure for both IPv4 and IPv6. This will aid in
definition, implementation, and transition between IPv4 and IPv6. definition, implementation, and transition between IPv4 and IPv6.
RFC 4022 S: "Management Information Base for the Transmission Control RFC 4022 S: "Management Information Base for the Transmission Control
Protocol (TCP)" (March 2005) Protocol (TCP)" (March 2005)
This document [RFC4022] obsoletes RFC 2012 and RFC 2452 and This document [RFC4022] obsoletes RFC 2012 and RFC 2452 and
specifies the current standard for the TCP MIB that should be specifies the current standard for the TCP MIB that should be
deployed. deployed.
7.7. Tools and Tutorials
RFC 1180 I: "TCP/IP Tutorial" (January 1991) (Errata)
This document [RFC1180] is an extremely brief overview of the
TCP/IP protocol suite as a whole. It gives some explanation as to
how and where TCP fits in.
RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for
Monitoring and Debugging TCP/IP Internets and Interconnected Devices"
(June 1993)
A few of the tools that this document [RFC1470] describes are
still maintained and in use today; for example, ttcp and tcpdump.
However, many of the tools described do not relate specifically to
TCP and are no longer used or easily available.
RFC 2398 I: "Some Testing Tools for TCP Implementors" (August 1998)
This document [RFC2398] describes a number of TCP packet
generation and analysis tools. Although some of these tools are
no longer readily available or widely used, for the most part they
are still relevant and useable.
RFC 4614 I: "A Roadmap for Transmission Control Protocol (TCP)
Specification Documents" (September 2006)
RFC 4614 [RFC4614] is the precursor of this document.
RFC 5783 I: "Congestion Control in the RFC Series" (February 2010)
This document [RFC5783] provides an overview of RFCs related to
congestion control that have been published so far. The focus of
the document are on end-host-based congestion control.
RFC 6077 I: "Open Research Issues in Internet Congestion Control"
(January 2011)
This RFC [RFC6077] summarizes the main open problems in the domain
of Internet congestion control. As a good starting point for
newcomers, the document describes several new challenges that are
becoming important as the network grows, as well as some issues
that have been known for many years.
7.8. Case Studies 7.8. Case Studies
RFC 700 U: "A Protocol Experiment" (August 1974) RFC 700 U: "A Protocol Experiment" (August 1974)
This document [RFC0700] presents a field report about the This document [RFC0700] presents a field report about the
deployment of a very early version of TCP, the so-called INWN #39 deployment of a very early version of TCP, the so-called INWN #39
protocol, which is originally described by Cerf and Kahn in INWG protocol, which is originally described by Cerf and Kahn in INWG
Note #39 [CK73] to use a PDP-11 line printer via the ARPANET. Note #39 [CK73] to use a PDP-11 line printer via the ARPANET.
RFC 889 U: "Internet Delay Experiments" (December 1983) RFC 889 U: "Internet Delay Experiments" (December 1983)
This document [RFC0889] is a status report about experiments This document [RFC0889] is a status report about experiments
concerning the TCP retransmission timeout calculation and also concerning the TCP retransmission timeout calculation and also
provides advices for implementers. provides advices for implementers.
RFC 1337 I: "TIME-WAIT Assassination Hazardsin TCP" (May 1992) RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 1992)
This document [RFC1337] points out a problem with acting on This document [RFC1337] points out a problem with acting on
received reset segments while one is in the TIME-WAIT state. The received reset segments while one is in the TIME-WAIT state. The
main recommendation is that hosts in TIME-WAIT ignore resets. main recommendation is that hosts in TIME-WAIT ignore resets.
This recommendation might not currently be widely implemented. This recommendation might not currently be widely implemented.
RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size" RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size"
(September 1998) (September 1998)
This document [RFC2415] presents results of some simulations using This document [RFC2415] presents results of some simulations using
skipping to change at page 37, line 7 skipping to change at page 38, line 7
handle another packet the same size as the current one. If not, handle another packet the same size as the current one. If not,
set one of the unused flag bits in your header prediction to set one of the unused flag bits in your header prediction to
guarantee that the prediction will fail on the next packet and guarantee that the prediction will fail on the next packet and
force you to go through full protocol processing. Otherwise, force you to go through full protocol processing. Otherwise,
you're done with this packet. So, the *total* tcp protocol you're done with this packet. So, the *total* tcp protocol
processing, exclusive of checksumming, is on the order of 6 processing, exclusive of checksumming, is on the order of 6
compares and an add." compares and an add."
Forward Acknowledgement (FACK) Forward Acknowledgement (FACK)
FACK [MM96] describes an alternate algorithm for triggering fast FACK [MM96] includes an alternate algorithm for triggering fast
retransmit, based on the extent of the SACK scoreboard. Its goal retransmit, based on the extent of the SACK scoreboard. Its goal
is to trigger fast retransmit as soon as the receiver's reassembly is to trigger fast retransmit as soon as the receiver's reassembly
queue is larger than the DUPACK threshold, as indicated by the queue is larger than the DUPACK threshold, as indicated by the
difference between the forward most SACK block edge and SND.UNA. difference between the forward most SACK block edge and SND.UNA.
This algorithm quickly and reliably triggers fast retransmit in This algorithm quickly and reliably triggers fast retransmit in
the presence of burst losses -- often on the first SACK following the presence of burst losses -- often on the first SACK following
such a loss. Such a threshold based algorithm also triggers fast such a loss. Such a threshold based algorithm also triggers fast
retransmit immediately in the presence of any reordering with retransmit immediately in the presence of any reordering with
extent greater than the DUPACK threshold. FACK is implemented in extent greater than the DUPACK threshold. FACK is implemented in
Linux and turned on per default. Linux and turned on per default.
skipping to change at page 38, line 10 skipping to change at page 39, line 10
10. IANA Considerations 10. IANA Considerations
This document contains no IANA considerations. This document contains no IANA considerations.
11. Acknowledgments 11. Acknowledgments
This document grew out of a discussion on the end2end-interest This document grew out of a discussion on the end2end-interest
mailing list, the public list of the End-to-End Research Group of the mailing list, the public list of the End-to-End Research Group of the
IRTF, and continued development under the IETF's TCP Maintenance and IRTF, and continued development under the IETF's TCP Maintenance and
Minor Extensions (TCPM) working group. We thank Joe Touch, Reiner Minor Extensions (TCPM) working group. We thank Mark Allman, Yuchung
Ludwig, Pekka Savola, Gorry Fairhurst, and Sally Floyd for their Cheng, Ted Faber, Fairhurst, Sally Floyd, Janardhan Iyengar, Reiner
contributions, in particular. The chairs of the TCPM working group, Ludwig, Pekka Savola, and Joe Touch for their contributions, in
Mark Allman and Ted Faber, have been instrumental in the development particular. Keith McCloghrie provided some useful notes and
of this document. Keith McCloghrie provided some useful notes and
clarification on the various MIB-related RFCs. clarification on the various MIB-related RFCs.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC0675] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of [RFC0675] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of
Internet Transmission Control Program", RFC 675, Internet Transmission Control Program", RFC 675,
December 1974. December 1974.
skipping to change at page 44, line 6 skipping to change at page 45, line 6
Wood, "Advice for Internet Subnetwork Designers", BCP 89, Wood, "Advice for Internet Subnetwork Designers", BCP 89,
RFC 3819, July 2004. RFC 3819, July 2004.
[RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
for TCP", RFC 4015, February 2005. for TCP", RFC 4015, February 2005.
[RFC4022] Raghunarayan, R., "Management Information Base for the [RFC4022] Raghunarayan, R., "Management Information Base for the
Transmission Control Protocol (TCP)", RFC 4022, Transmission Control Protocol (TCP)", RFC 4022,
March 2005. March 2005.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, September 2006.
[RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, [RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton,
"Improving the Robustness of TCP to Non-Congestion "Improving the Robustness of TCP to Non-Congestion
Events", RFC 4653, August 2006. Events", RFC 4653, August 2006.
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4774] Floyd, S., "Specifying Alternate Semantics for the [RFC4774] Floyd, S., "Specifying Alternate Semantics for the
Explicit Congestion Notification (ECN) Field", BCP 124, Explicit Congestion Notification (ECN) Field", BCP 124,
RFC 4774, November 2006. RFC 4774, November 2006.
skipping to change at page 49, line 10 skipping to change at page 50, line 8
Congestion Control", RFC 4341, March 2006. Congestion Control", RFC 4341, March 2006.
[SCWA99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, [SCWA99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
"TCP Congestion Control with a Misbehaving Receiver", ACM "TCP Congestion Control with a Misbehaving Receiver", ACM
Computer Communication Review, 29 (5), pp. 71-78, Computer Communication Review, 29 (5), pp. 71-78,
October 1999. October 1999.
Authors' Addresses Authors' Addresses
Martin Duke Martin Duke
>Boeing Research & Technology F5 Networks
PO Box 3707, MC 7L-49 401 Elliott Ave W
Seattle, WA 98124-2207 Seattle, WA 98119
Phone: 425-373-2852 Phone: 206-272-7537
Email: martin.duke@boeing.com Email: m.duke@f5.com
Robert Braden Robert Braden
USC Information Sciences Institute USC Information Sciences Institute
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
Phone: 310-448-9173 Phone: 310-448-9173
Email: braden@isi.edu Email: braden@isi.edu
Wesley M. Eddy Wesley M. Eddy
MTI Systems MTI Systems
 End of changes. 68 change blocks. 
260 lines changed or deleted 261 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/