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