draft-ietf-tcpm-tcp-roadmap-04.txt   draft-ietf-tcpm-tcp-roadmap-05.txt 
Network Working Group M. Duke Network Working Group M. Duke
Internet-Draft Boeing Phantom Works Internet-Draft Boeing Phantom Works
Expires: December 3, 2005 R. Braden Expires: April 2, 2006 R. Braden
USC Information Sciences Institute USC Information Sciences Institute
W. Eddy W. Eddy
NASA GRC/Verizon FNS Verizon Federal Network Systems
E. Blanton E. Blanton
Purdue University Purdue University Computer Science
June 1, 2005 September 29, 2005
A Roadmap for TCP Specification Documents A Roadmap for TCP Specification Documents
draft-ietf-tcpm-tcp-roadmap-04 draft-ietf-tcpm-tcp-roadmap-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2005. This Internet-Draft will expire on April 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Basic Functionality . . . . . . . . . . . . . . . . . . . . 5 2. Basic Functionality . . . . . . . . . . . . . . . . . . . . 5
3. Standard Enhancements . . . . . . . . . . . . . . . . . . . 8 3. Recommended Enhancements . . . . . . . . . . . . . . . . . . 8
3.1 Congestion Control and Loss Recovery Extensions . . . . . 9 3.1 Congestion Control and Loss Recovery Extensions . . . . . 9
3.2 SACK-based Loss Recovery and Congestion Control . . . . . 10 3.2 SACK-based Loss Recovery and Congestion Control . . . . . 10
3.3 Dealing with Forged Segments . . . . . . . . . . . . . . . 11 3.3 Dealing with Forged Segments . . . . . . . . . . . . . . . 11
4. Experimental Extensions . . . . . . . . . . . . . . . . . . 13 4. Experimental Extensions . . . . . . . . . . . . . . . . . . 13
5. Historic Extensions . . . . . . . . . . . . . . . . . . . . 16 5. Historic Extensions . . . . . . . . . . . . . . . . . . . . 17
6. Support Documents . . . . . . . . . . . . . . . . . . . . . 18 6. Support Documents . . . . . . . . . . . . . . . . . . . . . 19
6.1 Foundational Works . . . . . . . . . . . . . . . . . . . . 18 6.1 Foundational Works . . . . . . . . . . . . . . . . . . . . 19
6.2 Difficult Network Environments . . . . . . . . . . . . . . 20 6.2 Difficult Network Environments . . . . . . . . . . . . . . 21
6.3 Implementation Advice . . . . . . . . . . . . . . . . . . 22 6.3 Implementation Advice . . . . . . . . . . . . . . . . . . 23
6.4 Management Information Bases . . . . . . . . . . . . . . . 23 6.4 Management Information Bases . . . . . . . . . . . . . . . 24
6.5 Tools and Tutorials . . . . . . . . . . . . . . . . . . . 25 6.5 Tools and Tutorials . . . . . . . . . . . . . . . . . . . 26
6.6 Case Studies . . . . . . . . . . . . . . . . . . . . . . . 25 6.6 Case Studies . . . . . . . . . . . . . . . . . . . . . . . 26
7. Undocumented TCP Features . . . . . . . . . . . . . . . . . 27 7. Undocumented TCP Features . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32
11. Informative References . . . . . . . . . . . . . . . . . . . 32 11. Informative References . . . . . . . . . . . . . . . . . . . 33
11.1 Basic Functionality . . . . . . . . . . . . . . . . . . 32 11.1 Basic Functionality . . . . . . . . . . . . . . . . . . 33
11.2 Standard Enhancements . . . . . . . . . . . . . . . . . 32 11.2 Recommended Enhancements . . . . . . . . . . . . . . . . 33
11.3 Experimental Extensions . . . . . . . . . . . . . . . . 33 11.3 Experimental Extensions . . . . . . . . . . . . . . . . 34
11.4 Historic Extensions . . . . . . . . . . . . . . . . . . 34 11.4 Historic Extensions . . . . . . . . . . . . . . . . . . 35
11.5 Support Documents . . . . . . . . . . . . . . . . . . . 35 11.5 Support Documents . . . . . . . . . . . . . . . . . . . 36
11.6 Informative References Outside the RFC Series . . . . . 37 11.6 Informative References Outside the RFC Series . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
Intellectual Property and Copyright Statements . . . . . . . 40 Intellectual Property and Copyright Statements . . . . . . . 41
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 more experimental modifications to TCP have also
been published in the RFC series, along with informational notes, been published in the RFC series, along with informational notes,
case studies, and other advice. case studies, and other advice.
skipping to change at page 8, line 5 skipping to change at page 8, line 5
RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000) RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000)
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."
[RFC2988] [RFC2988]
3. Standard Enhancements 3. Recommended Enhancements
This section describes recommended TCP modifications that improve This section describes recommended TCP modifications that improve
performance and security. RFCs 1323 and 3168 represent fundamental performance and security. RFCs 1323 and 3168 represent fundamental
changes to the protocol. RFC 1323, based on RFCs 1072 and 1185, changes to the protocol. RFC 1323, based on RFCs 1072 and 1185,
allows better utilization of high bandwidth-delay product paths by allows better utilization of high bandwidth-delay product paths by
providing some needed mechanisms for high-rate transfers. RFC 3168 providing some needed mechanisms for high-rate transfers. RFC 3168
describes a change to the Internet's architecture, where routers describes a change to the Internet's architecture, where routers
signal end-hosts of growing congestion levels, and can do so before signal end-hosts of growing congestion levels, and can do so before
packet losses are forced. Section 3.1 lists improvements in the packet losses are forced. Section 3.1 lists improvements in the
congestion control and loss recovery mechanisms specified in RFC congestion control and loss recovery mechanisms specified in RFC
skipping to change at page 10, line 7 skipping to change at page 10, line 7
(January 2001) (January 2001)
Abstract: "This document proposes Limited Transmit, a new Abstract: "This document proposes Limited Transmit, a new
Transmission Control Protocol (TCP) mechanism that can be used to Transmission Control Protocol (TCP) mechanism that can be used to
more effectively recover lost segments when a connection's more effectively recover lost segments when a connection's
congestion window is small, or when a large number of segments are congestion window is small, or when a large number of segments are
lost in a single transmission window." [RFC3042] lost in a single transmission window." [RFC3042]
Tests from 2004 showed that Limited Transmit was deployed in Tests from 2004 showed that Limited Transmit was deployed in
roughly one third of the web servers tested [MAF04]. roughly one third of the web servers tested [MAF04].
RFC 3390 S: "Increasing TCP'S Initial Window" (October 2002) RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)
This document [RFC3390] updates RFC 2581 to permit an initial TCP This document [RFC3390] updates RFC 2581 to permit an initial TCP
window of three or four segments during the slow-start phase, window of three or four segments during the slow-start phase,
depending on the segment size. depending on the segment size.
RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery
Algorithm" (April 2004) Algorithm" (April 2004)
This document [RFC3782] specifies a modification to the standard This document [RFC3782] 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
acknowledgements to make inferences determining the next segment acknowledgements to make inferences determining the next segment
to send in situations where SACK would be helpful, but isn't to send in situations where SACK would be helpful, but isn't
available. While it is only a slight modification, the NewReno available. While 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 4015 S: "The Eifel Response Algorithm for TCP" (February 2005)
This document [RFC4015] describes the response portion of the
Eifel algorithm, which can be used in conjunction with one of
several methods of detecting when loss recovery has been
spuriously entered, such as the Eifel detection algorithm in RFC
3522, the algorithm in RFC 3708, or F-RTO [f-rto].
Abstract: "Based on an appropriate detection algorithm, the Eifel
response algorithm provides a way for a TCP sender to respond to a
detected spurious timeout. It adapts the retransmission timer to
avoid further spurious timeouts, and can avoid - depending on the
detection algorithm - the often unnecessary go-back-N retransmits
that would otherwise be sent. In addition, the Eifel response
algorithm restores the congestion control state in such a way that
packet bursts are avoided."
3.2 SACK-based Loss Recovery and Congestion Control 3.2 SACK-based Loss Recovery and Congestion Control
The base TCP specification in RFC 793 provided only a simple The base TCP specification in RFC 793 provided only a simple
cumulative acknowledgment mechanism. However, a selective cumulative acknowledgment mechanism. However, a selective
acknowledgment (SACK) mechanism provides performance improvement in acknowledgment (SACK) mechanism provides performance improvement in
the presence of multiple packet losses from the same flight, more the presence of multiple packet losses from the same flight, more
than outweighing the modest increase in complexity. A TCP should be than outweighing the modest increase in complexity. A TCP should be
expected to implement SACK, however SACK is a negotiated option and expected to implement SACK, however SACK is a negotiated option and
is only used if support is advertised by both sides of a connection. is only used if support is advertised by both sides of a connection.
skipping to change at page 15, line 11 skipping to change at page 15, line 11
This document presents conservative methods of using this This document presents conservative methods of using this
information to identify unnecessary retransmissions for various information to identify unnecessary retransmissions for various
applications." [RFC3708] applications." [RFC3708]
RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion
Windows" (March 2004) Windows" (March 2004)
This document [RFC3742] describes a more conservative slow-start This document [RFC3742] describes a more conservative slow-start
behavior to prevent massive packet losses when a connection uses a behavior to prevent massive packet losses when a connection uses a
very large window. very large window.
Work in progress: Forward RTO-Recovery (F-RTO): An Algorithm for RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005)
Detecting Spurious Retransmission Timeouts with TCP and SCTP
(Internet Draft name: draft-ietf-tcpm-frto)
The F-RTO detection algorithm [f-rto]provides another option for This document [RFC4015] describes the response portion of the
inferring spurious retransmission timeouts. Unlike some similar Eifel algorithm, which can be used in conjunction with one of
detection methods, F-RTO does not rely on the use of any TCP several methods of detecting when loss recovery has been
options. At the time of this writing, the TCP Maintenance and spuriously entered, such as the Eifel detection algorithm in RFC
Minor Extensions Working Group had completed a document describing 3522, the algorithm in RFC 3708, or F-RTO in RFC 4138.
F-RTO (by Pasi Sarolahti and Markku Kojo), and planned to make
this an Experimental part of the RFC series. Abstract: "Based on an appropriate detection algorithm, the Eifel
response algorithm provides a way for a TCP sender to respond to a
detected spurious timeout. It adapts the retransmission timer to
avoid further spurious timeouts, and can avoid - depending on the
detection algorithm - the often unnecessary go-back-N retransmits
that would otherwise be sent. In addition, the Eifel response
algorithm restores the congestion control state in such a way that
packet bursts are avoided."
RFC 4015 is itself a Proposed Standard. The consensus of the TCPM
working group was to place it in this section of the roadmap
document due to three factors.
1. RFC 4015 operates on the output of a detection algorithm, for
which there is currently no available mechanism on the
standards track.
2. The working group was not aware of any wide deployment and use
of RFC 4015.
3. The concensus of the working group, after a discussion of the
known Intellectual Property Rights claims on the techniques
described in RFC 4015, identified this section of the roadmap
as an appropriate location.
RFC 4138 E: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
Spurious Retransmission Timeouts with TCP and the Stream Control
Transmission Protocol" (August 2005)
The F-RTO detection algorithm [RFC4138] provides another option
for inferring spurious retransmission timeouts. Unlike some
similar detection methods, F-RTO does not rely on the use of any
TCP options.
5. Historic Extensions 5. Historic 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, or were found to be arouse substantial interest from implementers, or were found to be
defective for general use. defective for general use.
RFC 1106 "TCP Big Window and NAK Options" (June 1989) - found RFC 1106 "TCP Big Window and NAK Options" (June 1989) - found
defective defective
skipping to change at page 32, line 39 skipping to change at page 33, line 39
[RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
RFC 2675, August 1999. RFC 2675, August 1999.
[RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP [RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP
Processing of the IPv4 Precedence Field", RFC 2873, Processing of the IPv4 Precedence Field", RFC 2873,
June 2000. June 2000.
[RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission
Timer", RFC 2988, November 2000. Timer", RFC 2988, November 2000.
11.2 Standard Enhancements 11.2 Recommended Enhancements
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
skipping to change at page 34, line 24 skipping to change at page 35, line 24
[RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective
Acknowledgement (DSACKs) and Stream Control Transmission Acknowledgement (DSACKs) and Stream Control Transmission
Protocol (SCTP) Duplicate Transmission Sequence Numbers Protocol (SCTP) Duplicate Transmission Sequence Numbers
(TSNs) to Detect Spurious Retransmissions", RFC 3708, (TSNs) to Detect Spurious Retransmissions", RFC 3708,
February 2004. February 2004.
[RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large
Congestion Windows", RFC 3742, March 2004. Congestion Windows", RFC 3742, March 2004.
[f-rto] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO): [RFC4138] Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO):
An Algorithm for Detecting Spurious retransmission An Algorithm for Detecting Spurious Retransmission
Timeouts with TCP and SCTP", (draft-ietf-tcpm-frto-02 in Timeouts with TCP and the Stream Control Transmission
RFC Editor queue), November 2004. Protocol (SCTP)", RFC 4138.
11.4 Historic Extensions 11.4 Historic Extensions
[RFC1106] Fox, R., "TCP big window and NAK options", RFC 1106, [RFC1106] Fox, R., "TCP big window and NAK options", RFC 1106,
June 1989. June 1989.
[RFC1110] McKenzie, A., "Problem with the TCP big window option", [RFC1110] McKenzie, A., "Problem with the TCP big window option",
RFC 1110, August 1989. RFC 1110, August 1989.
[RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum
skipping to change at page 38, line 32 skipping to change at page 39, line 32
[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 Phantom Works Boeing Phantom Works
PO Box 3707, MC 3W-51 PO Box 3707, MC 7L-49
Seattle, WA 98124-2207 Seattle, WA 98124-2207
Phone: 253-657-8203 Phone: 425-865-1182
Email: mduke26@comcast.net Email: martin.duke@boeing.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
NASA GRC/Verizon FNS Verizon Federal Network Systems
21000 Brookpark Rd, MS 54-5 21000 Brookpark Rd, MS 54-5
Cleveland, OH 44135 Cleveland, OH 44135
Phone: 216-433-6682 Phone: 216-433-6682
Email: weddy@grc.nasa.gov Email: weddy@grc.nasa.gov
Ethan Blanton Ethan Blanton
Purdue University Purdue University Computer Science
250 N. University St.
West Lafayette, IN 47907
Email: eblanton@cs.purdue.edu Email: eblanton@cs.purdue.edu
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
 End of changes. 18 change blocks. 
67 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/