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