draft-ietf-tcpm-tcp-rfc4614bis-07.txt   draft-ietf-tcpm-tcp-rfc4614bis-08.txt 
TCP Maintenance and Minor Extensions M. Duke TCP Maintenance and Minor Extensions M. Duke
(TCPM) WG F5 (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: January 4, 2015 MTI Systems Expires: February 13, 2015 MTI Systems
E. Blanton E. Blanton
A. Zimmermann A. Zimmermann
NetApp, Inc. NetApp, Inc.
July 3, 2014 August 12, 2014
A Roadmap for Transmission Control Protocol (TCP) Specification A Roadmap for Transmission Control Protocol (TCP) Specification
Documents Documents
draft-ietf-tcpm-tcp-rfc4614bis-07 draft-ietf-tcpm-tcp-rfc4614bis-08
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 46 skipping to change at page 1, line 46
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 January 4, 2015. This Internet-Draft will expire on February 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Core Functionality . . . . . . . . . . . . . . . . . . . . . . 5 2. Core Functionality . . . . . . . . . . . . . . . . . . . . . . 5
3. Strongly Encouraged Enhancements . . . . . . . . . . . . . . . 8 3. Strongly Encouraged Enhancements . . . . . . . . . . . . . . . 8
3.1. Fundamental Changes . . . . . . . . . . . . . . . . . . . 8 3.1. Fundamental Changes . . . . . . . . . . . . . . . . . . . 8
3.2. Congestion Control Extensions . . . . . . . . . . . . . . 9 3.2. Congestion Control Extensions . . . . . . . . . . . . . . 9
3.3. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 10 3.3. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 11
3.4. Detection and Prevention of Spurious Retransmissions . . . 12 3.4. Detection and Prevention of Spurious Retransmissions . . . 12
3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 13 3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 13
3.6. Header Compression . . . . . . . . . . . . . . . . . . . . 14 3.6. Header Compression . . . . . . . . . . . . . . . . . . . . 14
3.7. Defending Spoofing and Flooding Attacks . . . . . . . . . 15 3.7. Defending Spoofing and Flooding Attacks . . . . . . . . . 15
4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 16 4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 17
4.1. Architectural Guidelines . . . . . . . . . . . . . . . . . 17 4.1. Architectural Guidelines . . . . . . . . . . . . . . . . . 17
4.2. Fundamental Changes . . . . . . . . . . . . . . . . . . . 18 4.2. Fundamental Changes . . . . . . . . . . . . . . . . . . . 18
4.3. Congestion Control Extensions . . . . . . . . . . . . . . 18 4.3. Congestion Control Extensions . . . . . . . . . . . . . . 18
4.4. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 20 4.4. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 20
4.5. Detection and Prevention of Spurious Retransmissions . . . 20 4.5. Detection and Prevention of Spurious Retransmissions . . . 20
4.6. TCP Timeouts . . . . . . . . . . . . . . . . . . . . . . . 21 4.6. TCP Timeouts . . . . . . . . . . . . . . . . . . . . . . . 21
4.7. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 21 4.7. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 21
5. TCP Parameters at IANA . . . . . . . . . . . . . . . . . . . . 22 5. TCP Parameters at IANA . . . . . . . . . . . . . . . . . . . . 22
6. Historic and Undeployed Extensions . . . . . . . . . . . . . . 23 6. Historic and Undeployed Extensions . . . . . . . . . . . . . . 23
7. Support Documents . . . . . . . . . . . . . . . . . . . . . . 26 7. Support Documents . . . . . . . . . . . . . . . . . . . . . . 26
skipping to change at page 5, 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 are not currently documented in the RFC series is practices that are not currently documented in the RFC series are
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 7, line 18 skipping to change at page 7, line 18
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 Section 2 and Differentiated Services [RFC2474]. between RFC 793 Section 2 and Differentiated Services [RFC2474].
RFC 5681 S: "TCP Congestion Control" (August 2009) RFC 5681 S: "TCP Congestion Control" (August 2009)
Although RFC 793 (see Section 2) did not contain any congestion Although RFC 793 (see Section 2) did not contain any congestion
control mechanisms, today congestion control is a required control mechanisms, today congestion control is a required
component of TCP implementations. This document [RFC5681] defines component of TCP implementations. This document [RFC5681] defines
the current versions of Van Jacobson's congestion avoidance and congestion avoidance and control mechanism for TCP, based on Van
control mechanisms for TCP, based on his 1988 SIGCOMM paper Jacobson's 1988 SIGCOMM paper [Jac88].
[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" is described in RFC 5681. The name "Reno"
"Reno" comes from the Net/2 release of the 4.3 BSD operating comes from the Net/2 release of the 4.3 BSD operating system.
system. This is generally regarded as the least common This is generally regarded as the least common denominator among
denominator among TCP flavors currently found running on Internet TCP flavors currently found running on Internet hosts. Reno TCP
hosts. Reno TCP includes the congestion control features of slow includes the congestion control features of slow start, congestion
start, congestion avoidance, fast retransmit, and fast recovery. avoidance, fast retransmit, and fast recovery.
RFC 5681 details the currently accepted congestion control RFC 5681 details the currently accepted congestion control
mechanism, while RFC 1122 Section 2 mandates that such a mechanism, while RFC 1122 Section 2 mandates that such a
congestion control mechanism must be implemented. RFC 5681 congestion control mechanism must be implemented. RFC 5681
differs slightly from the other documents listed in this section, differs slightly from the other documents listed in this section,
as it does not affect the ability of two TCP endpoints to as it does not affect the ability of two TCP endpoints to
communicate; however, congestion control remains a critical communicate; however, congestion control remains a critical
component of any widely deployed TCP implementation and is component of any widely deployed TCP implementation and is
required for the avoidance of congestion collapse and to ensure required for the avoidance of congestion collapse and to ensure
fairness among competing flows. fairness among competing flows.
skipping to change at page 8, line 43 skipping to change at page 8, line 43
3. Strongly Encouraged Enhancements 3. Strongly Encouraged 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 and Section 3.3 list improvements over to the protocol. Section 3.2 and Section 3.3 list improvements over
the congestion control and loss recovery mechanisms as specified in the congestion control and loss recovery mechanisms as specified in
RFC 5681 (see Section 2). Section 3.4 describes algorithms that RFC 5681 (see Section 2). Section 3.4 describes algorithms that
allow a TCP sender to detect whether it has entered loss recovery allow a TCP sender to detect whether it has entered loss recovery
spuriously. Section 3.5 comprises Path MTU Discovery mechanisms. spuriously. Section 3.5 comprises Path MTU Discovery mechanisms.
Schemes for TCP/IP header compression are listed in Section 3.6. Schemes for TCP/IP header compression are listed in Section 3.6.
Finally, Section 3.7 deals with the problem of preventing preventing Finally, Section 3.7 deals with the problem of preventing acceptance
acceptance of forged segments and flooding attacks. of forged segments and flooding attacks.
3.1. Fundamental Changes 3.1. Fundamental Changes
RFCs 2675 and 7323 represent fundamental changes to TCP by redefining RFCs 2675 and 7323 represent fundamental changes to TCP by redefining
how parts of the basic TCP header and options are interpreted. RFC how parts of the basic TCP header and options are interpreted. RFC
7323 defines the Window Scale Option, which re-interprets the 7323 defines the Window Scale Option, which re-interprets the
advertised receive window. RFC 2675 specifies that MSS option and advertised receive window. RFC 2675 specifies that MSS option and
urgent pointer fields with a value of 65,535 are to be treated urgent pointer fields with a value of 65,535 are to be treated
specially. specially.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
3.2. Congestion Control Extensions 3.2. Congestion Control 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 treats lost packets as indicating and loss recovery features. TCP treats lost packets as indicating
congestion-related loss, and cannot distinguish between congestion- congestion-related loss, and cannot distinguish between congestion-
related loss and loss due to transmission errors. Even when ECN is related loss and loss due to transmission errors. Even when ECN is
in use, there is a rather intimate coupling between congestion in use, there is a rather intimate coupling between congestion
control and loss recovery mechanisms. There are several extensions control and loss recovery mechanisms. There are several extensions
to both features, and more often than not, a particular extension to both features, and more often than not, a particular extension
applies to both. In this two sub-sections, we group enhancements to applies to both. In these two sub-sections, we group enhancements to
TCP's congestion control, while the next sub-section focus on TCP's TCP's congestion control, while the next sub-section focus on TCP's
loss recovery. loss recovery.
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
skipping to change at page 10, line 34 skipping to change at page 10, line 34
This document [RFC3390] specifies an increase in the permitted This document [RFC3390] specifies an increase in the permitted
initial window for TCP from one segment to three or four segments initial window for TCP from one segment to three or four segments
during the slow start phase, depending on the segment size. during the slow start phase, depending on the segment size.
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. This change improves the performance of
than the standard method when there is not a one-to-one TCP in situations where is no one-to-one relationship between data
relationship between data segments and acknowledgments. ABC still segments and acknowledgments (e.g. delayed ACKs or ACK loss) and
operates within the accepted guidelines, but is more robust to closes a security hole TCP receivers can use to induce the sender
delayed ACKs and ACK-division [SCWA99][RFC3449]. ABC is into increasing the sending rate too rapidly (ACK-division
recommended by RFC 5681 (see Section 2). [SCWA99][RFC3449]). ABC is recommended by RFC 5681 (see
Section 2).
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 recommends against the Quench messages by transport protocols and recommends against the
implementation of [RFC1016]. implementation of [RFC1016].
3.3. Loss Recovery Extensions 3.3. Loss Recovery Extensions
For the typical implementation of the TCP fast recovery algorithm For the typical implementation of the TCP fast recovery algorithm
described in RFC 5681 (see Section 2), a TCP sender only retransmits described in RFC 5681 (see Section 2), a TCP sender only retransmits
a segment after a retransmit timeout has occurred, or after three a segment after a retransmit timeout has occurred, or after three
duplicate ACKs have arrived triggering the fast retransmit. A single duplicate ACKs have arrived triggering the fast retransmit. A single
RTO might result in the retransmission of several segments, while the RTO might result in the retransmission of several segments, while the
fast retransmit algorithm in RFC 5681 leads only to a single fast retransmit algorithm in RFC 5681 leads only to a single
retransmission. Hence, multiple losses from a single window of data retransmission. Hence, multiple losses from a single window of data
can lead to a performance degradation. Documents listed in this can lead to a performance degradation. Documents listed in this
section aim to improve the overall performance of TCP's standard loss section aim to improve the overall performance of TCP's standard loss
recovery algorithms. In particular, some of them allows TCP senders recovery algorithms. In particular, some of them allow TCP senders
to recover more effectively when multiple segments are lost from a to recover more effectively when multiple segments are lost from a
single flight of data. single flight of data.
RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996) RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996)
(Errata) (Errata)
When more than one packet is lost during one round trip time TCP When more than one packet is lost during one round trip time TCP
may experience poor performance since a TCP sender can only learn may experience poor performance since a TCP sender can only learn
about a single lost packet per round trip time from cumulative about a single lost packet per round trip time from cumulative
acknowledgments. This document [RFC2018] defines the basic acknowledgments. This document [RFC2018] defines the basic
skipping to change at page 17, line 8 skipping to change at page 17, line 15
4. Experimental Extensions 4. Experimental Extensions
The RFCs in this section are either experimental and may become The RFCs in this section are either experimental and may become
proposed standards in the future or are proposed standard (or proposed standards in the future or are proposed standard (or
informational), but can considered as experimental due to lack of informational), but can considered as experimental due to lack of
wide deployment. At least part of the reason that they are still wide deployment. At least part of the reason that they are still
experimental is to gain more wide-scale experience with them before a experimental is to gain more wide-scale experience with them before a
standards track decision is made. standards track decision is made.
At this point is worth mentioning that if the experimental RFC is a If the experimental RFC is a proposal for a new protocol capability
proposal for a new protocol capability or service, i.e., it requires or service, i.e., it requires a new TCP option code point, the
a new TCP option code point, the implementation and experimentation implementation and experimentation should follow [RFC6994] (see
should follows [RFC6994] (see Section 5), which describes how the Section 5), which describes how the experimental TCP option code
experimental TCP option code points can concurrently support multiple points can concurrently support multiple TCP 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 18, line 7 skipping to change at page 18, line 14
individual TCP connections, represents a modification to the core individual TCP connections, represents a modification to the core
of TCP, which supports sharing information among TCP connections. of TCP, which supports sharing information among TCP connections.
Although a Proposed Standard, some pieces of the Congestion Although a Proposed Standard, some pieces of the Congestion
Manager support architecture have not been specified yet, and it Manager support architecture have not been specified yet, and it
has not achieved use or implementation beyond experimental stacks, has not achieved use or implementation beyond experimental stacks,
so it is not listed among the standard TCP enhancements in this so it is not listed among the standard TCP enhancements in this
roadmap. roadmap.
4.2. Fundamental Changes 4.2. Fundamental Changes
Like the standard documents listed in Section 3.1 there newly exist Like the standard documents listed in Section 3.1, there also exist
also experimental RFCs that represent fundamental changes to TCP. new Experimental RFCs that specify fundamental changes to TCP. At
One example is TCP Fast Open that deviates from the standard TCP the time of writing, the only example so far is TCP Fast Open that
semantics of [RFC0793]. deviates from the standard TCP semantics of [RFC0793].
RFC XXX E: "TCP Fast Open" (XXX 2014) RFC XXX E: "TCP Fast Open" (XXX 2014)
This document [I-D.ietf-tcpm-fastopen] describes TCP Fast Open This document [I-D.ietf-tcpm-fastopen] describes TCP Fast Open
that allows data to be carried in the SYN and SYN-ACK packets and that allows data to be carried in the SYN and SYN-ACK packets and
consumed by the receiver during the initial connection handshake. consumed by the receiver during the initial connection handshake.
It saves up to one RTT compared to the standard TCP, which It saves up to one RTT compared to the standard TCP, which
requires a three-way handshake to complete before data can be requires a three-way handshake to complete before data can be
exchanged. exchanged.
4.3. Congestion Control Extensions 4.3. 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 (see RFC 5783, Section 7.6), as it determines the many years (see RFC 5783, Section 7.6), as it determines the
performance of many applications that use TCP. A number of performance of many applications that use TCP. A number of
experimental RFCs address issues with flow start-up, overshoot, and experimental RFCs address issues with flow start-up, overshoot, and
steady-state behavior in the basic RFC 5681 (see Section 2) steady-state behavior in the basic RFC 5681 (see Section 2)
algorithms. In this sub-sections, enhancements to TCP's congestion algorithms. In these sub-sections, enhancements to TCP's congestion
control are listed. The next sub-section focus on TCP's loss control are listed. The next sub-section focuses on TCP's loss
recovery. 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 (see Section 2), which aggressive than that specified in RFC 5681 (see Section 2), which
says that a TCP sender SHOULD set its congestion window to the says that a TCP sender SHOULD set its congestion window to the
initial window after an idle period of an RTO or greater. initial window after an idle period of an RTO or greater.
skipping to change at page 21, line 23 skipping to change at page 21, line 31
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.6. TCP Timeouts 4.6. TCP Timeouts
Besides the well known retransmission timeout the TCP standard Besides the well-known retransmission timeout the TCP standard
[RFC0793] defines other timeouts. This section lists documents that [RFC0793] defines other timeouts. This section lists documents that
deals with TCP's various timouts. deal with TCP's various timeouts.
RFC 5482 S: "TCP User Timeout Option" (June 2009) RFC 5482 S: "TCP User Timeout Option" (June 2009)
As a local per-connection parameter the TCP user timeout controls As a local per-connection parameter the TCP user timeout controls
how long transmitted data may remain unacknowledged before a how long transmitted data may remain unacknowledged before a
connection is forcefully closed. This document [RFC5482] connection is forcefully closed. This document [RFC5482]
specifies the TCP User Timeout Option that allows one end of a TCP specifies the TCP User Timeout Option that allows one end of a TCP
connection to advertise its current user timeout value. This connection to advertise its current user timeout value. This
information provides advice to the other end of the TCP connection information provides advice to the other end of the TCP connection
to adapt its user timeout accordingly. to adapt its user timeout accordingly.
skipping to change at page 26, line 6 skipping to change at page 26, line 6
describes a method to extent the option space after the connection describes a method to extent the option space after the connection
establishment. establishment.
Although RFC 6013 was published 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
skipping to change at page 26, line 48 skipping to change at page 26, line 48
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 This document [RFC0675] is a very early precursor of the
fundamental RFC 793 (see Section 2), which already contained the fundamental RFC 793 (see Section 2), which already contained the
three-way handshake in its final form and the concept of sliding three-way handshake in its final form and the concept of sliding
windows for reliable data transmission. Apart from that the windows for reliable data transmission. Apart from that the
segment layout is totally different and the specified API differs segment layout is totally different and the specified API differs
from the latter RFC 793 (see Section 2). from the latter RFC 793 (see Section 2).
RFC 761 U: "DoD standard Transmission Control Protocol" (Januar RFC 761 U: "DoD standard Transmission Control Protocol" (January
1980) 1980)
This document [RFC0761] is the immediate precursor of RFC 793 (see This document [RFC0761] is the immediate precursor of RFC 793 (see
Section 2). The header format, the connection establishment Section 2). The header format, the connection establishment
including the different connection states, and the overall API including the different connection states, and the overall API
correspond mostly to the final Standard RFC 793 (see Section 2). correspond mostly to the final Standard RFC 793 (see Section 2).
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
skipping to change at page 28, line 27 skipping to change at page 28, line 27
concerns, while others specify TCP- and congestion-control-related concerns, while others specify TCP- and congestion-control-related
mechanisms that are broadly applicable and have impacts on TCP's mechanisms that are broadly applicable and have impacts on TCP's
congestion control techniques. Some of these documents are direct congestion control techniques. Some of these documents are direct
products of the Internet Architecture Board (IAB), giving their products of the Internet Architecture Board (IAB), giving their
guidance on specific aspects of congestion control in the Internet. guidance on specific aspects of congestion control in the Internet.
RFC 1958 I: "Architectural Principles of the Internet" (June 1996) RFC 1958 I: "Architectural Principles of the Internet" (June 1996)
This document [RFC1958] describes the underlying principles of the This document [RFC1958] describes the underlying principles of the
Internet architecture. It provides guidelines for network systems Internet architecture. It provides guidelines for network systems
design that have proven useful in the evolution of the Internet. designs that have proven useful in the evolution of the Internet.
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. Later work on TCP has included several more aggressive to TCP. Later work on TCP has included several more aggressive
mechanisms than Reno TCP includes, and RFC 5033 (see Section 7.4) mechanisms than Reno TCP includes, and RFC 5033 (see Section 7.4)
provides additional guidance on use of such algorithms. The provides additional guidance on use of such algorithms. The
fundamental architectural discussion in RFC 2914 remains valid, fundamental architectural discussion in RFC 2914 remains valid,
regarding the standards process role in defining protocol aspects regarding the standards process role in defining protocol aspects
skipping to change at page 33, line 31 skipping to change at page 33, line 31
This document [RFC0794] clarifies that operating systems need to This document [RFC0794] clarifies that operating systems need to
manage their limited resources, which may include TCP connection manage their limited resources, which may include TCP connection
state, and that these decisions can be made with application state, and that these decisions can be made with application
input, but they do not need to be part of the TCP protocol input, but they do not need to be part of the TCP protocol
specification itself. specification itself.
RFC 879 U: "The TCP Maximum Segment Size and Related Topics" RFC 879 U: "The TCP Maximum Segment Size and Related Topics"
(November 1983) (November 1983)
Abstract: "This memo discusses the TCP Maximum Segment Size Option Abstract: "This memo discusses the TCP Maximum Segment Size Option
and related topics. The purposes is to clarify some aspects of and related topics. The purpose is to clarify some aspects of TCP
TCP and its interaction with IP. This memo is a clarification to and its interaction with IP. This memo is a clarification to the
the TCP specification, and contains information that may be TCP specification, and contains information that may be considered
considered as 'advice to implementers'." [RFC0879] as 'advice to implementers'." [RFC0879]
RFC 1071 U: "Computing the Internet Checksum" (September 1988) RFC 1071 U: "Computing the Internet Checksum" (September 1988)
(Errata) (Errata)
This document [RFC1071] lists a number of implementation This document [RFC1071] lists a number of implementation
techniques for efficiently computing the Internet checksum (used techniques for efficiently computing the Internet checksum (used
by TCP). by TCP).
RFC 1624 I: "Computation of the Internet Checksum via Incremental RFC 1624 I: "Computation of the Internet Checksum via Incremental
Update" (May 1994) Update" (May 1994)
skipping to change at page 39, line 33 skipping to change at page 39, line 33
Forward Acknowledgement (FACK) Forward Acknowledgement (FACK)
FACK [MM96] includes an alternate algorithm for triggering fast FACK [MM96] includes an alternate algorithm for triggering fast
retransmit [RFC5681], based on the extent of the SACK scoreboard. retransmit [RFC5681], based on the extent of the SACK scoreboard.
Its goal is to trigger fast retransmit as soon as the receiver's Its goal is to trigger fast retransmit as soon as the receiver's
reassembly queue is larger than the duplicate ACK threshold, as reassembly queue is larger than the duplicate ACK threshold, as
indicated by the difference between the forward most SACK block indicated by the difference between the forward most SACK block
edge and SND.UNA. This algorithm quickly and reliably triggers edge and SND.UNA. This algorithm quickly and reliably triggers
fast retransmit in the presence of burst losses -- often on the fast retransmit in the presence of burst losses -- often on the
first SACK following such a loss. Such a threshold based first SACK following such a loss. Such a threshold-based
algorithm also triggers fast retransmit immediately in the algorithm also triggers fast retransmit immediately in the
presence of any reordering with extent greater than the duplicate presence of any reordering with extent greater than the duplicate
ACK threshold. FACK is implemented in Linux and turned on per ACK threshold. FACK is implemented in Linux and turned on per
default. default.
Congestion Control for High Rate Flows Congestion Control for High Rate Flows
In the last decade significant research effort has been put into In the last decade significant research effort has been put into
experimental TCP congestion control modifications for obtaining experimental TCP congestion control modifications for obtaining
high throughput with reduced startup and recovery times. Only few high throughput with reduced startup and recovery times. Only few
skipping to change at page 40, line 41 skipping to change at page 40, line 41
12.1. Normative References 12.1. Normative References
[I-D.ietf-tcpm-1323bis] [I-D.ietf-tcpm-1323bis]
Borman, D., Braden, R., Jacobson, V., and R. Borman, D., Braden, R., Jacobson, V., and R.
Scheffenegger, "TCP Extensions for High Performance", Scheffenegger, "TCP Extensions for High Performance",
draft-ietf-tcpm-1323bis-21 (work in progress), April 2014. draft-ietf-tcpm-1323bis-21 (work in progress), April 2014.
[I-D.ietf-tcpm-fastopen] [I-D.ietf-tcpm-fastopen]
Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", draft-ietf-tcpm-fastopen-08 (work in Fast Open", draft-ietf-tcpm-fastopen-09 (work in
progress), March 2014. progress), July 2014.
[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.
[RFC0700] Mader, E., Plummer, W., and R. Tomlinson, "Protocol [RFC0700] Mader, E., Plummer, W., and R. Tomlinson, "Protocol
experiment", RFC 700, August 1974. experiment", RFC 700, August 1974.
[RFC0721] Garlick, L., "Out-of-Band Control Signals in a Host-to- [RFC0721] Garlick, L., "Out-of-Band Control Signals in a Host-to-
Host Protocol", RFC 721, September 1976. Host Protocol", RFC 721, September 1976.
 End of changes. 24 change blocks. 
50 lines changed or deleted 49 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/