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