idnits 2.17.1 draft-ietf-tcpm-tcp-rfc4614bis-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 3, 2014) is 3557 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2780' is defined on line 1996, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-tcpm-fastopen-08 ** Obsolete normative reference: RFC 675 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 721 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 761 (Obsoleted by RFC 793, RFC 7805) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 813 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 816 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 879 (Obsoleted by RFC 7805, RFC 9293) ** Obsolete normative reference: RFC 896 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 1078 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 1106 (Obsoleted by RFC 6247) ** Obsolete normative reference: RFC 1110 (Obsoleted by RFC 6247) ** Obsolete normative reference: RFC 1146 (Obsoleted by RFC 6247) ** Obsolete normative reference: RFC 1379 (Obsoleted by RFC 6247) ** Obsolete normative reference: RFC 1644 (Obsoleted by RFC 6247) ** Obsolete normative reference: RFC 1693 (Obsoleted by RFC 6247) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2012 (Obsoleted by RFC 4022) ** Obsolete normative reference: RFC 2140 (Obsoleted by RFC 9040) ** Obsolete normative reference: RFC 2452 (Obsoleted by RFC 4022, RFC 8096) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2861 (Obsoleted by RFC 7661) ** Obsolete normative reference: RFC 2873 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6013 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 6093 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6429 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6528 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6691 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 28 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions M. Duke 3 (TCPM) WG F5 4 Internet-Draft R. Braden 5 Obsoletes: 4614 (if approved) ISI 6 Intended status: Informational W. Eddy 7 Expires: January 4, 2015 MTI Systems 8 E. Blanton 10 A. Zimmermann 11 NetApp, Inc. 12 July 3, 2014 14 A Roadmap for Transmission Control Protocol (TCP) Specification 15 Documents 16 draft-ietf-tcpm-tcp-rfc4614bis-06 18 Abstract 20 This document contains a "roadmap" to the Requests for Comments (RFC) 21 documents relating to the Internet's Transmission Control Protocol 22 (TCP). This roadmap provides a brief summary of the documents 23 defining TCP and various TCP extensions that have accumulated in the 24 RFC series. This serves as a guide and quick reference for both TCP 25 implementers and other parties who desire information contained in 26 the TCP-related RFCs. 28 This document obsoletes RFC 4614. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 4, 2015. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Core Functionality . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Strongly Encouraged Enhancements . . . . . . . . . . . . . . . 8 66 3.1. Fundamental Changes . . . . . . . . . . . . . . . . . . . 8 67 3.2. Congestion Control Extensions . . . . . . . . . . . . . . 9 68 3.3. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 10 69 3.4. Detection and Prevention of Spurious Retransmissions . . . 12 70 3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 13 71 3.6. Header Compression . . . . . . . . . . . . . . . . . . . . 14 72 3.7. Defending Spoofing and Flooding Attacks . . . . . . . . . 15 73 4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 16 74 4.1. Architectural Guidelines . . . . . . . . . . . . . . . . . 17 75 4.2. Fundamental Changes . . . . . . . . . . . . . . . . . . . 18 76 4.3. Congestion Control Extensions . . . . . . . . . . . . . . 18 77 4.4. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 20 78 4.5. Detection and Prevention of Spurious Retransmissions . . . 20 79 4.6. TCP Timeouts . . . . . . . . . . . . . . . . . . . . . . . 21 80 4.7. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 21 81 5. TCP Parameters at IANA . . . . . . . . . . . . . . . . . . . . 22 82 6. Historic and Undeployed Extensions . . . . . . . . . . . . . . 23 83 7. Support Documents . . . . . . . . . . . . . . . . . . . . . . 26 84 7.1. Foundational Works . . . . . . . . . . . . . . . . . . . . 26 85 7.2. Architectural Guidelines . . . . . . . . . . . . . . . . . 28 86 7.3. Difficult Network Environments . . . . . . . . . . . . . . 29 87 7.4. Guidance for Developing, Analyzing, and Evaluating TCP . . 32 88 7.5. Implementation Advice . . . . . . . . . . . . . . . . . . 33 89 7.6. Tools and Tutorials . . . . . . . . . . . . . . . . . . . 35 90 7.7. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 36 91 7.8. Case Studies . . . . . . . . . . . . . . . . . . . . . . . 37 92 8. Undocumented TCP Features . . . . . . . . . . . . . . . . . . 38 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 40 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 50 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 101 1. Introduction 103 A correct and efficient implementation of the Transmission Control 104 Protocol (TCP) is a critical part of the software of most Internet 105 hosts. As TCP has evolved over the years, many distinct documents 106 have become part of the accepted standard for TCP. At the same time, 107 a large number of experimental modifications to TCP have also been 108 published in the RFC series, along with informational notes, case 109 studies, and other advice. 111 As an introduction to newcomers and an attempt to organize the 112 plethora of information for old hands, this document contains a 113 "roadmap" to the TCP-related RFCs. It provides a brief summary of 114 the RFC documents that define TCP. This should provide guidance to 115 implementers on the relevance and significance of the standards-track 116 extensions, informational notes, and best current practices that 117 relate to TCP. 119 This document is not an update of RFC 1122 [RFC1122] and is not a 120 rigorous standard for what needs to be implemented in TCP. This 121 document is merely an informational roadmap that captures, organizes, 122 and summarizes most of the RFC documents that a TCP implementer, 123 experimenter, or student should be aware of. Particular comments or 124 broad categorizations that this document makes about individual 125 mechanisms and behaviors are not to be taken as definitive, nor 126 should the content of this document alone influence implementation 127 decisions. 129 This roadmap includes a brief description of the contents of each 130 TCP-related RFC. In some cases, we simply supply the abstract or a 131 key summary sentence from the text as a terse description. In 132 addition, a letter code after an RFC number indicates its category in 133 the RFC series (see BCP 9 [RFC2026] for explanation of these 134 categories): 136 S - Standards Track (Proposed Standard, Draft Standard, or 137 Internet Standard) 139 E - Experimental 141 I - Informational 143 H - Historic 145 B - Best Current Practice 147 U - Unknown (not formally defined) 149 Note that the category of an RFC does not necessarily reflect its 150 current relevance. For instance, RFC 5681 [RFC5681] is considered 151 part of the required core functionality of TCP, although the RFC is 152 only a Draft Standard. Similarly, some Informational RFCs contain 153 significant technical proposals for changing TCP. 155 Finally, if an error in the technical content has been found after 156 publication of an RFC, this fact is indicated by the term "(Errata)" 157 in the headline of the RFC's description. The contents of the errata 158 can be found at the RFC editor home page [Errata]. 160 This roadmap is divided into three main sections. Section 2 lists 161 the RFCs that describe absolutely required TCP behaviors for proper 162 functioning and interoperability. Further RFCs that describe 163 strongly encouraged, but non-essential, behaviors are listed in 164 Section 3. Experimental extensions that are not yet standard 165 practices, but that potentially could be in the future, are described 166 in Section 4. 168 The reader will probably notice that these three sections are broadly 169 equivalent to MUST/SHOULD/MAY specifications (per RFC 2119 170 [RFC2119]), and although the authors support this intuition, this 171 document is merely descriptive; it does not represent a binding 172 standards-track position. Individual implementers still need to 173 examine the standards documents themselves to evaluate specific 174 requirement levels. 176 Section 5 describes both the procedures that the Internet Assigned 177 Numbers Authority (IANA) uses and an RFC author should follow when 178 new TCP parameters are requested and finally assigned. 180 A small number of older experimental extensions that have not been 181 widely implemented, deployed, and used are noted in Section 6. Many 182 other supporting documents that are relevant to the development, 183 implementation, and deployment of TCP are described in Section 7. 185 A small number of fairly ubiquitous important implementation 186 practices that are not currently documented in the RFC series is 187 listed in Section 8. 189 Within each section, RFCs are listed in the chronological order of 190 their publication dates. 192 2. Core Functionality 194 A small number of documents compose the core specification of TCP. 195 These define the required core functionalities of TCP's header 196 parsing, state machine, congestion control, and retransmission 197 timeout computation. These base specifications must be correctly 198 followed for interoperability. 200 RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981) 201 (Errata) 203 This is the fundamental TCP specification document [RFC0793]. 204 Written by Jon Postel as part of the Internet protocol suite's 205 core, it describes the TCP packet format, the TCP state machine 206 and event processing, and TCP's semantics for data transmission, 207 reliability, flow control, multiplexing, and acknowledgment. 209 Section 3.6 of RFC 793, describing TCP's handling of the IP 210 precedence and security compartment, is mostly irrelevant today. 211 RFC 2873 (see Section 2) changed the IP precedence handling, and 212 the security compartment portion of the API is no longer 213 implemented or used. In addition, RFC 793 did not describe any 214 congestion control mechanism. Otherwise, however, the majority of 215 this document still accurately describes modern TCPs. RFC 793 is 216 the last of a series of developmental TCP specifications, starting 217 in the Internet Experimental Notes (IENs) and continuing in the 218 RFC series. 220 RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" 221 (October 1989) 223 This document [RFC1122] updates and clarifies RFC 793 (see 224 Section 2), fixing some specification bugs and oversights. It 225 also explains some features such as keep-alives and Karn's and 226 Jacobson's RTO estimation algorithms [KP87][Jac88][JK92]. ICMP 227 interactions are mentioned, and some tips are given for efficient 228 implementation. RFC 1122 is an Applicability Statement, listing 229 the various features that MUST, SHOULD, MAY, SHOULD NOT, and MUST 230 NOT be present in standards-conforming TCP implementations. 231 Unlike a purely informational "roadmap", this Applicability 232 Statement is a standards document and gives formal rules for 233 implementation. 235 RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification" 236 (December 1998) (Errata) 238 This document [RFC2460] is of relevance to TCP because it defines 239 how the pseudo-header for TCP's checksum computation is derived 240 when 128-bit IPv6 addresses are used instead of 32-bit IPv4 241 addresses. Additionally, RFC 2675 (see Section 3.1) describes TCP 242 changes required to support IPv6 jumbograms. 244 RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000) 245 (Errata) 247 This document [RFC2873] removes from the TCP specification all 248 processing of the precedence bits of the TOS byte of the IP 249 header. This resolves a conflict over the use of these bits 250 between RFC 793 Section 2 and Differentiated Services [RFC2474]. 252 RFC 5681 S: "TCP Congestion Control" (August 2009) 254 Although RFC 793 (see Section 2) did not contain any congestion 255 control mechanisms, today congestion control is a required 256 component of TCP implementations. This document [RFC5681] defines 257 the current versions of Van Jacobson's congestion avoidance and 258 control mechanisms for TCP, based on his 1988 SIGCOMM paper 259 [Jac88]. 261 A number of behaviors that together constitute what the community 262 refers to as "Reno TCP" are described in RFC 5681. The name 263 "Reno" comes from the Net/2 release of the 4.3 BSD operating 264 system. This is generally regarded as the least common 265 denominator among TCP flavors currently found running on Internet 266 hosts. Reno TCP includes the congestion control features of slow 267 start, congestion avoidance, fast retransmit, and fast recovery. 269 RFC 5681 details the currently accepted congestion control 270 mechanism, while RFC 1122 Section 2 mandates that such a 271 congestion control mechanism must be implemented. RFC 5681 272 differs slightly from the other documents listed in this section, 273 as it does not affect the ability of two TCP endpoints to 274 communicate; however, congestion control remains a critical 275 component of any widely deployed TCP implementation and is 276 required for the avoidance of congestion collapse and to ensure 277 fairness among competing flows. 279 RFC 2001 and RFC 2581 are the conceptual precursors of RFC 5681. 280 The most important changes relative to RFC 2581 are: 281 (a) The initial window requirements were changed to allow larger 282 Initial Windows as standardized in [RFC3390] (see 283 Section 3.2). 284 (b) During slow start and congestion avoidance, the usage of 285 Appropriate Byte Counting [RFC3465] (see Section 3.2) is 286 explicitly recommended. 287 (c) The use of Limited Transmit [RFC3042] (see Section 3.3) is 288 now recommended. 290 RFC 6093 S: "On the Implementation of the TCP Urgent Mechanism" 291 (January 2011) 293 This document [RFC6093] analyzes how current TCP stacks process 294 TCP urgent indications, and how the behavior of widely deployed 295 middleboxes affects the urgent indications processing. The 296 document updates the relevant specifications such that it 297 accommodates current practice in processing TCP urgent 298 indications. Finally, the document raises awareness about the 299 reliability of TCP urgent indications in the Internet, and 300 recommends against the use of urgent mechanism. 302 RFC 6298 S: "Computing TCP's Retransmission Timer" (June 2011) 304 Abstract: "This document defines the standard algorithm that 305 Transmission Control Protocol (TCP) senders are required to use to 306 compute and manage their retransmission timer. It expands on the 307 discussion in section 4.2.3.1 of RFC 1122 (see Section 2) and 308 upgrades the requirement of supporting the algorithm from a SHOULD 309 to a MUST." [RFC6298]. RFC 6298 updates RFC 2988 by changing the 310 initial RTO from 3s to 1s 312 RFC 6691 I: "TCP Options and Maximum Segment Size (MSS)" (July 2012) 314 This document [RFC6691] clarifies what value to use with the TCP 315 Maximum Segment Size (MSS) option when IP and TCP options are in 316 use. 318 3. Strongly Encouraged Enhancements 320 This section describes recommended TCP modifications that improve 321 performance and security. Section 3.1 represents fundamental changes 322 to the protocol. Section 3.2 and Section 3.3 list improvements over 323 the congestion control and loss recovery mechanisms as specified in 324 RFC 5681 (see Section 2). Section 3.4 describes algorithms that 325 allow a TCP sender to detect whether it has entered loss recovery 326 spuriously. Section 3.5 comprises Path MTU Discovery mechanisms. 327 Schemes for TCP/IP header compression are listed in Section 3.6. 328 Finally, Section 3.7 deals with the problem of preventing preventing 329 acceptance of forged segments and flooding attacks. 331 3.1. Fundamental Changes 333 RFCs 2675 and 7323 represent fundamental changes to TCP by redefining 334 how parts of the basic TCP header and options are interpreted. RFC 335 7323 defines the Window Scale Option, which re-interprets the 336 advertised receive window. RFC 2675 specifies that MSS option and 337 urgent pointer fields with a value of 65,535 are to be treated 338 specially. 340 RFC 2675 S: "IPv6 Jumbograms" (August 1999) (Errata) 342 IPv6 supports longer datagrams than were allowed in IPv4. These 343 are known as jumbograms, and use with TCP has necessitated changes 344 to the handling of TCP's MSS and Urgent fields (both 16 bits). 345 This document [RFC2675] explains those changes. Although it 346 describes changes to basic header semantics, these changes should 347 only affect the use of very large segments, such as IPv6 348 jumbograms, which are currently rarely used in the general 349 Internet. 351 Supporting the behavior described in this document does not affect 352 interoperability with other TCP implementations when IPv4 or non- 353 jumbogram IPv6 is used. This document states that jumbograms are 354 to only be used when it can be guaranteed that all receiving 355 nodes, including each router in the end-to-end path, will support 356 jumbograms. If even a single node that does not support 357 jumbograms is attached to a local network, then no host on that 358 network may use jumbograms. This explains why jumbogram use has 359 been rare, and why this document is considered a performance 360 optimization and not part of TCP over IPv6's basic functionality. 362 RFC 7323 S: "TCP Extensions for High Performance" (July 2014) 364 This document [I-D.ietf-tcpm-1323bis] defines TCP extensions for 365 window scaling, timestamps, and protection against wrapped 366 sequence numbers, for efficient and safe operation over paths with 367 large bandwidth-delay products. These extensions are commonly 368 found in currently used systems. The predecessor of this 369 document, RFC 1323, was published in 1992, and is deployed in most 370 TCP implementations. This document includes fixes and 371 clarifications based on the gained deployment experience. One 372 specific issued addressed in this specification is a 373 recommendation how to modify the algorithm for estimating the mean 374 RTT when timestamps are used. RFC 1072, RFC 1185, and RFC 1323 375 are the conceptual precursors of RFC 7323. 377 3.2. Congestion Control Extensions 379 Two of the most important aspects of TCP are its congestion control 380 and loss recovery features. TCP treats lost packets as indicating 381 congestion-related loss, and cannot distinguish between congestion- 382 related loss and loss due to transmission errors. Even when ECN is 383 in use, there is a rather intimate coupling between congestion 384 control and loss recovery mechanisms. There are several extensions 385 to both features, and more often than not, a particular extension 386 applies to both. In this two sub-sections, we group enhancements to 387 TCP's congestion control, while the next sub-section focus on TCP's 388 loss recovery. 390 RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN) 391 to IP" (September 2001) 393 This document [RFC3168] defines a means for end hosts to detect 394 congestion before congested routers are forced to discard packets. 395 Although congestion notification takes place at the IP level, ECN 396 requires support at the transport level (e.g., in TCP) to echo the 397 bits and adapt the sending rate. This document updates RFC 793 398 (see Section 2) to define two previously unused flag bits in the 399 TCP header for ECN support. RFC 3540 (see Section 4.3) provides a 400 supplementary (experimental) means for more secure use of ECN, and 401 RFC 2884 (see Section 7.8) provides some sample results from using 402 ECN. 404 RFC 3390 S: "Increasing TCP's Initial Window" (October 2002) 406 This document [RFC3390] specifies an increase in the permitted 407 initial window for TCP from one segment to three or four segments 408 during the slow start phase, depending on the segment size. 410 RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting 411 (ABC)" (February 2003) 413 This document [RFC3465] suggests that congestion control use the 414 number of bytes acknowledged instead of the number of 415 acknowledgments received. The ABC mechanism behaves differently 416 than the standard method when there is not a one-to-one 417 relationship between data segments and acknowledgments. ABC still 418 operates within the accepted guidelines, but is more robust to 419 delayed ACKs and ACK-division [SCWA99][RFC3449]. ABC is 420 recommended by RFC 5681 (see Section 2). 422 RFC 6633 S: "Deprecation of ICMP Source Quench Messages" (May 2012) 424 This document [RFC6633] formally deprecates the use of ICMP Source 425 Quench messages by transport protocols and recommends against the 426 implementation of [RFC1016]. 428 3.3. Loss Recovery Extensions 430 For the typical implementation of the TCP fast recovery algorithm 431 described in RFC 5681 (see Section 2), a TCP sender only retransmits 432 a segment after a retransmit timeout has occurred, or after three 433 duplicate ACKs have arrived triggering the fast retransmit. A single 434 RTO might result in the retransmission of several segments, while the 435 fast retransmit algorithm in RFC 5681 leads only to a single 436 retransmission. Hence, multiple losses from a single window of data 437 can lead to a performance degradation. Documents listed in this 438 section aim to improve the overall performance of TCP's standard loss 439 recovery algorithms. In particular, some of them allows TCP senders 440 to recover more effectively when multiple segments are lost from a 441 single flight of data. 443 RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996) 444 (Errata) 446 When more than one packet is lost during one round trip time TCP 447 may experience poor performance since a TCP sender can only learn 448 about a single lost packet per round trip time from cumulative 449 acknowledgments. This document [RFC2018] defines the basic 450 selective acknowledgment (SACK) mechanism for TCP, which can help 451 to overcome these limitations. The receiving TCP returns SACK 452 blocks to inform the sender which data has been received. The 453 sender can then retransmit only the missing data segments. 455 RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit" 456 (January 2001) 458 Abstract: "This document proposes Limited Transmit, a new 459 Transmission Control Protocol (TCP) mechanism that can be used to 460 more effectively recover lost segments when a connection's 461 congestion window is small, or when a large number of segments are 462 lost in a single transmission window." [RFC3042] Tests from 2004 463 showed that Limited Transmit was deployed in roughly one third of 464 the web servers tested [MAF04]. Limited Transmit is recommended 465 by RFC 5681 (see Section 2). 467 RFC 6582 S: "The NewReno Modification to TCP's Fast Recovery 468 Algorithm" (April 2012) 470 This document [RFC6582] specifies a modification to the standard 471 Reno fast recovery algorithm, whereby a TCP sender can use partial 472 acknowledgments to make inferences determining the next segment to 473 send in situations where SACK would be helpful but isn't 474 available. Although it is only a slight modification, the NewReno 475 behavior can make a significant difference in performance when 476 multiple segments are lost from a single window of data. 478 RFC 2582 and RFC 3782 are the conceptual precursors of RFC 6582. 479 The main change in RFC 3782 relative to RFC 2582 was to specify 480 the Careful variant of NewReno's Fast Retransmit and Fast Recovery 481 algorithms and advance those two algorithms from Experimental to 482 Standards Track status. The main change in RFC 6582 relative to 483 RFC 3782 was to solve a performance degradation that could occur 484 if FlightSize on Full ACK reception is zero. 486 RFC 6675 S: "A Conservative Loss Recovery Algorithm Based on 487 Selective Acknowledgment (SACK) for TCP" (August 2012) 489 This document [RFC6675] describes a conservative loss recovery 490 algorithm for TCP that is based on the use of the selective 491 acknowledgment (SACK) TCP option [RFC2018] (see Section 3.3). The 492 algorithm conforms to the spirit of the congestion control 493 specification in RFC 5681 (see Section 2), but allows TCP senders 494 to recover more effectively when multiple segments are lost from a 495 single flight of data. 497 RFC 6675 is a revision of RFC 3517 to address several situations 498 that are not handled explicitly before. In particular 499 (a) it improves the loss detection in the event that the sender 500 has outstanding segments that are smaller than SMSS. 501 (b) it modifies the definition of a "duplicate acknowledgment" to 502 utilize the SACK information in detecting loss. 503 (c) it maintains the ACK clock under certain circumstances 504 involving loss at the end of the window. 506 3.4. Detection and Prevention of Spurious Retransmissions 508 Spurious retransmission timeouts are harmful to TCP performance and 509 multiple algorithms have been defined for detecting when spurious 510 retransmissions have occurred, and then responding differently in 511 order to recover performance. The IETF defined multiple algorithms 512 because there are tradeoffs in whether or not certain TCP options 513 need to be implemented, and concerns about IPR status. The Standards 514 Track documents in this section are closely related to the 515 Experimental documents in Section 4.5 also addressing this topic. 517 RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK) 518 Option for TCP" (July 2000) 520 This document [RFC2883] extends RFC 2018 (see Section 3.3). It 521 enables use of the SACK option to acknowledge duplicate packets. 522 With this extension, called DSACK, the sender is able to infer the 523 order of packets received at the receiver, and therefore to infer 524 when it has unnecessarily retransmitted a packet. A TCP sender 525 could then use this information to detect spurious retransmissions 526 (see [RFC3708]. 528 RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005) 530 This document [RFC4015] describes the response portion of the 531 Eifel algorithm, which can be used in conjunction with one of 532 several methods of detecting when loss recovery has been 533 spuriously entered, such as the Eifel detection algorithm in RFC 534 3522 (see Section 4.5), the algorithm in RFC 3708 (see 535 Section 4.5), or F-RTO in RFC 5682 (see Section 3.4). 537 Abstract: "Based on an appropriate detection algorithm, the Eifel 538 response algorithm provides a way for a TCP sender to respond to a 539 detected spurious timeout. It adapts the retransmission timer to 540 avoid further spurious timeouts, and can avoid - depending on the 541 detection algorithm - the often unnecessary go-back-N retransmits 542 that would otherwise be sent. In addition, the Eifel response 543 algorithm restores the congestion control state in such a way that 544 packet bursts are avoided." 546 RFC 5682 S: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 547 Spurious Retransmission Timeouts with TCP" (September 2009) 549 The F-RTO detection algorithm [RFC5682], originally described in 550 RFC 4138, provides an option for inferring spurious retransmission 551 timeouts. Unlike some similar detection methods (e.g. RFC 3522 552 in Section 4.5 and RFC 3708 in Section 4.5), F-RTO does not rely 553 on the use of any TCP options. The basic idea is to send 554 previously unsent data after the first retransmission after a RTO. 555 If the ACKs advance the window, the RTO may be declared spurious. 557 3.5. Path MTU Discovery 559 The MTUs supported by different links and tunnels within the Internet 560 can vary widely. Fragmentation of packets larger than the supported 561 MTU on a hop is undesirable. As TCP is the segmentation layer for 562 dividing an application's bytestream into IP packet payloads, TCP 563 implementations generally include Path MTU Discovery (PMTUD) 564 mechanisms in order to maximize the size of segments they send, 565 without causing fragmentation within the network. Some algorithms 566 may utilize signaling from routers on the path that the MTU has been 567 exceeded. 569 RFC 1191 S: "Path MTU Discovery" (November 1990) 571 Abstract: "This memo describes a technique for dynamically 572 discovering the MTU of an arbitrary Internet path. It specifies a 573 small change to the way routers generate one type of ICMP message. 575 For a path that passes through a router that has not been so 576 changed, this technique might not discover the correct path MTU, 577 but it will always choose a path MTU as accurate as, and in many 578 cases more accurate than, the path MTU that would be chosen by 579 current practice." [RFC1191] 581 RFC 1981 S: "Path MTU Discovery for IP version 6" (August 1996) 583 Abstract: "This document describes Path MTU Discovery for IP 584 version 6. It is largely derived from RFC 1191 (see Section 3.5), 585 which describes Path MTU Discovery for IP version 4." [RFC1981] 587 RFC 4821 S: "Packetization Layer Path MTU Discovery" (March 2007) 589 Abstract: "This document describes a robust method for Path MTU 590 Discovery (PMTUD) that relies on TCP or some other Packetization 591 Layer to probe an Internet path with progressively larger packets. 592 This method is described as an extension to RFC 1191 (see 593 Section 3.5) and RFC 1981 (see Section 3.5), which specify ICMP- 594 based Path MTU Discovery for IP versions 4 and 6, respectively." 595 [RFC4821] 597 3.6. Header Compression 599 Especially in streaming applications, the overhead of TCP/IP headers 600 could correspond to more then 50% of the total amount of data sent. 601 Such large overheads may be tolerable in wired LANs where capacity is 602 often not an issue, but are excessive for WANs and wireless systems 603 where bandwidth is scarce. Header compression schemes for TCP/IP 604 like "RObust Header Compression (ROHC) can significantly compress 605 this overhead. It performs well over links with significant error 606 rates and long round-trip times. 608 RFC 1144 S: "Compressing TCP/IP Headers for Low-Speed Serial Links" 609 (February 1990) 611 This document [RFC1144] describes a method for compressing the 612 headers of TCP/IP datagrams to improve performance over low speed 613 serial links. The method described in this document is limited in 614 its handling of TCP options and cannot compress the headers of 615 SYNs and FINs. 617 RFC 6846 S: "RObust Header Compression (ROHC): A Profile for TCP/IP 618 (ROHC-TCP)" January 2013) 620 From abstract: "This document specifies a RObust Header 621 Compression (ROHC) profile for compression of TCP/IP packets. The 622 profile, called ROHC-TCP, provides efficient and robust 623 compression of TCP headers, including frequently used TCP options 624 such as selective acknowledgments (SACKs) and Timestamps." 625 [RFC6846] RFC 6846 is the successor of RFC 4996. It fixes a 626 technical issue with the SACK compression and clarifies other 627 compression methods used. 629 3.7. Defending Spoofing and Flooding Attacks 631 By default, TCP lacks any cryptographic structures to differentiate 632 legitimate segments from those spoofed from malicious hosts. 633 Spoofing valid segments requires correctly guessing a number of 634 fields. The documents in this sub-section describe ways to make that 635 guessing harder, or to prevent it from being able to affect a 636 connection negatively. 638 RFC 4953 I: "Defending TCP Against Spoofing Attacks" (July 2007) 640 This document [RFC4953] discusses the recently increased 641 vulnerability of long-lived TCP connections, such as BGP 642 connections, to reset (send RST) spoofing attacks. The document 643 analyzes the vulnerability, discussing proposed solutions at the 644 transport level and their inherent challenges, as well as existing 645 network level solutions and the feasibility of their deployment. 647 RFC 5461 I: "TCP's Reaction to Soft Errors" (February 2009) 649 This document [RFC5461] describes a non-standard but widely 650 implemented modification to TCP's handling of ICMP soft error 651 messages that rejects pending connection-requests when such error 652 messages are received. This behavior reduces the likelihood of 653 long delays between connection-establishment attempts that may 654 arise in some scenarios. 656 RFC 4987 I: "TCP SYN Flooding Attacks and Common Mitigations" (August 657 2007) 659 This document [RFC4987] describes the well-known TCP SYN flooding 660 attack. It analyzes and discusses various countermeasures against 661 these attacks, including their use and trade-offs. 663 RFC 5925 S: "The TCP Authentication Option" (May 2010) 665 This document [RFC5925] describes the TCP Authentication Option 666 (TCP-AO), which is used to authenticate TCP segments. TCP-AO 667 obsoletes the TCP MD5 Signature option of RFC 2385. It supports 668 the use of stronger hash functions, protects against replays for 669 long-lived TCP connections (as used, e.g., in BGP and LDP), 670 coordinates key exchanges between endpoints, and provides a more 671 explicit recommendation for external key management. 672 Cryptographic algorithms for TCP-AO are defined in [RFC5926] (see 673 Section 3.7). 675 RFC 5926 S: "Cryptographic Algorithms for the TCP Authentication 676 Option (TCP-AO)" (May 2010) 678 This document [RFC5926] specifies the algorithms and attributes 679 that can be used in TCP Authentication Option's (TCP-AO) [RFC5925] 680 (see Section 3.7) current manual keying mechanism and provides the 681 interface for future message authentication codes (MACs). 683 RFC 5927 I: "ICMP attacks against TCP" (July 2010) 685 Abstract: "This document discusses the use of the Internet Control 686 Message Protocol (ICMP) to perform a variety of attacks against 687 the Transmission Control Protocol (TCP). Additionally, this 688 document describes a number of widely implemented modifications to 689 TCP's handling of ICMP error messages that help to mitigate these 690 issues." [RFC5927] 692 RFC 5961 S: "Improving TCP's Robustness to Blind In-Window Attacks" 693 (August 2010) 695 This document [RFC5961] describes minor modifications to how TCP 696 handles inbound segments. This renders TCP connections, 697 especially long-lived connections such as H-323 or BGP, less 698 vulnerable to spoofed packet injection attacks where the 4-tuple 699 (the source and destination IP addresses and the source and 700 destination ports) has been guessed. 702 RFC 6528 S: "Defending Against Sequence Number Attacks" (February 703 2012) 705 Abstract: "This document [RFC6528] specifies an algorithm for the 706 generation of TCP Initial Sequence Numbers (ISNs), such that the 707 chances of an off-path attacker guessing the sequence numbers in 708 use by a target connection are reduced. This document revises 709 (and formally obsoletes) RFC 1948, and takes the ISN generation 710 algorithm originally proposed in that document to Standards Track, 711 formally updating RFC 793 (see Section 2). 713 4. Experimental Extensions 715 The RFCs in this section are either experimental and may become 716 proposed standards in the future or are already be proposed standard 717 (or informational), but considered as experimental due to lack of 718 wide deployment. At least part of the reason that they are still 719 experimental is to gain more wide-scale experience with them before a 720 standards track decision is made. 722 At this point is worth mentioning that if the experimental RFC is a 723 proposal for a new protocol capability or service, i.e., it requires 724 a new TCP option code point, the implementation and experimentation 725 should follows [RFC6994] (see Section 5), which describes how the 726 experimental TCP option code points can concurrently support multiple 727 TCP extensions. 729 By their publication as experimental RFCs, it is hoped that the 730 community of TCP researchers will analyze and test the contents of 731 these RFCs. Although experimentation is encouraged, there is not yet 732 formal consensus that these are fully logical and safe behaviors. 733 Wide-scale deployment of implementations that use these features 734 should be well thought-out in terms of consequences. 736 4.1. Architectural Guidelines 738 As multiple flows may share the same paths, sections of paths, or 739 other resources, the TCP implementation may benefit from sharing 740 information across TCP connections or other flows. Some Experimental 741 proposals have been documented and some implementations have included 742 the concepts. 744 RFC 2140 I: "TCP Control Block Interdependence" (April 1997) 746 This document [RFC2140] suggests how TCP connections between the 747 same endpoints might share information, such as their congestion 748 control state. To some degree, this is done in practice by a few 749 operating systems; for example, Linux currently has a destination 750 cache. Although this RFC is technically informational, the 751 concepts it describes are in experimental use, so we include it in 752 this section. 754 RFC 3124 S: "The Congestion Manager" (June 2001) 756 This document [RFC3124], the Congestion Manager, is a related 757 proposal to RFC 2140 (see Section 4.1). The idea behind the 758 Congestion Manager, moving congestion control outside of 759 individual TCP connections, represents a modification to the core 760 of TCP, which supports sharing information among TCP connections. 761 Although a Proposed Standard, some pieces of the Congestion 762 Manager support architecture have not been specified yet, and it 763 has not achieved use or implementation beyond experimental stacks, 764 so it is not listed among the standard TCP enhancements in this 765 roadmap. 767 4.2. Fundamental Changes 769 Like the standard documents listed in Section 3.1 there newly exist 770 also experimental RFCs that represent fundamental changes to TCP. 771 One example is TCP Fast Open that deviates from the standard TCP 772 semantics of [RFC0793]. 774 RFC XXX E: "TCP Fast Open" (XXX 2014) 776 This document [I-D.ietf-tcpm-fastopen] describes TCP Fast Open 777 that allows data to be carried in the SYN and SYN-ACK packets and 778 consumed by the receiver during the initial connection handshake. 779 It saves up to one RTT compared to the standard TCP, which 780 requires a three-way handshake to complete before data can be 781 exchanged. 783 4.3. Congestion Control Extensions 785 TCP congestion control has been an extremely active research area for 786 many years (see RFC 5783, Section 7.6), as it determines the 787 performance of many applications that use TCP. A number of 788 experimental RFCs address issues with flow start-up, overshoot, and 789 steady-state behavior in the basic RFC 5681 (see Section 2) 790 algorithms. In this sub-sections, enhancements to TCP's congestion 791 control are listed. The next sub-section focus on TCP's loss 792 recovery. 794 RFC 2861 E: "TCP Congestion Window Validation" (June 2000) 796 This document [RFC2861] suggests reducing the congestion window 797 over time when no packets are flowing. This behavior is more 798 aggressive than that specified in RFC 5681 (see Section 2), which 799 says that a TCP sender SHOULD set its congestion window to the 800 initial window after an idle period of an RTO or greater. 802 RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling 803 with Nonces" (June 2003) 805 This document [RFC3540] describes an optional addition to ECN that 806 protects against accidental or malicious concealment of marked 807 packets from the TCP sender. 809 RFC 3649 E: "HighSpeed TCP for Large Congestion Windows" (December 810 2003) 812 This document [RFC3649] proposes a modification to TCP's 813 congestion control mechanism for use with TCP connections with 814 large congestion windows, to allow TCP to achieve a higher 815 throughput in high-bandwidth environments. 817 RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion 818 Windows" (March 2004) 820 This document [RFC3742] describes a more conservative slow-start 821 behavior to prevent massive packet losses when a connection uses a 822 very large congestion window. 824 RFC 4782 E: "Quick-Start for TCP and IP" (January 2007) (Errata) 826 This document [RFC4782] specifies the optional Quick-Start 827 mechanism for TCP. This mechanism allows connections to use 828 higher sending rates at the beginning of the data transfer or 829 after an idle period, provided that there is significant unused 830 bandwidth along the path, and the sender and all of the routers 831 along the path approve this higher rate. 833 RFC 5562 E: "Adding Explicit Congestion Notification (ECN) Capability 834 to TCP's SYN/ACK Packets" (June 2009) 836 This document [RFC5562] describes an experimental modification to 837 ECN [RFC3168] (see Section 3.2) for the use of ECN in TCP SYN/ACK 838 packets. This would allow to ECN-mark rather than drop the TCP 839 SYN/ACK packet at an ECN-capable router, and to avoid the severe 840 penalty of a retransmission timeout for a connection when the SYN/ 841 ACK packet is dropped. 843 RFC 5690 I: "Adding Acknowledgement Congestion Control to TCP" 844 (February 2010) 846 This document [RFC5690] describes a congestion control mechanism 847 for acknowledgment (ACKs) traffic in TCP. The mechanism is based 848 on the acknowledgment congestion control of the Datagram 849 Congestion Control Protocol's (DCCP's) [RFC4340] Congestion 850 Control Identifier (CCID) 2 [RFC4341]. 852 RFC 6928 E: "Increasing TCP's Initial Window" (April 2013) 854 This document [RFC6928] proposes to increase the TCP initial 855 window from between 2 and 4 segments, as specified in RFC 3390 856 (see Section 3.2), to 10 segments with a fallback to the existing 857 recommendation when performance issues are detected. 859 4.4. Loss Recovery Extensions 861 RFC 5827 E: "Early Retransmit for TCP and SCTP" (April 2010) 863 This document [RFC5827] proposes the "Early Retransmit" mechanism 864 for TCP (and SCTP) that can be used to recover lost segments when 865 a connection's congestion window is small. In certain special 866 circumstances, Early Retransmit reduces the number of duplicate 867 acknowledgments required to trigger fast retransmit to recover 868 segment losses without waiting for a lengthy retransmission 869 timeout. 871 RFC 6069 E: "Making TCP more Robust to Long Connectivity Disruptions 872 (TCP-LCD)" (December 2010) 874 This document [RFC6069] describes how standard ICMP messages can 875 be used to disambiguate true congestion loss from non-congestion 876 loss caused by connectivity disruptions. It proposes a reversion 877 strategy of TCP's retransmission timer that enables a more prompt 878 detection of whether or not the connectivity has been restored. 880 RFC 6937 E: "Proportional Rate Reduction for TCP" (May 2013) 882 This document [RFC6937] describes an experimental Proportional 883 Rate Reduction (PRR) algorithm as an alternative to the widely 884 deployed Fast Recovery algorithm, to improve the accuracy of the 885 amount of data sent by TCP during loss recovery. 887 4.5. Detection and Prevention of Spurious Retransmissions 889 In addition to the Standards Track extensions to deal with spurious 890 retransmissions in Section 3.4, Experimental proposals have also been 891 documented. 893 RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003) 895 The Eifel detection algorithm [RFC3522] allows a TCP sender to 896 detect a posteriori whether it has entered loss recovery 897 unnecessarily by using the TCP timestamp option to solve the ACK 898 ambiguity. 900 RFC 3708 E: "Using TCP Duplicate Selective Acknowledgement (DSACKs) 901 and Stream Control Transmission Protocol (SCTP) Duplicate 902 Transmission Sequence Numbers (TSNs) to Detect Spurious 903 Retransmissions" (February 2004) 905 Abstract: "TCP and Stream Control Transmission Protocol (SCTP) 906 provide notification of duplicate segment receipt through 907 Duplicate Selective Acknowledgement (DSACKs) and Duplicate 908 Transmission Sequence Number (TSN) notification, respectively. 909 This document presents conservative methods of using this 910 information to identify unnecessary retransmissions for various 911 applications." [RFC3708] 913 RFC 4653 E: "Improving the Robustness of TCP to Non-Congestion 914 Events" (August 2008) 916 In the presence of non-congestion events, such as reordering an 917 out-of-order segment does not necessarily indicates a lost segment 918 and congestion. This document [RFC4653] proposes to increase the 919 threshold used to trigger a fast retransmission from the fixed 920 value of three duplicate ACKs to about one congestion window of 921 data in order to disambiguate true segment loss from segment 922 reordering. 924 4.6. TCP Timeouts 926 Besides the well known retransmission timeout the TCP standard 927 [RFC0793] defines other timeouts. This section lists documents that 928 deals with TCP's various timouts. 930 RFC 5482 S: "TCP User Timeout Option" (June 2009) 932 As a local per-connection parameter the TCP user timeout controls 933 how long transmitted data may remain unacknowledged before a 934 connection is forcefully closed. This document [RFC5482] 935 specifies the TCP User Timeout Option that allows one end of a TCP 936 connection to advertise its current user timeout value. This 937 information provides advice to the other end of the TCP connection 938 to adapt its user timeout accordingly. 940 4.7. Multipath TCP 942 MultiPath TCP (MPTCP) is an ongoing effort within the IETF that 943 allows a TCP connection to simultaneously use multiple IP-addresses/ 944 interfaces to spread their data across several subflows, while 945 presenting a regular TCP interface to applications. Benefits of this 946 include better resource utilization, better throughput and smoother 947 reaction to failures. The documents listed in this section specify 948 the Multipath TCP scheme, while the documents in Sections 7.2, 7.4, 949 and 7.5 provide some additional background information. 951 RFC 6356 E: "Coupled Congestion Control for Multipath Transport 952 Protocols" (August 2011) 954 This document [RFC6356] presents a congestion control algorithm 955 for multipath transport protocols such as Multipath TCP. It 956 couples the congestion control algorithms running on different 957 subflows by linking their increase functions, and dynamically 958 controls the overall aggressiveness of the multipath flow. The 959 result is an algorithm that is fair to TCP at bottlenecks while 960 moving traffic away from congested links. 962 RFC 6824 E: "TCP Extensions for Multipath Operation with Multiple 963 Addresses" (January 2013) (Errata) 965 This document [RFC6824] presents protocol changes required to add 966 multipath capability to TCP; specifically, those for signaling and 967 setting up multiple paths ("subflows"), managing these subflows, 968 reassembly of data, and termination of sessions. 970 5. TCP Parameters at IANA 972 RFCs listed here describes both the procedures that the Internet 973 Assigned Numbers Authority (IANA) uses when handling assignments and 974 the procedures an RFC author should follow when requesting new TCP 975 option codepoints. 977 RFC 2780 B: "IANA Allocation Guidelines For Values In the Internet 978 Protocol and Related Headers" (March 2000) 980 Abstract: "This memo provides guidance for the IANA to use in 981 assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and 982 TCP protocol headers."[RFC2780] 984 RFC 4727 S: "Experimental Values" (November 2006) 986 This document [RFC4727] reserves both TCP options 253 and 254 for 987 experimentation purposes. When such experiments are deployed in 988 the Internet, they should follow the additional requirements in 989 RFC 6994 (see Section 5). 991 RFC 6335 B: "Internet Assigned Numbers Authority (IANA) Procedures 992 for the Management of the Service Name and Transport Protocol Port 993 Number Registry (August 2011) 995 From abstract: "This document defines the procedures that the 996 Internet Assigned Numbers Authority (IANA) uses when handling 997 assignment and other requests related to the Service Name and 998 Transport Protocol Port Number registry." [RFC6335] 1000 RFC 6994 S: "Shared Use of Experimental TCP Options (August 2013) 1002 This document [RFC6994] describes how the experimental TCP option 1003 code points can concurrently support multiple TCP extensions, even 1004 within the same connection. It creates an IANA registry for 1005 extensions to the experimental code points. 1007 6. Historic and Undeployed Extensions 1009 The RFCs listed here define extensions that have thus far failed to 1010 arouse substantial interest from implementers and have never seen 1011 widespread deployment, or were found to be defective for general use. 1012 Most of them are reclassified by [RFC6247] to Historic status. 1014 RFC 721 U: "Out-of-Band Control Signals in a Host-to-Host Protocol" 1015 (September 1976): lack of interest 1017 RFC 721 [RFC0721] addresses the problem of implementing a reliable 1018 out-of-band signal (interrupts) for use in a host-to-host 1019 protocol. The proposal was not included in the final TCP 1020 specification. 1022 RFC 1078 U: "TCP Port Service Multiplexer (TCPMUX)" (November 1988): 1023 lack of interest 1025 This document [RFC1078] proposes a protocol to contact multiple 1026 services on a single well-known TCP port using a service name 1027 instead of a well-known number. 1029 RFC 1106 H: "TCP Big Window and NAK Options" (June 1989): found 1030 defective 1032 This RFC [RFC1106] defined an alternative to the Window Scale 1033 option for using large windows and described the "negative 1034 acknowledgment" or NAK option. There is a comparison of NAK and 1035 SACK methods, and early discussion of TCP over satellite issues. 1036 RFC 1110 (see Section 6) explains some problems with the 1037 approaches described in RFC 1106. The options described in this 1038 document have not been adopted by the larger community, although 1039 NAKs are used in the SCPS-TP adaptation of TCP for satellite and 1040 spacecraft use, developed by the Consultative Committee for Space 1041 Data Systems (CCSDS). 1043 RFC 1110 H: "A Problem with the TCP Big Window Option" (August 1989): 1044 deprecates RFC 1106 1046 Abstract: "The TCP Big Window option discussed in RFC 1106 (see 1047 Section 6) will not work properly in an Internet environment which 1048 has both a high bandwidth * delay product and the possibility of 1049 disordering and duplicating packets. In such networks, the window 1050 size must not be increased without a similar increase in the 1051 sequence number space. Therefore, a different approach to big 1052 windows should be taken in the Internet." [RFC1110] 1054 RFC 1146 H: "TCP Alternate Checksum Options" (March 1990): lack of 1055 interest 1057 This document [RFC1146] defined more robust TCP checksums than the 1058 16-bit ones-complement in use today. A typographical error in RFC 1059 1145 is fixed in RFC 1146; otherwise, the documents are the same. 1061 RFC 1263 I: "TCP Extensions Considered Harmful" (October 1991): lack 1062 of interest 1064 This document [RFC1263] argues against "backwards compatible" TCP 1065 extensions. Specifically mentioned are several TCP enhancements 1066 that have been successful, including timestamps, window scaling, 1067 PAWS, and SACK. RFC 1263 presents an alternative approach called 1068 "protocol evolution", whereby several evolutionary versions of TCP 1069 would exist on hosts. These distinct TCP versions would represent 1070 upgrades to each other and could be header-incompatible. 1071 Interoperability would be provided by having a virtualization 1072 layer select the right TCP version for a particular connection. 1073 This idea did not catch on with the community, while the type of 1074 extensions RFC 1263 specifically targeted as harmful did become 1075 popular. 1077 RFC 1379 H: "Extending TCP for Transactions -- Concepts" (November 1078 1992): found defective 1080 See RFC 1644, Section 6. 1082 RFC 1644 H: "T/TCP -- TCP Extensions for Transactions Functional 1083 Specification" (July 1994): found defective 1085 The inventors of TCP believed that cached connection state could 1086 have been used to eliminate TCP's 3-way handshake, to support two- 1087 packet request/response exchanges. RFC 1379 [RFC1379] (see 1088 Section 6) and RFC 1644 [RFC1644] show that this is far from 1089 simple. Furthermore, T/TCP floundered on the ease of denial-of- 1090 service attacks that can result. One idea pioneered by T/TCP 1091 lives on in RFC 2140 (see Section 4.1), in the sharing of state 1092 across connections. 1094 RFC 1693 H: "An Extension to TCP: Partial Order Service" (November 1095 1994): lack of interest 1097 This document [RFC1693] defines a TCP extension for applications 1098 that do not care about the order in which application-layer 1099 objects are received. Examples are multimedia and database 1100 applications. In practice, these applications either accept the 1101 possible performance loss because of TCP's strict ordering or they 1102 use specialized transport protocols other than TCP, such as PR- 1103 SCTP [RFC3758]. 1105 RFC 1705 I: "Six Virtual Inches to the Left: The Problem with IPng" 1106 (October 1994): lack of interest 1108 To overcome the exhaustion of the IP class B address space, 1109 suggest this document [RFC1705] that a new version of TCP (TCPng) 1110 needs to be developed and deployed. It proposes that a globally 1111 unique address be assigned to Transport layer to uniquely identify 1112 an Internet host without specifying any routing information. 1113 Later work on splitting locator and identifier values is 1114 summarized well in [RFC6115], but no resulting changes to TCP have 1115 occurred. 1117 RFC 6013 E: "TCP Cookie Transactions (TCPCT)" (January 2011): lack of 1118 interest 1120 This document [RFC6013] describes a method to exchange a cookie 1121 (nonce) during the connection establishment to negotiate 1122 elimination of receiver state. These cookies are later used to 1123 inhibit premature closing of connections, and reduce retention of 1124 state after the connection has terminated. 1126 Since the cookie pair is too large to fit with the other TCP 1127 options in the 40 bytes of TCP option space, the document further 1128 describes a method to extent the option space after the connection 1129 establishment. 1131 Although RFC 6013 was published in 2011, the authors of this 1132 document places it in this section of the roadmap document due to 1133 two factors. 1134 (a) The authors are not aware of any wide deployment and use of 1135 RFC 6013. 1137 (b) RFC 6013 uses experimental TCP option codepoints, which 1138 prohibits a large scale deployment. 1140 7. Support Documents 1142 This section contains several classes of documents that do not 1143 necessarily define current protocol behaviors, but that are 1144 nevertheless of interest to TCP implementers. Section 7.1 describes 1145 several foundational RFCs that give modern readers a better 1146 understanding of the principles underlying TCP's behaviors and 1147 development over the years. Section 7.2 contains architectural 1148 guidelines and principles for TCP architects and designers. The 1149 documents listed in Section 7.3 provide advice on using TCP in 1150 various types of network situations that pose challenges above those 1151 of typical wired links. Guidance for developing, analyzing, and 1152 evaluating TCP is given in Section 7.4. Some implementation notes 1153 and implementation advice can be found in Section 7.5. RFCs that 1154 describe tools for testing and debugging TCP implementations or that 1155 contain high-level tutorials on the protocol are listed Section 7.6. 1156 The TCP Management Information Bases are described in Section 7.7, 1157 and Section 7.8 lists a number of case studies that have explored TCP 1158 performance. 1160 7.1. Foundational Works 1162 The documents listed in this section contain information that is 1163 largely duplicated by the standards documents previously discussed. 1164 However, some of them contain a greater depth of problem statement 1165 explanation or other context. Particularly, RFCs 813 - 817 (known as 1166 the "Dave Clark Five") describe some early problems and solutions 1167 (RFC 815 only describes the reassembly of IP fragments and is not 1168 included in this TCP roadmap). 1170 RFC 675 U: "Specification of Internet Transmission Control Program" 1171 (December 1974) 1173 This document [RFC0675] is a very early precursor of the 1174 fundamental RFC 793 (see Section 2), which already contained the 1175 three-way handshake in its final form and the concept of sliding 1176 windows for reliable data transmission. Apart from that the 1177 segment layout is totally different and the specified API differs 1178 from the latter RFC 793 (see Section 2). 1180 RFC 761 U: "DoD standard Transmission Control Protocol" (Januar 1181 1980) 1183 This document [RFC0761] is the immediate precursor of RFC 793 (see 1184 Section 2). The header format, the connection establishment 1185 including the different connection states, and the overall API 1186 correspond mostly to the final Standard RFC 793 (see Section 2). 1188 RFC 813 U: "Window and Acknowledgement Strategy in TCP" (July 1982) 1190 This document [RFC0813] contains an early discussion of Silly 1191 Window Syndrome and its avoidance and motivates and describes the 1192 use of delayed acknowledgments. 1194 RFC 814 U: "Name, Addresses, Ports, and Routes" (July 1982) 1196 Suggestions and guidance for the design of tables and algorithms 1197 to keep track of various identifiers within a TCP/IP 1198 implementation are provided by this document [RFC0814]. 1200 RFC 816 U: "Fault Isolation and Recovery" (July 1982) 1202 In this document [RFC0816], TCP's response to indications of 1203 network error conditions such as timeouts or received ICMP 1204 messages is discussed. 1206 RFC 817 U: "Modularity and Efficiency in Protocol Implementation" 1207 (July 1982) 1209 This document [RFC0817] contains implementation suggestions that 1210 are general and not TCP specific. However, they have been used to 1211 develop TCP implementations and describe some performance 1212 implications of the interactions between various layers in the 1213 Internet stack. 1215 RFC 872 U: "TCP-on-a-LAN" (September 1982) 1217 Conclusion: "The sometimes-expressed fear that using TCP on a 1218 local net is a bad idea is unfounded." [RFC0872] 1220 RFC 896 U: "Congestion Control in IP/TCP Internetworks" (January 1221 1984) 1223 This document [RFC0896] contains some early experiences with 1224 congestion collapse and some initial thoughts on how to avoid it 1225 using congestion control in TCP. Furthermore, it defined an 1226 algorithm for efficient transmission of small packets that is 1227 today known as the Nagle Algorithm. 1229 RFC 964 U: "Some Problems with the Specification of the Military 1230 Standard Transmission Control Protocol" (November 1985) 1232 This document [RFC0964] points out several specification bugs in 1233 the US Military's MIL-STD-1778 document, which was intended as a 1234 successor to RFC 793 (see Section 2). This serves to remind us of 1235 the difficulty in specification writing (even when we work from 1236 existing documents!). 1238 7.2. Architectural Guidelines 1240 Some documents in this section contain architectural guidance and 1241 concerns, while others specify TCP- and congestion-control-related 1242 mechanisms that are broadly applicable and have impacts on TCP's 1243 congestion control techniques. Some of these documents are direct 1244 products of the Internet Architecture Board (IAB), giving their 1245 guidance on specific aspects of congestion control in the Internet. 1247 RFC 1958 I: "Architectural Principles of the Internet" (June 1996) 1249 This document [RFC1958] describes the underlying principles of the 1250 Internet architecture. It provides guidelines for network systems 1251 design that have proven useful in the evolution of the Internet. 1253 RFC 2914 B: "Congestion Control Principles" (September 2000) 1255 This document [RFC2914] motivates the use of end-to-end congestion 1256 control for preventing congestion collapse and providing fairness 1257 to TCP. Later work on TCP has included several more aggressive 1258 mechanisms than Reno TCP includes, and RFC 5033 (see Section 7.4) 1259 provides additional guidance on use of such algorithms. The 1260 fundamental architectural discussion in RFC 2914 remains valid, 1261 regarding the standards process role in defining protocol aspects 1262 that are critical to performance and avoiding congestion collapse 1263 scenarios. 1265 RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August 1266 2002) 1268 This document [RFC3360] is a plea that firewall vendors not send 1269 gratuitous TCP RST (Reset) packets when unassigned TCP header bits 1270 are used. This practice prevents desirable extension and 1271 evolution of the protocol and thus is potentially harmful to the 1272 future of the Internet. 1274 RFC 3439 I: "Some Internet Architectural Guidelines and Philosophy" 1275 (December 2002) 1277 This document [RFC3439] updates RFC 1958 (see Section 7.2) by 1278 outlining some philosophical guidelines for architects and 1279 designers of Internet backbone networks. The document describes 1280 the Simplicity Principle, which states that complexity is the 1281 primary impediment to efficient scaling. 1283 RFC 4774 B: "Specifying Alternate Semantics for the Explicit 1284 Congestion Notification (ECN) Field" (November 2006) 1286 This document [RFC4774] discusses some of the issues in defining 1287 alternate semantics for the ECN field, and specifies requirements 1288 for a safe co-existence with routers that do not understand the 1289 defined alternate semantics. 1291 RFC 6182 I: "Architectural Guidelines for Multipath TCP Development" 1292 (March 2011) 1294 Abstract: "This document outlines architectural guidelines for the 1295 development of a Multipath Transport Protocol, with references to 1296 how these architectural components come together in the 1297 development of a Multipath TCP (MPTCP) (see Section 4.7). This 1298 document lists certain high-level design decisions that provide 1299 foundations for the design of the MPTCP protocol, based upon these 1300 architectural requirements" [RFC6182] 1302 7.3. Difficult Network Environments 1304 As the internetworking field has explored wireless, satellite, 1305 cellular telephone, and other kinds of link-layer technologies, a 1306 large body of work has built up on enhancing TCP performance for such 1307 links. The RFCs listed in this section describe some of these more 1308 challenging network environments and how TCP interacts with them. 1310 RFC 2488 B: "Enhancing TCP Over Satellite Channels using Standard 1311 Mechanisms" (January 1999) 1313 From abstract: "While TCP works over satellite channels there are 1314 several IETF standardized mechanisms that enable TCP to more 1315 effectively utilize the available capacity of the network path. 1316 This document outlines some of these TCP mitigations. At this 1317 time, all mitigations discussed in this document are IETF 1318 standards track mechanisms (or are compliant with IETF 1319 standards)." [RFC2488] 1321 RFC 2757 I: "Long Thin Networks" (January 2000) 1323 Several methods of improving TCP performance over long thin 1324 networks (i.e., networks with low bandwidth and high delay), such 1325 as geosynchronous satellite links, are discussed in this document 1326 [RFC2757]. A particular set of TCP options is developed that 1327 should work well in such environments and be safe to use in the 1328 global Internet. The implications of such environments have been 1329 further discussed in RFC 3150 (see Section 7.3) and RFC 3155 (see 1330 Section 7.3), and these documents should be preferred where there 1331 is overlap between them and RFC 2757 (see Section 7.3). 1333 RFC 2760 I: "Ongoing TCP Research Related to Satellites" (February 1334 2000) 1336 This document [RFC2760] discusses the advantages and disadvantages 1337 of several different experimental means of improving TCP 1338 performance over long-delay or error-prone paths. These include 1339 T/TCP, larger initial windows, byte counting, delayed 1340 acknowledgments, slow start thresholds, NewReno and SACK-based 1341 loss recovery, FACK [MM96], ECN, various corruption-detection 1342 mechanisms, congestion avoidance changes for fairness, use of 1343 multiple parallel flows, pacing, header compression, state 1344 sharing, and ACK congestion control, filtering, and 1345 reconstruction. Although RFC 2488 (see Section 7.3) looks at 1346 standard extensions, this document focuses on more experimental 1347 means of performance enhancement. 1349 RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate Link- 1350 Related Degradations" (June 2001) 1352 From abstract: "This document is a survey of Performance Enhancing 1353 Proxies (PEPs) often employed to improve degraded TCP performance 1354 caused by characteristics of specific link environments, for 1355 example, in satellite, wireless WAN, and wireless LAN 1356 environments. Different types of Performance Enhancing Proxies 1357 are described as well as the mechanisms used to improve 1358 performance." [RFC3135] 1360 RFC 3150 B: "End-to-end Performance Implications of Slow Links" (July 1361 2001) 1363 From abstract: "This document makes performance-related 1364 recommendations for users of network paths that traverse "very low 1365 bit-rate" links....This recommendation may be useful in any 1366 network where hosts can saturate available bandwidth, but the 1367 design space for this recommendation explicitly includes 1368 connections that traverse 56 Kb/second modem links or 4.8 Kb/ 1369 second wireless access links - both of which are widely deployed." 1370 [RFC3150] 1372 RFC 3155 B: "End-to-end Performance Implications of Links with 1373 Errors" (August 2001) 1375 From abstract: "This document discusses the specific TCP 1376 mechanisms that are problematic in environments with high 1377 uncorrected error rates, and discusses what can be done to 1378 mitigate the problems without introducing intermediate devices 1379 into the connection." [RFC3155] 1381 RFC 3366 B: "Advice to link designers on link Automatic Repeat 1382 reQuest (ARQ)" (August 2002) 1384 From abstract: "This document provides advice to the designers of 1385 digital communication equipment and link-layer protocols employing 1386 link-layer Automatic Repeat reQuest (ARQ) techniques. This 1387 document presumes that the designers wish to support Internet 1388 protocols, but may be unfamiliar with the architecture of the 1389 Internet and with the implications of their design choices for the 1390 performance and efficiency of Internet traffic carried over their 1391 links." [RFC3366] 1393 RFC 3449 B: "TCP Performance Implications of Network Path Asymmetry" 1394 (December 2002) 1396 From abstract: "This document describes TCP performance problems 1397 that arise because of asymmetric effects. These problems arise in 1398 several access networks, including bandwidth-asymmetric networks 1399 and packet radio subnetworks, for different underlying reasons. 1400 However, the end result on TCP performance is the same in both 1401 cases: performance often degrades significantly because of 1402 imperfection and variability in the ACK feedback from the receiver 1403 to the sender. 1405 The document details several mitigations to these effects, which 1406 have either been proposed or evaluated in the literature, or are 1407 currently deployed in networks." [RFC3449] 1409 RFC 3481 B: "TCP over Second (2.5G) and Third (3G) Generation 1410 Wireless Networks" (February 2003) 1412 From abstract: "This document describes a profile for optimizing 1413 TCP to adapt so that it handles paths including second (2.5G) and 1414 third (3G) generation wireless networks." [RFC3481] 1416 RFC 3819 B: "Advice for Internet Subnetwork Designers" (July 2004) 1418 This document [RFC3819] describes how TCP performance can be 1419 negatively affected by some particular lower-layer behaviors and 1420 provides guidance in designing lower-layer networks and protocols 1421 to be amicable to TCP. RFC 3366 (see Section 7.3) specifically 1422 focuses on ARQ mechanisms, while RFC 3819 more widely covers 1423 additional aspects of the underlying layers 1425 7.4. Guidance for Developing, Analyzing, and Evaluating TCP 1427 Documents in this section give general guidance for developing, 1428 analyzing, and evaluating TCP. Some of the documents discuss for 1429 example the properties of congestion control protocols that are 1430 "safe" for Internet deployment, as well as how to measure the 1431 properties of congestion control mechanisms and transport protocols. 1433 RFC 5033 B: "Specifying New Congestion Control Algorithms" (August 1434 2007) 1436 This document [RFC5033] considers the evaluation of suggested 1437 congestion control algorithms that differ from the principles 1438 outlined in RFC 2914 (see Section 7.2). It is useful for authors 1439 of such algorithms as well as for IETF members reviewing the 1440 associated documents. 1442 RFC 5166 I: "Metrics for the Evaluation of Congestion Control 1443 Mechanisms" (March 2008) 1445 This document [RFC5166] discusses metrics that needs to be 1446 considered when evaluating new or modified congestion control 1447 mechanisms for the Internet. Among others topics, the document 1448 discusses throughput, delay, loss rates, response times, fairness 1449 and robustness for challenging environments. 1451 RFC 6077 I: "Open Research Issues in Internet Congestion Control" 1452 (January 2011) 1454 This RFC [RFC6077] summarizes the main open problems in the domain 1455 of Internet congestion control. As a good starting point for 1456 newcomers, the document describes several new challenges that are 1457 becoming important as the network grows, as well as some issues 1458 that have been known for many years. 1460 RFC 6181 I: "Threat Analysis for TCP Extensions for Multipath 1461 Operation with Multiple Addresses" (March 2011) 1463 This document [RFC6181] describes a threat analysis for Multipath 1464 TCP (MPTCP) (see Section 4.7). The document discusses several 1465 types of attacks and provides recommendations for MPTCP designers 1466 how to create an MPTCP specification that is as secure as the 1467 current (single-path) TCP. 1469 RFC 6349 I: "Framework for TCP Throughput Testing" (August 2011) 1471 From abstract: "This document describes a practical methodology 1472 for measuring end-to-end TCP throughput in a managed IP network. 1473 The goal is to provide a better indication in regard to user 1474 experience. In this framework, TCP and IP parameters are 1475 specified to optimize TCP throughput." [RFC6349] 1477 7.5. Implementation Advice 1479 RFC 794 U: "PRE-EMPTION" (September 1981) 1481 This document [RFC0794] clarifies that operating systems need to 1482 manage their limited resources, which may include TCP connection 1483 state, and that these decisions can be made with application 1484 input, but they do not need to be part of the TCP protocol 1485 specification itself. 1487 RFC 879 U: "The TCP Maximum Segment Size and Related Topics" 1488 (November 1983) 1490 Abstract: "This memo discusses the TCP Maximum Segment Size Option 1491 and related topics. The purposes is to clarify some aspects of 1492 TCP and its interaction with IP. This memo is a clarification to 1493 the TCP specification, and contains information that may be 1494 considered as 'advice to implementers'." [RFC0879] 1496 RFC 1071 U: "Computing the Internet Checksum" (September 1988) 1497 (Errata) 1499 This document [RFC1071] lists a number of implementation 1500 techniques for efficiently computing the Internet checksum (used 1501 by TCP). 1503 RFC 1624 I: "Computation of the Internet Checksum via Incremental 1504 Update" (May 1994) 1506 Incrementally updating the Internet checksum is useful to routers 1507 in updating IP checksums. Some middleboxes that alter TCP headers 1508 may also be able to update the TCP checksum incrementally. This 1509 document [RFC1624] expands upon the explanation of the incremental 1510 update procedure in RFC 1071 (see Section 7.5). 1512 RFC 1936 I: "Implementing the Internet Checksum in Hardware" (April 1513 1996) 1515 This document [RFC1936] describes the motivation for implementing 1516 the Internet checksum in hardware, rather than in software, and 1517 provides an implementation example. 1519 RFC 2525 I: "Known TCP Implementation Problems" (March 1999) 1521 From abstract: "This memo catalogs a number of known TCP 1522 implementation problems. The goal is to improve conditions in the 1523 existing Internet by enhancing the quality of current TCP/IP 1524 implementations." [RFC2525] 1526 RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000) 1528 From abstract: "This memo catalogs several known Transmission 1529 Control Protocol (TCP) implementation problems dealing with Path 1530 Maximum Transmission Unit Discovery (PMTUD), including the long- 1531 standing black hole problem, stretch acknowledgments (ACKs) due to 1532 confusion between Maximum Segment Size (MSS) and segment size, and 1533 MSS advertisement based on PMTU." [RFC2923] 1535 RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (February 1536 2003) 1538 This document [RFC3493] describes the de facto standard sockets 1539 API for programming with TCP. This API is implemented nearly 1540 ubiquitously in modern operating systems and programming 1541 languages. 1543 RFC 6056 B: "Recommendations for Transport-Protocol Port 1544 Randomization" (December 2010) 1546 This document [RFC6056] describes a number of simple and efficient 1547 methods for the selection of the client port number. It reduces 1548 the possibility of an attacker guessing the correct five-tuple 1549 (Protocol, Source/Destination Address, Source/Destination Port). 1551 RFC 6191 B: "Reducing the TIME-WAIT State Using TCP timestamps" 1552 (April 2011) 1554 This document [RFC6191] describes the usage of the TCP Timestamps 1555 option (RFC 7323, see Section 3.1) to perform heuristics to 1556 determine whether or not to allow the creation of a new 1557 incarnation of a connection that is in the TIME-WAIT state. 1559 RFC 6429 I: "TCP Sender Clarification for Persist Condition" 1560 (December 2011) 1562 This document [RFC6429] clarifies the actions that a TCP can take 1563 on connections that are experiencing the Zero Window Probe (ZWP) 1564 condition. 1566 RFC 6897 I: "Multipath TCP (MPTCP) Application Interface 1567 Considerations" (March 2013) 1569 This document [RFC6897] characterizes the impact that Multipath 1570 TCP (MPTCP) (see Section 4.7) may have on applications. It 1571 further discusses compatibility issues of MPTCP in combination 1572 with non-MPTCP-aware applications. Finally, it describes a basic 1573 API that is a simple extension of TCP's interface for MPTCP-aware 1574 applications. 1576 7.6. Tools and Tutorials 1578 RFC 1180 I: "TCP/IP Tutorial" (January 1991) (Errata) 1580 This document [RFC1180] is an extremely brief overview of the 1581 TCP/IP protocol suite as a whole. It gives some explanation as to 1582 how and where TCP fits in. 1584 RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for 1585 Monitoring and Debugging TCP/IP Internets and Interconnected Devices" 1586 (June 1993) 1588 A few of the tools that this document [RFC1470] describes are 1589 still maintained and in use today; for example, ttcp and tcpdump. 1590 However, many of the tools described do not relate specifically to 1591 TCP and are no longer used or easily available. 1593 RFC 2398 I: "Some Testing Tools for TCP Implementors" (August 1998) 1595 This document [RFC2398] describes a number of TCP packet 1596 generation and analysis tools. Although some of these tools are 1597 no longer readily available or widely used, for the most part they 1598 are still relevant and usable. 1600 RFC 5783 I: "Congestion Control in the RFC Series" (February 2010) 1602 This document [RFC5783] provides an overview of RFCs related to 1603 congestion control that have been published so far. The focus of 1604 the document is on end-host-based congestion control. 1606 7.7. MIB Modules 1608 The first MIB module defined for use with Simple Network Management 1609 Protocol (SNMP) was a single monolithic MIB module, called MIB-I, 1610 defined in RFC 1156. This evolved over time to the MIB-II 1611 specification in RFC 1213, which obsoletes RFC 1156. It then became 1612 apparent that having a single monolithic MIB module was not scalable, 1613 given the number and breadth of MIB data definitions that needed to 1614 be included. Thus, additional MIB modules were defined, and those 1615 parts of MIB-II that needed to evolve were split off. Eventually, 1616 the remaining parts of MIB-II were also split off, the TCP-specific 1617 part being documented in RFC 2012. RFC 2012 was obsoleted by RFC 1618 4022, which is the primary TCP MIB document today. For current TCP 1619 implementers, RFC 4022 should be supported. 1621 RFC 1156 S: "Management Information Base for Network Management of 1622 TCP/IP-based Internets" (May 1990) 1624 This document [RFC1156] describes the required MIB fields for TCP 1625 implementations with minor corrections and no technical changes 1626 from RFC 1066, which it obsoletes. This is the standards track 1627 document for MIB-I. 1629 RFC 1213 S: "Management Information Base for Network Management of 1630 TCP/IP-based Internets: MIB-II" (March 1991) 1632 This document [RFC1213] describes the second version of the MIB in 1633 a monolithic form. It is the immediate successor of RFC 1158, 1634 with minor modifications. It obsoletes the MIB-I, defined in RFC 1635 1156 (see Section 7.7). 1637 RFC 2012 S: "SNMPv2 Management Information Base for the Transmission 1638 Control Protocol using SMIv2" (November 1996) 1640 In an update to RFC 1213 (see Section 7.7), this document 1641 [RFC2012] defines the TCP MIB by splitting out the TCP-specific 1642 portions. It is now obsoleted by RFC 4022 (see Section 7.7). 1644 RFC 2452 S: "IP Version 6 Management Information Base for the 1645 Transmission Control Protocol" (December 1998) 1647 This document [RFC2452] augments RFC 2012 (see Section 7.7) by 1648 adding an IPv6-specific connection table. The rest of RFC 2012 1649 holds for any IP version. RFC 2452 is now obsoleted by RFC 4022 1650 (see Section 7.7). 1652 Although it is a standards track document, RFC 2452 is considered 1653 a historic mistake by the MIB community, as it is based on the 1654 idea of parallel IPv4 and IPv6 structures. Although IPv6 requires 1655 new structures, the community has decided to define a single 1656 generic structure for both IPv4 and IPv6. This will aid in 1657 definition, implementation, and transition between IPv4 and IPv6. 1659 RFC 4022 S: "Management Information Base for the Transmission Control 1660 Protocol (TCP)" (March 2005) 1662 This document [RFC4022] obsoletes RFC 2012 (see Section 7.7) and 1663 RFC 2452 (see Section 7.7) and specifies the current standard for 1664 the TCP MIB that should be deployed. 1666 RFC 4898 S: "TCP Extended Statistics MIB" (May 2007) 1668 This document [RFC4898] describes extended performance statistics 1669 for TCP. They are designed to use TCP's ideal vantage point to 1670 diagnose performance problems in both the network and the 1671 application. 1673 7.8. Case Studies 1675 RFC 700 U: "A Protocol Experiment" (August 1974) 1677 This document [RFC0700] presents a field report about the 1678 deployment of a very early version of TCP, the so-called INWN #39 1679 protocol, which is originally described by Cerf and Kahn in INWG 1680 Note #39 [CK73] to use a PDP-11 line printer via the ARPANET. 1682 RFC 889 U: "Internet Delay Experiments" (December 1983) 1684 This document [RFC0889] is a status report about experiments 1685 concerning the TCP retransmission timeout calculation and also 1686 provides advices for implementers. 1688 RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 1992) 1690 This document [RFC1337] points out a problem with acting on 1691 received reset segments while one is in the TIME-WAIT state. The 1692 main recommendation is that hosts in TIME-WAIT ignore resets. 1693 This recommendation might not currently be widely implemented. 1695 RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size" 1696 (September 1998) 1698 This document [RFC2415] presents results of some simulations using 1699 TCP initial windows greater than 1 segment. The analysis 1700 indicates that user-perceived performance can be improved by 1701 increasing the initial window to 3 segments. 1703 RFC 2416 I: "When TCP Starts Up With Four Packets Into Only Three 1704 Buffers" (September 1998) 1706 This document [RFC2416] uses simulation results to clear up some 1707 concerns about using an initial window of 4 segments when the 1708 network path has less provisioning. 1710 RFC 2884 I: "Performance Evaluation of Explicit Congestion 1711 Notification (ECN) in IP Networks" (July 2000) 1713 This document [RFC2884] describes experimental results that show 1714 some improvements to the performance of both short- and long-lived 1715 connections due to ECN. 1717 8. Undocumented TCP Features 1719 There are a few important implementation tactics for the TCP that 1720 have not yet been described in any RFC. Although this roadmap is 1721 primarily concerned with mapping the TCP RFCs, this section is 1722 included because an implementer needs to be aware of these important 1723 issues. 1725 Header Prediction 1727 Header prediction is a trick to speed up the processing of 1728 segments. Van Jacobson and Mike Karels developed the technique in 1729 the late 1980s. The basic idea is that some processing time can 1730 be saved when most of a segment's fields can be predicted from 1731 previous segments. A good description of this was sent to the 1732 TCP-IP mailing list by Van Jacobson on March 9, 1988: 1734 "Quite a bit of the speedup comes from an algorithm that we ('we' 1735 refers to collaborator Mike Karels and myself) are calling "header 1736 prediction". The idea is that if you're in the middle of a bulk 1737 data transfer and have just seen a packet, you know what the next 1738 packet is going to look like: It will look just like the current 1739 packet with either the sequence number or ack number updated 1740 (depending on whether you're the sender or receiver). Combining 1741 this with the "Use hints" epigram from Butler Lampson's classic 1742 "Epigrams for System Designers", you start to think of the tcp 1743 state (rcv.nxt, snd.una, etc.) as "hints" about what the next 1744 packet should look like. 1746 If you arrange those "hints" so they match the layout of a tcp 1747 packet header, it takes a single 14-byte compare to see if your 1748 prediction is correct (3 longword compares to pick up the send & 1749 ack sequence numbers, header length, flags and window, plus a 1750 short compare on the length). If the prediction is correct, 1751 there's a single test on the length to see if you're the sender or 1752 receiver followed by the appropriate processing. E.g., if the 1753 length is non-zero (you're the receiver), checksum and append the 1754 data to the socket buffer then wake any process that's sleeping on 1755 the buffer. Update rcv.nxt by the length of this packet (this 1756 updates your "prediction" of the next packet). Check if you can 1757 handle another packet the same size as the current one. If not, 1758 set one of the unused flag bits in your header prediction to 1759 guarantee that the prediction will fail on the next packet and 1760 force you to go through full protocol processing. Otherwise, 1761 you're done with this packet. So, the *total* tcp protocol 1762 processing, exclusive of checksumming, is on the order of 6 1763 compares and an add." 1765 Forward Acknowledgement (FACK) 1767 FACK [MM96] includes an alternate algorithm for triggering fast 1768 retransmit [RFC5681], based on the extent of the SACK scoreboard. 1769 Its goal is to trigger fast retransmit as soon as the receiver's 1770 reassembly queue is larger than the duplicate ACK threshold, as 1771 indicated by the difference between the forward most SACK block 1772 edge and SND.UNA. This algorithm quickly and reliably triggers 1773 fast retransmit in the presence of burst losses -- often on the 1774 first SACK following such a loss. Such a threshold based 1775 algorithm also triggers fast retransmit immediately in the 1776 presence of any reordering with extent greater than the duplicate 1777 ACK threshold. FACK is implemented in Linux and turned on per 1778 default. 1780 Congestion Control for High Rate Flows 1782 In the last decade significant research effort has been put into 1783 experimental TCP congestion control modifications for obtaining 1784 high throughput with reduced startup and recovery times. Only few 1785 RFCs have been published on some of these modifications, including 1786 HighSpeed TCP [RFC3649] (see Section 4.3), Limited Slow-Start 1787 [RFC3742] (see Section 4.3), and Quick-Start [RFC4782] (see 1788 Section 4.3), but high-rate congestion control mechanisms are 1789 still considered an open issue in congestion control research. 1790 Some other schemes have been published as Internet-Drafts, e.g. 1791 CUBIC [I-D.rhee-tcpm-cubic] (the standard TCP congestion control 1792 algorithm in Linux), Compound TCP [I-D.sridharan-tcpm-ctcp], and 1793 H-TCP [I-D.leith-tcp-htcp] or have been discussed a little by the 1794 IETF, but much of the work in this area has not been adopted 1795 within the IETF yet, so the majority of this work is outside the 1796 RFC series and may be discussed in other products of the IRTF 1797 Internet Congestion Control Research Group (ICCRG). 1799 9. Security Considerations 1801 This document introduces no new security considerations. Each RFC 1802 listed in this document attempts to address the security 1803 considerations of the specification it contains. 1805 10. IANA Considerations 1807 This document contains no IANA considerations. 1809 11. Acknowledgments 1811 This document grew out of a discussion on the end2end-interest 1812 mailing list, the public list of the End-to-End Research Group of the 1813 IRTF, and continued development under the IETF's TCP Maintenance and 1814 Minor Extensions (TCPM) working group. We thank Mark Allman, Yuchung 1815 Cheng, Ted Faber, Fairhurst, Sally Floyd, Janardhan Iyengar, Reiner 1816 Ludwig, Pekka Savola, and Joe Touch for their contributions, in 1817 particular. Keith McCloghrie provided some useful notes and 1818 clarification on the various MIB-related RFCs. 1820 12. References 1822 12.1. Normative References 1824 [I-D.ietf-tcpm-1323bis] 1825 Borman, D., Braden, R., Jacobson, V., and R. 1826 Scheffenegger, "TCP Extensions for High Performance", 1827 draft-ietf-tcpm-1323bis-21 (work in progress), April 2014. 1829 [I-D.ietf-tcpm-fastopen] 1830 Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1831 Fast Open", draft-ietf-tcpm-fastopen-08 (work in 1832 progress), March 2014. 1834 [RFC0675] Cerf, V., Dalal, Y., and C. Sunshine, "Specification of 1835 Internet Transmission Control Program", RFC 675, 1836 December 1974. 1838 [RFC0700] Mader, E., Plummer, W., and R. Tomlinson, "Protocol 1839 experiment", RFC 700, August 1974. 1841 [RFC0721] Garlick, L., "Out-of-Band Control Signals in a Host-to- 1842 Host Protocol", RFC 721, September 1976. 1844 [RFC0761] Postel, J., "DoD standard Transmission Control Protocol", 1845 RFC 761, January 1980. 1847 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1848 RFC 793, September 1981. 1850 [RFC0794] Cerf, V., "Pre-emption", RFC 794, September 1981. 1852 [RFC0813] Clark, D., "Window and Acknowledgement Strategy in TCP", 1853 RFC 813, July 1982. 1855 [RFC0814] Clark, D., "Name, addresses, ports, and routes", RFC 814, 1856 July 1982. 1858 [RFC0816] Clark, D., "Fault isolation and recovery", RFC 816, 1859 July 1982. 1861 [RFC0817] Clark, D., "Modularity and efficiency in protocol 1862 implementation", RFC 817, July 1982. 1864 [RFC0872] Padlipsky, M., "TCP-on-a-LAN", RFC 872, September 1982. 1866 [RFC0879] Postel, J., "TCP maximum segment size and related topics", 1867 RFC 879, November 1983. 1869 [RFC0889] Mills, D., "Internet delay experiments", RFC 889, 1870 December 1983. 1872 [RFC0896] Nagle, J., "Congestion control in IP/TCP internetworks", 1873 RFC 896, January 1984. 1875 [RFC0964] Sidhu, D. and T. Blumer, "Some problems with the 1876 specification of the Military Standard Transmission 1877 Control Protocol", RFC 964, November 1985. 1879 [RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, 1880 "Computing the Internet checksum", RFC 1071, 1881 September 1988. 1883 [RFC1078] Lottor, M., "TCP port service Multiplexer (TCPMUX)", 1884 RFC 1078, November 1988. 1886 [RFC1106] Fox, R., "TCP big window and NAK options", RFC 1106, 1887 June 1989. 1889 [RFC1110] McKenzie, A., "Problem with the TCP big window option", 1890 RFC 1110, August 1989. 1892 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1893 Communication Layers", STD 3, RFC 1122, October 1989. 1895 [RFC1144] Jacobson, V., "Compressing TCP/IP headers for low-speed 1896 serial links", RFC 1144, February 1990. 1898 [RFC1146] Zweig, J. and C. Partridge, "TCP alternate checksum 1899 options", RFC 1146, March 1990. 1901 [RFC1156] McCloghrie, K. and M. Rose, "Management Information Base 1902 for network management of TCP/IP-based internets", 1903 RFC 1156, May 1990. 1905 [RFC1180] Socolofsky, T. and C. Kale, "TCP/IP tutorial", RFC 1180, 1906 January 1991. 1908 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1909 November 1990. 1911 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 1912 for Network Management of TCP/IP-based internets:MIB-II", 1913 STD 17, RFC 1213, March 1991. 1915 [RFC1263] O'Malley, S. and L. Peterson, "TCP Extensions Considered 1916 Harmful", RFC 1263, October 1991. 1918 [RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", 1919 RFC 1337, May 1992. 1921 [RFC1379] Braden, B., "Extending TCP for Transactions -- Concepts", 1922 RFC 1379, November 1992. 1924 [RFC1470] Enger, R. and J. Reynolds, "FYI on a Network Management 1925 Tool Catalog: Tools for Monitoring and Debugging TCP/IP 1926 Internets and Interconnected Devices", RFC 1470, 1927 June 1993. 1929 [RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via 1930 Incremental Update", RFC 1624, May 1994. 1932 [RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions 1933 Functional Specification", RFC 1644, July 1994. 1935 [RFC1693] Connolly, T., Amer, P., and P. Conrad, "An Extension to 1936 TCP : Partial Order Service", RFC 1693, November 1994. 1938 [RFC1705] Carlson, R. and D. Ficarella, "Six Virtual Inches to the 1939 Left: The Problem with IPng", RFC 1705, October 1994. 1941 [RFC1936] Touch, J. and B. Parham, "Implementing the Internet 1942 Checksum in Hardware", RFC 1936, April 1996. 1944 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1945 RFC 1958, June 1996. 1947 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1948 for IP version 6", RFC 1981, August 1996. 1950 [RFC2012] McCloghrie, K., "SNMPv2 Management Information Base for 1951 the Transmission Control Protocol using SMIv2", RFC 2012, 1952 November 1996. 1954 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP 1955 Selective Acknowledgment Options", RFC 2018, October 1996. 1957 [RFC2140] Touch, J., "TCP Control Block Interdependence", RFC 2140, 1958 April 1997. 1960 [RFC2398] Parker, S. and C. Schmechel, "Some Testing Tools for TCP 1961 Implementors", RFC 2398, August 1998. 1963 [RFC2415] Poduri, K., "Simulation Studies of Increased Initial TCP 1964 Window Size", RFC 2415, September 1998. 1966 [RFC2416] Shepard, T. and C. Partridge, "When TCP Starts Up With 1967 Four Packets Into Only Three Buffers", RFC 2416, 1968 September 1998. 1970 [RFC2452] Daniele, M., "IP Version 6 Management Information Base for 1971 the Transmission Control Protocol", RFC 2452, 1972 December 1998. 1974 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1975 (IPv6) Specification", RFC 2460, December 1998. 1977 [RFC2488] Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP 1978 Over Satellite Channels using Standard Mechanisms", 1979 BCP 28, RFC 2488, January 1999. 1981 [RFC2525] Paxson, V., Dawson, S., Fenner, W., Griner, J., Heavens, 1982 I., Lahey, K., Semke, J., and B. Volz, "Known TCP 1983 Implementation Problems", RFC 2525, March 1999. 1985 [RFC2675] Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms", 1986 RFC 2675, August 1999. 1988 [RFC2757] Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N. 1989 Vaidya, "Long Thin Networks", RFC 2757, January 2000. 1991 [RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., 1992 Henderson, T., Heidemann, J., Touch, J., Kruse, H., 1993 Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP 1994 Research Related to Satellites", RFC 2760, February 2000. 1996 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1997 Values In the Internet Protocol and Related Headers", 1998 BCP 37, RFC 2780, March 2000. 2000 [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion 2001 Window Validation", RFC 2861, June 2000. 2003 [RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP 2004 Processing of the IPv4 Precedence Field", RFC 2873, 2005 June 2000. 2007 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 2008 Extension to the Selective Acknowledgement (SACK) Option 2009 for TCP", RFC 2883, July 2000. 2011 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 2012 Explicit Congestion Notification (ECN) in IP Networks", 2013 RFC 2884, July 2000. 2015 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 2016 RFC 2914, September 2000. 2018 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2019 RFC 2923, September 2000. 2021 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 2022 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 2023 January 2001. 2025 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 2026 RFC 3124, June 2001. 2028 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 2029 Shelby, "Performance Enhancing Proxies Intended to 2030 Mitigate Link-Related Degradations", RFC 3135, June 2001. 2032 [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, 2033 "End-to-end Performance Implications of Slow Links", 2034 BCP 48, RFC 3150, July 2001. 2036 [RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. 2037 Vaidya, "End-to-end Performance Implications of Links with 2038 Errors", BCP 50, RFC 3155, August 2001. 2040 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2041 of Explicit Congestion Notification (ECN) to IP", 2042 RFC 3168, September 2001. 2044 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 2045 BCP 60, RFC 3360, August 2002. 2047 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 2048 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 2049 August 2002. 2051 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 2052 Initial Window", RFC 3390, October 2002. 2054 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 2055 Guidelines and Philosophy", RFC 3439, December 2002. 2057 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 2058 Sooriyabandara, "TCP Performance Implications of Network 2059 Path Asymmetry", BCP 69, RFC 3449, December 2002. 2061 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 2062 Counting (ABC)", RFC 3465, February 2003. 2064 [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and 2065 F. Khafizov, "TCP over Second (2.5G) and Third (3G) 2066 Generation Wireless Networks", BCP 71, RFC 3481, 2067 February 2003. 2069 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 2070 Stevens, "Basic Socket Interface Extensions for IPv6", 2071 RFC 3493, February 2003. 2073 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 2074 for TCP", RFC 3522, April 2003. 2076 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 2077 Congestion Notification (ECN) Signaling with Nonces", 2078 RFC 3540, June 2003. 2080 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 2081 RFC 3649, December 2003. 2083 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 2084 Acknowledgement (DSACKs) and Stream Control Transmission 2085 Protocol (SCTP) Duplicate Transmission Sequence Numbers 2086 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 2087 February 2004. 2089 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 2090 Congestion Windows", RFC 3742, March 2004. 2092 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2093 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2094 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2095 RFC 3819, July 2004. 2097 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 2098 for TCP", RFC 4015, February 2005. 2100 [RFC4022] Raghunarayan, R., "Management Information Base for the 2101 Transmission Control Protocol (TCP)", RFC 4022, 2102 March 2005. 2104 [RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, 2105 "Improving the Robustness of TCP to Non-Congestion 2106 Events", RFC 4653, August 2006. 2108 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 2109 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 2111 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 2112 Explicit Congestion Notification (ECN) Field", BCP 124, 2113 RFC 4774, November 2006. 2115 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 2116 Start for TCP and IP", RFC 4782, January 2007. 2118 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2119 Discovery", RFC 4821, March 2007. 2121 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 2122 Extended Statistics MIB", RFC 4898, May 2007. 2124 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 2125 RFC 4953, July 2007. 2127 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2128 Mitigations", RFC 4987, August 2007. 2130 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 2131 Control Algorithms", BCP 133, RFC 5033, August 2007. 2133 [RFC5166] Floyd, S., "Metrics for the Evaluation of Congestion 2134 Control Mechanisms", RFC 5166, March 2008. 2136 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 2137 February 2009. 2139 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 2140 RFC 5482, March 2009. 2142 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 2143 Ramakrishnan, "Adding Explicit Congestion Notification 2144 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, 2145 June 2009. 2147 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 2148 Control", RFC 5681, September 2009. 2150 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 2151 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 2152 Spurious Retransmission Timeouts with TCP", RFC 5682, 2153 September 2009. 2155 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 2156 Acknowledgement Congestion Control to TCP", RFC 5690, 2157 February 2010. 2159 [RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC 2160 Series", RFC 5783, February 2010. 2162 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 2163 P. Hurtig, "Early Retransmit for TCP and Stream Control 2164 Transmission Protocol (SCTP)", RFC 5827, May 2010. 2166 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2167 Authentication Option", RFC 5925, June 2010. 2169 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 2170 for the TCP Authentication Option (TCP-AO)", RFC 5926, 2171 June 2010. 2173 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 2175 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 2176 Robustness to Blind In-Window Attacks", RFC 5961, 2177 August 2010. 2179 [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, 2180 January 2011. 2182 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2183 Protocol Port Randomization", BCP 156, RFC 6056, 2184 January 2011. 2186 [RFC6069] Zimmermann, A. and A. Hannemann, "Making TCP More Robust 2187 to Long Connectivity Disruptions (TCP-LCD)", RFC 6069, 2188 December 2010. 2190 [RFC6077] Papadimitriou, D., Welzl, M., Scharf, M., and B. Briscoe, 2191 "Open Research Issues in Internet Congestion Control", 2192 RFC 6077, February 2011. 2194 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 2195 TCP Urgent Mechanism", RFC 6093, January 2011. 2197 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 2198 Multipath Operation with Multiple Addresses", RFC 6181, 2199 March 2011. 2201 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 2202 Iyengar, "Architectural Guidelines for Multipath TCP 2203 Development", RFC 6182, March 2011. 2205 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 2206 Timestamps", BCP 159, RFC 6191, April 2011. 2208 [RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC 2209 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, 2210 RFC 1644, and RFC 1693 to Historic Status", RFC 6247, 2211 May 2011. 2213 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 2214 "Computing TCP's Retransmission Timer", RFC 6298, 2215 June 2011. 2217 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2218 Cheshire, "Internet Assigned Numbers Authority (IANA) 2219 Procedures for the Management of the Service Name and 2220 Transport Protocol Port Number Registry", BCP 165, 2221 RFC 6335, August 2011. 2223 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 2224 "Framework for TCP Throughput Testing", RFC 6349, 2225 August 2011. 2227 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 2228 Congestion Control for Multipath Transport Protocols", 2229 RFC 6356, October 2011. 2231 [RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender 2232 Clarification for Persist Condition", RFC 6429, 2233 December 2011. 2235 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 2236 Number Attacks", RFC 6528, February 2012. 2238 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 2239 NewReno Modification to TCP's Fast Recovery Algorithm", 2240 RFC 6582, April 2012. 2242 [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", 2243 RFC 6633, May 2012. 2245 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 2246 and Y. Nishida, "A Conservative Loss Recovery Algorithm 2247 Based on Selective Acknowledgment (SACK) for TCP", 2248 RFC 6675, August 2012. 2250 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2251 RFC 6691, July 2012. 2253 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2254 "TCP Extensions for Multipath Operation with Multiple 2255 Addresses", RFC 6824, January 2013. 2257 [RFC6846] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 2258 "RObust Header Compression (ROHC): A Profile for TCP/IP 2259 (ROHC-TCP)", RFC 6846, January 2013. 2261 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 2262 Interface Considerations", RFC 6897, March 2013. 2264 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 2265 "Increasing TCP's Initial Window", RFC 6928, April 2013. 2267 [RFC6937] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional 2268 Rate Reduction for TCP", RFC 6937, May 2013. 2270 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 2271 RFC 6994, August 2013. 2273 12.2. Informative References 2275 [CK73] Cerf, V. and R. Kahn, "Towards Protocols for Internetwork 2276 Communication", IFIP/TC6.1, NIC 18764, INWG 39, 2277 September 1973. 2279 [Errata] "RFC Editor - RFC Errata", 2280 . 2282 [I-D.leith-tcp-htcp] 2283 Leith, D., "H-TCP: TCP Congestion Control for High 2284 Bandwidth-Delay Product Paths", draft-leith-tcp-htcp-06 2285 (work in progress), April 2008. 2287 [I-D.rhee-tcpm-cubic] 2288 Rhee, I., Xu, L., and S. Ha, "CUBIC for Fast Long-Distance 2289 Networks", draft-rhee-tcpm-cubic-02 (work in progress), 2290 August 2008. 2292 [I-D.sridharan-tcpm-ctcp] 2293 Sridharan, M., Tan, K., Bansal, D., and D. Thaler, 2294 "Compound TCP: A New TCP Congestion Control for High-Speed 2295 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 2296 (work in progress), November 2008. 2298 [JK92] Jacobson, V. and M. Karels, "Congestion Avoidance and 2299 Control", This paper is a revised version of [Jac88], that 2300 includes an additional appendix. This paper has not been 2301 traditionally published, but is currently available at 2302 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992. 2304 [Jac88] Jacobson, V., "Congestion Avoidance and Control", ACM 2305 SIGCOMM 1988 Proceedings, in ACM Computer Communication 2306 Review, 18 (4), pp. 314-329, August 1988. 2308 [KP87] Karn, P. and C. Partridge, "Round Trip Time Estimation", 2309 ACM SIGCOMM 1987 Proceedings, in ACM Computer 2310 Communication Review, 17 (5), pp. 2-7, August 1987. 2312 [MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring the 2313 Evolution of Transport Protocols in the Internet", ACM 2314 Computer Communication Review, 35 (2), April 2005. 2316 [MM96] Mathis, M. and J. Mahdavi, "Forward Acknowledgement: 2317 Refining TCP Congestion Control", ACM SIGCOMM 1996 2318 Proceedings, in ACM Computer Communication Review 26 (4), 2319 pp. 281-292, October 1996. 2321 [RFC1016] Prue, W. and J. Postel, "Something a host could do with 2322 source quench: The Source Quench Introduced Delay 2323 (SQuID)", RFC 1016, July 1987. 2325 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2326 3", BCP 9, RFC 2026, October 1996. 2328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2329 Requirement Levels", BCP 14, RFC 2119, March 1997. 2331 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2332 "Definition of the Differentiated Services Field (DS 2333 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2334 December 1998. 2336 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2337 Conrad, "Stream Control Transmission Protocol (SCTP) 2338 Partial Reliability Extension", RFC 3758, May 2004. 2340 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2341 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 2343 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2344 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 2345 Congestion Control", RFC 4341, March 2006. 2347 [RFC6115] Li, T., "Recommendation for a Routing Architecture", 2348 RFC 6115, February 2011. 2350 [SCWA99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, 2351 "TCP Congestion Control with a Misbehaving Receiver", ACM 2352 Computer Communication Review, 29 (5), pp. 71-78, 2353 October 1999. 2355 Authors' Addresses 2357 Martin Duke 2358 F5 Networks 2359 401 Elliott Ave W 2360 Seattle, WA 98119 2362 Phone: 206-272-7537 2363 Email: m.duke@f5.com 2364 Robert Braden 2365 USC Information Sciences Institute 2366 Marina del Rey, CA 90292-6695 2368 Phone: 310-448-9173 2369 Email: braden@isi.edu 2371 Wesley M. Eddy 2372 MTI Systems 2373 MS 500-ASRC; 21000 Brookpark Rd 2374 Cleveland, OH 44135 2376 Phone: 216-433-6682 2377 Email: wes@mti-systems.com 2379 Ethan Blanton 2381 Email: elb@psg.com 2383 Alexander Zimmermann 2384 NetApp, Inc. 2385 Sonnenallee 1 2386 Kirchheim 85551 2387 Germany 2389 Phone: +49 89 900594712 2390 Email: alexander.zimmermann@netapp.com