TCP Extensions Considered Harmful
RFC 1263

Document Type RFC - Informational (October 1991; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1263 (Informational)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                        S. O'Malley
Request for Comments: 1263                                   L. Peterson
                                                   University of Arizona
                                                            October 1991

                   TCP EXTENSIONS CONSIDERED HARMFUL

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard.  Distribution of this document is
   unlimited.

Abstract

   This RFC comments on recent proposals to extend TCP.  It argues that
   the backward compatible extensions proposed in RFC's 1072 and 1185
   should not be pursued, and proposes an alternative way to evolve the
   Internet protocol suite.  Its purpose is to stimulate discussion in
   the Internet community.

1.  Introduction

   The rapid growth of the size, capacity, and complexity of the
   Internet has led to the need to change the existing protocol suite.
   For example, the maximum TCP window size is no longer sufficient to
   efficiently support the high capacity links currently being planned
   and constructed. One is then faced with the choice of either leaving
   the protocol alone and accepting the fact that TCP will run no faster
   on high capacity links than on low capacity links, or changing TCP.
   This is not an isolated incident. We have counted at least eight
   other proposed changes to TCP (some to be taken more seriously than
   others), and the question is not whether to change the protocol
   suite, but what is the most cost effective way to change it.

   This RFC compares the costs and benefits of three approaches to
   making these changes: the creation of new protocols, backward
   compatible protocol extensions, and protocol evolution. The next
   section introduces these three approaches and enumerates the
   strengths and weaknesses of each.  The following section describes
   how we believe these three approaches are best applied to the many
   proposed changes to TCP. Note that we have not written this RFC as an
   academic exercise.  It is our intent to argue against acceptance of
   the various TCP extensions, most notably RFC's 1072 and 1185 [4,5],
   by describing a more palatable alternative.

O'Malley & Peterson                                             [Page 1]
RFC 1263           TCP Extensions Considered Harmful        October 1991

2.  Creation vs. Extension vs. Evolution

2.1.  Protocol Creation

   Protocol creation involves the design, implementation,
   standardization, and distribution of an entirely new protocol. In
   this context, there are two basic reasons for creating a new
   protocol. The first is to replace an old protocol that is so outdated
   that it can no longer be effectively extended to perform its original
   function.  The second is to add a new protocol because users are
   making demands upon the original protocol that were not envisioned by
   the designer and cannot be efficiently handled in terms of the
   original protocol.  For example, TCP was designed as a reliable
   byte-stream protocol but is commonly used as both a reliable record-
   stream protocol and a reliable request-reply protocol due to the lack
   of such protocols in the Internet protocol suite.  The performance
   demands placed upon a byte-stream protocol in the new Internet
   environment makes it difficult to extend TCP to meet these new
   application demands.

   The advantage of creating a new protocol is the ability to start with
   a clean sheet of paper when attempting to solve a complex network
   problem.  The designer, free from the constraints of an existing
   protocol, can take maximum advantage of modern network research in
   the basic algorithms needed to solve the problem. Even more
   importantly, the implementor is free to steal from a large number of
   existing academic protocols that have been developed over the years.
   In some cases, if truly new functionality is desired, creating a new
   protocol is the only viable approach.

   The most obvious disadvantage of this approach is the high cost of
   standardizing and distributing an entirely new protocol.  Second,
   there is the issue of making the new protocol reliable. Since new
   protocols have not undergone years of network stress testing, they
   often contain bugs which require backward compatible fixes, and
   hence, the designer is back where he or she started.  A third
   disadvantage of introducing new protocols is that they generally have
   new interfaces which require significant effort on the part of the
   Internet community to use. This alone is often enough to kill a new
   protocol.

   Finally, there is a subtle problem introduced by the very freedom
   provided by this approach. Specifically, being able to introduce a
   new protocol often results in protocols that go far beyond the basic
   needs of the situation.  New protocols resemble Senate appropriations
Show full document text