Internet Engineering Task Force M. Duke
INTERNET-DRAFT Boeing
Category: Informational R. Braden
File: draft-duke-tcp-roadmap-00.txt ISI
Expires: August 2004 February 23 2004
A Roadmap for TCP Specification Documents
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. This document specifies an
Internet standards track protocol for the Internet community, and
requests discussion and suggestions for improvements. Please refer
to the current edition of the "Internet Official Protocol Standards"
(STD 1) for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document contains an early draft of a "road map" for the
Requests for Comment (RFC) documents relating to TCP (Transmission
Control Protocol), STD 7. This roadmap is intended to provide a
brief summary of the RFC documents that define the current "state" of
TCP standardization and documentation, as a guide to new and old
implementors.
Duke Expires August 2004 [Page 1]
DRAFT TCP Roadmap February 2004
Table of Contents
1. Introduction .................................................... 2
2. Core Specification .............................................. 3
3. Special Cases and Implementation Hints .......................... 5
4. Experimental TCP Extensions ..................................... 6
5. Deprecated TCP Extensions ....................................... 6
6. Case Studies and Protocol Analysis .............................. 7
7. Tools and Tutorials ............................................. 7
8. Security Considerations ......................................... 8
9. Acknowledgments ................................................. 8
1. Introduction
The correct and efficient implementation of TCP (Transmission Control
Protocol), STD 7, is a critical part of Internet host software. As
TCP has evolved over the years, more and more distinct documents have
become part of the accepted standard for TCP. At the same time, a
large number of proposed modifications to TCP have been published in
RFCs.
As an introduction to newcomers and an attempt to organize the
information for old hands, this document contains a "roadmap" to the
TCP-related RFCs. It provides a brief summary of the relevant RFC
documents that summarize the "state" of TCP, for the guidance of all
implementors.
This roadmap includes a very brief description of the contents and
relevance of each TCP-related RFC. In some cases, we simply supply
the Abstract or some key summary sentence from the text as the best
terse description (ideally, an RFC Abstract would ALWAYS be the best
summary!). In addition, a letter code after each RFC number
indicates its category in the RFC series:
S - Standards Track (Proposed Standard, Draft Standard,
or Standard)
E - Experimental
B - Best Current Practice
I - Informational
Note that the category of each RFC does not necessarily reflect its
current relevance. For instance, RFC 2581 is nearly universally
deployed although it is only a "Proposed Standard". Similarly, some
"Informational" RFCs actually technical contain proposals for
changing TCP.
This is a very preliminary version of the TCP roadmap, published in
Duke Expires August 2004 [Page 2]
DRAFT TCP Roadmap February 2004
hopes that others will refine and deepen its contents. It needs a
great deal of work, with much additional discussion of the relevance
and currency of the various RFCs. On the other hand, we believe that
this document already presents a useful model for surveys in many
other areas of Internet technology.
Section 2 lists the RFCs that form the core TCP specification.
Section 3 lists some RFCs that provide suggestions for implementers
or concern issues raised by particular network environments. Section
4 lists RFCs that are experimental and may one day become standards,
Section 5 lists deprecated extensions, Section 6 contains case
studies and analysis, and Section 7 provides tips and tools for
implementers. Within each section, RFCs are listed in chronological
order.
A more complete, though somewhat outdated, listing of operating
systems and the TCP options that they support is at:
http://www.psc.edu/networking/perf_tune.html#table
2. CORE SPECIFICATION
RFC 0793 S: "Transmission Control Protocol", STD 7 (Sep 81)
This is the fundamental specification of TCP. Written by Jon
Postel as part of the core Internet protocol suite, it describes
TCP packet formats and its semantics for data transmission,
reliability, flow control, multiplexing, acknowledgement,
precedence, and security.
RFC 1122 S: "Requirements for Internet Hosts - Communication Layers"
(Oct 89)
This document updates and clarifies RFC 793; it is a must-read for
any TCP implementor.
RFC 1213 S: "Management Information Base for Network Management of
TCP/IP-based Internets: MIB-II" (Mar 91)
This document defines the management data that a TCP
implementation is required support.
RFC 1323 S: "TCP Extensions for High Performance" (May 92)
This document introduces window scaling, timestamps, and
protection against wrapped sequence numbers for efficient and safe
operation over paths with large bandwidth-delay products. It is
implemented in Linux and BSD but is a non-default option in
Windows.
Duke Expires August 2004 [Page 3]
DRAFT TCP Roadmap February 2004
There are some corner cases in this specification that are still
under discussion.
RFC 2012 S: "SNMPv2 Management Information Base for the Transmission
Control Protocol using SMIv2" (Nov 96)
This document defines the TCP MIB. See also RFC 2452.
RFC 2018 S: "TCP Selective Acknowledgement Options" (Oct 96)
This document defines the sective acknowledgements (SACK)
mechanism, a fundamental TCP enhancement. SACK is currently
implemented in Windows, Linux, and BSD.
RFC 2452 S: "IP Version 6 Management Information Base for the
Transmission Control Protocol" (Dec 98)
This document augments RFC 2012 by adding an IPv6-specific
connection table. The rest of 2012 holds for any IP version.
((Shouldn't 2452 "Update" 2012 ?))
RFC 2581 S: "TCP Congestion Control" (Apr 99)
This document defines the current versions of Van Jacobson's
congestion avoidance and control mechanisms for TCP, based on his
1988 SIGCOMM paper.
RFC 2873 S: "TCP Processing of the IPv4 Precendence Field" (Jun 00)
This document removes from the TCP spec all processing of the
precedence bits of the TOS byte of the IP header. This resolves a
conflict between RFC 793 and Diff-serv.
RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
Option for TCP" (Jul 00)
This document extends RFC 2018 to cover the case of acknowledging
duplicate packets. ((Shouldn't 2883 "Update" 2018??))
RFC 2988 S: "Computing TCP's Retransmission Timer" (Nov 00)
Abstract: "This document defines the standard algorithm that
Transmission Control Protocol (TCP) senders are required to use to
compute and manage their retransmission timer. It expands on 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."
RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
Duke Expires August 2004 [Page 4]
DRAFT TCP Roadmap February 2004
(Jan 01)
Abstract: "This document proposes 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."
RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
to IP" (Sep 01):
This document defines a means of detecting congestion without
resorting to loss. Although congestion notification takes place
at the IP level, support is required at the transport level. This
document specifies the changes in TCP in particular. It updates
RFC 793 to define two previously-unused flag bits in the TCP
header.
RFC 3390 S: "Increasing TCP'S Initial Window" (Oct 02)
This docuemnt permits a TCP to use an initial window larger that
one packet during in the slowstart phase. Updates RFC 2581.
RFC 3517 S: "A Conservative Selective Acknowledgement (SACK)-based
Loss Recovery Algorithm for TCP" (Apr 03)
From text: "The algorithm presented in this document conforms to
the spirit of the current congestion control specification (RFC
2581), but allows TCP senders to recover more effectively when
multiple segments are lost from a single flight of data."
3. SPECIAL CASES AND IMPLEMENTATION HINTS
RFC 1144 S: "Compressing TCP/IP headers for low-speed serial links"
(Feb 90)
This document contains Van Jacobson's classic specification of
TCP/IP header compression. It is notable for its elegance and
clarity.
RFC 2140 I: "TCP Control Block Interdependence" (Apr 97)
This document suggests how TCP connections might share
information. Partially implemented in Linux.
RFC 2488 B: "Enhancing TCP Over Satellite Channels using Standard
Mechanisms" (Jan 99)
Duke Expires August 2004 [Page 5]
DRAFT TCP Roadmap February 2004
RFC 2525 I: "Known TCP Implementation Problems" (Mar 99)
RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (Aug 02)
This document is a plea to firewall vendors, not to send
gratuitous TCP RST (Reset) packets for unassigned TCP header bits.
This practice prevents desirable extension and evolution of the
protocol and hence is inimical to the future of the Internet.
RFC 3449 B: "TCP Performance Implications of Network Path Asymmetry"
(Dec 02)
RFC 3481 B: "TCP over Second (2.5G) and Third (3G) Generation
Wireless Networks" (Feb 03)
RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (Feb 03)
4. EXPERIMENTAL TCP EXTENSIONS
These documents may one day join the standards track, but they are
currently not recommended for implementation.
RFC 2582 E: "The NewReno Modification to TCP's Fast Recovery
Algorithm" (Apr 99)
Tweaks to congestion control.
RFC 2861 E: "TCP Congestion Window Validation" (Jun 00)
Decaying the congestion window if it hasn't been recently
utilized.
RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting
(ABC)" (Feb 03)
Congestion control using number of bytes acknowledged rather than
number of acknowledgements received. Implemented in Linux.
RFC 3522 E: "The Eifel Detection Algorithm for TCP" (Apr 03)
Use of timestamps to detect spurious timeouts.
RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling
with Nonces" (Jun 03)
Modified ECN to address security concerns.
5. DEPRECATED TCP EXTENSIONS
Duke Expires August 2004 [Page 6]
DRAFT TCP Roadmap February 2004
The RFCs listed here define extensions that failed to arouse
substantial interest, or were found to be defective.
RFC 1146 E "TCP alternate Checksum Options" (Mar 90)
Defined more robust alternatives to TCP checksum.
RFC 1379 I "Extending TCP for Transactions -- Concepts" (Nov 92)
See RFC 1644.
RFC 1644 E "T/TCP -- TCP Extensions for Transactions Functional
Specification" (Jul 94)
The inventors of TCP believed that cached connection state could
be used to eliminate TCP's 3-way handshake, to support single-
packet request/response exchanges. RFCs 1379 and 1644 show that
it is far from simple. Furthermore, T/TCP foundered on the ease
of denial-of-service attacks that can result.
RFC 1693 E "An Extension to TCP: Partial Order Service" (Nov 94)
This document defines a TCP extension for applications where total
reliability isn't necessary.
6. CASE STUDIES AND PROTOCOL ANALYSIS
RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 92):
This document pointed out some bad "corner cases" at connection
close.
RFC 2357 I: "IETF Criteria for Evaluating Reliable Multicast
Transport and Application Protocols" (Jun 98)
RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size"
(Sep 98)
RFC 2416 I: "When TCP Starts Up With Four Packets Into Only Three
Buffers" (Sep 98)
RFC 2760 I: "Ongoing TCP Research Related to Satellites" (Feb 00)
RFC 2884 I: "Performance Evaluation of Explicit Congestion
Notification (ECN) in IP Networks" (Jul 00)
RFC 2914 B: "Congestion Control Principles" (Sep 00).
Duke Expires August 2004 [Page 7]
DRAFT TCP Roadmap February 2004
RFC 2923 I: "TCP Problems with Path MTU Discovery" (Sep 00)
RFC 2963 I: "A Rate Adaptive Shaper for Differentiated Services" (Oct
2000)
Optimizing TCP performance in the presence of a DiffServ scheme.
RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations" (Jun 01)
7. TOOLS AND TUTORIALS
RFC 1180 I: "TCP/IP tutorial" (Jan 91)
RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for
Monitoring and Debugging TCP/IP Internets and Interconnected
Devices" (Jun 93)
RFC 2151 I: "A Primer on Internet and TCP/IP Tools and Utilities"
(Jun 97)
RFC 2398 I: "Some Testing Tools for TCP Implementors" (Aug 98)
8. Security Considerations
This document introduces no new security considerations. Each RFC
listed in this document addresses the security considerations of the
proposals it contains.
9. Acknowledgments
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
IRTF. We thank Joe Touch and Reiner Ludwig for their contributions,
in particular.
Author's Addresses
Martin Duke
Boeing Phantom Works
PO Box 3707, MC 3W-51
Seattle, WA 98124-2207
Phone: 253-657-8203
Email: mduke26@comcast.net
Robert Braden
USC Information Sciences Institute
Duke Expires August 2004 [Page 8]
DRAFT TCP Roadmap February 2004
Marina del Rey, CA 90292-6695
Phone: 310-448-9173
Email: braden@isi.edu
Duke Expires August 2004 [Page 9]
DRAFT TCP Roadmap February 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
Duke Expires August 2004 [Page 10]
DRAFT TCP Roadmap February 2004
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Duke Expires August 2004 [Page 11]