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]