rfc1263.txt

RFC 的详细文档！

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
   bills; they tend to accumulate many amendments that have nothing to
   do with the original problem. A good example of this phenomena is the
   attempt to standardize VMTP [1] as the Internet RPC protocol. While



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


   VMTP was a large protocol to begin with, the closer it got to
   standardization the more features were added until it essentially
   collapsed under its own weight. As we argue below, new protocols
   should initially be minimal, and then evolve as the situation
   dictates.


2.2.  Backward Compatible Extensions

   In a backward compatible extension, the protocol is modified in such
   a fashion that the new version of the protocol can transparently
   inter-operate with existing versions of the protocol. This generally
   implies no changes to the protocol's header. TCP slow start [3] is an
   example of such a change. In a slightly more relaxed version of
   backward compatibility, no changes are made to the fixed part of a
   protocol's header. Instead, either some fields are added to the
   variable length options field found at the end of the header, or
   existing header fields are overloaded (i.e., used for multiple
   purposes). However, we can find no real advantage to this technique
   over simply changing the protocol.

   Backward compatible extensions are widely used to modify protocols
   because there is no need to synchronize the distribution of the new
   version of the protocol. The new version is essentially allowed to
   diffuse through the Internet at its own pace, and at least in theory,
   the Internet will continue to function as before. Thus, the explicit
   distribution costs are limited. Backward compatible extensions also
   avoid the bureaucratic costs of standardizing a new protocol. TCP is
   still TCP and the approval cost of a modification to an existing
   protocol is much less than that of a new protocol. Finally, the very
   difficulty of making such changes tends to restrict the changes to
   the minimal set needed to solve the current problem. Thus, it is rare
   to see unneeded changes made when using this technique.

   Unfortunately, this approach has several drawbacks. First, the time
   to distribute the new version of the protocol to all hosts can be
   quite long (forever in fact). This leaves the network in a
   heterogeneous state for long periods of time. If there is the
   slightest incompatibly between old and new versions, chaos can
   result. Thus, the implicit cost of this type of distribution can be
   quite high. Second, designing a backward compatible change to a new
   protocol is extremely difficult, and the implementations "tend toward
   complexity and ugliness" [5]. The need for backward compatibility
   ensures that no code can every really be eliminated from the
   protocol, and since such vestigial code is rarely executed, it is
   often wrong. Finally, most protocols have limits, based upon the
   design decisions of it inventors, that simply cannot be side-stepped
   in this fashion.



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


2.3.  Protocol Evolution

   Protocol evolution is an approach to protocol change that attempts to
   escape the limits of backward compatibility without incurring all of
   the costs of creating new protocols. The basic idea is for the
   protocol designer to take an existing protocol that requires
   modification and make the desired changes without maintaining
   backward compatibility.  This drastically simplifies the job of the
   protocol designer. For example, the limited TCP window size could be
   fixed by changing the definition of the window size in the header
   from 16-bits to 32-bits, and re-compiling the protocol. The effect of
   backward compatibility would be ensured by simply keeping both the
   new and old version of the protocol running until most machines use
   the new version. Since the change is small and invisible to the user
   interface, it is a trivial problem to dynamically select the correct
   TCP version at runtime. How this is done is discussed in the next
   section.

   Protocol evolution has several advantages. First, it is by far the
   simplest type of modification to make to a protocol, and hence, the
   modifications can be made faster and are less likely to contain bugs.
   There is no need to worry about the effects of the change on all
   previous versions of the protocol. Also, most of the protocol is
   carried over into the new version unchanged, thus avoiding the design
   and debugging cost of creating an entirely new protocol. Second,
   there is no artificial limit to the amount of change that can be made
   to a protocol, and as a consequence, its useful lifetime can be
   extended indefinitely. In a series of evolutionary steps, it is
   possible to make fairly radical changes to a protocol without
   upsetting the Internet community greatly. Specifically, it is
   possible to both add new features and remove features that are no
   longer required for the current environment.  Thus, the protocol is
   not condemned to grow without bound. Finally, by keeping the old
   version of the protocol around, backward compatibility is guaranteed.
   The old code will work as well as it ever did.

   Assuming the infrastructure described in the following subsection,
   the only real disadvantage of protocol evolution is the amount of
   memory required to run several versions of the same protocol.
   Fortunately, memory is not the scarcest resource in modern
   workstations (it may, however, be at a premium in the BSD kernel and
   its derivatives). Since old versions may rarely if ever be executed,
   the old versions can be swapped out to disk with little performance
   loss. Finally, since this cost is explicit, there is a huge incentive
   to eliminate old protocol versions from the network.






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


2.4.  Infrastructure Support for Protocol Evolution

   The effective use of protocol evolution implies that each protocol is
   considered a vector of implementations which share the same top level
   interface, and perhaps not much else.  TCP[0] is the current
   implementation of TCP and exists to provide backward compatibility
   with all existing machines. TCP[1] is a version of TCP that is
   optimized for high-speed networks.  TCP[0] is always present; TCP[1]
   may or may not be. Treating TCP as a vector of protocols requires
   only three changes to the way protocols are designed and implemented.

   First, each version of TCP is assigned a unique id, but this id is
   not given as an IP protocol number. (This is because IP's protocol
   number field is only 8 bits long and could easily be exhausted.)  The
   "obvious" solution to this limitation is to increase IP's protocol
   number field to 32 bits. In this case, however, the obvious solution
   is wrong, not because of the difficultly of changing IP, but simply
   because there is a better approach. The best way to deal with this
   problem is to increase the IP protocol number field to 32 bits and
   move it to the very end of the IP header (i.e., the first four bytes
   of the TCP header).  A backward compatible modification would be made
   to IP such that for all packets with a special protocol number, say
   77, IP would look into the four bytes following its header for its
   de-multiplexing information. On systems which do not support a
   modified IP, an actual protocol 77 would be used to perform the de-
   multiplexing to the correct TCP version.

   Second, a version control protocol, called VTCP, is used to select
   the appropriate version of TCP for a particular connection. VTCP is
   an example of a virtual protocol as introduced in [2]. Application
   programs access the various versions of TCP through VTCP. When a TCP
   connection is opened to a specific machine, VTCP checks its local
   cache to determine the highest common version shared by the two
   machines. If the target machine is in the cache, it opens that
   version of TCP and returns the connection to the protocol above and
   does not effect performance. If the target machine is not found in
   the cache, VTCP sends a UDP packet to the other machine asking what