idnits 2.17.1 draft-ietf-tcpm-tcp-roadmap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 893. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 22) being 73 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 154: '...us features that MUST, SHOULD, MAY, SH...' RFC 2119 keyword, line 179: '...he algorithm from a SHOULD to a MUST."...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 8, 2004) is 7133 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC0793' on line 625 looks like a reference -- Missing reference section? 'RFC1122' on line 628 looks like a reference -- Missing reference section? 'RFC1323' on line 635 looks like a reference -- Missing reference section? 'RFC2873' on line 652 looks like a reference -- Missing reference section? 'RFC2988' on line 660 looks like a reference -- Missing reference section? 'RFC2581' on line 649 looks like a reference -- Missing reference section? 'RFC3042' on line 663 looks like a reference -- Missing reference section? 'RFC3168' on line 667 looks like a reference -- Missing reference section? 'RFC3390' on line 671 looks like a reference -- Missing reference section? 'RFC3782' on line 678 looks like a reference -- Missing reference section? 'RFC2018' on line 642 looks like a reference -- Missing reference section? 'RFC2883' on line 656 looks like a reference -- Missing reference section? 'RFC3517' on line 674 looks like a reference -- Missing reference section? 'RFC1156' on line 631 looks like a reference -- Missing reference section? 'RFC2012' on line 638 looks like a reference -- Missing reference section? 'RFC2452' on line 645 looks like a reference -- Missing reference section? 'RFC1144' on line 684 looks like a reference -- Missing reference section? 'RFC1948' on line 687 looks like a reference -- Missing reference section? 'RFC2140' on line 690 looks like a reference -- Missing reference section? 'RFC2488' on line 693 looks like a reference -- Missing reference section? 'RFC2525' on line 697 looks like a reference -- Missing reference section? 'RFC3360' on line 701 looks like a reference -- Missing reference section? 'RFC3449' on line 704 looks like a reference -- Missing reference section? 'RFC3481' on line 708 looks like a reference -- Missing reference section? 'RFC3493' on line 713 looks like a reference -- Missing reference section? 'RFC2861' on line 719 looks like a reference -- Missing reference section? 'RFC3465' on line 722 looks like a reference -- Missing reference section? 'RFC3522' on line 725 looks like a reference -- Missing reference section? 'RFC3540' on line 728 looks like a reference -- Missing reference section? 'RFC3742' on line 735 looks like a reference -- Missing reference section? 'RFC1146' on line 740 looks like a reference -- Missing reference section? 'RFC1379' on line 743 looks like a reference -- Missing reference section? 'RFC1644' on line 746 looks like a reference -- Missing reference section? 'RFC1693' on line 749 looks like a reference -- Missing reference section? 'RFC1337' on line 754 looks like a reference -- Missing reference section? 'RFC2415' on line 757 looks like a reference -- Missing reference section? 'RFC2416' on line 760 looks like a reference -- Missing reference section? 'FACK' on line 836 looks like a reference -- Missing reference section? 'RFC2760' on line 764 looks like a reference -- Missing reference section? 'RFC2884' on line 769 looks like a reference -- Missing reference section? 'RFC2914' on line 773 looks like a reference -- Missing reference section? 'RFC2923' on line 776 looks like a reference -- Missing reference section? 'RFC2963' on line 779 looks like a reference -- Missing reference section? 'RFC3135' on line 782 looks like a reference -- Missing reference section? 'RFC1180' on line 788 looks like a reference -- Missing reference section? 'RFC1470' on line 791 looks like a reference -- Missing reference section? 'RFC2398' on line 799 looks like a reference -- Missing reference section? 'RFC0813' on line 804 looks like a reference -- Missing reference section? 'RFC0817' on line 807 looks like a reference -- Missing reference section? 'RFC0876' on line 810 looks like a reference -- Missing reference section? 'RFC0896' on line 813 looks like a reference -- Missing reference section? 'RFC0964' on line 816 looks like a reference -- Missing reference section? 'RFC1066' on line 820 looks like a reference -- Missing reference section? 'RFC1072' on line 824 looks like a reference -- Missing reference section? 'RFC1185' on line 827 looks like a reference -- Missing reference section? 'RFC1213' on line 830 looks like a reference -- Missing reference section? 'RFC3649' on line 732 looks like a reference -- Missing reference section? 'RFC2151' on line 796 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 65 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Duke 3 Internet-Draft Boeing Phantom Works 4 Expires: April 8, 2005 R. Braden 5 USC Information Sciences Institute 6 W. Eddy 7 NASA GRC/Verizon FNS 8 E. Blanton 9 Purdue University 10 October 8, 2004 12 A Roadmap for TCP Specification Documents 13 draft-ietf-tcpm-tcp-roadmap-00 15 Status of this Memo 17 This document is an Internet-Draft and is subject to all provisions 18 of section 3 of RFC 3667. By submitting this Internet-Draft, each 19 author represents that any applicable patent or other IPR claims of 20 which he or she is aware have been or will be disclosed, and any of 21 which he or she become aware will be disclosed, in accordance with 22 RFC 3668. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as 27 Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on April 8, 2005. 42 Copyright Notice 44 Copyright (C) The Internet Society (2004). 46 Abstract 48 This document contains a "roadmap" to the Requests for Comments (RFC) 49 documents relating to the Internet's Transmission Control Protocol 50 (TCP). This roadmap provides a brief summary of the documents 51 defining TCP and various TCP extensions that have accumulated in the 52 RFC series. This serves as a rough guide and quick reference for 53 both TCP implementers and other parties that need help consuming the 54 vast cornucopia of TCP-related RFCs. 56 1. Introduction 58 One critical part of an Internet host's software is a correct and 59 efficient implementation of the Transmission Control Protocol (TCP) 60 [RFC0793]. As TCP has evolved over the years, many distinct 61 documents have become part of the accepted standard for TCP. At the 62 same time, a large number of more experimental modifications to TCP 63 have been published in the RFC series. 65 As an introduction to newcomers and an attempt to organize the 66 plethora of information for old hands, this document contains a 67 "roadmap" to the TCP-related RFCs. It provides a brief summary of 68 the relevant RFC documents that define TCP. This can give rough 69 guidance to implementers on the relevance and significance of various 70 standards track extensions, informational notes, and best current 71 practices 73 This roadmap includes a brief description of the contents and 74 relevance of each TCP-related RFC. In some cases, we simply supply 75 the abstract or some key summary sentence from the text as a terse 76 description. In addition, a letter code after each RFC number 77 indicates its category in the RFC series: 78 S - Standards Track (Proposed Standard, Draft Standard, or 79 Standard) 80 E - Experimental 81 B - Best Current Practice 82 I - Informational 84 Note that the category of each RFC does not necessarily reflect its 85 current relevance. For instance, RFC 2581 is nearly universally 86 deployed although it is only a "Proposed Standard". Similarly, some 87 "Informational" RFCs actually contain technical proposals for 88 changing TCP. 90 Section 2 lists the RFCs that form the core TCP specification. 91 Section 3 lists some RFCs that provide suggestions for implementers 92 or describe best current practices concerning issues raised by 93 particular network environments. Section 4 lists RFCs that are 94 experimental and may one day become standards, Section 5 lists some 95 deprecated extensions, Section 6 contains case studies and analysis, 96 and Section 7 provides tips and tools for implementers. Within each 97 section, RFCs are listed in chronological order. 99 When this document describes a features as "available in modern 100 operating systems", we mean that the feature is at least present in 101 widely deployed versions of today's Linux, BSD-derived, and Windows 102 operating systems. Many other specific operating systems are in use 103 on the Internet, and feature support varies widely both among them 104 and among specific versions of even the few operating systems in the 105 above list. However, if we say a feature is found in "modern 106 operating systems", the reader may fairly safely bet that it can at 107 least be found in most presently maintained commercial Unix flavors, 108 Cisco IOS versions, and various real-time and embedded kernels that 109 offer TCP support. 111 2. Core Specification 113 A small number of documents compose the core specification of TCP. 114 These can be grouped into the base documents, describing things like 115 the header format and state machine operation, documents describing 116 congestion control behaviors, and documents that detail SACK use for 117 efficient loss recovery. At this time every conformant TCP 118 implementation should implement: 120 Base protocol: RFC 793, as extended and clarified by RFC 1122, RFC 121 1323, RFC 2873, and RFC 2988. These documents are described in 122 Section 2.1 123 Congestion control: RFC 2581, RFC 3042, RFC 3168, RFC 3390, and 124 RFC 3782. Section 2.2 discusses these RFCs. 125 SACK: RFC 2018, RFC 2883, and RFC 3517 are noted in Section 2.3 127 In addition to these core documents, there are a number of standards 128 track documents that describe the TCP MIB statistics that are 129 required to be kept. These documents are listed in Section 2.4 and 130 their history is sketched, as a somewhat complex relationship exists 131 between them. 133 2.1 Base Protocol 135 RFC 0793 S: "Transmission Control Protocol", STD 7 (Sep 81) 137 This is the fundamental TCP specification document. Written by 138 Jon Postel as part of the Internet protocol suite's core, it 139 describes the TCP packet format, the TCP state machine and event 140 processing, and TCP's semantics for data transmission, 141 reliability, flow control, multiplexing, and acknowledgement. 142 Although the precedence and security compartment portions are 143 mostly irrelevant today, the majority of this document still 144 acurately describes modern TCPs. [RFC0793] 146 RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" 147 (Oct 89) 149 This document updates and clarifies RFC 793; fixing some 150 specification bugs and oversights. It also explains some features 151 such as keep-alives and Karn's and Jacobson's RTO estimation 152 algorithms [karn][vj88]. ICMP interactions are mentioned and some 153 tips are given for efficient implementation. RFC 1122 lists the 154 various features that MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT 155 be present in standards-conforming TCP implementations. [RFC1122] 157 RFC 1323 S: "TCP Extensions for High Performance" (May 92) 159 This document introduces window scaling, timestamps, and 160 protection against wrapped sequence numbers for efficient and safe 161 operation over paths with large bandwidth-delay products. These 162 are all commonly found in modern operating systems; however, they 163 may require manual tuning and configuration. There are some 164 corner cases in this specification that are still under 165 discussion. [RFC1323] 167 RFC 2873 S: "TCP Processing of the IPv4 Precendence Field" (Jun 00) 169 This document removes from the TCP specification all processing of 170 the precedence bits of the TOS byte of the IP header. This 171 resolves a conflict between RFC 793 and Diff-Serv. [RFC2873] 173 RFC 2988 S: "Computing TCP's Retransmission Timer" (Nov 00) 175 Abstract: "This document defines the standard algorithm that 176 Transmission Control Protocol (TCP) senders are required to use to 177 compute and manage their retransmission timer. It expands on the 178 discussion in section 4.2.3.1 of RFC 1122 and upgrades the 179 requirement of supporting the algorithm from a SHOULD to a MUST." 180 [RFC2988] 182 2.2 Congestion Control 184 RFC 2581 S: "TCP Congestion Control" (Apr 99) 186 This document defines the current versions of Van Jacobson's 187 congestion avoidance and control mechanisms for TCP, based on his 188 1988 SIGCOMM paper [vj88]. [RFC2581] 190 RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit" 191 (Jan 01) 193 Abstract: "This document proposes a new Transmission Control 194 Protocol (TCP) mechanism that can be used to more effectively 195 recover lost segments when a connection's congestion window is 196 small, or when a large number of segments are lost in a single 197 transmission window." [RFC3042] 199 RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN) 200 to IP" (Sep 01) 202 This document defines a means of detecting congestion without 203 resorting to loss. Although congestion notification takes place 204 at the IP level, support is required at the transport level to 205 echo the bits and adapt the sending rate. This document updates 206 RFC 793 to define two previously-unused flag bits in the TCP 207 header. [RFC3168] 209 RFC 3390 S: "Increasing TCP'S Initial Window" (Oct 02) 211 This document permits a TCP to use an initial window larger that 212 one packet during in the slow-start phase, updating RFC 2581. 213 [RFC3390] 215 RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery 216 Algorithm" (Apr 04) 218 This document specifies a slight modification to the standard Reno 219 fast recovery algorithm, whereby a TCP sender can use partial 220 acknowledgements to make inferences determining the next segment 221 to send in situations where SACK would be helpful, but isn't 222 available. [RFC3782] 224 2.3 SACK-based Loss Recovery 226 RFC 2018 S: "TCP Selective Acknowledgement Options" (Oct 96) 228 This document defines the sective acknowledgement (SACK) 229 mechanism, providing more fine-grained acknowledgement information 230 than the basic cummulative acknowledgement mechanism. Exchange of 231 SACK information is widely implemented in modern operating 232 systems. [RFC2018] 234 RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK) 235 Option for TCP" (Jul 00) 237 This document extends RFC 2018 to cover the case of acknowledging 238 duplicate packets. [RFC2883] 240 RFC 3517 S: "A Conservative Selective Acknowledgement (SACK)-based 241 Loss Recovery Algorithm for TCP" (Apr 03) 243 This document describes a TCP loss recovery algorithm which uses 244 available SACK information to intelligently recover when more than 245 one segment is lost from a single flight of data. While support 246 for the exchange of SACK information is widely implemented, not 247 all implementations use an algorithm as sophisticated as that 248 described in RFC 3517. [RFC3517] 250 2.4 TCP MIBs 252 The first MIB module defined for use with SNMP (in RFC 1066 and its 253 update, RFC 1156) was a single monolithic MIB module, called MIB-I. 254 This evolved over time to be MIB-II (RFC 1213). It then became 255 apparent that having a single monolithic MIB module was not scalable, 256 given the number and breadth of MIB data definitions that needed to 257 be included. Thus, additional MIB modules were defined, and those 258 parts of MIB-II which needed to evolve were split off. Eventually, 259 the remaining parts of MIB-II were also split off, with the 260 TCP-specific part being documented in RFC 2012. 262 RFC 2012 is the primary document that implementers should presently 263 be concerned with for MIB-II. If implementers desire to support 264 MIB-I, then RFC 1156 is the document to refer to, although it has 265 been obsoleted by the MIB-II specification in RFC 1213. Although a 266 standards track document, RFC 2452 is considered a historic mistake 267 by the MIB community, as it is based on the idea of parallel IPv4 and 268 IPv6 structures. The community has decided that while new structures 269 are needed to accomodate IPv6, a single generic structure for both 270 IPv4 and IPv6 addresses, to aid in definition, implementation, and 271 transition between IPv4 and IPv6. 273 RFC 1156 S: "Management Information Base for Network Management of 274 TCP/IP-based Internets" (May 90) 276 This document describes the required MIB fields for TCP 277 implementations, with minor corrections and no technical changes 278 from RFC 1066, which it obsoletes. This is the standards track 279 document for MIB-I. [RFC1156] 281 RFC 2012 S: "SNMPv2 Management Information Base for the Transmission 282 Control Protocol using SMIv2" (Nov 96) 284 This document defines the TCP MIB, updating RFC 1213.[RFC2012] 286 RFC 2452 S: "IP Version 6 Management Information Base for the 287 Transmission Control Protocol" (Dec 98) 289 This document augments RFC 2012 by adding an IPv6-specific 290 connection table. The rest of 2012 holds for any IP version. 291 ((Shouldn't 2452 "Update" 2012 ?)) [RFC2452] 293 3. Special Cases and Implementation Hints 295 RFC 1144 S: "Compressing TCP/IP headers for low-speed serial links" 296 (Feb 90) 298 This document contains Van Jacobson's classic specification of 299 TCP/IP header compression. It is notable for its elegance and 300 clarity. [RFC1144] 302 RFC 1948 I: "Defending Against Sequence Number Attacks" (May 96) 304 The sequence number guessing TCP vulnerability is described in 305 this document and means for defending it from exploitation are 306 discussed in this document. Some variation is implemented in most 307 modern operating systems. [RFC1948] 309 RFC 2140 I: "TCP Control Block Interdependence" (Apr 97) 311 This document suggests how TCP connections between the same 312 endpoints might share information, such as their congestion 313 control state. To some degree, this is done in practice by a few 314 modern operating systems. [RFC2140] 316 RFC 2488 B: "Enhancing TCP Over Satellite Channels using Standard 317 Mechanisms" (Jan 99) 319 From abstract: "While TCP works over satellite channels there are 320 several IETF standardized mechanisms that enable TCP to more 321 effectively utilize the available capacity of the network path. 322 This document outlines some of these TCP mitigations. At this 323 time, all mitigations discussed in this document are IETF 324 standards track mechanisms (or are compliant with IETF 325 standards)." [RFC2488] 327 RFC 2525 I: "Known TCP Implementation Problems" (Mar 99) 329 From abstract: "This memo catalogs a number of known TCP 330 implementation problems. The goal in doing so is to improve 331 conditions in the existing Internet by enhancing the quality of 332 current TCP/IP implementations." [RFC2525] 334 RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (Aug 02) 336 This document is a plea to firewall vendors not to send gratuitous 337 TCP RST (Reset) packets when unassigned TCP header bits are used. 338 This practice prevents desirable extension and evolution of the 339 protocol and hence is inimical to the future of the Internet. 340 [RFC3360] 342 RFC 3449 B: "TCP Performance Implications of Network Path Asymmetry" 343 (Dec 02) 345 From abstract: "This document describes TCP performance problems 346 that arise because of asymmetric effects. These problems arise in 347 several access networks, including bandwidth-asymmetric networks 348 and packet radio subnetworks, for different underlying reasons. 349 However, the end result on TCP performance is the same in both 350 cases: performance often degrades significantly because of 351 imperfection and variability in the ACK feedback from the receiver 352 to the sender. The document details several mitigations to these 353 effects, which have either been proposed or evaluated in the 354 literature, or are currently deployed in networks." [RFC3449] 356 RFC 3481 B: "TCP over Second (2.5G) and Third (3G) Generation 357 Wireless Networks" (Feb 03) 359 From abstract: "This document describes a profile for optimizing 360 TCP to adapt so that it handles paths including second (2.5G) and 361 third (3G) generation wireless networks." [RFC3481] 363 RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (Feb 03) 365 This document describes the de facto standard sockets API for 366 programming with TCP, which is implemented nearly ubiquitously in 367 modern operating systems and programming languages. [RFC3493] 369 4. Experimental TCP Extensions 371 These documents may one day join the standards track, but they are 372 currently not recommended for implementation. 374 RFC 2861 E: "TCP Congestion Window Validation" (Jun 00) 376 Decaying the congestion window if it hasn't been recently 377 utilized. [RFC2861] 379 RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting 380 (ABC)" (Feb 03) 382 Congestion control using number of bytes acknowledged rather than 383 number of acknowledgements received. Implemented in Linux. 384 [RFC3465] 386 RFC 3522 E: "The Eifel Detection Algorithm for TCP" (Apr 03) 388 Use of timestamps to detect spurious timeouts. [RFC3522] 390 RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling 391 with Nonces" (Jun 03) 393 Modified ECN to address security concerns. [RFC3540] 395 RFC 3649 E: "HighSpeed TCP for Large Congestion Windows" (Dec 03) 397 A modification to TCP's steady state behavior in order to 398 efficiently use very large windows is described in this document. 400 RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion 401 Windows" (Mar 04) 403 This document describes a more conservative slow-start behavoir to 404 prevent massive amounts of loss when connections use very large 405 windows. [RFC3742] 407 5. Deprecated TCP Extensions 409 The RFCs listed here define extensions that failed to arouse 410 substantial interest, or were found to be defective. 412 RFC 1146 E "TCP Alternate Checksum Options" (Mar 90) 414 This document defined a mechanism for using TCP checksums other 415 than the 16-bit ones-complement, which might be more robust. 416 [RFC1146] 418 RFC 1379 I "Extending TCP for Transactions -- Concepts" (Nov 92) 420 See RFC 1644. [RFC1379] 422 RFC 1644 E "T/TCP -- TCP Extensions for Transactions Functional 423 Specification" (Jul 94) 425 The inventors of T/TCP believed that cached connection state could 426 be used to eliminate TCP's 3-way handshake, to support single- 427 packet request/response exchanges. RFCs 1379 and 1644 show that 428 it is far from simple. Furthermore, T/TCP floundered on the ease 429 of denial-of-service attacks that can result. [RFC1644] 431 RFC 1693 E "An Extension to TCP: Partial Order Service" (Nov 94) 433 This document defines a TCP extension for applications where the 434 order that application layer objects are received in is relatively 435 unimportant, citing multimedia and database applications as 436 examples. In practice, these applications either made due with 437 the mismatch of standard TCP for their goals, or used other more 438 specialized transport protocols. [RFC1693] 440 6. Case Studies and Protocol Analysis 442 RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 92) 444 This document points out a problem with acting on received reset 445 segments while in the TIME-WAIT state. The main reccommendation 446 is that hosts in TIME-WAIT ignore resets. [RFC1337] 448 RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size" 449 (Sep 98) 451 Results of some simulations using TCP initial windows greater than 452 1 segment are presented in this document. The analysis indicates 453 that user-perceived performance can be improved by increasing the 454 initial window to 3 segments. [RFC2415] 456 RFC 2416 I: "When TCP Starts Up With Four Packets Into Only Three 457 Buffers" (Sep 98) 459 This document uses simulation results to clear up some concerns 460 about using an initial window of 4 segments when the network path 461 has less provisioning. [RFC2416] 463 RFC 2760 I: "Ongoing TCP Research Related to Satellites" (Feb 00) 465 This document discusses the advantages and disadvantages of 466 several different experimental means of improving TCP performance 467 over long-delay or error-prone paths. These include: T/TCP, 468 larger initial windows, byte counting, delayed acknowledgements, 469 slow start thresholds, NewReno and SACK-based loss recovery, FACK 470 [FACK], ECN, various corruption-detection mechanisms, congestion 471 avoidance changes for fairness, use of multiple parallel flows, 472 pacing, header compression, state sharing, and ACK congestion 473 control, filtering, and reconstruction. [RFC2760] 475 RFC 2884 I: "Performance Evaluation of Explicit Congestion 476 Notification (ECN) in IP Networks" (Jul 00) 478 This document describes experimental results that show some 479 improvements to the performance of both short and long-lived 480 connections due to ECN. [RFC2884] 482 RFC 2914 B: "Congestion Control Principles" (Sep 00) 484 The use of end-to-end congestion control for preventing congestion 485 collapse and providing fairness to TCP is motivated by this 486 document. [RFC2914] 488 RFC 2923 I: "TCP Problems with Path MTU Discovery" (Sep 00) 490 From abstract: "This memo catalogs several known Transmission 491 Control Protocol (TCP) implementation problems dealing with Path 492 Maximum Transmission Unit Discovery (PMTUD), including the 493 long-standing black hole problem, stretch acknowlegements (ACKs) 494 due to confusion between Maximum Segment Size (MSS) and segment 495 size, and MSS advertisement based on PMTU." [RFC2923] 497 RFC 2963 I: "A Rate Adaptive Shaper for Differentiated Services" (Oct 498 2000) 500 This document describes how TCP performance can be improved in 501 diffserv networks using rate adaptive shapers and color markers. 502 [RFC2963] 504 RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate 505 Link-Related Degradations" (Jun 01) 507 From abstract: "This document is a survey of Performance Enhancing 508 Proxies (PEPs) often employed to improve degraded TCP performance 509 caused by characteristics of specific link environments, for 510 example, in satellite, wireless WAN, and wireless LAN 511 environments. Different types of Performance Enhancing Proxies 512 are described as well as the mechanisms used to improve 513 performance." [RFC3135] 515 7. Tools and Tutorials 517 RFC 1180 I: "TCP/IP Tutorial" (Jan 91) This document is an extremely 518 brief overview of the TCP/IP protocol suite as a whole. It gives 519 some explanation as to how and where TCP fits in. [RFC1180] 521 RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for 522 Monitoring and Debugging TCP/IP Internets and Interconnected Devices" 523 (Jun 93) 525 A few of the tools that this document describes are still 526 maintained and in use today, such as ttcp and tcpdump, however, 527 many of the tools described do not related specifically to TCP and 528 are no longer used or easily available. [RFC1470] 530 RFC 2398 I: "Some Testing Tools for TCP Implementors" (Aug 98) 532 A number of TCP packet generation and analysis tools are described 533 in this document. While some of these tools are no longer readily 534 available or widely used, for the most part they are still 535 relevant and useable. [RFC2398] 537 8. Historical 539 The documents listed in this section contain information that is 540 largely duplicated by the standards documents in Section 2, however 541 some of them contain a greater depth of problem statement 542 explanation, or other historical context. 544 RFC 813: "Window and Acknowledgement Strategy in TCP" (July 82) 546 This document contains an early discussion of Silly Window 547 Syndrome and its avoidance, and motivates and describes the use of 548 delayed acknowledgements. [RFC0813] 550 RFC 817: "Modularity and Efficiency in Protocol Implementation" (July 551 82) 553 The suggestions for implementation in this document are general 554 and not TCP-specific, however they have been used to develop TCP 555 implementations and describe some performance implications of the 556 interactions between various layers in the Internet stack. 557 [RFC0817] 559 RFC 876: "The TCP Maximum Segment Size and Related Topics" (Nov 83) 561 Abstract: This memo discusses the TCP Maximum Segment Size Option 562 and related topics. The purposes is to clarify some aspects of 563 TCP and its interaction with IP. This memo is a clarification to 564 the TCP specification, and contains information that may be 565 considered as "advice to implementers". [RFC0876] 567 RFC 896: "Congestion Control in IP/TCP Internetworks" (Jan 84) 569 This document contains some early experiences with congestion 570 collapse and some initial thoughts on how to avoid it using 571 congestion control in TCP. [RFC0896] 573 RFC 964: "Some Problems with the Specification of the Military 574 Standard Transmission Control Protocol" (Nov 85) 576 The US Military wrote their own document defining TCP in addition 577 to RFC 793. A few serious specification bugs are detailed in RFC 578 964, reminding us of the difficulty in specification writing (even 579 when working from existing documents!). [RFC0964] 581 RFC 1066: "Management Information Base for Network Management of 582 TCP/IP-based Internets" (Aug 88) 584 This was the first document describing the TCP MIB. It is 585 obsoleted by RFC 1156. [RFC1066] 587 RFC 1072: "TCP Extensions for Long-Delay Paths" (Oct 88) 589 Early explanations of the mechanisms that were later described by 590 RFCs 1323 and 2018 are found in this document. [RFC1072] 592 RFC 1185: "TCP Extension for High-Speed Paths" (Oct 90) 594 More advanced strategies for dealing with sequence number wrapping 595 and detecting duplicates from earlier connections are outlined in 596 this document that builds on RFC 1072. [RFC1185] 598 RFC 1213 S: "Management Information Base for Network Management of 599 TCP/IP-based Internets: MIB-II" (Mar 91) 601 This document describes the second version of the MIB in a 602 monolithic form. RFC 2012 updates this document, by splitting out 603 the TCP-specific portions. [RFC1213] 605 9. Security Considerations 607 This document introduces no new security considerations. Each RFC 608 listed in this document attempts to address the security 609 considerations of the proposals it contains. 611 10. Acknowledgments 613 This document grew out of a discussion on the end2end-interest 614 mailing list, the public list of the End-to-End Research Group of the 615 IRTF. We thank Joe Touch and Reiner Ludwig for their contributions, 616 in particular. The chairs of the TCPM working group, Mark Allman and 617 Ted Faber, have been instrumental in the development of this 618 document. Keith McCloghrie provided some useful notes and 619 clarification on the various MIB-related RFCs. 621 11. References 623 11.1 Core Specification 625 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 626 793, September 1981. 628 [RFC1122] Braden, R., "Requirements for Internet Hosts - 629 Communication Layers", STD 3, RFC 1122, October 1989. 631 [RFC1156] McCloghrie, K. and M. Rose, "Management Information Base 632 for network management of TCP/IP-based internets", RFC 633 1156, May 1990. 635 [RFC1323] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions 636 for High Performance", RFC 1323, May 1992. 638 [RFC2012] McCloghrie, K., "SNMPv2 Management Information Base for 639 the Transmission Control Protocol using SMIv2", RFC 2012, 640 November 1996. 642 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 643 Selective Acknowledgment Options", RFC 2018, October 1996. 645 [RFC2452] Daniele, M., "IP Version 6 Management Information Base for 646 the Transmission Control Protocol", RFC 2452, December 647 1998. 649 [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 650 Control", RFC 2581, April 1999. 652 [RFC2873] Xiao, X., Hannan, A., Paxson, V. and E. Crabbe, "TCP 653 Processing of the IPv4 Precedence Field", RFC 2873, June 654 2000. 656 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An 657 Extension to the Selective Acknowledgement (SACK) Option 658 for TCP", RFC 2883, July 2000. 660 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 661 Timer", RFC 2988, November 2000. 663 [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing 664 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 665 January 2001. 667 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 668 Explicit Congestion Notification (ECN) to IP", RFC 3168, 669 September 2001. 671 [RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's 672 Initial Window", RFC 3390, October 2002. 674 [RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, "A 675 Conservative Selective Acknowledgment (SACK)-based Loss 676 Recovery Algorithm for TCP", RFC 3517, April 2003. 678 [RFC3782] Floyd, S., Henderson, T. and A. Gurtov, "The NewReno 679 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 680 April 2004. 682 11.2 Special Cases and Implementation Hints 684 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 685 serial links", RFC 1144, February 1990. 687 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 688 RFC 1948, May 1996. 690 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 691 April 1997. 693 [RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over 694 Satellite Channels using Standard Mechanisms", BCP 28, RFC 695 2488, January 1999. 697 [RFC2525] Paxson, V., Dawson, S., Fenner, W., Griner, J., Heavens, 698 I., Lahey, K., Semke, J. and B. Volz, "Known TCP 699 Implementation Problems", RFC 2525, March 1999. 701 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 702 BCP 60, RFC 3360, August 2002. 704 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. 705 Sooriyabandara, "TCP Performance Implications of Network 706 Path Asymmetry", BCP 69, RFC 3449, December 2002. 708 [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F. 709 Khafizov, "TCP over Second (2.5G) and Third (3G) 710 Generation Wireless Networks", BCP 71, RFC 3481, February 711 2003. 713 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. 714 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 715 3493, February 2003. 717 11.3 Experimental TCP Extensions 719 [RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion 720 Window Validation", RFC 2861, June 2000. 722 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 723 Counting (ABC)", RFC 3465, February 2003. 725 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 726 for TCP", RFC 3522, April 2003. 728 [RFC3540] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit 729 Congestion Notification (ECN) Signaling with Nonces", RFC 730 3540, June 2003. 732 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 733 RFC 3649, December 2003. 735 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 736 Congestion Windows", RFC 3742, March 2004. 738 11.4 Deprecated TCP Extensions 740 [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum 741 options", RFC 1146, March 1990. 743 [RFC1379] Braden, B., "Extending TCP for Transactions -- Concepts", 744 RFC 1379, November 1992. 746 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 747 Functional Specification", RFC 1644, July 1994. 749 [RFC1693] Connolly, T., Amer, P. and P. Conrad, "An Extension to TCP 750 : Partial Order Service", RFC 1693, November 1994. 752 11.5 Case Studies and Protocol Analysis 754 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 755 1337, May 1992. 757 [RFC2415] Poduri, K., "Simulation Studies of Increased Initial TCP 758 Window Size", RFC 2415, September 1998. 760 [RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With 761 Four Packets Into Only Three Buffers", RFC 2416, September 762 1998. 764 [RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., 765 Henderson, T., Heidemann, J., Touch, J., Kruse, H., 766 Ostermann, S., Scott, K. and J. Semke, "Ongoing TCP 767 Research Related to Satellites", RFC 2760, February 2000. 769 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 770 Explicit Congestion Notification (ECN) in IP Networks", 771 RFC 2884, July 2000. 773 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 774 2914, September 2000. 776 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 777 2923, September 2000. 779 [RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper 780 for Differentiated Services", RFC 2963, October 2000. 782 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 783 Shelby, "Performance Enhancing Proxies Intended to 784 Mitigate Link-Related Degradations", RFC 3135, June 2001. 786 11.6 Tools and Tutorials 788 [RFC1180] Socolofsky, T. and C. Kale, "TCP/IP tutorial", RFC 1180, 789 January 1991. 791 [RFC1470] Enger, R. and J. Reynolds, "FYI on a Network Management 792 Tool Catalog: Tools for Monitoring and Debugging TCP/IP 793 Internets and Interconnected Devices", RFC 1470, June 794 1993. 796 [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and 797 TCP/IP Tools and Utilities", RFC 2151, June 1997. 799 [RFC2398] Parker, S. and C. Schmechel, "Some Testing Tools for TCP 800 Implementors", RFC 2398, August 1998. 802 11.7 Historical 804 [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", 805 RFC 813, July 1982. 807 [RFC0817] Clark, D., "Modularity and efficiency in protocol 808 implementation", RFC 817, July 1982. 810 [RFC0876] Smallberg, D., "Survey of SMTP implementations", RFC 876, 811 September 1983. 813 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 814 RFC 896, January 1984. 816 [RFC0964] Sidhu, D. and T. Blumer, "Some problems with the 817 specification of the Military Standard Transmission 818 Control Protocol", RFC 964, November 1985. 820 [RFC1066] McCloghrie, K. and M. Rose, "Management Information Base 821 for network management of TCP/IP-based internets", RFC 822 1066, August 1988. 824 [RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay 825 paths", RFC 1072, October 1988. 827 [RFC1185] Jacobson, V., Braden, B. and L. Zhang, "TCP Extension for 828 High-Speed Paths", RFC 1185, October 1990. 830 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 831 for Network Management of TCP/IP-based internets:MIB-II", 832 STD 17, RFC 1213, March 1991. 834 11.8 Informative References Ouside the RFC Series 836 [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement: Refining 837 TCP Congestion Control", ACM SIGCOMM, August 1996. 839 [karn] Karn, P. and C. Partridge, "Round Trip Time Estimation", ACM 840 SIGCOMM, August 1987. 842 [vj88] Jacobson, V., "Congestion Avoidance and Control", ACM 843 SIGCOMM, August 1988. 845 Authors' Addresses 847 Martin Duke 848 Boeing Phantom Works 849 PO Box 3707, MC 3W-51 850 Seattle, WA 98124-2207 852 Phone: 253-657-8203 853 EMail: mduke26@comcast.net 854 Robert Braden 855 USC Information Sciences Institute 856 Marina del Rey, CA 90292-6695 858 Phone: 310-448-9173 859 EMail: braden@isi.edu 861 Wesley M. Eddy 862 NASA GRC/Verizon FNS 864 EMail: weddy@grc.nasa.gov 866 Ethan Blanton 867 Purdue University 869 EMail: eblanton@cs.purdue.edu 871 Intellectual Property Statement 873 The IETF takes no position regarding the validity or scope of any 874 Intellectual Property Rights or other rights that might be claimed to 875 pertain to the implementation or use of the technology described in 876 this document or the extent to which any license under such rights 877 might or might not be available; nor does it represent that it has 878 made any independent effort to identify any such rights. Information 879 on the procedures with respect to rights in RFC documents can be 880 found in BCP 78 and BCP 79. 882 Copies of IPR disclosures made to the IETF Secretariat and any 883 assurances of licenses to be made available, or the result of an 884 attempt made to obtain a general license or permission for the use of 885 such proprietary rights by implementers or users of this 886 specification can be obtained from the IETF on-line IPR repository at 887 http://www.ietf.org/ipr. 889 The IETF invites any interested party to bring to its attention any 890 copyrights, patents or patent applications, or other proprietary 891 rights that may cover technology that may be required to implement 892 this standard. Please address the information to the IETF at 893 ietf-ipr@ietf.org. 895 Disclaimer of Validity 897 This document and the information contained herein are provided on an 898 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 899 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 900 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 901 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 902 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 903 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 905 Copyright Statement 907 Copyright (C) The Internet Society (2004). This document is subject 908 to the rights, licenses and restrictions contained in BCP 78, and 909 except as set forth therein, the authors retain all their rights. 911 Acknowledgment 913 Funding for the RFC Editor function is currently provided by the 914 Internet Society.