[e2e] My version of your list...

[Duke, Martin]

Aside from a couple of typos, I am comfortable with using this version
as the basis for future corrections.

A couple of comments:

1) If one purpose is to call attention to those protocols whose status
ought to be updated, I think consolidating "Standard" and "Proposed
Standard" into one letter code obscures important information.  If 1323,
for example, is a de facto standard, then by all means let's list it as
a "core specification" but accurately depict its current official status
in the IETF as "P", as a clue that someone ought to promote to a
Standard.

2) I'm increasingly uncomfortable with the "Experimental or Deprecated
Extensions" category.  I think it should be split into those that are
dead and those very much alive.  Perhaps "Experimental Extensions"
defined as extensions that may one day become standards and "Deprecated
Extensions" as those that we have a consensus will not be.
  I could use everyone's help in making these distinctions, as I am less
than fully familiar with several of them.

Draft with these suggestions follows, although I am likely to make a few
errors as indicated.

Martin



-----Original Message-----
From: Bob Braden [mailto:braden at ISI.EDU] 
Sent: Friday, September 19, 2003 2:33 PM
To: end2end-interest at postel.org; Duke, Martin
Cc: braden at ISI.EDU
Subject: [e2e] My version of your list...



Summary of TCP RFCs


(I see LOTS of controversy lurking here...)

Bob Braden

________________________________________________________________


I. INTRODUCTION

This Document provides a roadmp to the Requests for Comment (RFC)
documents relating to TCP.

The intent of this document is twofold.  First, it provides a brief
summary of the relevant RFC documents that summarize the "state" of TCP.
Second, it is a snapshot of the current status of these proposals so
that the community at large can more easily initiate action to update
the status of old RFCs.


Each RFC number has a letter code after it indicating its category in
the RFC series.
	S - Standards-track
	E - Experimental
	B - Best Current Practice
	I - Informational

The status of each RFC does not necessarily reflect how it is
categorized below.  For instance, even though RFC 2581 is a "Proposed
Standard," it is virtually universally employed, and TCP proposals are
informally expected to show that they are fair to the congestion control
mechanism explained it.  Also, some "Informational" RFCs actually
contain proposals about ways to change TCP.


II. CORE SPECIFICATION

0793S "Transmission Control Protocol" (Sep 81): The core document that
describes the semantics of data transmission, reliability, flow control,
multiplexing, acknowledgement, precedence, and security.

1122S "Requirements for Internet Hosts - Communication Layers" (Oct 89):
update and clarification of RFC 793.

1213S "Management Information Base for Network Management of
TCP/IP-based internets:MIB-II" (Mar 91): the data fields that a TCP
implementation is required to keep track of.

1323S "TCP Extensions for High Performance" (May 92): introduces window
scaling, timestamps, and protection against wrapped sequence numbers for
long, fat pipes.  Implemented in Linux and BSD; a non-default option in
Windows.

2012S "SNMPv2 Management Information Base for the Transmission Control
Protocol using SMIv2" (Nov 96): an extension to the MIB to support IPv6.

2018S "TCP Selective Acknowledgement Options" (Oct 96): introduces SACK.

2452S "IP Version 6 Management Information Base for the Transmission
Control Protocol" (Dec 98): further MIB extensions for IPv6.

2873S "TCP Processing of the IPv4 Precendence Field" (Jun 00):  resolves
a conflict between different uses of bits in the IP header.

2581S "TCP Congestion Control" (Apr 99): Latest version of standards in
sender rate control.

2883S "An Extension to the Selective Acknowledgement (SACK) Option for
TCP" (Jul 00): introduces the concept of duplicate SACK.

2988S "Computing TCP's Retransmission Timer" (Nov 00): specifies
algorithm for computing the RTO.

3042S "Enhancing TCP's Loss Recovery Using Limited Transmit" (Jan 01): a
means of avoiding coarse timeouts when the window is small.

3168P "The Addition of Explicit Congestion Notification (ECN) to IP"
(Sep 01): a means of detecting congestion without resorting to loss.

3390S "Increasing TCP'S Initial Window" (Oct 02): starts with a larger
window, given larger modern bandwidths.

3517P "A Conservative Selective Acknowledgement (SACK)-based Loss
Recovery Algorithm for TCP" (Apr 03): tweaks the response to SACK.


III. IMPLEMENTATION SUGGESTIONS

3493I "Basic Socket Interface Extensions for IPv6" (Feb 03)

2525I "Known TCP Implementation Problems" (Mar 99)

3155B "End-to-end Performance Implications of Links with Errors" (Aug
01)

3360B "Inappropriate TCP Resets Considered Harmful" (Aug 02)

3449B "TCP Performance Implications of Network Path Asymmetry" (Dec 02)


IV. SPECIAL CASES

1144P "Compressing TCP/IP headers for low-speed serial links" (Feb 90):
not many people have this problem anymore.

2488B "Enhancing TCP Over Satellite Channels using Standard Mechanisms
(Jan 99)

3481B "TCP over Second (2.5G) and Third (3G) Generation Wireless
Networks" (Feb 03)


V. EXPERIMENTAL OR DEPRECATED EXTENSIONS

Not recommended for general implementation at this time.

1146E "TCP alternate checksum options" (Mar 90): for those who insist
that the standard checksum algorithm is insufficiently robust.

1379I "Extending TCP for Transactions -- Concepts" (Nov 92)

1644E "T/TCP -- TCP Extensions for Transactions Functional
Specification" (Jul 94)

1693E "An Extension to TCP: Partial Order Service" (Nov 94): for
applications where total reliability isn't necessary.

2140I "TCP Control Block Interdependence" (Apr 97): enables TCP
connections to share information.  Partially implemented in Linux.

2582E "The NewReno Modification to TCP's Fast Recovery Algorithm" (Apr
99): tweaks to congestion control.

2861E "TCP Congestion Window Validation" (Jun 00): decays congestion
window if it hasn't been recently utilized.

3465E "TCP Congestion Control with Appropriate Byte Counting (ABC)" (Feb
03): congestion control uses number of bytes acknowledged rather than
number of acknowledgements received.  Implemented in Linux.

3522E "The Eifel Detection Algorithm for TCP" (Apr 03): uses timestamps
to detect spurious timeouts.

3540E "Robust Explicit Congestion Notificaiton (ECN) signaling with
Nonces" (Jun 03): re-introduces ECN with security concerns addressed.


VI. CASE STUDIES AND PROTOCOL ANALYSIS

1337I "TIME-WAIT Assassination Hazards in TCP" (May 92): resolves some
bad corner cases at connection close.

2415I "Simulation Studies of Increased Initial TCP Window Size" (Sep 98)

2416I "When TCP Starts Up With Four Packets Into Only Three Buffers"
(Sep 98)

2760I "Ongoing TCP Research Related to Satellites" (Feb 00)

2884I "Performance Evaluation of Explicit Congestion Notification (ECN)
in IP Networks" (Jul 00)

2923I "TCP Problems with Path MTU Discovery" (Sep 00)

2963I "A Rate Adaptive Shaper for Differentiated Services" (Oct 2000):
optimizing TCP performance in the presence of a DiffServ scheme.

3135I "Performance Enhancing Proxies Intended to Mitigate Link-Related
Degradations" (Jun 01)


VII. TOOLS AND TUTORIALS

1180I "TCP/IP tutorial" (Jan 91): the basics

1470I "FYI on a Network Management Tool Catalog: Tools for Monitoring
and Debugging TCP/IP Internets and Interconnected Devices" (Jun 93)

2151I "A Primer on Internet and TCP/IP Tools and Utilities" (Jun 97)

2398I "Some Testing Tools for TCP Implementors" (Aug 98)