doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc1263.txt b/doc/rfc/rfc1263.txt
new file mode 100644
index 0000000..55b6e39
--- /dev/null
+++ b/doc/rfc/rfc1263.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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
+   versions of TCP that machine supports. If it receives a response, it
+   uses that information to select a version and puts the information in
+   the cache.  If no reply is forthcoming, it assumes that the other
+   machine does not support VTCP and attempts to open a TCP[0]
+   connection. VTCP's cache is flushed occasionally to ensure that its
+   information is current.
+
+   Note that this is only one possible way for VTCP to decide the right
+   version of TCP to use. Another possibility is for VTCP to learn the
+   right version for a particular host when it resolves the host's name.
+   That is, version information could be stored in the Domain Name
+
+
+
+O'Malley & Peterson                                             [Page 5]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   System. It is also possible that VTCP might take the performance
+   characteristics of the network into consideration when selecting a
+   version; TCP[0] may in fact turn out to be the correct choice for a
+   low-bandwidth network.
+
+   Third, because our proposal would lead to a more dynamically changing
+   network architecture, a mechanism for distributing new versions will
+   need to be developed. This is clearly the hardest requirement of the
+   infrastructure, but we believe that it can be addressed in stages.
+   More importantly, we believe this problem can be addressed after the
+   decision has been made to go the protocol evolution route.  In the
+   short term, we are considering only a single new version of TCP---
+   TCP[1]. This version can be distributed in the same ad hoc way, and
+   at exactly the same cost, as the backward compatible changes
+   suggested in RFC's 1072 and 1185.
+
+   In the medium term, we envision the IAB approving new versions of TCP
+   every year or so. Given this scenario, a simple distribution
+   mechanism can be designed based on software distribution mechanisms
+   that have be developed for other environments; e.g., Unix RDIST and
+   Mach SUP.  Such a mechanism need not be available on all hosts.
+   Instead, hosts will be divided into two sets, those that can quickly
+   be updated with new protocols and those that cannot.  High
+   performance machines that can use high performance networks will need
+   the most current version of TCP as soon as it is available, thus they
+   have incentive to change.  Old machines which are too slow to drive a
+   high capacity lines can be ignored, and probably should be ignored.
+
+   In the long term, we envision protocols being designed on an
+   application by application basis, without the need for central
+   approval. In such a world, a common protocol implementation
+   environment---a protocol backplane---is the right way to go.  Given
+   such a backplane, protocols can be automatically installed over the
+   network. While we claim to know how to build such an environment,
+   such a discussion is beyond the scope of this paper.
+
+
+2.5.  Remarks
+
+   Each of these three methods has its advantages.  When used in
+   combination, the result is better protocols at a lower overall cost.
+   Backward compatible changes are best reserved for changes that do not
+   affect the protocol's header, and do not require that the instance
+   running on the other end of the connection also be changed.  Protocol
+   evolution should be the primary way of dealing with header fields
+   that are no longer large enough, or when one algorithm is substituted
+   directly for another.  New protocols should be written to off load
+   unexpected user demands on existing protocols, or better yet, to
+
+
+
+O'Malley & Peterson                                             [Page 6]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   catch them before they start.
+
+   There are also synergistic effects. First, since we know it is
+   possible to evolve a newly created protocol once it has been put in
+   place, the pressure to add unnecessary features should be reduced.
+   Second, the ability to create new protocols removes the pressure to
+   overextend a given protocol. Finally, the ability to evolve a
+   protocol removes the pressure to maintain backward compatibility
+   where it is really not possible.
+
+
+3.  TCP Extensions: A Case Study
+
+   This section examines the effects of using our proposed methodology
+   to implement changes to TCP. We will begin by analyzing the backward
+   compatible extensions defined in RFC's 1072 and 1185, and proposing a
+   set of much simpler evolutionary modifications. We also analyze
+   several more problematical extensions to TCP, such as Transactional
+   TCP. Finally, we point our some areas of TCP which may require
+   changes in the future.
+
+   The evolutionary modification to TCP that we propose includes all of
+   the functionality described in RFC's 1072 and 1185, but does not
+   preserve the header format.  At the risk of being misunderstood as
+   believing backward compatibility is a good idea, we also show how our
+   proposed changes to TCP can be folded into a backward compatible
+   implementation of TCP.  We do this as a courtesy for those readers
+   that cannot accept the possibility of multiple versions of TCP.
+
+
+3.1.  RFC's 1072 and 1185
+
+   3.1.1.  Round Trip Timing
+
+   In RFC 1072, a new ECHO option is proposed that allows each TCP
+   packet to carry a timestamp in its header.  This timestamp is used to
+   keep a more accurate estimate of the RTT (round trip time) used to
+   decide when to re-transmit segments. In the original TCP algorithm,
+   the sender manually times a small number of sends. The resulting
+   algorithm was quite complex and does not produce an accurate enough
+   RTT for high capacity networks. The inclusion of a timestamp in every
+   header both simplifies the code needed to calculate the RTT and
+   improves the accuracy and robustness of the algorithm.
+
+   The new algorithm as proposed in RFC 1072 does not appear to have any
+   serious problems. However, the authors of RFC 1072 go to great
+   lengths in an attempt to keep this modification backward compatible
+   with the previous version of TCP. They place an ECHO option in the
+
+
+
+O'Malley & Peterson                                             [Page 7]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   SYN segment and state, "It is likely that most implementations will
+   properly ignore any options in the SYN segment that they do not
+   understand, so new initial options should not cause problems" [4].
+   This statement does not exactly inspire confidence, and we consider
+   the addition of an optional field to any protocol to be a de-facto,
+   if not a de-jure, example of an evolutionary change. Optional fields
+   simply attempt to hide the basic incompatibility inside the protocol,
+   it does not eliminate it.  Therefore, since we are making an
+   evolutionary change anyway, the only modification to the proposed
+   algorithm is to move the fields into the header proper.  Thus, each
+   header will contain 32-bit echo and echo reply fields. Two fields are
+   needed to handle bi-directional data streams.
+
+
+   3.1.2.  Window Size and Sequence Number Space
+
+   Long Fat Networks (LFN's), networks which contain very high capacity
+   lines with very high latency, introduce the possibility that the
+   number of bits in transit (the bandwidth-delay product) could exceed
+   the TCP window size, thus making TCP the limiting factor in network
+   performance.  Worse yet, the time it takes the sequence numbers to
+   wrap around could be reduced to a point below the MSL (maximum
+   segment lifetime), introducing the possibility of old packets being
+   mistakenly accepted as new.
+
+   RFC 1072 extends the window size through the use of an implicit
+   constant scaling factor. The window size in the TCP header is
+   multiplied by this factor to get the true window size.  This
+   algorithm has three problems. First, one must prove that at all times
+   the implicit scaling factor used by the sender is the same as the
+   receiver.  The proposed algorithm appears to do so, but the
+   complexity of the algorithm creates the opportunity for poor
+   implementations to affect the correctness of TCP.  Second, the use of
+   a scaling factor complicates the TCP implementation in general, and
+   can have serious effects on other parts of the protocol.
+
+   A final problem is what we characterize as the "quantum window
+   sizing" problem. Assuming that the scaling factors will be powers of
+   two, the algorithm right shifts the receiver's window before sending
+   it.  This effectively rounds the window size down to the nearest
+   multiple of the scaling factor. For large scaling factors, say 64k,
+   this implies that window values are all multiples of 64k and the
+   minimum window size is 64k; advertising a smaller window is
+   impossible. While this is not necessarily a problem (and it seems to
+   be an extreme solution to the silly window syndrome) what effect this
+   will have on the performance of high-speed network links is anyone's
+   guess. We can imagine this extension leading to future papers
+   entitled "A Quantum Mechanical Approach to Network Performance".
+
+
+
+O'Malley & Peterson                                             [Page 8]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   RFC 1185 is an attempt to get around the problem of the window
+   wrapping too quickly without explicitly increasing the sequence
+   number space.  Instead, the RFC proposes to use the timestamp used in
+   the ECHO option to weed out old duplicate messages. The algorithm
+   presented in RFC 1185 is complex and has been shown to be seriously
+   flawed at a recent End-to-End Research Group meeting.  Attempts are
+   currently underway to fix the algorithm presented in the RFC. We
+   believe that this is a serious mistake.
+
+   We see two problems with this approach on a very fundamental level.
+   First, we believe that making TCP depend on accurate clocks for
+   correctness to be a mistake. The Internet community has NO experience
+   with transport protocols that depend on clocks for correctness.
+   Second, the proposal uses two distinct schemes to deal with old
+   duplicate packets: the sliding window algorithm takes care of "new"
+   old packets (packets from the current sequence number epoch) and the
+   timestamp algorithm deals with "old" old packets (packets from
+   previous sequence number epochs). It is hard enough getting one of
+   these schemes to work much less to get two to work and ensure that
+   they do not interfere with one another.
+
+   In RFC 1185, the statement is made that "An obvious fix for the
+   problem of cycling the sequence number space is to increase the size
+   of the TCP sequence number field." Using protocol evolution, the
+   obvious fix is also the correct one. The window size can be increased
+   to 32 bits by simply changing a short to a long in the definition of
+   the TCP header. At the same time, the sequence number and
+   acknowledgment fields can be increased to 64 bits.  This change is
+   the minimum complexity modification to get the job done and requires
+   little or no analysis to be shown to work correctly.
+
+   On machines that do not support 64-bit integers, increasing the
+   sequence number size is not as trivial as increasing the window size.
+   However, it is identical in cost to the modification proposed in RFC
+   1185; the high order bits can be thought of as an optimal clock that
+   ticks only when it has to.  Also, because we are not dealing with
+   real time, the problems with unreliable system clocks is avoided.  On
+   machines that support 64-bit integers, the original TCP code may be
+   reused.  Since only very high performance machines can hope to drive
+   a communications network at the rates this modification is designed
+   to support, and the new generation of RISC microprocessors (e.g.,
+   MIPS R4000 and PA-RISC) do support 64-bit integers, the assumption of
+   64-bit arithmetic may be more of an advantage than a liability.
+
+
+
+
+
+
+
+
+O'Malley & Peterson                                             [Page 9]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   3.1.3.  Selective Retransmission
+
+   Another problem with TCP's support for LFN's is that the sliding
+   window algorithm used by TCP does not support any form of selective
+   acknowledgment. Thus, if a segment is lost, the total amount of data
+   that must be re-transmitted is some constant times the bandwidth-
+   delay product, despite the fact that most of the segments have in
+   fact arrived at the receiver.  RFC 1072 proposes to extend TCP to
+   allow the receiver to return partial acknowledgments to the sender in
+   the hope that the sender will use that information to avoid
+   unnecessary re-transmissions.
+
+   It has been our experience on predictable local area networks that
+   the performance of partial re-transmission strategies is highly non-
+   obvious, and it generally requires more than one iteration to find a
+   decent algorithm. It is therefore not surprising that the algorithm
+   proposed in RFC 1072 has some problems.  The proposed TCP extension
+   allows the receiver to include a short list of received fragments
+   with every ACK.  The idea being that when the receiver sends back a
+   normal ACK, it checks its queue of segments that have been received
+   out of order and sends the relative sequence numbers of contiguous
+   blocks of segments back to the sender. The sender then uses this
+   information to re-transmit the segments transmitted but not listed in
+   the ACK.
+
+   As specified, this algorithm has two related problems: (1) it ignores
+   the relative frequencies of delivered and dropped packets, and (2)
+   the list provided in the option field is probably too short to do
+   much good on networks with large bandwidth-delay products.  In every
+   model of high bandwidth networks that we have seen, the packet loss
+   rate is very low, and thus, the ratio of dropped packets to delivered
+   packets is very low. An algorithm that returns ACKs as proposed is
+   simply going to have to send more information than one in which the
+   receiver returns NAKs.
+
+   This problem is compounded by the short size of the TCP option field
+   (44 bytes). In theory, since we are only worried about high bandwidth
+   networks, returning ACKs instead of NAKs is not really a problem; the
+   bandwidth is available to send any information that's needed. The
+   problem comes when trying to compress the ACK information into the 44
+   bytes allowed.  The proposed extensions effectively compresses the
+   ACK information by allowing the receiver to ACK byte ranges rather
+   than segments, and scaling the relative sequence numbers of the re-
+   transmitted segments. This makes it much more difficult for the
+   sender to tell which segments should be re-transmitted, and
+   complicates the re-transmission code.  More importantly, one should
+   never compress small amounts of data being sent over a high bandwidth
+   network; it trades a scarce resource for an abundant resource.  On
+
+
+
+O'Malley & Peterson                                            [Page 10]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   low bandwidth networks, selective retransmission is not needed and
+   the SACK option should be disabled.
+
+   We propose two solutions to this problem. First, the receiver can
+   examine its list of out-of-order packets and guess which segments
+   have been dropped, and NAK those segments back to the sender. The
+   number of NAKs should be low enough that one per TCP packet should be
+   sufficient. Note that the receiver has just as much information as
+   the sender about what packets should be retransmitted, and in any
+   case, the NAKs are simply suggestions which have no effect on
+   correctness.
+
+   Our second proposed modification is to increase the offset field in
+   the TCP header from 4 bits to 16 bits.  This allows 64k-bytes of TCP
+   header, which allows us to radically simplify the selective re-
+   transmission algorithm proposed in RFC 1072.  The receiver can now
+   simply send a list of 64-bit sequence numbers for the out-of-order
+   segments to the sender. The sender can then use this information to
+   do a partial retransmission without needing an ouji board to
+   translate ACKs into segments.  With the new header size, it may be
+   faster for the receiver to send a large list than to attempt to
+   aggregate segments into larger blocks.
+
+
+   3.1.4.  Header Modifications
+
+   The modifications proposed above drastically change the size and
+   structure of the TCP header. This makes it a good time to re-think
+   the structure of the proposed TCP header. The primary goal of the
+   current TCP header is to save bits in the output stream. When TCP was
+   developed, a high bandwidth network was 56kbps, and the key use for
+   TCP was terminal I/O.  In both situations, minimal header size was
+   important.  Unfortunately, while the network has drastically
+   increased in performance and the usage pattern of the network is now
+   vastly different, most protocol designers still consider saving a few
+   bits in the header to be worth almost any price. Our basic goal is
+   different: to improve performance by eliminating the need to extract
+   information packed into odd length bit fields in the header.  Below
+   is our first cut at such a modification.
+
+   The protocol id field is there to make further evolutionary
+   modifications to TCP easier. This field basically subsumes the
+   protocol number field contained in the IP header with a version
+   number.  Each distinct TCP version has a different protocol id and
+   this field ensures that the right code is looking at the right
+   header.  The offset field has been increased to 16 bits to support
+   the larger header size required, and to simplify header processing.
+   The code field has been extended to 16 bits to support more options.
+
+
+
+O'Malley & Peterson                                            [Page 11]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   The source port and destination port are unchanged. The size of both
+   the sequence number and ACK fields have been increased to 64 bits.
+   The open window field has been increased to 32 bits. The checksum and
+   urgent data pointer fields are unchanged. The echo and echo reply
+   fields are added.  The option field remains but can be much larger
+   than in the old TCP.  All headers are padded out to 32 bit
+   boundaries.  Note that these changes increase the minimum header size
+   from 24 bytes (actually 36 bytes if the ECHO and ECHO reply options
+   defined in RFC 1072 are included on every packet) to 48 bytes. The
+   maximum header size has been increased to the maximum segment size.
+   We do not believe that the the increased header size will have a
+   measurable effect on protocol performance.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        Protocol ID                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Offset           |              Code             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |              Source           |              Dest             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                              Seq                              |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                              Ack                              |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                            Window                             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |             Checksum          |             Urgent            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                             Echo                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          Echo Reply                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  Options                                      |     Pad       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+   3.1.5.  Backward Compatibility
+
+   The most likely objection to the proposed TCP extension is that it is
+   not backward compatible with the current version of TCP, and most
+   importantly, TCP's header. In this section we will present three
+   versions of the proposed extension with increasing degrees of
+   backward compatibility. The final version will combine the same
+   degree of backward compatibility found in the protocol described in
+
+
+
+O'Malley & Peterson                                            [Page 12]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   RFC's 1072/1185, with the much simpler semantics described in this
+   RFC.
+
+   We believe that the best way to preserve backward compatibility is to
+   leave all of TCP alone and support the transparent use of a new
+   protocol when and where it is needed. The basic scheme is the one
+   described in section 2.4. Those machines and operating systems that
+   need to support high speed connections should implement some general
+   protocol infrastructure that allows them to rapidly evolve protocols.
+   Machines that do not require such service simply keep using the
+   existing version of TCP. A virtual protocol is used to manage the use
+   of multiple TCP versions.
+
+   This approach has several advantages. First, it guarantees backward
+   compatibility with ALL existing TCP versions because such
+   implementations will never see strange packets with new options.
+   Second, it supports further modification of TCP with little
+   additional costs. Finally, since our version of TCP will more closely
+   resemble the existing TCP protocol than that proposed in RFC's
+   1072/1185, the cost of maintaining two simple protocols will probably
+   be lower than maintaining one complex protocol.  (Note that with high
+   probability you still have to maintain two versions of TCP in any
+   case.)  The only additional cost is the memory required for keeping
+   around two copies of TCP.
+
+   For those that insist that the only efficient way to implement TCP
+   modifications is in a single monolithic protocol, or those that
+   believe that the space requirements of two protocols would be too
+   great, we simply migrate the virtual protocol into TCP. TCP is
+   modified so that when opening a connection, the sender uses the TCP
+   VERSION option attached to the SYN packet to request using the new
+   version.  The receiver responds with a TCP VERSION ACK in the SYN ACK
+   packet, after which point, the new header format described in Section
+   3.1.4 is used. Thus, there is only one version of TCP, but that
+   version supports multiple header formats. The complexity of such a
+   protocol would be no worse than the protocol described in RFC
+   1072/1185. It does, however, make it more difficult to make
+   additional changes to TCP.
+
+   Finally, for those that believe that the preservation of the TCP's
+   header format has any intrinsic value (e.g., for those that don't
+   want to re-program their ethernet monitors), a header compatible
+   version of our proposal is possible.  One simply takes all of the
+   additional information contained in the header given in Section 3.1.4
+   and places it into a single optional field. Thus, one could define a
+   new TCP option which consists of the top 32 bits of the sequence and
+   ack fields, the echo and echo_reply fields, and the top 16 bits of
+   the window field. This modification makes it more difficult to take
+
+
+
+O'Malley & Peterson                                            [Page 13]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   advantage of machines with 64-bit address spaces, but at a minimum
+   will be just as easy to process as the protocol described in RFC
+   1072/1185.  The only restriction is that the size of the header
+   option field is still limited to 44 bytes, and thus, selective
+   retransmission using NAKs rather than ACKs will probably be required.
+
+   The key observation is that one should make a protocol extension
+   correct and simple before trying to make it backward compatible.  As
+   far as we can tell, the only advantages possessed by the protocol
+   described in RFC 1072/1185 is that its typical header, size including
+   options, is 8 to 10 bytes shorter. The price for this "advantage" is
+   a protocol of such complexity that it may prove impossible for normal
+   humans to implement. Trying to maintain backward compatibility at
+   every stage of the protocol design process is a serious mistake.
+
+
+3.2.  TCP Over Extension
+
+   Another potential problem with TCP that has been discussed recently,
+   but has not yet resulted in the generation of an RFC, is the
+   potential for TCP to grab and hold all 2**16 port numbers on a given
+   machine.  This problem is caused by short port numbers, long MSLs,
+   and the misuse of TCP as a request-reply protocol. TCP must hold onto
+   each port after a close until all possible messages to that port have
+   died, about 240 seconds. Even worse, this time is not decreasing with
+   increase network performance.  With new fast hardware, it is possible
+   for an application to open a TCP connection, send data, get a reply,
+   and close the connection at a rate fast enough to use up all the
+   ports in less than 240 seconds. This usage pattern is generated by
+   people using TCP for something it was never intended to do---
+   guaranteeing at-most-once semantics for remote procedure calls.
+
+   The proposed solution is to embed an RPC protocol into TCP while
+   preserving backward compatibility. This is done by piggybacking the
+   request message on the SYN packet and the reply message on the SYN-
+   ACK packet. This approach suffers from one key problem: it reduces
+   the probability of a correct TCP implementation to near 0. The basic
+   problem has nothing to do with TCP, rather it is the lack of an
+   Internet request-reply protocol that guarantees at-most-once
+   semantics.
+
+   We propose to solve this problem by the creation of a new protocol.
+   This has already been attempted with VMTP, but the size and
+   complexity of VMTP, coupled with the process currently required to
+   standardize a new protocol doomed it from the start.  Instead of
+   solving the general problem, we propose to use Sprite RPC [7], a much
+   simpler protocol, as a means of off-loading inappropriate users from
+   TCP.
+
+
+
+O'Malley & Peterson                                            [Page 14]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   The basic design would attempt to preserve as much of the TCP
+   interface as possible in order that current TCP (mis)users could be
+   switched to Sprite RPC without requiring code modification on their
+   part. A virtual protocol could be used to select the correct protocol
+   TCP or Sprite RPC if it exists on the other machine. A backward
+   compatible modification to TCP could be made which would simply
+   prevent it from grabbing all of the ports by refusing connections.
+   This would encourage TCP abusers to use the new protocol.
+
+   Sprite RPC, which is designed for a local area network, has two
+   problems when extended into the Internet. First, it does not have a
+   usefully flow control algorithm. Second, it lacks the necessary
+   semantics to reliably tear down connections. The lack of a tear down
+   mechanism needs to be solved, but the flow control problem could be
+   dealt with in later iterations of the protocol as Internet blast
+   protocols are not yet well understood; for now, we could simple limit
+   the size of each message to 16k or 32k bytes. This might also be a
+   good place to use a decomposed version of Sprite RPC [2], which
+   exposes each of these features as separate protocols. This would
+   permit the quick change of algorithms, and once the protocol had
+   stabilized, a monolithic version could be constructed and distributed
+   to replace the decomposed version.
+
+   In other words, the basic strategy is to introduce as simple of RPC
+   protocol as possible today, and later evolve this protocol to address
+   the known limitations.
+
+
+3.3.  Future Modifications
+
+   The header prediction algorithm should be generalized so as to be
+   less sensitive to changes in the protocols header and algorithm.
+   There almost seems to be as much effort to make all modifications to
+   TCP backward compatible with header prediction as there is to make
+   them backward compatible with TCP.  The question that needs to be
+   answered is: are there any changes we can made to TCP to make header
+   prediction easier, including the addition of information into the
+   header.  In [6], the authors showed how one might generalize
+   optimistic blast from VMTP to almost any protocol that performs
+   fragmentation and reassembly.  Generalizing header prediction so that
+   it scales with TCP modification would be step in the right direction.
+
+   It is clear that an evolutionary change to increase the size of the
+   source and destination ports in the TCP header will eventually be
+   necessary.  We also believe that TCP could be made significantly
+   simpler and more flexible through the elimination of the pseudo-
+   header. The solution to this problem is to simply add a length field
+   and the IP address of the destination to the TCP header. It has also
+
+
+
+O'Malley & Peterson                                            [Page 15]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   been mentioned that better and simpler TCP connection establishment
+   algorithms would be useful.  Some form of reliable record stream
+   protocol should be developed.  Performing sliding window and flow
+   control over records rather than bytes would provide numerous
+   opportunities for optimizations and allow TCP to return to its
+   original purpose as a byte-stream protocol. Finally, it has become
+   clear to us that the current Internet congestion control strategy is
+   to use TCP for everything since it is the only protocol that supports
+   congestion control. One of the primary reasons many "new protocols"
+   are proposed as TCP options is that it is the only way to get at
+   TCP's congestion control. At some point, a TCP-independent congestion
+   control scheme must be implemented and one might then be able to
+   remove the existing congestion control from TCP and radically
+   simplify the protocol.
+
+
+4.  Discussion
+
+   One obvious side effect of the changes we propose is to increase the
+   size of the TCP header. In some sense, this is inevitable; just about
+   every field in the header has been pushed to its limit by the radical
+   growth of the network. However, we have made very little effort to
+   make the minimal changes to solve the current problem. In fact, we
+   have tended to sacrifice header size in order to defer future changes
+   as long as possible. The problem with this is that one of TCP's
+   claims to fame is its efficiency at sending small one byte packets
+   over slow networks. Increasing the size of the TCP header will
+   inevitably result in some increase in overhead on small packets on
+   slow networks. Clark among others have stated that they see no
+   fundamental performance limitations that would prevent TCP from
+   supporting very high speed networks. This is true as far as it goes;
+   there seems to be a direct trade-off between TCP performance on high
+   speed networks and TCP performance on slow speed networks. The
+   dynamic range is simply too great to be optimally supported by one
+   protocol. Hence, in keeping around the old version of TCP we have
+   effectively split TCP into two protocols, one for high bandwidth
+   lines and the other for low bandwidth lines.
+
+   Another potential argument is that all of the changes mentioned above
+   should be packaged together as a new version of TCP. This version
+   could be standardized and we could all go back to the status quo of
+   stable unchanging protocols.  While to a certain extent this is
+   inevitable---there is a backlog of necessary TCP changes because of
+   the current logistical problems in modifying protocols---it is only
+   begs the question. The status quo is simply unacceptably static;
+   there will always be future changes to TCP.  Evolutionary change will
+   also result in a better and more reliable TCP.  Making small changes
+   and distributing them at regular intervals ensures that one change
+
+
+
+O'Malley & Peterson                                            [Page 16]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   has actually been stabilized before the next has been made.  It also
+   presents a more balanced workload to the protocol designer; rather
+   than designing one new protocol every 10 years he makes annual
+   protocol extensions. It will also eventually make protocol
+   distribution easier: the basic problem with protocol distribution now
+   is that it is done so rarely that no one knows how to do it and there
+   is no incentive to develop the infrastructure needed to perform the
+   task efficiently.  While the first protocol distribution is almost
+   guaranteed to be a disaster, the problem will get easier with each
+   additional one. Finally, such a new TCP would have the same problems
+   as VMTP did; a radically new protocol presents a bigger target.
+
+   The violation of backward compatibility in systems as complex as the
+   Internet is always a serious step. However, backward compatibility is
+   a technique, not a religion. Two facts are often overlooked when
+   backward compatibility gets out of hand. First, violating backward
+   compatibility is always a big win when you can get away with it.  One
+   of the key advantages of RISC chips over CISC chips is simply that
+   they were not backward compatible with anything. Thus, they were not
+   bound by design decisions made when compilers were stupid and real
+   men programmed in assembler. Second, one is going to have to break
+   backward compatibility at some point anyway. Every system has some
+   headroom limitations which result in either stagnation (IBM mainframe
+   software) or even worse, accidental violations of backward
+   compatibility.
+
+   Of course, the biggest problem with our approach is that it is not
+   compatible with the existing standardization process. We hope to be
+   able to design and distribute protocols in less time than it takes a
+   standards committee to agree on an acceptable meeting time.  This is
+   inevitable because the basic problem with networking is the
+   standardization process. Over the last several years, there has been
+   a push in the research community for lightweight protocols, when in
+   fact what is needed are lightweight standards.  Also note that we
+   have not proposed to implement some entirely new set of "superior"
+   communications protocols, we have simply proposed a system for making
+   necessary changes to the existing protocol suites fast enough to keep
+   up with the underlying change in the network.  In fact, the first
+   standards organization that realizes that the primary impediment to
+   standardization is poor logistical support will probably win.
+
+
+5.  Conclusions
+
+   The most important conclusion of this RFC is that protocol change
+   happens and is currently happening at a very respectable clip.  While
+   all of the changes given as example in this document are from TCP,
+   there are many other protocols that require modification.  In a more
+
+
+
+O'Malley & Peterson                                            [Page 17]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+   prosaic domain, the telephone company is running out of phone
+   numbers; they are being overrun by fax machines, modems, and cars.
+   The underlying cause of these problems seems to be an consistent
+   exponential increase almost all network metrics: number of hosts,
+   bandwidth, host performance, applications, and so on, combined with
+   an attempt to run the network with a static set of unchanging network
+   protocols.  This has been shown to be impossible and one can almost
+   feel the pressure for protocol change building. We simply propose to
+   explicitly deal with the changes rather keep trying to hold back the
+   flood.
+
+   Of almost equal importance is the observation that TCP is a protocol
+   and not a platform for implementing other protocols. Because of a
+   lack of any alternatives, TCP has become a de-facto platform for
+   implementing other protocols. It provides a vague standard interface
+   with the kernel, it runs on many machines, and has a well defined
+   distribution path. Otherwise sane people have proposed Bounded Time
+   TCP (an unreliable byte stream protocol), Simplex TCP (which supports
+   data in only one direction) and Multi-cast TCP (too horrible to even
+   consider).  All of these protocols probably have their uses, but not
+   as TCP options. The fact that a large number of people are willing to
+   use TCP as a protocol implementation platform points to the desperate
+   need for a protocol independent platform.
+
+   Finally, we point out that in our research we have found very little
+   difference in the actual technical work involved with the three
+   proposed methods of protocol modification. The amount of work
+   involved in a backward compatible change is often more than that
+   required for an evolutionary change or the creation of a new
+   protocol.  Even the distribution costs seem to be identical.  The
+   primary cost difference between the three approaches is the cost of
+   getting the modification approved. A protocol modification, no matter
+   how extensive or bizarre, seems to incur much less cost and risk. It
+   is time to stop changing the protocols to fit our current way of
+   thinking, and start changing our way of thinking to fit the
+   protocols.
+
+
+6.  References
+
+
+[1]  Cheriton D., "VMTP: Versatile Message Transaction Protocol", RFC
+     1045, Stanford University, February 1988.
+
+
+[2]  Hutchinson, N., Peterson, L., Abbott, M., and S. O'Malley, "RPC in
+     the x-Kernel: Evaluating New Design Techniques", Proceedings of the
+     12th Symposium on Operating System Principles, Pgs. 91-101,
+
+
+
+O'Malley & Peterson                                            [Page 18]
+
+RFC 1263           TCP Extensions Considered Harmful        October 1991
+
+
+     December 1989.
+
+
+[3]  Jacobson, V., "Congestion Avoidance and Control", SIGCOMM '88,
+     August 1988.
+
+
+[4]  Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths",
+     RFC 1072, LBL, ISI, October 1988.
+
+
+[5]  Jacobson, V., Braden, R., and L. Zhang, "TCP Extensions for High-
+     Speed Paths", RFC 1185, LBL, ISI, PARC, October 1990.
+
+
+[6]  O'Malley, S., Abbott, M., Hutchinson, N., and L. Peterson, "A Tran-
+     sparent Blast Facility", Journal of Internetworking, Vol. 1, No.
+     2, Pgs. 57-75, December 1990.
+
+
+[7]  Welch, B., "The Sprite Remote Procedure Call System", UCB/CSD
+     86/302, University of California at Berkeley, June 1988.
+
+7.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+8.  Authors' Addresses
+
+   Larry L. Peterson
+   University of Arizona
+   Department of Computer Sciences
+   Tucson, AZ 85721
+
+   Phone: (602) 621-4231
+   EMail: llp@cs.arizona.edu
+
+
+   Sean O'Malley
+   University of Arizona
+   Department of Computer Sciences
+   Tucson, AZ 85721
+
+   Phone: 602-621-8373
+   EMail: sean@cs.arizona.edu
+
+
+
+
+
+O'Malley & Peterson                                            [Page 19]
+
\ No newline at end of file