idnits 2.17.1 draft-ietf-tcpm-tcp-roadmap-01.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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1231. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1208. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1215. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1221. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 175: '...isting the various features that MUST,...' RFC 2119 keyword, line 176: '... SHOULD, MAY, SHOULD NOT, and MUS...' RFC 2119 keyword, line 223: '...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 (January 20, 2005) is 7033 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 916 looks like a reference -- Missing reference section? 'RFC1122' on line 919 looks like a reference -- Missing reference section? 'Karn' on line 1163 looks like a reference -- Missing reference section? 'VJ88' on line 1170 looks like a reference -- Missing reference section? 'RFC2460' on line 925 looks like a reference -- Missing reference section? 'RFC2581' on line 928 looks like a reference -- Missing reference section? 'RFC2873' on line 931 looks like a reference -- Missing reference section? 'RFC2988' on line 935 looks like a reference -- Missing reference section? 'RFC1323' on line 940 looks like a reference -- Missing reference section? 'RFC3168' on line 960 looks like a reference -- Missing reference section? 'RFC3042' on line 956 looks like a reference -- Missing reference section? 'RFC3390' on line 964 looks like a reference -- Missing reference section? 'RFC3782' on line 974 looks like a reference -- Missing reference section? 'RFC2018' on line 946 looks like a reference -- Missing reference section? 'RFC2883' on line 952 looks like a reference -- Missing reference section? 'RFC3517' on line 967 looks like a reference -- Missing reference section? 'RFC1948' on line 943 looks like a reference -- Missing reference section? 'RFC1321' on line 382 looks like a reference -- Missing reference section? 'RFC2385' on line 949 looks like a reference -- Missing reference section? 'RFC3562' on line 971 looks like a reference -- Missing reference section? 'RFC2140' on line 980 looks like a reference -- Missing reference section? 'RFC3124' on line 986 looks like a reference -- Missing reference section? 'RFC2861' on line 983 looks like a reference -- Missing reference section? 'RFC3465' on line 989 looks like a reference -- Missing reference section? 'Savage' on line 1166 looks like a reference -- Missing reference section? 'RFC3522' on line 992 looks like a reference -- Missing reference section? 'RFC3540' on line 995 looks like a reference -- Missing reference section? 'RFC3649' on line 999 looks like a reference -- Missing reference section? 'RFC3708' on line 1002 looks like a reference -- Missing reference section? 'RFC3742' on line 1008 looks like a reference -- Missing reference section? 'RFC1106' on line 1013 looks like a reference -- Missing reference section? 'RFC1110' on line 1016 looks like a reference -- Missing reference section? 'RFC1146' on line 1019 looks like a reference -- Missing reference section? 'RFC1263' on line 1022 looks like a reference -- Missing reference section? 'RFC1379' on line 1025 looks like a reference -- Missing reference section? 'RFC1644' on line 1028 looks like a reference -- Missing reference section? 'RFC1693' on line 1031 looks like a reference -- Missing reference section? 'RFC0813' on line 1036 looks like a reference -- Missing reference section? 'RFC0814' on line 1039 looks like a reference -- Missing reference section? 'RFC0816' on line 1042 looks like a reference -- Missing reference section? 'RFC0817' on line 1045 looks like a reference -- Missing reference section? 'RFC0872' on line 1048 looks like a reference -- Missing reference section? 'RFC0896' on line 1053 looks like a reference -- Missing reference section? 'RFC0964' on line 1056 looks like a reference -- Missing reference section? 'RFC1072' on line 1064 looks like a reference -- Missing reference section? 'RFC1185' on line 1074 looks like a reference -- Missing reference section? 'RFC2914' on line 1127 looks like a reference -- Missing reference section? 'RFC2488' on line 1107 looks like a reference -- Missing reference section? 'RFC2757' on line 1115 looks like a reference -- Missing reference section? 'RFC2760' on line 1118 looks like a reference -- Missing reference section? 'FACK' on line 1160 looks like a reference -- Missing reference section? 'RFC3135' on line 1133 looks like a reference -- Missing reference section? 'RFC3449' on line 1140 looks like a reference -- Missing reference section? 'RFC3481' on line 1144 looks like a reference -- Missing reference section? 'RFC3819' on line 1153 looks like a reference -- Missing reference section? 'RFC0879' on line 1050 looks like a reference -- Missing reference section? 'RFC2525' on line 1111 looks like a reference -- Missing reference section? 'RFC2923' on line 1130 looks like a reference -- Missing reference section? 'RFC3360' on line 1137 looks like a reference -- Missing reference section? 'RFC3493' on line 1149 looks like a reference -- Missing reference section? 'RFC1066' on line 1060 looks like a reference -- Missing reference section? 'RFC1156' on line 1067 looks like a reference -- Missing reference section? 'RFC1213' on line 1077 looks like a reference -- Missing reference section? 'RFC2012' on line 1089 looks like a reference -- Missing reference section? 'RFC2452' on line 1103 looks like a reference -- Missing reference section? 'RFC1180' on line 1071 looks like a reference -- Missing reference section? 'RFC1470' on line 1084 looks like a reference -- Missing reference section? 'RFC2398' on line 1093 looks like a reference -- Missing reference section? 'RFC1337' on line 1081 looks like a reference -- Missing reference section? 'RFC2415' on line 1096 looks like a reference -- Missing reference section? 'RFC2416' on line 1099 looks like a reference -- Missing reference section? 'RFC2884' on line 1123 looks like a reference -- Missing reference section? 'RFC2147' on line 922 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 80 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group M. Duke 2 Internet-Draft Boeing Phantom Works 3 Expires: July 21, 2005 R. Braden 4 USC Information Sciences Institute 5 W. Eddy 6 NASA GRC/Verizon FNS 7 E. Blanton 8 Purdue University 9 January 20, 2005 11 A Roadmap for TCP Specification Documents 12 draft-ietf-tcpm-tcp-roadmap-01 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on July 21, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). 45 Abstract 47 This document contains a "roadmap" to the Requests for Comments (RFC) 48 documents relating to the Internet's Transmission Control Protocol 49 (TCP). This roadmap provides a brief summary of the documents 50 defining TCP and various TCP extensions that have accumulated in the 51 RFC series. This serves as a guide and quick reference for both TCP 52 implementers and other parties who desire information contained in 53 the TCP-related RFCs. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Basic Functionality . . . . . . . . . . . . . . . . . . . . . 5 59 3. Standard Enhancements . . . . . . . . . . . . . . . . . . . . 7 60 3.1 Congestion Control and Loss Recovery Extensions . . . . . 7 61 3.2 SACK-based Loss Recovery and Congestion Control . . . . . 9 62 3.3 Dealing with Forged Segments . . . . . . . . . . . . . . . 9 63 4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 11 64 5. Historic Extensions . . . . . . . . . . . . . . . . . . . . . 13 65 6. Support Documents . . . . . . . . . . . . . . . . . . . . . . 15 66 6.1 Foundational Works . . . . . . . . . . . . . . . . . . . . 15 67 6.2 Difficult Network Environments . . . . . . . . . . . . . . 16 68 6.3 Implementation Advice . . . . . . . . . . . . . . . . . . 18 69 6.4 Management Information Bases . . . . . . . . . . . . . . . 19 70 6.5 Tools and Tutorials . . . . . . . . . . . . . . . . . . . 20 71 6.6 Case Studies . . . . . . . . . . . . . . . . . . . . . . . 21 72 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 73 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 74 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 75 9.1 Basic Functionality . . . . . . . . . . . . . . . . . . . 25 76 9.2 Standard Enhancements . . . . . . . . . . . . . . . . . . 25 77 9.3 Experimental Extensions . . . . . . . . . . . . . . . . . 26 78 9.4 Historic Extensions . . . . . . . . . . . . . . . . . . . 27 79 9.5 Support Documents . . . . . . . . . . . . . . . . . . . . 27 80 9.6 Informative References Outside the RFC Series . . . . . . 30 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 82 Intellectual Property and Copyright Statements . . . . . . . . 32 84 1. Introduction 86 A correct and efficient implementation of the Transmission Control 87 Protocol (TCP) [RFC0793] is a critical part of the software of most 88 Internet hosts. As TCP has evolved over the years, many distinct 89 documents have become part of the accepted standard for TCP. At the 90 same time, a large number of more experimental modifications to TCP 91 have also been published in the RFC series, along with informational 92 notes, case studies, and other advice. 94 As an introduction to newcomers and an attempt to organize the 95 plethora of information for old hands, this document contains a 96 "roadmap" to the TCP-related RFCs. It provides a brief summary of 97 the RFC documents that define TCP. This should provide guidance to 98 implementers on the relevance and significance of the standards track 99 extensions, informational notes, and best current practices that 100 relate to TCP. 102 This roadmap includes a brief description of the contents of each 103 TCP-related RFC. In some cases, we simply supply the abstract or a 104 key summary sentence from the text as a terse description. In 105 addition, a letter code after each RFC number indicates its category 106 in the RFC series: 108 S - Standards Track (Proposed Standard, Draft Standard, or 109 Standard) 110 E - Experimental 111 B - Best Current Practice 112 I - Informational 114 Note that the category of an RFC does not necessarily reflect its 115 current relevance. For instance, RFC 2581 is nearly universally 116 deployed although it is only a Proposed Standard. Similarly, some 117 Informational RFCs contain significant technical proposals for 118 changing TCP. 120 This roadmap is divided into four main sections. Section 2 lists the 121 RFCs that describe absolutely required TCP behaviors for proper 122 functioning and interoperability. Further RFCs that describe 123 strongly encouraged, but not essential, behaviors are listed in 124 Section 3. Experimental extensions which are not yet standard 125 practices, but potentially could be in the future, are described in 126 Section 4. 128 The reader probably notices that these three sections are broadly 129 equivalent to MUST/SHOULD/MAY specifications, and while the authors 130 support this intuition, this document is merely descriptive; it does 131 not represent a binding standards track position. An individual 132 implementor still needs to examine the standards documents themselves 133 to evaluate specific requirement levels. 135 A small number of older experimental extensions which have not caught 136 on are noted in Section 5. Many other supporting documents that are 137 relevant to the development, implementation, and deployment of TCP 138 are described in Section 6. Within each section, RFCs are listed in 139 chronological order. 141 2. Basic Functionality 143 A small number of documents compose the core specification of TCP. 144 These define the required basic functionalities of TCP's header 145 parsing, state machine, congestion control, and retransmission 146 timeout computation. These base specifications must be correctly 147 followed for interoperability. 149 RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981) 151 This is the fundamental TCP specification document [RFC0793]. 152 Written by Jon Postel as part of the Internet protocol suite's 153 core, it describes the TCP packet format, the TCP state machine 154 and event processing, and TCP's semantics for data transmission, 155 reliability, flow control, multiplexing, and acknowledgement. 157 Section 3.6 of RFC 793, describing TCP's handling of the IP 158 precedence and security compartment, is mostly irrelevant today. 159 RFC 2873 changed the IP precedence handling, and the security 160 compartment portion of the API is no longer implemented or used. 161 In addition, RFC 793 did not describe any congestion control 162 mechanism. Otherwise, however, the majority of this document 163 still acurately describes modern TCPs. RFC 793 is the last of a 164 series of developmental TCP specifications, starting from IENs and 165 continuing in the RFC series. 167 RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" 168 (October 1989) 170 This document [RFC1122] updates and clarifies RFC 793, fixing some 171 specification bugs and oversights. It also explains some features 172 such as keep-alives and Karn's and Jacobson's RTO estimation 173 algorithms [Karn][VJ88]. ICMP interactions are mentioned and some 174 tips are given for efficient implementation. RFC 1122 is an 175 Applicability Statement, listing the various features that MUST, 176 SHOULD, MAY, SHOULD NOT, and MUST NOT be present in 177 standards-conforming TCP implementations. 179 RFC 2147 S: "TCP and UDP over IPv6 Jumbograms" (May 1997) 181 IPv6's support for longer datagrams than were allowed in IPv4, 182 necessitated some changes to the way that TCP's MSS and Urgent 183 fields (both 16 bits) are treated. 185 RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification 186 (December 1998) 188 This document [RFC2460] makes a slight update to the way the 189 pseudo-header for checksum computation is derived, defining the 190 process for IPv6 in addition to the previous practice for IPv4. 192 RFC 2581 S: "TCP Congestion Control" (April 1999) 194 Although RFC 793 did not contain any congestion control 195 mechanisms, today congestion control is a required component of 196 TCP implementations. This document [RFC2581] defines the current 197 versions of Van Jacobson's congestion avoidance and control 198 mechanisms for TCP, based on his 1988 SIGCOMM paper [VJ88]. RFC 199 2001 was a conceptual precursor that was obsoleted by RFC 2581. 201 A number of behaviors that together comprise what the community 202 refers to as "Reno TCP", are described in RFC 2581. The name 203 "Reno" comes from the Net/2 release of the 4.3 BSD operating 204 system. This is generally regarded as the least common 205 denominator among TCP flavors currently found running on Internet 206 hosts. Reno TCP includes the congestion control features of slow 207 start, congestion avoidance, fast retransmit, and fast recovery. 209 RFC 2873 S: "TCP Processing of the IPv4 Precendence Field" (June 210 2000) 212 This document [RFC2873] removes from the TCP specification all 213 processing of the precedence bits of the TOS byte of the IP 214 header. This resolves a conflict over the use of these bits 215 between RFC 793 and Differentiated Services. 217 RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000) 219 Abstract: "This document defines the standard algorithm that 220 Transmission Control Protocol (TCP) senders are required to use to 221 compute and manage their retransmission timer. It expands on the 222 discussion in section 4.2.3.1 of RFC 1122 and upgrades the 223 requirement of supporting the algorithm from a SHOULD to a MUST." 224 [RFC2988] 226 3. Standard Enhancements 228 This section describes recommended TCP modifications that improve 229 performance and security. RFCs 1323 and 3168 represent fundamental 230 changes to the protocol. RFC 1323, based on RFCs 1072 and 1185, 231 allows better utilization of high bandwidth-delay product paths by 232 providing some needed mechanisms for high-rate transfers. RFC 3168 233 describes a change to the Internet's architecture, where routers 234 signal end-hosts of growing congestion levels, and can do so before 235 packet losses are forced. Section 3.1 lists improvements in the 236 congestion control and loss recovery mechanisms specified in RFC 237 2581. Section 3.2 describes further refinements that make use of 238 selective acknowledgements. Section 3.3 deals with the problem of 239 preventing forged segments. 241 RFC 1323 S: "TCP Extensions for High Performance" (May 1992) 243 This document [RFC1323] defines TCP extensions for window scaling, 244 timestamps, and protection against wrapped sequence numbers, for 245 efficient and safe operation over paths with large bandwidth-delay 246 products. These extensions are commonly found in currently-used 247 systems; however, they may require manual tuning and 248 configuration. Some "corner cases" in this specification are 249 still under discussion. 251 RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN) 252 to IP" (September 2001) 254 This document [RFC3168] defines a means of detecting congestion 255 without resorting to packet loss. Although congestion 256 notification takes place at the IP level, ECN requires support at 257 the transport level (e.g., in TCP) to echo the bits and adapt the 258 sending rate. This document updates RFC 793 to define two 259 previously-unused flag bits in the TCP header for ECN support. 260 RFC 3540 provides a supplementary (experimental) means for making 261 ECN use more secure, and RFC 2884 provides some sample results 262 from using ECN. 264 3.1 Congestion Control and Loss Recovery Extensions 266 Two of the most important aspects of TCP are its congestion control 267 and loss recovery features. Since TCP traditionally (in the absence 268 of ECN) uses losses to infer congestion, there is a rather intimate 269 coupling between congestion control and loss recovery mechanisms. 270 There are several extensions to both features, and more often than 271 not, a particular extension applies to both. In this sub-section, we 272 group enhancements to either congestion control, loss recovery, or 273 both, which can be performed unilaterally - without negotiating 274 support between endpoints. In the next sub-section, we group the 275 extensions which specify or rely on the SACK option, whose use must 276 be negotiated bilaterally. TCP implementations should include the 277 enhancements from both sub-sections so that they can perform well 278 without regard to the feature sets of other hosts they connect to. 279 For example, if SACK use is not successfully negotiated, a TCP should 280 use the NewReno behavior as a fall-back. 282 RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit" 283 (January 2001) 285 Abstract: "This document proposes [Limited Transmit,] a new 286 Transmission Control Protocol (TCP) mechanism that can be used to 287 more effectively recover lost segments when a connection's 288 congestion window is small, or when a large number of segments are 289 lost in a single transmission window." [RFC3042] 291 RFC 3390 S: "Increasing TCP'S Initial Window" (October 2002) 293 This document [RFC3390] updates RFC 2581 to permit an initial TCP 294 window larger that one packet during in the slow-start phase. 296 RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery 297 Algorithm" (April 2004) 299 This document [RFC3782] specifies a slight modification to the 300 standard Reno fast recovery algorithm, whereby a TCP sender can 301 use partial acknowledgements to make inferences determining the 302 next segment to send in situations where SACK would be helpful, 303 but isn't available. 305 Work in progress: The Eifel Response Algorithm for TCP (Internet 306 Draft name: draft-ietf-tsvwg-tcp-eifel-response) 308 At the time of this writing, work on this document (from authors 309 Reiner Ludwig and Andrei Gurtov) had stabilized within the 310 Transport Area Working Group, and the document was planned to 311 become a Proposed Standard, pending IESG review, but was not yet a 312 part of the RFC series. This document describes the response 313 portion of the Eifel algorithm, which can be used in conjunction 314 with one of several methods of detecting when loss recovery has 315 been spuriously entered, such as the Eifel detection algorithm in 316 RFC 3522, the algorithm in RFC 3708, or F-RTO. 318 Abstract: "Based on an appropriate detection algorithm, the Eifel 319 response algorithm provides a way for a TCP sender to respond to a 320 detected spurious timeout. It adapts the retransmission timer to 321 avoid further spurious timeouts, and can avoid - depending on the 322 detection algorithm - the often unnecessary go-back-N retransmits 323 that would otherwise be sent. In addition, the Eifel response 324 algorithm restores the congestion control state in such a way that 325 packet bursts are avoided." 327 3.2 SACK-based Loss Recovery and Congestion Control 329 The base TCP specification in RFC 793 provided only a simple 330 cumulative acknowledgment mechanism. However, a selective 331 acknowledgment (SACK) mechanism provides significant performance 332 improvement in the presence of packet losses, more than outweighing 333 the modest increase in complexity. A TCP should be expected to 334 implement SACK, however SACK is a negotiated option and is only used 335 if support is advertised by both sides of a connection. 337 RFC 2018 S: "TCP Selective Acknowledgement Options" (October 1996) 339 This document [RFC2018] defines the basic selective 340 acknowledgement (SACK) mechanism for TCP. 342 RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK) 343 Option for TCP" (July 2000) 345 This document [RFC2883] extends RFC 2018 to cover the case of 346 acknowledging duplicate packets. 348 RFC 3517 S: "A Conservative Selective Acknowledgement (SACK)-based 349 Loss Recovery Algorithm for TCP" (April 2003) 351 This document [RFC3517] describes a relatively sophisticated 352 algorithm that a TCP sender can use for loss recovery when SACK 353 reports more than one segment lost from a single flight of data. 354 While support for the exchange of SACK information is widely 355 implemented, not all implementations use an algorithm as 356 sophisticated as that described in RFC 3517. 358 3.3 Dealing with Forged Segments 360 By default, TCP lacks any cryptographic structures to differentiate 361 legitimate segments and those spoofed from malicious hosts. Spoofing 362 valid segments requires correctly guessing a number of fields. The 363 documents in this sub-section describe ways to make that guessing 364 harder, or prevent it from being able to negatively impact a 365 connection. 367 RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996) 369 This document [RFC1948] describes the TCP vulnerability based upon 370 guessing sequence numbers and as well as defenses against this 371 exploit. Some variation is implemented in most currently-used 372 operating systems. 374 RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature 375 Option" (August 1998) 377 From document: "This document describes currrent existing practice 378 for securing BGP against certain simple attacks. It is understood 379 to have security weaknesses against concerted attacks. 381 This memo describes a TCP extension to enhance security for BGP. 382 It defines a new TCP option for carrying an MD5 [RFC1321] digest 383 in a TCP segment. This digest acts like a signature for that 384 segment, incorporating information known only to the connection 385 end points. Since BGP uses TCP as its transport, using this 386 option in the way described in this paper significantly reduces 387 the danger from certain security attacks on BGP." [RFC2385] 389 TCP MD5 options are currently only used in very limited contexts, 390 primarily for defending BGP exchanges between routers. Some 391 deployment notes for those using TCP MD5 are found in the later 392 RFC 3562, "Key Management Considerations for the TCP MD5 Signature 393 Option" [RFC3562]. 395 Work in progress: Transmission Control Protocol Security 396 Considerations (Internet Draft name: draft-ietf-tcpm-tcpsecure) 398 At the time of this writing, the TCP Maintenance and Minor 399 Extensions Working Group is producing a document (edited by Mitesh 400 Dalal) which describes a challenge-response mechanism for securing 401 TCP against spoofed control segments. This document is expected 402 to become an RFC in the near future. 404 4. Experimental Extensions 406 The RFCs in this section are still experimental, but may become 407 proposed standards in the future. At least part of the reason that 408 they are still experimental is to gain more wide-scale experience 409 with them before making a standards track decision. 411 RFC 2140 I: "TCP Control Block Interdependence" (April 1997) 413 This document [RFC2140] suggests how TCP connections between the 414 same endpoints might share information, such as their congestion 415 control state. To some degree, this is done in practice by a few 416 operating systems; for example, Linux has a destination cache. 418 A related proposal, the Congestion Manager, is specified in RFC 419 3124 [RFC3124]. The idea behind the Congestion Manager, moving 420 congestion control outside of individual TCP connections, 421 represents a modification to the core of TCP. Although a Proposed 422 Standard, some pieces of the Congestion Manager support 423 architecture have not been specified yet, and it has not achieved 424 use or implementation beyond experimental stacks. 426 RFC 2861 E: "TCP Congestion Window Validation" (June 2000) 428 This document [RFC2861] suggests reducing the congestion window 429 over time when no packets are flowing. 431 RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting 432 (ABC)" (February 2003) 434 This document [RFC3465] suggests that congestion control use the 435 number of bytes acknowledged rather than the number of 436 acknowledgements received. This has been implemented in Linux. 437 The ABC mechanism behaves differently than the standard means when 438 there is not a one-to-one relationship between data segments and 439 acknowledgements. ABC still operates within the accepted 440 guidelines, but is more robust to delayed ACKs and ACK-division 441 [Savage]. 443 RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003) 445 This document [RFC3522] suggests using timestamps to detect 446 spurious timeouts. 448 RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling 449 with Nonces" (June 2003) 451 This document [RFC3540] suggests a modified ECN to address 452 security concerns, and updates RFC 3168. 454 RFC 3649 E: "HighSpeed TCP for Large Congestion Windows" (December 455 2003) 457 This document [RFC3649] suggests a modification to TCP's 458 steady-state behavior to efficiently use very large windows. 460 RFC 3708 E: "Using TCP Duplicate Selective Acknowledgement (DSACKs) 461 and Stream Control Transmission Protocol (SCTP) Duplicate 462 Transmission Sequence Numbers (TSNs) to Detect Spurious 463 Retransmissions" (February 2004) 465 Abstract: "TCP and Stream Control Transmission Protocol (SCTP) 466 provide notification of duplicate segment receipt through 467 Duplicate Selective Acknowledgement (DSACKs) and Duplicate 468 Transmission Sequence Number (TSN) notification, respectively. 469 This document presents conservative methods of using this 470 information to identify unnecessary retransmissions for various 471 applications." [RFC3708] 473 RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion 474 Windows" (March 2004) 476 This document [RFC3742] describes a more conservative slow-start 477 behavior to prevent massive packet losses when a connection uses a 478 very large window. 480 Work in progress: Forward RTO-Recovery (F-RTO): An Algorithm for 481 Detecting Spurious Retransmission Timeouts with TCP and SCTP 482 (Internet Draft name: draft-ietf-tcpm-frto) 484 The F-RTO detection algorithm provides another option for 485 inferring spurious retransmission timeouts. At the time of this 486 writing, the TCP Maintenance and Minor Extensions Working Group 487 had completed a document describing F-RTO (by Pasi Sarolahti and 488 Markku Kojo), and planned to make this an Experimental part of the 489 RFC series, pending IESG review. 491 5. Historic Extensions 493 The RFCs listed here define extensions that have thus far failed to 494 arouse substantial interest, or were found to be defective. 496 RFC 1106 "TCP Big Window and NAK Options" (June 1989) 498 This RFC [RFC1106] defined an alternative to the Window Scale 499 option for using large windows, and described the "negative 500 acknowledgement" or NAK option. There is a comparison of NAK and 501 SACK methods, and early discussion of TCP over satellite issues. 502 The options described in this document have not been adopted by 503 the larger community, although NAKs are used in the SCPS-TP 504 adaptation of TCP, developed by the Consultive Committee for Space 505 Data Systems (CCSDS). 507 RFC 1110 "A Problem with the TCP Big Window Option" (August 1989) 509 Abstract: "The TCP Big Window option discussed in RFC 1106 will 510 not work properly in an Internet environment which has both a high 511 bandwidth * delay product and the possibility of disordering and 512 duplicating packets. In such networks, the window size must not 513 be increased without a similar increase in the sequence number 514 space. Therefore, a different approach to big windows should be 515 taken in the Internet." [RFC1110] 517 RFC 1146 E "TCP Alternate Checksum Options" (March 1990) 519 This document [RFC1146] defined more robust TCP checksums than the 520 16-bit ones-complement in use today. A typographical error in RFC 521 1145 is fixed in RFC 1146, otherwise the documents are the same. 523 RFC 1263 "TCP Extensions Considered Harmful" (October 1991) 525 This interesting document [RFC1263] argues against "backwards 526 compatible" TCP extensions. Specifically mentioned are several 527 TCP enhancements that have been successful, including timestamps, 528 window scaling, PAWS, and SACK. RFC 1263 presents an alternative 529 approach called "protocol evolution", whereby several evolutionary 530 versions of TCP would exist on hosts. These distinct TCP versions 531 would represent upgrades to each other and could be 532 header-incompatible. Interoperability would be provided by having 533 a virtualization layer select the right TCP version for a 534 particular connection. This idea did not catch on with the 535 community, while the type of extensions RFC 1263 specifically 536 targeted as harmful did become popular. 538 RFC 1379 I "Extending TCP for Transactions -- Concepts" (November 539 1992) 541 See RFC 1644. 543 RFC 1644 E "T/TCP -- TCP Extensions for Transactions Functional 544 Specification" (July 1994) 546 The inventors of TCP believed that cached connection state could 547 have been used to eliminate TCP's 3-way handshake, to support 548 two-packet request/response exchanges. RFCs 1379 [RFC1379] and 549 1644 [RFC1644] show that this is far from simple. Furthermore, 550 T/TCP floundered on the ease of denial-of-service attacks that can 551 result. 553 RFC 1693 E "An Extension to TCP: Partial Order Service" (November 554 1994) 556 This document [RFC1693] defines a TCP extension for applications 557 that do not care about the order in which application-layer 558 objects are received. Examples are multimedia and database 559 applications. In practice, these applications either accept the 560 possible performance loss because of TCP's strict ordering, or 561 they use more specialized transport protocols. 563 6. Support Documents 565 This section contains several classes of documents that do not 566 necessarily define current protocol behaviors, but are nevertheless 567 of interest to TCP implementors. Section 6.1 describes several 568 foundational RFCs that give modern readers a better understanding of 569 the principles underlying TCP's behaviors and development over the 570 years. The documents listed in Section 6.2 provide advice on using 571 TCP in various types of network situations that pose challenges above 572 those of typical wired links. Some implementation notes can be found 573 in Section 6.3. The TCP Management Information Bases are described 574 in Section 6.4. RFCs that describe tools for testing and debugging 575 TCP implementations or contain high-level tutorials on the protocol 576 are listed Section 6.5, while Section 6.6 lists a number of case 577 studies that have explored TCP performance. 579 6.1 Foundational Works 581 The documents listed in this section contain information that is 582 largely duplicated by the standards documents previously discussed. 583 However, some of them contain a greater depth of problem statement 584 explanation or other context. Particularly, RFCs 813-817 (known as 585 the "Dave Clark Five"), describe some early problems and solutions 586 (RFC 815 only describes the reassembly of IP fragments, and is not 587 included here). 589 RFC 813: "Window and Acknowledgement Strategy in TCP" (July 1982) 591 This document [RFC0813] contains an early discussion of Silly 592 Window Syndrome and its avoidance, and motivates and describes the 593 use of delayed acknowledgements. 595 RFC 814: "Name, Addresses, Ports, and Routes" (July 1982) 597 Suggestions and guidance for the design of tables and algorithms 598 to keep track of various identifiers within a TCP/IP 599 implementation are provided by this document [RFC0814]. 601 RFC 816: "Fault Isolation and Recovery" (July 1982) 603 In this document [RFC0816], TCP's response to indications of 604 network error conditions such as timeouts or received ICMP 605 messages. 607 RFC 817: "Modularity and Efficiency in Protocol Implementation" (July 608 1982) 610 This document [RFC0817] contains implementation suggestions that 611 are general and not TCP-specific. However they have been used to 612 develop TCP implementations and describe some performance 613 implications of the interactions between various layers in the 614 Internet stack. 616 RFC 872: "TCP-ON-A-LAN" (September 1982) 618 Conclusion: "The sometimes-expressed fear that using TCP on a 619 local net is a bad idea is unfounded." [RFC0872] 621 RFC 896: "Congestion Control in IP/TCP Internetworks" (January 1984) 623 This document [RFC0896] contains some early experiences with 624 congestion collapse and some initial thoughts on how to avoid it 625 using congestion control in TCP. 627 RFC 964: "Some Problems with the Specification of the Military 628 Standard Transmission Control Protocol" (November 1985) 630 This document [RFC0964] was prepared by the US Military to define 631 TCP in greater detail than RFC 793. A few serious specification 632 bugs are detailed in RFC 964, reminding us of the difficulty in 633 specification writing (even when working from existing 634 documents!). 636 RFC 1072: "TCP Extensions for Long-Delay Paths" (October 1988) 638 This document [RFC1072] contains early explanations of the 639 mechanisms that were later described by RFCs 1323 and 2018, which 640 obsolete it. 642 RFC 1185: "TCP Extension for High-Speed Paths" (October 1990) 644 This document [RFC1185] builds on RFC 1072 to describe more 645 advanced strategies for dealing with sequence number wrapping and 646 detecting duplicates from earlier connections. This document was 647 obsoleted by RFC 1323. 649 RFC 2914 B: "Congestion Control Principles" (September 2000) 651 This document [RFC2914] motivates the use of end-to-end congestion 652 control for preventing congestion collapse and providing fairness 653 to TCP. 655 6.2 Difficult Network Environments 657 As the internetworking field has explored wireless, satellite, 658 cellular telephone, and other kinds of link-layer technologies, a 659 large body of work has built up on enhancing TCP performance for such 660 links. The RFCs listed in this section describe some of these more 661 challenging network environments and how TCP interacts with them. 663 RFC 2488 B: "Enhancing TCP Over Satellite Channels using Standard 664 Mechanisms" (January 1999) 666 From abstract: "While TCP works over satellite channels there are 667 several IETF standardized mechanisms that enable TCP to more 668 effectively utilize the available capacity of the network path. 669 This document outlines some of these TCP mitigations. At this 670 time, all mitigations discussed in this document are IETF 671 standards track mechanisms (or are compliant with IETF 672 standards)." [RFC2488] 674 RFC 2757 I: "Long Thin Networks" (January 2000) 676 Several methods of improving TCP performance over long thin 677 networks, such as geosynchronous satellite links, are discussed in 678 this document [RFC2757]. A particular set of TCP options is 679 developed that should work well in such environments, and be safe 680 to use in the global Internet. 682 RFC 2760 I: "Ongoing TCP Research Related to Satellites" (February 683 2000) 685 This document [RFC2760] discusses the advantages and disadvantages 686 of several different experimental means of improving TCP 687 performance over long-delay or error-prone paths. These include: 688 T/TCP, larger initial windows, byte counting, delayed 689 acknowledgements, slow start thresholds, NewReno and SACK-based 690 loss recovery, FACK [FACK], ECN, various corruption-detection 691 mechanisms, congestion avoidance changes for fairness, use of 692 multiple parallel flows, pacing, header compression, state 693 sharing, and ACK congestion control, filtering, and 694 reconstruction. While RFC 2488 looks at standard extensions, this 695 document focuses on more experimental means of performance 696 enhancement. 698 RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate 699 Link-Related Degradations" (June 2001) 701 From abstract: "This document is a survey of Performance Enhancing 702 Proxies (PEPs) often employed to improve degraded TCP performance 703 caused by characteristics of specific link environments, for 704 example, in satellite, wireless WAN, and wireless LAN 705 environments. Different types of Performance Enhancing Proxies 706 are described as well as the mechanisms used to improve 707 performance." [RFC3135] 709 RFC 3449 B: "TCP Performance Implications of Network Path Asymmetry" 710 (December 2002) 712 From abstract: "This document describes TCP performance problems 713 that arise because of asymmetric effects. These problems arise in 714 several access networks, including bandwidth-asymmetric networks 715 and packet radio subnetworks, for different underlying reasons. 716 However, the end result on TCP performance is the same in both 717 cases: performance often degrades significantly because of 718 imperfection and variability in the ACK feedback from the receiver 719 to the sender. 721 The document details several mitigations to these effects, which 722 have either been proposed or evaluated in the literature, or are 723 currently deployed in networks." [RFC3449] 725 RFC 3481 B: "TCP over Second (2.5G) and Third (3G) Generation 726 Wireless Networks" (February 2003) 728 From abstract: "This document describes a profile for optimizing 729 TCP to adapt so that it handles paths including second (2.5G) and 730 third (3G) generation wireless networks." [RFC3481] 732 RFC 3819 B: "Advice for Internet Subnetwork Designers" (July 2004) 734 This document [RFC3819] describes how TCP performance can be 735 negatively impacted by some particular lower-layer behaviors, and 736 provides guidance in designing lower-layer networks and protocols 737 to be amicable to TCP. 739 6.3 Implementation Advice 741 RFC 879: "The TCP Maximum Segment Size and Related Topics" (November 742 1983) 744 Abstract: 'This memo discusses the TCP Maximum Segment Size Option 745 and related topics. The purposes is to clarify some aspects of 746 TCP and its interaction with IP. This memo is a clarification to 747 the TCP specification, and contains information that may be 748 considered as "advice to implementers".' [RFC0879] 750 RFC 2525 I: "Known TCP Implementation Problems" (March 1999) 752 From abstract: "This memo catalogs a number of known TCP 753 implementation problems. The goal in doing so is to improve 754 conditions in the existing Internet by enhancing the quality of 755 current TCP/IP implementations." [RFC2525] 757 RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000) 759 From abstract: "This memo catalogs several known Transmission 760 Control Protocol (TCP) implementation problems dealing with Path 761 Maximum Transmission Unit Discovery (PMTUD), including the 762 long-standing black hole problem, stretch acknowlegements (ACKs) 763 due to confusion between Maximum Segment Size (MSS) and segment 764 size, and MSS advertisement based on PMTU." [RFC2923] 766 RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August 767 2002) 769 This document [RFC3360] is a plea that firewall vendors not send 770 gratuitous TCP RST (Reset) packets when unassigned TCP header bits 771 are used. This practice prevents desirable extension and 772 evolution of the protocol and hence is inimical to the future of 773 the Internet. 775 RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (February 776 2003) 778 This document [RFC3493] describes the de facto standard sockets 779 API for programming with TCP. This API is implemented nearly 780 ubiquitously in modern operating systems and programming 781 languages. 783 6.4 Management Information Bases 785 The first MIB module defined for use with SNMP (in RFC 1066 and its 786 update, RFC 1156) was a single monolithic MIB module, called MIB-I. 787 This evolved over time to be MIB-II (RFC 1213). It then became 788 apparent that having a single monolithic MIB module was not scalable, 789 given the number and breadth of MIB data definitions that needed to 790 be included. Thus, additional MIB modules were defined, and those 791 parts of MIB-II which needed to evolve were split off. Eventually, 792 the remaining parts of MIB-II were also split off, with the 793 TCP-specific part being documented in RFC 2012. 795 RFC 2012 is the primary document for MIB-II. MIB-I, defined in RFC 796 1156, has been obsoleted by the MIB-II specification in RFC 1213 797 (updated by 2012). Work is in progress, at the time of this writing, 798 on a document that incorporates IPv6 and updates and obsoletes RFC 799 2012 (currently in the form of draft-ietf-ipv6-rfc2012-update, edited 800 by Rajiv Raghunarayan, under submission to the IESG as a Proposed 801 Standard). 803 RFC 1066: "Management Information Base for Network Management of 804 TCP/IP-based Internets" (August 1988) 806 This document [RFC1066] was the description of the TCP MIB. It 807 was obsoleted by RFC 1156. 809 RFC 1156 S: "Management Information Base for Network Management of 810 TCP/IP-based Internets" (May 1990) 812 This document [RFC1156] describes the required MIB fields for TCP 813 implementations, with minor corrections and no technical changes 814 from RFC 1066, which it obsoletes. This is the standards track 815 document for MIB-I. 817 RFC 1213 S: "Management Information Base for Network Management of 818 TCP/IP-based Internets: MIB-II" (March 1991) 820 This document [RFC1213] describes the second version of the MIB in 821 a monolithic form. RFC 2012 updates this document by splitting 822 out the TCP-specific portions. 824 RFC 2012 S: "SNMPv2 Management Information Base for the Transmission 825 Control Protocol using SMIv2" (November 1996) 827 This document [RFC2012] defines the TCP MIB, updating RFC 1213. 829 RFC 2452 S: "IP Version 6 Management Information Base for the 830 Transmission Control Protocol" (December 1998) 832 This document [RFC2452] augments RFC 2012 by adding an 833 IPv6-specific connection table. The rest of 2012 holds for any IP 834 version. 836 Although it is a standards track document, RFC 2452 is considered 837 a historic mistake by the MIB community, as it is based on the 838 idea of parallel IPv4 and IPv6 structures. Although IPv6 requires 839 new structures, the community has decided to define a single 840 generic structure for both IPv4 and IPv6. This will aid in 841 definition, implementation, and transition between IPv4 and IPv6. 843 6.5 Tools and Tutorials 844 RFC 1180 I: "TCP/IP Tutorial" (January 1991) 846 This document [RFC1180] is an extremely brief overview of the 847 TCP/IP protocol suite as a whole. It gives some explanation as to 848 how and where TCP fits in. 850 RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for 851 Monitoring and Debugging TCP/IP Internets and Interconnected Devices" 852 (June 1993) 854 A few of the tools that this document [RFC1470] describes are 855 still maintained and in use today, for example ttcp and tcpdump. 856 However, many of the tools described do not relate specifically to 857 TCP and are no longer used or easily available. 859 RFC 2398 I: "Some Testing Tools for TCP Implementors" (August 1998) 861 This document [RFC2398] describes a number of TCP packet 862 generation and analysis tools. While some of these tools are no 863 longer readily available or widely used, for the most part they 864 are still relevant and useable. 866 6.6 Case Studies 868 RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 1992) 870 This document [RFC1337] points out a problem with acting on 871 received reset segments while in the TIME-WAIT state. The main 872 recemmendation is that hosts in TIME-WAIT ignore resets. 874 RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size" 875 (September 1998) 877 This document [RFC2415] presents results of some simulations using 878 TCP initial windows greater than 1 segment. The analysis 879 indicates that user-perceived performance can be improved by 880 increasing the initial window to 3 segments. 882 RFC 2416 I: "When TCP Starts Up With Four Packets Into Only Three 883 Buffers" (September 1998) 885 This document [RFC2416] uses simulation results to clear up some 886 concerns about using an initial window of 4 segments when the 887 network path has less provisioning. 889 RFC 2884 I: "Performance Evaluation of Explicit Congestion 890 Notification (ECN) in IP Networks" (July 2000) 892 This document [RFC2884] describes experimental results that show 893 some improvements to the performance of both short and long-lived 894 connections due to ECN. 896 7. Security Considerations 898 This document introduces no new security considerations. Each RFC 899 listed in this document attempts to address the security 900 considerations of the specification it contains. 902 8. Acknowledgments 904 This document grew out of a discussion on the end2end-interest 905 mailing list, the public list of the End-to-End Research Group of the 906 IRTF. We thank Joe Touch, Reiner Ludwig, and Pekka Savola for their 907 contributions, in particular. The chairs of the TCPM working group, 908 Mark Allman and Ted Faber, have been instrumental in the development 909 of this document. Keith McCloghrie provided some useful notes and 910 clarification on the various MIB-related RFCs. 912 9. References 914 9.1 Basic Functionality 916 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 917 793, September 1981. 919 [RFC1122] Braden, R., "Requirements for Internet Hosts - 920 Communication Layers", STD 3, RFC 1122, October 1989. 922 [RFC2147] Borman, D., "TCP and UDP over IPv6 Jumbograms", RFC 2147, 923 May 1997. 925 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 926 (IPv6) Specification", RFC 2460, December 1998. 928 [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion 929 Control", RFC 2581, April 1999. 931 [RFC2873] Xiao, X., Hannan, A., Paxson, V. and E. Crabbe, "TCP 932 Processing of the IPv4 Precedence Field", RFC 2873, June 933 2000. 935 [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission 936 Timer", RFC 2988, November 2000. 938 9.2 Standard Enhancements 940 [RFC1323] Jacobson, V., Braden, B. and D. Borman, "TCP Extensions 941 for High Performance", RFC 1323, May 1992. 943 [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", 944 RFC 1948, May 1996. 946 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 947 Selective Acknowledgment Options", RFC 2018, October 1996. 949 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 950 Signature Option", RFC 2385, August 1998. 952 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M. and M. Podolsky, "An 953 Extension to the Selective Acknowledgement (SACK) Option 954 for TCP", RFC 2883, July 2000. 956 [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing 957 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 958 January 2001. 960 [RFC3168] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of 961 Explicit Congestion Notification (ECN) to IP", RFC 3168, 962 September 2001. 964 [RFC3390] Allman, M., Floyd, S. and C. Partridge, "Increasing TCP's 965 Initial Window", RFC 3390, October 2002. 967 [RFC3517] Blanton, E., Allman, M., Fall, K. and L. Wang, "A 968 Conservative Selective Acknowledgment (SACK)-based Loss 969 Recovery Algorithm for TCP", RFC 3517, April 2003. 971 [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 972 Signature Option", RFC 3562, July 2003. 974 [RFC3782] Floyd, S., Henderson, T. and A. Gurtov, "The NewReno 975 Modification to TCP's Fast Recovery Algorithm", RFC 3782, 976 April 2004. 978 9.3 Experimental Extensions 980 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 981 April 1997. 983 [RFC2861] Handley, M., Padhye, J. and S. Floyd, "TCP Congestion 984 Window Validation", RFC 2861, June 2000. 986 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 987 RFC 3124, June 2001. 989 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 990 Counting (ABC)", RFC 3465, February 2003. 992 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 993 for TCP", RFC 3522, April 2003. 995 [RFC3540] Spring, N., Wetherall, D. and D. Ely, "Robust Explicit 996 Congestion Notification (ECN) Signaling with Nonces", RFC 997 3540, June 2003. 999 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 1000 RFC 3649, December 2003. 1002 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 1003 Acknowledgement (DSACKs) and Stream Control Transmission 1004 Protocol (SCTP) Duplicate Transmission Sequence Numbers 1005 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 1006 February 2004. 1008 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 1009 Congestion Windows", RFC 3742, March 2004. 1011 9.4 Historic Extensions 1013 [RFC1106] Fox, R., "TCP big window and NAK options", RFC 1106, June 1014 1989. 1016 [RFC1110] McKenzie, A., "Problem with the TCP big window option", 1017 RFC 1110, August 1989. 1019 [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum 1020 options", RFC 1146, March 1990. 1022 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 1023 Harmful", RFC 1263, October 1991. 1025 [RFC1379] Braden, B., "Extending TCP for Transactions -- Concepts", 1026 RFC 1379, November 1992. 1028 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 1029 Functional Specification", RFC 1644, July 1994. 1031 [RFC1693] Connolly, T., Amer, P. and P. Conrad, "An Extension to TCP 1032 : Partial Order Service", RFC 1693, November 1994. 1034 9.5 Support Documents 1036 [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", 1037 RFC 813, July 1982. 1039 [RFC0814] Clark, D., "Name, addresses, ports, and routes", RFC 814, 1040 July 1982. 1042 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, July 1043 1982. 1045 [RFC0817] Clark, D., "Modularity and efficiency in protocol 1046 implementation", RFC 817, July 1982. 1048 [RFC0872] Padlipsky, M., "TCP-on-a-LAN", RFC 872, September 1982. 1050 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1051 RFC 879, November 1983. 1053 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 1054 RFC 896, January 1984. 1056 [RFC0964] Sidhu, D. and T. Blumer, "Some problems with the 1057 specification of the Military Standard Transmission 1058 Control Protocol", RFC 964, November 1985. 1060 [RFC1066] McCloghrie, K. and M. Rose, "Management Information Base 1061 for network management of TCP/IP-based internets", RFC 1062 1066, August 1988. 1064 [RFC1072] Jacobson, V. and R. Braden, "TCP extensions for long-delay 1065 paths", RFC 1072, October 1988. 1067 [RFC1156] McCloghrie, K. and M. Rose, "Management Information Base 1068 for network management of TCP/IP-based internets", RFC 1069 1156, May 1990. 1071 [RFC1180] Socolofsky, T. and C. Kale, "TCP/IP tutorial", RFC 1180, 1072 January 1991. 1074 [RFC1185] Jacobson, V., Braden, B. and L. Zhang, "TCP Extension for 1075 High-Speed Paths", RFC 1185, October 1990. 1077 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1078 for Network Management of TCP/IP-based internets:MIB-II", 1079 STD 17, RFC 1213, March 1991. 1081 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1082 1337, May 1992. 1084 [RFC1470] Enger, R. and J. Reynolds, "FYI on a Network Management 1085 Tool Catalog: Tools for Monitoring and Debugging TCP/IP 1086 Internets and Interconnected Devices", RFC 1470, June 1087 1993. 1089 [RFC2012] McCloghrie, K., "SNMPv2 Management Information Base for 1090 the Transmission Control Protocol using SMIv2", RFC 2012, 1091 November 1996. 1093 [RFC2398] Parker, S. and C. Schmechel, "Some Testing Tools for TCP 1094 Implementors", RFC 2398, August 1998. 1096 [RFC2415] Poduri, K., "Simulation Studies of Increased Initial TCP 1097 Window Size", RFC 2415, September 1998. 1099 [RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With 1100 Four Packets Into Only Three Buffers", RFC 2416, September 1101 1998. 1103 [RFC2452] Daniele, M., "IP Version 6 Management Information Base for 1104 the Transmission Control Protocol", RFC 2452, December 1105 1998. 1107 [RFC2488] Allman, M., Glover, D. and L. Sanchez, "Enhancing TCP Over 1108 Satellite Channels using Standard Mechanisms", BCP 28, RFC 1109 2488, January 1999. 1111 [RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, 1112 J., Heavens, I., Lahey, K., Semke, J. and B. Volz, "Known 1113 TCP Implementation Problems", RFC 2525, March 1999. 1115 [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V. and N. 1116 Vaidya, "Long Thin Networks", RFC 2757, January 2000. 1118 [RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., 1119 Henderson, T., Heidemann, J., Touch, J., Kruse, H., 1120 Ostermann, S., Scott, K. and J. Semke, "Ongoing TCP 1121 Research Related to Satellites", RFC 2760, February 2000. 1123 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 1124 Explicit Congestion Notification (ECN) in IP Networks", 1125 RFC 2884, July 2000. 1127 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 1128 2914, September 2000. 1130 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 1131 2923, September 2000. 1133 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G. and Z. 1134 Shelby, "Performance Enhancing Proxies Intended to 1135 Mitigate Link-Related Degradations", RFC 3135, June 2001. 1137 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 1138 BCP 60, RFC 3360, August 2002. 1140 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G. and M. 1141 Sooriyabandara, "TCP Performance Implications of Network 1142 Path Asymmetry", BCP 69, RFC 3449, December 2002. 1144 [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A. and F. 1145 Khafizov, "TCP over Second (2.5G) and Third (3G) 1146 Generation Wireless Networks", BCP 71, RFC 3481, February 1147 2003. 1149 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W. 1150 Stevens, "Basic Socket Interface Extensions for IPv6", RFC 1151 3493, February 2003. 1153 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1154 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J. and L. 1155 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1156 RFC 3819, July 2004. 1158 9.6 Informative References Outside the RFC Series 1160 [FACK] Mathis, M. and J. Mahdavi, "Forward Acknowledgement: 1161 Refining TCP Congestion Control", ACM SIGCOMM, August 1996. 1163 [Karn] Karn, P. and C. Partridge, "Round Trip Time Estimation", 1164 ACM SIGCOMM, August 1987. 1166 [Savage] Savage, S., Cardwell, N., Wetherall, D. and T. Anderson, 1167 "TCP Congestion Control with a Misbehaving Receiver", ACM 1168 Computer Communication Review 29 (5), October 1999. 1170 [VJ88] Jacobson, V., "Congestion Avoidance and Control", ACM 1171 SIGCOMM, August 1988. 1173 Authors' Addresses 1175 Martin Duke 1176 Boeing Phantom Works 1177 PO Box 3707, MC 3W-51 1178 Seattle, WA 98124-2207 1180 Phone: 253-657-8203 1181 EMail: mduke26@comcast.net 1183 Robert Braden 1184 USC Information Sciences Institute 1185 Marina del Rey, CA 90292-6695 1187 Phone: 310-448-9173 1188 EMail: braden@isi.edu 1190 Wesley M. Eddy 1191 NASA GRC/Verizon FNS 1193 EMail: weddy@grc.nasa.gov 1194 Ethan Blanton 1195 Purdue University 1197 EMail: eblanton@cs.purdue.edu 1199 Intellectual Property Statement 1201 The IETF takes no position regarding the validity or scope of any 1202 Intellectual Property Rights or other rights that might be claimed to 1203 pertain to the implementation or use of the technology described in 1204 this document or the extent to which any license under such rights 1205 might or might not be available; nor does it represent that it has 1206 made any independent effort to identify any such rights. Information 1207 on the procedures with respect to rights in RFC documents can be 1208 found in BCP 78 and BCP 79. 1210 Copies of IPR disclosures made to the IETF Secretariat and any 1211 assurances of licenses to be made available, or the result of an 1212 attempt made to obtain a general license or permission for the use of 1213 such proprietary rights by implementers or users of this 1214 specification can be obtained from the IETF on-line IPR repository at 1215 http://www.ietf.org/ipr. 1217 The IETF invites any interested party to bring to its attention any 1218 copyrights, patents or patent applications, or other proprietary 1219 rights that may cover technology that may be required to implement 1220 this standard. Please address the information to the IETF at 1221 ietf-ipr@ietf.org. 1223 Disclaimer of Validity 1225 This document and the information contained herein are provided on an 1226 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1227 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1228 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1229 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1230 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1231 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1233 Copyright Statement 1235 Copyright (C) The Internet Society (2005). This document is subject 1236 to the rights, licenses and restrictions contained in BCP 78, and 1237 except as set forth therein, the authors retain all their rights. 1239 Acknowledgment 1241 Funding for the RFC Editor function is currently provided by the 1242 Internet Society.