idnits 2.17.00 (12 Aug 2021) /tmp/idnits3342/draft-ietf-tcpm-tcp-rfc4614bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 12, 2014) is 2832 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2780' is defined on line 1993, but no explicit reference was found in the text == Outdated reference: draft-ietf-tcpm-1323bis has been published as RFC 7323 == Outdated reference: draft-ietf-tcpm-fastopen has been published as RFC 7413 ** 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 813 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 816 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 879 (Obsoleted by RFC 7805) ** 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 6013 (Obsoleted by RFC 7805) ** Obsolete normative reference: RFC 6824 (Obsoleted by RFC 8684) Summary: 22 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCP Maintenance and Minor Extensions M. Duke 3 (TCPM) WG F5 4 Internet-Draft R. Braden 5 Obsoletes: 4614 (if approved) ISI 6 Intended status: Informational W. Eddy 7 Expires: February 13, 2015 MTI Systems 8 E. Blanton 10 A. Zimmermann 11 NetApp, Inc. 12 August 12, 2014 14 A Roadmap for Transmission Control Protocol (TCP) Specification 15 Documents 16 draft-ietf-tcpm-tcp-rfc4614bis-08 18 Abstract 20 This document contains a "roadmap" to the Requests for Comments (RFC) 21 documents relating to the Internet's Transmission Control Protocol 22 (TCP). This roadmap provides a brief summary of the documents 23 defining TCP and various TCP extensions that have accumulated in the 24 RFC series. This serves as a guide and quick reference for both TCP 25 implementers and other parties who desire information contained in 26 the TCP-related RFCs. 28 This document obsoletes RFC 4614. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 13, 2015. 47 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Core Functionality . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Strongly Encouraged Enhancements . . . . . . . . . . . . . . . 8 66 3.1. Fundamental Changes . . . . . . . . . . . . . . . . . . . 8 67 3.2. Congestion Control Extensions . . . . . . . . . . . . . . 9 68 3.3. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 11 69 3.4. Detection and Prevention of Spurious Retransmissions . . . 12 70 3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . . 13 71 3.6. Header Compression . . . . . . . . . . . . . . . . . . . . 14 72 3.7. Defending Spoofing and Flooding Attacks . . . . . . . . . 15 73 4. Experimental Extensions . . . . . . . . . . . . . . . . . . . 17 74 4.1. Architectural Guidelines . . . . . . . . . . . . . . . . . 17 75 4.2. Fundamental Changes . . . . . . . . . . . . . . . . . . . 18 76 4.3. Congestion Control Extensions . . . . . . . . . . . . . . 18 77 4.4. Loss Recovery Extensions . . . . . . . . . . . . . . . . . 20 78 4.5. Detection and Prevention of Spurious Retransmissions . . . 20 79 4.6. TCP Timeouts . . . . . . . . . . . . . . . . . . . . . . . 21 80 4.7. Multipath TCP . . . . . . . . . . . . . . . . . . . . . . 21 81 5. TCP Parameters at IANA . . . . . . . . . . . . . . . . . . . . 22 82 6. Historic and Undeployed Extensions . . . . . . . . . . . . . . 23 83 7. Support Documents . . . . . . . . . . . . . . . . . . . . . . 26 84 7.1. Foundational Works . . . . . . . . . . . . . . . . . . . . 26 85 7.2. Architectural Guidelines . . . . . . . . . . . . . . . . . 28 86 7.3. Difficult Network Environments . . . . . . . . . . . . . . 29 87 7.4. Guidance for Developing, Analyzing, and Evaluating TCP . . 32 88 7.5. Implementation Advice . . . . . . . . . . . . . . . . . . 33 89 7.6. Tools and Tutorials . . . . . . . . . . . . . . . . . . . 35 90 7.7. MIB Modules . . . . . . . . . . . . . . . . . . . . . . . 36 91 7.8. Case Studies . . . . . . . . . . . . . . . . . . . . . . . 37 92 8. Undocumented TCP Features . . . . . . . . . . . . . . . . . . 38 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 40 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 95 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 40 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 50 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51 101 1. Introduction 103 A correct and efficient implementation of the Transmission Control 104 Protocol (TCP) is a critical part of the software of most Internet 105 hosts. As TCP has evolved over the years, many distinct documents 106 have become part of the accepted standard for TCP. At the same time, 107 a large number of experimental modifications to TCP have also been 108 published in the RFC series, along with informational notes, case 109 studies, and other advice. 111 As an introduction to newcomers and an attempt to organize the 112 plethora of information for old hands, this document contains a 113 "roadmap" to the TCP-related RFCs. It provides a brief summary of 114 the RFC documents that define TCP. This should provide guidance to 115 implementers on the relevance and significance of the standards-track 116 extensions, informational notes, and best current practices that 117 relate to TCP. 119 This document is not an update of RFC 1122 [RFC1122] and is not a 120 rigorous standard for what needs to be implemented in TCP. This 121 document is merely an informational roadmap that captures, organizes, 122 and summarizes most of the RFC documents that a TCP implementer, 123 experimenter, or student should be aware of. Particular comments or 124 broad categorizations that this document makes about individual 125 mechanisms and behaviors are not to be taken as definitive, nor 126 should the content of this document alone influence implementation 127 decisions. 129 This roadmap includes a brief description of the contents of each 130 TCP-related RFC. In some cases, we simply supply the abstract or a 131 key summary sentence from the text as a terse description. In 132 addition, a letter code after an RFC number indicates its category in 133 the RFC series (see BCP 9 [RFC2026] for explanation of these 134 categories): 136 S - Standards Track (Proposed Standard, Draft Standard, or 137 Internet Standard) 139 E - Experimental 141 I - Informational 143 H - Historic 145 B - Best Current Practice 147 U - Unknown (not formally defined) 149 Note that the category of an RFC does not necessarily reflect its 150 current relevance. For instance, RFC 5681 [RFC5681] is considered 151 part of the required core functionality of TCP, although the RFC is 152 only a Draft Standard. Similarly, some Informational RFCs contain 153 significant technical proposals for changing TCP. 155 Finally, if an error in the technical content has been found after 156 publication of an RFC, this fact is indicated by the term "(Errata)" 157 in the headline of the RFC's description. The contents of the errata 158 can be found at the RFC editor home page [Errata]. 160 This roadmap is divided into three main sections. Section 2 lists 161 the RFCs that describe absolutely required TCP behaviors for proper 162 functioning and interoperability. Further RFCs that describe 163 strongly encouraged, but non-essential, behaviors are listed in 164 Section 3. Experimental extensions that are not yet standard 165 practices, but that potentially could be in the future, are described 166 in Section 4. 168 The reader will probably notice that these three sections are broadly 169 equivalent to MUST/SHOULD/MAY specifications (per RFC 2119 170 [RFC2119]), and although the authors support this intuition, this 171 document is merely descriptive; it does not represent a binding 172 standards-track position. Individual implementers still need to 173 examine the standards documents themselves to evaluate specific 174 requirement levels. 176 Section 5 describes both the procedures that the Internet Assigned 177 Numbers Authority (IANA) uses and an RFC author should follow when 178 new TCP parameters are requested and finally assigned. 180 A small number of older experimental extensions that have not been 181 widely implemented, deployed, and used are noted in Section 6. Many 182 other supporting documents that are relevant to the development, 183 implementation, and deployment of TCP are described in Section 7. 185 A small number of fairly ubiquitous important implementation 186 practices that are not currently documented in the RFC series are 187 listed in Section 8. 189 Within each section, RFCs are listed in the chronological order of 190 their publication dates. 192 2. Core Functionality 194 A small number of documents compose the core specification of TCP. 195 These define the required core functionalities of TCP's header 196 parsing, state machine, congestion control, and retransmission 197 timeout computation. These base specifications must be correctly 198 followed for interoperability. 200 RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981) 201 (Errata) 203 This is the fundamental TCP specification document [RFC0793]. 204 Written by Jon Postel as part of the Internet protocol suite's 205 core, it describes the TCP packet format, the TCP state machine 206 and event processing, and TCP's semantics for data transmission, 207 reliability, flow control, multiplexing, and acknowledgment. 209 Section 3.6 of RFC 793, describing TCP's handling of the IP 210 precedence and security compartment, is mostly irrelevant today. 211 RFC 2873 (see Section 2) changed the IP precedence handling, and 212 the security compartment portion of the API is no longer 213 implemented or used. In addition, RFC 793 did not describe any 214 congestion control mechanism. Otherwise, however, the majority of 215 this document still accurately describes modern TCPs. RFC 793 is 216 the last of a series of developmental TCP specifications, starting 217 in the Internet Experimental Notes (IENs) and continuing in the 218 RFC series. 220 RFC 1122 S: "Requirements for Internet Hosts - Communication Layers" 221 (October 1989) 223 This document [RFC1122] updates and clarifies RFC 793 (see 224 Section 2), fixing some specification bugs and oversights. It 225 also explains some features such as keep-alives and Karn's and 226 Jacobson's RTO estimation algorithms [KP87][Jac88][JK92]. ICMP 227 interactions are mentioned, and some tips are given for efficient 228 implementation. RFC 1122 is an Applicability Statement, listing 229 the various features that MUST, SHOULD, MAY, SHOULD NOT, and MUST 230 NOT be present in standards-conforming TCP implementations. 231 Unlike a purely informational "roadmap", this Applicability 232 Statement is a standards document and gives formal rules for 233 implementation. 235 RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification" 236 (December 1998) (Errata) 238 This document [RFC2460] is of relevance to TCP because it defines 239 how the pseudo-header for TCP's checksum computation is derived 240 when 128-bit IPv6 addresses are used instead of 32-bit IPv4 241 addresses. Additionally, RFC 2675 (see Section 3.1) describes TCP 242 changes required to support IPv6 jumbograms. 244 RFC 2873 S: "TCP Processing of the IPv4 Precedence Field" (June 2000) 245 (Errata) 247 This document [RFC2873] removes from the TCP specification all 248 processing of the precedence bits of the TOS byte of the IP 249 header. This resolves a conflict over the use of these bits 250 between RFC 793 Section 2 and Differentiated Services [RFC2474]. 252 RFC 5681 S: "TCP Congestion Control" (August 2009) 254 Although RFC 793 (see Section 2) did not contain any congestion 255 control mechanisms, today congestion control is a required 256 component of TCP implementations. This document [RFC5681] defines 257 congestion avoidance and control mechanism for TCP, based on Van 258 Jacobson's 1988 SIGCOMM paper [Jac88]. 260 A number of behaviors that together constitute what the community 261 refers to as "Reno TCP" is described in RFC 5681. The name "Reno" 262 comes from the Net/2 release of the 4.3 BSD operating system. 263 This is generally regarded as the least common denominator among 264 TCP flavors currently found running on Internet hosts. Reno TCP 265 includes the congestion control features of slow start, congestion 266 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. Strongly 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 acceptance 328 of forged segments and flooding attacks. 330 3.1. Fundamental Changes 332 RFCs 2675 and 7323 represent fundamental changes to TCP by redefining 333 how parts of the basic TCP header and options are interpreted. RFC 334 7323 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 7323 S: "TCP Extensions for High Performance" (July 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 1323 374 are the conceptual precursors of RFC 7323. 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 these 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. This change improves the performance of 415 TCP in situations where is no one-to-one relationship between data 416 segments and acknowledgments (e.g. delayed ACKs or ACK loss) and 417 closes a security hole TCP receivers can use to induce the sender 418 into increasing the sending rate too rapidly (ACK-division 419 [SCWA99][RFC3449]). ABC is recommended by RFC 5681 (see 420 Section 2). 422 RFC 6633 S: "Deprecation of ICMP Source Quench Messages" (May 2012) 424 This document [RFC6633] formally deprecates the use of ICMP Source 425 Quench messages by transport protocols and recommends against the 426 implementation of [RFC1016]. 428 3.3. Loss Recovery Extensions 430 For the typical implementation of the TCP fast recovery algorithm 431 described in RFC 5681 (see Section 2), a TCP sender only retransmits 432 a segment after a retransmit timeout has occurred, or after three 433 duplicate ACKs have arrived triggering the fast retransmit. A single 434 RTO might result in the retransmission of several segments, while the 435 fast retransmit algorithm in RFC 5681 leads only to a single 436 retransmission. Hence, multiple losses from a single window of data 437 can lead to a performance degradation. Documents listed in this 438 section aim to improve the overall performance of TCP's standard loss 439 recovery algorithms. In particular, some of them allow TCP senders 440 to recover more effectively when multiple segments are lost from a 441 single flight of data. 443 RFC 2018 S: "TCP Selective Acknowledgment Options" (October 1996) 444 (Errata) 446 When more than one packet is lost during one round trip time TCP 447 may experience poor performance since a TCP sender can only learn 448 about a single lost packet per round trip time from cumulative 449 acknowledgments. This document [RFC2018] defines the basic 450 selective acknowledgment (SACK) mechanism for TCP, which can help 451 to overcome these limitations. The receiving TCP returns SACK 452 blocks to inform the sender which data has been received. The 453 sender can then retransmit only the missing data segments. 455 RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit" 456 (January 2001) 458 Abstract: "This document proposes Limited Transmit, a new 459 Transmission Control Protocol (TCP) mechanism that can be used to 460 more effectively recover lost segments when a connection's 461 congestion window is small, or when a large number of segments are 462 lost in a single transmission window." [RFC3042] Tests from 2004 463 showed that Limited Transmit was deployed in roughly one third of 464 the web servers tested [MAF04]. Limited Transmit is recommended 465 by RFC 5681 (see Section 2). 467 RFC 6582 S: "The NewReno Modification to TCP's Fast Recovery 468 Algorithm" (April 2012) 470 This document [RFC6582] specifies a modification to the standard 471 Reno fast recovery algorithm, whereby a TCP sender can use partial 472 acknowledgments to make inferences determining the next segment to 473 send in situations where SACK would be helpful but isn't 474 available. Although it is only a slight modification, the NewReno 475 behavior can make a significant difference in performance when 476 multiple segments are lost from a single window of data. 478 RFC 2582 and RFC 3782 are the conceptual precursors of RFC 6582. 479 The main change in RFC 3782 relative to RFC 2582 was to specify 480 the Careful variant of NewReno's Fast Retransmit and Fast Recovery 481 algorithms and advance those two algorithms from Experimental to 482 Standards Track status. The main change in RFC 6582 relative to 483 RFC 3782 was to solve a performance degradation that could occur 484 if FlightSize on Full ACK reception is zero. 486 RFC 6675 S: "A Conservative Loss Recovery Algorithm Based on 487 Selective Acknowledgment (SACK) for TCP" (August 2012) 489 This document [RFC6675] describes a conservative loss recovery 490 algorithm for TCP that is based on the use of the selective 491 acknowledgment (SACK) TCP option [RFC2018] (see Section 3.3). The 492 algorithm conforms to the spirit of the congestion control 493 specification in RFC 5681 (see Section 2), but allows TCP senders 494 to recover more effectively when multiple segments are lost from a 495 single flight of data. 497 RFC 6675 is a revision of RFC 3517 to address several situations 498 that are not handled explicitly before. In particular 499 (a) it improves the loss detection in the event that the sender 500 has outstanding segments that are smaller than SMSS. 501 (b) it modifies the definition of a "duplicate acknowledgment" to 502 utilize the SACK information in detecting loss. 503 (c) it maintains the ACK clock under certain circumstances 504 involving loss at the end of the window. 506 3.4. Detection and Prevention of Spurious Retransmissions 508 Spurious retransmission timeouts are harmful to TCP performance and 509 multiple algorithms have been defined for detecting when spurious 510 retransmissions have occurred, and then responding differently in 511 order to recover performance. The IETF defined multiple algorithms 512 because there are tradeoffs in whether or not certain TCP options 513 need to be implemented, and concerns about IPR status. The Standards 514 Track documents in this section are closely related to the 515 Experimental documents in Section 4.5 also addressing this topic. 517 RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK) 518 Option for TCP" (July 2000) 520 This document [RFC2883] extends RFC 2018 (see Section 3.3). It 521 enables use of the SACK option to acknowledge duplicate packets. 522 With this extension, called DSACK, the sender is able to infer the 523 order of packets received at the receiver, and therefore to infer 524 when it has unnecessarily retransmitted a packet. A TCP sender 525 could then use this information to detect spurious retransmissions 526 (see [RFC3708]. 528 RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005) 530 This document [RFC4015] describes the response portion of the 531 Eifel algorithm, which can be used in conjunction with one of 532 several methods of detecting when loss recovery has been 533 spuriously entered, such as the Eifel detection algorithm in RFC 534 3522 (see Section 4.5), the algorithm in RFC 3708 (see 535 Section 4.5), or F-RTO in RFC 5682 (see Section 3.4). 537 Abstract: "Based on an appropriate detection algorithm, the Eifel 538 response algorithm provides a way for a TCP sender to respond to a 539 detected spurious timeout. It adapts the retransmission timer to 540 avoid further spurious timeouts, and can avoid - depending on the 541 detection algorithm - the often unnecessary go-back-N retransmits 542 that would otherwise be sent. In addition, the Eifel response 543 algorithm restores the congestion control state in such a way that 544 packet bursts are avoided." 546 RFC 5682 S: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 547 Spurious Retransmission Timeouts with TCP" (September 2009) 549 The F-RTO detection algorithm [RFC5682], originally described in 550 RFC 4138, provides an option for inferring spurious retransmission 551 timeouts. Unlike some similar detection methods (e.g. RFC 3522 552 in Section 4.5 and RFC 3708 in Section 4.5), F-RTO does not rely 553 on the use of any TCP options. The basic idea is to send 554 previously unsent data after the first retransmission after a RTO. 555 If the ACKs advance the window, the RTO may be declared spurious. 557 3.5. Path MTU Discovery 559 The MTUs supported by different links and tunnels within the Internet 560 can vary widely. Fragmentation of packets larger than the supported 561 MTU on a hop is undesirable. As TCP is the segmentation layer for 562 dividing an application's bytestream into IP packet payloads, TCP 563 implementations generally include Path MTU Discovery (PMTUD) 564 mechanisms in order to maximize the size of segments they send, 565 without causing fragmentation within the network. Some algorithms 566 may utilize signaling from routers on the path that the MTU has been 567 exceeded. 569 RFC 1191 S: "Path MTU Discovery" (November 1990) 571 Abstract: "This memo describes a technique for dynamically 572 discovering the MTU of an arbitrary Internet path. It specifies a 573 small change to the way routers generate one type of ICMP message. 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 either experimental and may become 715 proposed standards in the future or are proposed standard (or 716 informational), but can considered as experimental due to lack of 717 wide deployment. At least part of the reason that they are still 718 experimental is to gain more wide-scale experience with them before a 719 standards track decision is made. 721 If the experimental RFC is a proposal for a new protocol capability 722 or service, i.e., it requires a new TCP option code point, the 723 implementation and experimentation should follow [RFC6994] (see 724 Section 5), which describes how the experimental TCP option code 725 points can concurrently support multiple TCP extensions. 727 By their publication as experimental RFCs, it is hoped that the 728 community of TCP researchers will analyze and test the contents of 729 these RFCs. Although experimentation is encouraged, there is not yet 730 formal consensus that these are fully logical and safe behaviors. 731 Wide-scale deployment of implementations that use these features 732 should be well thought-out in terms of consequences. 734 4.1. Architectural Guidelines 736 As multiple flows may share the same paths, sections of paths, or 737 other resources, the TCP implementation may benefit from sharing 738 information across TCP connections or other flows. Some Experimental 739 proposals have been documented and some implementations have included 740 the concepts. 742 RFC 2140 I: "TCP Control Block Interdependence" (April 1997) 744 This document [RFC2140] suggests how TCP connections between the 745 same endpoints might share information, such as their congestion 746 control state. To some degree, this is done in practice by a few 747 operating systems; for example, Linux currently has a destination 748 cache. Although this RFC is technically informational, the 749 concepts it describes are in experimental use, so we include it in 750 this section. 752 RFC 3124 S: "The Congestion Manager" (June 2001) 754 This document [RFC3124], the Congestion Manager, is a related 755 proposal to RFC 2140 (see Section 4.1). The idea behind the 756 Congestion Manager, moving congestion control outside of 757 individual TCP connections, represents a modification to the core 758 of TCP, which supports sharing information among TCP connections. 759 Although a Proposed Standard, some pieces of the Congestion 760 Manager support architecture have not been specified yet, and it 761 has not achieved use or implementation beyond experimental stacks, 762 so it is not listed among the standard TCP enhancements in this 763 roadmap. 765 4.2. Fundamental Changes 767 Like the standard documents listed in Section 3.1, there also exist 768 new Experimental RFCs that specify fundamental changes to TCP. At 769 the time of writing, the only example so far is TCP Fast Open that 770 deviates from the standard TCP semantics of [RFC0793]. 772 RFC XXX E: "TCP Fast Open" (XXX 2014) 774 This document [I-D.ietf-tcpm-fastopen] describes TCP Fast Open 775 that allows data to be carried in the SYN and SYN-ACK packets and 776 consumed by the receiver during the initial connection handshake. 777 It saves up to one RTT compared to the standard TCP, which 778 requires a three-way handshake to complete before data can be 779 exchanged. 781 4.3. Congestion Control Extensions 783 TCP congestion control has been an extremely active research area for 784 many years (see RFC 5783, Section 7.6), as it determines the 785 performance of many applications that use TCP. A number of 786 experimental RFCs address issues with flow start-up, overshoot, and 787 steady-state behavior in the basic RFC 5681 (see Section 2) 788 algorithms. In these sub-sections, enhancements to TCP's congestion 789 control are listed. The next sub-section focuses on TCP's loss 790 recovery. 792 RFC 2861 E: "TCP Congestion Window Validation" (June 2000) 794 This document [RFC2861] suggests reducing the congestion window 795 over time when no packets are flowing. This behavior is more 796 aggressive than that specified in RFC 5681 (see Section 2), which 797 says that a TCP sender SHOULD set its congestion window to the 798 initial window after an idle period of an RTO or greater. 800 RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling 801 with Nonces" (June 2003) 803 This document [RFC3540] describes an optional addition to ECN that 804 protects against accidental or malicious concealment of marked 805 packets from the TCP sender. 807 RFC 3649 E: "HighSpeed TCP for Large Congestion Windows" (December 808 2003) 810 This document [RFC3649] proposes a modification to TCP's 811 congestion control mechanism for use with TCP connections with 812 large congestion windows, to allow TCP to achieve a higher 813 throughput in high-bandwidth environments. 815 RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion 816 Windows" (March 2004) 818 This document [RFC3742] describes a more conservative slow-start 819 behavior to prevent massive packet losses when a connection uses a 820 very large congestion window. 822 RFC 4782 E: "Quick-Start for TCP and IP" (January 2007) (Errata) 824 This document [RFC4782] specifies the optional Quick-Start 825 mechanism for TCP. This mechanism allows connections to use 826 higher sending rates at the beginning of the data transfer or 827 after an idle period, provided that there is significant unused 828 bandwidth along the path, and the sender and all of the routers 829 along the path approve this higher rate. 831 RFC 5562 E: "Adding Explicit Congestion Notification (ECN) Capability 832 to TCP's SYN/ACK Packets" (June 2009) 834 This document [RFC5562] describes an experimental modification to 835 ECN [RFC3168] (see Section 3.2) for the use of ECN in TCP SYN/ACK 836 packets. This would allow to ECN-mark rather than drop the TCP 837 SYN/ACK packet at an ECN-capable router, and to avoid the severe 838 penalty of a retransmission timeout for a connection when the SYN/ 839 ACK packet is dropped. 841 RFC 5690 I: "Adding Acknowledgement Congestion Control to TCP" 842 (February 2010) 844 This document [RFC5690] describes a congestion control mechanism 845 for acknowledgment (ACKs) traffic in TCP. The mechanism is based 846 on the acknowledgment congestion control of the Datagram 847 Congestion Control Protocol's (DCCP's) [RFC4340] Congestion 848 Control Identifier (CCID) 2 [RFC4341]. 850 RFC 6928 E: "Increasing TCP's Initial Window" (April 2013) 852 This document [RFC6928] proposes to increase the TCP initial 853 window from between 2 and 4 segments, as specified in RFC 3390 854 (see Section 3.2), to 10 segments with a fallback to the existing 855 recommendation when performance issues are detected. 857 4.4. Loss Recovery Extensions 859 RFC 5827 E: "Early Retransmit for TCP and SCTP" (April 2010) 861 This document [RFC5827] proposes the "Early Retransmit" mechanism 862 for TCP (and SCTP) that can be used to recover lost segments when 863 a connection's congestion window is small. In certain special 864 circumstances, Early Retransmit reduces the number of duplicate 865 acknowledgments required to trigger fast retransmit to recover 866 segment losses without waiting for a lengthy retransmission 867 timeout. 869 RFC 6069 E: "Making TCP more Robust to Long Connectivity Disruptions 870 (TCP-LCD)" (December 2010) 872 This document [RFC6069] describes how standard ICMP messages can 873 be used to disambiguate true congestion loss from non-congestion 874 loss caused by connectivity disruptions. It proposes a reversion 875 strategy of TCP's retransmission timer that enables a more prompt 876 detection of whether or not the connectivity has been restored. 878 RFC 6937 E: "Proportional Rate Reduction for TCP" (May 2013) 880 This document [RFC6937] describes an experimental Proportional 881 Rate Reduction (PRR) algorithm as an alternative to the widely 882 deployed Fast Recovery algorithm, to improve the accuracy of the 883 amount of data sent by TCP during loss recovery. 885 4.5. Detection and Prevention of Spurious Retransmissions 887 In addition to the Standards Track extensions to deal with spurious 888 retransmissions in Section 3.4, Experimental proposals have also been 889 documented. 891 RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003) 893 The Eifel detection algorithm [RFC3522] allows a TCP sender to 894 detect a posteriori whether it has entered loss recovery 895 unnecessarily by using the TCP timestamp option to solve the ACK 896 ambiguity. 898 RFC 3708 E: "Using TCP Duplicate Selective Acknowledgement (DSACKs) 899 and Stream Control Transmission Protocol (SCTP) Duplicate 900 Transmission Sequence Numbers (TSNs) to Detect Spurious 901 Retransmissions" (February 2004) 903 Abstract: "TCP and Stream Control Transmission Protocol (SCTP) 904 provide notification of duplicate segment receipt through 905 Duplicate Selective Acknowledgement (DSACKs) and Duplicate 906 Transmission Sequence Number (TSN) notification, respectively. 907 This document presents conservative methods of using this 908 information to identify unnecessary retransmissions for various 909 applications." [RFC3708] 911 RFC 4653 E: "Improving the Robustness of TCP to Non-Congestion 912 Events" (August 2008) 914 In the presence of non-congestion events, such as reordering an 915 out-of-order segment does not necessarily indicates a lost segment 916 and congestion. This document [RFC4653] proposes to increase the 917 threshold used to trigger a fast retransmission from the fixed 918 value of three duplicate ACKs to about one congestion window of 919 data in order to disambiguate true segment loss from segment 920 reordering. 922 4.6. TCP Timeouts 924 Besides the well-known retransmission timeout the TCP standard 925 [RFC0793] defines other timeouts. This section lists documents that 926 deal with TCP's various timeouts. 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) 992 From abstract: "This document defines the procedures that the 993 Internet Assigned Numbers Authority (IANA) uses when handling 994 assignment and other requests related to the Service Name and 995 Transport Protocol Port Number registry." [RFC6335] 997 RFC 6994 S: "Shared Use of Experimental TCP Options (August 2013) 999 This document [RFC6994] describes how the experimental TCP option 1000 code points can concurrently support multiple TCP extensions, even 1001 within the same connection. It creates an IANA registry for 1002 extensions to the experimental code points. 1004 6. Historic and Undeployed Extensions 1006 The RFCs listed here define extensions that have thus far failed to 1007 arouse substantial interest from implementers and have never seen 1008 widespread deployment, or were found to be defective for general use. 1009 Most of them are reclassified by [RFC6247] to Historic status. 1011 RFC 721 U: "Out-of-Band Control Signals in a Host-to-Host Protocol" 1012 (September 1976): lack of interest 1014 RFC 721 [RFC0721] addresses the problem of implementing a reliable 1015 out-of-band signal (interrupts) for use in a host-to-host 1016 protocol. The proposal was not included in the final TCP 1017 specification. 1019 RFC 1078 U: "TCP Port Service Multiplexer (TCPMUX)" (November 1988): 1020 lack of interest 1022 This document [RFC1078] proposes a protocol to contact multiple 1023 services on a single well-known TCP port using a service name 1024 instead of a well-known number. 1026 RFC 1106 H: "TCP Big Window and NAK Options" (June 1989): found 1027 defective 1029 This RFC [RFC1106] defined an alternative to the Window Scale 1030 option for using large windows and described the "negative 1031 acknowledgment" or NAK option. There is a comparison of NAK and 1032 SACK methods, and early discussion of TCP over satellite issues. 1033 RFC 1110 (see Section 6) explains some problems with the 1034 approaches described in RFC 1106. The options described in this 1035 document have not been adopted by the larger community, although 1036 NAKs are used in the SCPS-TP adaptation of TCP for satellite and 1037 spacecraft use, developed by the Consultative Committee for Space 1038 Data Systems (CCSDS). 1040 RFC 1110 H: "A Problem with the TCP Big Window Option" (August 1989): 1041 deprecates RFC 1106 1043 Abstract: "The TCP Big Window option discussed in RFC 1106 (see 1044 Section 6) will not work properly in an Internet environment which 1045 has both a high bandwidth * delay product and the possibility of 1046 disordering and duplicating packets. In such networks, the window 1047 size must not be increased without a similar increase in the 1048 sequence number space. Therefore, a different approach to big 1049 windows should be taken in the Internet." [RFC1110] 1051 RFC 1146 H: "TCP Alternate Checksum Options" (March 1990): lack of 1052 interest 1054 This document [RFC1146] defined more robust TCP checksums than the 1055 16-bit ones-complement in use today. A typographical error in RFC 1056 1145 is fixed in RFC 1146; otherwise, the documents are the same. 1058 RFC 1263 I: "TCP Extensions Considered Harmful" (October 1991): lack 1059 of interest 1061 This document [RFC1263] argues against "backwards compatible" TCP 1062 extensions. Specifically mentioned are several TCP enhancements 1063 that have been successful, including timestamps, window scaling, 1064 PAWS, and SACK. RFC 1263 presents an alternative approach called 1065 "protocol evolution", whereby several evolutionary versions of TCP 1066 would exist on hosts. These distinct TCP versions would represent 1067 upgrades to each other and could be header-incompatible. 1068 Interoperability would be provided by having a virtualization 1069 layer select the right TCP version for a particular connection. 1070 This idea did not catch on with the community, while the type of 1071 extensions RFC 1263 specifically targeted as harmful did become 1072 popular. 1074 RFC 1379 H: "Extending TCP for Transactions -- Concepts" (November 1075 1992): found defective 1077 See RFC 1644, Section 6. 1079 RFC 1644 H: "T/TCP -- TCP Extensions for Transactions Functional 1080 Specification" (July 1994): found defective 1082 The inventors of TCP believed that cached connection state could 1083 have been used to eliminate TCP's 3-way handshake, to support two- 1084 packet request/response exchanges. RFC 1379 [RFC1379] (see 1085 Section 6) and RFC 1644 [RFC1644] show that this is far from 1086 simple. Furthermore, T/TCP floundered on the ease of denial-of- 1087 service attacks that can result. One idea pioneered by T/TCP 1088 lives on in RFC 2140 (see Section 4.1), in the sharing of state 1089 across connections. 1091 RFC 1693 H: "An Extension to TCP: Partial Order Service" (November 1092 1994): lack of interest 1094 This document [RFC1693] defines a TCP extension for applications 1095 that do not care about the order in which application-layer 1096 objects are received. Examples are multimedia and database 1097 applications. In practice, these applications either accept the 1098 possible performance loss because of TCP's strict ordering or they 1099 use specialized transport protocols other than TCP, such as PR- 1100 SCTP [RFC3758]. 1102 RFC 1705 I: "Six Virtual Inches to the Left: The Problem with IPng" 1103 (October 1994): lack of interest 1105 To overcome the exhaustion of the IP class B address space, 1106 suggest this document [RFC1705] that a new version of TCP (TCPng) 1107 needs to be developed and deployed. It proposes that a globally 1108 unique address be assigned to Transport layer to uniquely identify 1109 an Internet host without specifying any routing information. 1110 Later work on splitting locator and identifier values is 1111 summarized well in [RFC6115], but no resulting changes to TCP have 1112 occurred. 1114 RFC 6013 E: "TCP Cookie Transactions (TCPCT)" (January 2011): lack of 1115 interest 1117 This document [RFC6013] describes a method to exchange a cookie 1118 (nonce) during the connection establishment to negotiate 1119 elimination of receiver state. These cookies are later used to 1120 inhibit premature closing of connections, and reduce retention of 1121 state after the connection has terminated. 1123 Since the cookie pair is too large to fit with the other TCP 1124 options in the 40 bytes of TCP option space, the document further 1125 describes a method to extent the option space after the connection 1126 establishment. 1128 Although RFC 6013 was published in 2011, the authors of this 1129 document places it in this section of the roadmap document due to 1130 two factors. 1131 (a) The authors are not aware of any wide deployment and use of 1132 RFC 6013. 1134 (b) RFC 6013 uses experimental TCP option codepoints, which 1135 prohibits a large-scale deployment. 1137 7. Support Documents 1139 This section contains several classes of documents that do not 1140 necessarily define current protocol behaviors, but that are 1141 nevertheless of interest to TCP implementers. Section 7.1 describes 1142 several foundational RFCs that give modern readers a better 1143 understanding of the principles underlying TCP's behaviors and 1144 development over the years. Section 7.2 contains architectural 1145 guidelines and principles for TCP architects and designers. The 1146 documents listed in Section 7.3 provide advice on using TCP in 1147 various types of network situations that pose challenges above those 1148 of typical wired links. Guidance for developing, analyzing, and 1149 evaluating TCP is given in Section 7.4. Some implementation notes 1150 and implementation advice can be found in Section 7.5. RFCs that 1151 describe tools for testing and debugging TCP implementations or that 1152 contain high-level tutorials on the protocol are listed Section 7.6. 1153 The TCP Management Information Bases are described in Section 7.7, 1154 and Section 7.8 lists a number of case studies that have explored TCP 1155 performance. 1157 7.1. Foundational Works 1159 The documents listed in this section contain information that is 1160 largely duplicated by the standards documents previously discussed. 1161 However, some of them contain a greater depth of problem statement 1162 explanation or other context. Particularly, RFCs 813 - 817 (known as 1163 the "Dave Clark Five") describe some early problems and solutions 1164 (RFC 815 only describes the reassembly of IP fragments and is not 1165 included in this TCP roadmap). 1167 RFC 675 U: "Specification of Internet Transmission Control Program" 1168 (December 1974) 1170 This document [RFC0675] is a very early precursor of the 1171 fundamental RFC 793 (see Section 2), which already contained the 1172 three-way handshake in its final form and the concept of sliding 1173 windows for reliable data transmission. Apart from that the 1174 segment layout is totally different and the specified API differs 1175 from the latter RFC 793 (see Section 2). 1177 RFC 761 U: "DoD standard Transmission Control Protocol" (January 1178 1980) 1180 This document [RFC0761] is the immediate precursor of RFC 793 (see 1181 Section 2). The header format, the connection establishment 1182 including the different connection states, and the overall API 1183 correspond mostly to the final Standard RFC 793 (see Section 2). 1185 RFC 813 U: "Window and Acknowledgement Strategy in TCP" (July 1982) 1187 This document [RFC0813] contains an early discussion of Silly 1188 Window Syndrome and its avoidance and motivates and describes the 1189 use of delayed acknowledgments. 1191 RFC 814 U: "Name, Addresses, Ports, and Routes" (July 1982) 1193 Suggestions and guidance for the design of tables and algorithms 1194 to keep track of various identifiers within a TCP/IP 1195 implementation are provided by this document [RFC0814]. 1197 RFC 816 U: "Fault Isolation and Recovery" (July 1982) 1199 In this document [RFC0816], TCP's response to indications of 1200 network error conditions such as timeouts or received ICMP 1201 messages is discussed. 1203 RFC 817 U: "Modularity and Efficiency in Protocol Implementation" 1204 (July 1982) 1206 This document [RFC0817] contains implementation suggestions that 1207 are general and not TCP specific. However, they have been used to 1208 develop TCP implementations and describe some performance 1209 implications of the interactions between various layers in the 1210 Internet stack. 1212 RFC 872 U: "TCP-on-a-LAN" (September 1982) 1214 Conclusion: "The sometimes-expressed fear that using TCP on a 1215 local net is a bad idea is unfounded." [RFC0872] 1217 RFC 896 U: "Congestion Control in IP/TCP Internetworks" (January 1218 1984) 1220 This document [RFC0896] contains some early experiences with 1221 congestion collapse and some initial thoughts on how to avoid it 1222 using congestion control in TCP. Furthermore, it defined an 1223 algorithm for efficient transmission of small packets that is 1224 today known as the Nagle Algorithm. 1226 RFC 964 U: "Some Problems with the Specification of the Military 1227 Standard Transmission Control Protocol" (November 1985) 1229 This document [RFC0964] points out several specification bugs in 1230 the US Military's MIL-STD-1778 document, which was intended as a 1231 successor to RFC 793 (see Section 2). This serves to remind us of 1232 the difficulty in specification writing (even when we work from 1233 existing documents!). 1235 7.2. Architectural Guidelines 1237 Some documents in this section contain architectural guidance and 1238 concerns, while others specify TCP- and congestion-control-related 1239 mechanisms that are broadly applicable and have impacts on TCP's 1240 congestion control techniques. Some of these documents are direct 1241 products of the Internet Architecture Board (IAB), giving their 1242 guidance on specific aspects of congestion control in the Internet. 1244 RFC 1958 I: "Architectural Principles of the Internet" (June 1996) 1246 This document [RFC1958] describes the underlying principles of the 1247 Internet architecture. It provides guidelines for network systems 1248 designs that have proven useful in the evolution of the Internet. 1250 RFC 2914 B: "Congestion Control Principles" (September 2000) 1252 This document [RFC2914] motivates the use of end-to-end congestion 1253 control for preventing congestion collapse and providing fairness 1254 to TCP. Later work on TCP has included several more aggressive 1255 mechanisms than Reno TCP includes, and RFC 5033 (see Section 7.4) 1256 provides additional guidance on use of such algorithms. The 1257 fundamental architectural discussion in RFC 2914 remains valid, 1258 regarding the standards process role in defining protocol aspects 1259 that are critical to performance and avoiding congestion collapse 1260 scenarios. 1262 RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August 1263 2002) 1265 This document [RFC3360] is a plea that firewall vendors not send 1266 gratuitous TCP RST (Reset) packets when unassigned TCP header bits 1267 are used. This practice prevents desirable extension and 1268 evolution of the protocol and thus is potentially harmful to the 1269 future of the Internet. 1271 RFC 3439 I: "Some Internet Architectural Guidelines and Philosophy" 1272 (December 2002) 1274 This document [RFC3439] updates RFC 1958 (see Section 7.2) by 1275 outlining some philosophical guidelines for architects and 1276 designers of Internet backbone networks. The document describes 1277 the Simplicity Principle, which states that complexity is the 1278 primary impediment to efficient scaling. 1280 RFC 4774 B: "Specifying Alternate Semantics for the Explicit 1281 Congestion Notification (ECN) Field" (November 2006) 1283 This document [RFC4774] discusses some of the issues in defining 1284 alternate semantics for the ECN field, and specifies requirements 1285 for a safe co-existence with routers that do not understand the 1286 defined alternate semantics. 1288 RFC 6182 I: "Architectural Guidelines for Multipath TCP Development" 1289 (March 2011) 1291 Abstract: "This document outlines architectural guidelines for the 1292 development of a Multipath Transport Protocol, with references to 1293 how these architectural components come together in the 1294 development of a Multipath TCP (MPTCP) (see Section 4.7). This 1295 document lists certain high-level design decisions that provide 1296 foundations for the design of the MPTCP protocol, based upon these 1297 architectural requirements" [RFC6182] 1299 7.3. Difficult Network Environments 1301 As the internetworking field has explored wireless, satellite, 1302 cellular telephone, and other kinds of link-layer technologies, a 1303 large body of work has built up on enhancing TCP performance for such 1304 links. The RFCs listed in this section describe some of these more 1305 challenging network environments and how TCP interacts with them. 1307 RFC 2488 B: "Enhancing TCP Over Satellite Channels using Standard 1308 Mechanisms" (January 1999) 1310 From abstract: "While TCP works over satellite channels there are 1311 several IETF standardized mechanisms that enable TCP to more 1312 effectively utilize the available capacity of the network path. 1313 This document outlines some of these TCP mitigations. At this 1314 time, all mitigations discussed in this document are IETF 1315 standards track mechanisms (or are compliant with IETF 1316 standards)." [RFC2488] 1318 RFC 2757 I: "Long Thin Networks" (January 2000) 1320 Several methods of improving TCP performance over long thin 1321 networks (i.e., networks with low bandwidth and high delay), such 1322 as geosynchronous satellite links, are discussed in this document 1323 [RFC2757]. A particular set of TCP options is developed that 1324 should work well in such environments and be safe to use in the 1325 global Internet. The implications of such environments have been 1326 further discussed in RFC 3150 (see Section 7.3) and RFC 3155 (see 1327 Section 7.3), and these documents should be preferred where there 1328 is overlap between them and RFC 2757 (see Section 7.3). 1330 RFC 2760 I: "Ongoing TCP Research Related to Satellites" (February 1331 2000) 1333 This document [RFC2760] discusses the advantages and disadvantages 1334 of several different experimental means of improving TCP 1335 performance over long-delay or error-prone paths. These include 1336 T/TCP, larger initial windows, byte counting, delayed 1337 acknowledgments, slow start thresholds, NewReno and SACK-based 1338 loss recovery, FACK [MM96], ECN, various corruption-detection 1339 mechanisms, congestion avoidance changes for fairness, use of 1340 multiple parallel flows, pacing, header compression, state 1341 sharing, and ACK congestion control, filtering, and 1342 reconstruction. Although RFC 2488 (see Section 7.3) looks at 1343 standard extensions, this document focuses on more experimental 1344 means of performance enhancement. 1346 RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate Link- 1347 Related Degradations" (June 2001) 1349 From abstract: "This document is a survey of Performance Enhancing 1350 Proxies (PEPs) often employed to improve degraded TCP performance 1351 caused by characteristics of specific link environments, for 1352 example, in satellite, wireless WAN, and wireless LAN 1353 environments. Different types of Performance Enhancing Proxies 1354 are described as well as the mechanisms used to improve 1355 performance." [RFC3135] 1357 RFC 3150 B: "End-to-end Performance Implications of Slow Links" (July 1358 2001) 1360 From abstract: "This document makes performance-related 1361 recommendations for users of network paths that traverse "very low 1362 bit-rate" links....This recommendation may be useful in any 1363 network where hosts can saturate available bandwidth, but the 1364 design space for this recommendation explicitly includes 1365 connections that traverse 56 Kb/second modem links or 4.8 Kb/ 1366 second wireless access links - both of which are widely deployed." 1367 [RFC3150] 1369 RFC 3155 B: "End-to-end Performance Implications of Links with 1370 Errors" (August 2001) 1372 From abstract: "This document discusses the specific TCP 1373 mechanisms that are problematic in environments with high 1374 uncorrected error rates, and discusses what can be done to 1375 mitigate the problems without introducing intermediate devices 1376 into the connection." [RFC3155] 1378 RFC 3366 B: "Advice to link designers on link Automatic Repeat 1379 reQuest (ARQ)" (August 2002) 1381 From abstract: "This document provides advice to the designers of 1382 digital communication equipment and link-layer protocols employing 1383 link-layer Automatic Repeat reQuest (ARQ) techniques. This 1384 document presumes that the designers wish to support Internet 1385 protocols, but may be unfamiliar with the architecture of the 1386 Internet and with the implications of their design choices for the 1387 performance and efficiency of Internet traffic carried over their 1388 links." [RFC3366] 1390 RFC 3449 B: "TCP Performance Implications of Network Path Asymmetry" 1391 (December 2002) 1393 From abstract: "This document describes TCP performance problems 1394 that arise because of asymmetric effects. These problems arise in 1395 several access networks, including bandwidth-asymmetric networks 1396 and packet radio subnetworks, for different underlying reasons. 1397 However, the end result on TCP performance is the same in both 1398 cases: performance often degrades significantly because of 1399 imperfection and variability in the ACK feedback from the receiver 1400 to the sender. 1402 The document details several mitigations to these effects, which 1403 have either been proposed or evaluated in the literature, or are 1404 currently deployed in networks." [RFC3449] 1406 RFC 3481 B: "TCP over Second (2.5G) and Third (3G) Generation 1407 Wireless Networks" (February 2003) 1409 From abstract: "This document describes a profile for optimizing 1410 TCP to adapt so that it handles paths including second (2.5G) and 1411 third (3G) generation wireless networks." [RFC3481] 1413 RFC 3819 B: "Advice for Internet Subnetwork Designers" (July 2004) 1415 This document [RFC3819] describes how TCP performance can be 1416 negatively affected by some particular lower-layer behaviors and 1417 provides guidance in designing lower-layer networks and protocols 1418 to be amicable to TCP. RFC 3366 (see Section 7.3) specifically 1419 focuses on ARQ mechanisms, while RFC 3819 more widely covers 1420 additional aspects of the underlying layers 1422 7.4. Guidance for Developing, Analyzing, and Evaluating TCP 1424 Documents in this section give general guidance for developing, 1425 analyzing, and evaluating TCP. Some of the documents discuss for 1426 example the properties of congestion control protocols that are 1427 "safe" for Internet deployment, as well as how to measure the 1428 properties of congestion control mechanisms and transport protocols. 1430 RFC 5033 B: "Specifying New Congestion Control Algorithms" (August 1431 2007) 1433 This document [RFC5033] considers the evaluation of suggested 1434 congestion control algorithms that differ from the principles 1435 outlined in RFC 2914 (see Section 7.2). It is useful for authors 1436 of such algorithms as well as for IETF members reviewing the 1437 associated documents. 1439 RFC 5166 I: "Metrics for the Evaluation of Congestion Control 1440 Mechanisms" (March 2008) 1442 This document [RFC5166] discusses metrics that needs to be 1443 considered when evaluating new or modified congestion control 1444 mechanisms for the Internet. Among others topics, the document 1445 discusses throughput, delay, loss rates, response times, fairness 1446 and robustness for challenging environments. 1448 RFC 6077 I: "Open Research Issues in Internet Congestion Control" 1449 (January 2011) 1451 This RFC [RFC6077] summarizes the main open problems in the domain 1452 of Internet congestion control. As a good starting point for 1453 newcomers, the document describes several new challenges that are 1454 becoming important as the network grows, as well as some issues 1455 that have been known for many years. 1457 RFC 6181 I: "Threat Analysis for TCP Extensions for Multipath 1458 Operation with Multiple Addresses" (March 2011) 1460 This document [RFC6181] describes a threat analysis for Multipath 1461 TCP (MPTCP) (see Section 4.7). The document discusses several 1462 types of attacks and provides recommendations for MPTCP designers 1463 how to create an MPTCP specification that is as secure as the 1464 current (single-path) TCP. 1466 RFC 6349 I: "Framework for TCP Throughput Testing" (August 2011) 1468 From abstract: "This document describes a practical methodology 1469 for measuring end-to-end TCP throughput in a managed IP network. 1470 The goal is to provide a better indication in regard to user 1471 experience. In this framework, TCP and IP parameters are 1472 specified to optimize TCP throughput." [RFC6349] 1474 7.5. Implementation Advice 1476 RFC 794 U: "PRE-EMPTION" (September 1981) 1478 This document [RFC0794] clarifies that operating systems need to 1479 manage their limited resources, which may include TCP connection 1480 state, and that these decisions can be made with application 1481 input, but they do not need to be part of the TCP protocol 1482 specification itself. 1484 RFC 879 U: "The TCP Maximum Segment Size and Related Topics" 1485 (November 1983) 1487 Abstract: "This memo discusses the TCP Maximum Segment Size Option 1488 and related topics. The purpose is to clarify some aspects of TCP 1489 and its interaction with IP. This memo is a clarification to the 1490 TCP specification, and contains information that may be considered 1491 as 'advice to implementers'." [RFC0879] 1493 RFC 1071 U: "Computing the Internet Checksum" (September 1988) 1494 (Errata) 1496 This document [RFC1071] lists a number of implementation 1497 techniques for efficiently computing the Internet checksum (used 1498 by TCP). 1500 RFC 1624 I: "Computation of the Internet Checksum via Incremental 1501 Update" (May 1994) 1503 Incrementally updating the Internet checksum is useful to routers 1504 in updating IP checksums. Some middleboxes that alter TCP headers 1505 may also be able to update the TCP checksum incrementally. This 1506 document [RFC1624] expands upon the explanation of the incremental 1507 update procedure in RFC 1071 (see Section 7.5). 1509 RFC 1936 I: "Implementing the Internet Checksum in Hardware" (April 1510 1996) 1512 This document [RFC1936] describes the motivation for implementing 1513 the Internet checksum in hardware, rather than in software, and 1514 provides an implementation example. 1516 RFC 2525 I: "Known TCP Implementation Problems" (March 1999) 1518 From abstract: "This memo catalogs a number of known TCP 1519 implementation problems. The goal is to improve conditions in the 1520 existing Internet by enhancing the quality of current TCP/IP 1521 implementations." [RFC2525] 1523 RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000) 1525 From abstract: "This memo catalogs several known Transmission 1526 Control Protocol (TCP) implementation problems dealing with Path 1527 Maximum Transmission Unit Discovery (PMTUD), including the long- 1528 standing black hole problem, stretch acknowledgments (ACKs) due to 1529 confusion between Maximum Segment Size (MSS) and segment size, and 1530 MSS advertisement based on PMTU." [RFC2923] 1532 RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (February 1533 2003) 1535 This document [RFC3493] describes the de facto standard sockets 1536 API for programming with TCP. This API is implemented nearly 1537 ubiquitously in modern operating systems and programming 1538 languages. 1540 RFC 6056 B: "Recommendations for Transport-Protocol Port 1541 Randomization" (December 2010) 1543 This document [RFC6056] describes a number of simple and efficient 1544 methods for the selection of the client port number. It reduces 1545 the possibility of an attacker guessing the correct five-tuple 1546 (Protocol, Source/Destination Address, Source/Destination Port). 1548 RFC 6191 B: "Reducing the TIME-WAIT State Using TCP timestamps" 1549 (April 2011) 1551 This document [RFC6191] describes the usage of the TCP Timestamps 1552 option (RFC 7323, see Section 3.1) to perform heuristics to 1553 determine whether or not to allow the creation of a new 1554 incarnation of a connection that is in the TIME-WAIT state. 1556 RFC 6429 I: "TCP Sender Clarification for Persist Condition" 1557 (December 2011) 1559 This document [RFC6429] clarifies the actions that a TCP can take 1560 on connections that are experiencing the Zero Window Probe (ZWP) 1561 condition. 1563 RFC 6897 I: "Multipath TCP (MPTCP) Application Interface 1564 Considerations" (March 2013) 1566 This document [RFC6897] characterizes the impact that Multipath 1567 TCP (MPTCP) (see Section 4.7) may have on applications. It 1568 further discusses compatibility issues of MPTCP in combination 1569 with non-MPTCP-aware applications. Finally, it describes a basic 1570 API that is a simple extension of TCP's interface for MPTCP-aware 1571 applications. 1573 7.6. Tools and Tutorials 1575 RFC 1180 I: "TCP/IP Tutorial" (January 1991) (Errata) 1577 This document [RFC1180] is an extremely brief overview of the 1578 TCP/IP protocol suite as a whole. It gives some explanation as to 1579 how and where TCP fits in. 1581 RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for 1582 Monitoring and Debugging TCP/IP Internets and Interconnected Devices" 1583 (June 1993) 1585 A few of the tools that this document [RFC1470] describes are 1586 still maintained and in use today; for example, ttcp and tcpdump. 1587 However, many of the tools described do not relate specifically to 1588 TCP and are no longer used or easily available. 1590 RFC 2398 I: "Some Testing Tools for TCP Implementors" (August 1998) 1592 This document [RFC2398] describes a number of TCP packet 1593 generation and analysis tools. Although some of these tools are 1594 no longer readily available or widely used, for the most part they 1595 are still relevant and usable. 1597 RFC 5783 I: "Congestion Control in the RFC Series" (February 2010) 1599 This document [RFC5783] provides an overview of RFCs related to 1600 congestion control that have been published so far. The focus of 1601 the document is on end-host-based congestion control. 1603 7.7. MIB Modules 1605 The first MIB module defined for use with Simple Network Management 1606 Protocol (SNMP) was a single monolithic MIB module, called MIB-I, 1607 defined in RFC 1156. This evolved over time to the MIB-II 1608 specification in RFC 1213, which obsoletes RFC 1156. It then became 1609 apparent that having a single monolithic MIB module was not scalable, 1610 given the number and breadth of MIB data definitions that needed to 1611 be included. Thus, additional MIB modules were defined, and those 1612 parts of MIB-II that needed to evolve were split off. Eventually, 1613 the remaining parts of MIB-II were also split off, the TCP-specific 1614 part being documented in RFC 2012. RFC 2012 was obsoleted by RFC 1615 4022, which is the primary TCP MIB document today. For current TCP 1616 implementers, RFC 4022 should be supported. 1618 RFC 1156 S: "Management Information Base for Network Management of 1619 TCP/IP-based Internets" (May 1990) 1621 This document [RFC1156] describes the required MIB fields for TCP 1622 implementations with minor corrections and no technical changes 1623 from RFC 1066, which it obsoletes. This is the standards track 1624 document for MIB-I. 1626 RFC 1213 S: "Management Information Base for Network Management of 1627 TCP/IP-based Internets: MIB-II" (March 1991) 1629 This document [RFC1213] describes the second version of the MIB in 1630 a monolithic form. It is the immediate successor of RFC 1158, 1631 with minor modifications. It obsoletes the MIB-I, defined in RFC 1632 1156 (see Section 7.7). 1634 RFC 2012 S: "SNMPv2 Management Information Base for the Transmission 1635 Control Protocol using SMIv2" (November 1996) 1637 In an update to RFC 1213 (see Section 7.7), this document 1638 [RFC2012] defines the TCP MIB by splitting out the TCP-specific 1639 portions. It is now obsoleted by RFC 4022 (see Section 7.7). 1641 RFC 2452 S: "IP Version 6 Management Information Base for the 1642 Transmission Control Protocol" (December 1998) 1644 This document [RFC2452] augments RFC 2012 (see Section 7.7) by 1645 adding an IPv6-specific connection table. The rest of RFC 2012 1646 holds for any IP version. RFC 2452 is now obsoleted by RFC 4022 1647 (see Section 7.7). 1649 Although it is a standards track document, RFC 2452 is considered 1650 a historic mistake by the MIB community, as it is based on the 1651 idea of parallel IPv4 and IPv6 structures. Although IPv6 requires 1652 new structures, the community has decided to define a single 1653 generic structure for both IPv4 and IPv6. This will aid in 1654 definition, implementation, and transition between IPv4 and IPv6. 1656 RFC 4022 S: "Management Information Base for the Transmission Control 1657 Protocol (TCP)" (March 2005) 1659 This document [RFC4022] obsoletes RFC 2012 (see Section 7.7) and 1660 RFC 2452 (see Section 7.7) and specifies the current standard for 1661 the TCP MIB that should be deployed. 1663 RFC 4898 S: "TCP Extended Statistics MIB" (May 2007) 1665 This document [RFC4898] describes extended performance statistics 1666 for TCP. They are designed to use TCP's ideal vantage point to 1667 diagnose performance problems in both the network and the 1668 application. 1670 7.8. Case Studies 1672 RFC 700 U: "A Protocol Experiment" (August 1974) 1674 This document [RFC0700] presents a field report about the 1675 deployment of a very early version of TCP, the so-called INWN #39 1676 protocol, which is originally described by Cerf and Kahn in INWG 1677 Note #39 [CK73] to use a PDP-11 line printer via the ARPANET. 1679 RFC 889 U: "Internet Delay Experiments" (December 1983) 1681 This document [RFC0889] is a status report about experiments 1682 concerning the TCP retransmission timeout calculation and also 1683 provides advices for implementers. 1685 RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 1992) 1687 This document [RFC1337] points out a problem with acting on 1688 received reset segments while one is in the TIME-WAIT state. The 1689 main recommendation is that hosts in TIME-WAIT ignore resets. 1690 This recommendation might not currently be widely implemented. 1692 RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size" 1693 (September 1998) 1695 This document [RFC2415] presents results of some simulations using 1696 TCP initial windows greater than 1 segment. The analysis 1697 indicates that user-perceived performance can be improved by 1698 increasing the initial window to 3 segments. 1700 RFC 2416 I: "When TCP Starts Up With Four Packets Into Only Three 1701 Buffers" (September 1998) 1703 This document [RFC2416] uses simulation results to clear up some 1704 concerns about using an initial window of 4 segments when the 1705 network path has less provisioning. 1707 RFC 2884 I: "Performance Evaluation of Explicit Congestion 1708 Notification (ECN) in IP Networks" (July 2000) 1710 This document [RFC2884] describes experimental results that show 1711 some improvements to the performance of both short- and long-lived 1712 connections due to ECN. 1714 8. Undocumented TCP Features 1716 There are a few important implementation tactics for the TCP that 1717 have not yet been described in any RFC. Although this roadmap is 1718 primarily concerned with mapping the TCP RFCs, this section is 1719 included because an implementer needs to be aware of these important 1720 issues. 1722 Header Prediction 1724 Header prediction is a trick to speed up the processing of 1725 segments. Van Jacobson and Mike Karels developed the technique in 1726 the late 1980s. The basic idea is that some processing time can 1727 be saved when most of a segment's fields can be predicted from 1728 previous segments. A good description of this was sent to the 1729 TCP-IP mailing list by Van Jacobson on March 9, 1988: 1731 "Quite a bit of the speedup comes from an algorithm that we ('we' 1732 refers to collaborator Mike Karels and myself) are calling "header 1733 prediction". The idea is that if you're in the middle of a bulk 1734 data transfer and have just seen a packet, you know what the next 1735 packet is going to look like: It will look just like the current 1736 packet with either the sequence number or ack number updated 1737 (depending on whether you're the sender or receiver). Combining 1738 this with the "Use hints" epigram from Butler Lampson's classic 1739 "Epigrams for System Designers", you start to think of the tcp 1740 state (rcv.nxt, snd.una, etc.) as "hints" about what the next 1741 packet should look like. 1743 If you arrange those "hints" so they match the layout of a tcp 1744 packet header, it takes a single 14-byte compare to see if your 1745 prediction is correct (3 longword compares to pick up the send & 1746 ack sequence numbers, header length, flags and window, plus a 1747 short compare on the length). If the prediction is correct, 1748 there's a single test on the length to see if you're the sender or 1749 receiver followed by the appropriate processing. E.g., if the 1750 length is non-zero (you're the receiver), checksum and append the 1751 data to the socket buffer then wake any process that's sleeping on 1752 the buffer. Update rcv.nxt by the length of this packet (this 1753 updates your "prediction" of the next packet). Check if you can 1754 handle another packet the same size as the current one. If not, 1755 set one of the unused flag bits in your header prediction to 1756 guarantee that the prediction will fail on the next packet and 1757 force you to go through full protocol processing. Otherwise, 1758 you're done with this packet. So, the *total* tcp protocol 1759 processing, exclusive of checksumming, is on the order of 6 1760 compares and an add." 1762 Forward Acknowledgement (FACK) 1764 FACK [MM96] includes an alternate algorithm for triggering fast 1765 retransmit [RFC5681], based on the extent of the SACK scoreboard. 1766 Its goal is to trigger fast retransmit as soon as the receiver's 1767 reassembly queue is larger than the duplicate ACK threshold, as 1768 indicated by the difference between the forward most SACK block 1769 edge and SND.UNA. This algorithm quickly and reliably triggers 1770 fast retransmit in the presence of burst losses -- often on the 1771 first SACK following such a loss. Such a threshold-based 1772 algorithm also triggers fast retransmit immediately in the 1773 presence of any reordering with extent greater than the duplicate 1774 ACK threshold. FACK is implemented in Linux and turned on per 1775 default. 1777 Congestion Control for High Rate Flows 1779 In the last decade significant research effort has been put into 1780 experimental TCP congestion control modifications for obtaining 1781 high throughput with reduced startup and recovery times. Only few 1782 RFCs have been published on some of these modifications, including 1783 HighSpeed TCP [RFC3649] (see Section 4.3), Limited Slow-Start 1784 [RFC3742] (see Section 4.3), and Quick-Start [RFC4782] (see 1785 Section 4.3), but high-rate congestion control mechanisms are 1786 still considered an open issue in congestion control research. 1787 Some other schemes have been published as Internet-Drafts, e.g. 1788 CUBIC [I-D.rhee-tcpm-cubic] (the standard TCP congestion control 1789 algorithm in Linux), Compound TCP [I-D.sridharan-tcpm-ctcp], and 1790 H-TCP [I-D.leith-tcp-htcp] or have been discussed a little by the 1791 IETF, but much of the work in this area has not been adopted 1792 within the IETF yet, so the majority of this work is outside the 1793 RFC series and may be discussed in other products of the IRTF 1794 Internet Congestion Control Research Group (ICCRG). 1796 9. Security Considerations 1798 This document introduces no new security considerations. Each RFC 1799 listed in this document attempts to address the security 1800 considerations of the specification it contains. 1802 10. IANA Considerations 1804 This document contains no IANA considerations. 1806 11. Acknowledgments 1808 This document grew out of a discussion on the end2end-interest 1809 mailing list, the public list of the End-to-End Research Group of the 1810 IRTF, and continued development under the IETF's TCP Maintenance and 1811 Minor Extensions (TCPM) working group. We thank Mark Allman, Yuchung 1812 Cheng, Ted Faber, Fairhurst, Sally Floyd, Janardhan Iyengar, Reiner 1813 Ludwig, Pekka Savola, and Joe Touch for their contributions, in 1814 particular. Keith McCloghrie provided some useful notes and 1815 clarification on the various MIB-related RFCs. 1817 12. References 1819 12.1. Normative References 1821 [I-D.ietf-tcpm-1323bis] 1822 Borman, D., Braden, R., Jacobson, V., and R. 1823 Scheffenegger, "TCP Extensions for High Performance", 1824 draft-ietf-tcpm-1323bis-21 (work in progress), April 2014. 1826 [I-D.ietf-tcpm-fastopen] 1827 Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 1828 Fast Open", draft-ietf-tcpm-fastopen-09 (work in 1829 progress), July 2014. 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. 1986 Vaidya, "Long Thin Networks", RFC 2757, January 2000. 1988 [RFC2760] Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D., 1989 Henderson, T., Heidemann, J., Touch, J., Kruse, H., 1990 Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP 1991 Research Related to Satellites", RFC 2760, February 2000. 1993 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1994 Values In the Internet Protocol and Related Headers", 1995 BCP 37, RFC 2780, March 2000. 1997 [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion 1998 Window Validation", RFC 2861, June 2000. 2000 [RFC2873] Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP 2001 Processing of the IPv4 Precedence Field", RFC 2873, 2002 June 2000. 2004 [RFC2883] Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An 2005 Extension to the Selective Acknowledgement (SACK) Option 2006 for TCP", RFC 2883, July 2000. 2008 [RFC2884] Hadi Salim, J. and U. Ahmed, "Performance Evaluation of 2009 Explicit Congestion Notification (ECN) in IP Networks", 2010 RFC 2884, July 2000. 2012 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 2013 RFC 2914, September 2000. 2015 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 2016 RFC 2923, September 2000. 2018 [RFC3042] Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing 2019 TCP's Loss Recovery Using Limited Transmit", RFC 3042, 2020 January 2001. 2022 [RFC3124] Balakrishnan, H. and S. Seshan, "The Congestion Manager", 2023 RFC 3124, June 2001. 2025 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 2026 Shelby, "Performance Enhancing Proxies Intended to 2027 Mitigate Link-Related Degradations", RFC 3135, June 2001. 2029 [RFC3150] Dawkins, S., Montenegro, G., Kojo, M., and V. Magret, 2030 "End-to-end Performance Implications of Slow Links", 2031 BCP 48, RFC 3150, July 2001. 2033 [RFC3155] Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N. 2034 Vaidya, "End-to-end Performance Implications of Links with 2035 Errors", BCP 50, RFC 3155, August 2001. 2037 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2038 of Explicit Congestion Notification (ECN) to IP", 2039 RFC 3168, September 2001. 2041 [RFC3360] Floyd, S., "Inappropriate TCP Resets Considered Harmful", 2042 BCP 60, RFC 3360, August 2002. 2044 [RFC3366] Fairhurst, G. and L. Wood, "Advice to link designers on 2045 link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366, 2046 August 2002. 2048 [RFC3390] Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's 2049 Initial Window", RFC 3390, October 2002. 2051 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 2052 Guidelines and Philosophy", RFC 3439, December 2002. 2054 [RFC3449] Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M. 2055 Sooriyabandara, "TCP Performance Implications of Network 2056 Path Asymmetry", BCP 69, RFC 3449, December 2002. 2058 [RFC3465] Allman, M., "TCP Congestion Control with Appropriate Byte 2059 Counting (ABC)", RFC 3465, February 2003. 2061 [RFC3481] Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and 2062 F. Khafizov, "TCP over Second (2.5G) and Third (3G) 2063 Generation Wireless Networks", BCP 71, RFC 3481, 2064 February 2003. 2066 [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. 2067 Stevens, "Basic Socket Interface Extensions for IPv6", 2068 RFC 3493, February 2003. 2070 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 2071 for TCP", RFC 3522, April 2003. 2073 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 2074 Congestion Notification (ECN) Signaling with Nonces", 2075 RFC 3540, June 2003. 2077 [RFC3649] Floyd, S., "HighSpeed TCP for Large Congestion Windows", 2078 RFC 3649, December 2003. 2080 [RFC3708] Blanton, E. and M. Allman, "Using TCP Duplicate Selective 2081 Acknowledgement (DSACKs) and Stream Control Transmission 2082 Protocol (SCTP) Duplicate Transmission Sequence Numbers 2083 (TSNs) to Detect Spurious Retransmissions", RFC 3708, 2084 February 2004. 2086 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 2087 Congestion Windows", RFC 3742, March 2004. 2089 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 2090 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 2091 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 2092 RFC 3819, July 2004. 2094 [RFC4015] Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm 2095 for TCP", RFC 4015, February 2005. 2097 [RFC4022] Raghunarayan, R., "Management Information Base for the 2098 Transmission Control Protocol (TCP)", RFC 4022, 2099 March 2005. 2101 [RFC4653] Bhandarkar, S., Reddy, A., Allman, M., and E. Blanton, 2102 "Improving the Robustness of TCP to Non-Congestion 2103 Events", RFC 4653, August 2006. 2105 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 2106 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 2108 [RFC4774] Floyd, S., "Specifying Alternate Semantics for the 2109 Explicit Congestion Notification (ECN) Field", BCP 124, 2110 RFC 4774, November 2006. 2112 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick- 2113 Start for TCP and IP", RFC 4782, January 2007. 2115 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 2116 Discovery", RFC 4821, March 2007. 2118 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 2119 Extended Statistics MIB", RFC 4898, May 2007. 2121 [RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", 2122 RFC 4953, July 2007. 2124 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2125 Mitigations", RFC 4987, August 2007. 2127 [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion 2128 Control Algorithms", BCP 133, RFC 5033, August 2007. 2130 [RFC5166] Floyd, S., "Metrics for the Evaluation of Congestion 2131 Control Mechanisms", RFC 5166, March 2008. 2133 [RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, 2134 February 2009. 2136 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 2137 RFC 5482, March 2009. 2139 [RFC5562] Kuzmanovic, A., Mondal, A., Floyd, S., and K. 2140 Ramakrishnan, "Adding Explicit Congestion Notification 2141 (ECN) Capability to TCP's SYN/ACK Packets", RFC 5562, 2142 June 2009. 2144 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 2145 Control", RFC 5681, September 2009. 2147 [RFC5682] Sarolahti, P., Kojo, M., Yamamoto, K., and M. Hata, 2148 "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting 2149 Spurious Retransmission Timeouts with TCP", RFC 5682, 2150 September 2009. 2152 [RFC5690] Floyd, S., Arcia, A., Ros, D., and J. Iyengar, "Adding 2153 Acknowledgement Congestion Control to TCP", RFC 5690, 2154 February 2010. 2156 [RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC 2157 Series", RFC 5783, February 2010. 2159 [RFC5827] Allman, M., Avrachenkov, K., Ayesta, U., Blanton, J., and 2160 P. Hurtig, "Early Retransmit for TCP and Stream Control 2161 Transmission Protocol (SCTP)", RFC 5827, May 2010. 2163 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 2164 Authentication Option", RFC 5925, June 2010. 2166 [RFC5926] Lebovitz, G. and E. Rescorla, "Cryptographic Algorithms 2167 for the TCP Authentication Option (TCP-AO)", RFC 5926, 2168 June 2010. 2170 [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, July 2010. 2172 [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's 2173 Robustness to Blind In-Window Attacks", RFC 5961, 2174 August 2010. 2176 [RFC6013] Simpson, W., "TCP Cookie Transactions (TCPCT)", RFC 6013, 2177 January 2011. 2179 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 2180 Protocol Port Randomization", BCP 156, RFC 6056, 2181 January 2011. 2183 [RFC6069] Zimmermann, A. and A. Hannemann, "Making TCP More Robust 2184 to Long Connectivity Disruptions (TCP-LCD)", RFC 6069, 2185 December 2010. 2187 [RFC6077] Papadimitriou, D., Welzl, M., Scharf, M., and B. Briscoe, 2188 "Open Research Issues in Internet Congestion Control", 2189 RFC 6077, February 2011. 2191 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 2192 TCP Urgent Mechanism", RFC 6093, January 2011. 2194 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 2195 Multipath Operation with Multiple Addresses", RFC 6181, 2196 March 2011. 2198 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 2199 Iyengar, "Architectural Guidelines for Multipath TCP 2200 Development", RFC 6182, March 2011. 2202 [RFC6191] Gont, F., "Reducing the TIME-WAIT State Using TCP 2203 Timestamps", BCP 159, RFC 6191, April 2011. 2205 [RFC6247] Eggert, L., "Moving the Undeployed TCP Extensions RFC 2206 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, 2207 RFC 1644, and RFC 1693 to Historic Status", RFC 6247, 2208 May 2011. 2210 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 2211 "Computing TCP's Retransmission Timer", RFC 6298, 2212 June 2011. 2214 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 2215 Cheshire, "Internet Assigned Numbers Authority (IANA) 2216 Procedures for the Management of the Service Name and 2217 Transport Protocol Port Number Registry", BCP 165, 2218 RFC 6335, August 2011. 2220 [RFC6349] Constantine, B., Forget, G., Geib, R., and R. Schrage, 2221 "Framework for TCP Throughput Testing", RFC 6349, 2222 August 2011. 2224 [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled 2225 Congestion Control for Multipath Transport Protocols", 2226 RFC 6356, October 2011. 2228 [RFC6429] Bashyam, M., Jethanandani, M., and A. Ramaiah, "TCP Sender 2229 Clarification for Persist Condition", RFC 6429, 2230 December 2011. 2232 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 2233 Number Attacks", RFC 6528, February 2012. 2235 [RFC6582] Henderson, T., Floyd, S., Gurtov, A., and Y. Nishida, "The 2236 NewReno Modification to TCP's Fast Recovery Algorithm", 2237 RFC 6582, April 2012. 2239 [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", 2240 RFC 6633, May 2012. 2242 [RFC6675] Blanton, E., Allman, M., Wang, L., Jarvinen, I., Kojo, M., 2243 and Y. Nishida, "A Conservative Loss Recovery Algorithm 2244 Based on Selective Acknowledgment (SACK) for TCP", 2245 RFC 6675, August 2012. 2247 [RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", 2248 RFC 6691, July 2012. 2250 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 2251 "TCP Extensions for Multipath Operation with Multiple 2252 Addresses", RFC 6824, January 2013. 2254 [RFC6846] Pelletier, G., Sandlund, K., Jonsson, L-E., and M. West, 2255 "RObust Header Compression (ROHC): A Profile for TCP/IP 2256 (ROHC-TCP)", RFC 6846, January 2013. 2258 [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application 2259 Interface Considerations", RFC 6897, March 2013. 2261 [RFC6928] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, 2262 "Increasing TCP's Initial Window", RFC 6928, April 2013. 2264 [RFC6937] Mathis, M., Dukkipati, N., and Y. Cheng, "Proportional 2265 Rate Reduction for TCP", RFC 6937, May 2013. 2267 [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", 2268 RFC 6994, August 2013. 2270 12.2. Informative References 2272 [CK73] Cerf, V. and R. Kahn, "Towards Protocols for Internetwork 2273 Communication", IFIP/TC6.1, NIC 18764, INWG 39, 2274 September 1973. 2276 [Errata] "RFC Editor - RFC Errata", 2277 . 2279 [I-D.leith-tcp-htcp] 2280 Leith, D., "H-TCP: TCP Congestion Control for High 2281 Bandwidth-Delay Product Paths", draft-leith-tcp-htcp-06 2282 (work in progress), April 2008. 2284 [I-D.rhee-tcpm-cubic] 2285 Rhee, I., Xu, L., and S. Ha, "CUBIC for Fast Long-Distance 2286 Networks", draft-rhee-tcpm-cubic-02 (work in progress), 2287 August 2008. 2289 [I-D.sridharan-tcpm-ctcp] 2290 Sridharan, M., Tan, K., Bansal, D., and D. Thaler, 2291 "Compound TCP: A New TCP Congestion Control for High-Speed 2292 and Long Distance Networks", draft-sridharan-tcpm-ctcp-02 2293 (work in progress), November 2008. 2295 [JK92] Jacobson, V. and M. Karels, "Congestion Avoidance and 2296 Control", This paper is a revised version of [Jac88], that 2297 includes an additional appendix. This paper has not been 2298 traditionally published, but is currently available at 2299 ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992. 2301 [Jac88] Jacobson, V., "Congestion Avoidance and Control", ACM 2302 SIGCOMM 1988 Proceedings, in ACM Computer Communication 2303 Review, 18 (4), pp. 314-329, August 1988. 2305 [KP87] Karn, P. and C. Partridge, "Round Trip Time Estimation", 2306 ACM SIGCOMM 1987 Proceedings, in ACM Computer 2307 Communication Review, 17 (5), pp. 2-7, August 1987. 2309 [MAF04] Medina, A., Allman, M., and S. Floyd, "Measuring the 2310 Evolution of Transport Protocols in the Internet", ACM 2311 Computer Communication Review, 35 (2), April 2005. 2313 [MM96] Mathis, M. and J. Mahdavi, "Forward Acknowledgement: 2314 Refining TCP Congestion Control", ACM SIGCOMM 1996 2315 Proceedings, in ACM Computer Communication Review 26 (4), 2316 pp. 281-292, October 1996. 2318 [RFC1016] Prue, W. and J. Postel, "Something a host could do with 2319 source quench: The Source Quench Introduced Delay 2320 (SQuID)", RFC 1016, July 1987. 2322 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 2323 3", BCP 9, RFC 2026, October 1996. 2325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2326 Requirement Levels", BCP 14, RFC 2119, March 1997. 2328 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2329 "Definition of the Differentiated Services Field (DS 2330 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2331 December 1998. 2333 [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. 2334 Conrad, "Stream Control Transmission Protocol (SCTP) 2335 Partial Reliability Extension", RFC 3758, May 2004. 2337 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2338 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 2340 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2341 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 2342 Congestion Control", RFC 4341, March 2006. 2344 [RFC6115] Li, T., "Recommendation for a Routing Architecture", 2345 RFC 6115, February 2011. 2347 [SCWA99] Savage, S., Cardwell, N., Wetherall, D., and T. Anderson, 2348 "TCP Congestion Control with a Misbehaving Receiver", ACM 2349 Computer Communication Review, 29 (5), pp. 71-78, 2350 October 1999. 2352 Authors' Addresses 2354 Martin Duke 2355 F5 Networks 2356 401 Elliott Ave W 2357 Seattle, WA 98119 2359 Phone: 206-272-7537 2360 Email: m.duke@f5.com 2361 Robert Braden 2362 USC Information Sciences Institute 2363 Marina del Rey, CA 90292-6695 2365 Phone: 310-448-9173 2366 Email: braden@isi.edu 2368 Wesley M. Eddy 2369 MTI Systems 2370 MS 500-ASRC; 21000 Brookpark Rd 2371 Cleveland, OH 44135 2373 Phone: 216-433-6682 2374 Email: wes@mti-systems.com 2376 Ethan Blanton 2378 Email: elb@psg.com 2380 Alexander Zimmermann 2381 NetApp, Inc. 2382 Sonnenallee 1 2383 Kirchheim 85551 2384 Germany 2386 Phone: +49 89 900594712 2387 Email: alexander.zimmermann@netapp.com