idnits 2.17.1 

draft-ietf-tcpm-tcp-roadmap-06.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

  ** It looks like you're using RFC 3978 boilerplate.  You should update this
     to the boilerplate described in the IETF Trust License Policy document
     (see https://trustee.ietf.org/license-info), which is required now.

  -- Found old boilerplate from RFC 3978, Section 5.1 on line 20.

  -- Found old boilerplate from RFC 3978, Section 5.5 on line 1520.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1497.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1504.

  -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1510.

  ** This document has an original RFC 3978 Section 5.4 Copyright Line,
     instead of the newer IETF Trust Copyright according to RFC 4748.

  ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead
     of the newer disclaimer which includes the IETF Trust according to RFC
     4748.


  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard


  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 198: '...      MUST, SHOULD, MAY, SHOULD NOT, a...'
     RFC 2119 keyword, line 252: '...he algorithm from a SHOULD to a MUST."...'
     RFC 2119 keyword, line 476: '...      sender SHOULD set its congestion...'


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
     match the current year

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

  -- The document date (February 3, 2006) is 6651 days in the past.  Is this
     intentional?


  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  -- Missing reference section? 'RFC2026' on line 1143 looks like a reference

  -- Missing reference section? 'RFC0793' on line 1137 looks like a reference

  -- Missing reference section? 'RFC1122' on line 1140 looks like a reference

  -- Missing reference section? 'KP87' on line 1439 looks like a reference

  -- Missing reference section? 'Jac88' on line 1435 looks like a reference

  -- Missing reference section? 'JK92' on line 1429 looks like a reference

  -- Missing reference section? 'RFC2460' on line 1146 looks like a reference

  -- Missing reference section? 'RFC2581' on line 1154 looks like a reference

  -- Missing reference section? 'RFC2873' on line 1160 looks like a reference

  -- Missing reference section? 'RFC2474' on line 1149 looks like a reference

  -- Missing reference section? 'RFC2988' on line 1164 looks like a reference

  -- Missing reference section? 'RFC1323' on line 1169 looks like a reference

  -- Missing reference section? 'RFC2675' on line 1157 looks like a reference

  -- Missing reference section? 'RFC3168' on line 1189 looks like a reference

  -- Missing reference section? 'RFC3042' on line 1185 looks like a reference

  -- Missing reference section? 'MAF04' on line 1443 looks like a reference

  -- Missing reference section? 'RFC3390' on line 1193 looks like a reference

  -- Missing reference section? 'RFC3782' on line 1203 looks like a reference

  -- Missing reference section? 'RFC2018' on line 1175 looks like a reference

  -- Missing reference section? 'RFC2883' on line 1181 looks like a reference

  -- Missing reference section? 'RFC3517' on line 1196 looks like a reference

  -- Missing reference section? 'RFC1948' on line 1172 looks like a reference

  -- Missing reference section? 'RFC1321' on line 423 looks like a reference

  -- Missing reference section? 'RFC2385' on line 1178 looks like a reference

  -- Missing reference section? 'RFC3562' on line 1200 looks like a reference

  -- Missing reference section? 'RFC2140' on line 1218 looks like a reference

  -- Missing reference section? 'RFC3124' on line 1224 looks like a reference

  -- Missing reference section? 'RFC2861' on line 1221 looks like a reference

  -- Missing reference section? 'RFC3465' on line 1227 looks like a reference

  -- Missing reference section? 'SCWA99' on line 1452 looks like a reference

  -- Missing reference section? 'RFC3449' on line 1405 looks like a reference

  -- Missing reference section? 'RFC3522' on line 1230 looks like a reference

  -- Missing reference section? 'RFC3540' on line 1233 looks like a reference

  -- Missing reference section? 'RFC3649' on line 1237 looks like a reference

  -- Missing reference section? 'RFC3708' on line 1240 looks like a reference

  -- Missing reference section? 'RFC3742' on line 1246 looks like a reference

  -- Missing reference section? 'RFC4015' on line 1207 looks like a reference

  -- Missing reference section? 'RFC4138' on line 1249 looks like a reference

  -- Missing reference section? 'RFC1106' on line 1256 looks like a reference

  -- Missing reference section? 'RFC1110' on line 1259 looks like a reference

  -- Missing reference section? 'RFC1146' on line 1262 looks like a reference

  -- Missing reference section? 'RFC1263' on line 1265 looks like a reference

  -- Missing reference section? 'RFC1379' on line 1268 looks like a reference

  -- Missing reference section? 'RFC1644' on line 1271 looks like a reference

  -- Missing reference section? 'RFC1693' on line 1274 looks like a reference

  -- Missing reference section? 'RFC0813' on line 1279 looks like a reference

  -- Missing reference section? 'RFC0814' on line 1282 looks like a reference

  -- Missing reference section? 'RFC0816' on line 1285 looks like a reference

  -- Missing reference section? 'RFC0817' on line 1288 looks like a reference

  -- Missing reference section? 'RFC0872' on line 1291 looks like a reference

  -- Missing reference section? 'RFC0896' on line 1296 looks like a reference

  -- Missing reference section? 'RFC0964' on line 1299 looks like a reference

  -- Missing reference section? 'RFC1072' on line 1311 looks like a reference

  -- Missing reference section? 'RFC1185' on line 1321 looks like a reference

  -- Missing reference section? 'RFC2914' on line 1380 looks like a reference

  -- Missing reference section? 'RFC2488' on line 1360 looks like a reference

  -- Missing reference section? 'RFC2757' on line 1368 looks like a reference

  -- Missing reference section? 'RFC2760' on line 1371 looks like a reference

  -- Missing reference section? 'MM96' on line 1447 looks like a reference

  -- Missing reference section? 'RFC3135' on line 1386 looks like a reference

  -- Missing reference section? 'RFC3150' on line 1390 looks like a reference

  -- Missing reference section? 'RFC3155' on line 1394 looks like a reference

  -- Missing reference section? 'RFC3366' on line 1401 looks like a reference

  -- Missing reference section? 'RFC3481' on line 1409 looks like a reference

  -- Missing reference section? 'RFC3819' on line 1418 looks like a reference

  -- Missing reference section? 'RFC0879' on line 1293 looks like a reference

  -- Missing reference section? 'RFC1071' on line 1307 looks like a reference

  -- Missing reference section? 'RFC1624' on line 1336 looks like a reference

  -- Missing reference section? 'RFC1936' on line 1339 looks like a reference

  -- Missing reference section? 'RFC2525' on line 1364 looks like a reference

  -- Missing reference section? 'RFC2923' on line 1383 looks like a reference

  -- Missing reference section? 'RFC3360' on line 1398 looks like a reference

  -- Missing reference section? 'RFC3493' on line 1414 looks like a reference

  -- Missing reference section? 'RFC1066' on line 1303 looks like a reference

  -- Missing reference section? 'RFC1156' on line 1314 looks like a reference

  -- Missing reference section? 'RFC1213' on line 1324 looks like a reference

  -- Missing reference section? 'RFC2012' on line 1342 looks like a reference

  -- Missing reference section? 'RFC2452' on line 1356 looks like a reference

  -- Missing reference section? 'RFC4022' on line 1423 looks like a reference

  -- Missing reference section? 'RFC1180' on line 1318 looks like a reference

  -- Missing reference section? 'RFC1470' on line 1331 looks like a reference

  -- Missing reference section? 'RFC2398' on line 1346 looks like a reference

  -- Missing reference section? 'RFC1337' on line 1328 looks like a reference

  -- Missing reference section? 'RFC2415' on line 1349 looks like a reference

  -- Missing reference section? 'RFC2416' on line 1352 looks like a reference

  -- Missing reference section? 'RFC2884' on line 1376 looks like a reference


     Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 93 comments (--).

     Run idnits with the --verbose option for more detailed information about
     the items above.

--------------------------------------------------------------------------------


2	Network Working Group                                            M. Duke
3	Internet-Draft                                      Boeing Phantom Works
4	Expires: August 7, 2006                                        R. Braden
5	                                      USC Information Sciences Institute
6	                                                                 W. Eddy
7	                                         Verizon Federal Network Systems
8	                                                              E. Blanton
9	                                      Purdue University Computer Science
10	                                                        February 3, 2006

12	               A Roadmap for TCP Specification Documents
13	                     draft-ietf-tcpm-tcp-roadmap-06

15	Status of this Memo

17	   By submitting this Internet-Draft, each author represents that any
18	   applicable patent or other IPR claims of which he or she is aware
19	   have been or will be disclosed, and any of which he or she becomes
20	   aware will be disclosed, in accordance with Section 6 of BCP 79.

22	   Internet-Drafts are working documents of the Internet Engineering
23	   Task Force (IETF), its areas, and its working groups.  Note that
24	   other groups may also distribute working documents as Internet-
25	   Drafts.

27	   Internet-Drafts are draft documents valid for a maximum of six months
28	   and may be updated, replaced, or obsoleted by other documents at any
29	   time.  It is inappropriate to use Internet-Drafts as reference
30	   material or to cite them other than as "work in progress."

32	   The list of current Internet-Drafts can be accessed at
33	   http://www.ietf.org/ietf/1id-abstracts.txt.

35	   The list of Internet-Draft Shadow Directories can be accessed at
36	   http://www.ietf.org/shadow.html.

38	   This Internet-Draft will expire on August 7, 2006.

40	Copyright Notice

42	   Copyright (C) The Internet Society (2006).

44	Abstract

46	   This document contains a "roadmap" to the Requests for Comments (RFC)
47	   documents relating to the Internet's Transmission Control Protocol
48	   (TCP).  This roadmap provides a brief summary of the documents
49	   defining TCP and various TCP extensions that have accumulated in the
50	   RFC series.  This serves as a guide and quick reference for both TCP
51	   implementers and other parties who desire information contained in
52	   the TCP-related RFCs.

54	Table of Contents

56	   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
57	   2.   Basic Functionality  . . . . . . . . . . . . . . . . . . . .   5
58	   3.   Recommended Enhancements . . . . . . . . . . . . . . . . . .   8
59	     3.1  Congestion Control and Loss Recovery Extensions  . . . . .   9
60	     3.2  SACK-based Loss Recovery and Congestion Control  . . . . .  10
61	     3.3  Dealing with Forged Segments . . . . . . . . . . . . . . .  11
62	   4.   Experimental Extensions  . . . . . . . . . . . . . . . . . .  13
63	   5.   Historic Extensions  . . . . . . . . . . . . . . . . . . . .  17
64	   6.   Support Documents  . . . . . . . . . . . . . . . . . . . . .  19
65	     6.1  Foundational Works . . . . . . . . . . . . . . . . . . . .  19
66	     6.2  Difficult Network Environments . . . . . . . . . . . . . .  21
67	     6.3  Implementation Advice  . . . . . . . . . . . . . . . . . .  24
68	     6.4  Management Information Bases . . . . . . . . . . . . . . .  25
69	     6.5  Tools and Tutorials  . . . . . . . . . . . . . . . . . . .  27
70	     6.6  Case Studies . . . . . . . . . . . . . . . . . . . . . . .  27
71	   7.   Undocumented TCP Features  . . . . . . . . . . . . . . . . .  29
72	   8.   Security Considerations  . . . . . . . . . . . . . . . . . .  31
73	   9.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  32
74	   10.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . .  33
75	   11.  Informative References . . . . . . . . . . . . . . . . . . .  34
76	     11.1   Basic Functionality  . . . . . . . . . . . . . . . . . .  34
77	     11.2   Recommended Enhancements . . . . . . . . . . . . . . . .  34
78	     11.3   Experimental Extensions  . . . . . . . . . . . . . . . .  35
79	     11.4   Historic Extensions  . . . . . . . . . . . . . . . . . .  36
80	     11.5   Support Documents  . . . . . . . . . . . . . . . . . . .  37
81	     11.6   Informative References Outside the RFC Series  . . . . .  40
82	        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  40
83	        Intellectual Property and Copyright Statements . . . . . . .  42

85	1.  Introduction

87	   A correct and efficient implementation of the Transmission Control
88	   Protocol (TCP) is a critical part of the software of most Internet
89	   hosts.  As TCP has evolved over the years, many distinct documents
90	   have become part of the accepted standard for TCP.  At the same time,
91	   a large number of more experimental modifications to TCP have also
92	   been published in the RFC series, along with informational notes,
93	   case studies, and other advice.

95	   As an introduction to newcomers and an attempt to organize the
96	   plethora of information for old hands, this document contains a
97	   "roadmap" to the TCP-related RFCs.  It provides a brief summary of
98	   the RFC documents that define TCP.  This should provide guidance to
99	   implementers on the relevance and significance of the standards track
100	   extensions, informational notes, and best current practices that
101	   relate to TCP.

103	   This document is not an update of RFC 1122, and is not a rigorous
104	   standard for what needs to be implemented in TCP.  This document is
105	   merely an informational roadmap that captures, organizes, and
106	   summarizes most of the RFC documents that a TCP implementer,
107	   experimenter, or student should be aware of.  Particular comments or
108	   broad categorizations that this document makes about individual
109	   mechanisms and behaviors are not to be taken as definitive, nor
110	   should the content of this document alone influence implementation
111	   decisions.

113	   This roadmap includes a brief description of the contents of each
114	   TCP-related RFC.  In some cases, we simply supply the abstract or a
115	   key summary sentence from the text as a terse description.  In
116	   addition, a letter code after an RFC number indicates its category in
117	   the RFC series (see BCP 9 [RFC2026] for explanation of these
118	   categories):

120	      S - Standards Track (Proposed Standard, Draft Standard, or
121	      Standard)

123	      E - Experimental

125	      B - Best Current Practice

127	      I - Informational

129	   Note that the category of an RFC does not necessarily reflect its
130	   current relevance.  For instance, RFC 2581 is nearly universally
131	   deployed although it is only a Proposed Standard.  Similarly, some
132	   Informational RFCs contain significant technical proposals for
133	   changing TCP.

135	   This roadmap is divided into four main sections.  Section 2 lists the
136	   RFCs that describe absolutely required TCP behaviors for proper
137	   functioning and interoperability.  Further RFCs that describe
138	   strongly encouraged, but not essential, behaviors are listed in
139	   Section 3.  Experimental extensions that are not yet standard
140	   practices, but potentially could be in the future, are described in
141	   Section 4.

143	   The reader will probably notice that these three sections are broadly
144	   equivalent to MUST/SHOULD/MAY specifications (per RFC 2119), and
145	   while the authors support this intuition, this document is merely
146	   descriptive; it does not represent a binding standards track
147	   position.  An individual implementer still needs to examine the
148	   standards documents themselves to evaluate specific requirement
149	   levels.

151	   A small number of older experimental extensions that have not been
152	   widely implemented, deployed, and used are noted in Section 5.  Many
153	   other supporting documents that are relevant to the development,
154	   implementation, and deployment of TCP are described in Section 6.
155	   Within each section, RFCs are listed in the chronological order of
156	   their publication dates.

158	   A small number of fairly ubiquitous important implementation
159	   practices that are not currently documented in the RFC series are
160	   listed in Section 7.

162	2.  Basic Functionality

164	   A small number of documents compose the core specification of TCP.
165	   These define the required basic functionalities of TCP's header
166	   parsing, state machine, congestion control, and retransmission
167	   timeout computation.  These base specifications must be correctly
168	   followed for interoperability.

170	   RFC 793 S: "Transmission Control Protocol", STD 7 (September 1981)

172	      This is the fundamental TCP specification document [RFC0793].
173	      Written by Jon Postel as part of the Internet protocol suite's
174	      core, it describes the TCP packet format, the TCP state machine
175	      and event processing, and TCP's semantics for data transmission,
176	      reliability, flow control, multiplexing, and acknowledgement.

178	      Section 3.6 of RFC 793, describing TCP's handling of the IP
179	      precedence and security compartment, is mostly irrelevant today.
180	      RFC 2873 changed the IP precedence handling, and the security
181	      compartment portion of the API is no longer implemented or used.
182	      In addition, RFC 793 did not describe any congestion control
183	      mechanism.  Otherwise, however, the majority of this document
184	      still acurately describes modern TCPs.  RFC 793 is the last of a
185	      series of developmental TCP specifications, starting in the
186	      Internet Experimental Notes (IENs) and continuing in the RFC
187	      series.

189	   RFC 1122 S: "Requirements for Internet Hosts - Communication Layers"
190	   (October 1989)

192	      This document [RFC1122] updates and clarifies RFC 793, fixing some
193	      specification bugs and oversights.  It also explains some features
194	      such as keep-alives and Karn's and Jacobson's RTO estimation
195	      algorithms [KP87][Jac88][JK92].  ICMP interactions are mentioned
196	      and some tips are given for efficient implementation.  RFC 1122 is
197	      an Applicability Statement, listing the various features that
198	      MUST, SHOULD, MAY, SHOULD NOT, and MUST NOT be present in
199	      standards-conforming TCP implementations.  Unlike a purely
200	      informational "roadmap", this Applicability Statement is a
201	      standards document, and gives formal rules for implementation.

203	   RFC 2460 S: "Internet Protocol, Version 6 (IPv6) Specification
204	   (December 1998)

206	      This document [RFC2460] is of relevance to TCP because it defines
207	      how the pseudo-header for TCP's checksum computation is derived,
208	      when 128-bit IPv6 addresses are used instead of 32-bit IPv4
209	      addresses.  Additionally, RFC 2675 describes TCP changes required
210	      to support IPv6 jumbograms.

212	   RFC 2581 S: "TCP Congestion Control" (April 1999)

214	      Although RFC 793 did not contain any congestion control
215	      mechanisms, today congestion control is a required component of
216	      TCP implementations.  This document [RFC2581] defines the current
217	      versions of Van Jacobson's congestion avoidance and control
218	      mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88].  RFC
219	      2001 was a conceptual precursor that was obsoleted by RFC 2581.

221	      A number of behaviors that together comprise what the community
222	      refers to as "Reno TCP", are described in RFC 2581.  The name
223	      "Reno" comes from the Net/2 release of the 4.3 BSD operating
224	      system.  This is generally regarded as the least common
225	      denominator among TCP flavors currently found running on Internet
226	      hosts.  Reno TCP includes the congestion control features of slow
227	      start, congestion avoidance, fast retransmit, and fast recovery.

229	      RFC 1122 mandates the implementation of a congestion control
230	      mechanism, and RFC 2581 details the currently accepted mechanism.
231	      RFC 2581 differs slightly from the other documents listed in this
232	      section, as it does not affect the ability of two TCP endpoints to
233	      communicate; however, congestion control remains a critical
234	      component of any widely-deployed TCP implementation and is
235	      required for the avoidance of congestion collapse and to ensure
236	      fairness among competing flows.

238	   RFC 2873 S: "TCP Processing of the IPv4 Precendence Field" (June
239	   2000)

241	      This document [RFC2873] removes from the TCP specification all
242	      processing of the precedence bits of the TOS byte of the IP
243	      header.  This resolves a conflict over the use of these bits
244	      between RFC 793 and Differentiated Services [RFC2474].

246	   RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000)

248	      Abstract: "This document defines the standard algorithm that
249	      Transmission Control Protocol (TCP) senders are required to use to
250	      compute and manage their retransmission timer.  It expands on the
251	      discussion in section 4.2.3.1 of RFC 1122 and upgrades the
252	      requirement of supporting the algorithm from a SHOULD to a MUST."
253	      [RFC2988]

255	3.  Recommended Enhancements

257	   This section describes recommended TCP modifications that improve
258	   performance and security.  RFCs 1323 and 3168 represent fundamental
259	   changes to the protocol.  RFC 1323, based on RFCs 1072 and 1185,
260	   allows better utilization of high bandwidth-delay product paths by
261	   providing some needed mechanisms for high-rate transfers.  RFC 3168
262	   describes a change to the Internet's architecture, where routers
263	   signal end-hosts of growing congestion levels, and can do so before
264	   packet losses are forced.  Section 3.1 lists improvements in the
265	   congestion control and loss recovery mechanisms specified in RFC
266	   2581.  Section 3.2 describes further refinements that make use of
267	   selective acknowledgements.  Section 3.3 deals with the problem of
268	   preventing forged segments.

270	   RFC 1323 S:  "TCP Extensions for High Performance" (May 1992)

272	      This document [RFC1323] defines TCP extensions for window scaling,
273	      timestamps, and protection against wrapped sequence numbers, for
274	      efficient and safe operation over paths with large bandwidth-delay
275	      products.  These extensions are commonly found in currently-used
276	      systems; however, they may require manual tuning and
277	      configuration.  One issue in this specification that is still
278	      under discussion concerns a modification to the algorithm for
279	      estimating the mean RTT when timestamps are used.

281	   RFC 2675 S: "IPv6 Jumbograms" (August 1999)

283	      IPv6 supports longer datagrams than were allowed in IPv4.  These
284	      are known as Jumbograms, and use with TCP has necessitated changes
285	      to the handling of TCP's MSS and Urgent fields (both 16 bits).
286	      This document [RFC2675] explains those changes.  While it
287	      describes changes to basic header semantics, these changes should
288	      only affect the use of very large segments, such as IPv6
289	      jumbograms, which are currently rarely used in the general
290	      Internet.  Supporting the behavior described in this document does
291	      not affect interoperability with other TCP implementations when
292	      using IPv4 or non-jumbogram IPv6.  This document states that
293	      jumbograms are to only be used when it can be guaranteed that all
294	      receiving nodes, including each router in the end-to-end path,
295	      will support jumbograms.  If even a single node that that does not
296	      support jumbograms is attached to a local network, then no host on
297	      that network may use jumbograms.  This explains why jumbogram use
298	      has been rare, and why this document is considered a performance
299	      optimzation rather than part of TCP over IPv6's basic
300	      functionality.

302	   RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
303	   to IP" (September 2001)

305	      This document [RFC3168] defines a means for end hosts to detect
306	      congestion before congested routers are forced to discard packets.
307	      Although congestion notification takes place at the IP level, ECN
308	      requires support at the transport level (e.g., in TCP) to echo the
309	      bits and adapt the sending rate.  This document updates RFC 793 to
310	      define two previously-unused flag bits in the TCP header for ECN
311	      support.  RFC 3540 provides a supplementary (experimental) means
312	      for more secure use of ECN, and RFC 2884 provides some sample
313	      results from using ECN.

315	3.1  Congestion Control and Loss Recovery Extensions

317	   Two of the most important aspects of TCP are its congestion control
318	   and loss recovery features.  Since TCP traditionally (in the absence
319	   of ECN) uses losses to infer congestion, there is a rather intimate
320	   coupling between congestion control and loss recovery mechanisms.
321	   There are several extensions to both features, and more often than
322	   not, a particular extension applies to both.  In this sub-section, we
323	   group enhancements to either congestion control, loss recovery, or
324	   both, which can be performed unilaterally - without negotiating
325	   support between endpoints.  In the next sub-section, we group the
326	   extensions which specify or rely on the SACK option, which must be
327	   negotiated bilaterally.  TCP implementations should include the
328	   enhancements from both sub-sections so that TCP senders can perform
329	   well without regard to the feature sets of other hosts they connect
330	   to.  For example, if SACK use is not successfully negotiated, a host
331	   should use the NewReno behavior as a fall-back.

333	   RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
334	   (January 2001)

336	      Abstract: "This document proposes Limited Transmit, a new
337	      Transmission Control Protocol (TCP) mechanism that can be used to
338	      more effectively recover lost segments when a connection's
339	      congestion window is small, or when a large number of segments are
340	      lost in a single transmission window."  [RFC3042]
341	      Tests from 2004 showed that Limited Transmit was deployed in
342	      roughly one third of the web servers tested [MAF04].

344	   RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)

346	      This document [RFC3390] updates RFC 2581 to permit an initial TCP
347	      window of three or four segments during the slow-start phase,
348	      depending on the segment size.

350	   RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery
351	   Algorithm" (April 2004)

353	      This document [RFC3782] specifies a modification to the standard
354	      Reno fast recovery algorithm, whereby a TCP sender can use partial
355	      acknowledgements to make inferences determining the next segment
356	      to send in situations where SACK would be helpful, but isn't
357	      available.  While it is only a slight modification, the NewReno
358	      behavior can make a significant difference in performance when
359	      multiple segments are lost from a single window of data.

361	3.2  SACK-based Loss Recovery and Congestion Control

363	   The base TCP specification in RFC 793 provided only a simple
364	   cumulative acknowledgment mechanism.  However, a selective
365	   acknowledgment (SACK) mechanism provides performance improvement in
366	   the presence of multiple packet losses from the same flight, more
367	   than outweighing the modest increase in complexity.  A TCP should be
368	   expected to implement SACK, however SACK is a negotiated option and
369	   is only used if support is advertised by both sides of a connection.

371	   RFC 2018 S: "TCP Selective Acknowledgement Options" (October 1996)

373	      This document [RFC2018] defines the basic selective
374	      acknowledgement (SACK) mechanism for TCP.

376	   RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
377	   Option for TCP" (July 2000)

379	      This document [RFC2883] extends RFC 2018 to cover the case of
380	      acknowledging duplicate segments.

382	   RFC 3517 S: "A Conservative Selective Acknowledgement (SACK)-based
383	   Loss Recovery Algorithm for TCP" (April 2003)

385	      This document [RFC3517] describes a relatively sophisticated
386	      algorithm that a TCP sender can use for loss recovery when SACK
387	      reports more than one segment lost from a single flight of data.
388	      While support for the exchange of SACK information is widely
389	      implemented, not all implementations use an algorithm as
390	      sophisticated as that described in RFC 3517.

392	3.3  Dealing with Forged Segments

394	   By default, TCP lacks any cryptographic structures to differentiate
395	   legitimate segments and those spoofed from malicious hosts.  Spoofing
396	   valid segments requires correctly guessing a number of fields.  The
397	   documents in this sub-section describe ways to make that guessing
398	   harder, or prevent it from being able to negatively impact a
399	   connection.

401	   The TCPM working group is currently in progress towards fully
402	   understanding and defining mechanisms for preventing spoofing attacks
403	   (including both spoofed TCP segments and ICMP datagrams).  Some of
404	   the solutions being considered rely on TCP modifications, while
405	   others rely on security at lower layers (like IPsec) for protection.

407	   RFC 1948 I: "Defending Against Sequence Number Attacks" (May 1996)

409	      This document [RFC1948] describes the TCP vulnerability that
410	      allows an attacker to send forged TCP packets, based upon guessing
411	      the initial sequence number in the three-way handshake.  Simple
412	      defenses against exploitation are then described.  Some variation
413	      is implemented in most currently-used operating systems.

415	   RFC 2385 S: "Protection of BGP Sessions via the TCP MD5 Signature
416	   Option" (August 1998)

418	      From document: "This document describes current existing practice
419	      for securing BGP against certain simple attacks.  It is understood
420	      to have security weaknesses against concerted attacks.

422	      This memo describes a TCP extension to enhance security for BGP.
423	      It defines a new TCP option for carrying an MD5 [RFC1321] digest
424	      in a TCP segment.  This digest acts like a signature for that
425	      segment, incorporating information known only to the connection
426	      end points.  Since BGP uses TCP as its transport, using this
427	      option in the way described in this paper significantly reduces
428	      the danger from certain security attacks on BGP."  [RFC2385]

430	      TCP MD5 options are currently only used in very limited contexts,
431	      primarily for defending BGP exchanges between routers.  Some
432	      deployment notes for those using TCP MD5 are found in the later
433	      RFC 3562, "Key Management Considerations for the TCP MD5 Signature
434	      Option" [RFC3562].  A draft that is currently in the RFC Editor's
435	      queue for publication [tcpmd5app] deprecates TCP MD5 for use
436	      outside BGP.

438	4.  Experimental Extensions

440	   The RFCs in this section are still experimental, but may become
441	   proposed standards in the future.  At least part of the reason that
442	   they are still experimental is to gain more wide-scale experience
443	   with them before making a standards track decision.  By their
444	   publication as experimental RFCs, it is hoped that the community of
445	   TCP researchers will analyze and test the contents of these RFCs.
446	   Although encouraged for experimentation, there is not yet formal
447	   consensus that these are fully logical and safe behaviors.  Wide-
448	   scale deployment of implementations that use these features should be
449	   well thought-out in terms of consequences.

451	   RFC 2140 I: "TCP Control Block Interdependence" (April 1997)

453	      This document [RFC2140] suggests how TCP connections between the
454	      same endpoints might share information, such as their congestion
455	      control state.  To some degree, this is done in practice by a few
456	      operating systems; for example, Linux currently has a destination
457	      cache.  Although this RFC is technically informational, the
458	      concepts it describes are in experimental use, so we include it in
459	      this section.

461	      A related proposal, the Congestion Manager, is specified in RFC
462	      3124 [RFC3124].  The idea behind the Congestion Manager, moving
463	      congestion control outside of individual TCP connections,
464	      represents a modification to the core of TCP, which supports
465	      sharing information among TCP connections as well.  Although a
466	      Proposed Standard, some pieces of the Congestion Manager support
467	      architecture have not been specified yet, and it has not achieved
468	      use or implementation beyond experimental stacks, so it is not
469	      listed among the standard TCP enhancements in this roadmap.

471	   RFC 2861 E: "TCP Congestion Window Validation" (June 2000)

473	      This document [RFC2861] suggests reducing the congestion window
474	      over time when no packets are flowing.  This behavior is more
475	      aggressive than that specified in RFC 2581, which says that a TCP
476	      sender SHOULD set its congestion window to the initial window
477	      after an idle period of an RTO or greater.

479	   RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting
480	   (ABC)" (February 2003)

482	      This document [RFC3465] suggests that congestion control use the
483	      number of bytes acknowledged rather than the number of
484	      acknowledgements received.  This has been implemented in Linux.
485	      The ABC mechanism behaves differently than the standard method
486	      when there is not a one-to-one relationship between data segments
487	      and acknowledgements.  ABC still operates within the accepted
488	      guidelines, but is more robust to delayed ACKs and ACK-division
489	      [SCWA99][RFC3449].

491	   RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003)

493	      This document [RFC3522] suggests using timestamps to detect
494	      spurious timeouts.

496	   RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling
497	   with Nonces" (June 2003)

499	      This document [RFC3540] suggests a modified ECN to address
500	      security concerns, and updates RFC 3168.

502	   RFC 3649 E: "HighSpeed TCP for Large Congestion Windows" (December
503	   2003)

505	      This document [RFC3649] suggests a modification to TCP's steady-
506	      state behavior to efficiently use very large windows.

508	   RFC 3708 E: "Using TCP Duplicate Selective Acknowledgement (DSACKs)
509	   and Stream Control Transmission Protocol (SCTP) Duplicate
510	   Transmission Sequence Numbers (TSNs) to Detect Spurious
511	   Retransmissions" (February 2004)

513	      Abstract: "TCP and Stream Control Transmission Protocol (SCTP)
514	      provide notification of duplicate segment receipt through
515	      Duplicate Selective Acknowledgement (DSACKs) and Duplicate
516	      Transmission Sequence Number (TSN) notification, respectively.
517	      This document presents conservative methods of using this
518	      information to identify unnecessary retransmissions for various
519	      applications."  [RFC3708]

521	   RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion
522	   Windows" (March 2004)

524	      This document [RFC3742] describes a more conservative slow-start
525	      behavior to prevent massive packet losses when a connection uses a
526	      very large window.

528	   RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005)

530	      This document [RFC4015] describes the response portion of the
531	      Eifel algorithm, which can be used in conjunction with one of
532	      several methods of detecting when loss recovery has been
533	      spuriously entered, such as the Eifel detection algorithm in RFC
534	      3522, the algorithm in RFC 3708, or F-RTO in RFC 4138.

536	      Abstract: "Based on an appropriate detection algorithm, the Eifel
537	      response algorithm provides a way for a TCP sender to respond to a
538	      detected spurious timeout.  It adapts the retransmission timer to
539	      avoid further spurious timeouts, and can avoid - depending on the
540	      detection algorithm - the often unnecessary go-back-N retransmits
541	      that would otherwise be sent.  In addition, the Eifel response
542	      algorithm restores the congestion control state in such a way that
543	      packet bursts are avoided."

545	      RFC 4015 is itself a Proposed Standard.  The consensus of the TCPM
546	      working group was to place it in this section of the roadmap
547	      document due to three factors.

549	      1.  RFC 4015 operates on the output of a detection algorithm, for
550	          which there is currently no available mechanism on the
551	          standards track.

553	      2.  The working group was not aware of any wide deployment and use
554	          of RFC 4015.

556	      3.  The concensus of the working group, after a discussion of the
557	          known Intellectual Property Rights claims on the techniques
558	          described in RFC 4015, identified this section of the roadmap
559	          as an appropriate location.

561	   RFC 4138 E: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
562	   Spurious Retransmission Timeouts with TCP and the Stream Control
563	   Transmission Protocol" (August 2005)

565	      The F-RTO detection algorithm [RFC4138] provides another option
566	      for inferring spurious retransmission timeouts.  Unlike some
567	      similar detection methods, F-RTO does not rely on the use of any
568	      TCP options.

570	5.  Historic Extensions

572	   The RFCs listed here define extensions that have thus far failed to
573	   arouse substantial interest from implementers, or were found to be
574	   defective for general use.

576	   RFC 1106 "TCP Big Window and NAK Options" (June 1989) - found
577	   defective

579	      This RFC [RFC1106] defined an alternative to the Window Scale
580	      option for using large windows, and described the "negative
581	      acknowledgement" or NAK option.  There is a comparison of NAK and
582	      SACK methods, and early discussion of TCP over satellite issues.
583	      RFC 1110 explains some problems with the approaches described in
584	      RFC 1106.  The options described in this document have not been
585	      adopted by the larger community, although NAKs are used in the
586	      SCPS-TP adaptation of TCP for satellite and spacecraft use,
587	      developed by the Consultive Committee for Space Data Systems
588	      (CCSDS) .

590	   RFC 1110 "A Problem with the TCP Big Window Option" (August 1989) -
591	   deprecates RFC 1106

593	      Abstract: "The TCP Big Window option discussed in RFC 1106 will
594	      not work properly in an Internet environment which has both a high
595	      bandwidth * delay product and the possibility of disordering and
596	      duplicating packets.  In such networks, the window size must not
597	      be increased without a similar increase in the sequence number
598	      space.  Therefore, a different approach to big windows should be
599	      taken in the Internet."  [RFC1110]

601	   RFC 1146 E "TCP Alternate Checksum Options" (March 1990) - lacked
602	   interest

604	      This document [RFC1146] defined more robust TCP checksums than the
605	      16-bit ones-complement in use today.  A typographical error in RFC
606	      1145 is fixed in RFC 1146, otherwise the documents are the same.

608	   RFC 1263 "TCP Extensions Considered Harmful" (October 1991) - lacked
609	   interest

611	      This document [RFC1263] argues against "backwards compatible" TCP
612	      extensions.  Specifically mentioned are several TCP enhancements
613	      that have been successful, including timestamps, window scaling,
614	      PAWS, and SACK.  RFC 1263 presents an alternative approach called
615	      "protocol evolution", whereby several evolutionary versions of TCP
616	      would exist on hosts.  These distinct TCP versions would represent
617	      upgrades to each other and could be header-incompatible.
618	      Interoperability would be provided by having a virtualization
619	      layer select the right TCP version for a particular connection.
620	      This idea did not catch on with the community, while the type of
621	      extensions RFC 1263 specifically targeted as harmful did become
622	      popular.

624	   RFC 1379 I "Extending TCP for Transactions -- Concepts" (November
625	   1992) - found defective

627	      See RFC 1644.

629	   RFC 1644 E "T/TCP -- TCP Extensions for Transactions Functional
630	   Specification" (July 1994) - found defective

632	      The inventors of TCP believed that cached connection state could
633	      have been used to eliminate TCP's 3-way handshake, to support two-
634	      packet request/response exchanges.  RFCs 1379 [RFC1379] and 1644
635	      [RFC1644] show that this is far from simple.  Furthermore, T/TCP
636	      floundered on the ease of denial-of-service attacks that can
637	      result.  One idea pioneered by T/TCP lives on in RFC 2140, in the
638	      sharing of state across connections.

640	   RFC 1693 E "An Extension to TCP: Partial Order Service" (November
641	   1994) - lacked interest

643	      This document [RFC1693] defines a TCP extension for applications
644	      that do not care about the order in which application-layer
645	      objects are received.  Examples are multimedia and database
646	      applications.  In practice, these applications either accept the
647	      possible performance loss because of TCP's strict ordering, or
648	      they use more specialized transport protocols.

650	6.  Support Documents

652	   This section contains several classes of documents that do not
653	   necessarily define current protocol behaviors, but are nevertheless
654	   of interest to TCP implementers.  Section 6.1 describes several
655	   foundational RFCs that give modern readers a better understanding of
656	   the principles underlying TCP's behaviors and development over the
657	   years.  The documents listed in Section 6.2 provide advice on using
658	   TCP in various types of network situations that pose challenges above
659	   those of typical wired links.  Some implementation notes can be found
660	   in Section 6.3.  The TCP Management Information Bases are described
661	   in Section 6.4.  RFCs that describe tools for testing and debugging
662	   TCP implementations or contain high-level tutorials on the protocol
663	   are listed Section 6.5, while Section 6.6 lists a number of case
664	   studies that have explored TCP performance.

666	6.1  Foundational Works

668	   The documents listed in this section contain information that is
669	   largely duplicated by the standards documents previously discussed.
670	   However, some of them contain a greater depth of problem statement
671	   explanation or other context.  Particularly, RFCs 813-817 (known as
672	   the "Dave Clark Five"), describe some early problems and solutions
673	   (RFC 815 only describes the reassembly of IP fragments, and is not
674	   included in this TCP roadmap).

676	   RFC 813: "Window and Acknowledgement Strategy in TCP" (July 1982)

678	      This document [RFC0813] contains an early discussion of Silly
679	      Window Syndrome and its avoidance, and motivates and describes the
680	      use of delayed acknowledgements.

682	   RFC 814: "Name, Addresses, Ports, and Routes" (July 1982)

684	      Suggestions and guidance for the design of tables and algorithms
685	      to keep track of various identifiers within a TCP/IP
686	      implementation are provided by this document [RFC0814].

688	   RFC 816: "Fault Isolation and Recovery" (July 1982)

690	      In this document [RFC0816], TCP's response to indications of
691	      network error conditions such as timeouts or received ICMP
692	      messages is discussed.

694	   RFC 817: "Modularity and Efficiency in Protocol Implementation" (July
695	   1982)

697	      This document [RFC0817] contains implementation suggestions that
698	      are general and not TCP-specific.  However, they have been used to
699	      develop TCP implementations and describe some performance
700	      implications of the interactions between various layers in the
701	      Internet stack.

703	   RFC 872: "TCP-ON-A-LAN" (September 1982)

705	      Conclusion: "The sometimes-expressed fear that using TCP on a
706	      local net is a bad idea is unfounded."  [RFC0872]

708	   RFC 896: "Congestion Control in IP/TCP Internetworks" (January 1984)

710	      This document  [RFC0896] contains some early experiences with
711	      congestion collapse and some initial thoughts on how to avoid it
712	      using congestion control in TCP.

714	   RFC 964: "Some Problems with the Specification of the Military
715	   Standard Transmission Control Protocol" (November 1985)

717	      This document [RFC0964] points out several specification bugs in
718	      the US Military's MIL-STD-1778 document, which was intended as a
719	      successor to RFC 793.  This serves to remind us of the difficulty
720	      in specification writing (even when working from existing
721	      documents!).

723	   RFC 1072: "TCP Extensions for Long-Delay Paths" (October 1988)

725	      This document [RFC1072] contains early explanations of the
726	      mechanisms that were later described by RFCs 1323 and 2018, which
727	      obsolete it.

729	   RFC 1185: "TCP Extension for High-Speed Paths" (October 1990)

731	      This document [RFC1185] builds on RFC 1072 to describe more
732	      advanced strategies for dealing with sequence number wrapping and
733	      detecting duplicates from earlier connections.  This document was
734	      obsoleted by RFC 1323.

736	   RFC 2914 B: "Congestion Control Principles" (September 2000)

738	      This document [RFC2914] motivates the use of end-to-end congestion
739	      control for preventing congestion collapse and providing fairness
740	      to TCP.

742	6.2  Difficult Network Environments

744	   As the internetworking field has explored wireless, satellite,
745	   cellular telephone, and other kinds of link-layer technologies, a
746	   large body of work has built up on enhancing TCP performance for such
747	   links.  The RFCs listed in this section describe some of these more
748	   challenging network environments and how TCP interacts with them.

750	   RFC 2488 B: "Enhancing TCP Over Satellite Channels using Standard
751	   Mechanisms" (January 1999)

753	      From abstract: "While TCP works over satellite channels there are
754	      several IETF standardized mechanisms that enable TCP to more
755	      effectively utilize the available capacity of the network path.
756	      This document outlines some of these TCP mitigations.  At this
757	      time, all mitigations discussed in this document are IETF
758	      standards track mechanisms (or are compliant with IETF
759	      standards)."  [RFC2488]

761	   RFC 2757 I: "Long Thin Networks" (January 2000)

763	      Several methods of improving TCP performance over long thin
764	      networks, such as geosynchronous satellite links, are discussed in
765	      this document [RFC2757].  A particular set of TCP options is
766	      developed that should work well in such environments, and be safe
767	      to use in the global Internet.  The implications of such
768	      environments have been further discussed in RFC 3150 and RFC 3155,
769	      and these documents should be preferred where there is overlap
770	      between them and RFC 2757.

772	   RFC 2760 I: "Ongoing TCP Research Related to Satellites" (February
773	   2000)

775	      This document [RFC2760] discusses the advantages and disadvantages
776	      of several different experimental means of improving TCP
777	      performance over long-delay or error-prone paths.  These include:
778	      T/TCP, larger initial windows, byte counting, delayed
779	      acknowledgements, slow start thresholds, NewReno and SACK-based
780	      loss recovery, FACK [MM96], ECN, various corruption-detection
781	      mechanisms, congestion avoidance changes for fairness, use of
782	      multiple parallel flows, pacing, header compression, state
783	      sharing, and ACK congestion control, filtering, and
784	      reconstruction.  While RFC 2488 looks at standard extensions, this
785	      document focuses on more experimental means of performance
786	      enhancement.

788	   RFC 3135 I: "Performance Enhancing Proxies Intended to Mitigate Link-
789	   Related Degradations" (June 2001)

791	      From abstract: "This document is a survey of Performance Enhancing
792	      Proxies (PEPs) often employed to improve degraded TCP performance
793	      caused by characteristics of specific link environments, for
794	      example, in satellite, wireless WAN, and wireless LAN
795	      environments.  Different types of Performance Enhancing Proxies
796	      are described as well as the mechanisms used to improve
797	      performance."  [RFC3135]

799	   RFC 3150 B: "End-to-end Performance Implications of Slow Links" (July
800	   2001)

802	      From abstract: "This document makes performance-related
803	      recommendations for users of network paths that traverse "very low
804	      bit-rate" links. [...]  This recommendation may be useful in any
805	      network where hosts can saturate available bandwidth, but the
806	      design space for this recommendation explicitly includes
807	      connections that traverse 56 Kb/second modem links or 4.8 Kb/
808	      second wireless access links - both of which are widely deployed."
809	      [RFC3150]

811	   RFC 3155 B: "End-to-end Performance Implications of Links with
812	   Errors" (August 2001)

814	      From abstract: "This document discusses the specific TCP
815	      mechanisms that are problematic in environments with high
816	      uncorrected error rates, and discusses what can be done to
817	      mitigate the problems without introducing intermediate devices
818	      into the connection."  [RFC3155]

820	   RFC 3366 "Advice to link designers on link Automatic Repeat reQuest
821	   (ARQ)" (August 2002)

823	      From abstract: "This document provides advice to the designers of
824	      digital communication equipment and link-layer protocols employing
825	      link-layer Automatic Repeat reQuest (ARQ) techniques.  This
826	      document presumes that the designers wish to support Internet
827	      protocols, but may be unfamiliar with the architecture of the
828	      Internet and with the implications of their design choices for the
829	      performance and efficiency of Internet traffic carried over their
830	      links."  [RFC3366]

832	   RFC 3449 B: "TCP Performance Implications of Network Path Asymmetry"
833	   (December 2002)

835	      From abstract: "This document describes TCP performance problems
836	      that arise because of asymmetric effects.  These problems arise in
837	      several access networks, including bandwidth-asymmetric networks
838	      and packet radio subnetworks, for different underlying reasons.
839	      However, the end result on TCP performance is the same in both
840	      cases: performance often degrades significantly because of
841	      imperfection and variability in the ACK feedback from the receiver
842	      to the sender.

844	      The document details several mitigations to these effects, which
845	      have either been proposed or evaluated in the literature, or are
846	      currently deployed in networks."  [RFC3449]

848	   RFC 3481 B: "TCP over Second (2.5G) and Third (3G) Generation
849	   Wireless Networks" (February 2003)

851	      From abstract: "This document describes a profile for optimizing
852	      TCP to adapt so that it handles paths including second (2.5G) and
853	      third (3G) generation wireless networks."  [RFC3481]

855	   RFC 3819 B: "Advice for Internet Subnetwork Designers" (July 2004)

857	      This document [RFC3819] describes how TCP performance can be
858	      negatively impacted by some particular lower-layer behaviors, and
859	      provides guidance in designing lower-layer networks and protocols
860	      to be amicable to TCP.

862	6.3  Implementation Advice

864	   RFC 879: "The TCP Maximum Segment Size and Related Topics" (November
865	   1983)

867	      Abstract: 'This memo discusses the TCP Maximum Segment Size Option
868	      and related topics.  The purposes is to clarify some aspects of
869	      TCP and its interaction with IP.  This memo is a clarification to
870	      the TCP specification, and contains information that may be
871	      considered as "advice to implementers".'  [RFC0879]

873	   RFC 1071: "Computing the Internet Checksum" (September 1988)

875	      This document [RFC1071] lists a number of implementation
876	      techniques for efficiently computing the Internet checksum (used
877	      by TCP).

879	   RFC 1624 I: "Computation of the Internet Checksum via Incremental
880	   Update" (May 1994)

882	      Incrementally updating the Internet checksum is useful to routers
883	      in updating IP checksums.  Some middleboxes that alter TCP headers
884	      may also be able to incrementally update the TCP checksum.  This
885	      document [RFC1624] expands upon the explanation of the incremental
886	      update proceedure in RFC 1071.

888	   RFC 1936 I: "Implementing the Internet Checksum in Hardware" (April
889	   1996)

891	      This document [RFC1936] describes the motivation for implementing
892	      the Internet checksum in hardware, rather than software, and
893	      provides an example implementation.

895	   RFC 2525 I: "Known TCP Implementation Problems" (March 1999)

897	      From abstract: "This memo catalogs a number of known TCP
898	      implementation problems.  The goal in doing so is to improve
899	      conditions in the existing Internet by enhancing the quality of
900	      current TCP/IP implementations."  [RFC2525]

902	   RFC 2923 I: "TCP Problems with Path MTU Discovery" (September 2000)

904	      From abstract: "This memo catalogs several known Transmission
905	      Control Protocol (TCP) implementation problems dealing with Path
906	      Maximum Transmission Unit Discovery (PMTUD), including the long-
907	      standing black hole problem, stretch acknowlegements (ACKs) due to
908	      confusion between Maximum Segment Size (MSS) and segment size, and
909	      MSS advertisement based on PMTU."  [RFC2923]

911	   RFC 3360 B: "Inappropriate TCP Resets Considered Harmful" (August
912	   2002)

914	      This document [RFC3360] is a plea that firewall vendors not send
915	      gratuitous TCP RST (Reset) packets when unassigned TCP header bits
916	      are used.  This practice prevents desirable extension and
917	      evolution of the protocol and hence is potentially harmful to the
918	      future of the Internet.

920	   RFC 3493 I: "Basic Socket Interface Extensions for IPv6" (February
921	   2003)

923	      This document [RFC3493] describes the de facto standard sockets
924	      API for programming with TCP.  This API is implemented nearly
925	      ubiquitously in modern operating systems and programming
926	      languages.

928	6.4  Management Information Bases

930	   The first MIB module defined for use with SNMP (in RFC 1066 and its
931	   update, RFC 1156) was a single monolithic MIB module, called MIB-I.
932	   This evolved over time to be MIB-II (RFC 1213).  It then became
933	   apparent that having a single monolithic MIB module was not scalable,
934	   given the number and breadth of MIB data definitions that needed to
935	   be included.  Thus, additional MIB modules were defined, and those
936	   parts of MIB-II which needed to evolve were split off.  Eventually,
937	   the remaining parts of MIB-II were also split off, with the TCP-
938	   specific part being documented in RFC 2012.

940	   RFC 2012 was obsoleted by RFC 4022, which is the primary TCP MIB
941	   document today.  MIB-I, defined in RFC 1156, has been obsoleted by
942	   the MIB-II specification in RFC 1213.  For current TCP implementers,
943	   RFC 4022 should be supported.

945	   RFC 1066: "Management Information Base for Network Management of TCP/
946	   IP-based Internets" (August 1988)

948	      This document [RFC1066] was the description of the TCP MIB.  It
949	      was obsoleted by RFC 1156.

951	   RFC 1156 S: "Management Information Base for Network Management of
952	   TCP/IP-based Internets" (May 1990)

954	      This document [RFC1156] describes the required MIB fields for TCP
955	      implementations, with minor corrections and no technical changes
956	      from RFC 1066, which it obsoletes.  This is the standards track
957	      document for MIB-I.

959	   RFC 1213 S: "Management Information Base for Network Management of
960	   TCP/IP-based Internets: MIB-II" (March 1991)

962	      This document [RFC1213] describes the second version of the MIB in
963	      a monolithic form.  RFC 2012 updates this document by splitting
964	      out the TCP-specific portions.

966	   RFC 2012 S: "SNMPv2 Management Information Base for the  Transmission
967	   Control Protocol using SMIv2" (November 1996)
968	      This document [RFC2012] defined the TCP MIB, in an update to RFC
969	      1213.  It is now obsoleted by RFC 4022.

971	   RFC 2452 S: "IP Version 6 Management Information Base for the
972	   Transmission Control Protocol" (December 1998)

974	      This document [RFC2452] augments RFC 2012 by adding an IPv6-
975	      specific connection table.  The rest of 2012 holds for any IP
976	      version.

978	      Although it is a standards track document, RFC 2452 is considered
979	      a historic mistake by the MIB community, as it is based on the
980	      idea of parallel IPv4 and IPv6 structures.  Although IPv6 requires
981	      new structures, the community has decided to define a single
982	      generic structure for both IPv4 and IPv6.  This will aid in
983	      definition, implementation, and transition between IPv4 and IPv6.

985	   RFC 4022 S: "Management Information Base for the Transmission Control
986	   Protocol (TCP)" (March 2005)

988	      This document [RFC4022] obsoletes RFC 2012 and RFC 2452, and
989	      specifies the current standard for the TCP MIB that should be
990	      deployed.

992	6.5  Tools and Tutorials

994	   RFC 1180 I: "TCP/IP Tutorial" (January 1991)

996	      This document [RFC1180] is an extremely brief overview of the
997	      TCP/IP protocol suite as a whole.  It gives some explanation as to
998	      how and where TCP fits in.

1000	   RFC 1470 I: "FYI on a Network Management Tool Catalog: Tools for
1001	   Monitoring and Debugging TCP/IP Internets and Interconnected Devices"
1002	   (June 1993)

1004	      A few of the tools that this document [RFC1470] describes are
1005	      still maintained and in use today, for example ttcp and tcpdump.
1006	      However, many of the tools described do not relate specifically to
1007	      TCP and are no longer used or easily available.

1009	   RFC 2398 I: "Some Testing Tools for TCP Implementors" (August 1998)

1011	      This document  [RFC2398] describes a number of TCP packet
1012	      generation and analysis tools.  While some of these tools are no
1013	      longer readily available or widely used, for the most part they
1014	      are still relevant and useable.

1016	6.6  Case Studies

1018	   RFC 1337 I: "TIME-WAIT Assassination Hazards in TCP" (May 1992)

1020	      This document [RFC1337] points out a problem with acting on
1021	      received reset segments while in the TIME-WAIT state.  The main
1022	      recommendation is that hosts in TIME-WAIT ignore resets.  This
1023	      recommendation might not currently be widely implemented.

1025	   RFC 2415 I: "Simulation Studies of Increased Initial TCP Window Size"
1026	   (September 1998)

1028	      This document [RFC2415] presents results of some simulations using
1029	      TCP initial windows greater than 1 segment.  The analysis
1030	      indicates that user-perceived performance can be improved by
1031	      increasing the initial window to 3 segments.

1033	   RFC 2416 I: "When TCP Starts Up With Four Packets Into Only Three
1034	   Buffers" (September 1998)

1036	      This document [RFC2416] uses simulation results to clear up some
1037	      concerns about using an initial window of 4 segments when the
1038	      network path has less provisioning.

1040	   RFC 2884 I: "Performance Evaluation of Explicit Congestion
1041	   Notification (ECN) in IP Networks" (July 2000)

1043	      This document [RFC2884] describes experimental results that show
1044	      some improvements to the performance of both short and long-lived
1045	      connections due to ECN.

1047	7.  Undocumented TCP Features

1049	   There are a few important implementation tactics for the TCP that
1050	   have not yet been described in any RFC.  Although this roadmap is
1051	   primarily concerned with mapping the TCP RFCs, this section is
1052	   included because an implementer needs to be aware of these important
1053	   issues.

1055	   SYN Cookies

1057	      A mechanism known as "SYN cookies" is widely used to thwart TCP
1058	      SYN flooding attacks, in which an attacker sends a flood of SYNs
1059	      to a victim but fails to complete the 3-way handshake.  The result
1060	      is exhaustion of resources at the server.  The SYN cookie
1061	      mechanism allows the server to return a cleverly-chosen initial
1062	      sequence number that has all the required state for the secure
1063	      completion of the handshake.  Then the server can avoid saving
1064	      connection state during the 3-way handshake and thus survive a SYN
1065	      flooding attack.

1067	      A web search for "SYN cookies" will reveal a number of useful
1068	      descriptions of this mechanism, although there is currently no RFC
1069	      on the matter.

1071	   Header Prediction

1073	      Header prediction is a trick to speed up the processing of
1074	      segments.  Van Jacobson and Mike Karels developed the technique in
1075	      the late 1980s.  The basic idea is that some processing time can
1076	      be saved when most of a segment's fields can be predicted from
1077	      previous segments.  A good description of this was sent to the
1078	      TCP-IP mailing list by Van Jacobson on March 9, 1988:

1080	         Quite a bit of the speedup comes from an algorithm that we
1081	         ('we' refers to collaborator Mike Karels and myself) are
1082	         calling "header prediction".  The idea is that if you're in the
1083	         middle of a bulk data transfer and have just seen a packet, you
1084	         know what the next packet is going to look like:  It will look
1085	         just like the current packet with either the sequence number or
1086	         ack number updated (depending on whether you're the sender or
1087	         receiver).  Combining this with the "Use hints" epigram from
1088	         Butler Lampson's classic "Epigrams for System Designers", you
1089	         start to think of the tcp state (rcv.nxt, snd.una, etc.) as
1090	         "hints" about what the next packet should look like.

1092	         If you arrange those "hints" so they match the layout of a tcp
1093	         packet header, it takes a single 14-byte compare to see if your
1094	         prediction is correct (3 longword compares to pick up the send
1095	         & ack sequence numbers, header length, flags and window, plus a
1096	         short compare on the length).  If the prediction is correct,
1097	         there's a single test on the length to see if you're the sender
1098	         or receiver followed by the appropriate processing.  E.g., if
1099	         the length is non-zero (you're the receiver), checksum and
1100	         append the data to the socket buffer then wake any process
1101	         that's sleeping on the buffer.  Update rcv.nxt by the length of
1102	         this packet (this updates your "prediction" of the next
1103	         packet).  Check if you can handle another packet the same size
1104	         as the current one.  If not, set one of the unused flag bits in
1105	         your header prediction to guarantee that the prediction will
1106	         fail on the next packet and force you to go through full
1107	         protocol processing.  Otherwise, you're done with this packet.
1108	         So, the *total* tcp protocol processing, exclusive of
1109	         checksumming, is on the order of 6 compares and an add.

1111	8.  Security Considerations

1113	   This document introduces no new security considerations.  Each RFC
1114	   listed in this document attempts to address the security
1115	   considerations of the specification it contains.

1117	9.  IANA Considerations

1119	   This document contains no IANA considerations.

1121	10.  Acknowledgments

1123	   This document grew out of a discussion on the end2end-interest
1124	   mailing list, the public list of the End-to-End Research Group of the
1125	   IRTF, and continued development under the IETF's TCP Maintenance and
1126	   Minor Extensions (TCPM) working group.  We thank Joe Touch, Reiner
1127	   Ludwig, Pekka Savola, Gorry Fairhurst, and Sally Floyd for their
1128	   contributions, in particular.  The chairs of the TCPM working group,
1129	   Mark Allman and Ted Faber, have been instrumental in the development
1130	   of this document.  Keith McCloghrie provided some useful notes and
1131	   clarification on the various MIB-related RFCs.

1133	11.  Informative References

1135	11.1  Basic Functionality

1137	   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
1138	              RFC 793, September 1981.

1140	   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
1141	              Communication Layers", STD 3, RFC 1122, October 1989.

1143	   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
1144	              3", BCP 9, RFC 2026, October 1996.

1146	   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
1147	              (IPv6) Specification", RFC 2460, December 1998.

1149	   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
1150	              "Definition of the Differentiated Services Field (DS
1151	              Field) in the IPv4 and IPv6 Headers", RFC 2474,
1152	              December 1998.

1154	   [RFC2581]  Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
1155	              Control", RFC 2581, April 1999.

1157	   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
1158	              RFC 2675, August 1999.

1160	   [RFC2873]  Xiao, X., Hannan, A., Paxson, V., and E. Crabbe, "TCP
1161	              Processing of the IPv4 Precedence Field", RFC 2873,
1162	              June 2000.

1164	   [RFC2988]  Paxson, V. and M. Allman, "Computing TCP's Retransmission
1165	              Timer", RFC 2988, November 2000.

1167	11.2  Recommended Enhancements

1169	   [RFC1323]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
1170	              for High Performance", RFC 1323, May 1992.

1172	   [RFC1948]  Bellovin, S., "Defending Against Sequence Number Attacks",
1173	              RFC 1948, May 1996.

1175	   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
1176	              Selective Acknowledgment Options", RFC 2018, October 1996.

1178	   [RFC2385]  Heffernan, A., "Protection of BGP Sessions via the TCP MD5
1179	              Signature Option", RFC 2385, August 1998.

1181	   [RFC2883]  Floyd, S., Mahdavi, J., Mathis, M., and M. Podolsky, "An
1182	              Extension to the Selective Acknowledgement (SACK) Option
1183	              for TCP", RFC 2883, July 2000.

1185	   [RFC3042]  Allman, M., Balakrishnan, H., and S. Floyd, "Enhancing
1186	              TCP's Loss Recovery Using Limited Transmit", RFC 3042,
1187	              January 2001.

1189	   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
1190	              of Explicit Congestion Notification (ECN) to IP",
1191	              RFC 3168, September 2001.

1193	   [RFC3390]  Allman, M., Floyd, S., and C. Partridge, "Increasing TCP's
1194	              Initial Window", RFC 3390, October 2002.

1196	   [RFC3517]  Blanton, E., Allman, M., Fall, K., and L. Wang, "A
1197	              Conservative Selective Acknowledgment (SACK)-based Loss
1198	              Recovery Algorithm for TCP", RFC 3517, April 2003.

1200	   [RFC3562]  Leech, M., "Key Management Considerations for the TCP MD5
1201	              Signature Option", RFC 3562, July 2003.

1203	   [RFC3782]  Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
1204	              Modification to TCP's Fast Recovery Algorithm", RFC 3782,
1205	              April 2004.

1207	   [RFC4015]  Ludwig, R. and A. Gurtov, "The Eifel Response Algorithm
1208	              for TCP", RFC 4015, February 2005.

1210	   [tcpmd5app]
1211	              Bellovin, S. and A. Zinin, "Standards Maturity Variance
1212	              Regarding the TCP MD5 Signature Option (RFC 2385) and the
1213	              BGP-4 Specification", (draft-iesg-tcpmd5app-01 in RFC
1214	              Editor queue), September 2004.

1216	11.3  Experimental Extensions

1218	   [RFC2140]  Touch, J., "TCP Control Block Interdependence", RFC 2140,
1219	              April 1997.

1221	   [RFC2861]  Handley, M., Padhye, J., and S. Floyd, "TCP Congestion
1222	              Window Validation", RFC 2861, June 2000.

1224	   [RFC3124]  Balakrishnan, H. and S. Seshan, "The Congestion Manager",
1225	              RFC 3124, June 2001.

1227	   [RFC3465]  Allman, M., "TCP Congestion Control with Appropriate Byte
1228	              Counting (ABC)", RFC 3465, February 2003.

1230	   [RFC3522]  Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm
1231	              for TCP", RFC 3522, April 2003.

1233	   [RFC3540]  Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
1234	              Congestion Notification (ECN) Signaling with Nonces",
1235	              RFC 3540, June 2003.

1237	   [RFC3649]  Floyd, S., "HighSpeed TCP for Large Congestion Windows",
1238	              RFC 3649, December 2003.

1240	   [RFC3708]  Blanton, E. and M. Allman, "Using TCP Duplicate Selective
1241	              Acknowledgement (DSACKs) and Stream Control Transmission
1242	              Protocol (SCTP) Duplicate Transmission Sequence Numbers
1243	              (TSNs) to Detect Spurious Retransmissions", RFC 3708,
1244	              February 2004.

1246	   [RFC3742]  Floyd, S., "Limited Slow-Start for TCP with Large
1247	              Congestion Windows", RFC 3742, March 2004.

1249	   [RFC4138]  Sarolahti, P. and M. Kojo, "Forward RTO-Recovery (F-RTO):
1250	              An Algorithm for Detecting Spurious Retransmission
1251	              Timeouts with TCP and the Stream Control Transmission
1252	              Protocol (SCTP)", RFC 4138.

1254	11.4  Historic Extensions

1256	   [RFC1106]  Fox, R., "TCP big window and NAK options", RFC 1106,
1257	              June 1989.

1259	   [RFC1110]  McKenzie, A., "Problem with the TCP big window option",
1260	              RFC 1110, August 1989.

1262	   [RFC1146]  Zweig, J. and C. Partridge, "TCP alternate checksum
1263	              options", RFC 1146, March 1990.

1265	   [RFC1263]  O'Malley, S. and L. Peterson, "TCP Extensions Considered
1266	              Harmful", RFC 1263, October 1991.

1268	   [RFC1379]  Braden, B., "Extending TCP for Transactions -- Concepts",
1269	              RFC 1379, November 1992.

1271	   [RFC1644]  Braden, B., "T/TCP -- TCP Extensions for Transactions
1272	              Functional Specification", RFC 1644, July 1994.

1274	   [RFC1693]  Connolly, T., Amer, P., and P. Conrad, "An Extension to
1275	              TCP : Partial Order Service", RFC 1693, November 1994.

1277	11.5  Support Documents

1279	   [RFC0813]  Clark, D., "Window and Acknowledgement Strategy in TCP",
1280	              RFC 813, July 1982.

1282	   [RFC0814]  Clark, D., "Name, addresses, ports, and routes", RFC 814,
1283	              July 1982.

1285	   [RFC0816]  Clark, D., "Fault isolation and recovery", RFC 816,
1286	              July 1982.

1288	   [RFC0817]  Clark, D., "Modularity and efficiency in protocol
1289	              implementation", RFC 817, July 1982.

1291	   [RFC0872]  Padlipsky, M., "TCP-on-a-LAN", RFC 872, September 1982.

1293	   [RFC0879]  Postel, J., "TCP maximum segment size and related topics",
1294	              RFC 879, November 1983.

1296	   [RFC0896]  Nagle, J., "Congestion control in IP/TCP internetworks",
1297	              RFC 896, January 1984.

1299	   [RFC0964]  Sidhu, D. and T. Blumer, "Some problems with the
1300	              specification of the Military Standard Transmission
1301	              Control Protocol", RFC 964, November 1985.

1303	   [RFC1066]  McCloghrie, K. and M. Rose, "Management Information Base
1304	              for network management of TCP/IP-based internets",
1305	              RFC 1066, August 1988.

1307	   [RFC1071]  Braden, R., Borman, D., Partridge, C., and W. Plummer,
1308	              "Computing the Internet checksum", RFC 1071,
1309	              September 1988.

1311	   [RFC1072]  Jacobson, V. and R. Braden, "TCP extensions for long-delay
1312	              paths", RFC 1072, October 1988.

1314	   [RFC1156]  McCloghrie, K. and M. Rose, "Management Information Base
1315	              for network management of TCP/IP-based internets",
1316	              RFC 1156, May 1990.

1318	   [RFC1180]  Socolofsky, T. and C. Kale, "TCP/IP tutorial", RFC 1180,
1319	              January 1991.

1321	   [RFC1185]  Jacobson, V., Braden, B., and L. Zhang, "TCP Extension for
1322	              High-Speed Paths", RFC 1185, October 1990.

1324	   [RFC1213]  McCloghrie, K. and M. Rose, "Management Information Base
1325	              for Network Management of TCP/IP-based internets:MIB-II",
1326	              STD 17, RFC 1213, March 1991.

1328	   [RFC1337]  Braden, B., "TIME-WAIT Assassination Hazards in TCP",
1329	              RFC 1337, May 1992.

1331	   [RFC1470]  Enger, R. and J. Reynolds, "FYI on a Network Management
1332	              Tool Catalog: Tools for Monitoring and Debugging TCP/IP
1333	              Internets and Interconnected Devices", RFC 1470,
1334	              June 1993.

1336	   [RFC1624]  Rijsinghani, A., "Computation of the Internet Checksum via
1337	              Incremental Update", RFC 1624, May 1994.

1339	   [RFC1936]  Touch, J. and B. Parham, "Implementing the Internet
1340	              Checksum in Hardware", RFC 1936, April 1996.

1342	   [RFC2012]  McCloghrie, K., "SNMPv2 Management Information Base for
1343	              the Transmission Control Protocol using SMIv2", RFC 2012,
1344	              November 1996.

1346	   [RFC2398]  Parker, S. and C. Schmechel, "Some Testing Tools for TCP
1347	              Implementors", RFC 2398, August 1998.

1349	   [RFC2415]  Poduri, K., "Simulation Studies of Increased Initial TCP
1350	              Window Size", RFC 2415, September 1998.

1352	   [RFC2416]  Shepard, T. and C. Partridge, "When TCP Starts Up With
1353	              Four Packets Into Only Three Buffers", RFC 2416,
1354	              September 1998.

1356	   [RFC2452]  Daniele, M., "IP Version 6 Management Information Base for
1357	              the Transmission Control Protocol", RFC 2452,
1358	              December 1998.

1360	   [RFC2488]  Allman, M., Glover, D., and L. Sanchez, "Enhancing TCP
1361	              Over Satellite Channels using Standard Mechanisms",
1362	              BCP 28, RFC 2488, January 1999.

1364	   [RFC2525]  Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
1365	              J., Heavens, I., Lahey, K., Semke, J., and B. Volz, "Known
1366	              TCP Implementation Problems", RFC 2525, March 1999.

1368	   [RFC2757]  Montenegro, G., Dawkins, S., Kojo, M., Magret, V., and N.
1369	              Vaidya, "Long Thin Networks", RFC 2757, January 2000.

1371	   [RFC2760]  Allman, M., Dawkins, S., Glover, D., Griner, J., Tran, D.,
1372	              Henderson, T., Heidemann, J., Touch, J., Kruse, H.,
1373	              Ostermann, S., Scott, K., and J. Semke, "Ongoing TCP
1374	              Research Related to Satellites", RFC 2760, February 2000.

1376	   [RFC2884]  Hadi Salim, J. and U. Ahmed, "Performance Evaluation of
1377	              Explicit Congestion Notification (ECN) in IP Networks",
1378	              RFC 2884, July 2000.

1380	   [RFC2914]  Floyd, S., "Congestion Control Principles", BCP 41,
1381	              RFC 2914, September 2000.

1383	   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery",
1384	              RFC 2923, September 2000.

1386	   [RFC3135]  Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
1387	              Shelby, "Performance Enhancing Proxies Intended to
1388	              Mitigate Link-Related Degradations", RFC 3135, June 2001.

1390	   [RFC3150]  Dawkins, S., Montenegro, G., Kojo, M., and V. Magret,
1391	              "End-to-end Performance Implications of Slow Links",
1392	              BCP 48, RFC 3150, July 2001.

1394	   [RFC3155]  Dawkins, S., Montenegro, G., Kojo, M., Magret, V., and N.
1395	              Vaidya, "End-to-end Performance Implications of Links with
1396	              Errors", BCP 50, RFC 3155, August 2001.

1398	   [RFC3360]  Floyd, S., "Inappropriate TCP Resets Considered Harmful",
1399	              BCP 60, RFC 3360, August 2002.

1401	   [RFC3366]  Fairhurst, G. and L. Wood, "Advice to link designers on
1402	              link Automatic Repeat reQuest (ARQ)", BCP 62, RFC 3366,
1403	              August 2002.

1405	   [RFC3449]  Balakrishnan, H., Padmanabhan, V., Fairhurst, G., and M.
1406	              Sooriyabandara, "TCP Performance Implications of Network
1407	              Path Asymmetry", BCP 69, RFC 3449, December 2002.

1409	   [RFC3481]  Inamura, H., Montenegro, G., Ludwig, R., Gurtov, A., and
1410	              F. Khafizov, "TCP over Second (2.5G) and Third (3G)
1411	              Generation Wireless Networks", BCP 71, RFC 3481,
1412	              February 2003.

1414	   [RFC3493]  Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
1415	              Stevens, "Basic Socket Interface Extensions for IPv6",
1416	              RFC 3493, February 2003.

1418	   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
1419	              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
1420	              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
1421	              RFC 3819, July 2004.

1423	   [RFC4022]  Raghunarayan, R., "Management Information Base for the
1424	              Transmission Control Protocol (TCP)", RFC 4022,
1425	              March 2005.

1427	11.6  Informative References Outside the RFC Series

1429	   [JK92]    Jacobson, V. and M. Karels, "Congestion Avoidance and
1430	             Control", This paper is a revised version of [Jac88], that
1431	             includes an additional appendix.  This paper has not been
1432	             traditionally published, but is currently available at
1433	             ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z. 1992.

1435	   [Jac88]   Jacobson, V., "Congestion Avoidance and Control", ACM
1436	             SIGCOMM 1988 Proceedings, in ACM Computer Communication
1437	             Review, 18 (4), pp. 314-329, August 1988.

1439	   [KP87]    Karn, P. and C. Partridge, "Round Trip Time Estimation",
1440	             ACM SIGCOMM 1987 Proceedings, in ACM Computer Communication
1441	             Review, 17 (5), pp. 2-7, August 1987.

1443	   [MAF04]   Medina, A., Allman, M., and S. Floyd, "Measuring the
1444	             Evolution of Transport Protocols in the Internet", ACM
1445	             Computer Communication Review, 35 (2), April 2005.

1447	   [MM96]    Mathis, M. and J. Mahdavi, "Forward Acknowledgement:
1448	             Refining TCP Congestion Control", ACM SIGCOMM 1996
1449	             Proceedings, in ACM Computer Communication Review 26 (4),
1450	             pp. 281-292, October 1996.

1452	   [SCWA99]  Savage, S., Cardwell, N., Wetherall, D., and T. Anderson,
1453	             "TCP Congestion Control with a Misbehaving Receiver", ACM
1454	             Computer Communication Review, 29 (5), pp. 71-78,
1455	             October 1999.

1457	Authors' Addresses

1459	   Martin Duke
1460	   Boeing Phantom Works
1461	   PO Box 3707, MC 7L-49
1462	   Seattle, WA  98124-2207

1464	   Phone: 425-865-1182
1465	   Email: martin.duke@boeing.com
1466	   Robert Braden
1467	   USC Information Sciences Institute
1468	   Marina del Rey, CA  90292-6695

1470	   Phone: 310-448-9173
1471	   Email: braden@isi.edu

1473	   Wesley M. Eddy
1474	   Verizon Federal Network Systems
1475	   21000 Brookpark Rd, MS 54-5
1476	   Cleveland, OH  44135

1478	   Phone: 216-433-6682
1479	   Email: weddy@grc.nasa.gov

1481	   Ethan Blanton
1482	   Purdue University Computer Science
1483	   250 N. University St.
1484	   West Lafayette, IN  47907

1486	   Email: eblanton@cs.purdue.edu

1488	Intellectual Property Statement

1490	   The IETF takes no position regarding the validity or scope of any
1491	   Intellectual Property Rights or other rights that might be claimed to
1492	   pertain to the implementation or use of the technology described in
1493	   this document or the extent to which any license under such rights
1494	   might or might not be available; nor does it represent that it has
1495	   made any independent effort to identify any such rights.  Information
1496	   on the procedures with respect to rights in RFC documents can be
1497	   found in BCP 78 and BCP 79.

1499	   Copies of IPR disclosures made to the IETF Secretariat and any
1500	   assurances of licenses to be made available, or the result of an
1501	   attempt made to obtain a general license or permission for the use of
1502	   such proprietary rights by implementers or users of this
1503	   specification can be obtained from the IETF on-line IPR repository at
1504	   http://www.ietf.org/ipr.

1506	   The IETF invites any interested party to bring to its attention any
1507	   copyrights, patents or patent applications, or other proprietary
1508	   rights that may cover technology that may be required to implement
1509	   this standard.  Please address the information to the IETF at
1510	   ietf-ipr@ietf.org.

1512	Disclaimer of Validity

1514	   This document and the information contained herein are provided on an
1515	   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1516	   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1517	   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1518	   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1519	   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1520	   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

1522	Copyright Statement

1524	   Copyright (C) The Internet Society (2006).  This document is subject
1525	   to the rights, licenses and restrictions contained in BCP 78, and
1526	   except as set forth therein, the authors retain all their rights.

1528	Acknowledgment

1530	   Funding for the RFC Editor function is currently provided by the
1531	   Internet Society.